当前位置: 首页 > 创领中心 > 网络优化

Updater是如何运作的 Image ArgoCD

  • 网络优化
  • 2024-11-15
  • 826

Argo CD Image Updater是一种智能更新由 Argo CD 治理的 Kubernetes 上班负载的容器镜像的工具。 该工具可以审核与 Kubernetes 上班负载一同部署的容器镜像的新版本,并经常使用 Argo CD 智能将其更新到准许的最新版本。它经过为 Argo CD 运行程序设置适当的运行程序参数来上班,相似于argocd app set --helm-set image.tag=v1.0.1,但以齐全智能化的方式。

Argo CD Image Updater 会活期轮询 Argo CD 中性能的运行程序,并查问相应的镜像仓库以失掉或许的新版本。假设在仓库中找到新版本的镜像,并且满足版本解放,Argo CD 镜像更新程序将批示 Argo CD 经常使用新版本的镜像更新运行程序。

依据您的运行程序智能同步战略,Argo CD 将智能部署新的镜像版本或将运行程序标志为不同步,您可以经过同步运行程序来手动触发镜像更新。

Image Updater 程序经过读取 ArgoCD 运行程序资源中的annotations来上班,这些注解指定应智能更新哪些镜像。它会审核指定镜像仓库中能否有较新的标签,假设它们与预约义的形式或规定婚配,则经常使用这些较新的标签更新运行程序清单。此智能化环节可确保您的运行程序一直运转最新版本的镜像,遵照 GitOps 的分歧性和可追溯性准则。

Image Updater 基本的上班流程如下所示:

另外须要留意的是经常使用该工具目前有几个限度:

倡导在运转 Argo CD 的同一个 Kubernetes 命名空间集群中运转 Argo CD Image Updater,但这不是必需的。理想上,甚至不须要在 Kubernetes 集群中运转 Argo CD Image Updater 或基本不须要访问任何 Kubernetes 集群。但假设不访问 Kubernetes,某些性能或许不可经常使用,所以剧烈倡导经常使用第一种装置方法。

运转镜像更新程序的最间接方法是将其作为 Kubernetes 上班负载装置到运转 Argo CD 的命名空间中。这样就不须要任何性能,也不会对你的上班负载发生任何影响。

kubectl apply -n argocd -f

装置实现后咱们就可以在 Argo CD 中看到Argo CD Image Updater组件了:

$ kubectl get pods -n argocdNAMEREADYSTATUSRESTARTSAGEargocd-application-controller-01/1Running021margocd-applicationset-controller-587b5c864b-2kt2v1/1Running07d4hargocd-dex-server-6958d7dcf4-66s6s1/1Running07d4hargocd-image-updater-57b788886d-d4qh51/1Running034sargocd-notifications-controller-6847bd5c98-wqbjj1/1Running07d4hargocd-redis-6fcf5c8898-c67521/1Running07d4hargocd-repo-server-9646985c8-7dmj51/1Running07d4hargocd-server-67b76b54d7-hxx6q1/1Running07d4h

如今咱们就可以间接去监听镜像能否出现了变动,而不须要在 CI 流水线中去手动提交修正资源清单到代码仓库了。

要充沛应用 ArgoCD 镜像更新程序,将其性能衔接到镜像仓库至关关键,尤其是在经常使用私有仓库或公共仓库上的私有存储库时。以下是如何性能必要的凭据并了解可用的不同方法。

ArgoCD Image Updater 可以经常使用以下方法失掉凭据:

kubectl create -n argocd secret docker-registry dockerhub-secret \--docker-username someuser \--docker-password s0m3p4ssw0rd \--docker-server "https://registry-1.docker.io"

这个 secret 可以被援用为pullsecret:<namespace>/<secret_name>(pullsecret:argocd/dockerhub-secret)。

kubectl create -n argocd secret generic some-secret \--from-literal=creds=someuser:s0m3p4ssw0rd

该 secret 可以用secret:<namespace>/<secret_name>#<field_name>(secret:argocd/some-secret#creds) 的方式援用。

env:- name: DOCKER_HUB_CREDSvalue: "someuser:s0m3p4ssw0rd"

该 secret 可以用env:<name_of_environment_variable>(env:DOCKER_HUB_CREDS) 的方式援用。

