根据官方gitlab documentation,在ci管道中启用docker build的一种方法是使用dind服务(就gitlab-ci services而言).
但是,由于在docker执行器上运行ci作业总是如此,所以还需要docker：latest image.
有人能解释一下：
> docker：dind和docker之间有什么区别：最新图片？
>(最重要的)：为什么需要服务和泊坞窗图像(例如,如从in this example所示,从github文档链接)来执行例如一个码头工人在一个ci工作？不是docker：最新的图像(作业将在其中执行！)包含docker守护进程(我认为还有docker-compose),这是我们需要的命令所需的工具(例如docker build,docker push)等等)？
除非我错了,否则问题或多或少会变成：
Why a docker client and a docker daemon cannot reside in the same docker (enabled) container
what is the difference between the docker:dind and the docker:latest images?
> docker:latest包含连接到docker守护程序所需的所有内容,即运行docker build,docker run等.它还包含docker守护程序,但它不是作为入口点启动的.
> docker:dind在docker：latest上构建并启动docker守护进程作为其入口点.
因此,它们的内容几乎相同,但是通过它们的入口点,一个被配置为连接到tcp：// docker：2375作为客户端,而另一个用于守护进程.
why are both the service and the docker image needed […]?
你不需要两者.您可以使用两者中的任何一个,作为第一步启动dockerd,然后照常运行docker build和docker run命令,就像我做的那样here;显然这是gitlab at some point中的原始方法.但我发现只写代码更简洁：docker：dind而不是使用before_script来设置dockerd.此外,你不必弄清楚如何开始&在基本映像中正确安装dockerd(如果您没有使用docker：latest.)
如果您知道您的跑步者正在将/var/run/docker.sock挂载到您的图像中,那么在.gitlab-ci.yml中声明该服务还可以让您轻松更换docker-in-docker.您可以将protected variable DOCKER_HOST设置为unix：///var/run/docker.sock以获得更快的构建.其他无法访问此类运行器的人仍然可以分叉您的存储库并回退到dind服务,而无需修改.giltab-ci.yml.
