GitOps delivery based on KubeVela

Introduction: kubevera is a simple, easy-to-use and highly scalable cloud native application management and delivery platform. The OAM model behind kubevera naturally solves the management problems such as the combination and arrangement of complex resources in the process of application construction, and also models the later operation and maintenance strategy, which means that kubevera can manage complex large-scale applications in combination with GitOps, Convergence of system complexity problems caused by the growth of team and system scale.

Author Dong Tianxin (FOG)

Reviewed & proofread by: Xiyang, Haizhu

Editor & typesetter: Wen Yan

KubeVela is a simple, easy-to-use and highly scalable cloud native application management and delivery platform, which allows developers to easily and quickly define and deliver modern microservice applications on Kubernetes without knowing any details related to Kubernetes infrastructure.

The OAM model behind KubeVela naturally solves the management problems such as the combination and arrangement of complex resources in the process of application construction, and also models the later operation and maintenance strategy, which means that KubeVela can manage complex large-scale applications in combination with GitOps and converge the system complexity problems caused by the growth of team and system scale.

What is GitOps

Its core idea is to store the declarative description of the infrastructure and application configuration required by the application system in the Git warehouse, and cooperate with an automatic process, so that after each warehouse is updated, the automatic process can gradually update the environment to the latest configuration.

This method allows developers to automatically deploy applications by directly changing the code and configuration in the Git warehouse. Using GitOps can bring many values to application R & D, such as:

Improve production efficiency. Automatic continuous deployment can accelerate the average deployment time and increase development efficiency.

Lower the threshold for developer deployment. By pushing code instead of container configuration, developers can easily deploy without knowing the internal implementation of Kubernetes.

Make change records traceable. Using Git to manage the cluster can make every change traceable and strengthen audit tracking.

The cluster can be restored through Git's rollback / branch function.

KubeVela and GitOps

As a declarative application delivery control plane, KubeVela naturally supports the use of GitOps, and enables users to more clearly feel the benefits brought by GitOps and the end-to-end application delivery and management experience, including:

Application delivery workflow (CD pipeline)
- That is, KubeVela supports the description of procedural application delivery in GitOps mode, rather than simply declaring the final state;

Handle various dependencies and topologies in the deployment process;

Provide a unified upper level abstraction on the semantics of various existing GitOps tools to simplify the application delivery and management process;

Uniformly declare, deploy and bind cloud services;

Provide out of the box delivery strategy (Canary, blue-green release, etc.);

Provide out of the box hybrid cloud / multi cloud deployment policies (placement rules, cluster filtering rules, etc.);

Provide Kustomize style Patch in multi environment delivery to describe deployment differences without learning any details of Kustomize itself;

......

In this article, we mainly explain the steps of delivering directly using KubeVela in GitOps mode.

GitOps workflow

GitOps workflow is divided into CI and CD parts:

CI (Continuous Integration): continuously integrate, build code for business applications, build images, and push them to the image warehouse. At present, there are many mature CI tools, such as GitHub Action and Travis commonly used in open source projects, as well as Jenkins and Tekton commonly used in enterprises. In this article, we use GitHub Action to complete CI. Of course, you can also use other CI tools instead. KubeVela can connect CI processes under any tool around GitOps.

CD (Continuous Delivery): continuous deployment will automatically update the configuration in the cluster, such as updating the latest image in the image warehouse to the cluster. At present, there are two main CD schemes:

- 1) Push based: the CD of push mode is mainly completed by configuring the CI pipeline. In this way, the access secret key of the cluster needs to be shared with the CI, so that the CI pipeline can push changes to the cluster through commands. Please refer to our previous blog: using Jenkins + KubeVela to complete the continuous delivery of applications (see the relevant links at the end of the article).

2) Pull based: the CD in pull mode will monitor the changes of the warehouse (code warehouse or configuration warehouse) in the cluster and synchronize these changes to the cluster. Compared with the Push mode, the cluster actively pulls the update of pull based, thus avoiding the problem of secret key exposure. This is also the core content of this paper.

