Chez HeavyCookie, on utilise GitLab pour son côté tout-en-un, et plus particulièrement pour les aspects CI/CD.

L'architecture de nos projets ne nous permet pas pour l'instant d'utiliser la fonctionnalité Auto-DevOps puisque :

• On n'a pas de Kubernetes derrière Gitlab pour l'instant.
• On utilise Docker Compose dans un seul dépôt Git contenant nos projets backend sous Rails et nos frontend Node/Webpack.

Le problème, c'est que l'image de base docker n'a pas l'exécutable docker-compose.

Création de l'image Docker custom

La partie CI de GitLab fonctionne à l'aide de runners qui sont des daemons a installer sur les machines exécutant les process d'intégration continue.

Je vous laisse voir la doc sur l'installation d'un runner qui est assez explicite. J'ai choisi l'installation via le package Debian.

Le choix un peu tricky se situe sur l'executor qui définit la façon dont vont être gérés les commandes fournies au gitlab-runner.
Perso, j'ai choisi le type docker basé sur l'image docker:latest un peu modifié pour me permettre d'avoir déjà docker-compose dans mon image et une instance de docker séparée de celle qui tourne sur mon serveur.

Le container devra être lancé avec des privilèges alors attention aux petits malins, surtout si vos process de build peuvent déclencher du code ne venant pas seulement de personnes de confiance.

L'image est basé sur Alpine Linux, on reprend donc l'image docker:latest et on y ajoute docker-compose via apk ¹

# Dockerfile
FROM docker:latest
RUN apk add --no-cache python py-pip python-dev && pip install docker-compose

Pour builder le container sur GitLab-CI, un simple fichier .gitlab-ci.yml :

# .gitlab-ci.yml
image: docker:latest
services: ['docker:dind']
 
stages:
  - build
 
before_script:
  # Authenticate to GitLab Docker Registry before executing tasks
  - echo $CI_JOB_TOKEN | docker login -u gitlab-ci-token --password-stdin registry.heavycookie.co
 
build:docker:
  stage: build
  script:
    - docker build -t registry.example.com/ci/docker . # Building image from `Dockerfile`
    - docker push registry.example.com/ci/docker # Pushing builded image to registry

Utilisation / Configuration

Pour utiliser ce runner, deux solutions :

• soit vous précisez dans chaque .gitlab-ci.yml de vos projets l'image à utiliser et le service :

  # .gitlab-ci.yml.example
  image: registry.example.com/ci/docker
  services:
    - docker:dind
  # [...]

• Soit vous configurez votre runner de façon à ce qu'il utilise toujours la bonne image et le service associé en éditant son toml de configuration (/etc/gitlab-runner/config.toml). Voici un exemple de celui que l'on utilise :

  # [...]
  [[runners]]
    name = "Docker-in-docker"
    url = "https://gitlab.example.com/"
    token = "your-token"
    executor = "docker"
    environment = ["DOCKER_DRIVER=overlay2"]
    [runners.docker]
      privileged = true # Needed to run docker:dind
      image = "registry.example.com/ci/docker"
      services = ["docker:dind"]

  Les variables importantes dans cette configuration sont les 3 dernières privileged, image et services.

Dernière chose, attention aux droits de l'utilisateur qui déclenche le process de CI : il faut qu'il ait le droit d'accéder à l'image registry.example.com/ci/docker (donc ajoutez-le comme membre du dépot).

Et voilà, vous pouvez utiliser la commande docker-compose dans vos scripts .gitlab-ci.yml une fois pour toute !

*[CI]: Continuous Integration ou intégration continue *[CD]: Continuous Deployment ou déploiement continu