Unité 5.3 : GitOps et opérations de déploiement

Introduction

Vous disposez d'un déploiement TaskBoard fonctionnel sur Managed Kubernetes, d'un pipeline CI/CD qui construit et pousse les images, et de Terraform qui provisionne le cluster. Le problème est la dérive. Quelqu'un exécute kubectl edit pour appliquer un correctif rapide à un déploiement en production, l'état réel diverge de ce qui est dans Git, et la prochaine exécution du pipeline l'annule silencieusement ou, pire encore, échoue. GitOps corrige cela en faisant d'un dépôt Git la source de vérité unique et en exécutant un contrôleur au sein du cluster qui récupère continuellement l'état souhaité et réconcilie l'état réel pour qu'il corresponde.

Dans cette unité, vous installez ArgoCD sur votre cluster MKS, le connectez au dépôt de manifests de TaskBoard, et observez sa capacité à réparer automatiquement les modifications manuelles. Vous séparez le dépôt dont Terraform est propriétaire (le cluster, le réseau, les bases de données) du dépôt dont ArgoCD est propriétaire (les manifests Kubernetes), afin que les deux contrôleurs ne s'écrasent jamais mutuellement. Enfin, vous automatisez la démolition des environnements par branche, de sorte qu'une branche de fonctionnalité crée son propre espace de noms et le détruit lors de la fusion ou de la fermeture.

1. Principes de GitOps et boucle de réconciliation par tirage

GitOps inverse la direction habituelle du déploiement. Au lieu qu'un exécuteur CI pousse kubectl apply dans le cluster depuis l'extérieur (modèle de poussée), un contrôleur exécuté à l'intérieur du cluster tire l'état souhaité depuis Git et l'applique (modèle de tirage). L'engagement Git est à la fois le déclencheur du déploiement, le journal d'audit et le mécanisme de retour arrière. Pour effectuer un retour arrière, vous annulez l'engagement et le contrôleur réconcilie vers l'état précédent.

Trois propriétés définissent un système GitOps : l'intégralité de l'état souhaité est déclarative et stockée dans Git, le contrôleur compare continuellement l'état souhaité à l'état en cours, et toute divergence (dérive) est soit signalée, soit corrigée automatiquement. Sur IONOS CLOUD MKS, cela est important car le cluster exécute déjà ses propres boucles de réconciliation pendant la fenêtre de maintenance hebdomadaire, de sorte que la réconciliation de votre application doit coexister avec les modifications pilotées par la plateforme.

1.1 État déclaratif dans Git

Tout ce que gère ArgoCD est du YAML Kubernetes pur, engagé dans un dépôt. Il n'y a pas de kubectl run impératif dans un flux de travail GitOps. Un manifeste de déploiement minimal pour TaskBoard ressemble à ceci :

# apps/taskboard/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: taskboard-api
  namespace: taskboard
spec:
  replicas: 2
  selector:
    matchLabels:
      app: taskboard-api
  template:
    metadata:
      labels:
        app: taskboard-api
    spec:
      imagePullSecrets:
        - name: cr-pull-secret
      containers:
        - name: api
          image: my-registry.cr.de-fra.ionos.com/taskboard-api:GIT_SHA
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5

La balise image contient un SHA git plutôt que latest. C'est le levier de promotion : modifier la balise dans Git est ce qui déclenche un nouveau déploiement, et la balise vous indique exactement quel commit est en cours d'exécution.

1.2 Détection de dérive et auto-réparation

Lorsqu'une personne exécute kubectl scale deployment/taskboard-api --replicas=5 directement sur le cluster, l'état en cours d'exécution ne correspond plus à Git, qui indique toujours replicas: 2. Un contrôleur GitOps en mode auto-réparation détecte cette différence lors de son prochain cycle de synchronisation et réduit l'échelle à 2. La leçon opérationnelle pour votre équipe est la suivante : le cluster est en lecture seule pour les humains. Toutes les modifications passent par une demande d'extraction.

# This manual change will be reverted by ArgoCD self-heal
kubectl -n taskboard scale deployment/taskboard-api --replicas=5

