Infrastructure d’Agent Auto-Scaling : Un Démarrage Rapide Pratique

Introduction à l’infrastructure des agents d’auto-scaling

Dans le monde de l’intégration continue et de la livraison continue (CI/CD), les agents de construction (ou travailleurs, exécuteurs) sont les chevaux de trait qui compilent le code, exécutent des tests et déploient des applications. À mesure que les équipes de développement grandissent et que la complexité des projets augmente, la demande pour ces agents peut fluctuer considérablement. La provision manuelle et la déprovision des agents sont non seulement chronophages, mais engendrent également des inefficacités : soit les agents restent inoccupés, coûtant de l’argent, soit les compilations s’accumulent, ralentissant le développement. C’est ici qu’une infrastructure d’agents d’auto-scaling devient indispensable.

L’auto-scaling permet à votre flotte d’agents d’ajuster dynamiquement sa capacité en fonction de la demande. Lorsqu’il y a un afflux de requêtes de construction, de nouveaux agents sont automatiquement déployés. Lorsque la demande diminue, les agents inactifs sont supprimés, optimisant ainsi l’utilisation des ressources et les coûts. Cet article fournit un guide pratique pour mettre en œuvre l’auto-scaling pour votre infrastructure d’agents CI/CD, en se concentrant sur des modèles courants et en fournissant des exemples concrets.

Pourquoi l’auto-scaling ? Les avantages principaux

• Optimisation des coûts : Ne payez que pour les ressources que vous utilisez. Les agents inactifs dans le cloud sont un drain direct sur votre budget.
• Amélioration du débit : Éliminez les files d’attente de construction. Plus d’agents signifient plus de constructions simultanées, ce qui conduit à des cycles de retour d’information plus rapides pour les développeurs.
• Fiabilité accrue : Répartissez les charges de travail sur plusieurs agents, réduisant ainsi le risque d’un point de défaillance unique.
• Simplification des opérations : Automatisez le processus de mise à l’échelle, libérant votre équipe des tâches de provisionnement manuel.
• Élasticité : Gérez en douceur les pics et les creux imprévisibles de la demande sans intervention manuelle.

Architectures courantes d’auto-scaling

Bien que les spécificités varient selon le système CI/CD et le fournisseur de cloud, la plupart des infrastructures d’agents d’auto-scaling suivent quelques modèles de base :

1. Groupes d’auto-scaling des fournisseurs de cloud (ASG)

   De nombreux systèmes CI/CD s’intègrent directement avec des groupes d’auto-scaling spécifiques aux fournisseurs de cloud (par exemple, AWS Auto Scaling Groups, Azure Virtual Machine Scale Sets, Google Cloud Managed Instance Groups). Vous définissez une image de base (AMI, VHD, image VM) pour votre agent, spécifiez des politiques de mise à l’échelle (basées sur l’utilisation du CPU, la longueur de la file d’attente, des métriques personnalisées), et le fournisseur de cloud gère le cycle de vie.

   Avantages :

   • Excellente intégration avec l’infrastructure cloud.
   • Utilise des services cloud solidement éprouvés.
   • Souvent le plus simple à mettre en place pour une mise à l’échelle de base.

   Inconvénients :

   • Peut être moins granulaire pour le contrôle de types d’agents spécifiques ou de conditions.
   • Lié à un seul fournisseur de cloud.

2. Intégrations spécifiques aux systèmes CI/CD

   De nombreuses plateformes CI/CD modernes (par exemple, Jenkins, GitLab CI, Buildkite, CircleCI, GitHub Actions) offrent leurs propres mécanismes d’auto-scaling ou intégrations directes avec divers fournisseurs de cloud/orchestateurs de conteneurs. Cela implique souvent un « contrôleur » ou un « plugin » qui surveille la file d’attente de construction et demande de nouveaux agents en fonction des besoins.

   Avantages :

   • Optimisé pour les besoins spécifiques de la plateforme CI/CD.
   • Fournit souvent une logique plus sophistiquée pour le provisionnement d’agents (par exemple, étiquettes spécifiques, exigences en ressources).
   • Peut prendre en charge des types d’agents hétérogènes.

   Inconvénients :

   • Peut nécessiter plus de configuration au sein du système CI/CD lui-même.
   • Peut parfois être moins performant que la mise à l’échelle native dans le cloud pour des changements très rapides.

