Introduction aux agents distribués pour des builds plus complexes

Pourquoi distribuer les builds : les limites d'un Jenkins mono-noeud

Jusqu'à présent, vos projets Jenkins se sont probablement exécutés sur le serveur Jenkins principal lui-même, aussi appelé le "master" ou "contrôleur". Pour des petits projets ou des phases d'apprentissage, cela peut suffire. Cependant, à mesure que le nombre de projets, la fréquence des builds, et la complexité des tâches d'automatisation augmentent, s'appuyer uniquement sur le master Jenkins pour exécuter tous les builds présente des limites significatives.

Premièrement, la performance : le master Jenkins a besoin de ressources pour gérer son interface utilisateur, orchestrer les pipelines, stocker les configurations, etc. Si en plus il doit exécuter des builds gourmands en CPU ou en mémoire, il peut devenir lent et instable. Deuxièmement, la scalabilité : un seul noeud ne peut exécuter qu'un nombre limité de builds simultanément (défini par le nombre d'exécuteurs configurés sur le master). Cela peut créer des files d'attente importantes si de nombreux builds sont déclenchés en même temps. Troisièmement, la diversité des environnements de build : différents projets peuvent nécessiter des systèmes d'exploitation, des versions de langages, des outils ou des bibliothèques spécifiques qui ne peuvent pas tous cohabiter facilement sur une seule machine.

C'est là qu'intervient le concept d'agents distribués (parfois encore appelés "slaves" ou "noeuds" dans des documentations plus anciennes). L'idée est de déporter la charge d'exécution des builds du master vers une flotte de machines dédiées, appelées agents. Le master Jenkins se concentre alors sur son rôle d'orchestrateur, tandis que les agents effectuent le travail effectif de construction, de test, et de déploiement.

Le rôle et les avantages des agents Jenkins

Un agent Jenkins est une machine (physique ou virtuelle, sur site ou dans le cloud, ou même un conteneur Docker) qui est connectée au master Jenkins et capable d'exécuter les tâches de build qui lui sont assignées. Le master communique avec les agents pour leur envoyer les instructions du pipeline, récupérer les artefacts et les logs.

L'utilisation d'agents distribués apporte de nombreux avantages :

• Amélioration de la performance et de la scalabilité : En ajoutant plus d'agents, vous augmentez la capacité de votre système Jenkins à exécuter des builds en parallèle. Cela réduit les temps d'attente et permet de traiter un volume plus important de travaux.
• Spécialisation des environnements : Vous pouvez configurer des agents avec des environnements spécifiques. Par exemple, un agent Windows avec Visual Studio pour compiler des projets .NET, un agent Linux avec une version spécifique de Java et Maven, un agent macOS avec Xcode pour des builds iOS, ou un agent avec Docker installé pour exécuter des builds dans des conteneurs.
• Isolation des builds : Chaque build s'exécute sur un agent, ce qui peut offrir une meilleure isolation par rapport aux autres builds et au master lui-même, réduisant les risques d'interférences.
• Sécurité : Exécuter les builds sur des agents permet de limiter les outils et les accès nécessaires sur le master Jenkins, qui peut être davantage sécurisé.
• Maintenance facilitée : Si un agent rencontre un problème, il peut être mis hors service et remplacé sans impacter directement le master ou les autres agents.

En résumé, les agents distribués transforment Jenkins d'une application potentiellement monolithique en un système distribué, robuste et adaptable, capable de gérer des charges de travail importantes et des exigences d'environnement hétérogènes.

Configurer et connecter des agents au master Jenkins

Il existe plusieurs manières de configurer et de connecter des agents au master Jenkins. La configuration se fait généralement depuis l'interface de Jenkins, dans "Gérer Jenkins" > "Gestion des noeuds et des clouds" (Manage Nodes and Clouds).

Les méthodes de connexion courantes incluent :

