DevOps
TP3 : DÉPLOIEMENT
SOUS KUBERNETES
AVEC ET SANS HELM
ET CRÉATION DE
PIPELINES CI/CD
AVEC JENKINS
Réalisé par:
Riadh Ibrahim
Wejdene Chamroukhi RT5
Iheb Alimi
2025-2026
🎯 Objectifs du TP
Installer et configurer un cluster Kubernetes
local avec Minikube / Kind
Installer et comprendre l’utilisation de Helm
pour gérer les déploiements sur Kubernetes.
Créer un pipeline CI/CD avec Jenkins pour
déployer une application sur Kubernetes sans
Helm.
Créer un pipeline CI/CD avec Jenkins pour
déployer une application sur Kubernetes en
utilisant Helm.
[Link] k8s cluster avec minikube
Un outil open-source qui permet
d’exécuter un cluster Kubernetes
mono-nœud directement sur une
machine locale. Il est idéal pour le
développement, les tests et
l’apprentissage de Kubernetes sans
avoir besoin d’un cluster distant
the Minikube cluster will be the
core component, which is
responsible for running the
Kubernetes cluster. The cluster is
built on top of the Docker engine
we have installed, which is
responsible for creating and
managing containers. The
kubectl utility will be used to
interact with the Kubernetes
cluster and perform actions like
deploying, scaling, and managing
applications
Minikube Dashboard
Cette commande ouvre une interface web graphique du cluster
offrant une vue visuelle en temps rée
[Link] Helm
outil open-source qui simplifie le
déploiement d’applications sur
Kubernetes via des charts. Idéal
pour le dev, les tests et la prod, il
permet d’installer, mettre à jour et
versionner facilement des apps
complexes en une commande
le développeur utilise un client
Helm installé sur son poste, qui
possède les permissions
nécessaires (cluster-admin). Le
client Helm récupère les charts
depuis un dépôt de charts
configuré, puis se connecte à
l’API du cluster Kubernetes pour
y déployer ces charts
Helm gère les charts, qui contiennent des templates définissant les
ressources Kubernetes et des values fournissant les données de
configuration. Helm interagit aussi avec des repositories qui hébergent
les charts, et gère les releases, incluant leur versioning et leur cycle de
vie.
Création de l'application
1.1 Développement d’une app web avec Spring Boot
C’est une simple app accessible sur le port 8081, car le port 8080 est déjà
réservé et utilisé par Jenkins sur l’environnement d’exécution
Création de l'application
1.2 Configuration avec Maven ([Link])
Création de l'application
1.3 Ajout du Dockerfile pour la construction
du container
Ce Dockerfile :
1. Utilise une image de base légère Java 17 : eclipse-temurin:17-jre-alpine
2. Définit une variable contenant le nom du fichier JAR généré : ARG
JAR_FILE=target/[Link]
3. Copie le JAR du dossier target vers l’image Docker sous le nom [Link]
4. Lance l’application avec la commande java -jar /[Link] lorsque le
container démarre
[Link] CI/CD Jenkins pour déployer sur
Kubernetes sans Helm.
Versionnage du projet dans un GitHub Repo
Dans la branche main, l’application est déployée sur Minikube sans
Helm, en utilisant uniquement des fichiers YAML
(k8s/[Link] et k8s/[Link]).
LINK
Implémentation du pipeline
Stages métier du pipeline
Build & Test with Maven : compile le
projet Java et exécute les tests
automatisés.
Build Docker Image : construit
l’image Docker de l’application et
crée la version latest.
Push Docker Image : envoie l’image
Docker (versionné + latest) vers
Docker Hub.
Deploy to Kubernetes : applique les
fichiers YAML sur le cluster
Kubernetes et vérifie le
déploiement.
Implémentation du pipeline
Gestion des retours et notifications
Le bloc post définit les actions à effectuer après l'exécution des
stages.
En cas de succès, un message indiquant la réussite complète
du pipeline est affiché.
En cas d'échec, un message d'erreur est généré pour signaler la
défaillance du pipeline.
Implémentation du pipeline
Jenkins CI/CD Pipeline for Java Application
Ce pipeline automatise le déploiement d'une application Spring Boot depuis GitHub
vers Kubernetes.
Jenkins détecte les changements sur la branche main via polling, puis exécute quatre
étapes : compilation et tests avec Maven, construction d'une image Docker, push de
l'image vers Docker Hub, et déploiement sur Kubernetes Minikube en appliquant
directement les fichiers [Link] et [Link] avec kubectl.
Cette approche utilise des commandes kubectl basiques pour déployer 2 replicas de
l'application exposée via un service LoadBalancer, sans gestion de versioning ni
packaging des ressources Kubernetes.
Résultats & Vérification
Le pipeline Jenkins s’est exécuté sans erreur : l’image Docker a été
construite et poussée sur Docker Hub, puis le déploiement a été
appliqué avec succès sur Minikube.
Résultats & Vérification
Les ressources Kubernetes sont créées : 2 pods en état Running, un
ReplicaSet actif, et le Service de type LoadBalancer accessible via
minikube service. L’application est opérationnelle.
[Link] CI/CD Jenkins pour déployer sur
Kubernetes avec Helm.
Versionnage du projet dans un GitHub Repo
Dans la branche helm, l’application est déployée sur Minikube avec
Helm, en utilisant un chart personnalisé . Cette méthode garantit un
déploiement paramétrable, versionné et facilement réversible grâce à
la gestion des releases Helm.
LINK
Implémentation du pipeline
Configuration d’un second pipeline Jenkins dédié à la
branche helm, déclenché automatiquement à chaque
push sur cette branche pour exécuter le déploiement via
Helm
Implémentation du pipeline
Stages métier du pipeline
On a presque les mêmes stages mais il y a des modifications sur le
stage 4 : Deploy with Helm
On Utilise les credentials kubeconfig pour se connecter au cluster
Kubernetes, puis exécute helm upgrade --install demo-app
./demo-app-chart --set [Link]=latest qui installe le chart Helm
ou met à jour le déploiement existant avec la nouvelle image.
Helm gère automatiquement tous les objets Kubernetes
(deployment, service, etc.) en une seule commande.
Fichiers Helm modifiés
[Link] : Fichier de métadonnées du chart Helm. Contient le
nom (demo-app-chart), la description, le type (application), la
version du chart (0.1.0) et la version de l'application déployée (0.0.1).
[Link] : Fichier de configuration principal. Définit les valeurs
par défaut pour le déploiement : 2 replicas, l'image Docker
(alimiheb/demo-app:latest), le type de service (LoadBalancer), les
ports (80 externe vers 8081 interne), et la politique de pull d'image
(Always pour toujours récupérer la dernière version). C'est le fichier
que vous modifiez pour adapter l'application sans toucher aux
templates.
[Link] : Template Kubernetes pour créer le
déploiement. Utilise les valeurs de [Link] avec la syntaxe {{
.[Link] }} pour générer dynamiquement le nombre de replicas,
l'image, et le port du conteneur. Modifié pour utiliser targetPort
(8081) au lieu du port du service.
[Link] : Template pour exposer l'application. Génère
automatiquement un service avec le type et les ports définis dans
[Link]. Utilise les labels Helm pour lier le service aux pods du
déploiement.
Implémentation du pipeline
Jenkins CI/CD Pipeline for Java Application
Le pipeline suit exactement le même flux que le premier (branche
main) pour les trois premières étapes :
Jenkins détecte les changements sur la branche helm via polling,
compile l'application avec Maven, construit et pousse l'image
Docker vers Docker Hub.
La seule différence majeure réside dans la dernière étape de
déploiement : au lieu d'utiliser kubectl apply sur des fichiers YAML
individuels, le pipeline exécute la commande helm upgrade --
install demo-app ./demo-app-chart qui déploie l'application en
utilisant le chart Helm.
Cette approche apporte une gestion packagée des ressources
Kubernetes avec templating, versioning automatique des releases,
et capacité de rollback simple, tout en conservant la même
architecture de 2 replicas exposés via LoadBalancer.
Résultats & Vérification
Le pipeline Jenkins s’est exécuté sans erreur : l’image Docker a été
construite et poussée sur Docker Hub, puis le déploiement a été
appliqué avec succès sur Minikube.
Résultats & Vérification
Les ressources Kubernetes sont créées et gérées par Helm : 2 pods
en état Running, un ReplicaSet actif, et le Service de type
LoadBalancer accessible via minikube service. Helm suit la release
demo-app avec versioning automatique, permettant des rollbacks
faciles et une gestion unifiée de tous les objets déployés.
L'application est opérationnelle.
Résultats & Vérification
Conclusion
kubectl offre un contrôle granulaire mais manuel, tandis
que Helm apporte l'automatisation, le versioning et la
gestion du cycle de vie complet des applications
Kubernetes.
Helm ajoute une couche d'abstraction qui simplifie les
opérations complexes au prix d'une légère complexité
initiale dans la création du chart.
Pour ce TP, les deux approches déploient la même
architecture (2 replicas, LoadBalancer), mais Helm offre
une meilleure maintenabilité et évolutivité à long terme.