There are two types of personnel oriented delivery, which we will introduce respectively:

For infrastructure delivery for platform administrators / operation and maintenance personnel, users can update the infrastructure configuration in the cluster by directly updating the configuration file in the warehouse, such as the system's dependent software, security policy, storage, network and other infrastructure configuration.

For the delivery of end developers, once the user's code is merged into the application code warehouse, it will automatically trigger the update of applications in the cluster, which can more efficiently complete the iteration of applications. Combined with KubeVela's gray publishing, traffic allocation, multi cluster deployment and other functions, it can form a more powerful automatic publishing capability.

Delivery to platform administrators / O & M personnel

As shown in the figure, platform administrators / operation and maintenance personnel do not need to care about the application code, so they only need to prepare a Git configuration warehouse and deploy KubeVela configuration files. Subsequent configuration changes to applications and infrastructure can be completed by directly updating the Git configuration warehouse, so that each configuration change can be tracked.

Prepare to configure warehouse

Refer to for specific configuration Example warehouse 1 (see relevant links at the end of the text for details).

In this example, we will deploy a MySQL database software as the infrastructure of the project, and deploy a business application to use the database. The directory structure of the configuration warehouse is as follows:

clusters/ The KubeVela GitOps configuration in the cluster is included in the. Users need to clusters/ Manually deploy files from to the cluster. This is a one-time control operation. After execution, KubeVela can automatically monitor the file changes in the configuration warehouse and automatically update the configuration in the cluster. Where, clusters/apps.yaml Will listen apps/ Changes in all applications, clusters/infra.yaml Will listen infrastructure/ All infrastructure changes.

apps/ The directory contains all the configurations of business applications. In this case, it is a business application using a database.

infrastructure/ It contains some infrastructure related configurations and policies, in this case MySQL database.

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

Kube Vela recommends using the above directory structure to manage your GitOps repository. clusters/ Relevant KubeVela GitOps configurations are stored in and need to be manually deployed to the cluster, apps / and infrastructure/ Store your application and infrastructure configuration separately. By separating the application from the basic configuration, you can more reasonably manage your deployment environment and isolate the impact of application changes.

clusters/ catalogue

First, let's look at the clusters directory, which is also the initialization operation configuration directory of KubeVela docking GitOps.

with clusters/infra.yaml For example:

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: infra
spec:
  components:
  - name: database-config
    type: kustomize
    properties:
      repoType: git
      # Replace here with the git configuration warehouse address you need to listen to
      url: https://github.com/FogDong/KubeVela-GitOps-Infra-Demo
      # If it is a private warehouse, you also need to associate git secret
      # secretRef: git-secret
      # The time interval of automatic pull configuration is set to 10 minutes here due to the small variability of infrastructure
      pullInterval: 10m
      git:
        # Branch listening for changes
        branch: main
      # Listen for the changed path and point to the file in the infrastructure directory in the warehouse
      path: ./infrastructure

apps.yaml And infra.yaml Almost consistent, except that the file directories monitored are different. stay apps.yaml In, properties.path The value of will be changed to . / apps, indicating listening apps/ File changes in the directory.
The GitOps control configuration file in the cluster folder needs to be manually deployed to the cluster at one time during initialization. After that, KubeVela will automatically listen apps/ as well as infrastructure/ The configuration files in the directory and update them regularly.

apps/ catalogue

apps/ The application configuration file is stored in the directory, which is a simple application configured with database information and progress. The application will connect to a MySQL database and simply start the service. Under the default service path, the current version number will be displayed. stay /db Under path, the information in the current database will be listed.

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: my-app
  namespace: default
spec:
  components:
    - name: my-server
      type: webservice
      properties:
        image: ghcr.io/fogdong/test-fog:master-cba5605f-1632714412
        port: 8088
        env:
          - name: DB_HOST
            value: mysql-cluster-mysql.default.svc.cluster.local:3306
          - name: DB_PASSWORD
            valueFrom:
              secretKeyRef:
                name: mysql-secret
                key: ROOT_PASSWORD
      traits:
        - type: ingress
          properties:
            domain: testsvc.example.com
            http:
              /: 8088

