手把手带你玩转ArgoCD --- 多环境管理

本文介绍如何使用ArgoCD进行多环境的管理，最终达到一个配置仓管理多套环境（dev、test、stg、prod）的目的。

一、环境

1. 四个腾讯云K8S集群，分别规划作为开发dev、测试test、预生产stg、生产prod环境

二、各自部署ArgoCD

我基于自管理的ArgoCD配置仓进行改造，Self Managed Argo CD请参考我的另一篇文章。

改造前的github上的项目仓库路径树： argocd/
├── argocd-appprojects # stores ArgoCD App Project's yaml files
├── argocd-apps # stores ArgoCD Application's yaml files
├── argocd-install # stores Argo CD installation files
│ ├── argo-cd # argo/argo-cd helm chart
│ └── values-override.yaml # custom values.yaml for argo-cd chart

改造后的项目仓库路径树：

values-override-prod.yaml改造如下（其他三个类似）：

## ArgoCD configuration
## Ref: https://github.com/argoproj/argo-cd
##
## Server
server:
  ## ArgoCD config
  ## reference https://github.com/argoproj/argo-cd/blob/master/docs/operator-manual/argocd-cm.yaml
  configEnabled: true
  rbacConfig:
    policy.default: role:readonly
    policy.csv: |
      p, applications, *, operation-prod/*, allow
  config:
    repositories: |
      - name: ops-devops
        type: git
        url: https://xxxxxx.git
        passwordSecret:
          key: password
          name: config-repo-secret
        usernameSecret:
          key: username
          name: config-repo-secret
        insecure: true
        insecureIgnoreHostKey: true
      - name: argo-helm
        type: helm
        url: https://argoproj.github.io/argo-helm
  additionalApplications: 
    - name: argocd
      namespace: argocd
      destination:
        namespace: argocd
        server: https://kubernetes.default.svc
      project: argocd
      source:
        helm:
          version: v3
          valueFiles:
          - values.yaml
          - ../values-override-prod.yaml
        path: argocd-install/argo-cd
        repoURL: https://xxxxxx.git
        targetRevision: HEAD
      syncPolicy:
        syncOptions:
        - CreateNamespace=true
    - name: argocd-apps-prod
      namespace: argocd
      destination:
        namespace: argocd
        server: https://kubernetes.default.svc
      project: argocd
      source:
        path: argocd-apps/prod
        repoURL: https://xxxxxx.git
        targetRevision: HEAD
        directory:
          recurse: true
          jsonnet: {}
      syncPolicy:
        automated:
          selfHeal: true
          prune: true
    - name: argocd-appprojects
      namespace: argocd
      destination:
        namespace: argocd
        server: https://kubernetes.default.svc
      project: argocd
      source:
        path: argocd-appprojects/prod
        repoURL: https://xxxxxx.git
        targetRevision: HEAD
        directory:
          recurse: true
          jsonnet: {}
      syncPolicy:
        automated:
          selfHeal: true
          prune: true
  additionalProjects: 
  - name: argocd
    namespace: argocd
    additionalLabels: {}
    additionalAnnotations: {}
    description: Argocd Project
    sourceRepos:
    - '*'
    destinations:
    - namespace: argocd
      server: https://kubernetes.default.svc    
    clusterResourceWhitelist:
    - group: '*'
      kind: '*'
    orphanedResources:
      warn: false

• repoURL: xxxxxx.git 是配置仓地址

我们本地用kubectl连接到不同的集群，然后分别执行下面的安装脚本，这样就在每一个集群上各自安装了一套自管理的ArgoCD。

helm install argocd ./argo-cd --namespace=argocd --create-namespace -f values-override-dev.yaml

helm install argocd ./argo-cd --namespace=argocd --create-namespace -f values-override-test.yaml

helm install argocd ./argo-cd --namespace=argocd --create-namespace -f values-override-stg.yaml

helm install argocd ./argo-cd --namespace=argocd --create-namespace -f values-override-prod.yaml

注意： values-override-xxx.yaml中的targetRevision: HEAD，指向的HEAD分支不一定是master分支，对应着gitlab上的default分支。

gitlab在如下位置进行配置：

三、多环境治理要诀

• 各自环境的project和app定义在argocd-appprojects和argocd-apps各自的环境文件夹（dev、test、stg、prod）下。

• 配置仓分支管理

方案	优势	劣势
master一个分支来管理多个环境，不同的环境对应master分支的多个路径下的配置	不要考虑繁琐的分支合并	开发调试时要很频繁的修改配置，一不小心就会影响生产环境
分支dev对应开发环境，test对应测试环境，stg对应预发环境，prod对应生产环境，	互不影响	配置仓代码不好维护，之间配置同步不好维护
分支dev对应开发，master一个分支来管理test，stg，prod三个环境

综合使用第三个方案，test，stg，prod三个相对稳定的环境统一使用master分支的不同路径进行管理，dev开发环境使用配置仓的dev分支进行管理。当使用dev分支测试ok后，开发者修改配置仓dev分支下test、stg或者prod路径下的配置，然后发起MR合并到master分支，经过审核后合入master分支才能进一步更新test、stg或者prod环境。

dev开发环境使用配置仓的dev分支进行管理，也就是需要将values-override-dev.yaml里修改 targetRevision: HEAD 为 targetRevision: dev。