如果您想了解Tekton与ArgoCD结合实现GitOps和tektontrigger的知识,那么本篇文章将是您的不二之选。我们将深入剖析Tekton与ArgoCD结合实现GitOps的各个方面,并为
如果您想了解Tekton 与 Argo CD 结合实现 GitOps和tekton trigger的知识,那么本篇文章将是您的不二之选。我们将深入剖析Tekton 与 Argo CD 结合实现 GitOps的各个方面,并为您解答tekton trigger的疑在这篇文章中,我们将为您介绍Tekton 与 Argo CD 结合实现 GitOps的相关知识,同时也会详细的解释tekton trigger的运用方法,并给出实际的案例分析,希望能帮助到您!
本文目录一览:- Tekton 与 Argo CD 结合实现 GitOps(tekton trigger)
- Argo CD使用指南:如何构建一套完整的GitOps?
- ArgoCD + KubeVela:以开发者为中心的 GitOps
- ArgoCD + KubeVela:以开发者为中心的GitOps
- DevOps 选型指南:Zadig / 云效 / Coding/Jenkins/GitLab/Argo/Tekton
Tekton 与 Argo CD 结合实现 GitOps(tekton trigger)
前面我们使用 Tekton 完成了应用的 CI/CD 流程,但是 CD 是在 Tekton 的任务中去完成的,现在我们使用 GitOps 的方式来改造我们的流水线,将 CD 部分使用 Argo CD 来完成。

这里我们要先去回顾下前面的 Tekton 实战部分的内容,整个流水线包括 clone、test、build、docker、deploy、rollback 几个部分的任务,最后的 deploy 和 rollback 属于 CD 部分,我们只需要这部分使用 Argo CD 来构建即可。
首先我们将项目 http://git.k8s.local/course/devops-demo.git
仓库中的 Helm Chart 模板单独提取出来放到一个独立的仓库中 http://git.k8s.local/course/devops-demo-deploy
,这样方便和 Argo CD 进行对接,整个项目下面只有用于应用部署的 Helm Chart 模板。

首先在 Argo CD 上面添加该仓库:

然后创建新应用,首先可以创建一个项目,在 Argo CD 中有一个 AppProject 的 CRD,表示应用程序的逻辑分组,它由以下几个关键属性组成:
-
sourceRepos
:项目中的应用程序可以从中获取清单的仓库引用 -
destinations
:项目中的应用可以部署到的集群和命名空间 -
roles
:项目内资源访问定义的角色
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
# 项目名
name: demo
namespace: argocd
spec:
# 目标
destinations:
# 此项目的服务允许部署的 namespace,这里为全部
- namespace: ''*''
# 此项目允许部署的集群,这里为默认集群,即为Argo CD部署的当前集群
server: https://kubernetes.default.svc
# 允许的数据源
sourceRepos:
- http://git.k8s.local/course/devops-demo-deploy.git
更多配置信息可以前往文档 https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/ 查看,项目创建完成后,在该项目下创建一个 Application,代表环境中部署的应用程序实例。
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: devops-demo
namespace: argocd
spec:
destination:
namespace: default
server: ''https://kubernetes.default.svc''
project: demo
source:
path: helm # 从 Helm 存储库创建应用程序时,chart 必须指定 path
repoURL: ''http://git.k8s.local/course/devops-demo-deploy.git''
targetRevision: HEAD
helm:
parameters:
- name: replicaCount
value: ''2''
valueFiles:
- my-values.yaml
这里我们定义了一个名为 devops-demo
的应用,应用源来自于 helm 路径,使用的是 my-values.yaml
文件,此外还可以通过 source.helm.parameters
来配置参数,同步策略我们仍然选择使用手动的方式,我们可以在 Tekton 的任务中去手动触发同步。上面的资源对象创建完成后应用就会处于 OutOfSync
状态,因为集群中还没部署该应用。

