Argo成熟度曲线的四个阶段

Argo CD 是最流行的用于将应用程序部署到 Kubernetes 集群的 GitOps 工具。许多将应用程序迁移至 Kubernetes 的团队选择 Argo CD，因为它拥有强大的同步引擎和直观的仪表板。

Argo CD 也是完全开源的，这意味着团队可以自由地将其安装在私有云、防火墙后的数据中心或内部网络中的服务器，甚至在空气隔离的环境中（即无网络连接的环境），无需任何许可证。特别是自 Weaveworks 在 2024 年初停止运营以来，Argo CD 的人气正在迅速上升。

然而，重要的是要理解，虽然 Argo CD 是一个很棒的 GitOps 同步工具，但它缺乏一些大型企业在大规模部署时需要的功能。如果你只有一个或两个 Kubernetes 集群，且应用数量不多，开始使用 Argo CD 就显得非常简单。但对于大型安装，涉及多个集群和多个应用的情况，仅使用 Argo CD 会显得过于繁琐。在这种情况下，随着你组织的 Kubernetes 使用规模扩大，考虑像 Codefresh 这样的企业级解决方案会更有利。

在本指南中，我们将介绍 Argo 成熟度曲线的四个阶段，并说明 Codefresh 如何在每个阶段为您提供 Argo CD 默认功能之外的帮助。

这里的主要观点是，企业有一些需求 Argo CD 的同步引擎无法满足，而 Codefresh 则是专为企业平台设计的。

阶段一 — 初始安装 Argo CD 对比使用控制平面

Argo CD的开源版本默认支持两种安装模式：如下所示。

1. 在每个 Kubernetes 集群上都安装一个 Argo CD 实例。
2. 安装一个中心的 Argo CD 实例来管理多个其他集群。

每个方法都有其各自的优缺点。我们在我们关于 Argo CD 架构的文章中详细介绍了这些内容。重点是，没有一个选项是完美的，每个选项都有其各自的不足。

在大规模管理时，这些单独的 Argo CD 实例特别棘手。

最大的问题在于日常的集群管理。你现在需要管理多个 Argo CD 实例及其各自的仪表板。比如有六个 Kubernetes 集群，你也将有六个不同的仪表板。找应用时，你需要记得使用正确的 Argo CD 仪表板。将六个 Argo CD 实例全部升级到同一版本也是一项棘手的任务。

你可以有一个中央的 Argo CD 实例来管理其他集群。

这也带来了一些不小的挑战。

1. 中央的 Argo CD 实例是单一故障点。
2. 与其他集群的通信是向外的。这意味着如果其他集群不在同一个网络域中，你需要在防火墙中打开相应的端口。
3. 当你拥有大量应用程序和集群时，集中式的实例很快就会成为性能瓶颈。

选择这两种安装选项的团队每天都不得不面对这些缺点，并且要么接受它们，要么想方设法解决。使用Codefresh则有第三种选择，即使用控制台。

Codefresh控制平面将多个Argo CD实例整合到一个统一的管理仪表板中。

控制平面方法兼具两种世界的最佳优势，没有不足。

1. 与控制平面的通信是从内到外的。这意味着你可以在防火墙后面管理 Argo CD 实例，并且不需要开启任何端口。
2. 没有单点故障。即使控制平面出现问题，各个 Argo CD 实例仍会各自继续同步。
3. 没有性能瓶颈，你可以很容易地混合配置多个 Argo CD 实例和集群。
4. 仍然可以使用统一的应用程序仪表板来查看和管理 Argo CD 实例。

最重要的一点是，对于使用 Argo CD 的用户，特别是开发人员来说，这一点尤为重要。他们现在可以轻松查看他们的应用，不再需要在多个控制面板间切换。

即使在这个早期阶段（安装 Argo CD 时），选择 Codefresh 会为 Argo CD 的管理员和用户带来额外的好处。

第二阶段 — 管理多个应用和追踪代码变动

完成初始安装后，让我们来看看日常操作是怎么进行的。创建 Argo CD 应用程序其实很简单。开箱即用，Argo CD 就可以支持你的 Helm 图表、Kustomize 覆盖以及其他任何自定义清单。

这里的主要问题在于，Argo CD 知道的应用程序信息非常有限。Argo CD 关于一个应用程序唯一知道的信息是，

