Jenkins #4 — Plugins Essentiels : Docker, K8s, Git, SonarQube et Slack

Jenkins sans plugins, c’est un scheduler Groovy glorifié. Les 1800+ plugins du catalogue transforment un moteur basique en plateforme CI/CD complète. Docker, Kubernetes, SonarQube, Slack — tout passe par un plugin.

Ce cours couvre les plugins que tu retrouveras dans 90% des installations Jenkins en production. Pas la doc officielle réchauffée : les patterns concrets, les pièges courants, et la config qui tient la route.

Gestion des plugins et Configuration as Code

L’UI (Manage Jenkins → Plugins) suffit pour explorer, mais en production tu veux de l’automation. Le Plugin Installation Manager est le standard pour Docker et les déploiements automatisés.

# Installation automatisée des plugins
jenkins-plugin-cli --plugins \
  "docker-workflow kubernetes git slack sonar credentials-binding" \
  --war /usr/share/java/jenkins.war

# Lister les plugins installés (Script Console)
Jenkins.instance.pluginManager.plugins.each {
    println "${it.shortName} (${it.version})"
}

JCasC — le plugin non-négociable

Le plugin Configuration as Code configure Jenkins entièrement via YAML. Reproductible, versionnable, auditable. Chaque modification passe par une PR — fini les changements sauvages dans l’UI que personne ne retrouve.

# jenkins.yaml — exemple de configuration complète
jenkins:
  systemMessage: "Jenkins configuré par JCasC"
  numExecutors: 0
  securityRealm:
    local:
      allowsSignup: false

unclassified:
  slackNotifier:
    teamDomain: "mon-equipe"
    tokenCredentialId: "slack-token"
  sonarGlobalConfiguration:
    installations:
      - name: "SonarQube"
        serverUrl: "https://sonar.example.com"
        credentialsId: "sonar-token"

💡 Le combo gagnant : JCasC + Job DSL. Le premier configure Jenkins lui-même, le second génère tous les jobs par code. Résultat : tu reconstruis ton Jenkins from scratch en 10 minutes à partir d’un repo Git.

Docker Pipeline — builder et exécuter des conteneurs

Le plugin docker-workflow couvre trois cas d’usage majeurs : utiliser Docker comme agent, builder des images, et pusher vers un registre.

Docker comme agent — ton stage s’exécute dans un conteneur éphémère. Chaque build part d’un environnement propre, sans pollution entre projets :

pipeline {
    agent {
        docker {
            image 'node:20-alpine'
            args '-v /tmp:/tmp -e NODE_ENV=test'
            registryUrl 'https://registry.example.com'
            registryCredentialsId 'registry-creds'
        }
    }
    stages {
        stage('Build') {
            steps { sh 'npm ci && npm run build' }
        }
    }
}

Builder et pusher des images — le workflow complet avec docker.build() et docker.withRegistry() pour tagger et publier en une étape :

stage('Build & Push') {
    steps {
        script {
            docker.withRegistry("https://${REGISTRY}", 'registry-creds') {
                def image = docker.build("${REGISTRY}/mon-app:${BUILD_NUMBER}",
                    "-f docker/Dockerfile.prod --build-arg ENV=prod .")
                image.push()
                image.push('latest')
            }
        }
    }
}

⚠️ Piège classique : oublier le nettoyage des images locales. Ajoute toujours un post { always { sh "docker rmi ... || true" } } — sinon ton disque Jenkins explose en quelques semaines.

Kubernetes — agents dynamiques à la demande

Le plugin kubernetes transforme ton cluster K8s en pool d’agents élastique. Chaque build spawne un pod, chaque pod meurt après le job. Zéro gaspillage, scaling automatique.

La config se fait dans Manage Jenkins → Clouds → Kubernetes. Ensuite, tu définis tes pods directement dans le pipeline avec du YAML inline :

pipeline {
    agent {
        kubernetes {
            yaml '''
            apiVersion: v1
            kind: Pod
            spec:
              containers:
              - name: node
                image: node:20-alpine
                command: ['sleep', 'infinity']
                resources:
                  requests: { memory: "512Mi", cpu: "250m" }
                  limits: { memory: "1Gi", cpu: "500m" }
              - name: docker
                image: docker:24-dind
                securityContext:
                  privileged: true
            '''
            defaultContainer 'node'
        }
    }
    stages {
        stage('Build') {
            steps { sh 'npm ci && npm run build' }
        }
        stage('Docker') {
            steps {
                container('docker') { sh 'docker build -t mon-app .' }
            }
        }
    }
}

🔥 Pattern production : utilise des PersistentVolumeClaim pour cacher les dépendances Maven/npm entre builds. Sans cache, chaque build re-télécharge tout — c’est 5 à 10 minutes perdues par run sur un projet Java conséquent.

