Unité 3.3 : CI/CD Pipelines pour IONOS

Introduction

Vous avez conteneurisé TaskBoard, poussé ses images vers le registre de conteneurs IONOS, et déployé manuellement sur Managed Kubernetes. L'exécution de docker push et kubectl apply depuis votre ordinateur portable ne permet pas de mettre à l'échelle pour une équipe, et cela ne survive pas au moment où vous oubliez quel étiquette d'image est en production. Dans cette unité, vous reliez toute la boucle ensemble afin qu'une git push soit la seule étape manuelle. Un commit déclenche une construction, l'image atterrit dans le registre de conteneurs avec l'étiquette du SHA git, et la nouvelle étiquette est déployée sur le Cluster.

Vous allez également soumettre l'infrastructure à la même discipline. Terraform plan s'exécute sur chaque demande de tirage, afin que les réviseurs voient la différence avant que quoi que ce soit ne change, et apply ne s'exécute qu'après la fusion. Deux contraintes IONOS façonnent chaque pipeline que vous écrivez ici : le API est asynchrone, les déploiements doivent donc attendre la disponibilité au lieu de la supposer, et l'authentification du registre de conteneurs est basée sur le jeton Docker de connexion uniquement, sans RBAC et sans référentiels par équipe, les informations d'identification vivent donc dans les secrets de l'interface de ligne de commande.

1. Conception de pipeline pour IONOS

Un pipeline CI/CD sur IONOS se divise en deux flux distincts qui ne devraient pas partager un travail. Les modifications d'application suivent build -> test -> push image -> deploy to Kubernetes. Les modifications d'infrastructure suivent plan -> apply. Les mélanger signifie qu'une faute de frappe dans un fichier Kubernetes peut bloquer une correction d'infrastructure urgente, et un terraform apply lent retarde chaque déploiement d'application.

Le flux d'application se termine par kubectl apply, ou plus précisément, une mise à jour contrôlée de l'étiquette d'image par rapport à un déploiement existant. Le flux d'infrastructure se termine par terraform apply contre vos ressources IONOS. Les deux flux s'authentifient à IONOS, mais ils utilisent des informations d'identification différentes : le flux d'application nécessite un jeton de registre de conteneurs et un kubeconfig, tandis que le flux d'infrastructure nécessite un jeton IONOS_TOKEN pour le Cloud API.

1.1 Étiquetage d'images avec le SHA Git

Ne déployez jamais :latest. Une étiquette mutable rend les restaurations ambigües et brise le lien entre un pod en cours d'exécution et le commit qui l'a produit. Étiquetez chaque image avec le SHA Git immuable afin que la révision en cours d'exécution soit toujours traçable.

# Derive an immutable tag from the commit
REGISTRY="taskboard.cr.de-fra.ionos.com"
SHA=$(git rev-parse --short HEAD)
IMAGE="${REGISTRY}/taskboard-api:${SHA}"

docker build -t "${IMAGE}" ./api
docker push "${IMAGE}"

Le nom d'hôte du registre suit le modèle {registry-name}.cr.{location-with-dash}.ionos.com, par exemple tue1608es.cr.es-vit.ionos.com. Le nom d'hôte n'est alloué qu'après que le registre a atteint l'état En cours d'exécution et est vide jusqu'alors, donc un pipeline qui provisionne un registre frais doit lire le nom d'hôte à partir de la sortie Terraform plutôt que de le coder en dur.

1.2 Séparation des référentiels d'application et d'infrastructure

Gardez Terraform dans un référentiel d'infrastructure et les fichiers Kubernetes ainsi que le code d'application dans un référentiel d'application. Le référentiel d'infrastructure s'applique lors de la fusion ; le référentiel d'application crée et déploie lors de la poussée. Cette séparation maintient la zone d'impact d'un changement erroné petite et vous permet d'accorder un accès différent à différents groupes.

taskboard-app/          # build, push, kubectl deploy
  api/Dockerfile
  k8s/deployment.yaml
  .github/workflows/deploy.yml
taskboard-infra/        # terraform plan/apply
  main.tf
  modules/
  .github/workflows/terraform.yml

2. GitHub Actions pour IONOS

