5 ms·
> Docker-in-Docker paradigm Apologies for the patronising comment, but do you really mean that? Docker in Docker works but is intended for the developers of Do
by quietbritishjim 6y ago
> Docker-in-Docker paradigm
Apologies for the patronising comment, but do you really mean that? Docker in Docker works but is intended for the developers of Docker to debug Docker itself. Usually for running Docker from within a container, you just hook up the Docker client to the TCP port of the Docker daemon running outside the container, which isn't strictly Docker-in-Docker.
I ask this in case you're trying a wildly use case (if you really are running true Docker-in-Docker), or are making an unfair comparison (if you're just using the usual Docker client in container to daemon on host). In the latter case, I must admit I don't know what the idiomatic alternative would be for podman, given that I know nothing about it except that it's daemonless (and even that I only learned by reading your comment).
- felipelemos 6y agoThere are some reasons to use docker in docker beyond debug docker itself. For example, in Jenkins case, select specific proxy settings for the daemon for a specific job without affecting other jobs in the same node.
- solotronics 6y agoI also needed to run docker commands from within a container (Jenkins container executing docker cmds on the host it's running on). I don't know how common this is but I had the same use case.
- flerchin 6y agoWe docker-in-docker too, exactly as OP describes. In jenkins CI/CD.
- nhoughto 6y agoDocker in docker is a very common pattern in CI, in some cases is the only way to achieve certain tasks.
- haberman 6y agoWhat kinds of tasks require two levels of containers?
- bogomipz 6y agoYour CI server running in a container that is itself executing Docker commands.
- wwright 6y agoAs mentioned elsewhere in the thread, this does not require DinD. You can connect to the host’s Docker daemon. (Other interfaces such as K8S are also much safer.)
- hinkley 6y agoIsn't exposing the host Docker daemon the security issue that people grouse about?
- bogomipz 6y agoYes it is. The Docker socket - /var/run/docker.sock is owned by root and so anyone that has access to it effectively has root on that host. User namespace mitigate this to some degree.
- bogomipz 6y agoYes and I am one of those people who mentioned elsewhere that this does not require DinD. Please reread the question I am actually responding to which is a general questions "What kinds of tasks ...?" The parent is asking what 'problem is the DinD solution is solving for. You also can not connect to the host's Docker socket if you do not manage that host where Docker is running in the first place.
- defen 6y agoYou need more constraints than that to explain why you can't just mount /run/docker.sock in the CI container.
- bogomipz 6y agoThere is also Kaniko which works quite well: https://github.com/GoogleContainerTools/kaniko https://github.com/GoogleContainerTools/kaniko
- bmurphy1976 6y agoWe use docker-in-docker as well to deploy our Jenkins workers. It has it's pros (running Ubuntu 18.04 and Ubuntu 20.04 workers side-by-side and ease of pushing out an update) but it's fragile and confusing. Things can get really hacky when you need to start sharing volumes or injecting additional configuration. I'm much more confident with packer now though. Next time I do any major work on our Jenkins infrastructure I'm ripping out docker-in-docker for the workers and replacing it with packer built images.
- outworlder 6y ago> but is intended for the developers of Docker to debug Docker itself Heh. We use DIND with docker compose to have a container which has KUBERNETES inside. And it even works. How's that for a wild use-case? EDIT: That's done to create a local dev environment, with K8s, localstack, infra, etc. Instead of having multiple machines or deploying everything outside containers.
- WatchDog 6y agoI do a lot of build automation work, and running containers within containers would be super useful for me. That said docker-in-docker doesn't work without running privileged or forwarding the host port. It's a non-starter for me, there are the obvious security problems, but also practical non-security issues. Forwarding the port causes encapsulation issues, a build job can finish leaving stuff running, can also interfere with other jobs on the system. Using privileged containers isn't an option when using things like ECS fargate.
- Too 6y agoI think what most people mean when they say docker-in-docker is in layman terms. You simply just a way to do "docker run" from within another container. Whether that's done by actually running docking daemon inside or mounting something from the host or whatever else i don't really care. I just want it to work. Sure, there are some details you might want to control, like image caches and such being shared with host, i just find there is a lack of documentation and best practices of how to do nested docker, if that is even intended to work or if mounting docker.sock is an unsupported hack. Most information found about this is scattered on shady blogs. For the examples of CI brought up the use cases are fairly obvious, you have a jenkins installation with x plugins installed - running as a container. Within this jenkins you are building multiple different projects which all require their own respective image to build. As a project developer here i don't even want to know if this jenkins is a bare metal, a vm or a container. Here docker is more used to bundle all the dependencies, not for strict security with perfect containerization.