【DevOps】GitOps多环境管理最佳实践 -- 多目录模式

前言

GitOps的多环境是一个棘手的问题，在前面的文章中，我们已经极力劝阻使用多分支的方式管理多个环境，以及环境之间的版本升级。在本文中，我们将详细介绍如何使用同一Git分支上的不同目录来建模GitOps的多环境管理，如何通过简单的文件复制操作来处理环境升级。

Helm/Kustomize的启示

在Kubernetes集群中，如果要说最流行的应用部署工具，那必定是helm了，其次还有kustomize。 首先来看helm, 在一个helm Chart中，会使用一个存有应用部署所需全部参数的values.yaml文件，来部署一个应用。如果有多个环境，由于每个环境的参数不同，因此需要多个values.yaml文件，例如：

my-chart/
├── Chart.yaml
├── charts/
├── environments/
│   ├── dev/
│   │   └── values.yaml
│   ├── prod/
│   │   └── values.yaml
│   └── staging/
│       └── values.yaml
├── templates/
│   ├── deployment.yaml
│   └── service.yaml
└── values.yaml

其中，应用主目录下的values.yaml存放各环境通用的参数值，而在environments目录下的三个以环境名命名的子目录下的values.yaml