Laty Gueye Samba: Déployer des applications Spring Boot et Angular en continu avec GitLab CI/CD et Docker

```html

Déployer des applications Spring Boot et Angular en continu avec GitLab CI/CD et Docker

La mise en production d’une application Spring Boot couplée à un front Angular devient robuste lorsqu’elle est automatisée via GitLab CI/CD et Docker. Cette approche permet de fiabiliser les déploiements, de réduire le temps de correction et d’unifier le cycle de vie applicatif.

Architecture cible

Le modèle recommandé sépare clairement les responsabilités :

Backend : application Spring Boot packagée en image Docker.
Frontend : application Angular buildée en fichiers statiques, servis via un conteneur (ex. Nginx).
Réseau et configuration : variables d’environnement, URLs et secrets gérés par GitLab.

Pré-requis

La démarche suppose l’existence :

D’un dépôt Git avec un dossier backend et un dossier frontend.
D’images Docker publiées (GitLab Container Registry ou autre registre).
D’un environnement de déploiement accessible (VM, cluster, ou Docker Engine distant).

Docker pour le backend Spring Boot

L’objectif est de construire une image reproductible et légère. Un multi-stage build améliore le temps de build et réduit la taille finale.

Exemple Dockerfile (backend)

Docker pour le frontend Angular

Angular doit être compilé une fois au build, puis servir les fichiers statiques via un serveur HTTP (souvent Nginx).

Exemple Dockerfile (frontend)

Gestion de la configuration

La configuration doit être externalisée. Le backend Spring Boot consomme généralement des variables d’environnement. Le frontend Angular peut aussi être paramétré via :

des variables injectées au build (moins flexible),
ou un modèle basé sur un fichier runtime (ex. config.js) servi par Nginx.

Exemple variables backend

Pipeline GitLab CI/CD : principes

Le pipeline peut être découpé en étapes logiques :

Build : compilation backend/frontend, puis construction d’images Docker.
Test : exécution des tests unitaires et/ou intégration (optionnel mais recommandé).
Push : publication des images sur GitLab Container Registry.
Deploy : mise à jour automatique sur la cible (VM/serveur/cluster).

Exemple `.gitlab-ci.yml` (build + deploy)

L’exemple ci-dessous illustre une approche typique avec build, push, puis déploiement via SSH. Le déploiement peut être ajusté en fonction de l’infrastructure (Docker Compose, scripts, Kubernetes, etc.).


     ~/.ssh/id_rsa
    - chmod 600 ~/.ssh/id_rsa
    - ssh-keyscan -H "$DEPLOY_HOST" >> ~/.ssh/known_hosts
  script:
    - |
      ssh "$DEPLOY_USER@$DEPLOY_HOST" bash -lc "'
      export IMAGE_BACKEND=$IMAGE_BACKEND
      export IMAGE_FRONTEND=$IMAGE_FRONTEND
      export TAG=$CI_COMMIT_SHA

      docker login -u \"$CI_REGISTRY_USER\" -p \"$CI_REGISTRY_PASSWORD\" $CI_REGISTRY || true

      # Exemple avec Docker Compose (à adapter)
      # Le serveur doit contenir un docker-compose.yml qui référence les variables.
      docker compose pull backend frontend || true
      docker compose up -d --remove-orphans
      '"
  only:
    - main
    ]]>

Note : l’exemple suppose l’existence d’un docker-compose.yml côté serveur. Une variante consiste à utiliser le digest ou des tags stables (ex. staging, latest).

docker-compose côté serveur

Un déploiement par Docker Compose simplifie la mise à jour et la gestion de services.

Exemple docker-compose.yml (serveur)

Déploiement progressif et rollback

Pour renforcer la résilience, le pipeline peut intégrer :

Tags versionnés (sha, semver) et conservations d’historiques.
Rollback : relancer l’ancien tag en cas d’échec.
Déploiement progressif : staging avant production.

Bonnes pratiques de sécurité

Secrets uniquement via Variables GitLab protégées (ex. DEPLOY_SSH_KEY, DB_PASSWORD).
Accès minimal : compte SSH dédié, permissions restreintes.
Scan d’images : vérifier les vulnérabilités (optionnel selon tooling).
Images immuables : déployer un artefact précis (tag sha) plutôt que latest en production.

Optimisations de performance

Pour réduire le temps CI/CD :

Utiliser un cache Maven et Node (ou des volumes dans le runner).
Activer des build multi-stage (déjà utilisé dans les exemples).
Limiter les triggers (déployer seulement sur main ou sur tags).

Exigences de qualité (tests)

Les tests doivent être intégrés tôt dans le pipeline. Le backend peut exécuter JUnit et des tests d’intégration, tandis que le frontend exécute des tests unitaires (Jest/Karma selon configuration).

Exemple ajout stage de tests (idée)

Conclusion

En combinant Docker (builds reproductibles) et GitLab CI/CD (automatisation du cycle de vie), la mise en production de Spring Boot et Angular devient continue, traçable et plus simple à faire évoluer. La séparation backend/frontend, l’externalisation de la configuration et la gestion de versions d’images renforcent la fiabilité globale.

Prochaine étape : adapter les scripts de déploiement à l’infrastructure (VM, Docker Compose, ou Kubernetes) et ajouter des tests et un contrôle qualité plus stricts.

Déployer des applications Spring Boot et Angular en continu avec GitLab CI/CD et Docker

Déployer des applications Spring Boot et Angular en continu avec GitLab CI/CD et Docker

Architecture cible

Pré-requis

Docker pour le backend Spring Boot

Exemple Dockerfile (backend)

Docker pour le frontend Angular

Exemple Dockerfile (frontend)

Gestion de la configuration

Exemple variables backend

Pipeline GitLab CI/CD : principes

Exemple .gitlab-ci.yml (build + deploy)

docker-compose côté serveur

Exemple docker-compose.yml (serveur)

Déploiement progressif et rollback

Bonnes pratiques de sécurité

Optimisations de performance

Exigences de qualité (tests)

Exemple ajout stage de tests (idée)

Conclusion

À propos de l'auteur

Exemple `.gitlab-ci.yml` (build + deploy)