Un workflow GitHub Actions pour le flux d'application comporte trois étapes logiques en un seul travail : construction et test, connexion Docker et poussée, puis déploiement vers Managed Kubernetes. Les parties spécifiques à IONOS sont la connexion au registre (basée sur un jeton) et la récupération de la configuration kube.

2.1 Stockage des secrets IONOS

Les jetons n'appartiennent jamais au référentiel. Stockez le jeton du registre de conteneurs et la configuration kube en tant que secrets de référentiel ou d'environnement. Le mot de passe du jeton du registre de conteneurs n'est affiché qu'une seule fois lors de la création, il faut donc le capturer immédiatement et le stocker dans CI. Un jeton de registre peut être permanent ou temporaire avec une expiryDate, et à l'expiration, le jeton est supprimé plutôt que désactivé, ce qui signifie qu'un jeton expiré dans CI échoue la connexion Docker purement et simplement plutôt que de se dégrader silencieusement.

2.2 Le workflow de déploiement

# .github/workflows/deploy.yml
name: deploy-taskboard
on:
  push:
    branches: [main]

env:
  REGISTRY: taskboard.cr.de-fra.ionos.com
  IMAGE_NAME: taskboard-api

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set image tag
        run: echo "TAG=$(git rev-parse --short HEAD)" >> "$GITHUB_ENV"

      - name: Run tests
        run: |
          cd api
          pip install -r requirements.txt
          pytest

      - name: Log in to IONOS Container Registry
        run: echo "${{ secrets.CR_PASSWORD }}" | docker login "$REGISTRY" \
             -u "${{ secrets.CR_USERNAME }}" --password-stdin

      - name: Build and push image
        run: |
          docker build -t "$REGISTRY/$IMAGE_NAME:$TAG" ./api
          docker push "$REGISTRY/$IMAGE_NAME:$TAG"

      - name: Configure kubectl
        run: |
          mkdir -p "$HOME/.kube"
          echo "${{ secrets.KUBECONFIG }}" | base64 -d > "$HOME/.kube/config"

      - name: Deploy to Managed Kubernetes
        run: |
          kubectl set image deployment/taskboard-api \
            api="$REGISTRY/$IMAGE_NAME:$TAG"
          kubectl rollout status deployment/taskboard-api --timeout=180s

kubectl set image met à jour uniquement le champ d'image sur le déploiement existant, ce qui déclenche une mise à jour en roulement sans réappliquer l'ensemble du manifeste. L'étape kubectl rollout status bloque jusqu'à ce que le déploiement soit terminé ou que le délai d'expiration soit déclenché, ce qui est la bonne façon de signaler un déploiement échoué comme un pipeline échoué. La configuration kube elle-même provient de Managed Kubernetes Cluster : vous pouvez la télécharger à partir des paramètres Cluster ou, dans un pipeline automatisé, la lire à partir de la sortie Terraform (couvert dans l'unité 3.2) et stocker la valeur codée en base64 en tant que secret KUBECONFIG.

3. GitLab CI pour IONOS

GitLab CI exprime le même flux que des étapes discrètes dans .gitlab-ci.yml. Les spécificités d'IONOS sont identiques : connexion basée sur jeton à Docker pour accéder au registre et un kubeconfig pour le Cluster. GitLab propose un service Docker-dans-Docker pour construire des images à l'intérieur du pipeline.

3.1 Étapes du pipeline

# .gitlab-ci.yml
stages: [test, build, deploy]

variables:
  REGISTRY: taskboard.cr.de-fra.ionos.com
  IMAGE_NAME: taskboard-api

test:
  stage: test
  image: python:3.12
  script:
    - cd api && pip install -r requirements.txt && pytest

build:
  stage: build
  image: docker:24
  services: [docker:24-dind]
  script:
    - export TAG=$CI_COMMIT_SHORT_SHA
    - echo "$CR_PASSWORD" | docker login "$REGISTRY" -u "$CR_USERNAME" --password-stdin
    - docker build -t "$REGISTRY/$IMAGE_NAME:$TAG" ./api
    - docker push "$REGISTRY/$IMAGE_NAME:$TAG"

