Automatiser Spring Boot + Docker avec GitLab CI (facile)

Les objectifs de ce TP de mise en pratique CI/CD sont les suivants :

• Compiler et packager l’appli Spring Boot (Maven ou Gradle)
• Construire l’image Docker
• Pousser l’image dans le GitLab Container Registry

Contexte du TP : Windows + Docker Desktop + WSL2 côté dev. Le pipeline GitLab s’exécute côté serveur (runner)

Par contre il faut remplir les conditions suivantes :

• Fichier dockerfile à la racine
• pom.xml (Maven) ou build.gradle (Gradle)
• Projet est hébergé sur GitLab

Si vous êtes habitué à GitLab, il vous faut activer le Container Registry (une fois).

Dans votre projet GitLab / Settings / Packages & Registries / Container Registry puis Enable.

Les variables d’authentification intégrées CI_REGISTRY_USER et CI_REGISTRY_PASSWORD seront disponibles automatiquement.

Premier Job build

Créez le fichier .gitlab-ci.yml à la racine du repo dont voici le code ci-dessous :

## Définit les étapes
stages:
  - build
  - image

# votre image de job : Maven + le JDK 17
image: maven:3.9.8-eclipse-temurin-17

variables:
  MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"

cache:
  key: maven-cache
  paths:
    - .m2/repository

build:maven:
  stage: build
  script:
    - mvn -B -DskipTests package
  artifacts:
    when: always
    paths:
      - target/*.jar
    expire_in: 1 week

Explications de ce que fait chaque ligne de ce script :

stages:
  - build
  - image

Rôle : Définit les étapes (stages) du pipeline CI/CD.

• build : Première étape, généralement dédiée à la compilation et aux tests.
• image : Deuxième étape, souvent utilisée pour construire une image Docker (bien que cette étape ne soit pas définie dans le reste du script).

Ordre : Les étapes s’exécutent séquentiellement, d’abord build puis image.

image: maven:3.9.8-eclipse-temurin-17

Rôle : Spécifie l’image Docker utilisée pour exécuter les jobs du pipeline.

• maven:3.9.8-eclipse-temurin-17 : Une image Docker officielle qui inclut Maven 3.9.8 et OpenJDK 17 (Temurin).

Tous les jobs du pipeline utiliseront cette image comme environnement d’exécution.

variables:
  MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"

Rôle : Définit des variables d’environnement pour notre pipeline.

• MAVEN_OPTS : Variable utilisée par Maven pour passer des options à la JVM.
• -Dmaven.repo.local=.m2/repository : Configure le dossier local du dépôt Maven (.m2/repository) pour stocker les dépendances téléchargées.

Cela permet de persister le cache Maven entre les exécutions du pipeline.

cache:
  key: maven-cache
  paths:
    - .m2/repository

Rôle : Configure le cache pour accélérer les builds futurs.

• key: maven-cache : Identifie le cache avec une clé (maven-cache).
• paths: - .m2/repository : Spécifie le dossier à mettre en cache (ici, notre dépôt Maven local).

Les dépendances Maven téléchargées seront sauvées en cache et réutilisées lors des prochains builds, ce qui réduit le temps d’exécution. Si vous ne le faites pas, ce n’est pas grave, mais c’est bien pratique de le faire.

build:maven:

Rôle : Définit un job nommé build:maven dans le pipeline.

Ce job appartient à l’étape build (définie plus haut dans stages).

  stage: build

Rôle : Associe le job build:maven à l’étape build. Le job s’exécutera pendant la phase build du pipeline.

  script:
    - mvn -B -DskipTests package

Rôle : Définit les commandes à exécuter pendant le job.

mvn -B -DskipTests package :

• mvn : Commande habituelle pour exécuter Maven.
• -B : C’est le mode batch (désactive les interactions utilisateur).
• -DskipTests : Vous l’avez deviné, il permet d’ignorer les tests pendant la compilation (pour gagner du temps).
• package : cela compile le projet et génère un fichier .jar dans le dossier target/

  artifacts:
    when: always
    paths:
      - target/*.jar
    expire_in: 1 week

Rôle : Définit les artifacts (fichiers générés) à sauvegarder après le job.

• when: always : Les artifacts sont toujours sauvegardés, même si le job échoue.
• paths: - target/*.jar : Il spécifie les fichiers à conserver (tous les .jar dans target/).
• expire_in: 1 week : Les artifacts seront supprimés après 1 semaine.

Résumé global du script

• Étapes du pipeline : build –> image.
• Environnement : Utilise une image Docker avec Maven et JDK 17.
• Variables : Configure le dépôt Maven local pour persister les dépendances.
• Cache : Sauvegarde le dossier .m2/repository pour accélérer les builds futurs.
• Job build:maven : Exécute mvn package (sans tests).
• Sauvegarde les fichiers .jar générés comme artifacts (valables 1 semaine).

On utilise ce type de script dans un pipeline CI/CD pour :

• Compiler notre projet Java/Maven (Spring Boot pour nous).
• Générer un artifact (fichier .jar) pour les étapes suivantes (déploiement).
• Optimiser les builds en utilisant un cache pour les dépendances Maven.

Remarques : L’utilisation de -DskipTests permet d’ignorer les tests avec skipTest. Ainsi, si vous voulez les exécuter, retirez cette option. Pour le Cache, il faut s’assurer que le chemin .m2/repository est correct pour le projet. L’utilisation de Artifacts permet de conserver le .jar pour être utilisés dans les étapes suivantes comme le déploiement.

Deuxième Job image (Docker-in-Docker, le plus simple pour commencer)

ça fonctionnera si votre runner autorise Docker-in-Docker ou dind (dans GitLab.com Shared Runners).

C’est le plus simple à comprendre au début !

Et à utiliser

image: docker:27

services:
  - name: docker:27-dind
    command: ["--tls=false"]

# Ces variables évitent le TLS pour simplifier notre démo.
variables:
  DOCKER_HOST: tcp://docker:2375
  DOCKER_TLS_CERTDIR: ""

build:image:
  stage: image
  needs: ["build:maven"]    # attend que le jar soit construit
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'   # ne build l’image que sur main
    - if: '$CI_COMMIT_TAG'                # ou sur un tag
  before_script:
    - echo "Login to GitLab Registry"
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"
  script:
    # Tags utiles : SHA et branche
    - export IMAGE="$CI_REGISTRY_IMAGE"
    - export TAG_SHA="$CI_COMMIT_SHORT_SHA"
    - export TAG_BRANCH="$CI_COMMIT_REF_SLUG"

    # Construire l’image (le Dockerfile copie déjà le jar depuis 'target/')
    - docker build -t "$IMAGE:$TAG_SHA" -t "$IMAGE:$TAG_BRANCH" -t "$IMAGE:latest" .

    # Faire un push des tags
    - docker push "$IMAGE:$TAG_SHA"
    - docker push "$IMAGE:$TAG_BRANCH"
    - docker push "$IMAGE:latest"

A chaque push sur le main (ou création de tag), le pipeline :

• Se loggue à votre Registry
• Il construit l’image à partir du Dockerfile
• Il push l’image avec 3 tags pratiques : :sha, :branche, :latest

Remarque : Il se peut que nous ayons quelques soucis sur Windows, pour le Runner Windows, préférez un runner Linux (Shell ou Docker executor). Les images maven/docker officielles sont Linux !

Documentation

Vous avez la documentation pour GitLab/CI qui est plutôt bien faite.