Can you elaborate on what you mean by new/old docker-linux-container?
Are you refering to images, and asking wether it makes a difference if an image was build using an old docker version works with a recent docker version?
Container runtimes use images according the OCI container image specs.
Practicaly, you can build container images and run container based on them without docker. You could use buildkit directly, kaniko or podman to build your image. You could run your containers on kubernetes, podman, crio, containerd …
Which translates to “Can I run a container based on a very new linux container image with a very old docker-daemon?”
I don’t see a reson why not, as long as you are talling about vanila docker. I can imaging this is not always the case with modifed forks.
I’ve this question, because I wanna provide some docker-container to some peoples.
My docker-containers have inside a very new linux, but these people which are running my docker-container don’t want to upgrade their docker-daemon, because it’s only allowed for they to install stuff from the official redhat-repository, and there is only a very old docker-daemon in the official redhat-repository.
From my point of view, the docker distributions you get from docker’s repositories are vanila docker.
From my point ov view, this is not a vanila docker distribution, as redhat forked and customized the docker sources to align them with their own operating system and philosophy.
This doesn’t necessarily mean it will not work, but it means that there is no guaranty that redhat’s docker distribution behaves like a vanila docker distribution.
Are they still on 1.13 something? Even if, this version should already work with OCI complient container images, regardless if build with docker, buildkit, buildah, kaniko or whatever tool used that creats OCI complient container images…
Okay, it does not work!
I’ve a very new docker-linux-container (debian-11) with an very old docker-daemon (18.06.1-ce, build e68fc7a).
If I’m trying to run this new docker-linux-container with this old docker-daemon, a normal file-system-listing in the container shows me only question marks and I got permissions issue with the root user:
Can you run any container using docker directly without docker-compose? For example:
docker run --rm -it bash ls -la /
Can you try an old container on the old docker daemon? Does that work? For example:
docker run --rm -it bash:4.4.0 ls -la /
which is from 2018.
What is your storage driver? If you could share the output of
docker info
I think that could also help to identify the cause.
What is the filesystem under your docker root dir? (/var/lib/docker by default) Is it a network filesystem?
What happens when you try to list files of a running container on the host?
docker run -d --name test httpd:2.4
docker container inspect test
sudo ls -la $(docker container inspect test --format '{{ .GraphDriver.Data.MergedDir }}')
I guess it is just a similar, changed config, not what you used. Metin probably asked for the original (if that can be shared), because the “special” part is often not what keywords you use, but what values those have. Although I think if you can answer my questions, that can also help us to help you.
No, I don’t have security features enabled, I don’t know about security features.
It’s just very new docker-linux-container (debian-11) with an very old docker-daemon (18.06.1-ce, build e68fc7a).
Nothing more, nothing special
You can run getenforce to see wether selinux is set to enforced, permissive or disabled.
Running container with enforced selinux is a different beast, you might want to check this blog post Selinux with Containers. I had people taking care of creating selinux polices for containers whenever something didn’t run and I never asked how they actualy created them.
Docker-CE on CentOS should have come with a selinux policy package. As far as I remember installing the CentOS packages on RHEL lacked a dependency in that area. I never liked docker on RHEL based systems…
For testing purposes this should be fine. But I would advise against making it a permanent solution, as deactivating selinux will have a bad impact on the security.
You might want to wait for someone with current experience in running Docker on a RHEL-based system. Last time I used Docker EE on Rhel was 3-4 years ago…