❤️💕💕新时代拥抱云原生，云原生具有环境统一、按需付费、即开即用、稳定性强特点。Myblog:http://nsddd.top
[TOC]
上面我们经历了两个大的阶段，我们从开始学习 GitOps 开始，到 GitOps 的高级部分。
我们到现在，开始正式的实践 GitOps 的，以我们自己的企业生产级别项目 OpenIM 为例开始。
我们主要是 以 ArgoCD 以及 Jenkins X 还有 Flux 来实践。
Argo CD是Kubernetes的一个开源GitOps操作符。该项目是Argo系列的一部分，Argo系列是一套用于在Kubernetes上运行和管理作业和应用程序的云原生工具。Argo CD与Argo Workflows、Roll out和Events一样，侧重于应用程序交付用例，并使三种计算模式（服务、工作流和基于事件的处理）的组合变得更加容易。在2020年，Argo CD被云原生计算基金会（CNCF）接纳为孵化级托管项目。
Argo CD 背后的公司是 Intuit ，在 2018 年，Intuit 决定用 Kubernetes 来加速云迁移，当时市面上有几款成功的 Kubernetes 部署工具，但是没有一个完全符合 Intuit 需求，于是投入研究 ArgoCD。
Intuit 是一个基于云的软件及服务（SaaS）公司，拥有大约 5000 名开发人员，已经成功在本地和云端运行了数百个微服务。鉴于这种规模，指望各个团队都运行自己的 Kubernetes 集群是不合理的，相反，由一个集中的平台团队为整个公司的运行和维护一组多租户集群的决策显然会更加合适。所以考虑了如下要求：
- 有效的服务：不要求每一个 team 安装和维护 deployment operator，由集中式团队提供。
- 支持多租户和多集群管理：在多租户的环境中，用户需要一个有效且灵活的访问控制系统。Kubernetes 内置了一个很棒的角色访问控制系统，但是当你面对数百个集群的时候，还是不够
- 支持可观测性：持续部署工具应为开发人员提供托管应用程序状态有关的洞察，一个用户友好的交互方式，理应快速回答以下的问题：
- 应用程序配置中是否与 Git 中定义的配置同步
- 究竟是什么不匹配
- 应用程序是否已经启动并且正在运行
- 究竟是什么出现了故障
Intuit 需要找到匹配其企业规模的 GitOps Operator ，评估后决定自己实现了 ArgoCD
为了有效地使用ArgoCD，我们应该了解两个基本概念：应用程序(Application) 和项目(project)。让我们先仔细看看这个应用程序。
应用程序应用程序提供了Kubernetes资源的逻辑分组，并定义了资源清单的源和目标。
Argo CD应用程序的主要属性是源和目标。源指定了资源清单在Git仓库中的位置。目标指定在Kubernetes群集中应在何处创建资源。
Application源代码包括存储库URL和存储库中的目录。通常存储库包括多个目录，每个应用程序环境（如QA和Prod）都有一个目录。
- Prod: deployment.yaml
- qa: deployment.yaml
每个目录不一定包含纯YAML文件。Argo CD不强制执行任何配置管理工具，而是为各种配置管理工具提供一流的支持。因此，目录可能包含一个Helm图定义为YAML以及Kustomize覆盖图。Application destination定义资源必须部署的位置，并包含目标的API服务器URLKubernetes集群，以及集群名称Namespace。API服务器URL标识必须在其中部署所有应用程序清单的群集。跨多个集群部署应用程序清单是不可能的，但是可以将不同的应用程序部署到不同的集群中。Namespace名称用于标识所有Namespace级应用程序资源的目标Namespace。因此，argo cd应用程序表示部署在kuberne-tes集群中的环境，并将其连接到存储在git存储库中的所需状态。
除了源和目标之外，ArgoCD Application 还有两个更重要的属性：同步状态和健康状态。
同步状态会回答观察到的应用资源状态是否偏离存储在Git资源库中的资源状态。偏差计算背后的逻辑等价于kubectl diff命令的逻辑。同步状态的可能值为in sync和out sync。in-sync状态意味着找到每个应用程序资源并与预期的资源状态完全匹配。不同步状态表示至少有一个资源状态与预期状态不匹配或在目标群集中找不到。
健康状态集合了关于组成应用程序的每个资源的观察到的健康状态的信息。每种Kubernetes资源类型的运行状况评估逻辑都不同，并会产生以下值之一:
- 健康状态&例如，如果所需数量的Pod正在运行，并且每个Pod都成功通过就绪性和活动性探测，则认为Kubernetes部署处于健康状态。
- 进展-表示尚未健康但仍有望达到健康状态的资源。如果部署尚不健康，但仍没有progressing-DeadlineSeconds2字段指定的时间限制，则认为部署正在进行。
- 缺少-表示存储在Git中但未部署到目标群集的资源。
聚合的应用程序状态是每个应用程序资源的最差状态。健康状态是最好的，下降到进展、退化和缺失（最差）。因此，如果所有应用程序资源都正常，并且只有一个资源降级，则聚合状态也会降级。
乍一看，GitOps运算符的实现看起来并不复杂。理论上，你只需要用manifests克隆Git仓库，然后使用kubectl diff和kubectl apply来检测和处理配置偏移。这是真的，除非您试图为多个团队自动执行此过程，并同时管理数十个集群的配置。从逻辑上讲，这个过程分为三个阶段，每个阶段都有自己的挑战：
- 检索资源清单
- 检测并修正偏差
- 向最终用户展示结果
每个阶段消耗不同的资源，每个阶段的实现必须以不同的方式扩展。一个单独的Argo CD组件负责每个阶段。
Argo CD由实现GitOps协调周期阶段的三个主要组件组成。argocd-repo-server从Git检索清单。argocd-application-controller 将来自Git的清单与Kubernetes集群中的资源进行比较。argocd-api 服务器向用户显示协调结果。
让我们通过每个阶段和相应的Argo CD组件的实现细节。
检索资源清单Argo CD中的清单生成由argocd-repo-server组件实现。这一阶段提出了一整套挑战。Manifest生成需要下载Git仓库内容并生成现成的manifest YAML。首先，每次需要检索预期的资源清单时都下载整个存储库内容太耗费时间。Argo CD通过在本地磁盘上缓存存储库内容并使用 git fetch 命令只从远程Git存储库下载最近的更改来解决这个问题。下一个挑战与内存使用有关。在现实生活中，资源清单很少存储为普通的YAML文件。在大多数情况下，开发人员更喜欢使用配置管理工具，如Helm或Kustomize。每个工具调用都会导致内存使用量的激增。为了处理内存使用问题，Argo CD允许用户限制并行清单生成的数量，并扩大argocd-repo-server实例的数量，以提高性能。
argocd-repo-server 将复制的仓库缓存在本地存储器上，并封装了与配置管理工具的交互，这是生成最终资源清单所必需的。
检测并修正偏差协调阶段由argocd-application-controller组件实现。控制器加载实时Kubernetes群集状态，将其与argocd-repo-server提供的预期清单进行比较，并修补偏离的资源。这个阶段可能是最具挑战性的一个阶段。为了正确检测偏差，GitOps操作员需要了解集群中的每个资源，并比较和更新数千个资源。
argocd-application-controller 执行资源协调。控制器利用 argocd-repo-server 组件来检索预期的清单，并将清单与内存中的轻量级Kubernetes集群状态缓存进行比较。
控制器维护每个托管群集的轻量级缓存，并使用Kubernetes watch API在后台对其进行更新。这使得控制器能够在几分之一秒内对应用程序进行每个表单的协调，并使其能够同时扩展和管理数十个集群。每次协调后，控制器将获得有关每个应用程序资源的详尽信息，包括同步和运行状况状态。控制器会将这些信息保存到Redis集群中，以便稍后将其呈现给最终用户。
向最终用户展示结果最后，对账结果必须提交给最终用户。此任务由argocd-server组件执行。虽然繁重的工作已经由argocd-repo-server和argocd-application-controller完成，但最后一个阶段的弹性需求最高。Argocd-server是一个无状态的Web应用程序，它加载关于和解结果的信息并支持Web用户界面。该架构设计允许Argo CD以最小的维护开销为大型企业提供GitOps操作。
虽然Argo CD是一个企业级的、复杂的分布式系统，但它仍然是轻量级的，可以很容易地在minikube上运行。安装很简单，包括几个简单的步骤。有关如何安装Argo CD的更多信息，请参阅附录B，或按照官方的Argo CD说明进行操作。
Argo CD一运行，我们就可以部署我们的第一个应用程序了。正如之前提到的，要部署Argo CD应用程序，我们需要指定包含部署清单的Git存储库，并以Kubernetes集群和Namespace为目标。我使用下面的仓库开始：
ArgoCD可以部署到外部集群中，也可以部署到安装它的同一集群中。让我们使用第二个选项并将应用程序部署到minikube集群的defaultNamespace中。
当RESET Your FOR在前面的章节中工作时，您是否已经分叉了部署存储库？请确保还原更改以获得最佳体验。最简单的方法是删除之前分叉的存储库，然后再分叉一次。
我们可以使用 web 用户界面，CLI 命令行，甚至 REST 或 gRPC API 接口的方式来创建应用程序。由于我们已经安装并且配置 Argo CD CLI，那就是用它来部署应用程序。
1.安装argocd
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
2.暴露argocd ui
# NodePort方式
kubectl patch service -n argocd argocd-server -p '{"spec": {"type": "NodePort"}}'
3.登陆argocd
# 获取admin登陆密码
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d
继续并且用虾米那的命令船检第一个应用程序：
argocd app create sample-app \
--repo https://github.com/cubxxw/sample-app-deployment \
--path . \
--dest-server https://kubernetes.default.svc \
--dest-namespace default应用程序创建后，我们可以使用Argo CD CLI获取应用程序的状态信息。使用以下命令获取有关sample-app应用程序状态的信息:
argocd app get sample-app从命令输出中我们可以看到，应用程序不同步，不健康。默认情况下，Argo CD不会在检测到偏差时将Git仓库中定义的资源推入群集。除了高层的总结，我们还可以看到每一个应用资源的详细信息。Argo CD检测到应用程序应该有一个部署和一个服务，但这两个资源都丢失了。要部署资源，我们需要配置自动化应用程序同步
使用同步策略5或手动触发同步。要触发同步并部署资源，请使用以下命令:
argocd app sync sample-app
一旦同步被触发，Argo CD就会将存储在Git中的清单推送到Kubernetes集群中，然后重新评估应用程序状态。当同步完成时，最终的应用程序状态将打印到控制台。sample-app应用程序已成功同步，每个结果都符合预期的状态。
除了CLI和API之外，Argo CD还提供了一个用户友好的网络界面。使用Web界面，您可以获得跨多个集群部署的所有应用程序的高级视图，以及关于每个应用程序资源的非常详细的信息。打开 https://<host>:<port>URL 查看Argo CD用户界面中的应用程序列表。
显示可用Argo CD应用程序的应用程序列表页。该页面提供有关每个应用程序的高级信息，如同步和运行状况状态。
应用程序列表页面提供有关所有已部署应用程序的高级信息，包括运行状况和同步状态。使用此页面，您可以快速查找您的任何应用程序是否已降级或有配置漂移。用户界面是为大型企业设计的，能够处理数百个应用程序。您可以使用搜索和各种过滤器快速找到所需的应用程序。
应用细节页有关该应用程序的其他信息可在应用程序详细信息页面上获取。通过点击"示例应用程序"应用程序图块来导航到应用程序详细信息页面。应用程序详细信息页显示了应用程序资源层次结构，并提供了有关同步和运行状况状态的其他详细信息。让我们更仔细地查看应用程序资源树，并了解它提供的特性。资源树的根元素是应用程序本身。下一个层次包括管理资源。托管资源是指在Git中定义的、由Argo CD显式控制的资源。正如我们在第2章中了解到的，Kubernetes控制器经常利用委托并创建子资源来解除工作门。第三个和更深的层次代表这种资源。这提供了关于每个应用程序元素的完整信息，并使应用程序详细信息页面成为极其强大的Kubernetes仪表板。除了这些信息，用户界面还允许对每个资源执行各种操作。可以删除任何资源，通过运行sync重新创建它
操作，使用内置的YAML编辑器更新资源定义，甚至运行特定于资源的操作，如Deployment restart。
到目前为止，我们已经学习了如何使用Argo CD部署新的应用程序，以及如何使用CLI和用户界面获取详细的应用程序信息。接下来，让我们学习如何使用GitOps和Argo CD部署新的应用程序版本。
为了执行GitOps部署，我们需要更新资源清单，并让GitOps操作员将更改推送到Kubernetes集群中。第一步，使用以下命令克隆部署存储库：
$ git clone git@github.com:cubxxw/sample-app-deployment.git
$ cd sample-app-deployment接下来，使用以下命令更改Deploymentresource的映像版本:
sed -i '' 's/sample-app:v.*/sample-app:v0.2/' deployment.yaml使用git diff命令来确保你的Git仓库有预期的修改:
git diff diff --git a/deployment.yaml b/deployment.yaml
index 5fc3833..397d058 100644--- a/deployment.yaml+++ b/deployment.yaml@@ -16,7 +16,7 @@ spec:containers: - command: - /app/sample-app-image: gitopsbook/sample-app:v0.1+ image: gitopsbook/sample-app:v0.2name: sample-appports: - containerPort: 8080最后，使用git commit和git push将更改推送到远程Git仓库:
$ git commit -am "update deployment image"
$ git push让我们使用Argo CD CLI确保Argo CD正确检测到Git中的清单变更，然后触发同步进程以将变更推送到Kubernetes集群中:
$ argocd app diff sample-app --refresh
===== apps/Deployment default/sample-app ======21c21< image: gitopsbook/sample-app:v0.1---> image: gitopsbook/sample-app:v0.2资源清单同步只是基本的用例。在现实生活中，我们经常需要在实际部署之前和之后执行额外的步骤。例如，设置维护页面，在新版本部署之前执行数据库迁移，最后删除维护页面。传统上，这些部署步骤是在CI管道中编写脚本的。然而，这又需要从CI服务器进行生产访问，这涉及到安全威胁。为了解决这个问题，Argo CD提供了一个称为资源挂钩的特性。这些钩子允许在同步过程中在Kubernetes集群中运行定制脚本，通常打包到Pod或Job中。钩子是存储在Git存储库中的Kubernetes资源清单，并使用 argocd.argoproj.io/hook 注释进行注释。注释值
包含一个以逗号分隔的阶段列表，当钩子被假定执行时。支持以下阶段：
- 预同步-在应用舱单之前执行
- 同步-在所有预同步钩子完成并成功执行之后，同时执行清单。
跳过指示到Argo CD跳过应用清单
同步后执行--在所有同步钩子完成并成功执行之后，执行成功的应用，以及处于健康状态的所有资源。
同步-同步操作失败时执行
钩子在集群内部执行，因此不需要从CI管道访问集群。指定同步阶段的能力提供了必要的灵活性，并允许一种机制来解决大多数现实生活中的部署用例。
$ git add pre-sync.yaml$ git commit -am 'Add pre-sync hook'
$ git push
同步启动后，应用程序详细信息页面会在右上角显示实时进程状态。状态包括有关操作开始时间和持续时间的信息。您可以通过单击同步状态图标查看同步状态面板的详细信息，包括同步钩子结果。
钩子作为常规资源清单存储在Git存储库中，并在Application资源树中可视化为常规资源。您可以查看“之前”作业的实时状态，并使用Argo CD用户界面查看子Pods。除了阶段之外，还可以自定义钩子删除策略。删除策略允许自动删除钩子资源，这将为您节省大量的手工工作。
资源挂钩允许封装应用程序同步逻辑，因此我们不必使用脚本和持续集成工具。然而，一些这样的用例自然地属于持续集成过程，使用像Jenkins这样的工具仍然是更好的选择。其中一个用例是部署后验证。这里的挑战在于GitOps部署本质上是异步的。将提交推送到Git Repository后，我们仍然需要确保将更改传播到Kubernetes集群。即使在传播更改之后，开始运行测试也是不安全的。在大多数情况下，Kubernetes资源的更新也不是即时的。例如，Deployment资源更新触发滚动更新过程。滚动更新可能需要几分钟时间，如果新的应用程序版本有问题，甚至会失败。因此，如果您过早地开始测试，您可能会最终测试先前部署的应用程序版本。Argo CD通过提供帮助监视应用程序状态的工具使这个问题变得微不足道。阿尔戈CD应用程序等待命令监视应用程序，并在应用程序达到同步和正常状态后退出。命令一退出，您就可以假定所有更改都已成功推出，并且可以安全地开始部署后验证。argocd app wait命令经常与argocd app sync一起使用。使用以下命令同步您的应用程序，并等待更改完全推出，并且应用程序已准备好进行测试：
$ argocd app sync sample-app && argocd app wait sample-appArgo CD没有引入自己的用户管理系统，而是提供了与多个SSO服务的集成。该列表包括Okta、Google OAuth、Azure AD等等。
SSO代表“单点登录”（Single Sign-On）。这是一种身份验证服务，允许用户使用一组登录凭据（如用户名和密码）来访问多个应用程序或系统。SSO的主要目的是简化用户的登录过程和管理，提高安全性和用户体验。
SSO是一种会话和用户身份验证服务，允许用户使用一组SSO登录凭据访问多个应用程序。
SSO集成非常棒，因为它为您节省了大量的管理开销，并且最终用户不必记住另一组登录凭据。有几种用于交换认证和授权数据的开放标准。最流行的是SAML、OAuth和OpenID Connect（OIDC）。其中，SAML和OI DC满足典型企业的最佳需求，可用于实现SSO。Argo CD公司决定与OIDC合作，因为它的强大和简单。配置OIDC集成所需的步骤数取决于您的OIDC提供程序。Argo CD社区已经为流行的OIDC提供商（如Okta和Azure AD）贡献了大量的说明。在OIDC提供程序端执行配置后，需要将相应的配置添加到argocd-cm ConfigMap中。以下代码段表示Okta配置示例:
如果您的组织没有与OIDC兼容的SSO服务怎么办？在这种情况下，您可以使用一个联合的OIDC提供程序Dex 7，默认情况下它被绑定到Argo CD中。Dex充当其他身份提供者的代理，允许与SAML、LDAP提供者甚至GitHub和Active Directory等服务建立集成。GitHub通常是一个非常有吸引力的选择，特别是当您的组织中的开发人员已经在使用它的时候。此外，在GitHub中配置的组织和团队。
适合组织集群访问所需的访问控制模型。您很快就会了解到，使用GitHub团队成员对Argo CD访问建模非常简单。让我们使用GitHub来增强Argo CD安装并启用SSO集成。首先，我们需要创建一个GitHub OAuth应用程序。导航到https://github.com/settings/applications/new。
-
✴️版权声明 © ：本书所有内容遵循CC-BY-SA 3.0协议（署名-相同方式共享）©