# Within the sync interval, ArgoCD reports OutOfSync, then heals back to 2
argocd app get taskboard --refresh

2. Installation et configuration d'ArgoCD sur MKS

ArgoCD est un projet CNCF, et non un produit IONOS CLOUD, il s'installe donc sur MKS de la même manière que sur n'importe quel cluster Kubernetes conforme. Les éléments spécifiques à IONOS CLOUD concernent la manière d'obtenir le kubeconfig, la façon dont le serveur ArgoCD est exposé (ce qui dépend du modèle LoadBalancer de MKS décrit à la section 4), et l'authentification des tirages d'images auprès du Container Registry d'IONOS CLOUD.

2.1 Récupération du kubeconfig et installation d'ArgoCD

Vous provisionnez le cluster avec Terraform et récupérez le kubeconfig avant d'installer quoi que ce soit. IONOS CLOUD documente trois chemins de gestion de configuration pour récupérer le fichier kubeconfig : la CLI ionosctl, Ansible et Terraform. Avec Terraform, la source de données ionoscloud_k8s_cluster expose le kubeconfig en tant qu'attribut que vous pouvez écrire dans un fichier.

data "ionoscloud_k8s_cluster" "taskboard" {
  id = ionoscloud_k8s_cluster.taskboard.id
}

resource "local_file" "kubeconfig" {
  content         = data.ionoscloud_k8s_cluster.taskboard.kube_config
  filename        = "${path.module}/kubeconfig.yaml"
  file_permission = "0600"
}

Une fois le kubeconfig en place, installez ArgoCD dans son propre espace de noms :

export KUBECONFIG=./kubeconfig.yaml

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# Wait for the API server to come up on the worker nodes
kubectl -n argocd rollout status deployment/argocd-server

Les pods ArgoCD sont planifiés sur vos nœuds de travail MKS. Les composants du plan de contrôle gérés par IONOS CLOUD (le serveur API K8s, CSI, CCM, Calico et CoreDNS) sont mis à jour par IONOS CLOUD lors des opérations de maintenance et ne sont pas modifiés par ArgoCD.

2.2 Définition de la CRD Application

L'objet principal d'ArgoCD est la ressource personnalisée Application. Elle pointe vers un dépôt Git, un chemin à l'intérieur de celui-ci, ainsi que vers un cluster de destination et un espace de noms. La synchronisation automated avec prune et selfHeal en fait une véritable boucle GitOps : prune supprime les ressources retirées de Git, et selfHeal annule les modifications manuelles apportées au cluster.

# argocd/taskboard-app.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: taskboard
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/taskboard-manifests.git
    targetRevision: main
    path: overlays/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: taskboard
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

Appliquez-le avec kubectl apply -n argocd -f argocd/taskboard-app.yaml. À partir de ce moment, chaque commit effectué sur le chemin overlays/prod déclenche une réconciliation.

3. Topologie des dépôts : séparation de l'infrastructure et des applications

L'erreur GitOps la plus courante sur IONOS CLOUD consiste à mélanger l'infrastructure gérée par Terraform et les applications gérées par ArgoCD dans un même endroit, puis à les voir entrer en conflit. Le modèle propre consiste à utiliser deux dépôts avec une frontière de responsabilité clairement définie.

Le dépôt d'infrastructure contient Terraform : ionoscloud_k8s_cluster, ionoscloud_k8s_node_pool, le réseau, les bases de données et le Container Registry. Il est appliqué lors de la fusion dans main via votre pipeline CI. Le dépôt d'application contient les manifests Kubernetes et les superpositions Kustomize, et ArgoCD le surveille.

3.1 Frontière de responsabilité

La règle est simple : si une ressource est créée par terraform apply, ArgoCD ne doit jamais la gérer, et si une ressource est créée par la synchronisation ArgoCD, Terraform ne doit jamais la gérer. Le relais s'effectue à travers les sorties. Terraform produit le cluster et le secret de récupération du registre ; ArgoCD consomme le cluster et y déploie les applications.

# infrastructure repo: outputs that the app layer consumes
output "k8s_cluster_id" {
  value = ionoscloud_k8s_cluster.taskboard.id
}

