容器CI&CD实践:基于Helm实现应用交付自动回滚

640?wx_fmt=png&wxfrom=5&wx_lazy=1

打造开源云计算中国第一互动社区

内容专注于Linux、Kubernetes、OpenStack、容器、Ceph、Cloud Foundry......

导读


随着容器的落地,交付的规模和速度都在快速增长,日趋频繁的容器应用交付也带来很多实际的问题,比如如何自动化地快速回滚?


传统做法是通过设置“发布守护者”角色去观察发布过程中的每个细节,一旦发现情况不妙,就立即采取措施,人工干预发布的过程。


然而,人的精力毕竟有效,大量繁复的工作难以保证其质量,也导致发布效率很快遇到瓶颈。为了很好地解决这个问题,基于 Kubernetes 的 Helm Chart 首先解决了应用的编排问题,实现一键发布,同时结合 Prometheus 或者 ElasticSearch 实现高灵敏度地探测应用的实时状态,动态实时地做出响应,比如回滚或者暂停,这种方式能够大幅度减少部署工作量,并且提高部署质量。


基于这种策略,能够很轻松地实现对应用运行动态的实时监测,也方便在应用状态异常时,通过简单的 Helm 命令实现整个应用的回滚。过程中涉及的 Helm、Prometheus 或者 ElasticSearch 都是开源组件,能够非常方便地集成到整个 CI/CD 流水线,因此本文中推荐的做法也很有借鉴意义。


—— 译者 JFrog 中国解决方案架构师付辉

前言

持续交付正在成为一种标准,如果部署的流程得当,那么部署的结果将是可预测的。在代码中进行更改时,大部分时间都遵循构建、测试、部署和监控等步骤。大多数实现了自动化部署的人都会这么来做。


如果在监控阶段检测到故障,则运维人员必须验证并将故障发布回滚到先前已知的工作状态。这个过程非常耗时,并不总是自动化的,因为它需要有人监视监视仪表盘并对其做出反应。


如果团队结构良好并采用了 Devops 的工作方式,那么值班人员会在出现问题时收到警报。警报是根据指标触发的,但在接到警报后,值班人员必须打开笔记本电脑(如果不在现场),查看图表,弄清楚问题所在,并决定上次发布是否需要回滚。


退一步思考,如果你可以自动化这个过程呢?


本文将提供关于 Kubernetes 部署的一些基本知识,以及如何使用 Helm 及其插件功能来更智能地控制基于 Prometheus 指标的版本回滚。

640?wx_fmt=png

关于 Helm 和 Kubernetes 部署的一些基本知识

如果您使用 Kubernetes,大部分时间您将配置存储到应用程序库中。


然后在部署阶段,运行 Kubectl Apply -f ./manifest.yaml 命令将您的配置应用到集群。遵循这种做法通常很好,但需要为每个应用程序创建一个配置。


为了简化这个过程,Deis(现在是 Microsoft 的一部分)背后的团队创建了 Helm 。


Helm 是一个 Kubernetes 软件包管理器,它将模板和控制发布的能力提升到了一个新的水平。它最近吸引了很多注意力,因为它简化了应用程序的发布过程。如果您想了解更多关于 Helm 的信息,我诚邀您阅读入门指南:https://docs.helm.sh。


使用单个命令,您可以升级一个应用程序:

640?wx_fmt=png

在上面的例子中,我假定 company-repo/common-chart已经被创建。


那么,如果你想回滚到以前的版本:

640?wx_fmt=png

很简单不是吗?


现在我们可以升级并回滚 Release 了,我们可以跳到下一步:基于 Prometheus 指标回滚。


监控发布,失败回滚

几天前我发布了一个名为 Helm-Monitor 的 Helm 插件。这个插件就像听起来那么简单,它会定期查询 Prometheus 或 ElasticSearch 实例。当返回肯定的(译者注:这里的肯定指应用部署不正常)结果时,应用程序将其视为失败并启动发布版本的回滚。

640?wx_fmt=png

以下是通过 Helm-Monitor 插件使用 Helm 监控发行版的步骤。


在这个例子中,需要直接访问 Prometheus 实例(如果在本地进行测试,使用 Kubectl Port-Forward 可以很方便)。


安装插件:

640?wx_fmt=png

使用新版本的应用程序升级您的 Release:

640?wx_fmt=png

自升级开始以来,我们现在可以通过查询 Prometheus 来监控我们的发布。在以下示例中,如果在过去5分钟内测量的5xx错误率超过0,则会启动回滚:


640?wx_fmt=png

默认情况下,Helm-Monitor 每10秒钟运行一次查询,总共5分钟。如果5分钟后没有找到结果,则停止监测过程。


Github 上提供了一个关于如何使用 Helm-Monitor 的完整示例。


到目前为止,该插件仅支持 Prometheus 和 ElasticSearch 查询,但您可以轻松插入另一个系统。 ElasticSearch 查询可能如下所示:

640?wx_fmt=png

总结

当检测失败时,即使准确,人类识别模式的速度也很慢。这就是为什么要采用自动化的方式来识别常见故障模式,并在发布期间和之后采取行动。通过这种方法,使用 Helm 和 Helm Monitor 插件发布应用程序,您可以节省一些时间并专注于重要的事情:交付高质量的产品。


希望这些信息可以帮助您改善您的交付流程。


内容覆盖主流开源领域

640?wx_fmt=png 640?wx_fmt=png 640?wx_fmt=png 640?wx_fmt=png 640?wx_fmt=jpeg 640?wx_fmt=png

投稿邮箱

[email protected]

640?wx_fmt=png

猜你喜欢

转载自blog.csdn.net/lq1ns259ej3okyvk4jf/article/details/79990735