生产环境中的GitOps

在现实世界中的日常操作可能是复杂的。例如，如何处理应用于环境的破坏性更改？错误的更改会破坏裸机服务器，从而导致数据丢失和IP更改。GitOps如何处理不同的环境（如开发、阶段或生产）？你如何促进舞台和生产的变化？
在本节中，我们将解决这些问题，并讨论如何将GitOps应用于实际操作。

云资源生命周期

在许多情况下，GitOps可以很好地与Kubernetes集群一起工作，因为它自然支持声明性部署和不可变的基础结构。然而，现实世界的云基础设施可能是复杂的，混合云可以包括许多不同的资源，如裸机、经典VSI、网络设备、云数据库服务、Kubernetes集群和容器。
每种类型的资源都有自己的生命周期。假设您有一个构建在多个VSI之上的Kubernetes集群，并且部署为容器的云原生应用程序具有最短的生命周期。群集的生命周期可能比VSI长，因为群集的工作节点随时间变化。裸机服务器的生命周期最长。

由于存在不同的资源生命周期，因此无法通过单个CI/CD管道或单个操作工作流处理针对整个堆栈的所有更改。在将GitOps实践应用于全栈云资源时，您需要使用不同的策略。

可变与不变

GitOps鼓励您使用不可变的基础设施和声明性容器，这意味着在部署之后，不能对基础设施或云原生应用程序进行任何更改。Kubernetes采取不可变的容器。
但是，假设您在资源有限的情况下将应用程序部署在经典基础结构之上，并且它的生命周期仍然很长。在这种情况下，仍然可以利用GitOps方法来管理基础设施，以利用GitOps的优势，例如随着时间的推移而进行的版本更改和改进的安全性。

基于推的部署与基于拉的部署

尽管基于拉的部署是可以确保更好安全性的GitOps最佳实践，但GitOps采用者并不需要使用基于拉的部署。然而，在某些情况下，并不是所有的东西都可以使用声明性配置来描述，并且没有使用基于推送的部署的选项–例如，使用Jenkins、Travis或Ansible等工具来提供云基础设施。

对多种环境的支持

上面的描述主要描述了GitOps如何在单个环境下工作。然而，在实际的云环境中（如DevOps)，通常有多个环境来支持开发、测试和生产场景。
下图是一个参考模型，说明了GitOps如何与开发、阶段和生产环境一起工作：

一个典型的策略是为系统设置开发、阶段和生产环境。使用GitOps，您可以在声明性配置存储库中设置相应的分支，以便所有三个环境共享相同的配置存储库。对于每个环境，都有一个GitOps代理（一个或多个–参见参考体系结构一节），它从临时分支中提取更改。例如，开发环境监视并从开发分支提取更改，而暂存环境从暂存分支提取更改。
Git工作流的设置是为了支持代码审查、批准、合并和测试。在开发环境拉出更改并通过集成测试之后，可以通过在暂存上创建新的拉出请求将相同的更改提升到暂存分支。通过执行类似的过程，开发人员或SRE所做的更改最终可以由生产环境拉动。
注意，这个过程只是一个参考模型。在实际情况中，项目团队可以根据为实际情况做出的体系结构决策来调整这一点。

参考体系结构

根据您所学的知识，您还可以定义一个高级参考体系结构来将GitOps实践应用到IBM云环境中。这看起来类似于GitOps概述中显示的体系结构，但这里的主要区别是基于现实世界的情况。在下图中，我们已经将组件映射到一个建议的软件实例。

最重要的是，这种体系结构将CaaS和IaaS层的CD进程分开，因为它们可能具有非常不同的资源和生命周期。根据资源的性质，对不同的资源使用不同的工具。更具体地说，我们建议在Red Hat OpenShift实例上安装GitOps插件。这将提供一个开箱即用的Argo CD实例，以扮演GitOps代理角色，在CaaS层部署更改。在IaaS层上，IBM Cloud Schematics服务通过封装用于IBM Cloud的Terraform插件来实现GitOps实践，该插件将对基础设施进行更改并提供/更新大部分IBM Cloud资源。

总结

了解了GitOps的原则、GitOps提供的优点以及一些通过真实世界的示例说明的最佳实践。GitOps不仅可以应用于基于容器的App，还可以应用于全栈的云资源。通过精心设计的自动化流程，它还可以支持在多个环境中促进更改的开发和操作。
GitOps是在云上使用DevOps的一种改进方法，但它不能解决所有的挑战。也就是说，GitOps应该被用作云DevOps工具箱中的一个有用工具。