GitLab: CI/CD

Comment utiliser GitLab CI/CD

👋 Bienvenue dans la documentation Stackhero !

Stackhero offre une solution GitLab cloud clé en main, pensée pour les équipes qui ont besoin d’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é maximale.

Mises à jour faciles en un seul clic, pour garder votre environnement à jour sans interruption.

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

Performance constante et sécurité renforcée sur votre propre infrastructure privée et dédiée. Aucun voisin bruyant, isolation complète assurée.

Choix de l’emplacement d’hébergement : 🇪🇺 Europe ou 🇺🇸 USA selon vos exigences de conformité ou de latence.

Démarrez rapidement et concentrez-vous sur votre code. La solution GitLab cloud hosting de Stackhero est prête à l’emploi en environ 5 minutes.

Introduction

GitLab CI/CD est une fonctionnalité puissante et intégrée à GitLab, une plateforme open source largement utilisée pour le contrôle de version et la collaboration. Cet outil vous permet de rationaliser et d'automatiser les étapes essentielles de la construction, des tests et du déploiement de vos logiciels, assurant ainsi une livraison plus rapide et plus fiable d'applications de haute qualité.

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

L'un des principaux avantages de GitLab CI/CD est son intégration étroite au sein même de GitLab. Cela vous permet de définir et de 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 de programmation, de frameworks et d'outils, ce qui le rend suffisamment polyvalent pour convenir à 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 prend en charge 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 nécessaire, 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) dans votre tableau de bord Stackhero.

Activer le support DinD présente un risque de sécurité, surtout si vous souhaitez isoler vos utilisateurs et éviter qu'ils puissent accéder 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 désiré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é, ce qui masque 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 démarre des services réels (bases de données, message brokers, etc.) sous forme de conteneurs Docker temporaires pendant l'exécution des tests, la configuration ci-dessus est déjà adaptée. Gardez 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, donc 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.