Jenkins #1 — Introduction : Pourquoi Jenkins, Architecture et Premier Job

Tu fais un git push, et tout se déploie tout seul : tests, build, livraison. Pas de script bash planqué sur le PC de Jean-Pierre, pas de merge sauvage le vendredi soir. C’est exactement ce que Jenkins fait depuis plus de 15 ans pour des milliers d’équipes. Dans ce premier cours, tu vas comprendre pourquoi Jenkins reste le pilier du CI/CD, comment son architecture fonctionne, et tu vas installer ta première instance pour lancer un vrai job.

Pourquoi Jenkins est incontournable

Sans intégration continue, le quotidien d’une équipe ressemble à ça : chacun code dans son coin pendant des jours, le merge tourne au cauchemar, et les tests passent… quand on y pense. Jenkins automatise toute cette chaîne — chaque commit déclenche un build, lance les tests, et peut livrer en production sans intervention humaine.

Il existe d’autres outils (GitLab CI, GitHub Actions, CircleCI), mais Jenkins garde des atouts uniques. C’est 100% open source, tu l’héberges toi-même sans vendor lock-in, et son écosystème de 1800+ plugins permet d’intégrer à peu près n’importe quoi — du legacy COBOL au cluster Kubernetes.

🔥 Cas réel : Une banque européenne utilise Jenkins pour orchestrer 400 pipelines quotidiens sur des stacks hétérogènes (Java, .NET, mainframe). Aucun outil SaaS ne couvre ce spectre — Jenkins le fait grâce à ses agents spécialisés et ses plugins.

💡 Tip DevOps : Jenkins brille sur les infras complexes et les gros volumes. Si ton projet est un repo GitHub avec 3 devs, GitHub Actions sera plus simple. Choisis l’outil adapté au contexte, pas le plus populaire.

Comprendre l’architecture master/agent

Jenkins fonctionne sur un modèle controller/agent. Le controller (anciennement “master”) est le cerveau : il héberge l’interface web, planifie les jobs et stocke la configuration. Les agents sont les bras : ils exécutent réellement les builds.

Le controller gère quatre choses :

• L’interface web sur le port 8080 — ton dashboard de pilotage
• Le scheduler — il décide quel agent exécute quel job selon les labels
• L’API REST — pour automatiser Jenkins depuis l’extérieur
• La config — tout est dans $JENKINS_HOME (par défaut /var/lib/jenkins/)

Les agents se connectent au controller via SSH ou JNLP (port 50000). Chaque agent porte des labels (linux, docker, gpu…) et dispose d’executors — des slots d’exécution parallèle. Deux executors = deux jobs simultanés max sur cet agent.

⚠️ Attention : Ne lance jamais de builds sur le controller en production. Mets ses executors à zéro. Un build malveillant sur le controller compromet toute ton infrastructure Jenkins.

