Tous les produits
Search
Centre de documentation

Container Service for Kubernetes:Build a CI pipeline for a Golang project using a workflow cluster

Dernière mise à jour :Sep 12, 2026

Les clusters de workflows ACK One exécutent Argo Workflows hébergé avec une élasticité intégrée et une mise à l'échelle automatique. Cette rubrique explique comment configurer un pipeline d'intégration continue (CI) qui clone un dépôt Go, exécute les tests, construit une image de conteneur et la pousse vers un registre, en s'appuyant sur deux niveaux de mise en cache persistante pour garantir des exécutions rapides.

image

Fonctionnement

Le pipeline utilise un modèle ClusterWorkflowTemplate prédéfini nommé ci-go-v1. Chaque exécution suit trois étapes organisées sous forme de graphe acyclique dirigé (DAG) :

  1. Clonage Git et extraction : clone le dépôt, extrait la branche cible et écrit l'identifiant court du commit dans un fichier partagé.

  2. Tests Go : exécute go test -v ./... sur le code source cloné. Le cache des modules Go est stocké dans le répertoire /pkg/mod sur un système de fichiers NAS. Les modules téléchargés lors d'une exécution sont réutilisés lors de la suivante, ce qui permet aux commandes go test et go build d'éviter de retélécharger les dépendances.

  3. Construction et push de l'image : utilise buildctl-daemonless.sh (BuildKit) pour construire l'image et la pousser vers Container Registry Enterprise Edition (ACR EE). BuildKit met en cache les couches d'image dans le registre sous le tag :buildcache . Les couches inchangées ne sont pas reconstruites lors des exécutions suivantes.

Ces deux caches persistent entre les exécutions du pipeline : le cache des modules Go sur NAS est partagé par toutes les tâches au sein d'une même exécution, tandis que le cache des couches BuildKit réside dans le registre d'une exécution à l'autre.

Prérequis

Avant de commencer, assurez-vous de disposer des éléments suivants :

Étape 1 : Créer les identifiants du registre dans le cluster de workflows

BuildKit tire et pousse des images à l'aide d'un Secret nommé docker-config. Créez-le dans le namespace où vous prévoyez de soumettre les pipelines.

Important

