KubeVela作为一个申明式的运行交付控制平面，自然就可以以GitOps的方式启动经常使用，并且这样做会在GitOps的基础上为用户提供更多的优势和端到端的体验，包括：

GitOps形式须要依赖FluxCD插件，所以在经常使用GitOps形式下交付运行之前须要先启用FluxCD插件。

velaaddonenablefluxcd

GitOps上班流分为CI和`CD两个局部：

而交付面向的人员有以下两种：

面向平台治理员/运维人员的交付

如下图所示，关于平台治理员/运维人员而言，他们并不须要关心运行的代码，所以只有要预备一个Git性能仓库并部署KubeVela性能文件，后续关于运行及基础设备的性能变化，便可经过间接更新Git性能仓库来成功，使得每一次性性能变卦可追踪。

这里咱们将部署一个数据库作为名目标基础设备，同时部署一个业务运行，经常使用这个数据库。性能仓库的目录结构如下:

├──apps│└──my-app.yaml├──clusters│├──apps.yaml│└──infra.yaml└──infrastructure└──mysql.yaml

clusters/目录

首先，咱们来看下clusters目录，这也是KubeVela对接GitOps的初始化操作性能目录。

以clusters/infra.yaml为例：

apiVersion:core.oam.dev/v1beta1kind:Applicationmetadata:name:infraspec:components:-name:>apiVersion:core.oam.dev/v1beta1kind:Applicationmetadata:name:my-appnamespace:defaultspec:components:-name:my-servertype:webserviceproperties:image:cnych/kubevela-gitops-demo:main-76a34322-1697703461port:8088env:-name:DB_HOSTvalue:mysql-cluster-mysql.default.svc.cluster.local:3306-name:DB_PASSvalueFrom:secretKeyRef:name:mysql-secretkey:ROOT_PASSWORDtraits:-type:scalerproperties:replicas:1-type:gatewayproperties:class:classInSpec:truedomain:vela-gitops-demo.k8s.localhttp:/:8088pathType:ImplementationSpecific这是一个经常使用了KubeVela内置组件类型webservice的运行，该运行绑定了gateway运维特色。经过在运行中申明运维才干的方式，只有一个文件，便能将底层的Deployment、Service、Ingress汇合起来，从而更为方便地治理运行。

infrastructure/目录

infrastructure/目录下寄存一些基础设备的性能。此处咱们经常使用mysqlcontroller来部署了一个MySQL集群。

apiVersion:core.oam.dev/v1beta1kind:Applicationmetadata:name:mysqlnamespace:defaultspec:components:-name:mysql-secrettype:k8s-objects#须要减少一个蕴含ROOT_PASSWORD的secretproperties:objects:-apiVersion:v1kind:Secretmetadata:name:mysql-secrettype:OpaquestringData:ROOT_PASSWORD:root321-name:mysql-operatortype:helmproperties:repoType:helmurl:

 在这个MySQL运行中，咱们减少了3个KubeVela的组件，第一个是一个k8s-objects类型的组件，也就是间接运行Kubees资源对象，咱们这里须要部署一个Secret对象；而后减少一个helm类型的组件，用来部署MySQL的Operator。当Operator部署成功且正确运转后，最后咱们将开局部署MySQL集群。


 部署clusters/目录下的文件


 性能完以上文件并寄存到Git性能仓库后，咱们须要在集群中手动部署clusters/目录下的KubeVelaGitOps性能文件。


 首先，在集群中部署clusters/infra.yaml。可以看到它智能在集群中拉起了infrastructure/目录下的MySQL部署文件：

$kubectlapply-fclusters/infra.yaml$velalsAPPCOMPONENTTYPETRAITSPHASEHEALTHYSTATUSCREATED-TIMEinfra>$kubectlgetpodsNAMEREADYSTATUSRESTARTSAGEmysql-cluster-mysql-04/4Running035mmysql-operator-02/2Running035m

 经过这种方式，咱们可以繁难地经过更新Git性能仓库中的文件，从而智能化更新集群中的性能。


 面向终端开发者的交付


 关于终端开发者而言，在KubeVelaGit性能仓库以外，还须要预备一个运行代码仓库。在用户更新了运行代码仓库中的代码后，须要性能一个CI来智能构建镜像并推送至镜像仓库中。KubeVela会监听镜像仓库中的最新镜像，并智能更新性能仓库中的镜像性能，最后再更新集群中的运行性能。经常使用户可以达成在更新代码后，集群中的性能也智能更新的成果，代码仓库位于。


 预备代码仓库


 预备一个代码仓库，外面蕴含一些源代码以及对应的file。这些代码将衔接到一个MySQL数据库，并繁难地启动服务。在自动的服务门路下，会显示以后版本号。在/db门路下，会列出以后数据库中的消息，基本代码如下所示：

http.HandleFunc("/",func(whttp.ResponseWriter,r*http.Request){_,_=fmt.Fprintf(w,"Version:%sn",VERSION)})http.HandleFunc("/db",func(whttp.ResponseWriter,r*http.Request){rows,err:=db.Query("select*fromuserinfo;")iferr!=nil{_,_=fmt.Fprintf(w,"Error:%vn",err)}forrows.Next(){varusernamestringvardescstringerr=rows.Scan(&username,&desc)iferr!=nil{_,_=fmt.Fprintf(w,"ScanError:%vn",err)}_,_=fmt.Fprintf(w,"User:%snDescription:%snn",username,desc)}})iferr:=http.ListenAndServe(":8088",nil);err!=nil{panic(err.Error())}

 咱们宿愿用户改变代码启动提交后，智能构建出最新的镜像并推送到镜像仓库。这一步CI可以经过前面咱们解说的Jenkins来成功，基本分歧。


 首先为代码仓库创立一个Webhook，指向Jenkins的触发器地址：


 而后在Jenkins中创立一个名为KubeVela-GitOps-App-Demo的流水线：


 并勾选GitHubhooktriggerforGITScmpolling触发器。


 触发器


 而后减少如下所示的流水线脚本：

voidsetBuildStatus(Stringmessage,Stringstate){step([$class:"GitHubCommitStatusSetter",reposSource:[$class:"ManuallyEnteredRepositorySource",url:"https://github.com/cnych/KubeVela-GitOps-App-Demo"],contextSource:[$class:"ManuallyEnteredCommitContextSource",context:"ci/jenkins/deploy-status"],errorHandlers:[[$class:"ChangingBuildStatusErrorHandler",result:"UNSTABLE"]],statusResultSource:[$class:"ConditionalStatusResultSource",results:[[$class:"AnyBuildResult",message:message,state:state]]]]);}pipeline{agent{kubernetes{cloud'Kubernetes'defaultContainer'jnlp'yaml'''spec:serviceAccountName:jenkinscontainers:-name:golangimage:golang:1.16-alpine3.15command:-cattty:true-name:dockerimage:docker:latestcommand:-cattty:trueenv:-name:DOCKER_HOSTvalue:tcp://docker-dind:2375'''}}stages{stage('Prepare'){steps{script{defcheckout=gitbranch:'main',url:'https://github.com/cnych/KubeVela-GitOps-App-Demo.git'env.GIT_COMMIT=checkout.GIT_COMMITenv.GIT_BRANCH=checkout.GIT_BRANCHdefunixTime=(newDate().time.intdiv(1000))defgitBranch=env.GIT_BRANCH.replace("origin/","")env.BUILD_ID="${gitBranch}-${env.GIT_COMMIT.substring(0,8)}-${unixTime}"echo"env.GIT_BRANCH=${env.GIT_BRANCH},env.GIT_COMMIT=${env.GIT_COMMIT}"echo"env.BUILD_ID=${env.BUILD_ID}"setBuildStatus("Deployrunning","PENDING");}}}stage('Test'){steps{container('golang'){sh'GOPROXY=$(pwd)/.cachegotest*.go'}}}stage('Build'){steps{withCredentials([[$class:'UsernamePasswordMultiBinding',credentialsId:'docker-auth',usernameVariable:'DOCKER_USER',passwordVariable:'DOCKER_PASSWORD']]){container('docker'){sh"""dockerlogin-u${DOCKER_USER}-p${DOCKER_PASSWORD}dockerbuild-tcnych/kubevela-gitops-demo:${env.BUILD_ID}.dockerpushcnych/kubevela-gitops-demo:${env.BUILD_ID}"""}}}}}post{success{setBuildStatus("Deploysuccess","SUCCESS");}failure{setBuildStatus("Deployfailed","FAILURE");}}}

 构建后咱们就可以将运行的镜像打包后推送到DockerHub去。


 性能秘钥消息


 在新的镜像推送到镜像仓库后，KubeVela会识别到新的镜像，并更新仓库及集群中的Application性能文件。因此，咱们须要一个含有Git消息的Secret，使KubeVela向Git仓库启动提交。部署如下文件，将其中的用户名和明码交流成你的Git用户名及明码（或Token）：

apiVersion:v1kind:Secretmetadata:name:git-secrettype:kubernetes.io/basic-authstringData:username:<yourusername>password:<yourpassword>

 预备性能仓库


 性能仓库与之前面向运维人员的性能迥然不同，只有要加上与镜像仓库相关的性能即可。


 修正clusters/中的apps.yaml，该GitOps性能会监听仓库中apps/下的运行文件变化以及镜像仓库中的镜像更新：

#......省略其余的imageRepository:#镜像地址image:<yourimage>#假设这是一个私有的镜像仓库，可以经过`kubectlcreatesecretdocker-registry`创立对应的镜像秘钥并相关联secretRef:dockerhub-secretfilterTags:#可对镜像tag启动过滤pattern:"^main-[a-f0-9]+-(?P<ts>[0-9]+)"extract:"$ts"#经过policy挑选出最新的镜像Tag并用于更新policy:numerical:order:asc#追加提交消息commitMessage:"Image:{{range.Updated.Images}}{{println.}}{{end}}"

 修正apps/my-app.yaml中的image字段，在前面加上#{"$imagepolicy":"default:apps"}的注释，KubeVela会经过该注释去更新对应的镜像字段，default:apps是下面GitOps性能对应的命名空间和称号。

spec:components:-name:my-servertype:webserviceproperties:image:cnych/kubevela-gitops-demo:main-9e8d2465-1697703645#{"$imagepolicy":"default:apps"}

 将clusters/中蕴含镜像仓库性能的文件更新到集群中后，咱们便可以经过修正代码来成功运行的更新。


 部署clusters/apps.yaml：

$kubectlapply-fclusters/apps.yaml$velalsAPPCOMPONENTTYPETRAITSPHASEHEALTHYSTATUSCREATED-TIMEappsappskustomizerunninghealthy2023-10-1916:31:49+0800CSTmy-appmy-serverwebservicescaler,gatewayrunningWorkflowunhealthyReady:0/12023-10-1916:32:11+0800CST$kubectlgetpodsNAMEREADYSTATUSRESTARTSAGEmy-server-6947fd65f9-84zhv1/1Running02m

 这样咱们就可以经过部署KubeVelaGitOps性能文件，智能在集群中拉起运行了。咱们可以经过curl运行的Ingress来验证结果能否正确，可以看到目前的版本是0.1.5，并且成功地衔接到了数据库：

$kubectlgetingressNAMECLASSHOSTSADDRESSPORTSAGEmy-servernginxvela-gitops-demo.k8s.local80115s$curl-H"Host:vela-gitops-demo.k8s.local"http://192.168.0.100Version:0.1.8$curl-H"Host:vela-gitops-demo.k8s.local"http://192.168.0.100/dbUser:KubeVelaDescription:It'satestuser

 修正代码


 将代码文件中的Version改为0.2.0，并修负数据库中的数据:

constVERSION="0.2.0"...funcInsertInitData(db*sql.DB){stmt,err:=db.Prepare(insertInitData)iferr!=nil{panic(err)}deferstmt.Close()_,err=stmt.Exec("KubeVela2","It'sanothertestuser")iferr!=nil{panic(err)}}

 提交该改变至代码仓库，反常咱们性能的CI流水线就会智能开局构建镜像并推送至镜像仓库。


 而KubeVela会经过监听镜像仓库，依据最新的镜像Tag来更新性能仓库中apps/下的运行my-app。


 此时，可以看到性能仓库中有一条来自kubevelabot的提交，提交消息均带有Updateimageautomatically.前缀。你也可以经过{{range.Updated.Images}}{{println.}}{{end}}在commitMessage字段中追加你所须要的消息。


 经过一段时期后，运行my-app就智能更新了。KubeVela会经过你性能的interval时时期隔，来每隔一段时期区分从性能仓库及镜像仓库中失掉最新消息：


 通用咱们可以经过curl对应的Ingress检查以后版本和数据库消息：

$kubectlgetingressNAMECLASSHOSTSADDRESSPORTSAGEmy-servernginxvela-gitops-demo.k8s.local8012m$curl-H"Host:vela-gitops-demo.k8s.local"http://<ingress-ip>Version:0.2.0$curl-H"Host:vela-gitops-demo.k8s.local"http://<ingress-ip>/dbUser:KubeVelaDescription:It'satestuserUser:KubeVela2Description:It'sanothertestuser

 版本已被成功更新！至此，咱们成功了从变卦代码，到智能部署至集群的所有操作。


 总结


 在运维侧，如若须要更新基础设备（如数据库）的性能，或是运行的性能项，只有要修正性能仓库中的文件，KubeVela将智能把性能同步到集群中，简化了部署流程。


 在研发侧，用户修正代码仓库中的代码后，KubeVela将智能更新性能仓库中的镜像，从而启动运行的版本更新。经过与GitOps的联合，KubeVela减速了运行从开发到部署的整个流程。或许你会感觉这和FluxCD不是差不多吗？确实是这样的，KubeVela的GitOps性能自身就是依赖FluxCD的，但是KubeVela的性能可远远不止于此，比如说下面咱们的运行经常使用的MySQL数据咱们是经过MySQLOperator来部署的，那假设我如今还换成云资源RDS呢？依照以前的方式方法，那么咱们须要去云平台手动申请RDS或许经常使用Terraform来启动治理，但在KubeVela中咱们齐全可以协助开发者集成、编排不同类型的云资源，涵盖混合多云环境，让你用一致中央式去经常使用不同厂商的云资源。雷同的咱们只有要在GitOps仓库中的性能文件Application对象中去减少云资源的治感性能即可，这样做到了一个对象治理多种资源的才干，这也是KubeVela的外围才干之一。


 最后假设你感觉运行太多治理不太繁难，那么咱们还可以经常使用命令失掉平台的概览消息以及对运行程序的资源形态启动诊断。