Argo CD应用的更新和回滚

Argo CD是用于Kubernetes的声明式GitOps应用持续交付工具，相比于传统的DevOps应用持续交付模型，GitOps模型下的应用更新和回滚更加高效，那么在使用Argo CD更新、交付应用之前，让我们先简单了解一下GitOps持续交付模式。

图7-11 应用中Deployment子资源frontend的详细信息

接下来我们使用Argo CD系统以GitOps的发布方式完成一个应用的迭代更新。

2. 应用更新

下面我们把guestbook-aliyun和guestbook-idc应用从第1版本更新至第2版本。

在GitOps发布模型中，Git源仓库是应用更新的唯一事实来源，我们需要基于master分支创建分支feat/guestbook-v2，分别更新values.yaml和values-idc.yaml文件中的frontend.image.tag为v2，提交patch并创建拉取请求，最后合并至master分支，如图7-13所示。

图7-13 创建拉取请求然后合并至master分支

应用管理员对这个拉取请求进行安全审批（通常情况下，会配置不同的测试任务对新提交的代码进行基础检查，应用管理员会根据检查结果判断当前拉取请求是否可以合并至主分支），如果允许新版本应用配置更新到master分支中，则合并此请求，如图7-14所示。

图7-14 合并拉取请求

现在，我们回到Argo CD系统中的应用详情页面。以应用guestbook-aliyun为例，点击REFRESH按钮或者等待Argo CD定期检测（默认每3分钟检查一次）Git源仓库中的代码更新。检测Git源仓库更新之后，我们可以非常直观地观察到当前运行与实际环境中的应用Git版本为14afbac，而Git源仓库端最新的Git版本为f9c5a9d，这是因为当前应用的声明态与运行态不一致，所以应用状态也同步更新为OutOfSync，如图7-15所示。

图7-15 检测Git源仓库代码更新

在图7-15中我们也可以直观地看到，应用中的Deployment子资源frontend有更新，点击并查看其DIFF信息，可以进一步确认本次更新的内容是否符合预期，如图7-16所示。

图7-16 应用声明态与运行态的DIFF信息

因为我们在创建应用guestbook-aliyun时设置的同步部署策略为手动，所以需要手动点击SYNC和SYNCHRONIZE将变更部署至集群。部署成功后，Deployment frontend及其动态创建的子资源版本标识也同步更新为rev:2，应用状态更新为Synced，如图7-17所示。

图7-17 同步部署后的应用资源拓扑图

浏览器访问guestbook-aliyun确认其版本已更新为第2版本。

3. 应用回滚

下面我们把应用guestbook-aliyun的版本回滚到第1版本。点击HISTORY AND ROLLBACK即可查看到应用发布的历史版本（默认保留10个历史版本），如图7-18所示。

图7-18 guestbook-aliyun应用发布的历史版本

从图7-18可以看到，当前应用有2个历史版本，Git Revision分别为14afbac和f9c5a9d，在回滚的版本右侧点击ROLLBACK即触发回滚操作，如图7-19所示。

图7-19 执行回滚操作

回滚操作执行完毕后，应用状态将再次变更为OutOfSync，Deployment frontend更新为rev:3，如图7-20所示。

图7-20 回滚后的guestbook-aliyun应用

浏览器再次访问guestbook确认其应用版本已回滚为第1版本。