3. Orchestration de conteneurs (Kubernetes)

   L’utilisation de Kubernetes comme infrastructure sous-jacente pour vos agents devient de plus en plus populaire. Les agents fonctionnent en tant que pods éphémères, et l’auto-scaling du cluster Kubernetes (ou outils similaires) peut étendre le pool de nœuds en fonction des requêtes de pods en attente. Cela offre une flexibilité immense et une efficacité des ressources.

   Avantages :

   • Densité et utilisation des ressources élevées (plusieurs agents par nœud).
   • Portabilité entre différents fournisseurs de cloud ou sur site.
   • Excellente adaptation pour des charges de travail éphémères, basées sur des tâches.

   Inconvénients :

   • Complexité de configuration initiale plus élevée pour Kubernetes lui-même.
   • Nécessite la conteneurisation de votre environnement de construction.

Démarrage rapide : Exemples pratiques

Explorons des exemples pratiques pour configurer l’auto-scaling avec deux outils CI/CD populaires et une approche centrée sur Kubernetes.

Exemple 1 : Jenkins avec des instances EC2 Spot d’AWS

Jenkins, un serveur d’automatisation open-source largement utilisé, offre un excellent support pour l’auto-scaling basé sur le cloud, en particulier avec AWS EC2. Utiliser des instances Spot peut réduire considérablement les coûts.

Prérequis :

• Une instance Jenkins en cours d’exécution (de préférence sur EC2 ou une VM dédiée).
• Un compte AWS avec les autorisations IAM appropriées (EC2, VPC, S3 si vous utilisez S3 pour les artefacts).
• Plugin EC2 de Jenkins installé.

Étapes :

1. Préparez une AMI EC2 pour votre agent Jenkins :

   Lancez une instance EC2 (par exemple, t3.medium, Ubuntu LTS). Installez le Java Development Kit (JDK), tous les outils de construction nécessaires (Maven, Gradle, npm, Docker CLI), et configurez l’agent Jenkins. Assurez-vous que l’agent se connecte avec succès à votre contrôleur Jenkins manuellement d’abord. Une fois configuré, créez une AMI à partir de cette instance. Cette AMI sera le modèle pour vos agents d’auto-scaling.

   # Exemple de configuration sur Ubuntu pour un agent Java de base
   sudo apt update
   sudo apt install -y openjdk-11-jdk maven docker.io
   sudo usermod -aG docker jenkins # En supposant que l'utilisateur jenkins pour l'agent
   sudo systemctl enable docker
   sudo systemctl start docker
   
   # Configuration manuelle de l'agent Jenkins (pour tester l'AMI)
   # Téléchargez agent.jar depuis votre contrôleur Jenkins
   # java -jar agent.jar -jnlpUrl <votre-url-jenkins>/computer/<nom-agent>/slave-agent.jnlp -secret <secret> -workDir <path>
   
   # Une fois vérifié, créez l'AMI à partir de cette instance EC2.