Le Secret et le volume NAS (créé à l'étape 2) doivent appartenir au même namespace que le pipeline que vous soumettez.

  1. Configurez les identifiants d'accès pour votre instance ACR EE. Consultez la rubrique Configurer les identifiants d'accès.

  2. Exécutez la commande suivante pour créer le Secret. Remplacez $repositoryDomain, $username et $password par votre domaine ACR EE et vos identifiants.

    kubectl create secret generic docker-config \
      --from-literal="config.json={\"auths\": {\"$repositoryDomain\": {\"auth\": \"$(echo -n $username:$password|base64)\"}}}"

Étape 2 : Monter un volume NAS sur le cluster de workflows

Le volume NAS remplit deux fonctions :

  • Partage de données entre les tâches : le dépôt cloné et le fichier d'identifiant de commit y sont écrits par la tâche git-checkout-pr et lus par les tâches en aval.

  • Persistance du cache des modules Go : le cache situé dans /pkg/mod est réutilisé d'une exécution à l'autre. La première exécution télécharge les modules ; les suivantes ignorent cette étape.

NAS utilise le mode d'accès ReadWriteMany afin que toutes les tâches du pipeline puissent lire et écrire simultanément dans le volume.

  1. Obtenez l'adresse du point de montage de votre système de fichiers NAS. Consultez la rubrique Gérer les points de montage.

  2. Appliquez le manifeste suivant pour créer un volume persistant (PV) et une revendication de volume persistant (PVC) dans le cluster de workflows. Remplacez <your nas filesystem mount point address> par l'adresse réelle de votre point de montage. Pour plus d'informations, consultez la rubrique Utiliser des volumes NAS.

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: pv-nas
      labels:
        alicloud-pvname: pv-nas
    spec:
      capacity:
        storage: 100Gi
      accessModes:
        - ReadWriteMany          # Required: all pipeline tasks read and write this volume concurrently
      csi:
        driver: nasplugin.csi.alibabacloud.com
        volumeHandle: pv-nas
        volumeAttributes:
          server: <your nas filesystem mount point address>
          path: "/"
      mountOptions:
      - nolock,tcp,noresvport
      - vers=3
    ---
    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: pvc-nas             # The predefined template references this name — do not change it
    spec:
      accessModes:
        - ReadWriteMany
      resources:
        requests:
          storage: 100Gi
      selector:
        matchLabels:
          alicloud-pvname: pv-nas

Étape 3 : Soumettre un pipeline

Le modèle prédéfini ci-go-v1 est disponible dans tous les clusters de workflows. Utilisez l'environnement de travail Argo ou l'interface CLI Argo pour soumettre une exécution de pipeline.

Les exemples ci-dessous utilisent un dépôt Git public. Pour un dépôt privé, ajoutez une étape qui clone le dépôt à l'aide d'identifiants stockés avant l'étape de clonage et d'extraction Git.

Soumettre depuis l'environnement de travail Argo

  1. Connectez-vous à la console ACK One. Dans le volet de navigation de gauche, sélectionnez le cluster de workflows que vous avez créé.

  2. Sur la page Cluster Information, cliquez sur l'onglet Basic Information. Dans la section Common Operations, cliquez sur Workflow Console (Argo).

  3. Dans l'environnement de travail Argo, cliquez sur Cluster Workflow Templates dans le volet de navigation de gauche, puis sur le modèle nommé ci-go-v1.

  4. Cliquez sur + SUBMIT en haut à droite. Configurez les paramètres dans le panneau qui s'affiche (consultez la section Paramètres du modèle pour les descriptions), puis cliquez sur + SUBMIT.

  5. Consultez l'état du pipeline sur la page de détails Workflows.

    Le workflow ci-go-v1-9wwnb affiche des coches vertes (statut de réussite) pour toutes les étapes. L'ordre d'exécution est git-checkout-pr → run-test → build-push-image, ce qui indique que l'extraction du code, l'exécution des tests ainsi que la construction et le push de l'image sont terminés.

Soumettre à l'aide de l'interface CLI Argo

  1. Créez un fichier nommé workflow.yaml avec le contenu suivant. Mettez à jour les valeurs des paramètres pour qu'elles correspondent à votre environnement.

    apiVersion: argoproj.io/v1alpha1
    kind: Workflow
    metadata:
      generateName: ci-go-v1-
      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: main
        - name: container_image
          value: "test-registry.cn-hongkong.cr.aliyuncs.com/acs/echo-server"
        - 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
  2. Soumettez le pipeline :

    argo submit workflow.yaml

Paramètres du modèle

Le modèle ci-go-v1 accepte les paramètres suivants.

Paramètre Description Valeur par défaut Exemple
repo_url URL du dépôt Git — https://github.com/ivan-cai/echo-server.git
repo_name Nom du dépôt (utilisé comme nom de répertoire local) — echo-server
target_branch Branche à extraire main main
container_image Image à construire et à pousser. Format : <ACR EE domain>/<namespace>/<repository> — test-registry.cn-hongkong.cr.aliyuncs.com/acs/echo-server
container_tag Tag de base de l'image v1.0.0 v1.0.0
dockerfile Chemin relatif du Dockerfile par rapport à la racine du dépôt ./Dockerfile ./Dockerfile
enable_suffix_commitid Ajoute l'identifiant court du commit au tag de l'image, produisant <container_tag>-<commit_id>. Définissez sur false pour utiliser uniquement le tag de base. true true
enable_test Exécute l'étape de test Go. Définissez sur false pour ignorer les tests et passer directement à la construction. true true

Référence du modèle prédéfini

Le modèle complet est fourni ci-dessous pour personnalisation. Les sections clés sont annotées.

apiVersion: argoproj.io/v1alpha1
kind: ClusterWorkflowTemplate
metadata:
  name: ci-go-v1
spec:
  entrypoint: main
  volumes:
  - name: run-test
    emptyDir: {}          # Temporary volume scoped to the run-test task
  - name: workdir
    persistentVolumeClaim:
      claimName: pvc-nas  # NAS volume: shared across all tasks, persists Go module cache
  - name: docker-config
    secret:
      secretName: docker-config  # Registry credentials created in Step 1
  arguments:
    parameters:
    - name: repo_url
      value: ""
    - name: repo_name
      value: ""
    - name: target_branch
      value: "main"
    - name: container_image
      value: ""
    - name: container_tag
      value: "v1.0.0"
    - name: dockerfile
      value: "./Dockerfile"
    - name: enable_suffix_commitid
      value: "true"
    - name: enable_test
      value: "true"
  templates:
    - name: main
      dag:
        tasks:
          - name: git-checkout-pr
            inline:
              container:
                image: alpine:latest
                command:
                  - sh
                  - -c
                  - |
                    set -eu

                    apk --update add git

                    cd /workdir
                    echo "Start to Clone "{{workflow.parameters.repo_url}}
                    git -C "{{workflow.parameters.repo_name}}" pull || git clone {{workflow.parameters.repo_url}}
                    cd {{workflow.parameters.repo_name}}

                    echo "Start to Checkout target branch" {{workflow.parameters.target_branch}}
                    git checkout --track origin/{{workflow.parameters.target_branch}} || git checkout {{workflow.parameters.target_branch}}
                    git pull

                    echo "Get commit id"
                    git rev-parse --short origin/{{workflow.parameters.target_branch}} > /workdir/{{workflow.parameters.repo_name}}-commitid.txt
                    commitId=$(cat /workdir/{{workflow.parameters.repo_name}}-commitid.txt)
                    echo "Commit id is got: "$commitId

                    echo "Git Clone and Checkout Complete."
                volumeMounts:
                - name: "workdir"
                  mountPath: /workdir
                resources:
                  requests:
                    memory: 1Gi
                    cpu: 1
                activeDeadlineSeconds: 1200
          - name: run-test
            when: "{{workflow.parameters.enable_test}} == true"  # Skipped when enable_test=false
            inline:
              container:
                image: golang:1.22-alpine
                command:
                  - sh
                  - -c
                  - |
                    set -eu

                    if [ ! -d "/workdir/pkg/mod" ]; then
                      mkdir -p /workdir/pkg/mod
                      echo "GOMODCACHE Directory /pkg/mod is created"
                    fi

                    export GOMODCACHE=/workdir/pkg/mod  # Point Go to the NAS-backed module cache

                    cp -R /workdir/{{workflow.parameters.repo_name}} /test/{{workflow.parameters.repo_name}}
                    echo "Start Go Test..."

                    cd /test/{{workflow.parameters.repo_name}}
                    go test -v ./...

                    echo "Go Test Complete."
                volumeMounts:
                - name: "workdir"
                  mountPath: /workdir
                - name: run-test
                  mountPath: /test
                resources:
                  requests:
                    memory: 4Gi
                    cpu: 2
              activeDeadlineSeconds: 1200
            depends: git-checkout-pr
          - name: build-push-image
            inline:
              container:
                image: moby/buildkit:v0.13.0-rootless
                command:
                  - sh
                  - -c
                  - |
                    set -eu

                    tag={{workflow.parameters.container_tag}}
                    if [ {{workflow.parameters.enable_suffix_commitid}} == "true" ]
                    then
                      commitId=$(cat /workdir/{{workflow.parameters.repo_name}}-commitid.txt)
                      tag={{workflow.parameters.container_tag}}-$commitId  # e.g. v1.0.0-abc1234
                    fi

                    echo "Image Tag is: "$tag
                    echo "Start to Build And Push Container Image"

                    cd /workdir/{{workflow.parameters.repo_name}}

                    buildctl-daemonless.sh build \
                    --frontend \
                    dockerfile.v0 \
                    --local \
                    context=. \
                    --local \
                    dockerfile=. \
                    --opt filename={{workflow.parameters.dockerfile}} \
                    build-arg:GOPROXY=http://goproxy.cn,direct \
                    --output \
                    type=image,\"name={{workflow.parameters.container_image}}:${tag},{{workflow.parameters.container_image}}:latest\",push=true,registry.insecure=true \
                    --export-cache mode=max,type=registry,ref={{workflow.parameters.container_image}}:buildcache \  # Save layer cache to registry
                    --import-cache type=registry,ref={{workflow.parameters.container_image}}:buildcache            # Reuse layer cache from previous runs

                    echo "Build And Push Container Image {{workflow.parameters.container_image}}:${tag} and {{workflow.parameters.container_image}}:latest Complete."
                env:
                  - name: BUILDKITD_FLAGS
                    value: --oci-worker-no-process-sandbox
                  - name: DOCKER_CONFIG
                    value: /.docker
                volumeMounts:
                  - name: workdir
                    mountPath: /workdir
                  - name: docker-config
                    mountPath: /.docker
                securityContext:
                  seccompProfile:
                    type: Unconfined
                  runAsUser: 1000
                  runAsGroup: 1000
                resources:
                  requests:
                    memory: 4Gi
                    cpu: 2
              activeDeadlineSeconds: 1200
            depends: run-test

Étapes suivantes

  • Personnalisez ci-go-v1 : copiez le modèle et modifiez les étapes (par exemple, ajoutez une étape de linting ou changez la version de Go) pour créer votre propre ClusterWorkflowTemplate.

  • Déclenchez automatiquement les pipelines : intégrez argo submit avec le webhook de votre plateforme Git pour exécuter le pipeline à chaque push ou demande de fusion.

Références