应该使用什么 CI/CD 工具？

本文首发于：Jenkins 中文社区

在咱们正在进行的 Kubernetes FAQ 系列中，咱们回答了社区中一些常见的问题，本周咱们将讨论在选择 CI/CD 工具时须要考虑什么。

目前已经有大量的 CI/CD 工具可供选择-开源解决方案和商业解决方案。在这里，咱们重点介绍在设置持续交付流水线时要考虑的一些最重要的注意事项。

在这篇文章中你将学到：

• 为何须要自动化流水线
• 部署典型流水线的组件
• CD 流水线功能须要考虑
• 如何合并 GitOps

为何要建立自动化 CI/CD 流水线？

自动化 CI/CD 流水线有许多好处：

• 将您的上线时间从数周或数月减小到数天或数小时。经过自动化流水线，开发团队能够提升发布的速度以及代码的质量。以小增量连续添加的新功能和修复可使产品具备更少的缺陷。
• 一个强大的开发团队。因为交付流水线的全部阶段均可供团队中的任何人检查、改进和验证，所以能够建立对构建的全部权，从而鼓励整个组织的强大团队合做和协做能力。
• 下降软件开发的风险和成本。自动化鼓励开发人员在继续前进以前分阶段验证代码更改，从而减小了缺陷最终出如今生产中的机会。
• 减小进展中的工做量。CD 流水线提供从开发到客户的快速反馈循环。这个迭代周期不只能够帮助您构建正确的产品，并且还容许开发人员更快地进行产品改进，从而减小正在进行的工做。

典型的部署流水线

CD 流水线由几个不一样的阶段组成; 一个工具不能知足全部这些步骤。

如下是构成大多数自动化流水线的步骤：

1. 在笔记本电脑上编写代码，将其推入源代码仓库(如 Git)。
2. 代码经过单元、集成和其余自动化测试。若是测试经过，将构建成新的 Docker 镜像。
3. 将镜像推送到镜像仓库。
4. 将新镜像推送到集群中。

思考 CD 流水线的特性

建立流水线的困难之一是成功地将您想要使用的工具粘合在一块儿。这些是为流水线选择工具时要考虑的主要功能：

• 端到端的安全性
• 可以使用彻底可重现的审计跟踪进行回滚
• 内置可观察性和警报功能
• 平均快速部署时间以及平均快速恢复时间
• 简单的开发人员经验和工做流程

流水线端到端的安全性

在市场上的 CI/CD 工具中，有些工具将 CI 和 CD 部分合并为一个工具。或者更糟糕的是，那些负责建立 CI/CD 流水线的人将组装一系列手工锻造的脚本，这些脚本能够在一个方向上经过流水线推送代码，或执行被称为CIOP 流水线。

出于多种缘由，您不但愿这样作。这是一种反模式，由于集群安全和其余凭据不在集群以外，这多是不安全的。建议的方法是使用实​​现 Kubernetes Operator 的工具。

部署到集群的 Kubernetes Operator 能够监视仓库中的新镜像。更进一步，若是您的整个集群状态（经过声明性清单）都保存在 Git 中，那么“diff alert”能够成为从仓库中“提取”新镜像并将其部署到集群的动力。这不只是一种更安全的部署方法，并且还为开发人员提供了一种更简单的方法来应用和回滚生产环境的更改。

具有完整审计跟踪回滚

跟踪差别历史记录，以及在团队中处理大型应用程序时管理新旧部署的回滚可能具备挑战性。您须要一个能够轻松处理此类方案的工具。若是您拥有一个彻底可审计的路径，它能够帮助您了解什么时候什么时候执行了哪些操做，这也有助于 SOC 2合规性规定的增长。

可观察性和警报

将可观察性归入您的流水线意味着什么？

为了提升你的速度，你的流水线须要结合可观察性来回答这些问题：

若是自动发布更改，我怎么知道它是否有效？ 在复杂的分布式系统中，我如何理解问题、诊断问题并管理事件 - 尤为是当您须要回滚时？ 将持续交付与实时可观察性相结合，使您的开发团队可以在部署新功能以前作出更好的决策。

新功能和补丁被推送到 Git 并触发部署流水线，当它们准备好发布时，理想状况下应该对正在运行的集群实时监控。这容许开发人员根据反馈作出决策。能够将它们返回到流水线的起点，或将更新后的镜像部署到生产集群中。

更快的平均部署和恢复时间

除了可以频繁可靠地部署以外，还须要考虑考虑一个重要场景，是在集群宕机时的恢复。这须要快速、平滑，而且可能由可能不是由 Kubernetes 专业的开发人员来执行。

简单的开发人员经验和 Git 工做流程

为了在当今的云原生世界中快速发展，开发人员必须从端到端控制流水线。提交凭据等待人来回复的时期已经没有了。从开发人员一直使用的工具构建流水线是有意义的。像 Git 这样的工具。

使用 GitOps，有三个基本原则：

＃1.全部能够描述的内容都必须存储在 Git 中

经过使用 Git 做为事实源，能够观察集群并将其与所需的状态进行比较。目标是描述全部内容：策略、代码、配置，甚至监控事件和版本控制。将全部内容保持在版本控制之下，能够加强收敛性，若是最初它们没有成功，则能够从新应用更改。

＃2.不要直接使用 kubectl

通常来讲，使用命令行工具 kubectl 直接部署到集群不是一个好主意。许多人让他们的 CI 工具推进部署，可是这样作可能会对生产环境遭受更容易被攻击的风险。

＃3.使用遵循操做符模式的 Kubernetes Operator

使用遵循操做符模式的 Kubernetes Operator，您的集群始终经过其签入 Git 的配置文件与“事实源”保持同步。因为集群的所需状态保存在 Git 中，所以还能够观察到与正在运行的集群的差别。

将 GitOps 工做流程应用于流水线

经过采用 GitOps，开发人员能够经过提取请求管理基础架构配置和软件部署以及回滚。当真实来源与集群中运行的不一样时，集群会自动与 Git 中保存的内容同步。

Weave Cloud 的部署代理在集群内部运行。这意味着容器映像注册表和集群 API 的凭据永远不会离开集群的域。经过使用 Git 做为事实源，能够比较和警告所需的状态和当前状态。这不只能够确保集群保持最新，并且还能够在集群崩溃时提供从灾难中快速恢复的方法。

译者：史彦军