2. Configurer le plugin EC2 de Jenkins :

   Allez sur le tableau de bord de Jenkins -> Gérer Jenkins -> Gérer les nœuds et les clouds -> Configurer les clouds.

   Ajoutez un nouveau cloud -> Amazon EC2.

   • Nom : AWS-Spot-Agents
   • Identifiants Amazon EC2 : Ajoutez votre AWS Access Key ID et Secret Access Key (ou utilisez un rôle IAM pour le contrôleur Jenkins).
   • Régions EC2 : Sélectionnez votre région (par exemple, us-east-1).
   • Limite d’instances : Définissez une limite raisonnable (par exemple, 10) pour éviter des coûts excessifs.
   • Clé SSH : Sélectionnez une clé SSH existante pour l’accès aux agents.
   • Ajouter une nouvelle AMI :
   • ID AMI : Entrez l’ID de l’AMI que vous avez créée.
   • Description : Agent de construction Java Ubuntu
   • Étiquettes : java-agent linux (utilisées par les travaux Jenkins pour sélectionner les agents).
   • Type d’instance : t3.medium (ou approprié).
   • Zone de disponibilité : Sélectionnez votre AZ préférée ou laissez vide pour aléatoire.
   • Instance Spot : Cochez cette case.
   • Prix maximum Spot : Définissez une enchère maximale (par exemple, 0.10).
   • FS distant racine : /home/jenkins
   • Utilisateur distant : ubuntu (ou l’utilisateur de votre AMI).
   • Utilisation : Seulement les travaux de construction avec des expressions d'étiquette correspondant à ce nœud.
   • Temps de terminaison inactif : Définissez une durée (par exemple, 10 minutes) après laquelle un agent inactif sera supprimé.
3. Tester l’auto-scaling :

   Créez un travail Jenkins et configurez-le pour s’exécuter sur un agent avec l’étiquette java-agent. Déclenchez plusieurs compilations simultanément. Vous devriez observer de nouvelles instances Spot EC2 apparaître dans votre console AWS et se connecter à Jenkins. Après que les compilations soient terminées et que les agents deviennent inactifs pour le temps configuré, ils seront terminés.

Exemple 2 : GitLab CI avec GitLab Runner sur Docker Machine

GitLab CI s’intègre parfaitement avec GitLab Runner, qui peut être configuré pour s’auto-scaler en utilisant Docker Machine sur divers fournisseurs de cloud.

Prérequis :

• Une instance GitLab en cours d’exécution (SaaS ou auto-hébergée).
• Un serveur (par exemple, EC2, VM) pour héberger le gestionnaire de GitLab Runner.
• Docker et Docker Machine installés sur le gestionnaire de GitLab Runner.
• Identifiants du fournisseur de cloud (par exemple, AWS Access Key ID et Secret Access Key configurés sur le gestionnaire de Runner).

Étapes :

1. Installer et enregistrer GitLab Runner :

   Sur votre serveur de gestionnaire de Runner dédié, installez GitLab Runner :

   curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash
   sudo apt install gitlab-runner
   
   # Inscrivez le runner (obtenez votre token d'inscription dans les paramètres du projet/groupe GitLab)
   sudo gitlab-runner register 
    --url "https://gitlab.com/" 
    --registration-token "<votre-token-d'inscription>" 
    --description "Docker Machine Auto-scaling Runner" 
    --tag-list "docker,aws" 
    --executor "docker+machine"

2. Configurer config.toml pour Docker Machine :

   Éditez le fichier de configuration du Runner, généralement situé à /etc/gitlab-runner/config.toml.

   Ajoutez/modifiez la section [[runners]] et ajoutez une section [runners.docker] et [runners.machine].

   [[runners]]
    name = "Docker Machine Auto-scaling Runner"
    url = "https://gitlab.com/"
    token = "<your-registration-token>"
    executor = "docker+machine"
    [runners.docker]
    tls_verify = false
    image = "ubuntu:latest" # Image par défaut pour les builds
    privileged = false
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/cache"]
    shm_size = 0
    [runners.machine]
    IdleCount = 1 # Garder au moins une machine inactive
    IdleTime = 600 # Terminer les machines inactives après 10 minutes
    MaxBuilds = 100 # Terminer la machine après 100 builds
    MachineDriver = "amazonec2"
    MachineName = "gitlab-runner-%s"
    MachineOptions = [
    "amazonec2-instance-type=t3.medium",
    "amazonec2-ami=ami-0abcdef1234567890", # Utiliser une AMI de base avec Docker pré-installé
    "amazonec2-region=us-east-1",
    "amazonec2-vpc-id=vpc-0123456789abcdef0",
    "amazonec2-subnet-id=subnet-0abcdef1234567890",
    "amazonec2-security-group=gitlab-runner-sg",
    "amazonec2-use-private-address=true",
    "amazonec2-tags=gitlab-runner-managed,project:my-project"
    ]
    # Optionnel : Configurez Docker Machine pour les instances Spot
    # MachineOptions = [
    # ...,
    # "amazonec2-request-spot-instance=true",
    # "amazonec2-spot-price=0.05",
    # ]
   

   Note sur l’AMI : Pour Docker Machine, votre AMI doit avoir Docker pré-installé et configuré pour démarrer au démarrage. Docker Machine utilisera ensuite cette AMI pour provisionner de nouvelles instances.