output "registry_hostname" {
  value     = ionoscloud_container_registry.taskboard.hostname
  sensitive = false
}

Le tableau suivant définit explicitement les limites pour TaskBoard.

Comme indiqué ci-dessus, les contrôleurs ne partagent jamais un même type de ressource, de sorte qu'aucun ne remet en cause l'autre.

3.2 La transmission du imagePullSecret

Le Container Registry sur IONOS CLOUD n'utilise que des docker login basées sur des jetons ; il n'y a ni RBAC ni dépôts par équipe. Le secret de récupération est la seule information d'identification qui franchit la frontière entre l'infrastructure et l'application. Créez-le une seule fois à partir du jeton du registre, puis référencez-le dans les manifestes synchronisés par ArgoCD.

kubectl create secret docker-registry cr-pull-secret \
  --docker-server=my-registry.cr.de-fra.ionos.com \
  --docker-username='<token-name>' \
  --docker-password='<registry-token>' \
  --namespace=taskboard

Étant donné que ce secret contient une information d'identification, ne le commitez pas en texte brut. Créez-le impérativement comme indiqué ci-dessus (une seule fois, en dehors de Git) ou utilisez un opérateur sealed-secrets ou external-secrets afin qu'ArgoCD puisse gérer une forme chiffrée.

4. Risques spécifiques de réconciliation sur IONOS CLOUD

GitOps suppose que le cluster se comporte de manière prévisible. Deux comportements de MKS brisent cette hypothèse si vous n'y avez pas prévu : les Node sont immuables et reconstruits plutôt que corrigés, et un Service LoadBalancer ne provisionne pas un équilibreur de charge externe authentique.

4.1 Node immuables et fenêtre de maintenance

Les Node MKS sont immuables. Toute mise à niveau d'un pool de Node reconstruit chaque Node appartenant au pool au lieu de le corriger sur place, et les mises à niveau se produisent généralement automatiquement pendant la fenêtre de maintenance hebdomadaire. Cette fenêtre de maintenance est limitée à un maximum de 4 heures. Pendant cette fenêtre, IONOS CLOUD met à jour tous les composants du cluster, y compris le plan de contrôle, CSI, CCM, Calico et CoreDNS.

L'implication pour GitOps est que les pods sont évacués et réplanifiés sur des Node nouvellement construits selon un calendrier que vous ne contrôlez pas. Vos manifests doivent tolérer cela. Configurez des sondes de disponibilité afin qu'ArgoCD et les Services acheminent le trafic uniquement vers les pods prêts, et utilisez un PodDisruptionBudget afin que la reconstruction ne mette pas tous les réplicas hors service en même temps.

# Survive node rebuilds during the maintenance window
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: taskboard-api
  namespace: taskboard
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: taskboard-api

Une reconstruction nécessite également une marge de quota serveur : la reconstruction d'un Node provisionne un nouveau Node avant de supprimer l'ancien. Par conséquent, si le quota de serveurs de votre contrat est épuisé, la reconstruction ne peut pas se terminer. Maintenez une marge de quota d'au moins un Node par pool.

4.2 Le piège du service LoadBalancer

C'est le risque qui surprend la plupart des équipes exposant ArgoCD ou TaskBoard. Sur MKS, un Service de type: LoadBalancer n'est pas un véritable équilibreur de charge externe. IONOS CLOUD réserve une IP publique statique et l'assigne en tant qu'IP secondaire à un nœud worker, qui agit en tant que nœud d'entrée, et kube-proxy effectue le NAT du trafic vers le pod cible. L'IP source est perdue à moins de définir externalTrafficPolicy: Local, et le débit est limité à la limite publique de 2 Gbit/s de ce seul nœud d'entrée.

apiVersion: v1
kind: Service
metadata:
  name: taskboard-api-lb
  namespace: taskboard
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local   # preserve client source IP
  selector:
    app: taskboard-api
  ports:
    - port: 443
      targetPort: 8080

