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

Question

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

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

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

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

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

Answer 1

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

对此的规范参考（仍然是 5 年后）是 Jérôme Petazzoni 的 Using Docker-in-Docker for your CI or testing environment? Think twice. 我建议使用 Docker-in-Docker 是合适的：

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

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

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