deploy:
  stage: deploy
  image: bitnami/kubectl:latest
  script:
    - echo "$KUBECONFIG_B64" | base64 -d > /tmp/kubeconfig
    - export KUBECONFIG=/tmp/kubeconfig
    - kubectl set image deployment/taskboard-api api="$REGISTRY/$IMAGE_NAME:$CI_COMMIT_SHORT_SHA"
    - kubectl rollout status deployment/taskboard-api --timeout=180s
  only: [main]

Stockez CR_USERNAME, CR_PASSWORD, et KUBECONFIG_B64 en tant que variables CI/CD masquées et protégées dans les paramètres du projet GitLab. Les variables protégées ne sont exposées qu'aux pipelines qui s'exécutent sur des branches protégées, ce qui garde les informations d'identification de production en dehors des pipelines de branche de fonctionnalité. CI_COMMIT_SHORT_SHA est l'équivalent GitLab du tag git SHA, offrant la même garantie d'étiquette immuable que l'exemple GitHub Actions.

4. Terraform dans CI/CD

Les modifications d'infrastructure méritent un examen avant d'affecter les ressources IONOS, car terraform apply crée des ressources facturables et peut les détruire. Le modèle standard exécute terraform plan sur chaque demande de tirage et publie le plan comme commentaire de demande de tirage, puis exécute terraform apply uniquement après la fusion vers main. Cela donne aux réviseurs la différence exacte et empêche quiconque d'appliquer des modifications non révisées.

4.1 Planifier sur la demande de tirage, appliquer sur la fusion

# .github/workflows/terraform.yml
name: terraform
on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

env:
  IONOS_TOKEN: ${{ secrets.IONOS_TOKEN }}

jobs:
  plan:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - run: terraform init
      - run: terraform plan -no-color -out=tfplan
      - run: terraform show -no-color tfplan > plan.txt
      - uses: actions/github-script@v7
        with:
          script: |
            const fs = require('fs');
            const plan = fs.readFileSync('plan.txt', 'utf8');
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: '```\n' + plan.slice(0, 60000) + '\n```'
            });

  apply:
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - run: terraform init
      - run: terraform apply -auto-approve

Le fournisseur IONOS Terraform s'authentifie à partir de la variable d'environnement IONOS_TOKEN, donc passer le jeton d'accès en tant que variable d'environnement est tout ce dont le bloc de fournisseur a besoin. Le fournisseur interroge les opérations asynchrones IONOS internement, donc terraform apply bloque jusqu'à ce que chaque ressource atteigne son état prêt avant de passer à l'étape suivante. Cela signifie que le pipeline n'a pas besoin de ses propres boucles de prêt pour les ressources gérées par Terraform.

4.2 État distant pour CI/CD

L'état local ne fonctionne pas dans CI/CD car chaque exécuteur démarre avec une vérification propre. Utilisez le backend IONOS Object Storage compatible avec S3 afin que chaque exécution de pipeline lise et écrive l'état identique, et que le verrouillage d'état empêche deux applications concurrentes de le corrompre.

terraform {
  backend "s3" {
    bucket                      = "taskboard-tfstate"
    key                         = "infra/terraform.tfstate"
    region                      = "de"
    endpoints = { s3 = "https://s3-eu-central-1.ionoscloud.com" }
    skip_credentials_validation = true
    skip_region_validation      = true
    skip_requesting_account_id  = true
  }
}

Object Storage utilise l'authentification par clé d'accès et clé secrète, et non des jetons d'accès, donc les informations d'identification du backend sont séparées de IONOS_TOKEN. Fournissez-les au pipeline en tant que secrets AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY, que le backend S3 lit automatiquement.

5. Stratégies de déploiement et de restauration

La stratégie de déploiement par défaut de Kubernetes est RollingUpdate, qui remplace Pods de manière incrémentielle afin que le service reste disponible pendant un déploiement. Pour les charges de travail qui ne peuvent pas exécuter deux versions en même temps, utilisez Recreate, qui termine tous les anciens Pods avant de démarrer les nouveaux, au prix d'une courte période d'indisponibilité.

5.1 Configuration de la stratégie

