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

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

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

导读

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

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

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

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

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

前言

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

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

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

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

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

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

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

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

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

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

使用单个命令，您可以升级一个应用程序：

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

那么，如果你想回滚到以前的版本：

很简单不是吗？

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

监控发布，失败回滚

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

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

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

安装插件：

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

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

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

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

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

总结

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

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

内容覆盖主流开源领域

投稿邮箱

[email protected]