现在接下来我们去修改之前的 Tekton 流水线,之前的 Pipeline 流水线如下所示:
# pipeline.yaml
apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
name: pipeline
spec:
workspaces: # 声明 workspaces
- name: go-repo-pvc
params:
# 定义代码仓库
- name: git_url
- name: revision
type: string
default: "master"
# 定义镜像参数
- name: image
- name: registry_url
type: string
default: "harbor.k8s.local"
- name: registry_mirror
type: string
default: "https://ot2k4d59.mirror.aliyuncs.com/"
# 定义 helm charts 参数
- name: charts_dir
- name: release_name
- name: release_namespace
default: "default"
- name: overwrite_values
default: ""
- name: values_file
default: "values.yaml"
tasks: # 添加task到流水线中
- name: clone
taskRef:
name: git-clone
workspaces:
- name: output
workspace: go-repo-pvc
params:
- name: url
value: $(params.git_url)
- name: revision
value: $(params.revision)
- name: test
taskRef:
name: test
- name: build # 编译二进制程序
taskRef:
name: build
runAfter: # 测试任务执行之后才执行 build task
- test
- clone
workspaces: # 传递 workspaces
- name: go-repo
workspace: go-repo-pvc
- name: docker # 构建并推送 Docker 镜像
taskRef:
name: docker
runAfter:
- build
workspaces: # 传递 workspaces
- name: go-repo
workspace: go-repo-pvc
params: # 传递参数
- name: image
value: $(params.image)
- name: registry_url
value: $(params.registry_url)
- name: registry_mirror
value: $(params.registry_mirror)
- name: deploy # 部署应用
taskRef:
name: deploy
runAfter:
- docker
workspaces:
- name: source
workspace: go-repo-pvc
params:
- name: charts_dir
value: $(params.charts_dir)
- name: release_name
value: $(params.release_name)
- name: release_namespace
value: $(params.release_namespace)
- name: overwrite_values
value: $(params.overwrite_values)
- name: values_file
value: $(params.values_file)
- name: rollback # 回滚
taskRef:
name: rollback
when:
- input: "$(tasks.deploy.results.helm-status)"
operator: in
values: ["failed"]
params:
- name: release_name
value: $(params.release_name)
- name: release_namespace
value: $(params.release_namespace)
现在我们需要去掉最后的 deploy 和 rollback 两个任务,当 Docker 镜像构建推送完成后,我们只需要去修改部署代码仓库中的 values 文件,然后再去手动触发 Argo CD 同步状态即可(如果开启了自动同步这一步都可以省略了),而回滚操作直接在 Argo CD 中去操作即可,不需要定义一个单独的 Task 任务。
定义一个如下所示的 Taks 任务:
apiVersion: tekton.dev/v1alpha1
kind: Task
metadata:
name: sync
spec:
volumes:
- name: argocd-secret
secret:
secretName: $(inputs.params.argocd_secret)
params:
- name: argocd_url
description: "The URL of the ArgoCD server"
- name: argocd_secret
description: "The secret containing the username and password for the tekton task to connect to argo"
- name: commit_id
description: "The commit ID to update"
- name: app_name
description: "The name of the argo app to update"
- name: app_revision
default: "HEAD"
description: "The revision of the argo app to update"
steps:
- name: deploy
image: argoproj/argocd
volumeMounts:
- name: argocd-secret
mountPath: /var/secret
command:
- sh
args:
- -ce
- |
set -e
echo "update commit id"
argocd login --insecure $(params.argocd_url) --username $(/bin/cat /var/secret/username) --password $(/bin/cat /var/secret/password)
argocd app sync $(params.app_name) --revision $(params.app_revision)
argocd app wait $(params.app_name) --health
由于我们这里只需要修改 Helm Chart 的 Values 文件中的 image.tag
参数,最好的方式当然还是在一个 Task 中去修改 values.yaml 文件并 commit 到 Repo 仓库中去,当然也可以为了简单直接在 Argo CD 的应用侧配置参数即可,比如可以使用 argocd app set
命令来为应用配置参数,然后下面再用 argocd app sync
命令手动触发同步操作,这里其实就可以有很多操作了,比如我们可以根据某些条件来判断是否需要部署,满足条件后再执行 sync 操作,最后使用 wait
命令等待应用部署完成。
除了通过手动 argocd app set
的方式来配置参数之外,可能更好的方式还是直接去修改 Repo 仓库中的 values 值,这样在源代码仓库中有一个版本记录,我们可以新建如下所示的一个任务用来修改 values 值:
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
name: change-manifests
spec:
params:
- name: git_url
description: Git repository containing manifest files to update
- name: git_email
default: pipeline@k8s.local
- name: git_name
default: Tekton Pipeline
- name: git_manifest_dir
description: Manifests files dir
- name: tool_image
default: cnych/helm-kubectl-curl-git-jq-yq
- name: image_tag
description: Deploy docker image tag
steps:
- name: git-push
image: $(params.tool_image)
env:
- name: GIT_USERNAME
valueFrom:
secretKeyRef:
name: gitlab-auth
key: username
optional: true
- name: GIT_PASSWORD
valueFrom:
secretKeyRef:
name: gitlab-auth
key: password
optional: true
command: ["/bin/bash"]
args:
- -c
- |
set -eu
echo Load environment variables from previous steps
source /workspace/env-config
git config --global user.email "$(params.git_email)"
git config --global user.name "$(params.git_name)"
git clone --branch master --depth 1 http://${GIT_USERNAME}:${GIT_PASSWORD}@$(params.git_url) repo
cd "repo/$(params.git_manifest_dir)"
ls -l
echo old value:
cat my-values.yaml | yq r - ''image.tag''
echo replacing with new value:
echo $(params.image_tag)
yq w --inplace my-values.yaml ''image.tag'' "$(params.image_tag)"
echo verifying new value
yq r my-values.yaml ''image.tag''
if ! git diff-index --quiet HEAD --; then
git status
git add .
git commit -m "helm values updated by tekton pipeline in change-manifests task"
git push
else
echo "no changes, git repository is up to date"
fi
现在我们的流水线就变成了如下所示的清单:
# pipeline.yaml
apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
name: pipeline
spec:
workspaces: # 声明 workspaces
- name: go-repo-pvc
params:
# 定义代码仓库
- name: git_url
- name: git_infra_url
- name: revision
type: string
default: "master"
# 定义镜像参数
- name: image
- name: image_tag
- name: registry_url
type: string
default: "harbor.k8s.local"
- name: registry_mirror
type: string
default: "https://ot2k4d59.mirror.aliyuncs.com/"
- name: git_manifest_dir
default: "helm"
# 定义 argocd 参数
- name: argocd_url
- name: argocd_secret
- name: app_name
- name: app_revision
type: string
default: "HEAD"
tasks: # 添加task到流水线中
- name: clone
taskRef:
name: git-clone
workspaces:
- name: output
workspace: go-repo-pvc
params:
- name: url
value: $(params.git_url)
- name: revision
value: $(params.revision)
- name: test
taskRef:
name: test
- name: build # 编译二进制程序
taskRef:
name: build
runAfter: # 测试任务执行之后才执行 build task
- test
- clone
workspaces: # 传递 workspaces
- name: go-repo
workspace: go-repo-pvc
- name: docker # 构建并推送 Docker 镜像
taskRef:
name: docker
runAfter:
- build
workspaces: # 传递 workspaces
- name: go-repo
workspace: go-repo-pvc
params: # 传递参数
- name: image
value: $(params.image):$(params.image_tag)
- name: registry_url
value: $(params.registry_url)
- name: registry_mirror
value: $(params.registry_mirror)
- name: manifests
taskRef:
name: change-manifests
runAfter:
- docker
params:
- name: git_url
value: $(params.git_infra_url)
- name: git_manifest_dir
value: $(params.git_manifest_dir)
- name: image_tag
value: $(params.image_tag)
- name: sync
taskRef:
name: sync
runAfter:
- manifests
params:
- name: argocd_url
value: $(params.argocd_url)
- name: argocd_secret
value: $(params.argocd_secret)
- name: app_name
value: $(params.app_name)
- name: app_revision
value: $(params.app_revision)
最后创建用于 Argo CD 登录使用的 Secret 对象:
apiVersion: v1
kind: Secret
metadata:
name: argocd-auth
type: Opaque
stringData:
username: admin
password: admin321
最后修改 Tekton Triggers 中的 Template,如下所示:
# gitlab-template.yaml
apiVersion: triggers.tekton.dev/v1alpha1
kind: TriggerTemplate
metadata:
name: gitlab-template
spec:
params: # 定义参数,和 TriggerBinding 中的保持一致
- name: gitrevision
- name: gitrepositoryurl
resourcetemplates: # 定义资源模板
- apiVersion: tekton.dev/v1beta1
kind: PipelineRun # 定义 pipeline 模板
metadata:
generateName: gitlab-run- # TaskRun 名称前缀
spec:
serviceAccountName: tekton-build-sa
pipelineRef:
name: pipeline
workspaces:
- name: go-repo-pvc
persistentVolumeClaim:
claimName: go-repo-pvc
params:
- name: git_url
value: $(tt.params.gitrepositoryurl)
- name: git_infra_url
value: git.k8s.local/course/devops-demo-deploy.git
- name: image
value: "harbor.k8s.local/course/devops-demo"
- name: image_tag
value: "$(tt.params.gitrevision)"
- name: argocd_url
value: argocd.k8s.local
- name: argocd_secret
value: argocd-auth
- name: app_name
value: devops-demo
现在我们的整个流水线就更加精简了。现在我们去应用仓库中修改下源代码并提交就可以触发我们的流水线了。

