Le Container Registry GitLab pour le stockage de vos images Docker

Container Registry : Le Stockage de votre Logiciel

Le Registre de conteneurs est un système de stockage et de distribution intégré à GitLab qui permet de conserver vos images Docker. Contrairement au code source qui est du texte brut, une image Docker est une unité logicielle "prête à l'emploi" qui regroupe votre code, ses bibliothèques et ses dépendances pour garantir une exécution fiable sur n'importe quel serveur.

Pourquoi utiliser le Registre intégré de GitLab ?

Dans un cycle DevOps moderne, l'utilisation de conteneurs est la norme absolue. Utiliser le registre de GitLab plutôt qu'un service externe offre trois avantages majeurs :

• Sécurité Native : Vous n'avez pas besoin de créer des comptes supplémentaires. Les droits d'accès au registre sont strictement calqués sur les permissions de votre projet GitLab.
• Traçabilité Totale : Chaque image est liée au commit exact qui l'a générée. Vous savez précisément quelle version du code tourne sur votre serveur.
• Automatisation Transparente : GitLab fournit des identifiants temporaires sécurisés à vos pipelines pour qu'ils puissent pousser les images sans intervention humaine.

Construire et Pousser (Le Pipeline Build)

Le but est de transformer votre code en image Docker et de l'envoyer dans le coffre-fort de GitLab. Pour cela, on utilise des variables d'environnement prédéfinies que GitLab injecte automatiquement dans vos pipelines.

Exemple de pipeline (.gitlab-ci.yml) :

build_app:
  stage: build
  image: docker:latest
  services:
    - docker:dind # Docker-in-Docker pour permettre la construction
  script:
    # 1. Connexion au registre GitLab avec des identifiants temporaires
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    
    # 2. Construction de l'image avec un nom dynamique (Tag)
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG .
    
    # 3. Envoi de l'image vers le registre GitLab
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG

Détail des variables utilisées :

• $CI_REGISTRY_IMAGE : L'URL unique de stockage de votre projet.
• $CI_COMMIT_REF_SLUG : Le nom de votre branche, ce qui permet de versionner vos images.
• $CI_REGISTRY_USER / PASSWORD : Identifiants créés dynamiquement pour ce job précis.

Récupérer et Déployer (Le Pipeline Deploy)

Une fois l'image stockée dans le registre, elle est "gelée". Pour la déployer sur votre serveur ou votre cluster Kubernetes, vous devez effectuer un Pull de l'image.

Via Docker (Serveur simple)

Si vous déployez sur un serveur classique, vous devez d'abord vous connecter pour que Docker ait le droit de lire le registre privé de GitLab :

docker login registry.gitlab.com -u mon_user -p mon_access_token
docker pull registry.gitlab.com/mon-groupe/mon-projet:main

Via Kubernetes (Avec l'Agent GitLab)

C'est ici que tout se rejoint. Votre agent Kubernetes utilise son tunnel sécurisé pour récupérer l'image directement sans que vous n'ayez à gérer de mots de passe sur le serveur.

# Extrait d'un fichier de déploiement Kubernetes
spec:
  containers:
  - name: mon-app
    image: registry.gitlab.com/mon-groupe/mon-projet:main # On pointe vers le registre

4. Gérer le cycle de vie des images

Le stockage occupe de l'espace disque. GitLab permet de gérer le nettoyage automatique des images via l'interface :

• Naviguez vers Settings > Container Registry.
• Utilisez les Cleanup Policies pour automatiser la suppression des anciens tags.
• Enable cleanup policy : Active la suppression automatique des tags d'images.
• Keep the most recent : Nombre de tags à conserver impérativement pour garder un historique minimal.
• Keep tags matching : Expression régulière pour les tags qui ne doivent jamais être supprimés (ex: main, latest).
• Remove tags older than : Seuil d'ancienneté à partir duquel un tag devient éligible à la suppression.

"Gestion des politiques de nettoyage du Registre de Conteneurs"

Conclusion

Le Container Registry est le point final de votre chaîne de production automatisée. C'est ici que sont conservées les versions prêtes à l'emploi de votre logiciel. En centralisant vos images au même endroit que votre code, vous sécurisez votre distribution et simplifiez radicalement vos pipelines de déploiement.

Vous maîtrisez désormais le cycle complet : coder, tester via la CI, construire l'image dans le Registry et déployer sur un serveur via la CD.