自信地将Docker带入生产环境
通过
7分钟阅读
如今，许多开发软件的组织都以这样或那样的方式使用Docker。如果你去参加任何软件开发或DevOps会议，问一大群人“谁在使用Docker?”，房间里的大多数人都会举手。但如果你现在问观众，“谁在用Docker在生产吗?，大多数人的手会立刻掉下来。为什么这样一种迅速发展的流行技术在开发管道的早期阶段被如此广泛地使用，而在生产中却很少使用?
软件质量:开发人员测试，运维批准
一个典型的软件交付管道看起来是这样的(已经做了十多年了!)
来源:h
在管道中的每个阶段，代表性的构建都要进行测试，并且只有通过相关质量检验关的所有标准，这个构建的二进制结果才能进入下一个阶段。通过提升原始二进制文件，我们可以保证在CI服务器中构建的二进制文件是部署或分发的二进制文件。通过实施严格的质量检验关，我们保证了对未测试、测试和生产就绪工件的访问控制。
的难以承受的轻
$ docker build
由于运行Docker构建是如此容易，而不是构建通过质量门进入下一阶段…
它在每个阶段都被重建。
“那又怎样，”你说?所以很多。让我们来看一个典型的构建脚本。
要构建产品，您需要一组依赖项，构建过程通常会下载所需的每个依赖项的最新版本。但是由于开发管道的每个阶段都是在不同的时间建立的，所以……
你不能确定开发版本中的每个依赖项的相同版本也会出现在生产版本中。
但我们可以解决这个问题。让我们使用:
从ubuntu: 14.04。
完成了。
或者是我们?
我们能确定在开发中下载的Ubuntu 14.04版本与在生产中构建的版本完全相同吗?不，我们不能。不影响版本号的安全补丁或其他更改怎么办?但等;有个办法。我们用图像上的指纹。这是坚如磐石!我们将基础图像指定为:
从ubuntu: 0 bf3461984f2fb18d237995e81faa657aff260a52a795367e6725f0617f7a56c
但是，那个版本是什么来着?它比我上周用的那台旧还是新?
你懂的。使用指纹既不可读也不可维护，最后，没有人真正知道Docker映像中包含了什么。
那么dockerfile的其余部分呢?它的大部分只是一堆隐式或显式的依赖解析，或者以apt-get,或wget命令从任意位置下载文件。对于某些命令，您可以确定版本，但对于其他命令，您甚至不确定它们是否进行依赖项解析!那么传递依赖关系呢?
所以你会得到这样的结果:
基本上，通过在管道中的每个阶段重建Docker映像，您实际上是在更改它，因此您不能确保通过所有质量闸门的映像就是进入生产的映像。
停止重建，开始促进
我们应该做的是构建我们的开发，而不是在每个阶段重新构建映像，我们应该促进它，作为一个不可变的和稳定的二进制文件，通过质量闸门进入生产。
听起来不错。让我们用Docker来做。
等等，别这么快。
Docker标签是个累赘
Docker标签是这样的:
Docker标签限制我们每台主机只能有一个注册表。
如果您只能使用一个注册表，您如何构建推广管道?
“我会提倡使用标签，”你说。“那样我只需要一个Docker注册表每个主机。”当然，这在某种程度上是可行的。Docker标签(纯密钥:值属性)可能是通过次要质量关口提升映像的公平解决方案，但它们是否足够强大，足以保护您的生产部署?考虑到您无法管理标签上的权限，可能不会。房子的名字是什么?QA更新了吗?开发人员还能访问(并更改)候选版本吗?问题还在继续。相反，让我们看看推广，以获得更健壮的解决方案。毕竟，我们已经和Artifactory合作很多年了。
虚拟存储库久经考验
虚拟存储库从1.0版开始就在Artifactory中。最近，我们还添加了…的功能将工件部署到虚拟存储库。这意味着虚拟存储库可以作为上传和下载Docker映像的单一入口点。是这样的:
下面是我们要做的:
- 将我们的构建部署到一个虚拟存储库中，该存储库作为我们的开发Docker注册表
- 通过管道促进Artifactory内部的构建
- 解析来自与Docker注册表相同(甚至不同)的虚拟存储库的生产就绪映像
它是这样工作的:
我们的开发人员(或者我们的Jenkins)使用一个虚拟存储库，该存储库包装了一个本地开发存储库、一个本地生产存储库和一个代理的远程存储库码头工人中心(作为管道的第一步，我们的开发人员可能需要访问码头工人中心以创建我们的图像)。构建映像之后，通过docker-virtual库docker-dev-local。
现在，詹金斯再次介入，并通过生产管道推广我们的形象。
在此过程中的任何一步，您都可以将Docker客户端指向任何中间存储库，并在将其推广到生产环境之前提取用于测试或登台的映像。
一旦你的Docker镜像进入生产环境，你就可以通过另一个虚拟存储库将它公开给你的客户，作为你的生产Docker注册表。您不希望客户访问您的开发注册中心或管道中的任何其他注册中心。只有生产Docker注册表。不需要任何其他存储库，因为与其他包格式不同，docker映像的关键在于它拥有所需的一切。
我们做到了。我们构建了一个Docker映像，并将其推广到测试和登台的所有阶段，一旦它通过了所有这些质量检验关，Docker的完全相同的图像我们在开发过程中创建的映像现在可供最终用户下载或部署到生产服务器，而不会有接收到未经处理的映像的风险。
那设置呢?
您可能会问，让Docker与Artifactory中的所有这些存储库一起工作是否容易设置?好吧，现在我们的新反向代理配置生成器。坚持使用Artifactory和NGINX或Apache，你可以很容易地访问所有的Docker注册表，开始将Docker镜像推广到生产环境。