3. Redémarrer GitLab Runner :

   sudo gitlab-runner restart

4. Tester l’Auto-Scaling :

   Faites quelques modifications dans un dépôt GitLab qui déclenche un pipeline CI. Déclenchez plusieurs pipelines simultanément. Vous devriez voir de nouvelles instances EC2 se créer (ou des VM sur votre cloud choisi) et exécuter vos tâches. Après une période d’inactivité, elles seront terminées.

Exemple 3 : Kubernetes avec Cluster Autoscaler

Pour des charges de travail hautement dynamiques et conteneurisées, Kubernetes propose une solution d’auto-scaling puissante. Ici, vos agents CI/CD fonctionnent en tant que pods, et le Cluster Autoscaler de Kubernetes ajuste le pool de nœuds sous-jacent.

Prérequis :

• Un cluster Kubernetes en cours d’exécution (par exemple, EKS, AKS, GKE ou auto-géré).
• kubectl configuré pour accéder à votre cluster.
• Un système CI/CD capable de déployer des tâches en tant que pods Kubernetes (par exemple, plugin Kubernetes Jenkins, exécuteur Kubernetes GitLab CI, Tekton, Argo Workflows).

Étapes (conceptuelles pour l’exécuteur Kubernetes GitLab CI) :

1. Déployer le Cluster Autoscaler :

   Suivez la documentation pour déployer le Cluster Autoscaler spécifique à votre fournisseur de cloud (par exemple, EKS Cluster Autoscaler, GKE Cluster Autoscaler). Ce composant surveille les pods en attente et ajuste les groupes de nœuds à la hausse ou à la baisse.

   Exemple (EKS – simplifié, reportez-vous aux docs officielles) :

   # Créer une politique IAM pour le Cluster Autoscaler
   # Créer un rôle IAM et attacher la politique
   # Créer un compte de service et l'associer au rôle IAM
   # Déployer le déploiement du Cluster Autoscaler en utilisant Helm ou YAML
   
   # Exemple de commande Helm pour EKS Cluster Autoscaler
   helm upgrade --install cluster-autoscaler stable/cluster-autoscaler \
    --namespace kube-system \
    --set autoDiscovery.clusterName=<your-cluster-name> \
    --set rbac.create=true \
    --set serviceAccount.create=true \
    --set serviceAccount.name=cluster-autoscaler \
    --set image.repository=k8s.gcr.io/cluster-autoscaler \
    --set image.tag=v1.22.0 # Correspondre à votre version K8s
   

2. Configurer des groupes de nœuds/pools de nœuds dynamiques :

   Assurez-vous que votre cluster Kubernetes dispose de groupes de nœuds/pools configurés pour l’auto-scaling. Définissez des tailles minimum et maximum pour ces groupes.

   Exemple (GKE) :

   gcloud container node-pools create ci-agents-pool \
    --cluster <your-cluster-name> \
    --machine-type=e2-medium \
    --num-nodes=0 \
    --min-nodes=0 \
    --max-nodes=10 \
    --enable-autoscaling \
    --region=<your-region>

