Argo CD 实践教程 06

3.4 计划灾难恢复

Argo CD不直接使用任何数据库（Redis被用作缓存），所以它看起来没有任何状态。之前，我们看到了如何实现高可用性的安装，主要是通过增加每个部署的副本数量来完成的。但是，我们也有应用程序定义（如Git源集群和目标集群），以及关于如何访问Kubernetes集群或如何连接到私有Git回购或私有帮助集群的详细信息。这些东西构成了Argo CD的状态，它们保存在Kubernetes资源中——要么是本地资源，比如连接细节的秘密，要么是应用程序和应用程序约束的自定义资源。
灾难可能会由于人工干预而发生，例如Kubernetes集群或Argo CD名称空间正在被删除，或者可能是一些云提供商出现的问题。我们也可能有要将Argo CD安装从一个集群移动到另一个集群的场景。例如，也许当前的集群是用我们不想再支持的技术创建的，比如kubeadm（https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/），现在我们想转移到云提供商管理的技术。
你可能会出现在脑海中：“但我认为这是GitOps，所以一切都保存在Git回购中，这意味着它很容易重新创建？”首先，并不是所有的东西都被保存到Git回购中。例如，当在Argo CD中注册一个新集群时，我们必须运行一个命令，使这些详细信息不在Git中（出于安全原因，这是可以的）。其次，重新创建GitOps回购中的一切可能需要很多时间——可能有数千个应用程序、数百个集群和成千上万的Git回购。更好的选择可能是从备份中恢复到以前的所有资源，而不是从头开始重新创建所有的资源；这样做要快得多。

3.4.1 安装CLI

Argo CD提供了主CLI（argocd管理子命令）的实用程序部分，可用于创建备份（导出所有相关数据）到YAML文件或从现有文件导入数据。该CLI可以在主Docker映像中找到，也可以单独安装。
要安装v2.1.1CLI版本，请运行以下命令（这是macOS版本；对于其他选项，请检查官方页面：https://argo-cd.readthedocs.io/en/stable/cli_installation/ ）：

curl -sSL -o /usr/local/bin/argocd https://github.com/argoproj/
argo-cd/releases/download/v2.1.1/argocd-darwin-amd64
chmod +x /usr/local/bin/argocd
argocd version --client

如果一切正常，那么前面命令的输出应该显示Argo CD客户端版本，比如：

argocd: v2.1.1+aab9542
 BuildDate: 2021-08-25T15:14:05Z
 GitCommit: aab9542f8b3354f0940945c4295b67622f0af296
 GitTreeState: clean
 GoVersion: go1.16.5
 Compiler: gc
 Platform: darwin/amd64

** **现在我们已经安装了CLI，我们可以使用它来创建备份。

3.4.2 创建备份

现在，我们可以连接到群集并创建备份。你应该连接到已安装了Argo CD的集群（用于指向集群的kube上下文）。运行以下命令，该命令将基于当前日期和时间创建一个具有自定义名称的文件（这样，你可以每天甚至更频繁地运行它）：

