3 ms·

Surprised to see Docker-in-Docker mentioned so deeply down here. It’s an extremely valid way of doing things, and non-trivial to implement a caching layer for.

boudin 6y ago
Usually docker outside of docker is used, no? If the image is cached on the host, it would be available to any container having access to the docker daemon socket as well since it's the same daemon.
- stingraycharles 6y ago
  No that’s only the case if you mount the Docker socket into the container, which is not what Docker-in-Docker is.
pbalau 6y ago
Isn't Docker-in-Docker actually using the host's Docker daemon? I am mounting the docker socket in all my Docker-in-Docker containers, thus all the build tasks running on the same host can share the caches. I guess one could have docker containers that actually run docker, but I don't see a reason to do that...
- cpuguy83 6y ago
  No Docker-in-Docker would generally refer to running a new dockerd inside of a container.
- eblanshey 6y ago
  I was wondering how Docker-in-Docker works, but I couldn't find it dockermented anywhere. If it's using the host's Docker daemon, why do you need to mount the docker socket?
  - kinghajj 6y ago
    Docker-in-Docker (DinD) doesn't piggy back on the host's Docker daemon, but instead runs a stripped-down Docker daemon inside of the container. The major downside is that I/O is quite slow, since you're going through two virtualization layers (the DinD one, plus the host Docker daemon).
    - eblanshey 6y ago
      Will mounting the socket, as the person I replied to suggested, make it use the host's docker daemon?
      - pbalau 6y ago
        Yes, that's the point.
    - cpuguy83 6y ago
      This is not true. There is, effectively, no "virtualization" layer here. There are some things that if needed can cause overhead... such as the bridge networking (really shouldn't be a bottleneck for majority of people), and the CoW filesystem... which docker won't be (or shouldn't be) running on top of since, for example, overlayfs on top of overlayfs is not supported. There is also nothing stripped down about the daemon inside of the container.
      - kinghajj 6y ago
        Sure, I was speaking off the cuff based on my experience from a few years ago. Maybe I messed up and somehow had the DinD daemon not use a volume mount, and that's what caused it to build images slowly?
        cpuguy83 6y ago
        Very well could be since it would have to fallback to the naive graphdriver that just copies stuff around.
  - 6y ago

boudin 6y ago

Usually docker outside of docker is used, no? If the image is cached on the host, it would be available to any container having access to the docker daemon socket as well since it's the same daemon.

stingraycharles 6y ago
No that’s only the case if you mount the Docker socket into the container, which is not what Docker-in-Docker is.

pbalau 6y ago

Isn't Docker-in-Docker actually using the host's Docker daemon? I am mounting the docker socket in all my Docker-in-Docker containers, thus all the build tasks running on the same host can share the caches. I guess one could have docker containers that actually run docker, but I don't see a reason to do that...

cpuguy83 6y ago
No Docker-in-Docker would generally refer to running a new dockerd inside of a container.
eblanshey 6y ago
I was wondering how Docker-in-Docker works, but I couldn't find it dockermented anywhere. If it's using the host's Docker daemon, why do you need to mount the docker socket?
- kinghajj 6y ago
  Docker-in-Docker (DinD) doesn't piggy back on the host's Docker daemon, but instead runs a stripped-down Docker daemon inside of the container. The major downside is that I/O is quite slow, since you're going through two virtualization layers (the DinD one, plus the host Docker daemon).
  - eblanshey 6y ago
    Will mounting the socket, as the person I replied to suggested, make it use the host's docker daemon?
    - pbalau 6y ago
      Yes, that's the point.
  - cpuguy83 6y ago
    This is not true. There is, effectively, no "virtualization" layer here. There are some things that if needed can cause overhead... such as the bridge networking (really shouldn't be a bottleneck for majority of people), and the CoW filesystem... which docker won't be (or shouldn't be) running on top of since, for example, overlayfs on top of overlayfs is not supported. There is also nothing stripped down about the daemon inside of the container.
    - kinghajj 6y ago
      Sure, I was speaking off the cuff based on my experience from a few years ago. Maybe I messed up and somehow had the DinD daemon not use a volume mount, and that's what caused it to build images slowly?
      - cpuguy83 6y ago
        Very well could be since it would have to fallback to the naive graphdriver that just copies stuff around.
- 6y ago