网站app程序制作企业,网站加速器,wordpress找不到分类页面,网站制作员文章目录 ArgoCD简介ArgoCD安装访问ArgoCDGitOps 工作流总览创建 ArgoCD 应用检查 ArgoCD 同步状态访问应用 连接 GitOps 工作流体验 GitOps 工作流生产建议1#xff09;修改默认密码2#xff09;配置 Ingress 和 TLS3#xff09;使用 Webhook 触发 ArgoCD4#xff09;将源… 文章目录 ArgoCD简介ArgoCD安装访问ArgoCDGitOps 工作流总览创建 ArgoCD 应用检查 ArgoCD 同步状态访问应用 连接 GitOps 工作流体验 GitOps 工作流生产建议1修改默认密码2配置 Ingress 和 TLS3使用 Webhook 触发 ArgoCD4将源码仓库和应用定义仓库分离5加密 GitOps 中存储的秘钥 ArgoCD简介
官网https://argo-cd.readthedocs.io/en/stable/
ArgoCD安装
$ kubectl create namespace argocd$ kubectl apply -n argocd -f https://ghproxy.com/https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml~# kubectl wait --forconditionReady pods --all -n argocd --timeout 300s
pod/argocd-application-controller-0 condition met
pod/argocd-applicationset-controller-6dd887f766-gv2gk condition met
pod/argocd-dex-server-89774cfc6-v2dhc condition met
pod/argocd-notifications-controller-79c985586c-xkt7q condition met
pod/argocd-redis-74f98b85f-dvhjc condition met
pod/argocd-repo-server-9cb997c7b-vjzrn condition met
pod/argocd-server-749879d78d-hcc6v condition met访问ArgoCD
可以通过ingress或者nodeport方式暴露进行访问
useradmin
passwd$ kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath{.data.password} | base64 -dGitOps 工作流总览 我们可以把这个完整的 GitOps 工作流分成三个部分来看。 第一部分开发者推送代码到 GitHub 仓库然后触发 GitHub Action 自动构建。 第二部分GitHub Action 自动构建它包括下面三个步骤 构建示例应用的镜像。将示例应用的镜像推送到 Docker Registry 镜像仓库。更新代码仓库中 Helm Chart values.yaml 文件的镜像版本。 第三部分核心是 ArgoCD它包括下面两个步骤: 通过定期 Poll 的方式持续拉取 Git 仓库并判断是否有新的 commit。从 Git 仓库获取 Kubernetes 对象与集群对象进行实时比较自动更新集群内有差异的资源。 前边的环境已经准备好现在准备创建 GitOps 工作流中的第三部分也就是创建 ArgoCD 应用实现 Kubernetes 资源的自动同步。
创建 ArgoCD 应用
以示例应用为例子来创建 ArgoCD 应用这里主要分成两个步骤。
配置仓库访问权限。创建 ArgoCD 应用。
其中如果你的示例应用仓库是公开的可以跳过第一步。 配置 ArgoCD 仓库访问权限可选
$ argocd login 127.0.0.1:8080 --insecure #更换地址
Username: admin
Password:
admin:login logged in successfully添加示例应用仓库:
~# argocd repo add https://github.com/Hugh-yw/kubernetes-example.git --username $USERNAME --password $PASSWORD将 $USERNAME 替换为 GitHub 账户 ID将 $PASSWORD 替换为 GitHub Personal TokenToken创建链接https://github.com/settings/tokens/new
创建 ArgoCD 应用 ArgoCD 同时支持使用 Helm Chart、Kustomize 和 Manifest 来创建应用本次实践以示例应用的 Helm Chart 为例。 通过argocd app create命令来创建应用:
$ argocd app create example --sync-policy automated --repo https://github.com/Hugh-yw/kubernetes-example.git --revision main --path helm --dest-namespace gitops-example --dest-server https://kubernetes.default.svc --sync-option CreateNamespacetrue
application example created–sync-policy 参数代表设置自动同步策略。automated 的含义是自动同步也就是说当集群内的资源和 Git 仓库 Helm Chart 定义的资源有差异时ArgoCD 会自动执行同步操作实时确保集群资源和 Helm Chart 的一致性。 –repo 参数表示 Helm Chart 的仓库地址。这里的值是示例应用的仓库地址注意需要替换成你实际的 Git 仓库地址。 –revision 参数表示需要跟踪的分支或者 Tag这里我们让 ArgoCD 跟踪 main 分支的改动。 –path 参数表示 Helm Chart 的路径。在示例应用中存放 Helm Chart 的目录是 helm 目录。 –dest-namespace 参数表示命名空间。这里指定了 gitops-example 命名空间注意这是一个不存在的命名空间所以我们额外通过--sync-option参数来让 ArgoCD 自动创建这个命名空间。 最后–dest-server 参数表示要部署的集群 https://kubernetes.default.svc 表示 ArgoCD 所在的集群。 检查 ArgoCD 同步状态 在应用详情页面需要重点关注三个状态。
APP HEALTH 应用整体的健康状态它包含下面三个值。 Progressing处理中Healthy健康状态Degraded宕机 CURRENT SYNC STATUS 应用定义和集群对象的差异状态也包含下面三个值。 Synced完全同步OutOfSync存在差异Unknown未知 LAST SYNC RESULT 最后一次同步到 Git 仓库的信息包括 Commit ID 和提交者信息。
访问应用
当应用健康状态变为 Healthy 之后我们就可以访问应用了。
~# kubectl get ingressroute -n gitops-example
NAME AGE
frontend-service 70m访问应用链接http://frontend.demo.com
连接 GitOps 工作流 在完成 ArgoCD 的应用配置之后我们就已经将示例应用的 Helm Chart 定义和集群资源关联起来了但整个 GitOps 工作流还缺少非常重要的一部分就是上面提到的自动更新 Helm Chart values.yaml 文件镜像版本的部分在下面这张示意图中用“❌”把这个环节标记了出来。 在这部分工作流没有打通之前提交的新代码虽然会构建出新的镜像但是 Helm Chart 定义的镜像版本并不会产生变化 这会导致 ArgoCD 不能自动更新集群内工作负载的镜像版本。 要解决这个问题我们还需要在 GitHub Action 中添加自动修改 Helm Chart 并重新推送到仓库操作。 接下来我们修改示例应用的.github/workflows/build.yaml文件在“Build frontend and push”阶段后面添加一个新的阶段代码如下 - name: Update helm values.yamluses: fjogeleit/yaml-update-actionmainwith:valueFile: helm/values.yamlcommitChange: truebranch: mainmessage: Update Image Version to ${{ steps.vars.outputs.sha_short }}changes: |{backend.tag: ${{ steps.vars.outputs.sha_short }},frontend.tag: ${{ steps.vars.outputs.sha_short }}}使用了 GitHub Action 中yaml-update-action插件来修改 values.yaml 文件并把它推送到仓库。如果你是使用 GitLab 或者 Tekton 构建镜像可以调用 jq 命令行工具来修改 YAML 文件再使用 git 命令行将变更推送到仓库。 到这里 一个完整的 GitOps 工作流就建立好了。 体验 GitOps 工作流 尝试修改 frontend/src/App.js 文件例如修改文件第 49 行的“Hi! I am a geekbang”。修改完成后 将代码推送到 GitHub 仓库 main 分支此时GitHub Action 会自动构建镜像并且还会更新代码仓库中 Helm values.yaml 文件的镜像版本。 这里遇到一点小插曲在GitHub Action自动构建镜像时报异常
HttpError: Resource not accessible by integration参考解决资料https://www.drixn.com/3074.html
ArgoCD 默认每 3 分钟会拉取仓库检查是否有新的提交你也可以在 ArgoCD 控制台手动点击 Sync 按钮来触发同步。 ArgoCD 同步完成后我们可以在“LAST SYNC RESULT”一栏中看到 GitHub Action 修改 values.yaml 的提交记录当应用状态为 Healthy 时我们就可以访问新的应用版本了。
生产建议
1修改默认密码
注
修改密码前先使用 argocd login 登录到 ArgoCD 服务端。
$ argocd account update-password
*** Enter password of currently logged in user (admin):
*** Enter new password for user admin:2配置 Ingress 和 TLS
前提
需要安装 Cert-manageringress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:name: argocd-server-ingressnamespace: argocdannotations:cert-manager.io/cluster-issuer: letsencrypt-prodkubernetes.io/ingress.class: nginxkubernetes.io/tls-acme: truenginx.ingress.kubernetes.io/ssl-passthrough: truenginx.ingress.kubernetes.io/backend-protocol: HTTPS
spec:rules:- host: argocd.example.comhttp:paths:- path: /pathType: Prefixbackend:service:name: argocd-serverport:name: httpstls:- hosts:- argocd.example.comsecretName: argocd-secret # do not change, this is provided by Argo CD3使用 Webhook 触发 ArgoCD 我们在创建应用的时候提供了参数 --sync-policyautomated。这时候ArgoCD 会默认以 3 分钟一次的频率来自动拉取仓库的更改在生产环境下这个同步频率可能并不能满足快速发布的要求。 如果 ArgoCD 可以在公网进行访问建议使用 ArgoCD 提供的 Webhook 触发方式来解决这个问题了如下图所示 和主动 Poll 模型不同的是源码仓库在收到开发者推送代码的事件后将实时通过 HTTP 请求来通知 ArgoCD也就是图中红色字体的部分。 要使用 Webhook 通知的方式首先你需要在源码仓库进行配置。以 GitHub 为例首先进入仓库的“Settings”页面点击左侧的“Webhook”菜单进入配置页面如下图: 在 Payload URL 中输入你的 ArgoCD Server 外网访问域名/api/webhook ArgoCD 专门用于接收外部 Webhook 消息的固定路径。 Content type 选择 application/json并在 Secret 中输入你要配置的 Webhook 的密钥这个密钥需要提供给 ArgoCD 来校验 Webhook 来源是否合法 接下来你还需要为 ArgoCD 提供 GitHub Webhook 密钥使用下面的命令来编辑 argocd-secret 对象。 $ kubectl edit secret argocd-secret -n argocd
apiVersion: v1
kind: Secret
metadata:name: argocd-secretnamespace: argocd
type: Opaque
data:
...
stringData:# 加入这一项webhook.github.secret: my-secret注意stringData 可以直接输入 Webhook Secret 内容而不需要进行 Base64 编码。 如果你使用的是其他的代码托管平台例如 GitLab可以参考 https://argo-cd.readthedocs.io/en/stable/operator-manual/webhook/进行配置。
4将源码仓库和应用定义仓库分离 本次实践将示例应用的源码和 Helm Chart 存储在了同一个 Git 仓库实际上 这并不是一个好的实践。 这种方案有两个比较大的问题。首先当我们手动修改 Helm Chart 并推送到 Git 仓库之后在业务代码不变的情况下也会触发应用镜像构建这个过程是没有必要的。 其次在有一定规模的团队中开发和发布过程是分开的应用定义仓库一般只有基础架构部门或者 SRE 部门具有修改权限将源码和应用定义放在同一个 Git 仓库不利于权限控制开发者也很容易误操作。 所以基于上面这两个问题强烈建议将业务代码和应用定义分开存储管理。 5加密 GitOps 中存储的秘钥 本次实践使用的是 DockerHub 公开仓库所以 Kubernetes 集群不需要镜像拉取凭据就可以拉取到镜像。 在实际生产环境下一般我们会使用内部自建例如 Harbor 私有仓库。所以在大部分情况下我们会在 Helm Chart 里增加一个包含镜像拉取凭据的 Secret 对象。 apiVersion: v1
kind: Secret
metadata:name: regcred
type: kubernetes.io/dockerconfigjson
data:.dockerconfigjson: -eyJhdXRocyI6eyJodHRwczovL2luZGV4LmRvY2tlcxxxxS8iOnsidXNlcm5hbWUiOiJseXpoYW5nMTk5OSIsInBhc3N3b3JkIjoibXktdG9rZW4iLCJhdXRoIjoiYkhsNmFHRnVaekU1T1RrNmJYa3RkRzlyWlc0PSJ9fX0当 ArgoCD 部署应用时会一并将拉取凭据部署到集群中这就解决了镜像拉取权限的问题。 但是Secret 对象并没有加密功能 这可能会导致凭据泄露。 所以我们需要对这些敏感信息进行加密处理。关于如何加密秘钥是一个遗留项
