现代应用部署:如何使用NGINX和JFrog自动化你的蓝/绿部署

Damian咖喱
业务拓展技术总监

使用Kubernetes部署现代应用程序并不复杂。

了解JFrog和NGINX如何联合起来,通过集成的监控指标交付一致的CI/CD部署,从而为您的客户提供快速、安全的应用程序体验。

技术演示将包括由NGINX Plus入口控制器前端的Kubernetes集群上的蓝/绿应用部署示例。

视频记录

大家好,感谢大家今天的到来。

我叫达米安·库里。

我是NGINX的业务开发技术总监,它现在是F5的一部分,今天我们将讨论现代应用程序部署,特别是如何使用NGINX和JFrog来自动化你的蓝绿部署。

现在,在我们进入所有这些之前,我想花几分钟讨论一下它对现代应用程序体系结构意味着什么。

现在,这对很多人来说似乎很简单,但也有很多人没有完全理解它。

要拥有这种现代应用程序体系结构,它不是一个单一的解决方案。

有多种不同的方式,这不是一个全有或全无的游戏,你知道,你可以有一个现代的应用程序,它是一个单体,你可以有一个现代的应用程序,但它不能在Kubernetes中运行。

当然,今天,我们将更具体地讨论Kubernetes,但最好记住有很多移动的部分,它们都非常重要,但在一天结束的时候,这些工具是为了让你的生活更轻松,让你

应用程序基础设施更具弹性,能够快速安全地推出新版本的代码,而不会中断最终用户体验。

现在,有很多不同的地方NGINX和F5技术适用于这一图景,我们不打算在这方面花费大量时间。

但我们确实有一整套产品,你知道,绝对适用,可以真正帮助你完成这个hth华体会最新官方网站过程。

虽然这里有很多东西,但我们今天主要关注的是它的发展部分。

现在,这可能似乎很熟悉的人熟悉JFrog和应用程序开发标准流程,你知道,你有几个关键部分,你显然有自己的开发团队编写代码,然后提交代码到代码回购,这是,在我看来,最该体系结构的重要组成部分,它是在单一来源的真理源代码存储库,这一切来自于那里,如果它不是在回购,它没有投入生产。

基础设施就是代码,文档就是代码。

因为这是这里的一个重要部分,很多时候,传统上,代码库仅供应用程序开发人员使用。

说到运营,在我们有DevOps和SREs之前我们都只是系统管理员之类的。

我认为,这个系统的大部分在早期都是手工管理的,我的意思是,也许过了一段时间,我们有了一些东西,比如Chef中的Puppet,这实际上帮助我们开始沿着这条路线发展。

但现在有太多的工具和重新定义的基础设施,它们被分解成代码。

所有关于如何在云环境中启动环境的细节,都在代码中。所以当你需要站起来扩展你的环境时,非常非常快速,简单的过程。

第二部分是CI / CD流水线和自动化。

显然,如果没有自动化,很难有一个CI / CD管道,你知道,它们真的可以很好地协同工作。

这是非常重要的,特别是在流水线方面,因为它允许你有一个完整的测试套件,你可以做更深入的测试,在你把它投入生产之前,你有所有的自动化水平,以消除人为错误的水平,减少一个途径,有一个打字错误或某人的大手指什么的,或者,你知道,只是登录到错误的服务器,重新启动它?

这些都是已经发生的事情。

你知道,现在我们有了这项技术,它们更容易避免了。

最重要的是,当出现问题时,能够进行回滚。

在我看来,当你做一个新版本时,最重要的要求是有一个回滚计划。

这就是这些工具能真正,真正有益于你的环境的地方。

今天我们要直接讨论的是JFrog与NGINX+ Ingress控制器的交互。

在我们的Ingress控制器中,我们实际上内置了很多上游常规Ingress控制器中没有的功能。

主要介绍了虚拟服务器和虚拟服务器路由的概念。

基本上这是一种扩展的方式来对你的入口资源进行更细粒度的控制而不需要使用注释或片段之类的东西。2022世界杯阿根廷预选赛赛程