• Lancement d'agents via SSH : Le master Jenkins se connecte à l'agent via SSH et y lance le processus agent. C'est une méthode courante pour les agents Linux ou macOS.
• Lancement d'agents via Java Web Start (JNLP) : L'agent initie la connexion vers le master. Un processus agent (agent.jar) est démarré sur la machine agent, qui se connecte ensuite au master via un port JNLP. Cette méthode est souvent utilisée pour les agents Windows ou lorsque l'agent est derrière un pare-feu qui empêche les connexions SSH entrantes vers l'agent.
• Agents Docker : Avec des plugins comme Docker Pipeline, Jenkins peut dynamiquement provisionner des conteneurs Docker qui agissent comme des agents éphémères pour un build spécifique. L'environnement de build est défini par l'image Docker.
• Agents Cloud : Des plugins pour AWS (EC2 Plugin), Azure (Azure VM Agents Plugin), Google Cloud, Kubernetes, etc., permettent à Jenkins de provisionner et de dé-provisionner dynamiquement des agents sur des plateformes cloud en fonction de la demande. C'est une solution très flexible et économique.

Chaque agent configuré dans Jenkins peut avoir des "labels" (étiquettes). Les labels sont des chaînes de caractères (par exemple, linux, windows, docker, jdk11, performance-tests) qui décrivent les capacités ou le rôle de l'agent. Ces labels sont ensuite utilisés dans les Jenkinsfiles pour spécifier sur quel type d'agent un pipeline ou un stage doit s'exécuter.

Utiliser les agents dans un Jenkinsfile : la directive `agent`

Dans un Jenkinsfile Déclaratif, la directive agent contrôle où l'ensemble du pipeline, ou un stage spécifique, s'exécutera. Lorsque vous utilisez des agents distribués, cette directive devient cruciale.

Voici quelques exemples d'utilisation de la directive agent :

• agent any : Le pipeline peut s'exécuter sur n'importe quel agent disponible (y compris le master si celui-ci est configuré pour accepter des builds, ce qui est souvent déconseillé en production).
• agent none : Utilisé au niveau supérieur du pipeline si chaque stage définit son propre agent.
• agent { label 'mon-label-agent' } : Le pipeline ou le stage s'exécutera sur un agent possédant le label mon-label-agent. S'il y a plusieurs agents avec ce label, Jenkins en choisira un disponible.
• agent { label 'windows && dotnetcore' } : Utilise des expressions logiques pour combiner des labels. S'exécutera sur un agent ayant à la fois le label windows ET le label dotnetcore.
• agent { docker { image 'maven:3.8.1-jdk-11' args '-v /tmp:/tmp' } } : (Nécessite le plugin Docker Pipeline) Exécute le pipeline ou le stage à l'intérieur d'un conteneur Docker basé sur l'image maven:3.8.1-jdk-11. Jenkins peut provisionner ce conteneur sur un agent ayant Docker installé.
• agent { node { label 'mon-label-agent'; customWorkspace '/chemin/vers/workspace/specifique' } } : Permet plus de contrôle, comme la définition d'un espace de travail personnalisé sur l'agent.

Exemple de pipeline utilisant différents agents par stage :

pipeline {
    agent none // Pas d'agent global, chaque stage définit le sien
    stages {
        stage('Build Backend') {
            agent { label 'linux-java11' } // Agent spécifique pour le backend Java
            steps {
                echo "Construction du backend sur un agent Linux avec Java 11..."
                sh 'mvn clean install'
            }
        }
        stage('Build Frontend') {
            agent { docker { image 'node:16-alpine' } } // Agent Docker pour le frontend Node.js
            steps {
                echo "Construction du frontend dans un conteneur Node.js..."
                sh 'npm install && npm run build'
            }
        }
        stage('Deploy to Staging') {
            agent { label 'deploy-tools' } // Agent avec les outils de déploiement nécessaires
            steps {
                echo "Déploiement sur l'environnement de staging..."
                // sh './deploy_script.sh staging'
            }
        }
    }
}

L'introduction aux agents distribués ouvre un vaste champ de possibilités pour optimiser et adapter vos processus CI/CD avec Jenkins. Cela demande une certaine planification de l'infrastructure de vos agents, mais les gains en termes de performance, de flexibilité et de maintenabilité pour des builds plus complexes sont considérables.