#!/bin/shecho "someuser:s0m3p4ssw0rd"

将其援用为ext:<full_path_to_script>。

咱们这里就以 Github 的 Container Registry 为例,来演示下如何经常使用 ArgoCD Image Updater 来更新镜像。

首先咱们在 Github 团体设置页面中创立一个团体访问令牌,如下图所示:

这个 Token 的权限要包括write:packages和read:packages,这样咱们能力推送和拉取镜像,创立后会失掉一个 Token。

而后咱们可以在终端或命令行中,经常使用 GitHub 用户名和 GitHub 的团体访问令牌(PAT)登录 GitHub Container Registry。

export PAT=<your-token>echo $PAT | docker login ghcr.io -u <your-github-username> --password-stdin

将交流为团体访问令牌,将交流为 GitHub 用户名。

登录成功后咱们可以经常使用以下命令将 Docker 镜像标志为 GitHub Container Registry 镜像:

docker tag <your-image-name>:<tag> ghcr.io/<your-github-username>/<your-image-name>:<tag>

将<your-image-name>:<tag>交流为本地 Docker 镜像名与 tag 名,将<your-github-username>交流为 GitHub 用户名,<tag>交流想要经常使用的标签(例如自动的latest标签)。

而后经常使用以下命令将 Docker 镜像推送到 GitHub Container Registry 即可:

docker push ghcr.io/<your-github-username>/<your-image-name>:<tag>

实现以上步骤后,就可以在 GitHub 团体账号的 的Packages局部看到 Docker 镜像了,然而该镜像默以为 private 镜像,Pull 经常使用时须要先登录。

github packages

如今回到咱们的镜像更新程序中,经常使用上方的 Token 来创立一个 Secret:

kubectl create -n argocd secret docker-registry ghcr-secret \--docker-username=cnych \--docker-password=$PAT \--docker-server="https://ghcr.io"

设置凭据后,将它们性能在 ArgoCD 镜像更新程序的性能中,以经过镜像仓库启出发份验证,咱们可以修正镜像更新程序的性能:

apiVersion: v1kind: ConfigMapmetadata:name: argocd-image-updater-confignamespace: argocddata:registries.conf: |registries:- name: ghcr-hubapi_url:# 镜像仓库地址credentials: pullsecret:argocd/ghcr-secret # 凭据defaultns: library # 自动命名空间default: true # 自动仓库

上方性能中咱们指定了 GitHub 镜像仓库的凭据为pullsecret:argocd/ghcr-secret,这样 ArgoCD Image Updater 在访问ghcr.io时就会经常使用这个凭据。

接上去咱们还须要将 ArgoCD Image Updater 与 Git 集成,这也是重点,这样 ArgoCD Image Updater 就可以将镜像更新间接提交回源 Git 仓库。

咱们可以在 ArgoCD 的 Dashboard 中先减少一个 Git 仓库:

add git repo

接上去咱们可以依照反经常常使用方式创立一个新的Application对象,对应的资源清单文件如下所示:

apiVersion: argoproj.io/v1alpha1kind: Applicationmetadata:name: gitops-demonamespace: argocdspec:destination:namespace: gitops-demoserver:defaultsource:path: helm # 从 Helm 存储库创立运行程序时,chart 必定指定 pathrepoURL:masterhelm:parameters:- name: replicaCountvalue: "2"valueFiles:- my-values.yamlsyncPolicy:automated:prune: trueselfHeal: truesyncOptions:- CreateNamespace=true

间接创立上方的资源清单文件后,ArgoCD 会智能创立一个Application资源对象,并且会智能同步到 Git 仓库中,咱们可以在 Git 仓库中看到对应的资源清单文件:

gitops-demo

假设该运行出现了如下所示的失误信息:

Namespacegitops-demoSyncFailedresource :Namespace is not permitted in project default

则外表经常使用的 project 没有权限创立 namespace,咱们只要要为其减少对应的权限即可:

apiVersion: argoproj.io/v1alpha1kind: AppProjectmetadata:name: defaultnamespace: argocdspec:clusterResourceWhitelist: # 白名单,示意准许访问的资源- group: "*"kind: "*"destinations:- name: "*"namespace: "*"server: "*"sourceRepos:- "*"

咱们可以经常使用argocd app get命令来检查Application资源对象的形态:

