GitOps有助于重新定义需要精确、自动化和透明性的环境中管理基础设施和应用部署的方式。
译自 Achieve GitOps on Day One with IaC Automation，作者 Rak Siva 是 Team Nitric 工程副总裁，致力于提升软件开发者的体验。在软件行业拥有丰富的15年任期中，他开始了在充满挑战的工程旅程中深度参与...
在我在金融科技和数字化入职领域的任职期间，我经历了三个不可小觑的挑战，它们不断地测试团队的韧性：
配置错误和不一致性： 配置漂移或在不同环境中的不一致性的后果可能是灾难性的。在面对监管审查和运营风险时，有信心地回滚到经过验证的状态成为一个紧迫的问题。 手动和容易出错的过程： 源自人为疏忽的错误，如配置错误、安全漏洞和昂贵的停机威胁，投下阴影，甚至在规划良好的项目中也是如此。 缺乏可见性和可审计性： 像“谁做了那个更改？何时？为什么？”这样的问题可能变成无法逃避的难题，阻碍我们满足合规要求并解决安全问题。
像Spotify这样的行业领导者已经利用GitOps的力量迎头解决这些行业特定的挑战，正如Tim Hansen在上个月的Kubecon North America大会上所描述的“一切皆代码 - 在Spotify拥抱GitOps”。GitOps不仅提供解决方案，还赋予我们重新定义在一个精确、自动化和透明性不仅仅是理念而且是成功基石的环境中如何管理基础设施和应用部署的力量。
GitOps是一种将git版本控制的强大功能与基础设施即代码（IaC）和持续交付（CD）实践相结合的方法论。在其核心，GitOps将您的基础设施和应用配置视为代码，并将它们存储在git存储库中。这个单一的真相源成为自动化部署和同步您的环境的基础。
有许多深入探讨GitOps的文章，我在下面总结了关键原则。您可以在这里了解更多关于GitOps和这些原则的信息。
- 声明式配置： GitOps依赖于声明式配置，您在其中定义基础设施和应用程序的期望状态。这意味着您描述您想要的内容，而不是如何实现，这有助于保持一致性并减少配置漂移。
- 版本控制： Git是GitOps的支柱。它提供版本控制、协作和审计功能。对基础设施或应用程序的每次更改都受到跟踪，这使得在需要时轻松回滚到先前状态成为可能。
- 持续交付： GitOps采用持续交付的原则，自动化部署过程。每当您对git存储库进行更改时，自动化流水线会启动以将这些更改应用到您的环境中。这减少了人为错误的风险，确保迅速、可靠的部署。
- 自动化： 工具和流程被制定出来，以自动将基础设施的实际状态与git存储库中的期望状态同步。日常操作无需手动干预。
实施GitOps流程简化了开发人员和运维团队的责任。开发人员主要专注于编写和提交代码，而运维团队则承担了维护和确保解决方案的供应和部署对于开发人员和运维人员而言始终是安全和可靠的关键角色。
开发人员受益于这种方法，因为他们可以集中精力于编写代码和改进应用程序的核心任务。他们无需关注基础设施供应或部署过程的复杂细节。他们的代码更改、配置和应用程序更新在git存储库中进行版本控制，使协作和跟踪更改变得简单明了。
运维团队在GitOps中扮演着至关重要的角色，确保在git存储库中指定的基础设施和部署配置保持一致并符合最佳实践。他们管理这些配置的自动化和编排，确保更新在各种环境（如开发、测试和生产）中安全而可靠地应用。这种方法增强了安全性，减少了人为错误，并为合规性和故障排除提供了清晰的审计路径。
拥抱GitOps通常需要从传统基础设施管理中改变思维。团队需要采用声明式、版本控制的方法来定义和管理基础设施，这可能与他们现有的实践有所不同。
来源：VMware
根据上图，与软件开发和部署过程相关的GitOps工作流中的几乎所有内容都存储在您的存储库中：
- 基础设施即代码（IaC）： 这涉及通过代码而不是手动流程管理和配置基础设施。它使团队能够将版本控制、协作、合规性和CI/CD实践应用于基础设施管理。
- 配置： 这些是控制应用程序和基础设施行为的设置和参数。在GitOps工作流中，配置是进行版本控制并与代码一同管理的，确保一致性和可追溯性。
- 应用程序代码： 这是正在开发的应用程序的实际代码。在GitOps中，应用程序代码存储在版本控制系统中，通常与IaC和配置一起维护，以确保对版本和更改采用统一的方法。
- CI/CD流水线： CI/CD流水线定义了从开发到生产的代码更改经历的自动化步骤。在GitOps中，这些流水线也被视为代码并进行版本控制，从而实现自动化、可重复和可靠的流程。
乍一看，这似乎足够简单，然而，在这些资产内部蕴藏着建立成功的GitOps工作流的真正挑战。例如，声明基础设施即代码固然带来了许多好处，包括版本控制和可重复性，但它也带来了一系列的挑战。
- 复杂性： 基础设施可能会很复杂，涉及虚拟机、网络、存储和安全策略等各种资源。编写代码来定义和管理这种复杂性可能会具有挑战性，特别是对于更大更复杂的环境而言。
- 学习曲线： 采用IaC通常需要团队成员学习新的语言（Terraform、AWS CloudFormation、Ansible）、工具和最佳实践。这个学习曲线可能会减缓初始实施的速度并导致错误。
- 测试和验证： 确保IaC模板按预期工作可能会很困难。在部署之前，需要进行全面的测试和验证过程，以捕获潜在问题。这包括单元测试、集成测试以及针对目标环境的验证。
- 基础设施漂移： 将IaC引入CI/CD流水线时，团队还必须处理漂移。漂移发生在应用程序要求开始偏离IaC代码中定义的状态时。
因此，对于那些在IaC方面挣扎或尚未完全拥抱IaC的团队，GitOps尤其具有挑战性。这可能是一个令人不安的过渡，但幸运的是，出现了一些方法，可以帮助实现GitOps而不拥抱IaC。
要自信地开始GitOps之旅，关键是尽可能简化过程。可以通过使用自动化和抽象框架来实现这一点，这些框架可以解决与IaC相关的问题。
比较以下的图表与上面显示的图表。该流程通过使用自动化框架来解决先前提出的一些问题，消除了最初手工制作的某些资产。在本例中，我们使用我们的开源 Nitric Framework；其他工具也可以用于自动化该流程的部分。
- 本地开发和版本控制： 开发人员首先在模拟云基础设施的本地环境中搭建项目并编写应用程序代码。这种方法使他们能够离线迭代和测试代码。更改将提交到版本控制存储库，开发人员决定何时将其部署到云中。
- CI/CD流水线和Nitric框架： 当应用程序准备好进入更高的环境（如暂存或生产）时，与Nitric框架集成的CI/CD流水线从应用程序代码中推断出必要的云基础设施需求。它生成一个资源规范，充当基础设施的真实来源，并可进行版本控制以供审计。
- 基础设施同步： Nitric框架使用资源规范来确定并部署所需的基础设施组件到云提供商。该过程确保基础设施始终与应用程序代码同步，消除了每次CI/CD流水线运行时配置漂移的可能性。
- 运维团队的角色： 尽管手工制作基础设施即代码的需求降低了，运维团队仍然发挥着关键的作用。他们负责实施满足应用程序需求的基础设施提供者，如规模和可用性。
这种方法简化了产品开发周期，缩短了上市时间，并促进了开发人员与运维团队之间的协作环境。它有效地平衡了自动化与控制，确保基础设施变更既高效又得到良好管理。
构建和部署应用程序代码的前景可能看起来令人生畏。通过利用现代基础设施即代码自动化工具的力量，并采用 GitOps 方法，企业可以找到一条从开发到生产的无缝路径。
自动化框架像 Nitric 这样专注于简化工作流程中耗时的手动步骤，从而使您能够从第一天开始使用 GitOps 工作流程构建和发布应用程序。
对于那些对进一步探索这种方法感兴趣的人，请考虑深入了解 Nitric。