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

Vous pouvez mettre en place un pipeline CI automatisé efficace, rapide et économique en utilisant EventBridge et le système de workflows distribués Argo Workflows. Cette approche simplifie et accélère la livraison des applications.

Prérequis

Vous avez activé EventBridge et accordé les autorisations.
Vous avez créé un cluster de workflows Argo.
Vous avez créé un système de fichiers.
Vous avez créé une instance Enterprise Edition.
Vous avez accordé l'autorisation AliyunAdcpFullAccess à un utilisateur RAM. Pour plus d'informations, consultez la rubrique Accorder des autorisations à un utilisateur RAM.

Fonctionnement

Un pipeline CI automatisé et piloté par les événements se compose de deux parties :

La validation du code dans un dépôt Git déclenche un événement Git.
Le système CI exécute les tests pré-construction, génère une image Docker et pousse cette image vers un dépôt d'images.

Une fois l'image générée avec succès, vous pouvez utiliser un système de déploiement continu (CD), tel que ACK One GitOps, pour synchroniser le nouveau tag d'image avec votre cluster Kubernetes.

Ce tutoriel utilise EventBridge comme solution pilotée par les événements en raison de ses avantages en matière de disponibilité, de facilité d'utilisation, de sécurité et d'évolutivité. Le composant CI s'appuie sur Argo Workflows, un projet diplômé de la Cloud Native Computing Foundation (CNCF). Le cluster de workflows gère entièrement Argo Workflows afin d'améliorer la stabilité et l'observabilité. Il offre également des capacités d'exploitation et de maintenance (O&M) pour vous aider à construire des pipelines CI plus grands, plus rapides et plus économiques.

Un utilisateur valide du code dans un dépôt Git.
Sur la base d'une règle d'événement configurée, EventBridge capture l'événement Git et le transfère vers le cluster de workflows ACK One. Cela déclenche le workflow CI.
Un workflow CI sur un cluster de workflows ACK One génère une image Docker et la pousse vers un dépôt d'images. Vous pouvez ensuite utiliser GitOps pour synchroniser automatiquement les modifications d'image avec un cluster ACK.

Étape 1 : Préparer l'environnement CI

Créez un identifiant d'accès ACR EE et montez un volume NAS. Pour plus d'informations, consultez les étapes Étape 1 et Étape 2 de la rubrique Construire un pipeline CI pour un projet Golang à l'aide d'un cluster de workflows.

Remarque
Assurez-vous que le namespace est identique à celui de la ressource Workflow.
Ce tutoriel utilise le projet echo-server comme exemple de code d'application. Forkez le projet vers votre compte GitHub, puis modifiez le WorkflowTemplate en suivant les instructions de la rubrique Cloner un dépôt Git privé dans un pipeline CI.

Étape 2 : Déclencher le pipeline CI avec EventBridge

Créez un bus d'événements personnalisé.
Intégrez EventBridge à GitHub. Pour plus d'informations, consultez la rubrique Intégration GitHub.
Configurez éventuellement une règle d'événement. Le code suivant fournit un exemple de configuration. Pour plus d'informations sur la configuration des règles d'événement, consultez la rubrique Gérer les règles d'événement.
1. Motif d'événement : le paramètre suivant déclenche uniquement les modifications provenant de la branche release-v1.
```
{
    "source": [
        "github.event"
    ],
    "data": {
        "body": {
            "ref": [
                "refs/heads/release-v1"
            ]
        }
    }
}
```
2. Configurez la cible d'événement.
  1. Service Type : sélectionnez Container Service for Kubernetes.
  2. Cluster KubeConfig : saisissez le KubeConfig pour accéder au cluster de workflows via le VPC.
  3. YAML Configuration : sélectionnez Template.
  4. Parameters : ajoutez workflowName pour configurer l'ID de l'événement.
```
{
  "workflowName": "$.id"
}
```
  5. Template : saisissez la ressource personnalisée (CR) Workflow CI. L'exemple ci-dessous est fourni à titre indicatif ; créez la CR en fonction de vos informations réelles.
    
    Important
    Les configurations de ressources exigent que vous définissiez explicitement les champs name et namespace. Vous ne pouvez pas utiliser generateName. Si une ressource appartient au namespace par défaut default, vous devez également le déclarer.
```
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 : nous vous recommandons d'utiliser un VPC. Sélectionnez le VPC, le vSwitch et le groupe de sécurité correspondant au cluster de workflows.
Sur la base de la configuration précédente, lorsque vous modifiez et validez du code dans la branche release-v1 de votre dépôt GitHub, cette action déclenche un processus automatisé. Vous pouvez le vérifier de différentes manières.
1. Consultez la trace de l'événement.
  1. Connectez-vous à la console EventBridge. Dans le volet de navigation de gauche, cliquez sur Event Buses.
  2. Cliquez sur le nom de votre bus d'événements. Dans le volet de navigation de gauche, cliquez sur Event trace.
  3. Sur la page Event trace, vous pouvez consulter la trace de l'événement.
    
    Dans les détails de la trace d'événement, l'ID de l'événement est b91299ae-355d-4f66-ac53-8d84e5d84b97, le type d'événement est eventbridge:Events:HTTPEvent, le nom du bus d'événements est ci-test et la source de l'événement est github.event. Dans la section Event Delivery, la règle ttt a distribué l'événement vers la cible https://8.217.97.153:6443. Le statut de distribution est Succeeded, la latence de distribution est de 59 ms et la réponse de distribution est [200]NoMessage.
2. Consultez la topologie d'exécution du Workflow nouvellement créé.
  
  Vous trouverez cette topologie dans le cluster de workflows. Pour plus d'informations, consultez la rubrique Activer l'accès d'Argo Server au cluster de workflows.
  
  Le Workflow est nommé ci-go-v1-eb-3999580c-1ee4-4e10-a75b-af6e8eddccde. Sa topologie d'exécution DAG (graphe orienté acyclique) affiche les étapes suivantes : git-checkout-pr (Succeeded), run-test (Succeeded) et build-push-image (Running).