一、说在前面的话
上文已为我们准备好了以下内容：
- 制作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: trueselfHeal: trueallowEmpty: falsesyncOptions:- Validate=false- CreateNamespace=true- PruneProagationPolicy=foreground- PruneLast=trueretry:limit: 5backoff:duration: 5sfactor: 2maxDuration: 3m
八、总结
每次更新部署的时候，你只要修改git工程里的devops-service/values.yaml中的版本号，argocd就会自动触发部署。
后文有jenkins这款CI工具后，如果要把CI和CD串联起来，做到自动化，只需要在jenkins里修改values.yaml文件中的版本号。这也就是gitops是思想，基于git代码的提交触发以前人工的操作。
本文把我在使用argocd的过程中遇到的坑都一一总结出来，希望后来者有个对照。
踩过的坑，最大就是在helm部署的时候，没有做到gitops，要么没有选择values.yaml文件，要么覆盖了不应该覆盖的参数–程序版本号。
