时间戳

首页 > 解决方案 > 设置 ci/cd 系统时何时使用 docker:dind

docker - 设置 ci/cd 系统时何时使用 docker:dind

问题描述

我只是 gitlab 的新手，docker 的新手。我非常熟悉 CI/CD 最佳实践。我正在尝试了解/确定使用 docker:dind 将使我和我的团队受益的特定用例。

我一直在阅读这篇文章：https ://www.caktusgroup.com/blog/2020/02/25/docker-image/

在我们的环境中，我们设置了 HP 刀片（开发、登台、生产），每个都运行 docker 守护进程。

我能想到的一个用例是，如果开发人员想在他/她的桌面上本地尝试一些东西……那运行的 Docker 版本与我们的服务器上不同。他们也许可以在本地使用 docker:dind 映像，但指定与我们的服务器匹配的版本？没有把握。

有人可以帮我想出一些实际例子来说明何时/为什么有用吗？谢谢。

标签： dockercontinuous-integrationgitlab-ci

解决方案

对于基本上所有日常使用，包括您需要自己配置的 CI 系统，将主机的 Docker 套接字绑定安装到环境中并使用它。在大多数情况下，您根本不应该使用 Docker-in-Docker。

对此的规范参考（仍然是 5 年后）是 Jérôme Petazzoni 的Using Docker-in-Docker for your CI or testing environment？三思而后行。 我建议使用 Docker-in-Docker 是合适的：

  1. 如果您正在积极地在 Docker 本身上进行开发（您已经查看了https://github.com/moby/moby并正在编辑源代码）并且您需要一个沙箱来运行您修改后的守护程序；或者
  2. 如果您对 Docker 概念有非常深刻的理解，并且您和您一起工作的任何人都不会被“错误”的 Docker 守护进程中的映像或来自错误“主机系统”的绑定挂载所迷惑；或者
  3. 如果您有一个 CI 系统或其他工具非常特别地支持它作为零配置选项。

有几个“罐头”解决方案打破了大多数正常规则，但仍然运作良好。这里我能想到的最突出的例子是kind（“Kubernetes in Docker”），它打破了“不要运行 Docker-in-Docker”和“每个容器一个进程”的规则，运行整个 Kubernetes 集群在单个 Docker 容器中。它真的很有用，但它也向你隐藏了几乎所有关于“我的容器在哪里”的细节。这是我正在考虑的那种“零配置选项”。

我不会担心某个开发人员的 Docker 版本与您的 CI 或生产系统略有不同。我只遇到了一个与 Docker 不兼容的版本。就目前而言，“经典”与 BuildKit 构建系统可能会做一些不同的事情，但我不会引入非常复杂的替代设置来防止这种情况。

推荐阅读