×
Community Blog Developer-Centered GitOps

Developer-Centered GitOps

This article explains the authors' experiences using Argo CD and KubeVela to build a developer-centered continuous application delivery pipeline based on Alibaba Cloud use cases.

By Deng Hongchao, Senior Technical Expert of Alibaba Cloud and Ed Lee, Founder of Argo Project

1

Introduction

Argo CD, a GitOps continuous delivery tool provided for Kubernetes, is part of the CNCF Argo Project. This project is a set of Kubernetes-native tools for running and managing jobs and applications on Kubernetes.

KubeVela is an open-source application engine based on Kubernetes and Open Application Model (OAM). KubeVela is primarily designed for the platform and operation teams to create simple and highly scalable abstractions easily for developers on Kubernetes. Developers (end users) get rid of many of the complexities of configuring the application list on Kubernetes, such as scaling policies, deploying policies, and portals. However, platform teams are allowed to customize and control these configurations independently based on organizational policies.

In this article, we will share our experiences using Argo CD and KubeVela to build a developer-centered continuous application delivery pipeline based on Alibaba Cloud use cases.

Developer-Centered GitOps Experience

Ideally, developers want to focus on writing applications and pushing their codes to Git repositories without worrying about CI/CD pipelines and other operational issues when configuring and running applications. A very popular pattern on Kubernetes is to deploy applications automatically from Git repositories into the production environment. This is where Argo CD is used. Argo CD continuously monitors newly committed applications in Git repositories and deploys them automatically into the production environment. Argo CD uses predefined Kubernetes deployment inventory files in the repository to create or upgrade applications running on Kubernetes. This mode, called GitOps, is key to the continuous and automatic application delivery in Alibaba's modern cloud-native stack.

Although it is simple in concept, several important issues arise when applying GitOps to a wider range of end-user scenarios:

  1. The actual production application is complex and requires developers to understand how to configure many different types of Kubernetes resources.
  2. It becomes very challenging for each developer to learn how to configure and maintain all these Kubernetes resources properly while complying with organizational security, compliance, and operational policies. Even simple misconfiguration can cause deployment failures or even service unavailability.
  3. When Kubernetes specifications or organizational policies change, all application lists must be updated to reflect these changes. This is a huge task for an organization that might have YAML with thousands of applications and millions of Kubernetes inventory files.

These issues pose a strong need for an application abstraction that isolates developers from the platform and operational concerns that do not directly affect their applications. The abstract also provides an anchor to avoid configuration drift. The core abstraction of Kubernetes is intentionally designed not to provide a standard mechanism for application abstractions.

Considering this goal, KubeVela was created and designed as the smallest, scalable application engine for platform builders to enjoy a "PaaS-like" experience on Kubernetes. Specifically, KubeVela provides a simple and effective abstraction that separates application configuration issues from platform and operational issues. The following figure is an example of a workpiece named appfile:

2

After using appfile and deploying it together with Argo CD, developers only need to write a simple application configuration and push the code to Git. Then, their applications will be deployed automatically and begin to process real-time traffic on the target Kubernetes cluster. The platform and operation teams can use the CUElang template to define and/or modify these abstraction behaviors in advance. The teams can also ensure that these behaviors meet the organization's security, compliance, and other operational needs.

The next part of this article will introduce how the GitOps workflow above works in more detail.

KubeVela + Argo CD

1. Prerequisites

The only "trick" for platform operators is to make KubeVela a custom plug-in for the Argo CD so KubeVela can understand the appfile format.

2. Register the Plug-In

Argo CD can integrate additional configuration management plug-ins, such as Kubevela, by editing argocd-cm ConfigMap.

Save the following file as an argo-cm.yaml:

data:
  configManagementPlugins: |
    - name: vela
      init:
        command: ["sh", "-xc"]
        args: ["vela traits"]
      generate:
        command: ["sh", "-xc"]
        args: ["vela export"]

Run the following commands to update argocd-cm ConfigMap:

kubectl -n argocd patch cm/argocd-cm -p "$(cat argo-cm.yaml)"

3. Configure argo-repo-server

Argo CD has a component called argo-repo-server. It extracts the deployment inventory file from git and presents the final output. Here, we use vela cli to parse appfile and present it to Kubernetes resources.

First, use the required kubeconfig certificate to create ConfigMap for communication with the target Kubernetes clusters that have already installed KubeVela.

apiVersion: v1
kind: ConfigMap
metadata:
  name: vela-kubeconfig
  namespace: argocd
data:
  config: |
    # fill your kubeconfig here

After the preceding ConfigMap is created, update argo-repo-server to save vela cli and credentials.

Save the following patch files as 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

Then, execute the following command to update argocd-repo-server deployment:

kubectl -n argocd patch deploy/argocd-repo-server -p "$(cat deploy.yaml)"

So far, the KubeVela plug-in should have been registered, and argo-repo-server should be able to access the vela cli to present the appfile to Kubernetes resources.

Use KubeVela in Argo CD

Now, as an application developer, you can deploy applications specified by KubeVela through GitOps. Do not forget to specify the plug-in name when creating an application by using the argocd command line:

argocd app create <appName> --config-management-plugin vela

Let's use Argo CD UI for demonstration. Here is a sample repository containing appfile.

Configure Argo CD to monitor repositories pushed by Git, including initial status:

3

Now, any pushed repository will be automatically detected and deployed:

4

That's right! Now, you can create or modify appfile and push it to Git. Then, Argo CD will deploy them automatically to your Kubernetes cluster. All these works are done through the magic of GitOps!

Learn More

All of the settings and configurations above are available in this repository. Currently, KubeVela core and Argo CD are producing applications on Alibaba's web application platform. They have been used in tens of thousands of applications in internal environments and on public cloud services. Please try it out and let us know what you think!

0 0 0
Share on

You may also like

Comments