This is an application that uses KubeVela's built-in component type webservice, which is bound with the progress operation and maintenance feature. By declaring the operation and maintenance capability in the application, only one file is needed to collect the underlying Deployment, Service and progress, so as to manage the application more conveniently.

infrastructure/ catalogue

infrastructure/ Some infrastructure configurations are stored in the directory. Here, we use mysql controller (see the relevant links at the end of the article) to deploy a MySQL Cluster.

Note: please ensure that there is a secret in your cluster and pass it ROOT_PASSWORD MySQL password declared.

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: mysql
  namespace: default
spec:
  components:
    - name: mysql-controller
      type: helm
      properties:
        repoType: helm
        url: https://presslabs.github.io/charts
        chart: mysql-operator
        version: "0.4.0"
    - name: mysql-cluster
      type: raw
      dependsOn:
        - mysql-controller
      properties:
        apiVersion: mysql.presslabs.org/v1alpha1
        kind: MysqlCluster
        metadata:
          name: mysql-cluster
        spec:
          replicas: 1
          # Associated secret name
          secretName: mysql-secret

In this MySQL application, we use the ability of KubeVela workflow. The workflow is divided into two steps. The first step is to deploy the MySQL controller. When the controller deployment is successful and runs correctly, the second step will start to deploy the MySQL Cluster.

deploy clusters/ Files in directory

After configuring the above files and storing them in Git configuration warehouse, we need to manually deploy them in the cluster clusters/ KubeVela GitOps configuration file under directory.

First, deploy in a cluster clusters/infra.yaml. You can see that it is automatically pulled up in the cluster infrastructure/ MySQL deployment file under Directory:

kubectl apply -f clusters/infra.yaml

$ vela ls
APP     COMPONENT           TYPE        TRAITS  PHASE   HEALTHY STATUS  CREATED-TIME
infra   database-config     kustomize           running healthy         2021-09-26 20:48:09 +0800 CST
mysql   mysql-controller    helm                running healthy         2021-09-26 20:48:11 +0800 CST
└─      mysql-cluster       raw                 running healthy         2021-09-26 20:48:11 +0800 CST

Next, deploy in the cluster clusters/apps.yaml, you can see that it is automatically pulled up apps/ Application deployment file under Directory:

kubectl apply -f clusters/apps.yaml

APP     COMPONENT           TYPE        TRAITS  PHASE   HEALTHY STATUS  CREATED-TIME
apps    apps                kustomize           running healthy         2021-09-27 16:55:53 +0800 CST
infra   database-config     kustomize           running healthy         2021-09-26 20:48:09 +0800 CST
my-app  my-server           webservice  ingress running healthy         2021-09-27 16:55:55 +0800 CST
mysql   mysql-controller    helm                running healthy         2021-09-26 20:48:11 +0800 CST
└─      mysql-cluster       raw                 running healthy         2021-09-26 20:48:11 +0800 CST

So far, we have automatically pulled up applications and databases in the cluster by deploying KubeVela GitOps configuration files.

Through the progress of curl application, you can see that the current version is 0.1.5 and successfully connected to the database:

$ kubectl get ingress
NAME        CLASS    HOSTS                 ADDRESS         PORTS   AGE
my-server   <none>   testsvc.example.com   <ingress-ip>    80      162m
$ curl -H "Host:testsvc.example.com" http://<ingress-ip>
Version: 0.1.5
$ curl -H "Host:testsvc.example.com" http://<ingress-ip>/db
User: KubeVela
Description: It's a test user

Modify configuration

After the first deployment, we can update the configuration of the application in the cluster by modifying the configuration in the configuration warehouse.

Modify the Domain to which progress is applied:

...
      traits:
        - type: ingress
          properties:
            domain: kubevela.example.com
            http:
              /: 8089

