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