$ argocd app get argocd/gitops-demoName:argocd/gitops-demoProject:defaultServer:Repo:Values:my-values.yamlSyncWindow:Sync AllowedSync Policy:Automated (Prune)Sync Status:Synced to master (53d91ed)Health Status:ProgressingGROUPKINDNAMESPACENAMESTATUSHEALTHHOOKMESSAGENamespacegitops-demoRunningSyncednamespace/gitops-demo createdappsDeploymentdefaultgitops-demo-helm-guestbookSucceededPrunedprunedServicedefaultgitops-demo-helm-guestbookSucceededPrunedprunedServicegitops-demogitops-demo-devops-demoSyncedHealthyservice/gitops-demo-devops-demo createdappsDeploymentgitops-demogitops-demo-devops-demoSyncedProgressingdeployment.apps/gitops-demo-devops-demo creatednetworking.k8s.ioIngressgitops-demogitops-demo-devops-demoSyncedProgressingingress.networking.k8s.io/gitops-demo-devops-demo created

反常咱们这个运行就可以运转了:

$ curl{"msg":"Hello Tekton On GitLab With ArgoCD"}

然而在 Dashboard 中咱们可以看到运行只管曾经是Synced形态,然而APP HEALTH不时显示为Progressing形态。

这是由于 ArgoCD 的肥壮形态机制惹起的,咱们可以在源码中看到肥壮形态的审核逻辑。

func getIngressHealth(obj *unstructured.Unstructured) (*HealthStatus, error) { ingresses, _, _ := unstructured.NestedSlice(obj.Object, "status", "loadBalancer", "ingress") health := HealthStatus{} if len(ingresses) > 0 {health.Status = HealthStatusHealthy } else {health.Status = HealthStatusProgressing } return &health, nil}

他须要审核 Ingress 资源对象的status.loadBalancer.ingress字段能否为空,假设为空则示意肥壮形态为Progressing,否则为Healthy,但实践状况却是并不是一切的 Ingress 资源对象都会智能生成status.loadBalancer.ingress字段,比如咱们这里就并没有生成。

这个时刻咱们可以经过性能argocd-cm的性能资源来修正肥壮形态审核逻辑,减少如下所示的性能:

apiVersion: v1kind: ConfigMapmetadata:name: argocd-cmnamespace: argocddata:resource.customizations: |networking.k8s.io/Ingress:health.lua: |hs = {}if obj.metadata ~= nil and obj.metadata.creationTimestamp ~= nil thenhs.status = "Healthy"hs.message = "Ingress 已创立"elsehs.status = "Progressing"hs.message = "Ingress 正在创立中"endreturn hs

上方的性能示意假设 Ingress 资源对象的metadata.creationTimestamp字段不为空,则示意肥壮形态为Healthy,否则为Progressing,更新上方的性能后,咱们再次检查运行的肥壮形态就会发现曾经变成了Healthy形态:

接上去咱们就可以经常使用 ArgoCD Image Updater 来更新镜像了,修正上方的Application资源清单文件,咱们须要减少一些注解来指定须要更新的镜像规定战略,如下所示:

apiVersion: argoproj.io/v1alpha1kind: Applicationmetadata:name: gitops-demonamespace: argocdannotations:argocd-image-updater.argoproj.io/image-list: myalias=ghcr.io/cnych/gitops-demo # 指定镜像仓库argocd-image-updater.argoproj.io/myalias.allow-tags: regexp:^.*$ # 准许一切标签argocd-image-updater.argoproj.io/myalias.pull-secret: pullsecret:argocd/ghcr-secret # 指定凭据argocd-image-updater.argoproj.io/myalias.update-strategy: latest # 指定更新战略# argocd-image-updater.argoproj.io/myalias.ignore-tags: latest, master # 指定疏忽的标签argocd-image-updater.argoproj.io/write-back-method: git # 指定写回方法argocd-image-updater.argoproj.io/git-branch: master # 指定 Git 分支argocd-image-updater.argoproj.io/myalias.force-update: "true" # 强迫更新spec:destination:namespace: gitops-demoserver:defaultsource:path: helm # 从 Helm 存储库创立运行程序时,chart 必定指定 pathrepoURL:masterhelm:parameters:- name: replicaCountvalue: "2"valueFiles:- my-values.yamlsyncPolicy:automated:prune: trueselfHeal: truesyncOptions:- CreateNamespace=true

