Utiliser docker-compose avec GitLab CI dans un runner Docker

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 a pas de Kubernetes derrière pour l’instant.
• On utilise Docker Compose dans un seul dépot 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 runner qui sont des daemons a installer sur les machines exécutant les process d’intégration continue.

Je vous laissez 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é les commandes fournies au gitlab-runner.
Perso, j’ai choisi le type docker basé sur l’image docker:latest un peu custom 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 builds 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 ^update

# 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 projet 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 ai 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 !

Écrit par Thibault Lacroux, développeur freelance Ruby on Rails, React, Elixir & co. Vous devriez le suivre sur Twitter