所以我们以非常简单的方式添加了编辑,能够更细粒度地访问控制,什么流量去哪里,而不仅仅是基于,你知道,一个URI或类似的东西,给你更细粒度的控制,如果你过去一直在运行NGINX,你可能已经习惯了。

您可以在不同级别应用这些SSTORIA策略。

因此,您实际上可以让您的SecOps团队定义策略,然后将其自动包含在您的其他资源中。2022世界杯阿根廷预选赛赛程

所以这是一种很好的划分方式,确保你的团队相互支持,一起工作。

当然,你也可以有片段,对吧?

你知道,你不想把它们作为所有问题的答案,但拥有这种能力真的很有帮助,我们开发它的方式,我们打破了它。因此,您可以将不同的片段应用于许多不同级别的配置,从全局HTTP变量一直到服务器,一直到位置块。

因此,它是一个非常强大的工具,允许您进行更细粒度的控制。

你知道,它可以让你做一些简单的事情,就像我们在这里要做的一样。

现在,我相信每个人都很熟悉这个过程,你已经有了基本的开发生命周期,对吧?

你有了新特性和bug,它们会生成票据,然后得到修复,你知道,然后它们利用我们将要讨论的JFrog管道。

所以它继续调用管道,然后调用artifactory来构建图像,然后调用X-Ray来检查图像并确保一切正常。

最后,一旦所有的测试都通过了,我们就进入部署阶段。

首先,我们在Dev中部署,运行一系列测试,很好,一切看起来都很好,让我们把它推出到生产环境中。

所以很多人会想,我们在Dev中测试了,我们在staging中测试了,很快就可以了,让我们进入生产环境吧。

我通常不喜欢那样做,对吧?

因为你知道,即使你可以做很多很好的测试你的较低的环境中,是非常重要的要记住,有一些特性和功能,不会在这些较低的环境中,这样的事情你知道,CloudFlare CDN,取决于你使用负载平衡器,你知道交通实际上是暴露于公众可以产生很大的影响如何服务的行为上。

这就是我们使用这个工具的原因。当涉及到部署时,我们让用户进入NGINX Ingress控制器,然后从那里,它在两个版本之间路由。

所以我们首先运行的是我们称之为金丝雀监视器的东西。

基本上,我们正在做的是将v2版本部署到生产环境中,但我们正在使用NGINX和Ingress控制器中的功能来进行标头匹配。

所以现在它只会路由到这个v2版本,如果一个特定的标题是存在的,在这种情况下,标题名称发布与标签beta。

现在,你知道,你应该这么做,做一些快速的检查。很好,一切看起来都很好。

我们就这样翻过去吗?可以,但我们还是放轻松点吧。

让我们继续,让我们使用拆分功能

让我们将流量分成两部分,观察参数,返回代码,确保一切正常,然后我们可以慢慢提高这个比例,最终摆脱旧版本,将所有流量转移到v2上。

现在让我们来看看当我们进入现实世界时,它到底是什么样子的。

我们的应用在运行,现在是build 52。

所以我们需要做出一些改变来修复其中的一个bug。

我们会继续做那个提交,在这里快速地做一个git push。

让我们看看会发生什么。

好吧,我们推了密码。现在我们继续,让我们同步管道。

好了,看起来起作用了。

我们已经准备好了。

让我们来看看构建是如何进行的。

因此,我们将从第一个使用最新版本构建Docker映像的地方开始。

我们要做的第一件事就是等待节点池运行。

我们来看看今天要花多长时间。

好的,我们总是很开心当你在现场演示时,我们会看到今天下午需要多长时间。

希望这能很快开始。

在这里,我们可以快速浏览一下NGINX plus

仪表板。这是仪表板,它会继续并给你一些额外的关于你的Ingress控制器的信息,暴露额外的指标,并给你能力去深入并暴露很多。

这个现在很基本,我们只有几个基本的服务器区域设置我们的咖啡馆例子和我们今天要做的演示例子,你可以看到我们有一些流量去咖啡馆。