这个新的资源对象中,咱们减少了一些注释,这些注释用于性能 Argo CD Image Updater。这些性能用于指定智能更新容器镜像的战略、参数和相关信息。以下是对这些注释的具体解释:

如今咱们从新更新 Application 资源对象即可。接上去咱们只要要从新推送一个新的镜像到 GitHub Container Registry 即可智能触发 ArgoCD Image Updater 更新镜像。

咱们更新下仓库中的main.go文件:

修正代码

如今咱们从新构建一个新的镜像并推送到 GitHub Container Registry:

docker build --platform linux/amd64 -t ghcr.io/cnych/gitops-demo:v0.1.1 .docker push ghcr.io/cnych/gitops-demo:v0.1.1

推送新的镜像后,而后Argo CD Image Updater将会每 2 分钟从镜像仓库去检索镜像版本变动,一旦发现有新的镜像版本,它将智能经常使用新版原本更新集群内上班负载的镜像,并将镜像版本回写到 Git 仓库中去,咱们可以去检查 Argo CD Image Updater 的日志变动:

$ kubectl logs -f argocd-image-updater-57b788886d-d4qh5 -n argocdtime="2024-09-27T06:51:32Z" level=info msg="argocd-image-updater v0.14.0+af844fe starting [loglevel:INFO, interval:2m0s, healthport:8080]"time="2024-09-27T06:51:32Z" level=warning msg="commit message template at /app/config/commit.template does not exist, using default"time="2024-09-27T08:35:39Z" level=warning msg="\"latest\" strategy has been renamed to \"newest-build\". Please switch to the new convention as support for the old naming convention will be removed in future versions." image_alias=myalias image_name=ghcr.io/cnych/gitops-demo registry_url=ghcr.iotime="2024-09-27T08:35:40Z" level=info msg="Processing results: applicatinotallow=1 images_cnotallow=1 images_skipped=0 images_updated=0 errors=0"xxxxxxxxxxxxxxtime="2024-09-27T08:37:40Z" level=info msg="Starting image update cycle, considering 1 annotated application(s) for update"time="2024-09-27T08:37:40Z" level=warning msg="\"latest\" strategy has been renamed to \"newest-build\". Please switch to the new convention as support for the old naming convention will be removed in future versions." image_alias=myalias image_name=ghcr.io/cnych/gitops-demo registry_url=ghcr.iotime="2024-09-27T08:37:44Z" level=info msg="Setting new image to ghcr.io/cnych/gitops-demo:v0.1.1" alias=myalias applicatinotallow=gitops-demo image_name=cnych/gitops-demo image_tag=latest registry=ghcr.iotime="2024-09-27T08:37:44Z" level=info msg="Successfully updated image 'ghcr.io/cnych/gitops-demo:latest' to 'ghcr.io/cnych/gitops-demo:v0.1.1', but pending spec update (dry run=false)" alias=myalias applicatinotallow=gitops-demo image_name=cnych/gitops-demo image_tag=latest registry=ghcr.iotime="2024-09-27T08:37:44Z" level=info msg="Committing 1 parameter update(s) for application gitops-demo" applicatinotallow=gitops-demotime="2024-09-27T08:37:44Z" level=info msg="Starting configmap/secret informers"time="2024-09-27T08:37:44Z" level=info msg="Configmap/secret informer synced"time="2024-09-27T08:37:44Z" level=info msg="Initializingto /tmp/git-gitops-demo1873820104"time="2024-09-27T08:37:44Z" level=info msg="secrets informer cancelled"time="2024-09-27T08:37:44Z" level=info msg="configmap informer cancelled"time="2024-09-27T08:37:44Z" level=info msg="git fetch origin --tags --force --prune" dir=/tmp/git-gitops-demo1873820104 execID=acebctime="2024-09-27T08:37:46Z" level=info msg=Trace args="[git fetch origin --tags --force --prune]" dir=/tmp/git-gitops-demo1873820104 operation_name="exec git" time_ms=1640.146246time="2024-09-27T08:37:46Z" level=info msg="git config user.name argocd-image-updater" dir=/tmp/git-gitops-demo1873820104 execID=7ec2dtime="2024-09-27T08:37:46Z" level=info msg=Trace args="[git config user.name argocd-image-updater]" dir=/tmp/git-gitops-demo1873820104 operation_name="exec git" time_ms=1.5687190000000002time="2024-09-27T08:37:46Z" level=info msg="git config user.email noreply@argoproj.io" dir=/tmp/git-gitops-demo1873820104 execID=6e796time="2024-09-27T08:37:46Z" level=info msg=Trace args="[git config user.email noreply@argoproj.io]" dir=/tmp/git-gitops-demo1873820104 operation_name="exec git" time_ms=1.688394time="2024-09-27T08:37:46Z" level=info msg="git checkout --force master" dir=/tmp/git-gitops-demo1873820104 execID=403bbtime="2024-09-27T08:37:46Z" level=info msg=Trace args="[git checkout --force master]" dir=/tmp/git-gitops-demo1873820104 operation_name="exec git" time_ms=4.522311time="2024-09-27T08:37:46Z" level=info msg="git clean -ffdx" dir=/tmp/git-gitops-demo1873820104 execID=b3f03time="2024-09-27T08:37:46Z" level=info msg=Trace args="[git clean -ffdx]" dir=/tmp/git-gitops-demo1873820104 operation_name="exec git" time_ms=1.429556time="2024-09-27T08:37:46Z" level=info msg="git -c gpg.format=openpgp commit -a -F /tmp/image-updater-commit-msg441967746" dir=/tmp/git-gitops-demo1873820104 execID=0efc6time="2024-09-27T08:37:46Z" level=info msg=Trace args="[git -c gpg.format=openpgp commit -a -F /tmp/image-updater-commit-msg441967746]" dir=/tmp/git-gitops-demo1873820104 operation_name="exec git" time_ms=5.239213time="2024-09-27T08:37:46Z" level=info msg="git push origin master" dir=/tmp/git-gitops-demo1873820104 execID=fcd1ftime="2024-09-27T08:37:47Z" level=info msg=Trace args="[git push origin master]" dir=/tmp/git-gitops-demo1873820104 operation_name="exec git" time_ms=1934.14529time="2024-09-27T08:37:47Z" level=info msg="Successfully updated the live application spec" applicatinotallow=gitops-demotime="2024-09-27T08:37:47Z" level=info msg="Processing results: applicatinotallow=1 images_cnotallow=1 images_skipped=0 images_updated=1 errors=0"

