Event-driven CI pipeline with EventBridge - Container Service for Kubernetes

Es posible construir un pipeline de CI automatizado eficiente, rápido y rentable mediante EventBridge y el sistema de flujos de trabajo distribuidos Argo Workflows. Esto simplifica y acelera la entrega de aplicaciones.

Requisitos previos

Cuenta con activated EventBridge and granted permissions.
Cuenta con created an Argo workflow cluster.
Cuenta con created a file system.
Cuenta con created an Enterprise Edition instance.
Ha otorgado el permiso AliyunAdcpFullAccess a un usuario de RAM. Para obtener más información, consulte Grant permissions to a RAM user.

Funcionamiento

Un pipeline de CI automatizado y basado en eventos consta de dos partes:

La confirmación de código en un repositorio de Git desencadena un evento de Git.
El sistema de CI ejecuta pruebas previas a la compilación, construye una imagen de Docker y envía la imagen a un repositorio de imágenes.

Una vez que la imagen se compila correctamente, puede utilizar un sistema de despliegue continuo (CD), como ACK One GitOps, para sincronizar la nueva etiqueta de imagen con su clúster de Kubernetes.

Este tutorial utiliza EventBridge para la solución basada en eventos debido a sus advantages en disponibilidad, facilidad de uso, seguridad y escalabilidad. El componente de CI emplea Argo Workflows, un proyecto graduado de la Cloud Native Computing Foundation (CNCF). El clúster de flujos de trabajo gestiona por completo Argo Workflows para mejorar la estabilidad y la observability. También proporciona capacidades de operación y mantenimiento (O&M) que le permiten construir pipelines de CI más grandes, rápidos y rentables.

Un usuario confirma código en un repositorio de Git.
Con base en una regla de eventos configurada, EventBridge captura el evento de Git y lo reenvía al clúster de flujos de trabajo de ACK One. Esto activa el flujo de trabajo de CI.
Un CI workflow on an ACK One workflow cluster construye una imagen de Docker y la envía a un repositorio de imágenes. Posteriormente, puede usar GitOps para sincronizar automáticamente los cambios de imagen con un clúster de ACK.

Paso 1: Preparar el entorno de CI

Cree una credencial de acceso a ACR EE y monte un volumen NAS. Para obtener más información, consulte Step 1 y Step 2 en Build a CI Pipeline for a Golang project by using a workflow cluster.

Nota
Asegúrese de que el namespace sea el mismo que el del recurso Workflow.
Este tutorial utiliza el proyecto echo-server como código de aplicación de ejemplo. Haga un fork del proyecto en su cuenta de GitHub y luego modifique el WorkflowTemplate siguiendo las instrucciones en Clone a private Git repository in a CI Pipeline.

Paso 2: Activar el pipeline de CI con EventBridge

Create a custom event bus.
Integre EventBridge con GitHub. Para obtener más información, consulte GitHub integration.
De forma opcional, configure una regla de eventos. El siguiente código muestra una configuración de ejemplo. Para más detalles sobre cómo configurar reglas de eventos, consulte Manage event rules.
1. Patrón de eventos: La siguiente configuración activa cambios únicamente desde la rama release-v1.
```
{
    "source": [
        "github.event"
    ],
    "data": {
        "body": {
            "ref": [
                "refs/heads/release-v1"
            ]
        }
    }
}
```
2. Configure el destino del evento.
  1. Service Type: Seleccione Container Service for Kubernetes.
  2. Cluster KubeConfig: Introduzca el KubeConfig para acceder al clúster de flujos de trabajo a través de la VPC.
  3. YAML Configuration: Seleccione Template.
  4. Parameters: Agregue workflowName para configurar el ID del evento.
```
{
  "workflowName": "$.id"
}
```
  5. Template: Introduzca el recurso personalizado (CR) del Workflow de CI. El siguiente ejemplo es solo de referencia; cree el CR según su información real.
    
    Importante
    Las configuraciones de recursos requieren que establezca explícitamente name y namespace. No puede usar generateName. Si un recurso pertenece al namespace predeterminado default, también debe declararlo.
```
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"     # Replace this with the address of your container image repository.
    - 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: Se recomienda usar una VPC. Seleccione la VPC, el vSwitch y el security group correspondientes al clúster de flujos de trabajo.
Según la configuración anterior, cuando modifica y confirma código en la rama release-v1 de su repositorio de GitHub, esta acción desencadena un proceso automatizado. Puede comprobarlo de las siguientes maneras.
1. Consulte el rastreo de eventos.
  1. Inicie sesión en la consola de EventBridge. En el panel de navegación izquierdo, haga clic en Event Buses.
  2. Haga clic en el nombre de su bus de eventos. En el panel de navegación izquierdo, haga clic en Event trace.
  3. En la página Event trace, puede consultar el rastreo del evento.
    
    En los detalles del rastreo de eventos, el ID del evento es b91299ae-355d-4f66-ac53-8d84e5d84b97, el tipo de evento es eventbridge:Events:HTTPEvent, el nombre del bus de eventos es ci-test y el origen del evento es github.event. En la sección Event Delivery, la regla ttt entregó el evento al destino https://8.217.97.153:6443. El estado de entrega es Succeeded, la latencia de entrega es de 59 ms y la respuesta de entrega es [200]NoMessage.
2. Consulte la topología de ejecución del Workflow recién creado.
  
  Puede encontrar esta topología en el clúster de flujos de trabajo. Para obtener más información, consulte Enable Argo Server to access the workflow cluster.
  
  El Workflow tiene el nombre ci-go-v1-eb-3999580c-1ee4-4e10-a75b-af6e8eddccde. Su topología de ejecución de grafo acíclico dirigido (DAG) muestra los siguientes pasos: git-checkout-pr (Succeeded), run-test (Succeeded) y build-push-image (Running).