3. Configurer le système CI/CD pour utiliser l’exécuteur Kubernetes :

   Pour GitLab CI, enregistrez un Runner avec l’exécuteur Kubernetes. Cet exécuteur lancera un nouveau pod pour chaque tâche.

   sudo gitlab-runner register 
    --url "https://gitlab.com/" 
    --registration-token "<your-registration-token>" 
    --description "Kubernetes CI Runner" 
    --tag-list "kubernetes,docker" 
    --executor "kubernetes"

   Modifier /etc/gitlab-runner/config.toml :

   [[runners]]
    name = "Kubernetes CI Runner"
    url = "https://gitlab.com/"
    token = "<your-registration-token>"
    executor = "kubernetes"
    [runners.kubernetes]
    host = "" # Laisser vide pour la configuration en cluster
    namespace = "gitlab-runner"
    cpu_limit = "500m"
    memory_limit = "1Gi"
    image = "docker:20.10.16-dind-rootless" # Ou votre image de base préférée
    pull_policy = ["if-not-present", "always"]
    # Optionnel : Configurer une image de base pour vos builds
    # helper_image = "gitlab/gitlab-runner-helper:latest"
   

4. Tester l’Auto-Scaling :

   D déclencha plusieurs pipelines CI/CD. Observez de nouveaux pods créés dans l’espace de noms gitlab-runner. S’il n’y a pas assez de nœuds, le Cluster Autoscaler provisionnera de nouveaux nœuds dans votre ci-agents-pool. Une fois les tâches terminées, les pods se terminent et les nœuds inactifs sont réduits.

Meilleures Pratiques pour les Agents Auto-Scalables

• Utilisez des Images d’Agent Immuables : Construisez vos images d’agent (AMIs, images Docker) avec tous les outils nécessaires pré-installés. Cela garantit la cohérence et accélère les temps de démarrage des agents.
• Utilisez des Instances Spot/Préemptibles : Pour des builds non critiques ou tolérants aux pannes, l’utilisation d’instances spot peut réduire considérablement les coûts. Implémentez une logique de reprise dans votre CI/CD si les tâches peuvent être interrompues.
• Configurer un Rétrécissement Agressif : Pour optimiser les coûts, configurez les agents pour qu’ils se terminent rapidement après être devenus inactifs.
• Définir des Limites pour les Instances : Toujours définir des limites maximales pour vos groupes d’auto-scaling ou pools de nœuds pour éviter des dépassements de coûts inattendus.
• Surveillez Votre Infrastructure : Gardez un œil sur les files d’attente de builds, l’utilisation des agents et les coûts cloud. Ajustez les politiques de scaling selon les besoins.
• Optimisez le Temps de Démarrage des Agents : Minimisez le temps nécessaire pour qu’un agent soit prêt. Cela inclut l’optimisation de la taille de l’image, l’utilisation efficace de scripts cloud-init et la mise en cache des dépendances.
• Utilisez des Labels/Tags pour la Granularité : Utilisez des labels (Jenkins, Kubernetes) ou tags (GitLab) pour diriger des tâches spécifiques vers des agents ayant les bonnes capacités (par exemple, java-17, node-lts, gpu-enabled).
• Considérez des Pools Chauds : Pour des scénarios où un scaling rapide est critique, maintenez un petit "pouls chaud" d’agents inactifs prêts à reprendre instantanément des tâches, tout en permettant une montée en charge supplémentaire à la demande.

Conclusion

L’infrastructure d’agents auto-scalables n’est plus un luxe mais une nécessité pour les pipelines CI/CD modernes. En ajustant dynamiquement votre capacité d’agent, vous pouvez réaliser des économies significatives, améliorer la productivité des développeurs grâce à des retours plus rapides et construire un système de livraison plus résilient et élastique. Que vous choisissiez des groupes d’auto-scaling d’un fournisseur de cloud, des intégrations spécifiques à CI/CD ou une approche centrée sur Kubernetes, les principes demeurent les mêmes : automatisez, optimisez et ajustez pour répondre à la demande. Commencez par une configuration simple, surveillez ses performances et affinez de manière itérative votre stratégie d’auto-scaling pour parfaitement répondre aux besoins de votre équipe.

🕒 Published: March 26, 2026