HeavyCookie's Kitchen đŸȘ

Utiliser docker-compose avec GitLab CI dans un runner Docker

June 25, 2018 ‱ Tags : GitLab 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 !


  1. Utiliser --no-cache a l’air mieux que --update d’aprùs @Floweb & la doc de Alpine

    ↩

Thibault Lacroux

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

Blog comments powered by Disqus.