Exercice 08 : Projet Capstone - Pipeline GitLab CI avec Container Registry et Environnements

🎯 Objectifs

À la fin de cet exercice, vous serez capable de :

• ✅ Pousser des images Docker vers le GitLab Container Registry intégré
• ✅ Configurer des environnements staging et production dans GitLab CI
• ✅ Utiliser des variables protégées et masquées pour les secrets
• ✅ Optimiser le pipeline avec needs: et un cache efficace
• ✅ Inclure des templates externes avec include:

Durée estimée : 1h

Difficulté : ⭐⭐⭐⭐⭐ (Expert)

Prérequis :

• Exercices 06 et 07 GitLab CI complétés
• Module GitLab CI Avancé complété

📖 Contexte

Votre pipeline CI est optimisé. Il est temps de le connecter à un registry d'images et d'orchestrer des déploiements vers des environnements réels. Vous allez utiliser le Container Registry intégré à GitLab, configurer des environnements avec des URLs de déploiement, et sécuriser les secrets avec les variables protégées.

📋 Énoncé

Créez un pipeline de bout en bout : build, push vers GitLab Container Registry, déploiement staging automatique, déploiement production manuel avec environnements configurés.

🧭 Déroulement de l'exercice

Tâche 1 : Configurer les variables protégées

Dans GitLab → Settings → CI/CD → Variables, créez les variables suivantes :

• STAGING_SERVER (masked, protected sur main) : staging.example.com
• PROD_SERVER (masked, protected sur main) : prod.example.com
• DEPLOY_TOKEN (masked) : token-fake-12345

Indice : Les variables "Protected" ne sont injectées que dans les jobs qui s'exécutent sur des branches protégées (ex. main). Les variables "Masked" sont cachées dans les logs. Ces deux options sont cumulables.

Vérification : Dans Settings → CI/CD → Variables, les 3 variables sont listées avec les icônes de cadenas appropriées.

Tâche 2 : S'authentifier et pousser vers le Container Registry

Dans le job build-and-push, utilisez les variables prédéfinies $CI_REGISTRY, $CI_REGISTRY_USER, $CI_REGISTRY_PASSWORD pour vous connecter au Container Registry de GitLab, construire l'image et la pousser.

Indice :

`yaml

script:

- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY

- docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA .

- docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA

- docker tag $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA $CI_REGISTRY_IMAGE:latest

- docker push $CI_REGISTRY_IMAGE:latest

`

$CI_REGISTRY_IMAGE est l'URL complète du registry pour votre projet (ex : registry.gitlab.com/username/project).

Vérification : Dans GitLab → Packages & Registries → Container Registry, l'image apparaît avec le tag du commit SHA et latest.

Tâche 3 : Configurer le déploiement staging

Créez un job deploy-staging qui :

• Référence l'environnement staging avec une URL dynamique
• S'exécute automatiquement sur main
• Affiche l'image qui serait déployée et le serveur cible
• Crée un déploiement GitLab (visible dans Deployments)

Indice :

`yaml

deploy-staging:

environment:

name: staging

url: https://$CI_ENVIRONMENT_SLUG.example.com

rules:

- if: '$CI_COMMIT_BRANCH == "main"'

`

$CI_ENVIRONMENT_SLUG est le nom de l'environnement normalisé (lowercase, sans espaces).

Vérification : Après un push sur main, un déploiement apparaît dans GitLab → Deployments → Environments → staging.

Tâche 4 : Configurer le déploiement production manuel

Créez un job deploy-production qui s'exécute uniquement manuellement (when: manual) sur main, après deploy-staging. Il référence l'environnement production.

Indice : when: manual crée un bouton "Play" dans l'interface GitLab. Le job ne démarre que lorsqu'un utilisateur clique dessus. Cela simule une approbation manuelle avant la production.

Vérification : Le pipeline affiche le job deploy-production avec une icône "play" (triangle). Il ne s'exécute pas automatiquement.

Tâche 5 : Inclure un template SAST

Utilisez include: pour inclure le template de scan de sécurité SAST (Static Application Security Testing) fourni par GitLab. Ce template ajoute automatiquement des jobs de sécurité.

Indice :

`yaml

include:

- template: Security/SAST.gitlab-ci.yml

`

GitLab fournit des dizaines de templates prêts à l'emploi. Ce template ajoute des jobs de scan dans votre pipeline sans aucune configuration supplémentaire.

Vérification : Le pipeline inclut des jobs semgrep ou équivalent. L'onglet Security dans la MR affiche des résultats de scan.

Tâche 6 : Ajouter un job de nettoyage du registry

Créez un job cleanup-registry (stage final, when: manual) qui supprime les images du registry dont le tag n'est pas latest et qui ont plus de 7 jours. Simulez la commande (l'API GitLab Container Registry peut être appelée via curl).

Indice : GitLab expose une API REST pour gérer le registry : GET /projects/:id/registry/repositories. Pour la simulation : echo "Nettoyage des images anciennes...". En production, on utilise l'API GitLab avec le token de project access.

Vérification : Le job cleanup-registry apparaît avec une icône "play". Ses logs affichent la simulation de nettoyage.

🗂️ Mini-Projet : Pipeline de déploiement complet

Graphe du pipeline :

[test] ──→ [build-and-push] ──→ [deploy-staging (auto)] ──→ [deploy-production ▶ manuel]
                                                                        ↓
                                                          [cleanup-registry ▶ manuel]

Checkpoints de validation :

• L'image Docker est visible dans GitLab Container Registry avec les tags SHA et latest
• Les variables masquées ne sont pas affichées dans les logs
• L'environnement staging apparaît dans GitLab → Environments avec une URL
• deploy-production a une icône "play" (manuel)
• Le template SAST est inclus et des jobs de sécurité apparaissent
• cleanup-registry est un job manuel en fin de pipeline