通常情况下，当开发人员为托管在Kubernetes上的应用程序建立CI/CD管道时，Kubernetes（通常缩写为K8s）提供了一个框架来有效地运行分布式系统。它是一个帮助管理容器化工作负载和服务的平台，甚至还负责扩展。谷歌在2014年将其开源。，他们在一个任务运行器中处理CI和CD部分，如CircleCI或Travis CI。这些服务为你的部署提供基于推送的更新，这意味着代码 repo和部署目标的凭证必须存储在这些服务中。如果服务被破坏，这种方法就会出现问题，例如去年发生在CodeShip的情况。
即使是使用GitLab CI和GitHub Actions这样的服务，也需要将访问集群的凭证存储在它们那里。如果你使用GitOps，利用通常的推送到 repo -> 审查代码 -> 合并代码的顺序来管理你的基础设施配置，这也意味着要访问你的整个基础设施。
由于这些外部服务不是Kubernetes所特有的，因此不知道所有部署部分的状态，所以也很难跟踪不同的部署环境与存储在 repo中的配置文件的漂移情况。
幸运的是，有一些工具可以帮助我们解决这些问题。其中最知名的两个是Argo CD和Flux。它们允许凭证存储在你的Kubernetes集群内，在那里你可以对它们的安全性有更多的控制。它们还提供基于拉动的部署，并带有漂移检测。这两个工具解决了同样的问题，但从不同的角度解决了这些问题。
在这里，我们将更深入地了解这两个工具中的Argo CD。
什么是Argo CD
Argo CD是一个持续部署工具，你可以安装到你的Kubernetes集群中。它可以从git仓库中提取最新的代码，并将其部署到集群中--与外部CD服务相比，部署是基于拉动的。你可以用Argo CD管理你的应用程序和基础设施配置的更新。这种设置的优点包括能够使用集群本身的凭证进行部署，这些凭证可以存储在秘密或保险库中。
准备工作
为了尝试Argo CD，我们还准备了一个测试项目，将其部署到DigitalOcean的Kubernetes上。你可以从我们的GitLab仓库中抓取这个示例项目：https://gitlab.com/risingstack-org/argocd-demo/
分支这个repo可以让你自己进行修改，以后可以在Argo CD中把它设置为部署源。
从这里获取doctl。
docs.digitalocean.com/reference/d…
或者，如果你使用的是mac，可以从Homebrew获取。
brew install doctl
你可以在本教程中使用任何Kubernetes提供商。两个要求是拥有一个Docker仓库和一个可以访问它的Kubernetes集群。在本教程中，我们选择使用DigitalOcean，因为它的设置很简单，但大多数其他平台应该可以正常工作。
我们将专注于在大部分过程中使用Web UI，但如果你愿意，你也可以选择使用`doctl`cli工具。`doctl`大部分也可以替代`kubectl`。`doctl`只需要将我们构建的docker镜像推送到我们的部署所能访问的repo。
Helm是Kubernetes的一个模板引擎。它允许我们从yaml文件的结构中单独定义值，这有助于访问控制和使用同一模板管理多个环境。
你可以在这里抓住Helm：https://github.com/helm/helm/releases
或者通过Mac用户的Homebrew。
brew install helm
从github.com/argoproj/ar…下载最新的Argo CD版本
如果你使用的是mac，你可以从Homebrew获取cli工具。
brew install argocd
DigitalOcean设置
登录后，首先，使用右上方的 "创建 "按钮创建一个集群，并选择Kubernetes。为了这个演示的目的，我们可以只使用最小的集群，没有额外的节点。请确保选择一个离你近的数据中心。
准备演示应用程序
你可以在你分叉的 repo 的 node-app 文件夹中找到演示应用程序。在下面的步骤中使用这个文件夹来构建并推送docker镜像到GitLab注册中心。
docker login registry.gitlab.com
docker build . -t registry.gitlab.com/<substiture repo name here>/demo-app-1
docker push registry.gitlab.com/<substiture repo name here>/demo-app-1
GitLab为每个git repo提供了一个免费的镜像注册表--即使是免费级别的。你可以用这些来存储你构建的镜像，但要注意，注册表会继承git repo的隐私设置，你不能单独改变它们。
一旦镜像准备好了，一定要用正确的镜像网址来更新values.yaml文件，并使用helm来生成resources.yaml文件。然后你就可以用kubectl来部署一切了。
helm template -f "./helm/demo-app/values.yaml" "./helm/demo-app" > "./helm/demo-app/resources/resources.yaml"
kubectl apply -f helm/demo-app/resources/resources.yaml
这些demo-app资源的唯一目的是展示ArgoCD的UI功能，这就是为什么它还包含一个Ingress资源作为补充。
在集群中安装Argo CD
Argo CD提供了一个yaml文件来安装你所需要的一切，它可以在网上找到。这里最重要的是确保你把它安装到`argocd`命名空间，否则，你以后会遇到一些错误，Argo CD将无法使用。
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
从这里，你可以使用Kubernetes端口转发来访问Argo CD的用户界面。
kubectl -n argocd port-forward svc/argocd-server 8080:443
这将在localhost:8080暴露服务 - 我们将使用用户界面来设置与GitLab的连接，但也可以通过命令行工具完成。
Argo CD设置
要在用户界面上登录，使用`admin`作为用户名，并使用该命令获取的密码。
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d
一旦你登录了，从左边的设置菜单中的Repositories连接你的demo app repo的分叉。在这里，我们可以选择 ssh 和 https 认证 - 对于这个演示，我们将使用 https，但对于 ssh，你只需要设置一个密钥对即可使用。
在GitLab上创建一个API密钥，用它来代替密码和你的用户名来连接 repo。相对于使用你的账户密码来说，API 密钥允许某种程度的访问控制。
成功连接仓库后，剩下的事情就是设置一个应用程序，它将负责将我们的部署状态与GitLab repo中描述的状态同步。
你需要选择一个分支或标签来进行监控。现在让我们选择主分支--反正它应该包含最新的稳定代码。将同步策略设置为自动，可以在git repo更新时自动部署，还可以提供自动修剪和自我修复功能。
请确保将目标集群设置为下拉菜单中的可用集群，并使用`demo`命名空间。如果一切设置正确，Argo CD现在应该开始同步部署状态了。
Argo CD的特点
从应用程序视图中，你现在可以看到组成我们的演示应用程序的不同部分。
点击这些部分中的任何一个，可以检查部署的配置和检查到git中的配置的差异，以及单独检查yaml文件本身。差异现在应该是空的，但是一旦我们做了一些改变或者你禁用了自动同步，我们就会看到它的作用。
你还可以在这里访问来自pod的日志，这可能相当有用--不同的pod实例之间不保留日志，这意味着在删除pod时它们会丢失，然而。
也可以从这里处理回滚，点击 "历史和回滚 "按钮。在这里，你可以看到所有不同的版本，已经通过提交部署到我们的集群。
你可以使用右上方的......菜单，选择 "重新部署 "来重新部署其中的任何一个--这个功能需要关闭自动部署。然而，这里会提示你这样做。
这些应该涵盖了用户界面最重要的部分以及Argo CD中的可用功能。接下来，我们将看看当GitLab上的代码发生变化时，部署更新是如何发生的。
更新部署
设置完成后，你对推送到主分支的配置所做的任何改动都应该在不久后反映在部署中。
检查更新过程的一个非常简单的方法是将values.yaml中的`replicaCount`提高到2（或更多），并再次运行helm命令以生成resources.yaml。
然后，提交并推送到主站，在Argo CD用户界面上监控更新过程。
你应该在demo-app事件中看到一个新事件，原因是`ScalingReplicaSet'。
你可以用kubectl仔细检查结果，现在你应该看到有两个demo-app的实例在运行。
kubectl -n demo get pod
在 repo 中准备了另一个分支，叫做 second-app，它有另一个可以部署的应用，所以你可以看到更多的更新过程和差异。它与之前的部署方式很相似。
首先，你需要将second-app分支合并到master中--这将使变化被自动部署，正如我们已经设置的那样。然后，从node-app-2文件夹，构建并推送docker镜像。确保它有一个不同的版本标签，这样我们就可以使用相同的 repo!
docker build . -t registry.gitlab.com/<substitute repo name here>/demo-app-2
docker push registry.gitlab.com/<substitute repo name here>/demo-app-2
你可以将这一步的部署设置为手动，以便在实际更新发生前更好地查看差异。你可以在 "应用程序细节 "的同步设置部分这样做。
之后生成更新的资源文件，然后提交并推送到git以触发Argo CD的更新。
helm template -f "./helm/demo-app/values.yaml" "./helm/demo-app" > "./helm/demo-app/resources/resources.yaml"
这将导致差异出现在 "App details"->"Diff"，供你查看。你可以手动部署它，也可以把自动部署的功能调回来。
ArgoCD可以保护你免受那些从你的代码的最新源控制版本中漂移出来的资源变化的影响。让我们尝试手动将部署规模扩大到5个实例。
获取副本集的名称。
kubectl -n demo get rs
将它扩展到5个实例。
kubectl -n demo scale --replicas=5 rs/demo-app-<number>
如果你的动作够快，你可以在ArgoCD应用程序可视化上捕捉到应用的变化，因为它试图添加这些实例。然而，ArgoCD将阻止这种变化，因为它将从部署的源控制版本中漂移。它还将部署规模缩小到最新提交的定义值（在我的例子中，它被设置为3）。
降级事件可以在`demo-app`部署事件下找到，如下图所示。
从这里，你可以尝试任何你想做的改变
完成我们的ArgoCD Kubernetes教程
这就是我们对ArgoCD的快速介绍，它可以使你的GitOps工作流程更安全、更方便。
请继续关注，因为我们计划下一次再来看看另一个重磅炸弹。Flux。
本文作者是RisingStack的高级工程师Janos Kubisch。
The postArgo CD Kubernetes Tutorialappeared first onRisingStack Engineering.
