一、说在前面的话

上文已为我们准备好了以下内容：

• 制作java应用的docker镜像，并推送至镜像仓库
• 上传helm yaml代码至gitlab仓库（此gitlab和java应用所在的gitlab可以独立，也可以在一起，但是不宜在同一个工程，所以这里特此区分）
• 安装k8s和argocd
• argocd的权限设计和对接ldap(非必须)

本文先梳理出整个devops的设计框架，然后将演示java应用是如何在argocd中部署的，以及升级程序的版本号后，自动触发更新部署。

二、总体设计

• 这里的jenkins CI部分将交由下文继续展开，不属于本文的范畴
• 本文重点讲述argocd CD部分是如何部署的细节

三、argocd project

这里我采用的是default–默认组，在实际使用中，你需要创建多个project，用于隔离不同组里的人员其权限。
换句话说，你公司有5个业务组，那么就需要创建5个project。（这里不去翻译为中文，因为工程或者说项目，实在和我们实际的组不是很搭）

• 我理解的argocd中的project是指物理/虚拟组的概念，和权限是搭配使用的。给不同的人分配至不同的project，隔离不同组之间的权限。

四、 argocd cluster

因为我们把argocd部署在k8s，所以默认就有一个k8s可供部署应用。

你如果需要部署到其他k8s里，在这里再新增k8s的配置项即可。后面你在创建argocd 应用的时候就可以选择它。

五、argocd Repositories

这里的仓库，是指Helm yaml文件所存储的地方。前文我们已详细描述了如何制作并推送helm，本文就直接拿来使用，不再赘述。

gitlab的准备工作

把ssh密钥对的公钥存储在gitlab, 私钥保存在argocd。

正式创建argocd的仓库

下面的ssh private key data就是上图中的ssh私钥文件的内容。

返回仓库列表：

• 注意，你仓库的CONNECTION STATUS是Successful，说明授权成功。
• 接下里就是创建argocd 应用了。

六、argocd application

本文的重头戏了，前文所有的准备皆是为这一步做准备。

创建应用名称，选择所属的组，并设置自动部署还是手动部署

helm yaml和部署目标

yaml的部署方式

应用详情

创建好的应用见下

七、对argocd 应用的补充说明

• 应用中的参数覆盖，在详情界面，会有一个锤子状的图标以示区分。我这里要说的是，被覆盖的参数，只能手动修改后触发部署。像版本号等字段，是需要采用gitops技术来实现自动更新部署的，不要在argocd中进行参数覆盖，修改入口必须是在gitlab代码库。
  
• 查看应用的详情：yaml格式
  你查看MANIFEST内容，右上方点击“EDIT”即可修改。
  
• 同步策略详情见下：

  syncPolicy:
    automated:
      prune: true
      selfHeal: true
      allowEmpty: false
    syncOptions:
    - Validate=false
    - CreateNamespace=true
    - PruneProagationPolicy=foreground
    - PruneLast=true
    retry:
      limit: 5
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m

八、总结

每次更新部署的时候，你只要修改git工程里的devops-service/values.yaml中的版本号，argocd就会自动触发部署。

后文有jenkins这款CI工具后，如果要把CI和CD串联起来，做到自动化，只需要在jenkins里修改values.yaml文件中的版本号。这也就是gitops是思想，基于git代码的提交触发以前人工的操作。

本文把我在使用argocd的过程中遇到的坑都一一总结出来，希望后来者有个对照。

踩过的坑，最大就是在helm部署的时候，没有做到gitops，要么没有选择values.yaml文件，要么覆盖了不应该覆盖的参数–程序版本号。