1. 存放 Kubernetes 资源的 Git 仓库
2. 要部署的容器镜像
3. 应用部署的目标集群
4. 应用配置文件的 Git 哈希值

就这样！Argo CD 无法看到开发者关心的东西。开发者想了解哪些源代码改动进入了版本，还需要了解单元测试结果、安全漏洞和拉取请求等信息。Argo CD 对容器镜像构建之前的细节一无所知。

这意味着开发人员需要在多个系统（如 GitHub、Jira、持续集成服务器和 Argo CD）之间切换，以确切了解 Argo CD 部署了哪些内容。

几个团队采用了 Argo CD，希望开发人员能将 Argo CD UI 作为他们所有部署需求的一站式工具。但很快发现，开发人员仅使用 Argo CD UI 不够用。于是，组织开始考虑引入开发人员门户和内部开发平台，以解决开发团队的日常需求问题。

通过 Codefresh，你可以实现从源代码提交到部署全程可追溯。

Codefresh从多个其他系统（如CI服务器或票务服务器（例如JIRA））收集信息，并提供了一个应用程序部署的完整时间轴，包括所发生的所有事件：

• 谁发起的变更
• 哪个 Git 提交
• 包含了哪些功能（例如 Jira 任务）
• 哪些拉取请求参与了变更
• 使用了哪个流水线来创建工件
• 安全扫描、单元测试、代码规范检查等的结果
• 生成并推送到仓库的容器镜像有哪些
• 哪些 Kubernetes 应用程序受到影响
• 哪些单独的组件被更新

时间轴还显示了服务或应用在整个部署过程中的整体健康状况。

使用 Codefresh，开发人员可以在几秒钟内回答他们每天遇到的问题。一些例子包括，比如：

1. 目前在 Staging 环境中部署了哪些 JIRA 功能特性？
2. 上星期四部署了版本 0.3.0 的是谁？它包含哪些源代码功能特性？
3. 当前 JIRA 功能特性 4524 部署在什么地方？它还没有部署到生产环境吗？
4. 创建并放置于 QA 环境中已有五周的 billing:v0.4.0 镜像的 CI 流水线是什么？
5. 我们是否知道在压力测试环境中部署的工件存在任何关键漏洞？
6. 目前有多少开发人员刚刚将他们的功能推送至 QA？
7. 刚刚进入生产环境的 Pull Request 2345 是谁批准的？

如果你只有 Argo CD，解决这些问题可能需要很长时间（有时甚至需要几个小时）。使用 Codefresh，开发人员可以更轻松地理解和分析任何部署，并迅速掌握任何活跃应用的整体情况。

第三阶段 — 在不同环境间推广应用

在每个应用程序的初始部署完成之后，接下来就是让应用程序从一个环境迁移或部署到另一个环境。

不幸的是，开源版本的 Argo CD 无法处理推广相关事务。Argo CD 不理解“环境”的概念，对推广一无所知。这迫使使用 Argo CD 的人不得不自己想办法解决推广问题。

这里的一个经典模式是应用程序的“特定”命名，以及在应用程序名称里硬编码（将特定的环境信息直接写入）“环境”：

在这里，这3个Argo CD应用被命名为一个特殊的模式，以适应“环境”的要求。虽然对人类用户来说很清楚这是同一个应用在三个不同环境中部署，但对Argo CD来说，它完全是3个互不相关联的应用，彼此之间没有任何联系。

Codefresh 完全支持这样做：将多个应用程序分组（在产品中）以及正确地进行环境建模的方式（建模环境）。

Codefresh 环境可以是一个不同的命名空间、集群，或者不同集群中的多个命名空间。你可以将任何集群/命名空间的组合标记为一个环境。然后 Codefresh 可以在后台将应用和环境关联起来进行推理。在上述示例中，尽管这些底层应用仍然名为“accounts-qa、account-staging、accounts-production”，Codefresh 知道 这是同一个应用——accounts——已部署到三个不同的环境中。

除了环境支持外，Codefresh 还可以将 CI 阶段的信息汇集到环境之中（如前一节所述）。这意味着与 Argo CD 不同，它只知道容器镜像版本，而 Codefresh 可以将其他元数据关联到环境，比如源代码提交、拉取请求、安全扫描等信息。

这里是环境仪表盘的另一个视角，现在也加入了 JIRA 的数据：

使用此仪表板，开发人员可以快速了解他们的 GitOps 环境，并回答关于 功能 的问题，而仅使用 Argo CD 是无法做到这一点的。

