Mounting your host’s socket to this path means docker commands run inside the container will execute against your existing Docker daemon. The Docker CLI inside the docker image interacts with the Docker daemon socket it finds at /var/run/docker.sock. v /var/run/docker.sock:/var/run/docker.sock In many scenarios, you can achieve the intended effect by mounting your host’s Docker socket into a regular docker container: docker run -d -name docker The challenges associated with dind are best addressed by avoiding its use altogether. Mounting Your Host’s Docker Socket Instead This can create incompatibilities if the inner daemon is configured to use a storage driver which can’t be used on top of an existing CoW filesystem. All its containers, including the inner Docker daemon, will sit on a copy-on-write (CoW) filesystem though. The outer daemon will run atop your host’s regular filesystem such as ext4. This occurs when the inner Docker applies LSM policies that the outer daemon can’t anticipate.Īnother challenge concerns container filesystems. Certain systems may experience conflicts with Linux Security Modules (LSM) such as AppArmor and SELinux. It may be an unacceptable security risk in some environments though. This is necessary in a Docker-in-Docker scenario so your inner Docker is able to create new containers. Using privileged mode gives the container complete access to your host system. Privileged mode is activated by the -privileged flag in the command shown above.
This constraint applies even if you’re using rootless containers. Using Docker-in-Docker in this way comes with one big caveat: you need to use privileged mode.
0 kommentar(er)
