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.
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) :
Clonage Git et extraction : clone le dépôt, extrait la branche cible et écrit l'identifiant court du commit dans un fichier partagé.
Tests Go : exécute
go test -v ./...sur le code source cloné. Le cache des modules Go est stocké dans le répertoire/pkg/modsur 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 commandesgo testetgo buildd'éviter de retélécharger les dépendances.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 :
Un cluster de workflows. Consultez la rubrique Créer un cluster de workflows.
kubectl connecté au cluster de workflows à l'aide de son fichier kubeconfig. Consultez la rubrique Se connecter à un cluster à l'aide de kubectl.
L'interface CLI Argo d'Alibaba Cloud installée. Consultez la rubrique Installer l'interface CLI Argo.
Les autorisations RAM utilisateur configurées. Consultez la rubrique Autoriser un utilisateur RAM.
Un système de fichiers File Storage NAS créé. Consultez la rubrique Créer un système de fichiers NAS.
Une instance ACR EE créée. Consultez la rubrique Créer une instance ACR EE.
É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.
Le Secret et le volume NAS (créé à l'étape 2) doivent appartenir au même namespace que le pipeline que vous soumettez.
Configurez les identifiants d'accès pour votre instance ACR EE. Consultez la rubrique Configurer les identifiants d'accès.
-
Exécutez la commande suivante pour créer le Secret. Remplacez
$repositoryDomain,$usernameet$passwordpar 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/modest 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.
Obtenez l'adresse du point de montage de votre système de fichiers NAS. Consultez la rubrique Gérer les points de montage.
-
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
Connectez-vous à la console ACK One. Dans le volet de navigation de gauche, sélectionnez le cluster de workflows que vous avez créé.
Sur la page Cluster Information, cliquez sur l'onglet Basic Information. Dans la section Common Operations, cliquez sur Workflow Console (Argo).
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.
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.
-
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
-
Créez un fichier nommé
workflow.yamlavec 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 -
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 propreClusterWorkflowTemplate.Déclenchez automatiquement les pipelines : intégrez
argo submitavec le webhook de votre plateforme Git pour exécuter le pipeline à chaque push ou demande de fusion.