Conception d’un pipeline CI/CD : GitLab, SonarQube et Docker

- 4 mins read

Lors de mon BUT Réseaux et Télécommunications, j’ai réalisé un projet dont l’objectif était de concevoir un environnement de développement proche de ce que l’on peut retrouver en entreprise. Ce projet m’a permis de découvrir et de mettre en œuvre une chaîne CI/CD, basée sur GitLab, intégrant l’audit automatique du code et le déploiement continu d’une application conteneurisée.

Infrastructure système réalisée

Ce projet a été réalisé sur une unique VM Debian (contrainte imposée par le projet), sur laquelle j’ai déployé l’infrastructure suivante :

  • GitLab : système de versionnement de code et orchestrateur des pipelines CI/CD
  • SonarQube : audit automatique du code (partie CI)
  • Docker : déploiement applicatif via conteneurs (partie CD)
  • Nginx : reverse proxy HTTPS (ajout personnel pour se rapprocher d’un contexte réel)
  • Postfix (relay SMTP) : envoi des emails GitLab (réinitialisation de mot de passe)

Mise en place de la pipeline

Dans ce projet, la nouveauté pour moi était la mise en place d’un pipeline CI/CD que je n’avais jamais expérimenté.

Principe de fonctionnement d’un pipeline CI/CD

Un pipeline CI/CD est déclenché à chaque commit d’un projet sur GitLab. Ce pipeline est mis en place par les 2 éléments suivants :

  • Un GitLab runner : cet outil permet de lancer la pipeline après un commit
  • Un fichier .gitlab-ci.yml : ce fichier est placé dans le dépôt en question et décrit ce qui sera fait pendant le pipeline. Le pipeline créé permet donc d’auditer le code du dépôt et si ce dernier donnait un audit conforme, une image Docker était build puis le code était déployé dans un conteneur. La version finale de mon pipeline réalisé lors du projet dans le fichier .gitlab-ci.yml ressemblait à ça :
# ordre d'execution des jobs
stages:
  - sonarqube
  - build
  - run
    
# Job permettant l'analyse du code par sonarqube
sonarqube-check:
  stage: sonarqube
  tags:
    - SAE502_script
  variables:
    SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar" 
    GIT_DEPTH: "0" 
  cache:
    key: "${CI_JOB_NAME}"
    paths:
      - .sonar/cache
  script: 
    - sonar-scanner
    
# job permettant de build l'image docker
docker-build:
  stage: build
  script:
    - docker build -t python-socket-server .
  tags:
    - docker
      
# job permettant le run du conteneur docker
docker-run:
  stage: run
  script:
    - docker stop python-socket-server || true
    - docker rm python-socket-server || true
    - docker run -d --name python-socket-server -p 5555:5555 python-socket-server
  tags:
    - docker

Visualisation de la pipeline sur gitlab :

Audit de code par sonarqube

La configuration du pipeline concernant Sonarqube correspond à ce bloc dans le fichier .gitlab-ci.yml :

sonarqube-check:
  stage: sonarqube
  tags:
    - SAE502_script
  variables:
    SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar" 
    GIT_DEPTH: "0" 
  cache:
    key: "${CI_JOB_NAME}"
    paths:
      - .sonar/cache
  script: 
    - sonar-scanner

Lors du déclenchement du pipeline, Sonarqube fait un audit et donne un résultat sur son interface web comme ci : Sur ce rapport, on voit que le code ne passe pas le test car pendant l’audit, il a été considéré comme contenant des problèmes de sécurité.

Sonarqube est un outil puissant, il m’a permis de prendre conscience de l’importance de l’audit de code automatisé et des bonnes pratiques de sécurité, notamment sur la gestion des secrets et des erreurs applicatives.

Build d’image et deploiement avec Docker

La configuration du pipeline concernant Docker correspond à ce bloc dans le fichier .gitlab-ci.yml :

docker-build:
  stage: build
  script:
    - docker build -t python-socket-server .
  tags:
    - docker
      
docker-run:
  stage: run
  script:
    - docker stop python-socket-server || true
    - docker rm python-socket-server || true
    - docker run -d --name python-socket-server -p 5555:5555 python-socket-server
  tags:
    - docker

Après qu’un code a passé le test d’audit de Sonarqube, une image est build à partir d’un Dockerfile contenu dans le dépôt sur GitLab. Si le build se passe bien, un déploiement par conteneur est effectué en veillant à ce que l’ancien conteneur soit stoppé et supprimé afin que le nouveau prenne sa place.

Compétences acquises

Ce projet m’a permis de consolider et de développer des compétences techniques directement applicables en environnement professionnel, notamment :

Compétences consolidées

  • Mise en place et administration d’une infrastructure Linux sur machine virtuelle.
  • Utilisation d’un système de gestion de versions avec GitLab.
  • Déploiement et exploitation de services via des conteneurs Docker

Nouvelles compétences acquises

  • Conception et orchestration d’un pipeline CI/CD avec GitLab Runner.
  • Automatisation de l’audit de code à chaque commit.
  • Intégration de SonarQube pour l’analyse de la qualité et de la sécurité du code.
  • Automatisation du build et du déploiement continu d’une application conteneurisée.