5 ms·

CI/CD systems on AWS, Azure, GCP and others might be running on Kubernetes containers (using kaniko, podman, etc) or using Docker-in-Docker, and there isn't a w

CI/CD systems on AWS, Azure, GCP and others might be running on Kubernetes containers (using kaniko, podman, etc) or using Docker-in-Docker, and there isn't a widely supported or in-cloud-platform tool for sharing cached layers. And as pointed out below, even if you are intelligently caching layers, manifest requests count as a pull. As far as I know, no caching proxies exist for Docker that support limiting manifest pulls.

stingraycharles 6y ago
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?

stingraycharles 6y ago

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?