GitLab: CI/CD

Comment utiliser GitLab CI/CD

👋 Bienvenue sur la documentation de Stackhero !

Stackhero propose une solution GitLab cloud prête à l'emploi, conçue pour les équipes qui recherchent un environnement rapide, sécurisé et évolutif :

Utilisateurs, dépôts, transferts de données et temps de traitement CI/CD illimités pour une flexibilité totale.

Mises à jour simplifiées en un clic, pour garder votre environnement à jour sans interruption de service.

Nom de domaine personnalisé sécurisé en HTTPS (par exemple, https://git.votre-entreprise.com) pour une image professionnelle et une sécurité renforcée.

Performance constante et sécurité renforcée sur votre propre infrastructure privée et dédiée. Aucun voisin bruyant, isolation totale garantie.

Choix du lieu d'hébergement : 🇪🇺 Europe ou 🇺🇸 USA selon vos besoins de conformité ou de latence.

Lancez-vous rapidement et concentrez-vous sur votre code. La solution GitLab cloud hosting de Stackhero est opérationnelle en environ 5 minutes.

Introduction

GitLab CI/CD est une fonctionnalité puissante et intégrée de GitLab, une plateforme open source très répandue pour le contrôle de version et la collaboration. Cet outil vous permet d'automatiser et d'optimiser les étapes clés de la construction, des tests et du déploiement de vos applications, garantissant ainsi une livraison plus rapide et plus fiable de logiciels de qualité.

Par exemple, avec GitLab CI/CD, vous pouvez configurer des tests unitaires automatisés qui se déclenchent à chaque nouveau commit poussé sur un dépôt GitLab. Une fois ces tests validés, votre code peut être construit et déployé sur un environnement de staging pour des vérifications complémentaires. Après validation de tous les tests en staging, le système peut promouvoir le code en production, le rendant ainsi disponible aux utilisateurs finaux.

L'un des atouts majeurs de GitLab CI/CD est son intégration native dans GitLab. Vous pouvez ainsi définir et gérer vos pipelines CI/CD directement dans vos dépôts de projet, ce qui simplifie l'orchestration et le suivi de l'ensemble de votre workflow.

GitLab CI/CD prend en charge un large éventail de langages, frameworks et outils, ce qui le rend suffisamment polyvalent pour s'adapter à différents types de projets. Son système de pipelines personnalisables vous permet d'adapter chaque étape du processus CI/CD à vos besoins, que ce soit pour la construction, les tests ou le déploiement sur plusieurs environnements.

En résumé, GitLab CI/CD est une solution complète conçue pour automatiser et améliorer les processus de livraison logicielle. Il permet aux développeurs de se concentrer sur l'écriture et l'amélioration du code, tandis que la plateforme gère efficacement les tâches opérationnelles.

Comment construire des images Docker dans votre GitLab CI

Si votre dépôt de projet contient des fichiers Dockerfile, vous pouvez automatiser la construction, l'exécution et, si besoin, la publication de vos images Docker vers un registre.

Étape 1 : Activer le support Docker in Docker (DinD)

Pour commencer, activez le support "Docker in Docker" (DinD) depuis votre tableau de bord Stackhero.

L'activation du support DinD présente un risque de sécurité, en particulier si vous souhaitez isoler vos utilisateurs et éviter qu'ils accèdent aux projets des autres.

Étape 2 : Configurer le pipeline GitLab CI

Ensuite, modifiez votre fichier gitlab-ci.yml pour inclure une configuration de pipeline qui construit votre Dockerfile en utilisant DinD. Voici un exemple de configuration :

image: docker:29

build:
  stage: build
  services:
    - name: docker:29-dind
      alias: docker
  variables:
    # Oriente le CLI Docker vers le service Docker-in-Docker, via son port
    # non sécurisé (non-TLS). Voir la note ci-dessous sur l'importance de DOCKER_HOST.
    DOCKER_HOST: "tcp://docker:2375"
    DOCKER_TLS_CERTDIR: ""
  before_script:
    - docker info
  script:
    # Remplacez "my-docker-image" par le nom de l'image souhaitée :
    - docker build -t my-docker-image .
    # Optionnellement, testez l'image Docker :
    # - docker run my-docker-image /script/to/run/tests

Le service docker:29-dind démarre un démon Docker à côté de votre job, et DOCKER_HOST indique au CLI docker de l'utiliser. Définissez toujours DOCKER_HOST lorsque vous déclarez un service docker:dind : si vous l'omettez, le CLI se connecte silencieusement à un autre démon, et votre build peut réussir même si le service est mal configuré, masquant ainsi de vrais problèmes. DOCKER_TLS_CERTDIR: "" permet d'utiliser le port interne 2375 non sécurisé du réseau du job.

En alternative plus simple, vous pouvez supprimer complètement le bloc services et les deux variables : le runner Stackhero expose déjà un démon Docker prêt à l'emploi via un socket monté, donc une simple commande docker build fonctionne immédiatement.

Pour plus d'informations sur la construction d'images Docker avec GitLab CI, consultez la documentation officielle de GitLab.

Exécuter vos tests avec Testcontainers

Si votre suite de tests utilise Testcontainers, une bibliothèque qui lance des services réels (bases de données, message brokers, etc.) sous forme de conteneurs Docker éphémères pendant l'exécution des tests, la configuration ci-dessus est déjà adaptée. Conservez le service docker:29-dind et les deux variables : Testcontainers utilise DOCKER_HOST pour accéder au démon Docker et se connecter aux conteneurs qu'il démarre, aucune autre configuration n'est nécessaire.

Oublier de définir DOCKER_HOST est la cause la plus fréquente d'échecs de Testcontainers en CI. La bibliothèque utilise alors le socket Docker monté par le runner et ne parvient pas à accéder à ses propres conteneurs de test, ce qui se manifeste généralement par un timeout du conteneur helper Ryuk.