argocd admin export -n argocd > backup-$(date +"%Y-%m-
%d_%H:%M").yml

** **即使我们只安装了一个简单的应用程序（Argo CD本身），你也可以看到备份是一个相当大的文件（它应该包含近1000行）。这也是因为Argo CD应用程序是一个相当大的应用程序（我们部署了许多资源），它保存了它同步的所有历史。你将在ch03/灾难恢复文件夹中的Git存储库（https://github.com/PacktPublishing/ArgoCD-in-Practice）中找到我为HA安装生成的备份文件。
接下来，我们应该将此备份文件并保存在云存储系统中（如AWS S3、Azure Blob或谷歌云存储），对其进行加密，并围绕其有访问策略。这是因为，对于一个真正的安装，许多敏感的信息将被存储在那里，包括对你的生产Kubernetes 集群的访问。

3.4.3 在不同集群上恢复

要恢复备份，你需要在目标集群中安装Argo CD。这是因为，在备份中，我们有它的配置，以及所有的配置映射和秘密，所以我们为初始安装所更改的一切都应该存在。但是，备份不会存储实际的部署或状态集。这意味着需要在恢复备份之前安装它们。自定义资源的定义也是如此——我们将有所有的应用程序和应用程序项目的实例，但我们将不会有这些自定义资源的定义。
因此，在新的集群中，执行与之前使用Kustomize部分的HA安装中相同的安装。然后，运行以下命令（你需要更改文件名，使其与你的命令匹配）：

 argocd admin import - < backup-2021-09-15_18:16.yml

现在，你应该有一个新的安装，其中包含了你在创建备份时所拥有的所有状态（应用程序、集群和Git回购）。唯一的区别是，现在Redis缓存中没有任何，所以Argo CD需要开始重新计算Git回购的所有清单，这可能会影响系统最初几分钟的性能。在那之后，一切都应该照常进行。
在本节中，我们看到Argo CD工具很容易自动执行，从创建常规备份到在新创建的集群上恢复它们。有一个备份策略和不时地做恢复练习是很重要的。我们应该为灾难发生时做好准备，并有必要的运行手册，这样我们就可以执行相同的结果，无论是凌晨2点还是下午2点。灾难是罕见的，所以我们在日常操作中会遇到很多情况。这可能是同步的应用程序数量增加，或YAML模板工具的特定版本导致超时甚至系统无响应。为此，我们需要有一个很好的可观察性策略。我们将在下一节中探讨这一问题。

3.5 启用可观察性

可观察性很重要，因为它可以提供关于系统的运行状况、性能和行为的答案。当你在一个大型的应用程序中工作，几十个团队将他们的单体和微服务部署到库伯内特时，很有可能事情并不总是像你所期望的那样顺利。总是有一些错误的设置，一个旧版本，不应该使用，不可变字段试图更新，许多应用程序需要同步同时，一个团队试图使用私人回购没有设置SSH键，或可能导致大型应用程序超时。
幸运的是，Argo CD公开了许多指标，允许我们理解系统，它是否被充分利用或过度利用，以及如何处理它。它还为我们提供了一些方法，可以在同步失败时直接提醒负责开发团队特定应用程序的问题。我们将创建的警报可以分为两个方向：一个是负责操作Argo CD的团队，另一个是负责处理微服务的团队。
在本节中，我们将学习如何使用Prometheus监控Argo CD，这已经成为监控动态环境的默认选择，例如在库伯内特斯上的容器中运行的微服务。普罗米修斯，因为它专注于可靠性，是找出系统当前状态和容易识别可能的问题的最佳工具之一。

3.5.1使用Prometheus进行监视

就像Kubernetes 成为了容器编排的标准一样， Prometheus也成为了监控的标准。这是第二个进入云本地计算基金会（CNCF）的项目，Kubernetes是第一个。在云原生世界中，我们有一个在Kubernetes中运行Prometheus的操作符（就像Argo CD是GitOps的操作符一样），叫做Prometheus操作符（https://prometheus-operator.dev/）。Argo CD组件以Prometheus格式公开度量，这使得在集群中安装Prometheus操作符并开始抓取这些端点很容易。有一个帮助图表，你可以用来安装它（通常，这是在一个称为监视的单独的名称空间中完成的）：https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack。
安装完成后，我们将需要告诉Prometheus，它可以在哪里找到公开度量的端点。为此，我们可以使用自定义的服务监视器资源（https://prometheus-operator.dev/docs/operator/design/#servicemonitor）。应该删除三个服务——一个用于应用程序控制器，一个用于API服务器，另一个用于存储库服务器——从而覆盖了所有的Argo CD组件。你可以在https://argo-cd.readthedocs.io/en/stable/operator-manual/metrics/#prometheus-operator的官方文档中找到服务监视器资源。我们还在ch03/服务器文件夹中的Git存储库（https://github.com/PacktPublishing/ArgoCD-in-Practice）中保存了它们的一个副本。
你可以通过将文件放在Git存储库中的文件夹中，然后创建一个指向它的应用程序，以便可以使用GitOps应用它们。
在我们有了服务监视器资源并抓取过程开始之后，有一个Grafana仪表板（https://grafana.com/grafana/dashboards），在https://argo-cd.readthedocs.io/en/stable/operator-manual/metrics/#dashboards，你可以使用它。请遵循有关如何导入仪表板的官方文档，看看如何将其添加到你自己的Prometheus操作员安装： https://grafana.com/docs/grafana/latest/ dashboards/export-import/#import-dashboard。我们将从两个不同的角度涵盖监控——一个用于负责Argo CD的团队，我们称之为运营团队，另一个用于团队构建应用程序，我们称之为微服务团队。

3.5.2 针对运营团队的指标

若要执行同步，Argo CD将使用存储库服务器和控制器。这些是我们需要监控的最重要的部分，好好照顾它们将使我们有一个良好的、高性能的系统。各种指标可以帮助我们理解他们的行为。所以，让我们来探索其中的一些。
_OOMKilled _
_ _ 随着时间的推移，我们意识到这两个组件最有价值的度量不是Argo CD公开的东西，而是节点OS在试图使用过多资源的容器上执行的内存不足（OOM）杀死。这是一个很好的指标，指示你设置的容器资源是否不够，或者你使用了一个对于并行性来说太大的参数。Argo CD文档提供了一个很好的解释，说明何时可以发生OOM，以及使用哪些参数来减少并行性：https://argo-cd.readthedocs.io/en/stable/operator-manual/high_availability/ .对于存储库服务器，同时生成了太多的清单，而对于应用程序控制器，同时应用了太多的清单。
你可以使用以下查询来获取有关这些事件的警报。它检查容器是否在过去5分钟内重新启动，以及最后终止的原因是否是OOMKilled（这个查询来自这个旧的和有价值的kubernetes线程： https://github.com/kubernetes/kubernetes/issues/69676#issuecomment-455533596）：

sum by (pod, container, namespace) (kube_pod_container_
status_last_terminated_reason{reason="OOMKilled"}) * 
on (pod,container) group_left sum by (pod, container) 
(changes(kube_pod_container_status_restarts_total[5m])) > 0

如果你每周收到一到两次这样的警报，那可能不是那么糟糕，你可以再等几个星期，看看会发生什么。如果它们每天发生几次，无论是对于回购服务器或控制器，你都应该采取行动。以下是你可以做的一些事情:

增加部署/状态集的副本数量，以便当需要进行应用程序同步时，负载将扩展到更多的实例中。
为容器设置更多的CPU和内存资源。
降低存储库服务器的并行限制参数的值和控制器的并行限制参数的值。

OOM与控制器需要做多少工作来协调应用程序的状态有关。这意味着，如果你有几天没有部署，这种情况可能不会发生，而如果你同时开始同步许多应用程序，你可能会开始收到OOM警报。如果是这样，那么我们应该看到与我们在系统中定义的负载度量的相关性。接下来我们会看这些。
系统负载度量
** **有一些指标可以揭示系统的负载。在这里，我们将看一个与存储库服务器和一个与应用程序控制器相关的。
存储库服务器的任务是获取Git回购的内容，然后根据所使用的模板引擎创建清单。在它们创建了最终的清单之后，应用程序控制器将继续它们的工作。我们已经看到，同时使用太多的清单可能会导致OOM问题，但是当我们有很多请求获取Git存储库的内容时，会发生什么呢？在这种情况下，有一个名为argocd_repo_pending_request_total的度量（在普罗米修斯中，我们称之为度量），这取决于存储库服务器实例上挂决的请求数量。当然，这个数字应该尽可能接近于零，这表明当前的回购实例数量可以处理负载。然而，如果它在短时间内上升，这就不是一个问题。当很长一段时间内价值很大时，就会出现问题，所以这是你应该注意的。
注意——使用HPA缩放回购服务器
如果你已经在考虑基于这个指标使用HPA扩展回购服务器，请加入这个线程的讨论，因为它并不是那么容易：https://github.com/argoproj/argo-cd/issues/2559 。
在应用程序控制器方面，有另一个重要的显示系统负载的度量标准——即argocd_kubectl_exec_pending。这显示了在目标集群上将要执行的应用命令和身份验证命令的数量。最大数目可以等于 --kubectl-parallelism-limit 标志，因为这是多少并行线程可以在目标集群上启动命令。如果它在短时间内达到最大值，这就不是问题，但是当该值在较长时间内保持较大时，可能会出现花费大量时间的同步等问题。

3.5.3 针对微服务团队的指标

如果你试图应用平台团队为开发团队创建自助服务平台的想法，那么你应该允许开发团队监控、获取警报，并在他们的实时部署出现问题时采取行动。其中一种方法是允许他们为Argo CD应用程序设置警报，这些应用程序用于将其微服务带到生产阶段。有两个指标可以为开发团队提供价值。它可以用于同步状态，特别是在同步过程中出现故障时。另一种可以用于应用程序的运行状况状态，特别是降级状态，这意味着某个东西不能按预期运行。
应用程序同步状态
** **提醒同步状态非常有用，因此团队不需要注意UI或通过CLI运行常规命令，以查找新版本部署的状态。当你每周做几次时，尤其如此，更不用说你做得更频繁了。团队可以为他们管理的应用程序设置警报，以便如果他们无法同步Docker映像的新版本或他们对清单所做的其他更改，那么他们将收到警报。argocd_app_sync_total指标可用于此操作。
以下查询可用于提醒你有关在过去5分钟内已将其同步状态更改为“失败”的任何应用程序。该查询只查找来自argocd名称空间的应用程序，并以会计开始（会计团队会感兴趣）：

sum by (name) (changes(argocd_app_sync_total{phase="Failed", 
exported_namespace="argocd", name=~"accounting.*"}[5m]))>0

** **如果没有任何问题，我们就不应该得到任何结果。但是，如果我们确实得到了任何同步状态失败的应用程序，我们应该开始调查原因。
应用程序运行状况状态
** **运行状况状态与同步状态不同，因为它可以独立于同步进行修改。我们通常正在寻找一个退化状态，这发生时功能不正常，比如如果你要求三个副本状态集，但只有两个和运行而第三个仍然是初始化在很长一段时间后，或者它被终止，现在没有被安排，仍然未决。当应用程序在生产过程中运行时，这样的场景可以在任何时候发生，并且它与同步事件没有直接相关。跟踪它的度量标准是argocd_app_info。你可以使用以下查询来跟踪降级状态Argo CD应用程序从Argo CD名称空间如果名称开始刺激但它不结束应用程序（这可以是有用的中间应用程序由应用程序模式使用应用程序后缀：https://argo-cd.readthedocs.io/en/stable/operator-manual/cluster-bootstrapping/#app-of-apps-pattern ）：

argocd_app_info{health_status="Degraded",exported_
namespace="argocd",name=~"prod.*",name!~".*app"}

** **在结果中获取具有降级状态的应用程序明显表明，集群中的一些问题正在阻止应用程序正常运行，因此需要进行检查。
接下来，我们将学习如何通知用户有关在Argo CD中发生的事件，例如应用程序是否已成功部署。这可以通过不同的工具来实现。我们将看看那些特定于Argo CD的，比如Argo CD通知项目和内置到Argo CD中的自定义网络钩子。

3.6 通知最终用户

为了同步应用程序，Argo CD可以以两种不同的方式工作。首先，它可以手动工作，这样，对GitOps 的存储库新提交就不会产生任何直接影响，除非你通过CLI、使用UI或使用API调用手动触发同步。第二种模式，我认为是最常用的一种，是在推送到存储库后，Argo CD将开始自动协调集群状态，以便与我们声明的状态匹配。
执行状态更改的开发人员对和解的结果感兴趣——他们想知道他们的微服务是否正确运行，或者他们在新的配置或新的容器映像方面是否有一些问题。
之前，我们学习了如何使用普罗米修斯和Argo CD公开的应用程序运行状况和同步状态来监视同步进程。然而，还有另一种方法，我们可以通知开发团队，他们的微服务有一些失败，或者当一切进展完美时：ArgoCD通知项目。这是特别考虑到Argo CD的，可以为用户提供更多有用的细节。你可以在https://github.com/argoproj-labs/argocd-notifications.上了解更多关于Argo CD通知项目的信息。

3.6.1安装Argo CD Notifications

与Argo CD一样， Notifications项目可以通过三种不同的方式安装：通过帮助图表（https://github.com/argoproj/argo-helm/tree/master/charts/argocd-notifications），使用简单的清单（https://github.com/argoproj/argo-helm/tree/master/charts/argocd-notifications），或通过Kustomize 。我们将使用 Kustomize选项，并使用GitOps模式安装它。我们将构建的所有通知代码都可以在https://github.com/PacktPublishing/ArgoCD-in-Practice.git的ch03/notifications文件夹中找到。
在你用来安装Argo CD的同一回购中，创建一个名为notifications的新文件夹。在该文件夹中，创建一个名为kustomization.yaml的文件，并添加以下内容。如你所看到的，我们保持了相同的名称argocd空间；没有理由创建另一个应用程序，因为这不是一个独立的应用程序。但是，它需要一个Argo CD的实例来工作（换句话说，如果没有安装Argo CD，我们将不会有一个Argo CD Notifications的实例）：

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: argocd
bases:
 - github.com/argoproj-labs/argocd-notifications/manifests/
controller?ref=v1.1.1

你应该将文件提交到回购中，然后推送到远程，这样我们就可以创建应用程序文件。将此argocd-notifications-app.yaml命名，并这次将其放在顶部文件夹中（它应该与我们在本章前面创建Argo CD自管理时创建的argocd-app.yaml文件的级别相同）。下面是文件的内容（只需确保你用你自己的值替换路径和引用URL）：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
 name: argocd-notifications
spec:
 destination:
 namespace: argocd
 server: https://kubernetes.default.svc
 project: default
 source:
 path: ch03/notifications
 repoURL: https://github.com/PacktPublishing/ArgoCD-inPractice.git
 targetRevision: main
 syncPolicy:
 automated: {
    
    }

现在我们已经创建了该文件，我们需要使用以下命令来应用它（不要忘记提交并将其推送到你的回购中，以备将来参考）：

 kubectl apply -n argocd -f argocd-notifications-app.yaml

在应用它之后，你应该在集群中安装了由Argo CD安装的Argo CD通知应用程序。在UI中，它应该是这样的：

图3.2——Argo CD UI中的Argo CD通知应用程序
接下来，我们将学习如何从Argo CD Notifications中启动GitLab管道。这可以用来更新我们的应用程序在各种跟踪系统中的部署状态，并可以被视为关闭GitOps协调循环的一种方式。

3.6.2 启动管道

下面是Argo博客上的一篇好文章，它解释了如何设置正确的配置来通过电子邮件发送通知：https://blog.argoproj.io/notifications-for-argo-bb7338231604 。在官方文档中，有更多的通知服务的例子，如Slack（https://argocd-notifications.readthedocs.io/en/latest/services/slack/），微软团队(https://argocd-notifications.readthedocs。，电报(https://argocd-notifications.readthedocs.io/en/latest/services/telegram/)，以及其他一些人。关于如何使用网络钩子来设置GitHub提交的状态（https://argocd-notifications.readthedocs.io/en/latest/services/webhook/#set-github-commit-status）或自定义钩子来发布数据(https://argocd-notifications.readthedocs.io/en/latest/services/webhook/#set-github-commit-status).
一个管道的一个例子。GitLab现在越来越多地用于CI/CD，因为它允许管道以云原生的方式运行在容器上，它的Kubernetes运行器：https://docs.gitlab.com/runner/executors/kubernetes.html。对于我们的演示，我们将不会使用的Kubernetes遗嘱执行者；我们将使用GitLab提供的共享版本，它基于码头机器： https://docs.gitlab.com/runner/executors/docker_machine.html.我们正在创建的管道将在Kubernetes和Docker机器运行器上运行相同的管道。
首先，通过进入https://gitlab.com/users/sign_up，在GitLab上创建一个用户。一旦你建立并运行了帐户，就继续创建一个项目。在GitLab UI的右上角应该有一个新的项目按钮。在下一页中选择“创建空白项目”，之后你应该可以设置项目的名称。
在我的例子中，我将它命名为恢复-手动管道，并将该项目设置为公共项目，这样我就可以与所有人分享它。你可以根据自己的意愿进行设置：

图3.3——创建一个新的GitLab项目
一旦我们创建了项目，在添加任何代码之前，我们需要使用SSH密钥为Git存储库设置一个简单的身份验证方法。首先，转到右上角，找到右边的最后一个链接，然后点击它-你应该看到首选项菜单项。这将把你带到一个页面，在那里你有一个大的菜单在左边，包括一个SSH键条目。点击它将把你带到一个页面，在那里你可以添加你的SSH键（按照下面的屏幕截图中的步骤1、2和3到达SSH键页面）。这将会有一个链接来解释如何生成一个新的链接。创建它之后，可以将公共项粘贴到文本框中（不是私人的），给它一个标题，然后单击添加键：

图3.4——如何进入SSH密钥页面
现在我们有了正确的设置，我们可以克隆，拉，和推动我们的Git回购没有任何问题。
现在，回到我们的回购过程中，我们应该在本地克隆它，并在一个编辑器中打开它。我们将使用一个名为“更新-部署-状态”的作业来构建一个管道。它将使用一个阿尔卑斯的Docker图像，并将运行一个虚拟脚本，它将显示应用程序的名称、状态和由Argo CD应用的提交SHA。其想法是，这个作业可以做一些更改，例如为Git提交设置标记，或者在同步事件发生后在某些任务上放置生产标签。我们的是一个虚拟的一个来解释事件和管道之间的联系，但你的可以更高级。因此，在名为gitlab-ci.yml的自述文件.md文件附近创建一个新文件，并设置以下管道定义：

update-deploy-status:
 stage: .post
 script:
 - echo "Deploy status $APPLICATION_DEPLOY_STATUS for 
Application $APPLICATION_NAME on commit $APPLICATION_GIT_
COMMIT"
 image: alpine:3.14
 only:
 variables:
 - $APPLICATION_DEPLOY_STATUS
 - $APPLICATION_NAME
 - $APPLICATION_GIT_COMMIT

注-手动GitLab管道
手动启动可以使用需要运行作业的条件（请参见唯一：部分）。这也允许我们从GitLab UI启动管道，这是一个调试它的好方法。
接下来，我们将使用创建的.gitlab-ci.yml文件创建一个提交，并将其推到远程回购。在我们定义网络钩子之前，我们需要一种方法来验证对GitLab管道的Argo CD通知调用。我们将为此使用一个管道触发器令牌：https://docs.gitlab.com/ee/api/pipeline_triggers.html。我们将从GitLab的UI中创建它。在项目的主页上的左侧菜单中，有一个设置条目。单击它后，你将在其子菜单中看到CI/CD项。单击它将把你带到一个可以展开的页面，其中之一是管道触发器。在那里，你可以创建一个新的触发器；我命名为我的Argo CD通知网络钩子。单击添加触发器后，令牌将出现：

图3.5创建一个管道触发器-给它一个名称，然后单击添加触发器按钮
现在我们有了一个令牌，当我们想从Argo CD通知网络钩子启动管道时，我们可以使用它来进行身份验证。在管道触发器部分中，我们已经有了一个关于网络钩子应该是什么样子的例子——我们所需要做的就是用我们的配置来调整它。标记是我们刚刚创建的那个。在我们的例子中，REF_NAME是主要的分支。对于这些变量，我们将把它们填充到Argo CD通知模板中：

curl -X POST \ -F token=TOKEN \ -F "ref=REF_NAME" \ -F 
"variables[RUN_NIGHTLY_BUILD]=true" \ https://gitlab.com/api/
v4/projects/29851922/trigger/pipeline

对于接下来的几个步骤，我们可以遵循关于如何在Argo CD通知（https://argocd-notifications.readthedocs.io/en/stable/）。
我们需要修改 argocd-notifications-cm配置图，我们可以通过改变Git来实现。在我们安装Argo CD通知时创建的通知文件夹中，我们需要添加一个名为补丁的新文件夹。在此过程中，我们将添加一个名为argocd-notifications-cm.yaml的文件，在那里我们将定义触发器，何时发送网络钩子，以及网络钩子应该是什么样子，其中涉及到一个通知模板。我们将触发器称为同步器。当同步结果结束为成功、错误或失败时，我们将激活它，并将其链接到gitlab-webhook模板。接下来，模板链接到gitlab网络钩子，这显示一个HTTP邮政请求将发送所需的变量开始我们的工作，裁判设置为主要，以及身份验证令牌（你将需要设置为一个真正的值——你之前创建的）：

apiVersion: v1
kind: ConfigMap
metadata:
 name: argocd-notifications-cm
data:
 trigger.on-sync: |
 - when: app.status.operationState.phase in ['Succeeded', 
'Error', 'Failed']
 send: [gitlab-webhook]
 service.webhook.gitlab: |
 url: https://gitlab.com/api/v4/projects/29851922/trigger/
pipeline
 headers:
 - name: Content-Type
 value: multipart/form-data
 template.gitlab-webhook: |
 webhook:
 gitlab:
 method: POST
 body: ref=main&token=<token-goeshere>&variables[APPLICATION_DEPLOY_STATUS]={
    
    {.app.status.
sync.status}}&variables[APPLICATION_NAME]={
    
    {
    
    .app.metadata.
name}}&variables[APPLICATION_GIT_COMMIT]={
    
    {
    
    .app.status.
operationState.operation.sync.revision}}

我们需要在kustomization.yaml文件中的一个条目来引用这个新文件：

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: argocd
bases:
 - github.com/argoproj-labs/argocd-notifications/manifests/
controller?ref=v1.1.1
patchesStrategicMerge:
 - patches/argocd-notifications-cm.yaml

现在，创建提交，将其推到远程，并确保Argo CD应用程序已同步以包含我们的更改。我们现在应该准备好更新我们的一个应用程序自定义资源来订阅我们创建的网络钩子。在这种情况下，我们有Git中的应用程序，但它们并没有被Argo CD直接跟踪，所以如果我们更改它们，我们仍然需要手动应用它们。在第5章，Argo CD引导K8s集群中，我们将查看应用程序的模式，它允许我们在Git中存储所有的应用程序定义。但是现在，我们还可以手动执行这些小的更改。
之前，在ch03文件夹中，我们创建了一个argocd-app.yaml文件。在这里，我们将修改它，使它包括注释，将指定它与同步触发器订阅gitlab网络钩子（参见突出显示的代码）：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
 annotations:
 notifications.argoproj.io/subscribe.on-sync.gitlab: ""
 name: argocd
spec:
 destination:
 namespace: argocd
 server: https://kubernetes.default.svc
 project: default
 source:
 path: ch03/kustomize-installation
 repoURL: https://github.com/PacktPublishing/ArgoCD-inPractice.git
 targetRevision: main

我们需要使用以下命令手动应用此文件：

 kubectl apply -f argocd-app.yaml

输出应该如下：

 application.argoproj.io/argocd configured

这样，我们已经完成了所有的设置，以便我们在Argo CD应用程序上所做的每一次更改和同步都将在GitLab项目中启动一个管道。在这里，我们可以修改我们在本章前面讨论Argo CD自我管理时添加的argocd-cm配置图。在我们将更改推到远程之后，我们应该有一个管道，它提供了类似于以下内容的输出：

图3.6——由Argo CD通知启动的管道的GitLab作业输出
在本节中，我们进行了一个相当长的演示，其中我们创建了一个小型GitLab管道，其中有一个作业，当在Argo CD应用程序中发生失败或成功执行的同步时，会通过通知触发该作业。另一种选择是在执行新的提交时定期从管道查询应用程序同步状态，直到它到达我们等待的状态，然后必须执行我们需要的操作。这些通知允许我们接受GitOps的全部拉性，而不必创建使它看起来像推送方法的变通方法。

3.7 总结

我们通过安装Argo CD开始了这一章。我们选择了一个由云提供商管理的集群，因为我们需要更多的节点来试验HA部署。我们体验了Argo CD如何更新自己，以及如何对安装进行配置更改。虽然生产Kubernetes集群具有高度可用性，并且云提供商将为我们管理它，但仍然存在可能发生灾难的场景，因此我们需要有一个可工作的灾难恢复策略。我们看到了如何创建Argo CD状态的备份，然后在一个新的集群中恢复它。
可观察性是一个重要的主题，我们讨论了哪些度量可以用于监控Argo CD安装，从OOM容器重新启动到微服务团队需要注意的问题。最后，我们学习了如何将同步的结果链接到管道，以便一切都能实现自动化。
在下一章中，我们将发现如何使用Argo CD在AWS中引导一个新的Kubernetes集群，包括如何在新创建的集群中设置应用程序，如外部DNS和Istio。

3.8 深入阅读

要了解本章中介绍的更多主题，请查看以下资源：

Argo项目的官方博客（包括Argo CD和Argo组织的其他项目）：https://blog.argoproj.io。
对于HA安装，端口要跨节点（和可用性区域）分布也很重要。转到https://kubernetes.io/docs/concepts/scheduling-eviction/，看看这是如何通过节点亲和力来完成的。
与普罗米修斯的可观察性：https://prometheus.io/docs/introduction/ 。