开篇
本期视频，我们来动手自建一个应用，模拟实际的场景。通过这个场景模拟，各位可以感受到真正生产环境中应该怎样使用 ArgoCD。我们的项目托管在 Github，留作给大家作为参考材料。
argocd in action[1]
配套视频
flask demo
flask demo 目录用来模拟代码仓库，它是一个典型极简的 Flask 项目，主要功能就是输出数据库连接的环境变量到前端页面。
注：此处仅模拟功能，实际生产环境这么操作会被拉去祭天。
代码语言：javascript复制.
├── Dockerfile
├── Makefile
├── app.py
└── requirements.txt
我们可以通过 make image 命令在本地 build 一个镜像。我已经打包好一个镜像：364950776/flask-demo:latest
kustomize
kustomize 目录用来编写应用的配置清单，同样的，这也是一个典型极简的 kustomize 支持的配置目录。
具体 kustomize 的用法此处不再赘述，值得一提的是，deployment 中的环境变量，是通过 configMapGenerator 注入的。这是 kustomize 的一个特性，环境变量都存储在 envs.yaml 中。
代码语言：javascript复制.
├── deployment.yaml
├── envs.yaml
├── kustomization.yaml
├── namespace.yaml
└── service.yaml
添加代码仓库
注: 由于我们 github 中代码仓库是开放的，只需要添加地址即可，如果是私有仓库，需要额外添加认证信息。
部署自建应用
部署应用非常简单，在 UI 界面上填写配置即可。
发现问题
问题 1
业务源码和部署清单在同一仓库，职能权限不够清晰。源码是开发团队关心的，而部署是运维团队关注的。提交记录混淆在一起，审计困难。
所以 ArgoCD 官方强烈建议，业务源码和部署清单，分两个仓库存储。
问题 2
业务源码和部署清单，分两个仓库存储。每次源码发布新版本，开发人员都要手动打包镜像，再通知运维修改部署清单中的镜像，最后运维登录 ArgoCD 界面同步应用状态。
这个操作完全没效率可言，有没有自动方案，把上述过程全自动化完成。
结束语
虽然我们顺利地完成了对自建应用的 gitops 实验，但这并不是最佳实践，仍然有两个问题需要我们解决。下节课，咱们就来解决这两个问题。
参考资料
[1]
argocd in action: https://github.com/pyfs/argocd-in-action