Pour dépasser la limite d'un seul Node, effectuez une mise à l'échelle horizontale sur plusieurs IP LoadBalancer et nœuds d'entrée en utilisant l'équilibrage de charge DNS, ou placez le service derrière un ALB managé provisionné séparément (provisionné dans le dépôt d'infrastructure via Terraform, jamais créé automatiquement à partir d'un manifeste). Pour le trafic TaskBoard en production, le chemin ALB est la bonne réponse et maintient la préoccupation d'entrée dans la couche gérée par Terraform.

5. Promotion d'environnement et démontage éphémère

La promotion entre environnements est une opération Git, et non un script de déploiement. Avec Kustomize, une base partagée contient les manifestes et chaque environnement est un overlay qui modifie le nombre de répliques, les limites de ressources et l'étiquette d'image.

5.1 Overlays Kustomize

La base définit TaskBoard une seule fois ; les overlays différencient chaque environnement. La promotion d'une construction de l'environnement de préproduction vers la production consiste en une modification d'une seule ligne de l'étiquette d'image dans l'overlay de production, soumise par le biais d'une demande de tirage (pull request).

# overlays/prod/kustomization.yaml
resources:
  - ../../base
namespace: taskboard
images:
  - name: my-registry.cr.de-fra.ionos.com/taskboard-api
    newTag: 1a2b3c4   # promoted git SHA
patches:
  - path: replicas-patch.yaml

Chaque ArgoCD Application pointe vers un chemin d'overlay différent (overlays/dev, overlays/staging, overlays/prod), de sorte que le même référentiel pilote les trois environnements et que les différences entre eux sont auditées dans Git.

5.2 Environnements de branches éphémères et démantèlement

Pour les branches de fonctionnalité, vous créez un environnement jetable et le démantellez lors de la fusion ou de la fermeture de la branche. Les ressources provisionnées par Terraform génèrent des frais dès le moment de l'application, de sorte que le démantèlement automatisé constitue une gouvernance des coûts, et non une simple commodité. Le travail CI appelle terraform destroy pour la pile de la branche.

# .github/workflows/teardown.yml (triggered on PR close)
name: teardown-branch-env
on:
  pull_request:
    types: [closed]
jobs:
  destroy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Terraform destroy branch stack
        env:
          IONOS_TOKEN: ${{ secrets.IONOS_TOKEN }}
        run: |
          terraform init -backend-config="key=env/pr-${{ github.event.number }}.tfstate"
          terraform destroy -auto-approve -var="env_name=pr-${{ github.event.number }}"

Un piège lors du nettoyage concerne spécifiquement le stockage MKS : les volumes IONOS CLOUD sont représentés en tant que ressources PersistentVolume dans Kubernetes, et la politique de récupération des PV détermine ce qui arrive au volume sous-jacent lorsque la réclamation est supprimée. Si la politique de récupération est Retain, la suppression de l'espace de noms ou l'exécution de terraform destroy sur le cluster laisse des volumes IONOS CLOUD orphelins dans votre VDC qui continuent d'être facturés. Soit définissez la politique de récupération sur Delete pour les environnements éphémères, soit nettoyez explicitement les volumes restants après la démolition.

Fiche rapide de référence de l'API

Points de terminaison API clés pour les opérations GitOps et de déploiement sur MKS :

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

Atelier de code

Objectif : Configurer la synchronisation automatique ArgoCD pour les manifests de TaskBoard sur MKS, pousser une modification de manifest et observer la réconciliation la réparer, puis démanteler un environnement de branche.

Prérequis :

• Compte IONOS CLOUD avec jeton API
• Un cluster MKS en cours d'exécution provisionné via Terraform (depuis l'Unité 3.2)
• kubectl, argocd CLI, et Terraform installés localement
• Un dépôt Git contenant les manifests de TaskBoard

Étape 1 : Récupérer le kubeconfig depuis Terraform

terraform output -raw kubeconfig > kubeconfig.yaml
export KUBECONFIG=./kubeconfig.yaml
kubectl get nodes

Sortie attendue :

NAME                STATUS   ROLES    AGE   VERSION
taskboard-pool-1    Ready    <none>   12m   v1.34.x
taskboard-pool-2    Ready    <none>   12m   v1.34.x