这里的好处是你可以看到这些区域的流量实际上是如何在上游爆发的。

所以它真的可以让你深入了解,甚至可以看到每个pod级别的流量在哪里,并且能够看到我们在这个实例上收到了多少请求,

每秒的总请求数是多少,今天真正重要的是这些错误码。

这样你就能看到单个响应代码的计数

上游组的特定节点。

它也有良好的信息,发送接收的字节,服务器检查,健康检查监控器此时没有启用。

你会看到这些是空白的,但我们有反应时间。

所以当你看NGINX+时,这是一个非常非常有益的指标,因为你可以看到请求的平均响应时间是多少

到上游节点。

这样你就能更好地识别你是否看到了延迟或者你在那里看到了一些问题,你可以很容易地判断延迟是在哪里添加的,无论是在NGINX级别还是在应用程序级别。

好了,看起来我们现在让构建运行起来了。我们再给它一点时间,希望能跳到下一步。

让我们看看这里,我们已经开始运行了,希望,这个图像很快就会在这里建立起来。

我们就能进行下一步了。

在这个运行的时候,我们可以快速看一下管道是什么样子的。

我们有一些东西。所以你可以看到我们定义了一些不同的资源,我们可以访问我的Git存储库,里面有我们正在运行的2022世界杯阿根廷预选赛赛程所有代码,我们将继续并确保我们与大家分享,如果你想看看这个,并自己测试它。

我们正在定义我们在这个应用程序中使用的映像,同时你知道,弄清楚一些构建信息和一些关于我们将执行和运行这些pod的实际终点的不同信息。

接下来,我们来看看这个过程。

显然,现在我们正处于Docker构建过程中。你可以看到我们只是在做一个基本的更新,推送一个映像,然后构建那个映像,将它推送到Docker,确保一切看起来都很好然后将它提升到集群中然后继续,在那里部署它。

希望我们能往前走,快进一点然后我们就到了有趣的部分。

好吧。

看起来我们的第一个构建已经通过了,第二步看起来现在已经全部完成了。

现在我们要把它推入Docker存储库。

好吧。

一旦它们真正运行起来,它们运行得很快但这总是做现场演示的乐趣,对吧?

好了,现在我们要把这个新pod部署到EKS中,让它部署并站立起来。

所以,你知道,排队步骤通常比实际执行的时间要长。

我们会让它快速运行。

好了,现在我们只需要确保存在一个名称空间来部署我们的pod。

我们继续,我们实际上在进行部署,这一切都做得很好。

现在我们进入有趣的部分了。

现在我们将把这个应用部署到Ingress控制器中。

很快,你会看到,这里会有另一个。现在就在这里。这就是我们的新部署。

现在我们回到这里,在工具中,我有一个自定义header正在设置。

那么现在如果我重置这个页面,我们应该看到…

我们得到一个404错误。好吧,看来我们的新产品有点问题,所以

现在,这里的环境中正在进行一些检查。

我们在这里给它几秒钟,它在尝试重试,给它几秒钟,确保,它给它一些时间来确保404错误实际上是一个问题。

然后这个测试应该很快就会失败。

你会看到这些都被回滚了。

几秒钟后,我们应该继续看这个,你知道,释放54,当一切都被清理干净时,继续离开我们的仪表盘,因为那失败了。

有趣的是,你可以看到在Kubernetes中定义这个虚拟服务器是多么的简单,这里出现了错误。好了。

都打扫干净了。好吧,我们遇到了这个问题。

让我们继续,我们将要

继续吧,我们推出一个新版本。

所以你知道,有人会说,嘿,你破坏了一切,你的版本不能正常工作。我们继续。好了,我们想我们找到了。

我们继续,推一下它。

我们会把它推送到GitHub。

现在我们回到管道源,以确保我们能快速得到它,我们将继续,再次运行同步,我将跳转到管道,在那里你可以看到已经有一个作业处理。

好了,现在我们来看看这个构建是否会运行得更快。

看起来我们已经开始得更快了。

希望今天能快一点。