apiVersion: apps/v1
kind: Deployment
metadata:
  name: taskboard-api
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels: { app: taskboard-api }
  template:
    metadata:
      labels: { app: taskboard-api }
    spec:
      imagePullSecrets:
        - name: cr-pull-secret
      containers:
        - name: api
          image: taskboard.cr.de-fra.ionos.com/taskboard-api:abc1234
          readinessProbe:
            httpGet: { path: /healthz, port: 8080 }
            initialDelaySeconds: 5

maxUnavailable: 0 garantit qu'aucune capacité n'est perdue pendant le déploiement, et readinessProbe garantit que le trafic n'atteint que les Pods qui signalent une bonne santé. L'entrée imagePullSecrets fait référence au jeton du registre de conteneurs, puisque Cluster extrait les images en utilisant les mêmes informations d'identification basées sur le jeton que votre pipeline a utilisées pour les pousser. Les versions canary et blue-green sont réalisables avec des déploiements parallèles et un changement de trafic, ou avec un outil GitOps tel qu'ArgoCD, qui est couvert comme un modèle dans l'unité 5.3 plutôt que ici.

5.2 Restauration

Lorsqu'un déploiement se passe mal, restaurez l'application avec kubectl rollout undo, qui ramène le déploiement à sa révision précédente sans reconstruire quoi que ce soit.

# Inspect revision history
kubectl rollout history deployment/taskboard-api

# Roll back to the immediately previous revision
kubectl rollout undo deployment/taskboard-api

# Roll back to a specific revision
kubectl rollout undo deployment/taskboard-api --to-revision=4

Puisque chaque image est étiquetée avec son SHA Git, vous pouvez également restaurer de manière déterministe avec kubectl set image pointant vers une étiquette connue comme étant bonne. Pour l'infrastructure, la restauration signifie annuler l'engagement fautif et réexécuter terraform apply, qui rétablit les ressources en direct à l'état engagé. Si l'état lui-même est endommagé, restaurez-le à partir d'une copie versionnée dans le backend de Object Storage.

6. Création d'une bibliothèque de modules Terraform

Une fois que l'infrastructure de TaskBoard fonctionne, extrayez les modèles répétitifs en modules afin que le prochain service ne parte pas de zéro. Un module regroupe des ressources liées derrière des variables d'entrée et expose des sorties, transformant une pile verbale en quelques lignes de code de l'appelant.

6.1 Structure du module

# modules/k8s-service/variables.tf
variable "name"        { type = string }
variable "node_count"  { type = number, default = 2 }
variable "k8s_version" { type = string, default = "1.34" }

# modules/k8s-service/main.tf
resource "ionoscloud_k8s_cluster" "this" {
  name        = var.name
  k8s_version = var.k8s_version
}

resource "ionoscloud_k8s_node_pool" "this" {
  name        = "${var.name}-pool"
  k8s_cluster_id = ionoscloud_k8s_cluster.this.id
  node_count  = var.node_count
  # ... cores, ram, availability_zone, etc.
}

# modules/k8s-service/outputs.tf
output "cluster_id" { value = ionoscloud_k8s_cluster.this.id }

Les versions Kubernetes prises en charge sont 1.34, 1.33, 1.32, et 1.31, donc fixez une version connue comme étant bonne par défaut dans le module et laissez les appelants la remplacer. Node Pools peut utiliser des types Dedicated Core ou vCPU Server, et un pool Node a une limite maximale stricte de 100 nœuds avec une limite maximale recommandée de 20, donc validez node_count par rapport à ces limites plutôt que de laisser une faute de frappe provisionner un pool surdimensionné.

6.2 Consommation du module

module "taskboard" {
  source     = "./modules/k8s-service"
  name       = "taskboard-prod"
  node_count = 3
}

output "taskboard_cluster" {
  value = module.taskboard.cluster_id
}

Versionnez votre référentiel de modules avec des balises git et référencez une balise spécifique dans source afin qu'un changement en aval du module ne modifie pas silencieusement une pile existante. C'est ainsi qu'une équipe transforme un déploiement fonctionnel en une bibliothèque réutilisable.

API Carte de référence rapide

Points de terminaison clés utilisés par les pipelines CI/CD sur IONOS :

URL de base : https://api.ionos.com/cloudapi/v6 Authentification : Authorization: Bearer <token>