Étape 2 : Installer ArgoCD

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
kubectl -n argocd rollout status deployment/argocd-server

Sortie attendue :

deployment "argocd-server" successfully rolled out

Étape 3 : Créer la CRD de l'application pointant vers les manifests de TaskBoard

kubectl apply -n argocd -f argocd/taskboard-app.yaml
argocd app get taskboard

Sortie attendue :

Name:               argocd/taskboard
Sync Status:        Synced to main (1a2b3c4)
Health Status:      Healthy

Étape 4 : Introduire un dérive manuellement

kubectl -n taskboard scale deployment/taskboard-api --replicas=5
kubectl -n taskboard get deploy taskboard-api

Sortie attendue :

NAME            READY   UP-TO-DATE   AVAILABLE
taskboard-api   5/5     5            5

Étape 5 : Observer la restauration automatique par ArgoCD vers l'état déclaré dans Git

argocd app get taskboard --refresh
sleep 30
kubectl -n taskboard get deploy taskboard-api

Sortie attendue :

NAME            READY   UP-TO-DATE   AVAILABLE
taskboard-api   2/2     2            2

Étape 6 : Promouvoir une nouvelle image via une commande Git commit

# In the manifests repo, update overlays/prod/kustomization.yaml newTag
git commit -am "promote taskboard-api to 9f8e7d6"
git push origin main
argocd app wait taskboard --sync

Sortie attendue :

taskboard   Synced   Healthy

Étape 7 : Détruire un environnement de branche

terraform init -backend-config="key=env/pr-42.tfstate"
terraform destroy -auto-approve -var="env_name=pr-42"

Sortie attendue :

Destroy complete! Resources: 7 destroyed.

Étape 8 : Vérifier qu'aucun volume orphelin ne subsiste

ionosctl volume list --datacenter-id $DC_ID

Sortie attendue :

No volumes found  (or: only volumes belonging to retained environments)

Liste de contrôle de validation :

• [ ] ArgoCD signale Synced et Healthy pour TaskBoard
• [ ] La modification manuelle de l'échelle est annulée par l'auto-réparation dans l'intervalle de synchronisation
• [ ] L'engagement de la balise d'image déclenche un déploiement sans aucun kubectl apply
• [ ] terraform destroy supprime la pile de branches et ne laisse aucun volume de facturation

Nettoyage :

kubectl delete -n argocd -f argocd/taskboard-app.yaml
kubectl delete namespace argocd
terraform destroy -auto-approve

Erreurs courantes

Erreurs de développement à éviter lors de l'utilisation de GitOps et des opérations de déploiement sur IONOS CLOUD :

1. Conflit entre Terraform et ArgoCD sur la même ressource

   • Problème : Terraform gère un Service Kubernetes, tandis qu'ArgoCD le synchronise également depuis Git. Chaque apply et chaque synchronisation annulent l'effet de l'autre, ce qui provoque une boucle de conflit infinie et des ressources instables.
   • Cause : L'absence de frontière claire de responsabilité entre le dépôt d'infrastructure et le dépôt d'application.
   • Solution : Confier à Terraform uniquement l'infrastructure IONOS CLOUD (cluster, pools de nœuds, registre, bases de données) et à ArgoCD uniquement les manifests au sein du cluster. Transmettre le cluster et le registre entre eux via les sorties de Terraform, sans jamais que les deux outils gèrent le même objet.

2. Exposition d'ArgoCD ou de TaskBoard avec type: LoadBalancer en s'attendant à un équilibreur de charge réel

   • Problème : Tout le trafic est dirigé vers un seul nœud worker, l'adresse IP source du client est perdue, et le débit plafonne autour de 2 Gbit/s sans cause apparente.
   • Cause : Un Service MKS LoadBalancer ne provisionne pas d'équilibreur de charge externe. IONOS CLOUD attribue une IP publique statique en tant qu'IP secondaire à un seul nœud d'entrée, et kube-proxy effectue une traduction NAT vers le pod.
   • Solution : Définir externalTrafficPolicy: Local pour conserver l'adresse IP source, et, pour la production, placer un ALB Managé provisionné séparément depuis la couche Terraform devant le service, au lieu de compter sur le Service à nœud unique.

