“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 manifest一起受到影响。因此，在二进制文件中有任何更改的情况下，识别受影响的docker映像或任何其他复杂归档相对容易。

软件更新已经不像以前那么好了。容器和微服务改变了一切，产生了大量复杂连接和相互依赖的二进制文件，从而使更新过程复杂化。手动识别受更新影响的所有二进制文件实际上是不可能的，但是，使用JFrog Xray的影响分析找到这些联系并确定软件更新的真实成本是一个简单而自动化的过程。

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