docker-in-docker(dind)服务在gitlab ci中的作用 [英] Role of docker-in-docker (dind) service in gitlab ci

问题描述

根据官方 gitlab文档是在 ci 管道中启用 docker build 的一种方法，是利用 dind 服务(以> gitlab-ci 服务).

According to the official gitlab documentation, one way to enable docker build within ci pipelines, is to make use of the dind service (in terms of gitlab-ci services).

但是，就像在docker executor上运行ci作业的情况一样，还需要 docker:latest 映像.

However, as it is always the case with ci jobs running on docker executors, the docker:latest image is also needed.

有人可以解释:

• docker:dind 和 docker:latest 图像之间有什么区别?
• (最重要的是):为什么是两者都是服务和所需的docker映像(例如，如

• what is the difference between the docker:dind and the docker:latest images?
• (most importantly): why are both the service and the docker image needed (e.g. as indicated in this example, linked to from the github documentation) to perform e.g. a docker build whithin a ci job? doesn't the docker:latest image (within which the job will be executed!) incorporate the docker daemon (and I think the docker-compose also), which are the tools necessary for the commands we need (e.g. docker build, docker push etc)?

除非我错了，否则问题或多或少变成了:

Unless I am wrong, the question more or less becomes:

为什么Docker客户端和Docker守护程序不能驻留在相同的Docker(已启用)容器中

Why a docker client and a docker daemon cannot reside in the same docker (enabled) container

推荐答案

docker:dind和docker:latest映像之间有什么区别?

what is the difference between the docker:dind and the docker:latest images?

• docker:latest 包含连接到Docker守护程序所需的所有内容，即运行 docker build ， docker run 等.它也包含docker守护进程，但是它没有作为入口点启动.
• docker:dind a>建立在 docker:latest 上，并启动docker守护程序作为其入口点.
• docker:latest contains everything necessary to connect to a docker daemon, i.e., to run docker build, docker run and such. It also contains the docker daemon but it's not started as its entrypoint.
• docker:dind builds on docker:latest and starts a docker daemon as its entrypoint.

因此，它们的内容几乎相同，但是通过它们的入口点，其中一个被配置为作为客户端连接到 tcp://docker:2375 ，而另一个则用于守护程序.

So, their content is almost the same but through their entrypoints one is configured to connect to tcp://docker:2375 as a client while the other is meant to be used for a daemon.

为什么同时需要服务和docker映像[…]?

why are both the service and the docker image needed […]?

您不需要两者.您可以只使用两者之一，首先启动 dockerd ，然后像往常一样运行 docker build 和 docker run 命令，例如我在此处做过；显然，这有时是gitlab 中的原始方法.但是我发现只编写 service:docker:dind 而不是使用 before_script 来设置 dockerd 更干净.另外，您也不必弄清楚如何启动&

You don't need both. You can just use either of the two, start dockerd as a first step, and then run your docker build and docker run commands as usual like I did here; apparently this was the original approach in gitlab at some point. But I find it cleaner to just write service: docker:dind instead of having a before_script to setup dockerd. Also you don't have to figure out how to start & install dockerd properly in your base image (if you are not using docker:latest.)

在您的 .gitlab-ci.yml 中声明服务，如果您知道跑步者正在安装其/var/run/，则还可以轻松地换出docker-in-dockerdocker.sock 进入您的图像.您可以设置受保护的变量 DOCKER_HOST 到 unix:///var/run/docker.sock 以获得更快的构建.其他无权访问此转轮的人仍可以派生您的存储库并回退到 dind 服务，而无需修改您的 .gitlab-ci.yml .

Declaring the service in your .gitlab-ci.yml also lets you swap out the docker-in-docker easily if you know that your runner is mounting its /var/run/docker.sock into your image. You can set the protected variable DOCKER_HOST to unix:///var/run/docker.sock to get faster builds. Others who don't have access to such a runner can still fork your repository and fallback to the dind service without modifying your .gitlab-ci.yml.

这篇关于docker-in-docker(dind)服务在gitlab ci中的作用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！