好的。我想我们可以开始了。大家好。希望你们到目前为止都有一个愉快的沼泽。我是汉克·哈金斯。我在第一资本公司工作。我是一名高级软件工程师，在artifactory平台团队工作。今天，我们将学习自动化的工厂HA管道。我们将把它分解成我们管道中不同的阶段，并将其与我们如何实现这些阶段联系起来。顺便告诉你，所有的桌子上都有反馈卡，如果你们有机会能把这些卡片填好，那就太好了。
基本上就是我们要讲的内容的概述。我将简要介绍artifactory实现的背景，并介绍拥有可靠的自动化发布管道的一些好处。然后我们将概述我们的管道然后进入每个不同的阶段描述这个阶段的目的是什么以及我们如何在Capital One中实现它。最后，我们还要讲回滚策略因为这很重要。如果最后还有时间，我们会进入提问环节。之后我们也可以进行分组讨论。
从我们的背景开始，artifactory，显然，是我们的二进制存储，代理和远程存储库的企业解决方案。我是这个艺术团队的一员，我已经在第一资本公司工作了两年多。我们所做的基本上是为平台开发基础设施和自动化，以确保我们的用户在可用时获得新功能。我们有一个系统，用户可以投票选择他们最想要的功能和存储库，这就是我们决定如何发布这些新存储库或功能的方式。
因此，我们在自动化管道中发布的一些类型的东西是手工升级和我们需要进行的任何基础设施更新。我们目前在AWS之外运营，所以如果我们在自动伸缩组中有什么需要调整的地方，例如，如果我们想改变缩放，我们也必须通过我们的管道发布它。然后我们也发布了服务器配置更新。这个我稍后再讲。我们使用厨师食谱来配置服务器，显然这些也会通过我们的管道进行推送。最后是服务器安全补丁。我们试图保持对EC2实例的安全性的任何补丁的掌握。我们会定期循环出我们的实例这也会通过我们的管道。
在我们特定的手工实现中，我们有两个HA集群。我们有一个主要的artifactory HA集群，它在大多数时候使用的都是命中。然后我们在另一个[听不清00:03:11]区域有一个次要的artifactory HA集群，我们用它来做DR，我们的灾难恢复区域。所以我们尽量保持这两个手工集群同步。如果我们的主区域出了问题，我们可以直接将流量转移到DR区域。
因此，可靠的自动化发布管道的一些好处……我在这里列出了它们。可能还有更多，但这些是我能想到的。所以第一点，加快交付过程，有一个坚实的管道让你的开发人员更专注于开发。他们不必专注于发布到不同的环境，确保他们自己做所有的测试。你可以让所有这些都自动化，这是一个很好的方法，让开发人员可以更多地专注于开发，让发布过程更快地进行。
其次，它更容易扩展。假设您有一个管道，您正在将一个artifactory集群释放到一个区域。你想要扩展到第二个区域。如果你拥有可靠的自动发行管道，你便能够更轻松地做到这一点。您可能只需要添加更多的配置来释放到那个新区域。您已经准备好了测试。你已经有了所有其他的阶段，所以它可以顺利地进行，你真的不需要专注于把所有这些重新建立起来。
第三，它有可重复的，彻底的测试。所有这些测试的主要目标是确保无缝的用户体验，并且没有负面的用户影响。显然，如果你可以在用户甚至没有意识到发生了什么事情的情况下发布版本，这是最好的情况。这就是我们努力的方向，这是一个很好的目标。
最后一个，启用有效的回滚策略。它有两种方式。首先，它使您能够更快地检测故障。您的管道中有自动化的测试，因此您可以更快地检测配置错误的情况，例如，如果您仅仅启动一个集群，那么您就会意识到仅仅通过进行一些手动测试就无法实现某些功能。这样就快多了。它还有助于编排部署，以便在不影响用户的情况下进行回滚。我会在这里稍微讲一下我们是怎么做的。
这是我们如何建立管道的概述。我们有一个Jenkins管道，它与我们的Github仓库集成在一起。每当我们向主存储库发出投票请求时，就会触发一些小型测试。首先，一些快速反馈。它实际上运行一些快速的静态分析，旋转一个artifactory实例，并确保那个artifactory正在出现。因此，它不完全是HA级别，但它有助于对投票请求获得快速反馈。
一旦我们确定它看起来不错，我们就可以把它合并到我们的主存储库中，这就触发了开发环境的构建。它实际上有多地区的HA集群。我们的规模比生产规模小一些，但这是一个很好的方法来测试我们的基础设施是否在两个地区正确建设。所以我们也会针对这一点进行一些自动化测试。然后，一旦我们确定我们有足够的代码更改和我们想要发布到产品中去的东西，我们实际上用QA标签标记那些代码，然后我们构建那个标签来部署一个生产规模的QA环境。所以实例数和产量是完全相同的。实际上，我们正在复制我们的生产数据，以便与我们的生产数据几乎完全匹配。这对于确保我们的发布不会引起任何问题非常有帮助。
所以,是的。一旦我们确定QA看起来不错，我们就把同样的QA标签提升到生产标签，然后发布到生产。所以我们使用terrform来创建我们的基础设施。我把蓝绿色的部署放在这里，但不是蓝绿色。你会明白我在说什么。当您有一个连接到这些手工HA集群的集中式数据库时，这有点复杂。所以我们有一个伪蓝绿色的部署策略。然后我们使用厨师食谱来进行服务器配置。这只是安装、配置和启动我们的服务。我们有不同的服务:artifactory Nginx用于反向代理，datdog用于监控，Splunk用于收集日志。
好的。现在我们将进入我们管道中的每个不同阶段，稍微回顾一下每个阶段的细节以及我们是如何实现这些的。所以静态分析，这个运行在投票请求和我们的开发合并。是的，在那里我们合并到建立开发环境的主要分支。因此，这些可以确保我们的代码结构符合行业标准。它给了我们非常快速的反馈，确保我们没有在仓库中引入无法管理的代码结构。所以我们用一系列细料来处理。我们所做的是，实际上，我们已经把所有这些细粒装在一个医生容器里，在詹金斯管道中运行。这样就能确保我们不会对詹金斯产生任何影响我们就能在文件中使用这些不同的追踪器。
我们有烹饪风格，美食评论家，rubocop。我们把这些都用在我们的厨师食谱上。我们有Jenkins文件linter, Pylint因为我们实际上有一些自定义的Python脚本，还有ShellCheck，然后我们有terrform验证我们的terrform, markdown lints因为它真的很重要，让你的文档保持良好的，有组织的格式。
下一阶段，我们进行安全扫描。你们可能已经听说过几次了，把安检扫描左移是有好处的。确保在进入生产环境之前捕捉到这些漏洞。所以我们在管道中做一些安全扫描。我们这样做主要是为了扫描自定义脚本中的依赖项和二进制文件。我不认为我们扫描了我们的人造二进制，但我认为他们给了我们好东西。所以不用担心这个。所以我们实际上有两种安全扫描。静态安全测试，它只是分析代码的潜在可利用的代码结构。例如，如果您有一些SQL注入的潜力或跨站点脚本，诸如此类的东西。 And then the other type is composition analysis, and this is more what X-ray would give you. And that analyzes dependencies for known vulnerabilities and give recommendations on versions to use that have fixes for those vulnerabilities.
所以我们有一些定制代码，我们发送去进行安全扫描，我们有一个AWS lambda函数代码，它基本上把我们的Cloudwatch警报转发到我们的Slack，因为那通常是我们日常活动的地方。所以很容易看到这些。然后，我们还有一些自定义Python脚本来帮助在两个artifactory集群之间进行复制。,是的。我们遇到了一些问题，我们有一些大的存储库，不能很好地获得Chron复制，本地应用程序的工作，所以我们必须帮助一些我们自己的自定义脚本。
接下来是单元和集成测试。同样，这可能只适用于您可能拥有的任何自定义代码，所以您只需要测试并确保它不会破坏任何预期的行为。这也可以应用于自定义用户插件。我不知道你们中有多少人在artifactory中使用自定义用户插件，但他们实际上使用artifactory的公共API库。所以测试这些有点棘手，但我们所做的是我们基本上将一个artifactory的绝缘容器化，并将我们的用户插件注入到那个容器artifactory中，然后我们对它运行测试。所以它是在测试用户插件的功能，而不是将其作为管道的一部分集成到我们的环境中。
然后我们将在这里进入更多的部署过程。所以在我们部署任何东西之前就构建staging，我们必须将我们的文件放置到一个在运行时自动伸缩事件不会依赖于其他系统的地方。这也包括artifactory。所以很明显，如果你正在发布artifactory，你不能依赖artifactory进行运行时缩放，因为如果artifactory下降，你就会陷入困境。你不能再扩展了。我们所做的是将构建文件存储在S3桶中。从那时起，在运行时，我们就从那里开始源代码。因此，作为管道中构建阶段的一部分，我们从artifactory提取rpm，然后将它们上传到S3。所以我们使用的RPM是artifactory RPM和Nginx RPM。
然后是我们的厨师食谱，我们也推出了artifactory。我们构建并将其推到artifactory NS3，作为我们开发构建的一部分。然后我们的QA和生产构建将从artifactory提取相同的烹饪书，并将其放入S3中，以确保我们使用相同的烹饪书。我们不需要在我们的环境中重建它。
然后我们开始部署。这涉及到我们的部署策略。因此，基本上，我们的目标是在不影响工件可用性的情况下部署新堆栈，并确保用户甚至不会检测到正在发生的事情。这就是邮件的目标。因此，我们首先要做的是，让从主区域到DR区域的所有用户流量都失败，然后我们可以专注于部署到主区域。作为其中的一部分，我们将现有的堆栈缩小到只有几个成员节点。再也没有用户访问这个堆栈了。缩小规模是可以的。我们实际上也删除了主节点因为新加入的堆栈将加入现有的堆栈或集群，artifactory集群，因为它们将访问相同的数据库和相同的S3后备存储。因此，它们只是有效地将实例循环到相同的artifactory集群中。
这就是我们缩小成员节点数量的原因。它为即将出现的新实例释放许可证，新的主节点将成为该集群的主节点。因此，一旦我们启动堆栈，我们就对它运行一些测试。如果测试是成功的，那么我们就会让新栈的端点失败，或者将它们切换到新栈。我们也会把交通转回主要区域。
然后，一旦我们把流量转回主区域，我们就会等待一会儿，看看用户访问集群是否会导致任何额外的问题。当我们准备好了，我们也可以部署到我们的灾备地区。这就是蓝绿色的策略。我知道不是蓝绿色，但有点伪麻黄碱。因为我们保持了这些集群的同步，所以从用户的角度来看，部署过程是相对无缝的。我说相对，是因为我们在不同的区域有这些集群，很明显，两者之间会有延迟的差异。这实际上对用户没有任何影响。
现在我要讲一些我们在部署后做的不同的测试。我们必须通过这些测试，才能确定是否可以让交通恢复正常。我们首先要做的是配置测试。这只是为了确保在服务器不提供流量时，服务器上的一切都设置正确。所以我们实际上从Jenkins SSH隧道到每个新服务器，我们远程运行NSpec测试，以确保一切都正确设置。
NSpec与厨师食谱紧密相连。我想它甚至是试验厨房的一部分。因此，我们决定将NSpec与我们的厨师烹饪书一起使用，以确保一切设置正确，从而确保我们的服务是启用和运行的。这就是artifactory Nginx, datdog和Splunk。然后我们还要确保配置文件都是正确的，在正确的位置，并具有正确的权限。然后我们还要确保网络端口按预期打开。其中三个有我们感兴趣的端口。Artifactory有用于Artifactory和访问服务的tomcat端口。然后我们有Nginx端口。然后datdog监视artifactory上的JMX。 So that also is using a port. So just make sure all those are correctly opened and listening.
然后所有这些测试中的任何失败，部署后测试，这些中的任何失败都会导致回滚。我们在部署后做的第二种测试是验证测试。这是一套测试，我们必须确保组件或存储库都按预期工作。因此，我们实际上已经将包管理器进行了容器化，这些包管理器可以跨我们配置的所有存储库拉测试包。这很好，因为如果任何新的系统配置破坏了这些存储库的解析，它会捕捉到问题。例如，如果我们改变了Nginx的一些规则，这可能会影响医生的存储库，因为我们的Nginx被设置为将医生流量转发到特定的存储库。因此，我们测试以确保所有这些存储库都能正常工作是非常重要的。
然后它还测试部署工件，而不仅仅是提取工件。我们还测试将工件部署到每个不同的虚拟存储库。最后，但肯定不是最不重要的，性能测试。所以JFrog在他们的端处理了很多性能测试，但是每个人的用例都是不同的，我们实际上在之前的一些实现中用过这个。因此在用例中执行这个测试是非常重要的。这只是为了确保在发布到生产环境之前不会有任何性能下降。因为最糟糕的事情是，当你把它投入生产时，用户开始使用它，突然之间，手工工厂运行得超级慢，所有人都吓坏了。所以提前进行测试是很好的。
我们用JMeter来模拟生产级别的流量，我们分析总体TPS，也就是每秒的事务数。事实上，我会稍微讲一下这个问题。所以[听不清00:20:06]一个15分钟的负载测试作为我们管道的一部分运行。这与QA背道而驰。因此，在QA部署之后，我们运行这个15分钟的负载测试，将其作为自动化管道的一部分。对于任何重大升级或重大更改，我们还可以选择进行一小时的负载测试，以确保一切正常。那个不是自动运行的。我们手动运行它。但有这样的选择是好事。
然后我们也，就像我之前说的，我们同步我们的数据从生产到QA，以确保我们有尽可能接近的匹配我们的生产，因为这真的是你会看到事情出错的地方。如果你的QA数据比生产数据少，你可能就抓不到会导致用户问题的东西。所以,是的。如果可以的话，这样做是个好主意。
此外，建模流量有点困难，因为artifactory使用自己的包管理器提供了广泛的支持包类型。对于JMeter的特定实现，我们只能进行API调用。所以我们基本上浏览了我们的生产日志，得到了一个最频繁调用的API调用的列表。我们尝试匹配峰值流量时的API调用速率。它仍然不是完美的，但对于检测性能趋势非常有用。我们实际上正在积极地研究这个，我认为，现在实际上是在改进我们如何进行这些调用，并希望达到一个点，我们实际上可以使用包管理器本身来模拟这个生产流量，因为试图用一系列API调用来模拟医生投票是不理想的。
然后是回滚策略。实际上，我们有两个级别的回滚。我们有一个区域内回滚。因此，如果测试失败，这个自动化测试，我们实际上会删除新的堆栈，并将旧的堆栈恢复到以前的状态，在用户流量到达任何新实例之前。这就是我们的自动回滚。我们还有一个DR故障转移回滚。所以这更像是我们部署的一种策略。因此，当用户访问DR区域时，我们首先部署到主区域。这真的对我们很有帮助，一旦我们把用户流量转回主区域，我们就可以监视用户，在用户访问主区域时监视系统，确保我们没有错过任何可能有点不稳定的东西。因此，如果我们检测到某些东西没有按照我们希望的方式执行，我们可以快速地将该流量故障转移回我们的DR区域。 It’s got the same state as before. We haven’t updated it. So that’s kind of a quick rollback strategy in the case of something that we might’ve missed.
然后，在故障转移到DR区域之后，如果需要的话，可以通过将数据库回滚到上一个快照来恢复主区域。然后让这些区域在复制过程中恢复同步。这里需要注意的是，在重大升级的情况下，如果不回滚数据库，自动回滚是不可能的，因为通常情况下，那些重大升级涉及到某种数据库模式更改。因此，您不能根据迁移的数据库模式来调整旧的artifactory版本。因此，最好有某种回滚数据库的过程，然后将数据恢复到同步状态。实际上，我们目前还没有实现自动化，但希望最终会实现。幸运的是，我们不用做太多。这是一件好事。
总之，自动化发布管道有很多好处。加速交付过程，它们更容易扩展，具有可重复的、彻底的测试，并且支持回滚策略。即使是像artifactory这样的产品，彻底测试你的基础设施和配置以hth华体会最新官方网站建立对你的发布的信心也是很重要的。要经常寻找机会来改善你的渠道。现在的投资让你今后的生活更轻松。这就是我的建议。酷。谢谢。
我们可能还有点时间，如果有人有问题要问我的话。是的。
(听不清00:25:18)
我们用什么进行安全扫描?
是的。(听不清00:25:27)
正确的。因此，我们实际上有一个内部的安全扫描基础设施，它实际上集成了多个产品。hth华体会最新官方网站目前还不包括x射线，不过我们将来可能会评估x射线。所以这个，肯定会处理二进制。我不是百分百确定静态扫描是怎么回事。我过会儿再来找你。我可以调查一下。
我很抱歉。你能去讨论室继续吗?
哦,是的。是的。当然。所以,是的。我们可以休息一下去讨论室。如果任何人还有其他问题，请告诉我，我们会在这里找到答案。谢谢你！