当然，重点功能是环境之间的升级。由于 Codefresh 拥有每个应用程序部署到哪个环境的上下文信息，这种升级操作是 Codefresh GitOps 平台的核心功能。

在最简单的情况下，你可以让开发人员通过拖拽来推广应用。Codefresh 会自动生成一个包含所有必要信息的提交记录，以便执行推广。

在更复杂的情境中，你可以定义一个带有特定限制和检查的完整推广流程，而在普通的 Argo CD 中无法做到。

在上面的截图中，我们定义了一个基本的推广政策，涉及4个环境。新应用只能部署到“dev”环境。通过了“dev”环境中的检查后，它们可以并行地转移到“staging”和“qa”。只有当所有检查在“staging”和“qa”都通过后，应用才能进入生产环境部署。

这个推广政策的好处在于你可以定义任何前置或后置的任何验证并强制执行这些验证。这些验证可以包括安全扫描、冒烟测试、数据库检查等。

如果检查失败，晋升就会被冻结：

在这个示例中，“staging”阶段的检查成功了，但在“qa”阶段出了问题。这意味着开发人员无法将代码推送到生产环境，直到“qa”阶段的问题解决。你可以使用Codefresh友好的界面了解具体的问题，并深入查看日志信息。

总的来说，在环境和部署方面，普通的 Argo CD 帮不了你忙。

Codefresh的功能非常重要，因为开发人员总是考虑环境和部署的问题。

第四阶段 — 企业特性

在解决了基本功能之后，我们终于可以看看企业扩展时需要的所有功能了。

通常，组织最初只是使用 Argo CD，很快便发现需要其他功能，比如内置流水线和渐进式交付（蓝绿金丝雀部署）。这时，他们会选择手动安装 Argo Workflows 和 Argo Rollouts。之后，他们需要花费额外的时间来集成这些产品。

虽然 Argo 项目设计上可以协同工作，但将它们整合到一个单一集群中却是一个复杂的过程。举个例子，Argo Workflows 和 Argo CD 使用不同的单点登录机制，而 Argo Rollouts 完全不支持单点登录功能。

Codefresh 自带此集成，开箱即用。Codefresh 运行时是一个统一的安装包，内置了全部 4 个 Argo 项目，并已应用安全补丁。

我们前面第一部分提到的统一的集成仪表板也适用于其他 Argo 项目。例如，如果你使用 Codefresh 运行时，你就可以获得这 4 个项目免费的 SSO 支持，无需额外操作。

这里是一个从 Codefresh 界面的应用程序中使用渐进式交付的示例。

同时，值得一提的是，Codefresh 提供了几个企业级特性，这些特性需要相当大的努力才能实现，仅使用 Argo CD。由于 Codefresh 对 CI 和 CD 流程发生的所有情况都有全面的可见性，因此 DORA 指标始终可以从 Codefresh UI 中直接获取，无需配置。

最后，你可以找到几个揭示你部署过程中瓶颈环节的统计数据和见解。不过，如果你只用 Argo CD，还是需要手动创建这些统计数据和见解。

这只是一个Codefresh提供的额外企业功能的概览。还有其他一些功能，比如给容器镜像添加额外的元数据。

图像和部署的关联也支持开箱即用，使用Codefresh。

通常，开发人员需要知道特定图片的部署位置。使用Codefresh来回答这个问题只需几秒钟。仅使用Argo CD回答可能需要数小时，这取决于应用的复杂程度。

结论

我们已经了解了 GitOps 成熟度的 4 个阶段，并在每个 GitOps 阶段解释了 Argo CD 提供的内容以及 Codefresh 提供的更多特性。

现在应该已经很明显，Argo CD 作为同步引擎确实很棒，但缺少企业进行有效部署所需的一些功能。使用 Codefresh，你将获得一个包含所有缺失功能的完整企业级平台，同时仍在底层使用 Argo CD。

代码新鲜平台实际上是所有4个Argo项目的超集，并且在以下方面提供了更多的功能，例如：

1. 初始安装
2. 应用部署与CI流程的关联
3. 从初始提交到生产环境的源代码改动全程追踪
4. 环境升级和开发人员的安全措施的创建
5. 企业安全与支持
6. 部署统计、DORA指标和应用监测

现在开始使用 Codefresh GitOps 平台，立即注册账号，或预约演示会议。立即注册，或 预约演示。