All Products
Search
Document Center

Container Service for Kubernetes:Event-driven CI pipelines based on EventBridge

Last Updated:Nov 01, 2024

You can build efficient, fast, and cost-effective event-driven automated Continuous Integration (CI) pipelines based on EventBridge and the distributed Argo workflows to significantly simplify and accelerate application delivery. This topic describes how to build event-driven automated CI pipelines.

Prerequisites

Overview

An event-driven automated CI pipeline consists of the following two parts:

  1. A Git event trigger. An event is triggered when code is committed to the Git repository.

  2. Pre-build testing. The CI pipeline performs a test before the CI system builds the Docker image and pushes the image to the image repository.

After the image is built, you can use a Continuous Deployment (CD) system, such as ACK One GitOps, to synchronize the new image tags to the Kubernetes cluster.

image

In this example, the event-driven solution utilizes EventBridge, which provides benefits in terms of availability, ease of use, security, and scalability. The CI pipeline is built based on Argo Workflows, which is a graduated project of Cloud Native Computing Foundation (CNCF). The Distributed Cloud Container Platform for Kubernetes (ACK One) workflow cluster hosts Argo Workflows. This enhances stability and observability, provides O&M capabilities, and helps you build larger CI pipelines with higher performance and lower costs.

image
  1. A user commits code to the Git repository.

  2. EventBridge captures the Git event based on the configured rules and delivers the event to the ACK One workflow cluster to trigger the execution of the CI pipeline.

  3. ACK One creates a CI pipeline in the workflow cluster, builds a Docker image, and then pushes the image to the image repository. You can use GitOps to automatically synchronize image changes to the ACK cluster.

Step 1: Prepare the CI environment in the ACK One workflow cluster

  1. Create credentials in the workflow cluster to access the Container Registry Enterprise Edition instance and mount the File Storage NAS (NAS) volume to the workflow cluster. For more information, see Step 1 and Step 2 in Create CI pipelines for Golang projects in workflow clusters.

    Note

    Make sure that the namespace is the same as that of the workflow resource.

  2. In this example, the project used for the Apps Code Repo is echo-server. Fork echo-server to your GitHub account and modify the WorkflowTemplate by following the steps in the Clone a private Git repository in a CI pipeline topic.

Step 2: Use EventBridge to implement a Git event-driven CI pipeline

  1. Create a custom event bus.

  2. Integrate GitHub with EventBridge. For more information, see Integrate GitHub.

  3. (Optional) Configure event rules. The following content is used in this example. For more information about how to configure event rules, see Manage event rules.

    1. Event pattern: The following settings are configured to trigger pipelines only based on changes from the release-v1 branch.

      {
          "source": [
              "github.event"
          ],
          "data": {
              "body": {
                  "ref": [
                      "refs/heads/release-v1"
                  ]
              }
          }
      }
      
    2. Configure event targets.

      1. Service Type: Container Service for Kubernetes is selected.

      2. Kubernetes Cluster File: Enter the kubeconfig file of the ACK One workflow cluster.

      3. YAML: Template is selected.

      4. Parameters: Add the workflowName parameter and configure the event ID.

        {
        	"workflowName": "$.id"
        }
      5. Template: Enter the container image of the workflow and the corresponding container image repository address. The following example is only for reference. Specify a container image repository address based on your actual information.

        Important

        In the resource configuration, you must configure the name and namespace parameters. The generateName parameter cannot be used. If the resource belongs to the default namespace default, you must also specify the namespace.

        apiVersion: argoproj.io/v1alpha1
        kind: Workflow
        metadata:
          name: ci-go-v1-eb-${workflowName}
          namespace: default
          labels:
            workflows.argoproj.io/workflow-template: ackone-ci
        spec:
          arguments:
            parameters:
            - name: repo_url
              value: https://github.com/ivan-cai/echo-server.git
            - name: repo_name
              value: echo-server
            - name: target_branch
              value: release-v1
            - name: container_image
              value: "YOUR-IMAGE-REGISTRY-ADDRESS"     # The address of the container image repository. Replace the value based on your business requirements.
            - name: container_tag
              value: "v1.0.0"
            - name: dockerfile
              value: ./Dockerfile
            - name: enable_suffix_commitid
              value: "true"
            - name: enable_test
              value: "true"
          workflowTemplateRef:
            name: ci-go-v1
            clusterScope: true
      6. Network Access: Internet is selected.

  4. Based on the preceding configuration, the automation process is triggered after you make code changes on the release-v1 branch of your GitHub repository and commit the changes. To verify the preceding configuration, perform the following operations:

    1. View the event trace.

      1. Log on to the EventBridge console. In the left-side navigation pane, click Event Buses.

      2. Click the name of an event bus. In the left-side navigation pane, click Event Tracking.

      3. On the Event Tracing page, you can view the event trace.

        image

    2. View the topology of the workflow.

      View the topology of the workflow in the ACK One workflow cluster. For more information, see Enable Argo Server for a workflow cluster.

      image