现在,如果我们到这里,我们可以继续刷新页面,你会看到它现在让我们回到build 52。

因此,这种变化已经展开。

因为这是在标题版本中完成的,所以公众看不到任何问题。

所以这都是内部测试即使是在生产系统中。

好吧。

我们继续前进,完成了这个过程。所以它会继续前进,进入下一个步骤,它成功了,这总是好的。

好了,第二步开始了。

这个已经完成了,因为,你知道,一旦第一个发生,它们很快就会通过这里。

好的,我们正在等待Docker的推广。

它开始了。

马上就要开始了。

好吧。

我们将继续把这个部署再次部署到EKS集群中。

很好,部署完成了。现在我们再试一次。

希望我们已经抓住了破坏header检查的bug。

所以让我们重新部署它。再次,你可以看到,服务弹出

就在这里,你可以看到我们设置了一些东西。在路由定义中,我们只是路由斜线,这里,它匹配标志。

我们看到的条件是header被释放,值是beta。

这将把流量发送到这个演示实验室服务55。

然后,其他不匹配的请求会继续被发送到52号。

如果我们到这里,希望能刷新一下。

太好了,我们有55个。

那么现在,如果我们继续,我可以继续,然后停止…

好了,现在程序正在运行这些检查会在几秒钟后通过,一切正常。

我们可以在这里打开另一个选项卡我们不设置那个。

我们没有设置这个值,现在你可以看到我们有数字52。

所以我们有两个不同的构建,它们同时运行在同一个URI上。

好了,好了。所以这些测试已经通过了,现在我们将继续分割流量。

在这个演示中,我们继续做50-50分割。

您知道,通常在实际的生产环境中,您可能希望执行更多操作。

好的,太棒了。看起来它已经向前跑了。

是的。好吧。你可以看到,当我们运行这个服务器时,它已经配置好了,我们运行了一个检查,我们在这里检查的是NGINX上的状态页,寻找HTTP响应代码。

你可以看到它发现了400个错误。所以我们往回走。

好吧,显然我们又有麻烦了。

让我们继续,我想我们有最后一个构建,我们会继续,并实际修复这个。

我们要做最后的commit和push,看看会得到什么。

很快地,我们会同步管道源。

好了,看起来我们已经开始工作了。

希望这是我们需要的最后一张图片。

让我们看看接下来会发生什么。

好了,图像建立好了。

让我们看看这个过程的其余部分这次运行得有多快。

好吧,看起来这台运行得不错。它正在推动新形象。

好了,一切都打扫干净了。

我们可以继续推广这种形象。

好的,现在我们要推出那个部署。

好了。

好的,部署就在那里,现在希望,这将是我们最后一次,我们会继续并通过所有这些,我们所有的测试我们会继续并回滚旧版本。

我们推出了header base测试,我们在这里有了新应用。

我们在这里试一下。

现在我们有…

这里有56号楼。为了好玩,我们来确定一下……

这里还有52号楼。

好了,一切看起来都很好。

测试应该很快在这里完成。

仪表板上的一切看起来都很好,你可以看到我有几个请求进入了新请求,也有几个请求进入了旧请求。

因此,能够告诉您的流量在那里被隔离是很好的,您不必担心面向公众的流量会影响这些早期部署。

希望几秒钟后,这个检查会通过。

好了,现在我们进行了加权部署,你可以看到所有的。

所有的计数都会被重置,这是实时的。

因此,您也可以使用我们的Prometheus导出器轻松地将这些数据拉入Prometheus,并对其进行检查。

所以它非常灵活。

好的,现在你看到了。这一切都完成后发生得很快,所以检查通过了,我们继续前进,不仅把所有的流量转到新版本,我们继续回滚旧版本,你可以在这里看到。所以现在我们不是在构建52中运行,而是在构建56中运行。好了。我们的演示到此结束。

希望大家都喜欢今天的演讲。

如果您有任何问题或意见,请告诉我们。

我们很想听到更多,希望大家在接下来的会议中玩得愉快,度过美好的一天。

要么释放,要么死亡