可以看到当我们提交代码后,整个流水线构建会一直卡在最后的 sync 任务,这是因为我们执行了 argocd app wait $(params.app_name) --health
这个命令,需要等待应用健康后才会退出。
$ curl devops-demo.k8s.local
{"msg":"Hello Tekton + ArgoCD On GitLab"}
但实际上上面我们的应用已经部署成功了,只是 Argo CD 的健康检查没有通过,Argo CD 为几种标准的 Kubernetes 资源提供了内置的健康策略,然后将这些策略作为一个整体呈现在应用的健康状态中,比如会检查副本数是否正常,PVC 是否绑定等,而对于 Ingress 资源会检查 status.loadBalancer.ingress
列表是否非空,需要至少有一个 hostname 或 IP 值,而我们这里部署的 Ingress 中的值为空:
$ kubectl get ingress devops-demo -o yaml
apiVersion: extensions/v1beta1
kind: Ingress
......
spec:
rules:
- host: devops-demo.k8s.local
http:
paths:
- backend:
serviceName: devops-demo
servicePort: http
path: /
pathType: ImplementationSpecific
status:
loadBalancer: {}
所以健康检查一直不通过,在 Argo CD 页面上也可以证实是 Ingress 导致健康检查没通过:

这个时候需要我们去自定义 Ingress 资源的监控检查方式,Argo CD 支持用 Lua 来编写检查规则,修改 Argo CD 的 Configmap 配置文件:
$ kubectl edit cm -n argocd argocd-cm
# Please edit the object below. Lines beginning with a ''#'' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
data:
resource.customizations: | # 定制 Ingress 资源的健康检查方式
extensions/Ingress:
health.lua: |
hs = {}
hs.status = "Healthy"
return hs
......
修改完成后,我们的应用就会变成健康状态了。