🎯 Multi-conteneur : un pod peut contenir Node, Docker-in-Docker et kubectl dans des conteneurs séparés. Tu bascules de l’un à l’autre avec container('nom'). Chaque outil est isolé, versionné indépendamment.

Credentials Binding — gérer les secrets proprement

Le plugin credentials-binding est fondamental. Chaque secret — token API, clé SSH, mot de passe — doit passer par lui. Jamais de secret en dur dans le code, jamais dans les variables d’environnement du système.

Deux méthodes d’injection

La première, via environment, crée automatiquement les variables _USR et _PSW. La seconde, via withCredentials, est plus granulaire et supporte les fichiers :

pipeline {
    agent any
    environment {
        DOCKER_CREDS = credentials('docker-hub')  // crée _USR et _PSW
    }
    stages {
        stage('Deploy') {
            steps {
                withCredentials([
                    string(credentialsId: 'slack-token', variable: 'SLACK_TOKEN'),
                    file(credentialsId: 'kubeconfig', variable: 'KUBECONFIG'),
                    sshUserPrivateKey(credentialsId: 'deploy-key',
                        keyFileVariable: 'SSH_KEY', usernameVariable: 'SSH_USER')
                ]) {
                    sh 'kubectl --kubeconfig=$KUBECONFIG apply -f k8s/'
                }
            }
        }
    }
}

Organiser par scope

Organise tes credentials par niveau d’accès. Global pour les secrets partagés comme le registre Docker. Folder pour les secrets d’équipe — chaque équipe ne voit que ses propres credentials. Job-specific pour les cas isolés, quand un seul pipeline a besoin d’un accès particulier.

⚠️ Sécurité critique : Jenkins masque les credentials dans les logs, mais set -x dans un script bash les affiche en clair. Vérifie toujours que tes scripts n’activent pas le debug mode en production. Un echo $SECRET suffit pour fuiter un token dans les logs.

SonarQube et Slack — qualité et alertes

Analyse de code avec SonarQube

Le plugin SonarQube Scanner intègre l’analyse de qualité directement dans le pipeline. Le pattern standard en deux étapes — analyse puis quality gate — bloque les déploiements si la qualité se dégrade :

stage('SonarQube') {
    steps {
        withSonarQubeEnv('SonarQube') {
            sh """
                sonar-scanner \
                    -Dsonar.projectKey=mon-projet \
                    -Dsonar.sources=src \
                    -Dsonar.javascript.lcov.reportPaths=coverage/lcov.info
            """
        }
    }
}
stage('Quality Gate') {
    steps {
        timeout(time: 5, unit: 'MINUTES') {
            waitForQualityGate abortPipeline: true
        }
    }
}

💡 Le waitForQualityGate est la vraie valeur ajoutée : si la couverture chute ou que des bugs critiques apparaissent, le build échoue avant le déploiement. C’est ton filet de sécurité automatique.

Notifications Slack

Les notifications dans le bloc post du pipeline. Crée une Slack App avec le scope chat:write, stocke le token dans Jenkins Credentials, et ajoute les messages de succès/échec. L’équipe sait en temps réel si un build casse — plus besoin de vérifier l’UI Jenkins manuellement.

🔥 Astuce pro : envoie les échecs dans un canal dédié #build-failures avec mention @channel. Les succès dans #builds sans mention. Comme ça, les vraies alertes ne se noient pas dans le bruit.

Pièges courants et résumé

Les trois erreurs qu’on voit dans toutes les entreprises qui débutent avec Jenkins :

⚠️ Trop de plugins — chaque plugin est une surface d’attaque et un risque de régression lors des mises à jour. Installe uniquement ce que tu utilises. Un Jenkins avec 15 plugins bien choisis bat un Jenkins avec 80 plugins dont la moitié sont abandonnés.

⚠️ Mises à jour en masse — ne fais jamais Update All un vendredi. Mets à jour un par un, teste entre chaque mise à jour, et commite la liste des versions dans ton JCasC. Une régression dans un plugin peut casser 200 jobs d’un coup.

⚠️ Plugins abandonnés — vérifie la date du dernier commit et le nombre d’installations actives avant d’adopter un plugin. Un plugin sans mise à jour depuis 2 ans est une bombe à retardement pour la sécurité.

🎯 Priorités d’installation pour un nouveau Jenkins :

• Jour 1 : Git, Credentials Binding, Pipeline — le minimum vital
• Semaine 1 : Docker Pipeline, Slack, JCasC — l’automatisation de base
• Mois 1 : Kubernetes, SonarQube, Job DSL — l’industrialisation

La règle d’or : chaque plugin installé doit résoudre un problème concret. Si tu ne sais pas pourquoi il est là, désinstalle-le.