https://pantsbuild.org/ logo
#general
Title
# general
s

silly-spring-87100

12/30/2021, 1:06 PM
In my gitlab-ci I need to build docker images with
./pants pacakge
Unfortunately
docker:dind
image (we are using it curentlly) is not compatible with pants: • alpine linux • missing python What image would you use, to build and push docker images with
pants
inside CI container?
c

curved-television-6568

12/30/2021, 1:23 PM
Hi, From https://hub.docker.com/_/docker?tab=description
Before running Docker-in-Docker, be sure to read through Jérôme Petazzoni's excellent blog post on the subject, where he outlines some of the pros and cons of doing so (and some nasty gotchas you might run into).
If you are still convinced that you need Docker-in-Docker and not just access to a container’s host Docker server, then read on.
And at the end of that linked blog post:
The socket solution
Let’s take a step back here. Do you really want Docker-in-Docker? Or do you just want to be able to run Docker (specifically: build, run, sometimes push containers and images) from your CI system, while this CI system itself is in a container?
I’m going to bet that most people want the latter. All you want is a solution so that your CI system like Jenkins can start containers.
And the simplest way is to just expose the Docker socket to your CI container, by bind-mounting it with the 
-v
 flag.
Simply put, when you start your CI container (Jenkins or other), instead of hacking something together with Docker-in-Docker, start it with:
docker run -v /var/run/docker.sock:/var/run/docker.sock ...
Now this container will have access to the Docker socket, and will therefore be able to start containers. Except that instead of starting “child” containers, it will start “sibling” containers.
Try it out, using the 
docker
 official image (which contains the Docker binary):
docker run -v /var/run/docker.sock:/var/run/docker.sock \
-ti docker
This looks like Docker-in-Docker, feels like Docker-in-Docker, but it’s not Docker-in-Docker: when this container will create more containers, those containers will be created in the top-level Docker. You will not experience nesting side effects, and the build cache will be shared across multiple invocations.
So, have you looked at the possibility to use the hosts docker daemon, rather than to run a docker daemon inside a container?
That is, I would recommend with building an image that has the tools you need to run pants, and a docker client, and then bind-mount the docker.sock into that container so you can build and push docker images using the docker client in the container..
f

flat-zoo-31952

12/30/2021, 2:39 PM
there's important security implications of running with a socket bind though: you're basically giving full root access to the host machine to every CI job via that socket (since you can essentially mount whatever files you want, and run things as
--privileged
etc). This is probably acceptable for many circumstances, but if you're doing something like running PRs from strangers on owned infra, be really careful
c

curved-television-6568

12/30/2021, 2:54 PM
True, but I’d say you’d have to be equally careful regardless of what you do, if you’re running stuff from strangers, not only when involving docker 😉
f

flat-zoo-31952

12/30/2021, 3:24 PM
definitely... it's just something to consider... 😌
👍 1
(I'm a big fan of host docker sharing over dind for 99% of use cases. And it used to be even easier when they build docker statically as a fat binary and you could just mount /usr/bin/docker too)