Laboratoire de code

Objectif : Créer un pipeline GitHub Actions qui construit, pousse et déploie TaskBoard sur Managed Kubernetes à chaque push vers main.

Prérequis :

• Compte IONOS Cloud avec jeton API (IONOS_TOKEN)
• Un registre de conteneurs existant et Managed Kubernetes Cluster (à partir des unités 3.1 et 3.2)
• Un référentiel GitHub pour l'application TaskBoard
• docker, kubectl, et ionosctl installés localement

Étape 1 : Créer un jeton de registre pour CI

ionosctl container-registry token create \
  --registry-id "$REGISTRY_ID" --name ci-deploy

Sortie attendue :

TokenId    Name        Status   ExpiryDate
a1b2c3d4   ci-deploy   enabled  -
Password: <shown once - copy it now>

Étape 2 : Stocker les secrets dans GitHub

gh secret set CR_USERNAME --body "ci-deploy"
gh secret set CR_PASSWORD --body "<password from step 1>"
gh secret set KUBECONFIG  --body "$(ionosctl k8s kubeconfig get \
  --cluster-id "$CLUSTER_ID" | base64 -w0)"

Sortie attendue :

✓ Set secret CR_USERNAME
✓ Set secret CR_PASSWORD
✓ Set secret KUBECONFIG

Étape 3 : Ajouter le fichier de workflow Commit .github/workflows/deploy.yml de la section 2.2 dans le référentiel. Sortie attendue :

[main 9f3c1ab] add deploy workflow
 1 file changed, 38 insertions(+)

Étape 4 : Déclencher le pipeline

git commit --allow-empty -m "trigger deploy"
git push origin main

Sortie attendue :

To github.com:you/taskboard-app.git
   8d2e1f0..9f3c1ab  main -> main

Étape 5 : Voir l'exécution

gh run watch

Sortie attendue :

✓ build-and-deploy succeeded
  ✓ Build and push image
  ✓ Deploy to Managed Kubernetes

Étape 6 : Vérifier le déploiement sur le Cluster

kubectl get deployment taskboard-api -o wide

Sortie attendue :

NAME            READY   IMAGE
taskboard-api   3/3     taskboard.cr.de-fra.ionos.com/taskboard-api:9f3c1ab

Liste de validation :

• [ ] Image avec le tag git-SHA existe dans le registre de conteneurs
• [ ] L'image de déploiement correspond au tag poussé
• [ ] kubectl rollout status a signalé une réussite dans le pipeline
• [ ] Une deuxième poussée produit un nouveau tag SHA et une mise à jour de roulement propre

Nettoyage :

gh secret delete CR_USERNAME CR_PASSWORD KUBECONFIG
ionosctl container-registry token delete --registry-id "$REGISTRY_ID" --token-id "$TOKEN_ID"

Erreurs courantes

Erreurs de développement à éviter avec CI/CD sur IONOS :

1. Hardcoding le nom d'hôte du registre avant que le registre ne soit en cours d'exécution

   • Problème : Le pipeline échoue avec une erreur de résolution Docker lors de la connexion au registre contre un nom d'hôte vide.
   • Pourquoi cela se produit-il : Le nom d'hôte du registre n'est alloué qu'après que le registre a atteint l'état en cours d'exécution, donc un registre fraîchement provisionné n'a pas encore de nom d'hôte.
   • Correction : Lisez le nom d'hôte à partir de la sortie de Terraform au lieu de le coder en dur, et bloquez le travail de publication sur la disponibilité du registre :

   output "registry_hostname" { value = ionoscloud_container_registry.this.hostname }
   

2. S'attendre à ce qu'un service LoadBalancer Kubernetes soit un véritable Load Balancer externe

   • Problème : Le débit atteint un plateau et l'adresse source IP de chaque demande apparaît comme une adresse interne Cluster, ce qui brise la limitation de débit et les journaux d'audit.
   • Pourquoi cela se produit-il : Un service LoadBalancer sur Managed Kubernetes ne provisionne pas un équilibreur de charge externe. IONOS réserve une adresse publique statique IP et l'attribue en tant qu'adresse secondaire IP à un worker Node, et kube-proxy NAT le trafic vers le pod, limitant ainsi le débit à celui d'un seul Node et perdant l'adresse source IP.
   • Correction : Définissez externalTrafficPolicy: Local pour conserver l'adresse source IP, et placez le service derrière un ALB géré séparément ou répartissez-le sur plusieurs adresses IP d'équilibrage de charge pour dépasser le débit d'un seul Node :

   spec:
     type: LoadBalancer
     externalTrafficPolicy: Local
   

