GitLab Runner Docker Executor 中的缓存层 - Long Time DinD Container

Question

我正在我的项目中研究 GitLab CI，我创建了一个图像来进行我的测试和构建。当我在 docker executor 中运行它时，每个作业都需要从一开始就下载图像。我需要缓存层和拉取的图像以改善我的构建和部署时间（5 分钟，使用不安全选项最多 1 分钟）。

我搜索了多个链接和多个文章，很多人都有同样的问题。但是，GitLab 团队并没有解决这个问题。而且社区没有可靠且安全的解决方案。下面的链接遵循同样的问题：

1. 最佳答案不起作用：在 gitlab ci docker executor 中存储层
2. 多次更改绕过问题，但没有任何效果：https : //blog.scottlogic.com/2018/02/09/multi-dind-ci-boxes.html
3. 不使用挂载docker.sock 的讨论：https : //gitlab.com/gitlab-org/gitlab-foss/issues/17769
4. 使用挂载docker.sock 的讨论：https : //jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/
5. 构建一个长时间的容器（不要和我一起工作）：https : //medium.com/@tonywooster/docker-in-docker-in-gitlab-runners-220caeb708ca
6. 不挂载docker.sock 的文档：https : //docs.gitlab.com/ce/ci/docker/using_docker_build.html#use-docker-in-docker-executor
7. 卷配置示例：https : //github.com/ayufan/gitlab-ci-multi-runner/blob/master/docs/configuration/advanced-configuration.md#the-runnersdocker-section

最可能的方法（使用层缓存）是使用单独的容器并使运行器连接到它，并从中触发执行。这样，所有层都将位于“无限生命”容器中，并且不会在阶段结束时丢失所有缓存。考虑将docker.sock作为挂载公开的方法不仅不安全，而且在容器之间共享文件时也存在许多问题，因为它们都是兄弟姐妹，而不是共享卷的父子。

使用无限生命容器的方法如下所示：

docker run --privileged --name gitlab-dind -d --restart=always  docker:19-dind --storage-driver=overlay2

或者

docker network create gitlab-runner-net

docker run --privileged --name gitlab-runner-dind --network gitlab-runner-net --publish=2375:2375 --publish=2376:2376 -d docker:19-dind --storage-driver=overlay2

然后修改config.toml如下：

[runners.docker]
  tls_verify = false
  image = "docker:19"   <--------
  privileged = false     <--------
  disable_cache = false
  volumes = ["/cache"]
  links = ["gitlab-runner-dind:docker"]   <-----------
  shm_size = 0
[runners.cache]

或分别

[runners.docker]
  host = "tcp://gitlab-runner-dind:2375"    <--------
  tls_verify = false
  image = "docker:19"   <--------
  privileged = true     <--------
  disable_cache = false
  volumes = ["/cache"]
  network_mode = "gitlab-runner-net"   <-----------
  shm_size = 0
[runners.cache]

我也尝试过使用环境变量（在config.toml和.gitlab-ci.yml 上）：

DOCKER_TLS_CERTDIR=""
DOCKER_HOST=tcp://gitlab-runner-dind:2375

并从.gitlab-ci.yml 中删除：

services:
  - docker:19-dind
  alias: docker

我目前的结果是：

Running with gitlab-runner 12.4.1 (HASH)
  on NAME_OF_MY_RUNNER HASH
ERROR: Preparation failed: error during connect: Get http://gitlab-runner-dind:2375/v1.25/info: dial tcp: lookup gitlab-runner-dind on 172.31.0.2:53: no such host (executor_docker.go:980:0s)
Will be retried in 3s ...
ERROR: Preparation failed: error during connect: Get http://gitlab-runner-dind:2375/v1.25/info: dial tcp: lookup gitlab-runner-dind on 172.31.0.2:53: no such host (executor_docker.go:980:0s)
Will be retried in 3s ...
ERROR: Preparation failed: error during connect: Get http://gitlab-runner-dind:2375/v1.25/info: dial tcp: lookup gitlab-runner-dind on 172.31.0.2:53: no such host (executor_docker.go:980:0s)
Will be retried in 3s ...
ERROR: Job failed (system failure): error during connect: Get http://gitlab-runner-dind:2375/v1.25/info: dial tcp: lookup gitlab-runner-dind on 172.31.0.2:53: no such host (executor_docker.go:980:0s)

使用挂载的docker.sock它可以工作。但它是不安全的，并且卷在共享文件、工件和缓存方面存在许多问题。

root@GitlabRunner:/etc/gitlab-runner# gitlab-runner --version
Version:      12.4.1
Git revision: 05161b14
Git branch:   12-4-stable
GO version:   go1.10.8
Built:        2019-10-28T12:49:57+0000
OS/Arch:      linux/amd64

Answer 1

当您使用时，也许会更好kaniko。当你用 构建时，这不好dind。（危险提示@gitlab参考）

kaniko提供了使用存储库中的缓存机制的机会。kaniko@github

您唯一需要的是某个地方的存储库（我推荐Artifactory）。使用 Artifactory，您还可以通过dind（参见此处）进行缓存。