好吧。我想我们可以开始了。大家好。希望大家到目前为止都玩得愉快。我是汉克·哈金斯。我在第一资本公司工作。我是一名高级软件工程师，我在人工平台团队工作。今天，我们将讨论自动化人工HA管道。所以我们将把它分解成我们在流水线中拥有的不同阶段，并将其与我们如何实现这些阶段联系起来。你们知道，所有的桌子上都有反馈卡片，所以如果你们有机会填一下，那就太好了。
基本上，就是我们将要讨论的内容的概述。我将简要介绍一下我们实现artifactory的背景，并介绍一下拥有一个可靠的自动化发布管道的一些好处。然后我们将对我们的管道进行概述然后进入每个不同的阶段并描述该阶段的目的是什么以及我们如何在Capital One中实现它。最后，我们还会讲到回滚策略因为这很重要。如果最后还有时间，我们就开始提问。之后我们也可以进行分组讨论。
从我们的背景开始，很明显，是我们的二进制存储，代理和远程存储库的企业解决方案。我是这个人工团队的一员，我在Capital One已经工作两年多了。我们所做的基本上是为平台开发基础设施和自动化，以确保我们的用户能够获得可用的新功能。我们有一个系统，用户可以投票决定他们最想要的功能和存储库，这就是我们如何决定我们将如何发布这些新存储库或功能的方式。
因此，我们在自动化管道中发布的一些类型的东西是人工升级和我们需要进行的任何基础设施更新。我们目前在AWS上运行，所以如果我们想在我们的自动伸缩组中调整任何东西，例如，如果我们想改变规模，我们也必须通过我们的管道发布。然后我们也发布了服务器配置更新。我稍后会详细讲。我们实际上使用厨师食谱来配置我们的服务器，所以很明显，这些也将通过我们的管道进行推送。最后一件事是服务器安全补丁。我们试图保持在EC2实例安全补丁的顶端。所以我们定期循环我们的实例，这也通过我们的管道。
在我们的特定人工实现中，我们有两个HA集群。我们有一个主要的人工HA集群，大部分时间都在使用它。然后我们在另一个[听不清00:03:11]区域有一个二级人工高可用性集群我们用它来做DR，灾难恢复区域。所以我们尽量让这两个人工集群保持同步。如果我们的主区域出现问题，我们可以将流量切换到我们的DR区域。
因此，我在这里列出了可靠的自动化发布管道的一些好处。可能还有更多，但这些是我能想到的。第一点，加快交付过程，让你的开发人员能够更加专注于开发。他们不必专注于向不同的环境发布，确保他们自己完成所有的测试。你可以让所有这些都自动化，所以这是一种很好的方式，可以让开发人员更多地专注于开发，让发布过程更快地进行。
其次，它更容易扩展。假设你有一个管道，你要释放一个人工集群到一个区域。你想扩展到第二个区域。如果你有可靠的自动化发布管道，这就容易多了。你可能只需要增加一些构型来释放到新的区域。您已经进行了适当的测试。你已经有了所有其他的阶段，所以它会很顺利地进行，你不需要再把注意力集中在构建所有的阶段上。
第三，它有可重复的，彻底的测试。所有这些测试的主要目标是确保无缝的用户体验，并且不会对用户产生负面影响。显然，如果你可以在用户没有意识到发生了什么事情的情况下发布版本，那是最好的情况。所以这就是我们努力去做的，这是一个很好的目标。
最后一个选项支持有效的回滚策略。它有两种方法。首先，它使您能够更快地检测故障。您已经在您的管道中进行了自动化测试，因此您可以更快地检测到什么时候配置错误，而不是仅仅启动一个集群，例如，然后您意识到仅通过进行一些手动测试就可以实现某些功能无法正常工作。这样就快多了。然后，它还帮助编排部署，使您可以在不影响用户的情况下进行回滚。我会在这里讲一下我们是怎么做的。
这里的概述，这是我们如何建立管道的。我们有一个与Github存储库集成的Jenkins管道。每当我们向主存储库发出投票请求时，就会触发一些小规模的测试。首先是一些快速反馈。它运行一些快速的静态分析，启动一个人工实例并确保那个人工出现。所以这并不是HA的标准，但是对于获得关于投票请求的快速反馈是有好处的。
然后，一旦我们确定这看起来没问题，我们就可以将其合并到我们的主存储库中，并触发我们的开发环境的构建。它实际上有多区域高可用性集群。它们的规模比生产规模要小一些，但这是一个很好的方法，可以测试我们在两个地区的基础设施建设是否正确。所以我们也会对它进行一些自动化测试。然后，一旦我们确定有足够的代码更改和我们想要发布到生产环境的东西，我们实际上用QA标签标记代码，然后我们构建该标签来部署生产规模的QA环境。这是完全相同的实例数和产量。实际上，我们正在复制我们的生产数据，以获得与生产数据几乎完全匹配的数据。这对于确保我们的发布不会引起任何问题非常有帮助。
所以,是的。一旦我们确定QA看起来没问题，我们就会将相同的QA标签提升为生产标签，并将其发布到生产中。所以我们使用Terraform来创建我们的基础设施。我把蓝绿色部署在这里，但它不是蓝绿色的。你会明白我在说什么。当集中式数据库连接到这些人工HA集群时，情况就有点复杂了。所以我们有一个伪蓝绿色的部署策略。然后我们使用厨师食谱来配置服务器。这只是安装、配置和启动我们的服务。我们有不同的服务，人工Nginx用于反向代理，Datadog用于监控，Splunk用于收集日志。
好吧。我们现在将进入管道中的每个不同阶段，只是回顾一下每个阶段的细节以及我们如何实现这些。静态分析，这个在轮询请求和开发合并时运行。是的，我们的主要分支机构的合并建立了开发环境。这些确保了我们的代码结构符合行业标准。它给了我们非常快速的反馈，确保我们没有将难以管理的代码结构引入到我们的存储库中。所以我们用一系列的线索来处理这个问题。我们所做的是，实际上，我们把所有这些linter容器放入一个在Jenkins管道中运行的医生容器中。这确保了我们不会以任何方式影响Jenkins我们可以对文件运行任何这些不同的linter。
我们有烹饪风格，美食评论家，怪人。我们在烹饪书中都用到这些。我们有Jenkins文件检查器，Pylint，因为我们实际上有一些自定义Python脚本，和ShellCheck，然后我们有Terraform验证我们的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桶中。从那时起，在运行时，我们把所有的东西都放在那里。因此，作为管道构建阶段的一部分，我们确实从工厂中提取rpm，然后将它们上传到S3。所以我们使用的RPM是人工RPM和Nginx RPM。
然后我们的厨师食谱，我们也推到了手工。我们构建并将其推向人工NS3，作为我们开发构建的一部分。然后我们的QA和生产构建将从artifactory中提取相同的食谱并将其放入S3中，以确保我们使用的是相同的食谱。我们不需要在我们的环境中重建它。
然后我们进入部署。这涉及到我们的部署策略。因此，基本上，我们的目标是在不影响工件可用性的情况下部署新堆栈，并确保用户甚至不会检测到正在发生的事情。这就是邮件的目标。因此，我们首先要做的是，让所有从主区域到DR区域的用户流量失效，然后我们可以集中精力部署到主区域。因此，作为其中的一部分，我们将现有的堆栈缩小到只有几个成员节点。没有用户再访问这个堆栈了。缩小规模也没关系。我们实际上也删除了主节点，因为新的堆栈将加入到现有的堆栈或集群，人工集群，因为它们将访问相同的数据库和相同的S3后端存储。因此，它们实际上只是将实例循环到同一个人工集群中。
这就是我们减少成员节点数量的原因。它为即将出现的新实例释放许可证，并且新的主节点将成为该集群的主节点。所以一旦我们启动堆栈，我们就对它进行一些测试。如果测试成功了，那么我们就会把端点失败到新的堆栈，或者把它们切换到新的堆栈。我们也会把交通转回主要地区。
然后，一旦我们将流量转回主区域，我们等待一段时间，看看用户访问集群是否会导致任何额外的问题。当我们准备好了，我们也可以部署到我们的DR区域。这就是蓝绿色策略。我知道它不是蓝绿色的，但有点假。然后，因为我们保持这些集群同步，从用户的角度来看，部署过程是相对无缝的。我说相对，是因为我们在不同的区域有这些集群，所以很明显，两者之间的延迟是不同的。它实际上对用户没有影响。
现在我要讲一些不同的测试我们在部署之后做的测试。我们必须先通过这些测试，然后才能决定是否可以让车辆倒车。我们做的第一个是配置测试。这只是为了确保在服务器不提供流量时，服务器上的一切都正确设置。因此，我们实际上通过SSH隧道从Jenkins连接到每个新服务器，并远程运行NSpec测试以确保一切设置正确。
NSpec与厨师食谱紧密相连。我想它甚至是测试厨房的一部分。所以我们决定使用NSpec和我们的厨师食谱来确保一切都设置正确，这样我们就可以确保我们的服务是启用和运行的。这就是人工的Nginx, DataDog和Splunk。然后我们还要确保配置文件都是正确的，在正确的位置，并具有正确的权限。然后我们还要确保网络端口按预期打开。其中三个有我们感兴趣的端口。Artifactory有tomcat端口，用于Artifactory和访问服务。显然，我们还有Nginx端口。然后DataDog对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.
然后，一旦故障转移到容灾区域，我们可以通过回滚数据库来恢复主区域，如果需要的话，回滚到以前的快照。然后让这些区域在复制过程中恢复同步。这里需要注意的是，在重大升级的情况下，如果不回滚数据库，自动回滚是不可能的，因为通常情况下，这些重大升级涉及某种数据库模式更改。因此，您不能仅仅针对迁移的数据库模式来启动旧的人工版本。有一些进程来回滚那个数据库然后让事情恢复同步是个好主意。实际上，我们现在还没有自动化，但希望我们最终能做到。幸运的是，我们不需要做太多。这是一件好事。
综上所述，自动化发布管道有很多好处。加速交付过程，它们更容易扩展，它们具有可重复的，彻底的测试，并且它们支持回滚策略。即使是像artifactory这样的产品，彻底测试你的基础设施和配置来hth华体会最新官方网站建立发布的信心也是很重要的。总是寻找机会来改善你的管道。现在的投资让你的生活更轻松。这就是我的建议。酷。谢谢。
我们可能还有一点时间，如果有人有问题要问我。是的。
(听不清00:25:18)
我们用什么来进行安全扫描?
是的。(听不清00:25:27)
正确的。因此，我们实际上有一个内部的安全扫描基础设施，它实际上集成了多个产品。hth华体会最新官方网站它目前不包括x光，尽管我们将来可能会评估它。所以这个，肯定是处理二进制文件的。我不能100%确定是什么在做静态扫描。我过会儿再来找你。我可以调查一下。
我很抱歉。你能去讨论室继续吗?
哦,是的。是的。确定。所以,是的。我们可以去讨论室了。如果有人有任何问题，请告诉我，我们会按照[vec 00:26:11]来回答这些问题。谢谢你！