After a period of time, review the progress in the cluster:

NAME        CLASS    HOSTS                 ADDRESS         PORTS   AGE
my-server   <none>   kubevela.example.com  <ingress-ip>    80      162m

You can see that the Host address of progress has been successfully updated.

In this way, we can easily update the files in the Git configuration repository to automatically update the configuration in the cluster.

Delivery for end developers

For end developers, in addition to the KubeVela Git configuration repository, an application code repository needs to be prepared. As shown in the figure, after the user updates the code in the application code warehouse, a CI needs to be configured to automatically build the image and push it to the image warehouse. KubeVela will listen to the latest images in the image warehouse, automatically update the image configuration in the configuration warehouse, and finally update the application configuration in the cluster. This enables the user to automatically update the configuration in the cluster after updating the code.

Prepare code warehouse

Prepare a code warehouse, which contains some source code and the corresponding Dockerfile.

This code will connect to a MySQL database and simply start the service. Under the default service path, the current version number will be displayed. stay / Under the db path, the information in the current database will be listed.

http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        _, _ = fmt.Fprintf(w, "Version: %s\n", VERSION)
    })
    http.HandleFunc("/db", func(w http.ResponseWriter, r *http.Request) {
        rows, err := db.Query("select * from userinfo;")
        if err != nil {
            _, _ = fmt.Fprintf(w, "Error: %v\n", err)
        }
        for rows.Next() {
            var username string
            var desc string
            err = rows.Scan(&username, &desc)
            if err != nil {
                _, _ = fmt.Fprintf(w, "Scan Error: %v\n", err)
            }
            _, _ = fmt.Fprintf(w, "User: %s \nDescription: %s\n\n", username, desc)
        }
    })
    if err := http.ListenAndServe(":8088", nil); err != nil {
        panic(err.Error())
    }

We hope that after the user changes the code and submits it, the latest image will be automatically built and pushed to the image warehouse. This step can be achieved by integrating GitHub Actions, Jenkins or other CI tools. In this example, we complete continuous integration with GitHub Actions. Specific code files and configurations can be referred to Example warehouse 2 (see the relevant links at the end of the text for details).

Configure secret key information

After the new image is pushed to the image warehouse, KubeVela will recognize the new image and update the Application configuration files in the warehouse and cluster. Therefore, we need a Secret containing Git information to enable KubeVela to submit to Git warehouse. Deploy the following files and replace the user name and password with your Git user name and password (or Token):

apiVersion: v1
kind: Secret
metadata:
  name: git-secret
type: kubernetes.io/basic-auth
stringData:
  username: <your username>
  password: <your password>

Prepare to configure warehouse

The configuration warehouse is similar to the previous configuration for operation and maintenance personnel, which only needs to add the configuration related to the image warehouse. Please refer to for specific configuration Example warehouse 1 (see relevant links at the end of the text for details).

modify clusters/ Medium apps.yaml, the GitOps configuration will listen in the warehouse apps/ Apply file changes and image updates in the image warehouse:

...
  imageRepository:
    # Mirror Address 
    image: <your image>
    # If this is a private image repository, you can create a corresponding image secret key through 'kubectl create secret docker registry' and associate it
    # secretRef: imagesecret
    filterTags:
      # You can filter the image tag
      pattern: '^master-[a-f0-9]+-(?P<ts>[0-9]+)'
      extract: '$ts'
    # Filter the latest image Tag through policy and use it for update
    policy:
      numerical:
        order: asc
    # Additional submission information
    commitMessage: "Image: {{range .Updated.Images}}{{println .}}{{end}}"

modify apps/my-app.yaml Image field in, followed by # {"$imagepolicy": "default:apps"} Notes for. KubeVela will update the corresponding image field through this annotation. default:apps Is the namespace and name corresponding to the GitOps configuration above.

spec:
  components:
    - name: my-server
      type: webservice
      properties:
        image: ghcr.io/fogdong/test-fog:master-cba5605f-1632714412 # {"$imagepolicy": "default:apps"}