而后在 Git 仓库中咱们也可以看到有一条新的 commit 提交记载,可以看到在回写时,ArgoCD Image Updater并不会间接修正仓库的values.yaml文件,而是会创立一个专门用于笼罩 Helm Chartvalues.yaml的.argocd-source-devops-demo.yaml文件。

智能提交变卦后,Argo CD 就会智能同步部署运行了。

当然如今访问运行结果就是咱们更改后的内容了:

$ curl{"msg":"Hello ArgoCD With Image Updater"}

另外咱们可以留意到每次 Git 提交都与作者的姓名和电子邮件地址相关联。假设未性能,Argo CD 镜像更新程序口头的提交将经常使用argocd-image-updater <noreply@argoproj.io>作为作者。您可以经常使用--git-commit-user和--git-commit-email命令行开关笼罩作者,或在argocd-image-updater-config ConfigMap中设置git.user和git.email即可。

雷同咱们可以将 Argo CD Image Updater 经常使用的自动提交信息更改为适宜你的方式。可以创立一个便捷的模板(经常使用 Golang Template),并经过将argocd-image-updater-configConfigMap 中的密钥git.commit-message-template设置为模板的内容来使其可用,例如:

data:git.commit-message-template: |build: automatic update of {{ .AppName }}{{ range .AppChanges -}}updates image {{ .Image }} tag '{{ .OldTag }}' to '{{ .NewTag }}'{{ end -}}

模板中提供了两个顶级变量:

  • 关注微信

本网站的文章部分内容可能来源于网络和网友发布,仅供大家学习与参考,如有侵权,请联系站长进行删除处理,不代表本网站立场,转载联系作者并注明出处:https://clwxseo.com/wangluoyouhua/7854.html

猜你喜欢

热门资讯

关注我们

微信公众号