3. Exécution de Terraform avec un état local dans CI/CD

   • Problème : Chaque exécution du pipeline démarre avec un état vide, donc terraform apply tente de recréer des ressources qui existent déjà et renvoie une erreur en raison de noms en double.
   • Pourquoi cela se produit-il : Les exécuteurs CI vérifient un espace de travail propre sans fichier d'état, et il n'y a pas de backend partagé.
   • Correction : Configurez le backend S3 compatible avec Object Storage pour que toutes les exécutions partagent l'état, et fournissez les informations d'identification de clé d'accès et de clé secrète en tant que secrets de pipeline :

   export AWS_ACCESS_KEY_ID="$IONOS_S3_KEY"
   export AWS_SECRET_ACCESS_KEY="$IONOS_S3_SECRET"
   terraform init
   

Résumé

Vous pouvez maintenant gérer la boucle complète de construction, de test et de déploiement à partir d'un seul git push. Le pipeline d'application construit un conteneur, l'étiquette avec le SHA git, se connecte à IONOS Container Registry avec une connexion basée sur un jeton Docker, pousse l'image et la déploie sur Managed Kubernetes avec une vérification de prêt kubectl set image et kubectl rollout status. Le pipeline d'infrastructure maintient Terraform honnête en planifiant les demandes de tirage et en appliquant uniquement lors de la fusion, avec un état partagé dans Object Storage. Lorsque quelque chose se brise, kubectl rollout undo et un engagement Terraform rétabli vous ramènent à un état connu et bon, et votre bibliothèque de modules extraite signifie que le prochain service réutilise ces modèles au lieu de les réinventer.

Points clés :

• Séparez le flux d'application (build -> test -> push -> deploy) du flux d'infrastructure (plan -> apply) ; ne partagez jamais un travail entre eux
• Étiquetez chaque image avec le SHA git immuable, ne :latest jamais, afin que la révision en cours d'exécution soit toujours traçable et que les restaurations soient déterministes
• Les jetons de Container Registry sont affichés une seule fois lors de la création et sont supprimés à l'expiration ; stockez-les en tant que secrets CI et extrayez les images avec les mêmes informations d'identification basées sur des jetons
• Exécutez terraform plan sur les demandes de tirage et terraform apply sur la fusion, avec un état partagé S3-compatible dans Object Storage et IONOS_TOKEN en tant que secret
• Restaurez les applications avec kubectl rollout undo et l'infrastructure en rétablissant l'engagement et en réappliquant

Terminologie importante :

• Étiquette immuable : Une étiquette d'image de conteneur dérivée du SHA git qui ne change jamais, reliant chaque pod en cours d'exécution à l'engagement exact qui l'a construit.
• Mise à jour incrémentielle : La stratégie de déploiement par défaut de Kubernetes qui remplace Pods de manière incrémentielle afin que le service reste disponible pendant un déploiement.
• Planifier sur une demande de tirage : Le modèle CI de Terraform qui exécute terraform plan sur les demandes de tirage et publie la différence pour examen avant toute apply.
• Backend d'état distant : Un magasin d'état partagé Terraform (S3-compatible Object Storage sur IONOS) qui permet à chaque exécution CI de lire et d'écrire le même état avec verrouillage.
• imagePullSecret : Un secret Kubernetes contenant les informations d'identification du jeton de Container Registry afin que le Cluster puisse extraire des images privées.

Prochaines étapes

Continuer l'apprentissage : Unité 3.4 : Vérification des connaissances - Conteneurs et CI/CD

Sujets connexes :

• Unité 3.1 : Registre de conteneurs et pipelines d'images
• Unité 3.2 : Déploiement et opérations Kubernetes
• Unité 5.3 : GitOps et opérations de déploiement