3. Volumes IONOS CLOUD orphelins après la suppression d'un environnement de branche

   • Problème : Vous supprimez un environnement de branche avec terraform destroy, mais vous continuez d'être facturé, et des volumes résiduels subsistent dans le VDC.
   • Cause : Les volumes IONOS CLOUD sous-tendent des PersistentVolumes dont la politique de récupération est Retain, de sorte que la suppression de la requête ou de l'espace de noms laisse le volume sous-jacent en place.
   • Solution : Utiliser une StorageClass avec la politique de récupération Delete pour les environnements éphémères, ou ajouter une étape de suppression qui liste et supprime les volumes résiduels à l'aide de ionosctl volume list et ionosctl volume delete.

Résumé

Vous pouvez désormais exécuter un véritable workflow GitOps basé sur la récupération (pull) sur IONOS CLOUD Managed Kubernetes. ArgoCD réconcilie l'état déclaré de TaskBoard à partir de Git, corrige automatiquement les dérives manuelles et fait progresser les builds à travers les environnements grâce à un simple commit de tag d'image. Vous conservez Terraform et ArgoCD dans des dépôts distincts avec une frontière de responsabilité claire, afin que les deux contrôleurs ne s'écrasent jamais mutuellement. Vous connaissez également les deux comportements de MKS qui contredisent les hypothèses naïves de GitOps et la manière de concevoir autour d'eux.

Le bénéfice opérationnel est que la production est désormais en lecture seule pour les humains, chaque modification est un commit révisable, et le rollback est un git revert. Les environnements de branche sont jetables et se désinstallent d'eux-mêmes, et vous évitez le piège de la facturation des volumes orphelins en définissant la bonne politique de récupération.

Points clés :

• GitOps utilise un modèle de récupération (pull) : un contrôleur au sein du cluster réconcilie l'état souhaité de Git, faisant des commits le déclencheur de déploiement et le mécanisme de rollback
• Séparez le dépôt d'infrastructure géré par Terraform du dépôt d'application géré par ArgoCD pour éviter les boucles de réconciliation conflictuelles
• Les nœuds MKS sont immuables et reconstruits pendant la fenêtre de maintenance hebdomadaire (4 heures maximum) ; utilisez des PodDisruptionBudgets et des sondes de disponibilité afin que les déploiements survivent aux reconstructions
• Un Service LoadBalancer MKS n'est pas un véritable équilibreur de charge externe : un seul nœud d'ingress, perte de l'IP source sauf si externalTrafficPolicy: Local, et une limite de 2 Gbit/s ; utilisez un ALB managé pour la production
• Automatisez terraform destroy pour les environnements de branche et définissez la politique de récupération des PV sur Delete pour éviter les volumes orphelins qui continuent d'être facturés

Terminologie importante :

• GitOps : Un modèle opérationnel où Git est la source de vérité unique et où un contrôleur au sein du cluster réconcilie continuellement l'état en direct pour qu'il corresponde à l'état déclaratif commité
• Dérive : Divergence entre l'état en direct du cluster et l'état souhaité déclaré dans Git, causée par des modifications manuelles ou des processus externes
• Auto-réparation : Un mode de synchronisation ArgoCD qui rétablit automatiquement les modifications en direct vers l'état déclaré dans Git
• Politique de récupération : Le paramètre PersistentVolume de Kubernetes (Retain ou Delete) qui détermine si le volume IONOS CLOUD sous-jacent est supprimé lorsque sa demande est supprimée
• Nœud d'ingress : Le nœud worker MKS unique qui reçoit l'IP publique réservée d'un Service LoadBalancer comme IP secondaire et effectue la NAT du trafic vers les pods cibles

Prochaines étapes

Poursuivre l'apprentissage : Unité 5.4 : Vérification des connaissances - Opérations de production

Sujets connexes :

• Unité 3.3 : Pipelines CI/CD pour IONOS CLOUD
• Unité 5.2 : Automatisation de la sécurité