Jenkins CI/CD : installer, pipelines et Jenkinsfile (hub 2026)
À la fin de cette page hub, vous saurez pourquoi Jenkins reste pertinent en 2026, comment installer Jenkins sur Ubuntu 24.04 LTS (keyring apt moderne, OpenJDK 17), décrire l’architecture controller/agents, écrire un Jenkinsfile déclaratif (checkout → build → test → image Docker) et gérer les secrets sans les hard-coder — puis vous orienter dans le parcours Jenkins du site.
Niveau : Débutant → Intermédiaire · Temps estimé : 55–70 min · Versions cibles : Jenkins LTS récent (2.452+) · OpenJDK 17+ · Ubuntu 24.04 LTS · Docker Engine 27+ (agents) · Dernière vérification : 2026-09-11
Prérequis
- [ ] Serveur ou VM Ubuntu 24.04 LTS (lab) : 4 Go RAM minimum, 2 vCPU, 20 Go disque
- [ ] Accès sudo pour installer paquets et ouvrir le pare-feu
- [ ] Notions Git (clone, branche
main) — voir Git : contrôle de version distribué - [ ] (Recommandé) Docker Engine pour agents et
docker build— hub Docker - [ ] (Optionnel) Maven pour le build Java de démo — Maven build tool
- [ ] Coût estimé : 0 € en lab local / VM perso
Ce hub absorbe et enrichit le contenu live de /jenkins/ (install Ubuntu 24.04, Jenkinsfile, hardening, FAQ) en français pédagogique SEO. Les leçons sœurs détaillent introduction, install longue et syntaxe Jenkinsfile ; ici l’objectif est une page pilier menu.
Objectif : controller LTS joignable, Pipeline déclaratif versionné, checklist durcissement (UFW, credentials, agents) — flux reproductible dans Git.
Ce que nous allons construire
Hub Jenkins (menu CI/CD)
├── Pourquoi Jenkins en 2026 vs GitHub Actions / GitLab CI
├── Architecture : controller, agents, executors, plugins, credentials
├── Install rapide Ubuntu 24.04 (keyring, OpenJDK 17, systemctl, UFW)
├── Premier Pipeline déclaratif + Jenkinsfile (checkout/build/test/docker)
├── Agents Docker + secrets (credentials / withCredentials)
├── Erreurs fréquentes + FAQ (5)
└── Carte du parcours → Docker / Kubernetes / Maven / Git / Ansible
(Schéma à remplacer par une image locale, alt : « Architecture Jenkins : controller, agents Docker et pipeline as code Jenkinsfile ».)
Étape 1 — Pourquoi Jenkins en 2026 (CI/CD et pipeline as code)
Jenkins est le serveur d’automatisation open source de référence pour la CI/CD : il orchestre builds, tests, scans et déploiements via des pipelines as code (Jenkinsfile versionné dans Git). En 2026, il reste massivement déployé grâce à son écosystème de plugins, à l’exécution self-hosted et à la maturité des pipelines déclaratifs.
| Critère | Jenkins | GitHub Actions / GitLab CI |
|---|---|---|
| Hébergement | Self-hosted (contrôle total) | SaaS (+ runners self-hosted optionnels) |
| Forces | Plugins, agents custom, multi-SCM | UX native au forge, moins d’ops controller |
| Attention | Maintenance plugins / controller | Coût minutes, vendor lock-in |
| Pipeline as code | Jenkinsfile déclaratif |
YAML workflows / .gitlab-ci.yml |
Choisir Jenkins si agents custom, on-prem ou héritage fort. Préférer Actions/GitLab CI si l’équipe est 100 % SaaS. Les trois coexistent : l’essentiel reste le pipeline as code et des secrets hors dépôt.
Jenkins brille pour mélanger des outils (Maven, npm, Terraform, Ansible) sur agents labellisés, ou pour garder code/artefacts on-prem. Budgétez l’ops (LTS, plugins, backup $JENKINS_HOME). Les pages sœurs détaillent chaque brique.
Étape 2 — Architecture : controller, agents, executors, plugins
| Élément | Rôle |
|---|---|
| Controller | UI, orchestration, plugins, file d’attente |
| Agent | Nœud (VM/conteneur) qui exécute les stages |
| Executor | Slot de concurrence (1 build ≈ 1 executor) |
| Plugin | Git, Docker Pipeline, Credentials, Kubernetes… |
| Credentials | Secrets chiffrés côté Jenkins (hors Jenkinsfile) |
| Pipeline | Job défini par un Jenkinsfile (déclaratif recommandé) |
Bonne pratique 2026 : 2–4 executors sur le controller ; builds lourds sur agents Docker ou pods Kubernetes (registry.k8s.io avec le plugin K8s). Évitez Maven/Docker intensifs sur le controller en production.
Controller = file d’attente, historique, Credentials ; agents = JDK/Maven/Docker. Label (jdk17, docker) via agent { label '...' }. Sur K8s : pods éphémères, controller stable.
Étape 3 — Installer Jenkins rapidement sur Ubuntu 24.04 LTS
Mettez à jour le système, puis ajoutez le dépôt officiel avec keyring (méthode moderne — pas apt-key) :
sudo apt update && sudo apt upgrade -y
sudo apt install -y wget gnupg openjdk-17-jre-headless
sudo mkdir -p /etc/apt/keyrings
wget -O- https://pkg.jenkins.io/debian-stable/jenkins.io-2023.key
| sudo tee /etc/apt/keyrings/jenkins-keyring.asc > /dev/null
echo "deb [signed-by=/etc/apt/keyrings/jenkins-keyring.asc]
https://pkg.jenkins.io/debian-stable binary/"
| sudo tee /etc/apt/sources.list.d/jenkins.list
sudo apt update
sudo apt install -y jenkins
Sortie attendue : paquets installés sans erreur ; dépôt debian-stable (ligne LTS).
sudo systemctl start jenkins
sudo systemctl enable jenkins
sudo systemctl status jenkins --no-pager
sudo cat /var/lib/jenkins/secrets/initialAdminPassword
Attendu : Active: active (running) et une chaîne ~32 caractères. Ouvrez http://VOTRE_IP:8080, collez le mot de passe, installez les plugins suggérés, créez le compte admin. Ne laissez pas ce fichier password exposé après setup.
Durcissement minimal
sudo ufw allow OpenSSH
sudo ufw allow 8080/tcp
sudo ufw enable
sudo ufw status
Attendu : 22/tcp et 8080/tcp en ALLOW. En prod : reverse proxy HTTPS, SSO/OIDC, restriction IP. Conservez l’utilisateur système jenkins (jamais root).
Après le wizard : version LTS (About), plugins avec prudence, backup $JENKINS_HOME. Lab = snapshot VM ; équipe = URL, admin, systemctl restart.
Détail wizard : jenkins-installation · concepts : jenkins-introduction.
Étape 4 — Premier Pipeline déclaratif et Jenkinsfile
Placez un Jenkinsfile à la racine du dépôt :
pipeline {
agent any
parameters {
choice(name: 'ENV', choices: ['dev', 'staging', 'prod'],
description: 'Environnement cible')
}
environment {
DOCKER_REGISTRY = 'registry.example.com'
APP_IMAGE = "${DOCKER_REGISTRY}/demo-app:${env.BUILD_NUMBER}"
}
stages {
stage('Checkout') {
steps { checkout scm }
}
stage('Build') {
steps { sh 'mvn -B clean package -DskipTests' }
}
stage('Test') {
steps { sh 'mvn -B test' }
}
stage('Docker Build') {
steps {
sh "docker build -t ${APP_IMAGE} ."
echo "Image ${params.ENV} : ${APP_IMAGE}"
}
}
}
post { always { cleanWs() } }
}
Dans Jenkins : Nouveau job → Pipeline → script depuis le SCM (Pipeline script from SCM) → URL Git + credentials → chemin Jenkinsfile. Premier run : clone → Maven → tests → docker build. Paramètres via Build with Parameters (${params.ENV}, ${env.BUILD_NUMBER}).
Pipeline from SCM versionne le Jenkinsfile (PR, rollback). cleanWs() évite d’accumuler des workspaces. Échec Maven : corrigez localement (mvn -B test) puis relancez. Paramètres ENV = dev/staging/prod sans dupliquer le job.
Approfondir : jenkinsfile, jenkins-tutorials. Build Java → Maven ; image → Docker puis Kubernetes.
Étape 5 — Agents Docker et secrets (jamais en clair)
Agents Docker
Préférez une image agent plutôt que d’installer tous les outils sur le controller :
pipeline {
agent {
docker {
image 'maven:3.9-eclipse-temurin-17'
// Lab : socket Docker = accès privilégié hôte — à restreindre en prod
args '-v /var/run/docker.sock:/var/run/docker.sock'
}
}
stages {
stage('Build') {
steps { sh 'mvn -B -version && mvn -B clean package' }
}
}
}
Agents durables : image jenkins/inbound-agent, connexion inbound TCP (port 50000), labels (docker, jdk17). Sur Kubernetes : pods éphémères via le plugin (images registry.k8s.io si besoin).
Le socket Docker (/var/run/docker.sock) est pratique en lab mais quasi-root sur l’hôte : en prod préférez un builder contrôlé (Kaniko/Buildah, daemon distant). Documentez CPU/RAM des agents pour limiter la contention.
Credentials et withCredentials
Jamais de mot de passe, token ou clé en dur dans le Jenkinsfile ou les logs. Créez une entrée Manage Jenkins → Credentials, puis :
stage('Push registry') {
steps {
withCredentials([usernamePassword(
credentialsId: 'registry-bot',
usernameVariable: 'REG_USER',
passwordVariable: 'REG_PASS'
)]) {
sh '''
echo "$REG_PASS" | docker login -u "$REG_USER" --password-stdin registry.example.com
docker push "$APP_IMAGE"
'''
}
}
}
Alternative : credentials('id-ssh-git') / sshagent. Rotation = mise à jour du magasin Jenkins, sans commit Git.
Bonnes habitudes : credentialsId stables (registry-bot, git-readonly), comptes de service, scopes minimaux. Vérifiez que les logs ne fuient pas le secret (évitez les echo maladroits) — testez sur un job jetable avant la prod.
Étape 6 — Erreurs fréquentes
| Symptôme | Cause probable | Correction |
|---|---|---|
Cannot run program "docker" |
jenkins hors groupe docker |
sudo usermod -aG docker jenkins puis restart service |
| Échec Checkout (auth Git) | Credentials SCM manquants | PAT HTTPS ou clé SSH dans le store ; tester git ls-remote |
Permission denied /var/lib/jenkins |
Lancement en root / droits cassés | Utilisateur jenkins ; chown -R jenkins:jenkins |
OutOfMemoryError / heap |
Builds lourds sur controller | JAVA_OPTS="-Xmx4g" dans /etc/default/jenkins ; agents |
| Port 8080 inaccessible | UFW / SG / service down | systemctl status jenkins ; ufw allow 8080/tcp |
| Pipeline rouge après upgrade | Plugin incompatible | Notes LTS ; staging ; apt upgrade jenkins + restart |
Étape 7 — Carte du parcours Jenkins sur le site
| Ordre | Page | Rôle |
|---|---|---|
| 1 (hub) | jenkins (cette page) |
Pilier menu : install, architecture, Jenkinsfile, secrets |
| 2 | jenkins-introduction | Concepts CI/CD et vocabulaire |
| 3 | jenkins-installation | Install détaillée / options |
| 4 | jenkinsfile | Syntaxe déclarative approfondie |
| 5 | jenkins-tutorials | Labs et enchaînements pratiques |
Suite DevOps : Git → Maven → Docker → Jenkins → Kubernetes → Ansible. Un même commit déclenche build + image + (plus tard) déploiement.
Hub menu : débutants → introduction → installation → Jenkinsfile ; forge Azure → Jenkins with Azure Repos. Objectif : pipeline lisible, sécurisé, rejouable — pas une forêt de plugins.
FAQ
1. Comment mettre à jour Jenkins sur Ubuntu 24.04 ?
sudo apt update && sudo apt upgrade jenkins, puis sudo systemctl restart jenkins. Vérifiez Manage Jenkins → About. Lisez les notes LTS ; en équipe, validez d’abord sur un staging (mêmes Jenkinsfile / agents).
2. Puis-je exécuter des agents Jenkins dans des conteneurs Docker ?
Oui. Image jenkins/inbound-agent (ou agent Docker Pipeline éphémère). Connexion inbound souvent sur le port 50000. Sur cluster, préférez le plugin Kubernetes et des pods jetables.
3. Quelle est la bonne façon de stocker les secrets dans un Jenkinsfile ?
Ne jamais hard-coder. Magasin Credentials + credentials() / withCredentials au runtime. Préférez des tokens à durée limitée (PAT, robot registry) et documentez qui peut les faire tourner.
4. Combien d’executors configurer sur le controller ?
2 à 4 maximum pour l’UI et l’orchestration. Les builds CPU/RAM intensifs vont sur des agents dédiés ou pods.
5. Jenkins parle-t-il nativement à Kubernetes 1.31+ ?
Oui via le Kubernetes plugin : pods agents, images pointant vers registry.k8s.io quand vous utilisez des composants officiels. Combinez ensuite avec Helm / GitOps pour le CD.
Points clés à retenir
- Jenkins reste un pilier CI/CD self-hosted en 2026 grâce aux plugins et au Jenkinsfile versionné.
- Architecture saine : controller léger, agents (Docker/K8s) pour le travail lourd, credentials hors dépôt.
- Install Ubuntu 24.04 : OpenJDK 17+, dépôt debian-stable avec keyring (pas
apt-key),systemctl, UFW 8080. - Premier pipeline : Checkout → Build → Test → Docker ; paramètres +
environment. - Secrets :
withCredentials/credentials()uniquement — zéro secret en clair dans Git ou les logs. - Ops : backup
$JENKINS_HOME, LTS + plugins maîtrisés, HTTPS (reverse proxy) hors lab local.
Sauvegarder le controller et tenir le quotidien
Une install Jenkins qui « tourne » n’est pas encore un socle d’équipe. Trois habitudes séparent le lab du contrôleur à montrer.
Sauvegardez le répertoire maison du controller. Jobs, credentials chiffrés, plugins et historique vivent là. Sur Ubuntu 24.04, une archive nocturne ou un snapshot de disque suffit en lab ; en équipe, versionnez aussi les jobs (Job DSL ou configuration as code) pour ne pas dépendre d’un seul fichier XML. Testez la restauration une fois : un backup jamais relu est un talisman.
Ensuite, préférez le webhook du dépôt au poll. Un job qui interroge Git toutes les minutes charge le controller et retarde le feedback. GitHub, GitLab ou Azure Repos poussent un événement ; Jenkins clone et enchaîne. Moins de charge, traces plus claires.
Enfin, traitez les plugins comme du code de production : liste minimale, notes LTS lues, montée d’abord sur un staging. Documentez pour l’équipe : relance du controller, credentials registry, qui promeut vers la production.
Ces trois réflexes complètent l’install Ubuntu, le pipeline déclaratif et les secrets hors dépôt — pont vers Docker, Maven et le Capstone.
Pour aller plus loin
- Documentation officielle Jenkins : installation Linux, syntaxe Pipeline, Docker with Pipeline
- Durcir : TLS (reverse proxy), SSO, backup
$JENKINS_HOME, plugins minimaux - Multibranch : un
Jenkinsfiledétecté par branche/PR - Suite : SonarQube, Kubernetes, Ansible
- Observabilité : archiver JUnit / couverture, alerter sur les jobs rouges chroniques
Maillage série DevOps (CTA)
| ← Connexe | Git · Maven |
| → Suite Jenkins | Introduction · Installation · Jenkinsfile · Tutorials |
| Aussi | Docker · Kubernetes · Ansible |
