“DevOps方式”管理软件更新

在我最近参加的一次DevOps活动中，我与美国最大银行之一的DevOps团队的一些成员进行了交谈。讨论围绕补丁和软件更新在Dockerized环境中使用许多文件和微服务。没过多久，我就确定了他们的痛苦。

“如何在容器化的微服务世界中管理软件更新?”

这个问题代表了一个有效的问题，即更新和维护软件二进制文件的复杂性。随着整体应用程序被分解成多个容器化的微服务，随着敏捷开发实践导致更短的发布周期，软件二进制文件的多个版本被发布，这个问题正呈指数级增长。与此同时，存在一个相互依赖的网络，在这个网络中，更新第三方二进制文件会导致多个dockerized应用程序的更新。

这就是我写这篇博客的动机，在这篇博客中，我将讨论一种可用于管理软件二进制文件更新成本的解决方案，无论是升级、补丁，还是弃用。

一个人的成本更新

计算升级或修补单个文件的成本变得极其困难。让我们以这样一个场景为例，在生产环境中运行了几个容器化甚至非容器化应用程序，由于某种原因，您需要升级一个rpm包并修补一个jar文件。有一个问题要问:

有多少应用程序受到此更改的影响?

这种变化可能是由于一个主要的错误修复，一个新功能，一个安全更新，法律合规的需要，等等。因此，许多团队都会问这个问题:运维团队需要知道要修补或升级哪些应用程序，QA团队需要确定测试范围，安全团队需要计算安全风险，法律团队希望计算法律问题的影响(如果有的话)，而开发涉众正在考虑整体范围，甚至取决于更改的关键程度。

为了满足所有这些团队的需求，您需要能够深入理解组织中使用的所有二进制文件的软件，无论它们是专有的内部组件还是第三方库。但更重要的是，您需要能够找到二进制文件之间关系的软件，以创建一个全面的图表，显示它们是如何连接的。

影响分析

一旦创建了这个图表，然后给出一个问题或更改，就很容易知道哪些组件受到了影响，而这正是影响所在JFrog x光所做的事。通过对复杂二进制文件中的所有文件进行深度索引并将它们关联起来，它创建了一个类似于下图的图形。

在这个例子中，组件1的变化会影响它的所有祖先节点，包括App 1、App 2和App 3。这有助于计算补丁或升级组件1的成本。在JFrog x射线中一个更现实的视图是这样的:

在这个例子中，JFrog Xray列出了变化的影响scripts.tar．在这种情况下，其中一个Docker映像层(通过sha256识别)与多个引用该层的Docker清单一起受到影响。因此，在二进制文件中给出任何变化，识别受影响的docker映像或任何其他复杂归档相对容易。

软件更新已经不像以前那样了。容器和微服务改变了一切，创造了复杂连接和相互依赖的二进制文件的爆炸，从而使更新过程复杂化。然而，使用JFrog x射线手动识别所有受更新影响的二进制文件几乎是不可能的影响分析查找这些连接并确定软件更新的真实成本是一个简单且自动化的过程。

准备好对微服务进行影响分析了吗?开始免费试用JFrog x射线．