这是一个美妙的DevOps生活

在弗兰克·卡普拉(Frank Capra) 1947年的电影《生活多美好》(It 's a Wonderful Life)中，乔治·贝利(George Bailey)在绝望的深处希望自己从未出生。于是一位天使向他展示了那个世界会是什么样子。

我有时也觉得需要一个天使。

当然，不是出于同样的原因。我们的企业客户喜欢Artifactory，因为它可以帮助他们的客户DevOps容器管道从代码到集群平滑运行．然而我常常在容器中找到一种误解，因为Kubernetes编排Docker映像，Artifactory的主要价值被视为它的服务能力作为Docker注册表。这是非常重要的，但它提供了更多。

Artifactory为开发人员提供了选择语言和框架的自由，以及构建的信心。它为如何将各种包管理器和框架集成到企业DevOps流程中提供了可靠的策略。

在选择DevOps设置时，您可能会有一些基本问题:

• 开发人员能否创建确定性的、可靠的构建?
• 有多少我必须要刮胡子(不会增加价值的一次性任务)?
• 从依赖中潜入构建的是什么(膨胀和/或风险)?

幸运的是，Artifactory解决了所有这些问题:

• 缓存和归档来自公共存储库的所有依赖到本地存储库，以实现快速、可复制的构建。这些包括操作系统、语言、框架、容器和配置构件。
• 与大多数包管理器集成，便于安装和维护。与大多数流行的CI服务器集成，以最小的监督实现自动化。
• 提供对Docker映像的可见性，以便您随时确切地知道其中的内容。

游览Pottersville

Artifactory让这些事情变得如此自然，以至于人们很容易把它们视为理所当然。也许理解这些好处的最好方法是考虑如果没有Artifactory，您将如何完成相同的事情。

如果Artifactory没有诞生，你的容器DevOps管道会是什么样子?

选项1:始终从远程存储库构建

如果没有Artifactory对远程依赖项的本地缓存，您可以选择在每次构建应用程序时直接从远程资源构建它们。

在这种情况下，您总是将依赖项的最新版本合并到构建中。但是，您永远无法完全控制构建中的内容，无法确定您包含的版本是安全的或与应用程序的其余部分兼容。由于远程源代码中的代码可以并且将随时频繁更改，因此您不太可能从相同的构建过程中重新生成相同的映像。

出于同样的原因，您将不知道在构建中可能会引入哪些其他代码——它们是需要的还是安全的。如果您直接从远程资源构建所有内容，那么您的构建更有可能中断。

在构建时依赖远程公共存储库也有可能在网络上的流量负载很大时减慢CI进程的速度。更糟糕的是，当您需要生成关键补丁时，远程公共存储库的故障可能会对业务造成灾难性的影响。

选项2:从现有的Docker映像构建

如果没有Artifactory的存储库管理功能，您可能会选择已经在其中的Docker映像码头工人中心这与您需要的语言框架版本和操作系统发行版相匹配，并将其包含在最终的映像构建中。

这个场景将帮助您创建可复制的构建，但仅限于您的docker映像版本。您需要在工具的帮助很少的情况下，对进入生产环境的内容负责。

如果没有Artifactory，您很可能很少或根本看不到所选择的docker映像实际包含的内容。弄清楚这一点可能是一个繁琐的过程。

该映像可能包含恶意组件或未使用的组件。Docker构建阶段本身就有可能出现中断、延迟和意外膨胀，从而减慢发布过程。您生成的最终图像可能不符合您的操作策略。

选项3:在本地构造一个基本映像

没有Artifactory的存储库管理特性开发人员可以在本地工作站上构建一个基本映像，并将其推送到Docker注册表中。然后，CI进程可以将该基本映像与它们的应用程序组合起来，以构建最终的容器映像。

这种创建可维护的“黄金基础映像”的方法是创建可部署的应用程序容器的常用实践，这种容器在短期内可以很容易地复制。在这个场景中，开发人员的工作站(构建黄金基础映像的地方)有效地充当远程依赖项的本地缓存。

此过程需要仔细构建，并且能够独立于CI过程执行基本映像构建。如果您不需要经常更改基本映像，并且您对固定到给定的堆栈版本感到满意，那么它的效果最好。它还希望开发人员把时间花在构建映像上，而不是编码上。

在实践中，这个看似简单的解决方案可能会产生一系列问题，破坏您的构建自动化，并迫使您介入解决这些问题。就其本质而言，这些释放块很可能需要您在最不合适的时候进行干预——比如添加一个关键修复。

例如，您可能需要一个新的基本映像来前滚一些操作系统包并获取一个新的框架补丁。当您用新组件创建一个新的基本映像并将其上传到Docker时，所有的自动CI运行都必须停止。由于Docker和源代码中的更改注册在不同的更改日志中，因此必须针对新的Docker基本映像测试新更改。如果您必须重新构建，即使使用相同的源代码，您也会得到不同的结果，从而放弃确定性构建。

选项4:托管单个本地工件存储库

没有Artifactory的远程依赖项的本地缓存(比如npm、maven或PHP编写器包)，您可以选择在单独的服务器上创建和管理自己的文件。

如果您选择这样做，您将获得Artifactory提供的一个关键好处，即始终使用已知版本的依赖项进行构建。您将能够连续执行两个构建并生成相同的Docker映像。

然而，这个解决方案只有在你聪明和细心的情况下才能灵活。您将完全负责该基础设施，何时以及如何更新本地缓存，以及是否能够在需要时回滚这些更新，并保持归档修剪。

您的实现也不太可能是企业级的，能够在高可用性下可靠地使用来自多个供应商的工具。您采用的每一项新技术都需要额外的工作、资源和管理，甚至需要一个全新的系统来适应它。2022世界杯阿根廷预选赛赛程你收养了一群毛茸茸的，需要帮助的牦牛。

您也不太可能拥有构建的跨系统可追溯性，从而使您了解Docker映像是如何构建的。如果不想要的东西潜入你的构建，尽管你尽了最大的努力，你永远不会知道。你腹胀的风险虽然降低了，但仍然存在。

回到贝德福德瀑布

“很奇怪，不是吗?”天使克拉伦斯在电影中对乔治说。“每个人的生命都影响着许多其他人的生命。当他不在身边时，他会留下一个可怕的洞，不是吗?”

这也是对DevOps过程中的Artifactory的恰当描述。上面的示例显示了Artifactory帮助解决的自动化CI过程中有多少相互依赖关系。

Artifactory帮助您将Docker映像视为短暂的包装，同时为应用程序的生产做好准备。一旦它们准备好部署，Artifactory可以帮助您的自动化CI流程将需要重新构建Docker映像的次数降至最低，以确保它们的稳定性。

你脑子里响起了似曾相识的铃声吗?那也许是天使长了翅膀。

要了解Artifactory如何让您的DevOps生活变得更加精彩，请阅读使用二进制存储库管理器的10个原因．