如果需要回滚,则可以直接在 Argo CD 页面上点击 HISTORY AND ROLLBACK
安装查看部署的历史记录选择回滚的版本即可:

可以查看整个 Tekton 流水线的状态:
$ tkn pr describe gitlab-run-vdlm6
Name: gitlab-run-vdlm6
Namespace: default
Pipeline Ref: pipeline
Service Account: tekton-build-sa
Timeout: 1h0m0s
Labels:
tekton.dev/pipeline=pipeline
triggers.tekton.dev/eventlistener=gitlab-listener
triggers.tekton.dev/trigger=gitlab-push-events-trigger
triggers.tekton.dev/triggers-eventid=eeda9157-5eb3-4399-be4b-88955cb56764
️ Status
STARTED DURATION STATUS
4 minutes ago 2 minutes Succeeded
Resources
No resources
⚓ Params
NAME VALUE
∙ git_url http://git.k8s.local/course/devops-demo.git
∙ git_infra_url git.k8s.local/course/devops-demo-deploy.git
∙ image harbor.k8s.local/course/devops-demo
∙ image_tag 332798d9e28422341fd64704ab9b54b944d77084
∙ argocd_url argocd.k8s.local
∙ argocd_secret argocd-auth
∙ app_name devops-demo
Results
No results
Workspaces
NAME SUB PATH WORKSPACE BINDING
∙ go-repo-pvc --- PersistentVolumeClaim (claimName=go-repo-pvc)
Taskruns
NAME TASK NAME STARTED DURATION STATUS
∙ gitlab-run-vdlm6-sync-svmxl sync 3 minutes ago 42 seconds Succeeded
∙ gitlab-run-vdlm6-manifests-d297d manifests 3 minutes ago 26 seconds Succeeded
∙ gitlab-run-vdlm6-docker-g2tqx docker 4 minutes ago 48 seconds Succeeded
∙ gitlab-run-vdlm6-build-mkcrd build 4 minutes ago 9 seconds Succeeded
∙ gitlab-run-vdlm6-test-gjr4c test 4 minutes ago 4 seconds Succeeded
∙ gitlab-run-vdlm6-clone-57vpw clone 4 minutes ago 8 seconds Succeeded

最后用一张图来总结下我们使用 Tekton 结合 Argo CD 来实现 GitOps 的工作流:

K8S 进阶训练营



