我叫达米安·库里。
我是NGINX的业务开发技术总监，NGINX现在是F5的一部分，今天我们将讨论现代应用程序部署，特别是如何使用NGINX和JFrog来自动化你的蓝绿部署。
现在，在我们进入所有这些之前，我想花几分钟谈谈它对现代应用程序架构意味着什么。
现在，这对很多人来说似乎很简单，但也有很多人没有完全理解。
要拥有这种现代应用程序体系结构，它不是单一的解决方案。
有多种不同的方式，这不是全有或全无的游戏，你知道，你可以有一个现代的应用程序，它是一个整体，你可以有一个现代的应用程序，它不在Kubernetes中运行。
当然，今天，我们将更具体地讨论Kubernetes，但最好记住，有很多移动的部件，它们都非常重要，但在一天结束时，这些工具是为了让你的生活更轻松，让你的
应用程序基础设施更具弹性，能够快速安全地推出新版本的代码，而不会中断最终用户的体验。
现在，NGINX和F5技术在很多不同的地方都适用于这种情况，我们不打算在这上面花费大量的时间。
但我们确实有一整套的产品，你知道，绝对适用，可以真正帮助你完成这hth华体会最新官方网站个过程。
虽然这里有很多内容，但我们今天将主要关注它的发展部分。
现在,这可能似乎很熟悉的人熟悉JFrog和应用程序开发标准流程,你知道,你有几个关键部分,你显然有自己的开发团队编写代码,然后提交代码到代码回购,这是,在我看来,最该体系结构的重要组成部分,它是在单一来源的真理源代码存储库,这一切来自于那里,如果它不是在回购,它不会投入生产。
基础设施就是代码，文档就是代码。
因为这是这里的一个大的部分，很多时候，传统上，代码库只是为应用程序开发人员准备的。
你知道，在我们有DevOps和SREs这样的头衔之前，我们都只是系统管理员之类的东西。
这个系统的大部分，我认为，在早期是手工管理的，我的意思是，有一些你知道，也许过了一段时间，我们有了像木偶在厨师，这实际上帮助我们开始沿着这条线。
但是现在有这么多的工具和重新定义的基础设施，被旋转成代码。
所有关于如何在云环境中启动环境的细节，都在代码中。所以当你需要站起来扩展你的环境时，非常非常快速，简单的过程。
第二件我要做的是CI\CD管道和自动化。
显然，在没有自动化的情况下很难有一个CI\CD管道，而且你知道，它们真的能很好地协同工作。
这是非常重要的，特别是在管道方面，因为它允许你有完整的测试套件，你可以做更深入的测试，在你将其投入生产之前，你有所有级别的自动化来消除人为错误，减少打字错误或某人的胖手指之类的问题，或者只是登录到错误的服务器并重新启动，对吧?
这些都是已经发生的事情。
你知道，现在我们有了这项技术，它们更容易避免。
最重要的是，当出现问题时，要有回滚的能力。
在我看来，当你在做一个新版本时，最重要的要求就是要有回滚计划。
这就是这些工具对你的环境真正有好处的地方。
现在，对于我们今天要直接讨论的内容，我们将看看JFrog与NGINX+ Ingress控制器的交互。
在我们的Ingress控制器中，我们实际上内置了很多在上游常规Ingress控制器中没有的功能。
主要介绍了虚拟服务器和虚拟服务器路由的思想。
基本上，这是一种扩展的方式，可以更细粒度地控制你的Ingress资源，而不必求助于注释或片段之类的东西。2022世界杯阿根廷预选赛赛程
我们用很简单的方式在编辑中添加了进去能够更细粒度地控制你的访问，什么流量去哪了而不是仅仅基于URI之类的给你更细粒度的控制如果你过去运行过NGINX，你可能已经习惯了。
您可以在不同级别应用这些SSTORIA策略。
所以你可以让你的SecOps团队定义策略，然后自动包含在你的其他资源中。2022世界杯阿根廷预选赛赛程
因此，这是一个很好的方法来划分和确保你的团队相互支持，一起工作。
当然，你可以有片段，对吧?
你知道，你不想把它们作为所有问题的答案，但拥有这种能力真的很有帮助，我们开发它的方式，我们打破它。所以你可以把不同的代码段应用到不同级别的配置上，从全局HTTP变量，到服务器，再到位置块。
因此，它是一个非常强大的工具，允许您进行更细粒度的控制。
你知道，让你做一些简单的事情就像我们要在这里做的一样。
现在，我相信这个过程对每个人来说都很熟悉，你已经有了基本的开发生命周期，对吧?
你有了新的特性和漏洞，它们生成了票据，然后得到了修复，然后它们利用了我们将要谈论的JFrog管道。
它继续调用管道，然后调用artifactory来构建图像，然后调用X-Ray来检查图像并确保一切正常。
最后，一旦所有的测试都通过了，我们就进入了部署阶段。
首先，我们在Dev中进行部署，运行一系列测试，一切看起来都很好，让我们将其推向生产环境。
所以很多人认为，好吧，我们在Dev中测试了它，我们在阶段中测试了它，很快，但只要点击开始，让我们进入生产。
我通常不喜欢这样做，对吧?
因为你知道,即使你可以做很多很好的测试你的较低的环境中,是非常重要的要记住,有一些特性和功能,不会在这些较低的环境中,这样的事情你知道,CloudFlare CDN,取决于你使用负载平衡器,你知道交通实际上是暴露于公众可以产生很大的影响如何服务的行为上。
这就是我们使用这个工具的地方。当涉及到部署时，我们让用户进入NGINX Ingress控制器，然后从那里，它在两个版本之间路由它。
我们首先运行的是金丝雀监视器。
基本上，我们所做的是将v2版本部署到生产环境中，但我们使用NGINX + Ingress控制器中的功能来进行头匹配。
所以现在它只会在特定的报头出现时路由到v2版本，在这种情况下，报头名释放带有beta标签。
现在，你应该这么做，做一些快速检查。酷，一切看起来都很好。
我们应该翻过去吗?好吧，我们可以，但让我们放轻松点。
让我们继续使用拆分功能
让我们在这两者之间分割流量，观察指标，返回代码，看看，确保一切正常运行，然后我们可以慢慢地提高这个比例，最终摆脱旧版本，将所有流量转移到v2。
现在让我们看看当我们进入现实世界时，它是什么样子的。
我们的应用正在运行，我们现在正在构建52。
所以我们需要做出一些改变来修复其中的一个bug。
我们会进行那个提交，然后快速地在这里做一个git push。
看看会发生什么。
好吧，我们按了密码。现在我们继续，让我们同步我们的管道。
好吧，看起来起作用了。
我们在等一个模型。
让我们继续，看看构建是如何进行的。
所以我们将继续，从第一个开始，我们在这里用这个最新版本构建一个Docker映像。
我们要做的第一件事就是等待节点池运行。
让我们看看今天要花多长时间。
好的，当你进行现场演示时，我们总是很有趣，我们今天下午会看到它需要多长时间。
希望这能很快开始工作。
当我们在这里，我们可以快速看一下NGINX plus
仪表板。这是仪表板，它会给你一些额外的信息关于你的Ingress控制器，暴露额外的指标，让你有能力向下钻取，暴露很多信息。
这个现在很基本，我们有几个基本的服务器区设置了我们今天要做的咖啡馆示例和演示示例，你可以看到我们有一些流量到咖啡馆。
这里很好的部分是你可以看到这些区域的交通实际上是如何在上游爆发的。
所以它真的允许你深入，看到每个pod级别的流量如何，并且能够看到我们在这个实例上收到了多少请求，
每秒总请求数是多少，今天真正重要的是这些错误代码。
所以你可以从单个代码中看到实际响应代码的计数
上游组的特定节点。
它也有很好的信息，你知道，发送接收的字节数，服务器检查，健康检查监控器此时没有启用。
你们会看到这些是空白的，但是我们有响应时间。
当你看NGINX+时，这是一个非常非常有用的指标因为你可以看到请求的平均响应时间是多少
到上游节点。
所以你能够更好地识别你是否看到了延迟或者你在那里看到了一些问题，你可以很容易地知道延迟被添加到哪里，无论是在NGINX级别还是在应用程序级别。
好了，看起来我们现在运行了构建。所以我们再等一会儿，希望能跳到下一步。
让我们看看这里，我们已经开始运行了，希望这个图像很快就能在这里建立起来。
我们就可以进行下一步了。
当这个在运行时，我们可以快速看一下我们的管道是什么样子的。
我们有一些东西。你可以看到我们定义了一些不同的资源，我们可以访问我的Git存储库，里面有我们正在运行的所有2022世界杯阿根廷预选赛赛程代码，我们会继续，并确保我们与每个人共享，以防你想看一下，自己测试一下。
我们定义了这个应用程序使用的映像，同时还计算出了一些构建信息以及一些关于我们将执行和运行这些pod的实际端点的不同信息。
接下来，我们来看看这些过程。
显然，现在我们正处于Docker构建过程中。你可以看到我们只是在做一个基本的更新，推送一个映像，然后构建那个映像，推送到Docker，确保一切看起来都很好，然后将它提升到集群中，然后实际部署到那里。
希望我们能在这里快进一点我们会看到有趣的部分。
好的。
看起来我们的第一个构建已经通过了，第二步看起来已经全部完成了。
所以现在我们要推进Docker存储库。
好吧。
一旦它们真正运行起来，它们运行得很快但做现场演示总是很有趣的，对吧?
好，现在我们要把新的吊舱部署到EKS中，把它部署起来。
所以，你知道，排队步骤通常比实际执行的时间要长。
我们来快速地运行一下。
好了，现在我们要确保存在一个空间来部署我们的pod。
我们继续，我们实际上正在进行部署，这一切都做得很好，很干净。
现在我们进入了有趣的部分。
现在我们要把这个应用部署到Ingress控制器中。
很快，你会看到，这里有另一个。就在这里。这就是我们的新部署。
现在我们来到这里，在工具中，我设置了一个自定义头文件。
所以现在如果我重置这个页面，我们应该会看到…
我们得到了404错误。好吧，看起来我们的新架构有点问题，所以
目前，在这个环境中，有一些正在运行的检查。
我们再给它几秒钟，它会尝试重试，再给它几秒钟，确保它有时间来确保404错误确实是个问题。
然后这个测试很快就会失败。
你会看到这些都将被回滚。
几秒钟后，我们会看到这个，release 54，当所有东西都清理干净时，从仪表板中删除，因为那个失败了。
有趣的是，你可以看到在Kubernetes中定义这个虚拟服务器是多么简单，这就是错误。好了。
都打扫干净了。好吧，我们遇到了这个问题。
让我们继续，我们将要
继续，让我们推送一个新版本。
所以你知道，有人会说，嘿，你破坏了一切，你的版本不能正常工作。让我们继续。好吧，我们找到解决办法了。
我们继续，让我们推它。
我们会把它放到GitHub上。
现在我们回到管道源，确保我们能快速得到它，我们继续，再次运行同步，我将跳回到管道，你可以看到那里已经有一个作业在处理。
好了，现在我们要看看这个构建是否会运行得更快。
看起来我们已经开始得快一些了。
希望今天能讲得快一点。
现在，如果我们到这里，我们可以继续刷新页面，你会看到它现在把我们拉回到build 52。
所以这种改变已经开始了。
因为这是在一个标题版本中完成的，所以公众没有看到任何问题。
所以即使是在生产系统中，这些都只是内部测试。
好吧。
我们勇往直前，完成了这个过程。它会继续进行下一步，它成功了，这总是好的。
好了，第二步开始了。
这个已经完成了，因为，你知道，一旦第一个发生了，它们都很快地滚过这里。
好吧，我们在等Docker的晋升。
开始了。
马上就要开始了。
好吧。
我们将继续，再次将这个部署实际部署到EKS集群中。
很好，部署完成了。现在我们再试一次。
希望我们已经抓住了破坏头检查的bug。
所以让我们重新部署它。你可以再次看到，服务弹出
就在这里，你可以看出我们在设置一些东西。在路由定义中，我们只是在路由斜杠这里，它匹配标志。
我们看到的条件是头被释放，值是。
这将把流量发送到演示实验室服务55。
然后，其他所有不匹配的请求都会被发送到52号。
如果我们来到这里，希望能刷新一下。
太好了，我们有55个。
那么现在。如果我们继续我可以停止。
好，现在它在运行这些检查应该在几秒钟内通过，一切看起来都很好。
我们可以在这里打开另一个标签这里我们没有设置。
我们没有设置这个值，现在你可以看到我们有52。
因此，我们有两个不同的构建，它们同时在同一个URI上运行。
好了,好了。因此，这些测试已经通过，现在我们将转向分流流量。
在这个演示中，我们只做五五分。
您知道，通常在真实的生产环境中，您可能会想要做更多的事情。
好的,太棒了。看起来它已经跑了。
是的。好的。你可以看到，当我们运行这个服务器时，它都配置好了，我们运行了一个检查，我们在这里检查的是，我们实际上在NGINX上检查状态页，寻找HTTP响应码。
你可以看到它发现了400个错误。所以我们后退了。
好吧，显然我们又有麻烦了。
让我们继续，我想我们有最后一个构建，我们将继续实际修复这个。
我们将执行最后一次commit和push，看看会得到什么。
再一次，快速地，我们将同步管道源。
好了，看来我们已经开始工作了。
希望这是我们需要的最后一张图。
让我们看看接下来会发生什么。
好了，图像构建好了。
让我们看看这次流程的其余部分运行得有多快。
好吧，看起来这台运行得很好。它在推动新的图像。
好了，一切都清理干净了。
我们可以继续推广这种形象。
好的，现在我们要推出这个部署。
好了。
好了，部署已经完成了希望这是我们最后一次，我们会通过所有这些测试然后回滚旧版本。
再一次，我们推出header base test，我们在这里有了新应用。
让我们在这里试试。
现在我们有了。
这里有56号建筑。为了好玩，我们来确定一下…
这里还有52号建筑。
好的，一切看起来都很好。
测试应该很快就能完成。
仪表板上一切正常，可以看到有几个请求进入了新请求，也有几个请求进入了旧请求。
所以能够知道你的交通在那里被隔离是很好的，你不用担心公共交通会影响这些早期部署。
希望几秒钟后，这张支票就能通过。
好的，现在我们进行了加权部署你可以看到所有的。
所有的计数都将重置，这些都是实时的。
所以你也可以很容易地把这些数据拉到我们的Prometheus出口商，并对其进行检查。
所以它非常灵活。
好的，现在你看到了。它发生得非常快，一旦它聚集在一起，所以检查通过了，我们继续前进，不仅把所有的流量滚到新版本，我们继续前进，滚回旧版本，你可以在这里看到。现在不是build 52，而是build 56。好了。我们的演示到此结束。
希望大家都喜欢这个演讲。
如果您有任何问题或意见，请让我们知道。
我们很乐意听到更多的消息，大家都享受接下来的会议，祝大家有愉快的一天。