🧠 À retenir : Un job est une tâche automatisée. Un build est une exécution de ce job (numéroté #1, #2…). Le workspace est le répertoire de travail temporaire sur l’agent.

Commandes essentielles — Installer et lancer Jenkins

Jenkins tourne sur Java 17. Voici l’installation complète sur Ubuntu 22.04/24.04.

Pour installer Java et vérifier que tout est en place :

sudo apt update
sudo apt install -y fontconfig openjdk-17-jre
java -version

Ensuite, ajoute le dépôt officiel Jenkins et installe le paquet :

sudo wget -O /usr/share/keyrings/jenkins-keyring.asc \
  https://pkg.jenkins.io/debian-stable/jenkins.io-2023.key

echo "deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc]" \
  "https://pkg.jenkins.io/debian-stable binary/" | \
  sudo tee /etc/apt/sources.list.d/jenkins.list > /dev/null

sudo apt update && sudo apt install -y jenkins

Active et démarre le service, puis récupère le mot de passe admin initial :

sudo systemctl enable --now jenkins
sudo systemctl status jenkins
sudo cat /var/lib/jenkins/secrets/initialAdminPassword

Ouvre http://<IP>:8080, colle le mot de passe, installe les plugins suggérés et crée ton compte admin.

💡 Tip DevOps : Tu préfères Docker ? Une seule commande et c’est propre, sans toucher au système hôte :

docker run -d --name jenkins \
  -p 8080:8080 -p 50000:50000 \
  -v jenkins_home:/var/jenkins_home \
  jenkins/jenkins:lts-jdk17

Le volume jenkins_home persiste toute la config. Le port 50000 sert à la communication avec les agents JNLP.

Une fois Jenkins lancé, crée ton premier job : New Item → nom hello-world → Freestyle project. Dans Build Steps, ajoute un Execute shell :

#!/bin/bash
echo "=== Premier build Jenkins ==="
echo "Date  : $(date)"
echo "Agent : ${NODE_NAME}"
echo "Build : #${BUILD_NUMBER}"
echo "Job   : ${JOB_NAME}"
echo "Dir   : ${WORKSPACE}"

Clique Build Now, puis consulte la Console Output. Tu vois Jenkins injecter automatiquement ses variables d’environnement (BUILD_NUMBER, NODE_NAME, WORKSPACE…) dans chaque exécution.

Pour aller plus loin, paramètre ton job en cochant This project is parameterized. Tu peux ajouter des paramètres String, Choice ou Boolean et les utiliser dans tes scripts avec ${NOM_PARAM}.

Cas concret — Une startup passe de “ça marche sur ma machine” à Jenkins

Une startup de 12 devs pousse du code Python sur GitLab. Les tests tournent en local (quand le dev y pense), le déploiement se fait par scp sur le serveur de prod. Résultat : un bug en production tous les vendredis.

L’équipe installe Jenkins sur un VPS dédié. Configuration en 3 étapes :

1. Un job par service — chaque microservice a son pipeline qui clone le repo, lance pytest, builde l’image Docker
2. Des agents labelisés — un agent docker pour les builds d’images, un agent test avec les dépendances Python
3. Webhook GitLab — chaque push déclenche le pipeline automatiquement, plus besoin de poll

En configurant un déclencheur webhook et un script de build, voici ce que contient le job :

#!/bin/bash
set -e
pip install -r requirements.txt
pytest --junitxml=results.xml
docker build -t app:${BUILD_NUMBER} .
docker push registry.local/app:${BUILD_NUMBER}

Résultat après un mois : zéro déploiement cassé, temps de feedback réduit de 2 jours à 8 minutes, et les devs commitent plus souvent parce qu’ils ont confiance dans le filet de sécurité.

🔥 Cas réel : Ce pattern “webhook + build + push image” couvre 80% des besoins CI/CD. C’est le cas d’usage fondamental de Jenkins.

Pièges fréquents

Laisser les executors actifs sur le controller. C’est le piège n°1 : Jenkins propose par défaut 2 executors sur le controller. En prod, mets-les à zéro immédiatement via Manage Jenkins → Nodes → Built-In Node.

Oublier les backups. Tout Jenkins vit dans $JENKINS_HOME. Si tu perds ce répertoire, tu perds tout : jobs, credentials, historique. Un cron basique suffit pour commencer :

0 2 * * * tar czf /backup/jenkins-$(date +\%F).tar.gz /var/lib/jenkins/

Stocker des mots de passe dans les scripts. Utilise toujours le système de Credentials intégré : Manage Jenkins → Credentials. Jenkins chiffre les secrets et les injecte dans les builds sans les afficher dans les logs.

Ne pas mettre de reverse proxy. Jenkins écoute en HTTP sur 8080. En production, mets Nginx ou Caddy devant avec du TLS. C’est non négociable.

⚠️ Attention : Le fichier initialAdminPassword reste sur le disque après l’installation. Il n’est plus utile une fois le compte admin créé — vérifie que l’accès anonyme est bien désactivé dans les paramètres de sécurité.

Exercice et points clés

Exercice : Installe Jenkins avec Docker, crée un job Freestyle sys-info qui affiche la date, le hostname, l’espace disque (df -h) et la mémoire (free -m). Configure un trigger Build periodically avec H * * * * (toutes les heures). Vérifie la Console Output après le premier build.

Pour aller plus loin, convertis ce job en Pipeline avec un Jenkinsfile :

pipeline {
    agent any
    stages {
        stage('Info') {
            steps {
                sh 'echo "Build #${BUILD_NUMBER} sur ${NODE_NAME}"'
                sh 'df -h && free -m'
            }
        }
    }
}

🧠 À retenir :

• Jenkins = orchestrateur CI/CD open source, architecture controller/agent
• Le controller planifie, les agents exécutent — ne mixe jamais les deux rôles
• $JENKINS_HOME contient tout : c’est la seule chose à sauvegarder
• Les variables d’environnement (BUILD_NUMBER, WORKSPACE, NODE_NAME…) sont injectées automatiquement
• Sécurité dès le jour 1 : credentials chiffrés, reverse proxy TLS, pas d’accès anonyme

Dans le prochain cours, on attaque les pipelines as code avec le Jenkinsfile — là où Jenkins déploie toute sa puissance.