扫描二维码获取
更多云原生知识
k8s 技术圈
文章转载自 k8s 技术圈。点击这里阅读原文了解更多。
中国 KubeCon + CloudNativeCon 演讲提案征集|截止日期:7 月 25 日
CNCF 概况(幻灯片)
扫描二维码联系我们!
CNCF (Cloud Native Computing Foundation) 成立于 2015 年 12 月,隶属于 Linux Foundation,是非营利性组织。
CNCF(云原生计算基金会)致力于培育和维护一个厂商中立的开源生态系统,来推广云原生技术。我们通过将最前沿的模式民主化,让这些创新为大众所用。请长按以下二维码进行关注。
本文分享自微信公众号 - CNCF(lf_cncf)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与 “OSC 源创计划”,欢迎正在阅读的你也加入,一起分享。
Argo CD使用指南:如何构建一套完整的GitOps?
随着Kubernetes继续将自己确立为容器编排的行业标准,为你的应用和工具找到使用声明式模型的有效方法是成功的关键。在这篇文章中,我们将在AWS中建立一个K3s Kubernetes集群,然后使用Argo CD和Vault实现安全的GitOps。你可以在以下两个链接中分别查看基础架构以及Kubernetes umbrella应用程序:
https://github.com/atoy3731/a...
https://github.com/atoy3731/k...
以下是我们将会使用到的组件:
- AWS——这是我们将在底层基础设施使用的云提供商。它将管理我们的虚拟机以及Kubernetes工作所需的网络,并允许Ingress从外界进入集群。
- K3s——由Rancher开发的轻量级Kubernetes发行版。它对许多alpha功能和云插件进行了清理,同时也使用关系型数据库(本例中是RDS)代替etcd进行后端存储。
- Rancher——API驱动的UI,可以轻松管理你的Kubernetes集群
- Vault——Hashicorp的密钥管理实现。我将使用Banzai Cloud Vault的bank-- vaults实现,它可以通过使用Admission Webhook将密钥直接注入pod中。这大大减轻了你在Git仓库中存储密钥的需求。
- Argo CD——这是一个GitOps工具,可以让你在Git中维护Kubernetes资源的状态。Argo CD会自动将你的Kubernetes资源与Git仓库中的资源进行同步,同时也确保集群内对manifest的手动更改会自动还原。这保证了你的声明式部署模式。
- Cert Manager或LetsEncrypt——提供了一种为Kubernetes Ingress自动生成和更新证书的方法。
让我们先从AWS基础架构开始。
前期准备
你需要在你的系统中安装以下CLI:
- Terraform
- Kubectl
- AWS
同时,你还需要AWS管理员访问权限以及一个访问密钥。如果你没有,你可以使用信用卡创建一个账户。
最后,你需要一个可以管理/更新的托管域名,以指向你的基于Kubernetes弹性负载均衡器(ELB)。如果你还没有,建议你在NameCheap上开一个账户,然后购买一个.dev域名。它价格便宜,而且效果很好。
AWS基础架构
对于我们的AWS基础架构,我们将使用Terraform与S3支持来持久化状态。这为我们提供了一种方法来声明性地定义我们的基础架构,并在我们需要的时候反复进行更改。在基础设施仓库中,你会看到一个k3s/example.tfvars文件。我们需要根据我们特定的环境/使用情况更新这个文件,设置以下值:
- db_username — 将应用于Kubernetes后端存储的RDS实例的管理员用户名
- db_password — RDS用户的管理员密码。这通常应该在你的terraform apply命令内联过程中传递此参数,但为了简单起见,我们将在文件中设置它。
- public_ssh_key — 你的公共SSH密钥,当你需要SSH到Kubernetes EC2s时,你将使用它。
- keypair_name — 要应用于你的public_ssh_key的密钥对名称。
- key_s3_bucket_name — 生成的bucket将在集群成功创建时存储你的kubeconfig文件。
如果你想修改集群大小或设置特定的CIDRs(无类域间路由),可以设置下面的一些可选字段,但默认情况下,你会得到一个6节点(3个服务器,3个代理)的K3s集群。
同时,你将需要创建S3 bucket来存储你的Terraform状态并且在k3s/backends/s3.tfvars和k3s/main.tf文件中更改bucket字段来与其匹配。
一旦我们更新了所有的字段,并创建了S3状态bucket,我们就开始应用Terraform吧。首先,确保你在AWS账户中有一个管理IAM用户并且你已经在系统上正确设置了环境变量或AWS凭证文件,以便能够与AWS API对接,然后运行以下命令:
cd k3s/
terraform init -backend-config=backends/s3.tfvars
terraform apply -var-file=example.tfvars
一旦你执行以上命令,Terraform会在apply成功后输出预期的AWS状态。如果一切看起来都符合预期,请输入yes。这时候由于RDS集群的原因,需要5—10分钟的时间来配置AWS资源。
验证你的Kubernetes集群
Terraform成功应用之后(再多等几分钟的时间确保K3s已经部署完毕),你需要使用以下命令从S3 bucket中抓取kubeconfig文件(替换你在example.tfvars
中输入的bucket名称):
aws s3 cp s3://YOUR_BUCKET_NAME/k3s.yaml ~/.kube/config
这应该成功完成,让你现在能够与你的集群通信。让我们检查一下我们的节点状态,在继续之前,确保它们都处于就绪状态。
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
ip-10-0-1-208.ec2.internal Ready <none> 39m v1.18.9+k3s1
ip-10-0-1-12.ec2.internal Ready master 39m v1.18.9+k3s1
ip-10-0-1-191.ec2.internal Ready master 39m v1.18.9+k3s1
ip-10-0-2-12.ec2.internal Ready master 39m v1.18.9+k3s1
ip-10-0-2-204.ec2.internal Ready <none> 39m v1.18.9+k3s1
ip-10-0-1-169.ec2.internal Ready <none> 39m v1.18.9+k3s1
我们也来看看Argo CD的状态,它是通过manifest自动部署的:
$ kubectl get pods -n kube-system | grep argocd
helm-install-argocd-5jc9s 0/1 Completed 1 40m
argocd-redis-774b4b475c-8v9s8 1/1 Running 0 40m
argocd-dex-server-6ff57ff5fd-62v9b 1/1 Running 0 40m
argocd-server-5bf58444b4-mpvht 1/1 Running 0 40m
argocd-repo-server-6d456ddf8f-h9gvd 1/1 Running 0 40m
argocd-application-controller-67c7856685-qm9hm 1/1 Running 0 40m
现在我们可以继续为我们的ingress和证书自动化配置通配符DNS。
DNS配置
对于DNS,我通过Namecheap获得atoy.dev域名,但你可以使用任何你喜欢的DNS供应商。我们需要做的是创建一个通配符CNAME条目,以将所有请求路由到AWS ELB,它正在管理应用程序的ingress。
首先,通过访问你的AWS控制台获取你的弹性负载均衡器主机名称——导航到EC2部分并在左边菜单栏上点击Load Balancers。然后你应该看到一个使用随机字符创建的新LoadBalancer。如果你检查tag,它应该引用你的新Kubernetes集群。
你需要从该条目复制DNS名称。为我的域名访问NamecCheap 高级DNS页面,并输入*.demo.atoy.dev 的CNAME条目。 指向你从AWS复制的域名。你可以根据你的提供商/域名调整这个名称:
要验证它是否有效,你可以安装/使用nslookup来确保它解析到正确的主机名:
$ nslookup test.demo.atoy.dev
Server: 71.252.0.12
Address: 71.252.0.12#53
Non-authoritative answer:
test.demo.atoy.dev canonical name = a4c6dfd75b47a4b1cb85fbccb390fe1f-529310843.us-east-1.elb.amazonaws.com.
Name: a4c6dfd75b47a4b1cb85fbccb390fe1f-529310843.us-east-1.elb.amazonaws.com
Address: 52.20.5.150
Name: a4c6dfd75b47a4b1cb85fbccb390fe1f-529310843.us-east-1.elb.amazonaws.com
Address: 23.20.0.2
现在到Umbrella应用程序。
Argo CD和Umbrella应用程序
我们已经知道Argo CD已经部署好了,但现在我们要使用Argo CD的App-of-Apps部署模型来部署我们的其余工具套件。由于我们使用的是GitOps,你需要将k8s-tools-app仓库fork到你自己的Github账户上,然后我们需要做一些修改来匹配你各自的环境。
- 你需要为https://github.com/atoy3731/k... 进行全局查找/替换,并将其更改到之前fork的新存储库git URL。这使你可以管理自己的环境,让Argo CD可以从那里拉取。另外,需要确保你的Git仓库是公开的,以便Argo CD可以访问它。
- 在resources/tools/resources/other-resources.yaml中,更改argoHostand issuerEmail,使其与你的域名和邮箱相匹配。
- 在resources/tools/resources/rancher.yaml中,更改主机名称和邮件以匹配各自的域名和email。
- 在resources/apps/resources/hello-world.yaml中,将两个引用app.demo.aptoy.dev改为与你的域名一致。
一旦你做了这些更新,继续提交/推送你的更改到你的forked Github仓库。现在你已经准备好应用umbrella应用程序了。在本地克隆的仓库中执行以下操作:
$ kubectl apply -f umbrella-tools.yaml
appproject.argoproj.io/tools created
application.argoproj.io/umbrella-tools created
现在,Argo CD将开始配置所有其他工具,这些工具是仓库为你的集群定义的。你可以通过执行以下操作来获得已部署的应用程序的列表:
$ kubectl get applications -n kube-system
NAME AGE
other-resources 56m
umbrella-tools 58m
rancher 57m
vault-impl 57m
vault-operator 58m
vault-webhook 57m
cert-manager 57m
cert-manager-crds 58m
你将不得不等待5分钟左右的时间,让一切都准备好,让LetsEncrypt生成暂存证书。一旦事情按预期运行,你应该看到两个生成的Ingress条目,你可以通过浏览器访问:
$ kubectl get ingress -A
NAMESPACE NAME CLASS HOSTS ADDRESS PORTS AGE
cattle-system rancher <none> rancher.demo.atoy.dev a4c6dfd75b47a4b1cb85fbccb390fe1f-529310843.us-east-1.elb.amazonaws.com 80, 443 59m
kube-system argocd-ingress <none> argo.demo.atoy.dev a4c6dfd75b47a4b1cb85fbccb390fe1f-529310843.us-east-1.elb.amazonaws.com 80, 443 58m
现在你可以通过 https://rancher.YOUR-DOMAIN 浏览 Rancher,通过 https://argo.YOUR-DOMAIN 浏览 Argo CD。
NOTE 1:为了避免LetsEncrypt的任何速率限制,我们使用的是无效的暂存证书。这有一个好处是当你在你的浏览器访问Argo、Rancher或你的hello world应用程序,它会给你一个SSL异常。使用Chrome浏览器,在你的异常页面加载时输入thisisunsafe,它会让你绕过它。你也可以了解更新Cert-manager的ClusterIssuer,以使用生产级的可信证书。
NOTE 2:K3s预装了一个Traefik作为ingress controller,出于简单起见,我们直接使用它。
NOTE 3:首次登录Rancher后,你需要生成一个密码,并接受用于访问Rancher的URI。URI应该是预先加载在表单中的,所以您可以直接点击 "Okay"。
NOTE 4: 要登录Argo CD,它使用admin作为用户名,使用argocd-server pod名作为密码。你可以通过下面的操作来获得这个服务器的pod名(本例中是argocd-server-5bf58444b4-mpvht)。
$ kubectl get pods -n kube-system | grep argocd-server
argocd-server-5bf58444b4-mpvht 1/1 Running 0 64m
现在你应该能够访问Argo CD UI,登录并查看,如下所示:
既然我们的工具已经部署完成,让我们在Vault中存储密钥,以便hello world应用程序提取。
在Vault中创建密钥
为了让事情变得简单,在你的工具库中有一个帮助脚本。运行以下命令来获取Vault管理员令牌和端口转发命令:
$ sh tools/vault-config.sh
Your Vault root token is: s.qEl4Ftr4DR61dmbH3umRaXP0
Run the following:
export VAULT_TOKEN=s.qEl4Ftr4DR61dmbH3umRaXP0
export VAULT_CACERT=/Users/adam.toy/.vault-ca.crt
kubectl port-forward -n vault service/vault 8200 &
You will then be able to access Vault in your browser at: [https://localhost:8200](https://localhost:8200)
运行输出的命令,然后导航到https://localhost:8200。输入上面的root token进行登录。
当你登录时,你应该在一个密钥引擎页面。点击Secret/条目,然后点击右上方的创建密钥。我们将创建一个demo密钥,所以添加以下内容并点击保存:
现在我们已经为hello world应用程序准备好密钥了。
部署Hello World 应用程序
现在,回到我们的父版本,让我们运行下面的代码来部署hello world应用程序:
$ kubectl apply -f umbrella-apps.yaml
appproject.argoproj.io/apps created
application.argoproj.io/umbrella-apps created
创建完成后,回到Argo CD UI,你先应该看到两个新应用程序,umbrella-apps和demo-app。单击demo-app,然后等待所有资源正常运行:
一旦状态都是healthy之后,你应该能够通过访问https://app.YOUR-DOMAIN 导航到你的应用程序。
让我们也来验证一下我们的Vault密钥是否被注入到我们的应用程序pod中。在Argo CD UI的demo-app中,点击应用程序的一个Pod,然后点击顶部的日志标签。左边应该有两个容器,选择 test-deployment容器。在日志的顶部,你应该看到你的密钥在两行等号之间:
测试GitOps
现在我们来测试一下Argo CD,确保当我们在仓库中做一些更改时它能够自动同步。
在你的工具库中,找到resources/apps/resources/hello-world.yaml文件,将replicaCount的值从5改到10。提交并推送你的更改到主分支,然后在Argo CD UI中导航回demo-app。当Argo CD达到它的刷新间隔时,它会自动开始部署其他5个应用程序副本(如果你不想等待,可以点击你的 umbrella-apps Argo应用程序 ** 中的刷新按钮):
清 除
如果你准备拆掉你的集群,你需要先进入AWS控制台、EC2服务,然后点击Load Balancers。你会看到Kubernetes云提供商创建了一个ELB,但不是由Terraform管理的,你需要清理它。你还需要删除该ELB正在使用的安全组。
清理了ELB之后,运行以下命令并在出现提示时输入yes:
terraform destroy -var-file=example.tfvars
下一步是什么?
我们已经有一个很好的工具集来使用GitOps部署应用程序。那么下一步是什么?如果你愿意接受挑战,可以尝试在hello world应用旁边部署自己的应用,甚至尝试通过在应用manifest仓库中更新镜像标签来实现CI/CD。这样一来,当构建新的应用镜像时,新的标签就会在manifest仓库中自动更新,Argo CD就会部署新版本。
ArgoCD + KubeVela:以开发者为中心的 GitOps
:10 人将获赠 CNCF 士多 $100 礼券!
来参与 2020 年 CNCF 中国云原生调查
问卷链接(https://www.wjx.cn/jq/97146486.aspx)
客座文章作者:Deng Hongchao,阿里巴巴软件工程师
介绍
Argo CD 是为 Kubernetes 提供的 GitOps 持续交付工具。它是 CNCF Argo 项目的一部分,该项目是一组 Kubernetes 原生工具,用于在 Kubernetes 上运行和管理作业和应用程序。
https://github.com/argoproj/argo-cd/
KubeVela 是一个基于 Kubernetes 和 OAM(开放应用程序模型,Open Application Model)的开源应用程序引擎。KubeVela 主要是为平台和运营团队设计的,以便在 Kubernetes 上轻松创建简单但面向开发人员的高度可扩展的抽象。对开发人员(也就是最终用户)隐藏了在 Kubernetes 上配置应用程序清单的很多复杂性,比如伸缩策略、部署策略和入口,但允许平台团队基于组织策略独立定制和控制这些配置。
https://github.com/oam-dev/kubevela
在这篇博文中,我们将分享基于阿里云的用例,使用 Argo CD 和 KubeVela 构建以开发者为中心的持续应用交付流水线的经验。
以开发者为中心的 GitOps 体验
理想情况下,开发人员希望专注于编写应用程序并将其代码推送到 git 仓库上,而不必担心 CI/CD 流水线以及配置和运行应用程序时的其他操作问题。Kubernetes 上一个非常流行的模式是将应用程序从 git 自动部署到生产环境中。这就是 Argo CD 的用武之地。它会持续监视 git 仓库的新提交,并自动将它们部署到生产环境中。Argo CD 应用仓库中预定义的 Kubernetes 部署清单文件来创建或升级在 Kubernetes 上运行的应用程序。这种模式被称为 GitOps,是在阿里巴巴的现代云原生堆栈中实现持续自动应用交付的关键。
虽然概念上很简单,但在将 GitOps 应用到更广泛的最终用户场景时,会出现几个重要的问题。第一个问题是,实际的生产应用程序是复杂的,需要开发人员理解如何配置许多不同类型的 Kubernetes 资源。第二个问题(与第一个问题相关)是,对于每个开发人员来说,学习如何正确配置和维护所有这些对象,同时遵守组织安全、遵从性和操作策略变得非常具有挑战性。即使是简单的错误配置也可能导致部署失败,甚至服务不可用。第三个问题是,当 Kubernetes 规范或组织策略发生变化时,必须更新所有应用程序清单以反映这些变化。对于一个可能拥有数千个应用程序和数百万行 Kubernetes 清单文件的 YAML 的组织来说,这是一项巨大的任务。这些问题产生了对应用程序抽象的强烈需求,该抽象将开发人员与不会直接影响其应用程序的平台和操作关注点隔离开来,并提供了一个锚来避免配置漂移。Kubernetes 的核心抽象,通过有意的设计,并没有为抽象应用程序提供一个标准的机制。
考虑到这个目标,KubeVela 被创建和设计为一个最小的、可扩展的应用程序引擎,供平台构建人员在 Kubernetes 上创建 “类似 PaaS” 的体验。具体来说,KubeVela 提供了简单而有效的抽象,将应用程序配置问题与平台和操作问题分离开来。下面是一个名为 appfile 的工件示例:
通过使用 appfile 并将其与 Argo CD 一起部署,开发人员只需要编写一个简单的应用配置,并将代码推送到 git。然后,他们的应用程序将被自动部署,并开始在目标 Kubernetes 集群上处理实时流量。在幕后,平台和运营团队有能力用 CUElang 模板预先定义和 / 或修改这些抽象的行为,并确保它们满足组织的安全性、遵从性和其他运营需求。
https://github.com/oam-dev/kubevela/tree/master/hack/vela-templates/cue
在下面,我们将更详细地解释上述 GitOps 工作流是如何工作的。
KubeVela 搭配 Argo CD
先决条件
对于平台运营者来说,唯一的 “技巧” 是使 KubeVela 成为 Argo CD 的自定义插件,这样它就能 “理解” appfile 格式。
注册插件
Argo CD 允许通过编辑 argocd-cm ConfigMap 集成额外的配置管理插件,如 Kubevela。
将以下文件保存为 argo-cm.yaml:
data:
configManagementPlugins: |
- name: vela
init:
command: ["sh", "-xc"]
args: ["vela traits"]
generate:
command: ["sh", "-xc"]
args: ["vela export"]
然后执行以下命令更新 argocd-cm ConfigMap:
kubectl -n argocd patch cm/argocd-cm -p "$(cat argo-cm.yaml)"
配置 argo-repo-server
Argo CD 有一个名为 argo-repo-server 的组件,它从 Git 中提取部署清单文件并呈现最终输出。在这里,我们将使用 vela cli 解析 appfile 并将其呈现到 Kubernetes 资源中。
首先,使用所需的 kubeconfig 证书创建 ConfigMap,以便与已经安装了 KubeVela 的目标 Kubernetes 集群进行通信:
apiVersion: v1
kind: ConfigMap
metadata:
name: vela-kubeconfig
namespace: argocd
data:
config: |
# fill your kubeconfig here
当创建了上面的 ConfigMap,更新 argo-repo-server 以保存 vela cli 和凭证。
将以下补丁文件保存为 deploy.yaml:
spec:
template:
spec:
# 1. Define an emptyDir volume which will hold the custom binaries
volumes:
- name: custom-tools
emptyDir: {}
- name: vela-kubeconfig
configMap:
name: vela-kubeconfig
# 2. Use an init container to download/copy custom binaries
initContainers:
- name: download-tools
image: oamdev/argo-tool:v1
command: [sh, -c]
args:
- cp /app/vela /custom-tools/vela
volumeMounts:
- mountPath: /custom-tools
name: custom-tools
# 3. Volume mount the custom binary to the bin directory
containers:
- name: argocd-repo-server
env:
- name: KUBECONFIG
value: /home/argocd/.kube/config
volumeMounts:
- mountPath: /usr/local/bin/vela
name: custom-tools
subPath: vela
- mountPath: /home/argocd/.kube/
name: vela-kubeconfig
然后执行以下命令更新 argocd-repo-server 部署:
kubectl -n argocd patch deploy/argocd-repo-server -p "$(cat deploy.yaml)"
到目前为止,vela 插件应该已经注册,argo-repo-server 应该可以访问 vela cli,将 appfile 呈现到 Kubernetes 资源中。
在 Argo CD 中使用 KubeVela
现在,作为应用程序开发人员,你可以通过 GitOps 部署使用 KubeVela 指定的应用程序。通过 argocd 命令行创建应用时,要记住指定插件名:
argocd app create <appName> --config-management-plugin vela
让我们用 Argo CD UI 来演示一下。下面是一个包含 appfile 的仓库示例:
https://github.com/hongchaodeng/argocd-example-apps/tree/master/appfile
配置 Argo CD 来监视 Git 推送的仓库,包括初始状态:
任何推到仓库现在将自动检测和部署:
就是这样!现在你可以创建 / 修改 appfile,推送到 git,Argo CD 会自动将它们部署到你的 Kubernetes 集群,所有这些都是通过神奇的 GitOps!
了解更多
所有上述设置和配置均可在此仓库中获得。KubeVela core 和 Argo CD 目前正在阿里巴巴的 web 应用平台上生产应用,并已用于内部和公共云服务上的数万个应用程序。请尝试一下,让我们知道你的想法!
https://github.com/oam-dev/kubevela/tree/master/docs/examples/argo
CNCF Slack #kubevela 频道:
https://slack.cncf.io/
ArgoCD Slack 频道:
https://argoproj.github.io/community/join-slack
点击【阅读原文】阅读网站原文。
扫描二维码联系我们!
CNCF (Cloud Native Computing Foundation) 成立于 2015 年 12 月,隶属于 Linux Foundation,是非营利性组织。
CNCF(云原生计算基金会)致力于培育和维护一个厂商中立的开源生态系统,来推广云原生技术。我们通过将最前沿的模式民主化,让这些创新为大众所用。请长按以下二维码进行关注。