一、说在前面的话
上文已为我们准备好了以下内容:
- 制作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文件,要么覆盖了不应该覆盖的参数–程序版本号。