take clusters/ After the files containing the image warehouse configuration are updated to the cluster, we can update the application by modifying the code.

Modify code

The code in the code file Version Change to 0.1.6 and modify the data in the database:

const VERSION = "0.1.6"
...
func InsertInitData(db *sql.DB) {
    stmt, err := db.Prepare(insertInitData)
    if err != nil {
        panic(err)
    }
    defer stmt.Close()
    _, err = stmt.Exec("KubeVela2", "It's another test user")
    if err != nil {
        panic(err)
    }
}

After submitting the change to the code warehouse, we can see that the CI pipeline we configured starts to build the image and push it to the image warehouse.

KubeVela will listen to the image warehouse and update the configuration warehouse according to the latest image Tag apps/ Application under my-app.

At this point, you can see that there is a message from kubevelabot The submitted information is provided with Update image automatically. Prefix. You can also pass {{range .Updated.Images}}{{println .}}{{end}} stay commitMessage Add the information you need to the field.

It is worth noting that if you want to put the code and configuration in the same warehouse, you need to filter out the data from kubevelabot To prevent repeated construction of the pipeline. You can configure filtering in CI S as follows:

jobs:
publish:
  if: "!contains(github.event.head_commit.message, 'Update image automatically')"

Re view the applications in the cluster. You can see that after a period of time, the applications my-app The image of has been updated.

Kube Vela will configure it through you interval Time interval to obtain the latest information from the configuration warehouse and the image warehouse at regular intervals:

When the configuration file in Git warehouse is updated, KubeVela will update the applications in the cluster according to the latest configuration.

When there are new tags in the image warehouse, KubeVela will filter out the latest image tags according to the policy rules configured by you and update them to the Git warehouse. When the files in the code warehouse are updated, KubeVela will repeat the first step to update the files in the cluster, so as to achieve the effect of automatic deployment.

adopt curl Corresponding Ingress To view the current version and database information:

$ kubectl get ingress
NAME        CLASS    HOSTS                 ADDRESS         PORTS   AGE
my-server   <none>   kubevela.example.com  <ingress-ip>    80      162m
$ curl -H "Host:kubevela.example.com" http://<ingress-ip>
Version: 0.1.6
$ curl -H "Host:kubevela.example.com" http://<ingress-ip>/db
User: KubeVela
Description: It's a test user
User: KubeVela2
Description: It's another test user

Version has been successfully updated! So far, we have completed all operations from code change to automatic deployment to the cluster.

summary

On the operation and maintenance side, if you need to update the configuration of infrastructure (such as database) or application configuration items, you only need to modify the files in the configuration warehouse. KubeVela will automatically synchronize the configuration to the cluster, simplifying the deployment process.

On the R & D side, after the user modifies the code in the code warehouse, KubeVela will automatically update the image in the configuration warehouse. So as to update the version of the application.

By combining with GitOps, KubeVela accelerates the whole process from application development to deployment.

Stamp the original text and view the official homepage and documents of KubeVela project!!

Programmer Group

GitOps delivery based on KubeVela

What is GitOps

KubeVela and GitOps

GitOps workflow

Delivery to platform administrators / O & M personnel

Prepare to configure warehouse

clusters/ catalogue

apps/ catalogue

infrastructure/ catalogue

Modify configuration

Delivery for end developers

Prepare code warehouse

Configure secret key information

Prepare to configure warehouse

Modify code

summary

Hot Keywords

Programmer Group

GitOps delivery based on KubeVela

What is GitOps

KubeVela and GitOps

GitOps workflow

Delivery to platform administrators / O & M personnel

Prepare to configure warehouse

​clusters/​ catalogue

apps/ catalogue

​infrastructure/​ catalogue

Modify configuration

Delivery for end developers

Prepare code warehouse

Configure secret key information

Prepare to configure warehouse

Modify code

summary

Hot Keywords

clusters/ catalogue

infrastructure/ catalogue