blog.bressure.net

On a réussi à mettre en place des constructions conteneurisées avec docker in docker dans l’article précédent. Le fait d’utiliser docker in docker permet de rendre la construction repétable puisque même l’outil de construction (ici docker) est sous forme se conteneur. On ne depend pas d’une installation préalable sur le système qui exécute la construction. Nous définissons dans le mécanisme de construction le systeme de construction lui-même.

L’autre avantage est d’isoler chaque construction. Ainsi on peut avoir plusieurs constructions d’un même projet en parallèle sans avoir a ce soucier d’un même port exposé sur l’hôte. Pas besoin d’avoit un port par construction: si cela reste possible par branche, 2 commit successifs sur une même branche vont utiliser le même port donc il faut séquencer les construction etc. Dind permet d’avoir l’esprit tranquille.

Déploiement continu

Dans mon environnement d’exécution, une application disons le blog de cerf-volant est distanciée une seule fois. Je pourrais être tenté de n’avoir qu’une application instanciée autant de fois qu’il y a de blog par exemple. Mais chaque blog wordpress est légèrement différents avec des plugins différents et cette personnalisation est souvent longue donc il est plus judicieux d’avoir un service déjà personnalisé avec des images déjà personnalisées. Finalement je préfère avoir autant d’application (docker-compose.yml) qu’autrefois j’avais de VM.

La conséquence est que le déploiement est plus simple. Un application ne se deploie qu’une fois donc son port exposé sur l’hôte (la VM de production) lui est dédié. Dans ce cas docker in docker ne sert plus à rien. On gagne à passer par le démon docker de l’hôte pour lancer les services.

C’est pourquoi selon l’étape (stage) de la construction j’utilise dind ou pas. J’identifie 4 étapes essentielles:

1. build
2. test
3. staging
4. production

Les 2 premiers doivent se faire en environnent isolé c’est-à-dire avec docker in docker tandis que le 3e consiste en un déploiement automatisé en environnement de preprod et le dernier est un déploiement manuel en production.

Outils de déploiement

Le deploiement consite à lancer un service docker sur la VM de prepod ou de prod. Est-ce que les outils déjà rencontré jusque jusque-là peuvent répondre à ce besoin ? docker CLI, docker-compose et gitlab-runner sont-ils suffisants ?

Le lancement du service consiste en:

1. rapatrier la définition du service sur le serveur de prod ou de preprod
2. lancer le service avec docker-compose

L’étape 1 revient à rapatrier une copie des sources et a seconde étape revient utiliser docker-compose sur le demon docker de la VM de prod ou preprod.

Or ces fonctions sont remplies par gitlab-runner. Il suffit simplement de l’utiliser avec un job (construction) qui n’utilise pas dind mais le démon docker de l’hôte. On va utiliser la même configuration qu’en Integration: un executor de type docker. Il suffit pour cela de configurer le runner pour passer par le partage de socket (monter la socket de l’hôte comme socket docker du conteneur de construction (docker-compose).

Finalement la VM de prod ou de preprod n’aura comme prérequis que l’installation d’un docker engine et gitlab-runner dockerisé dans lequel on va créer le runner de déploiement.

Les aspects de sécurités devront être investigués: authentification du serveur gitlab voire du client gitlab-runner

Installation du serveur de préprod

Il faut créer une VM avec un partitionnement LVM2 afi de pouvoir étendre l’espace disque de la VM si besoin. Ma configuration de départ est une VM à 4 Go de RAM et 20 Go de disque avec comme OS une débian 9.9.0.

1. Installer docker selon la documentation officielle
2. Installer docker-compose pour pouvoir installer le gitlab-runner de déploiement (même si on pourrait s’en passer et utiliser une version conteneurisé de docker-compose !)
3. Télécharger la configuration du service du gitlab-runner sur la machine de préprod. Dans mon cas comme elle se trouve sur mon dépot git, je fais un clone….

version: "3.7"
services:
    docker:
        image: 'gitlab/gitlab-runner:alpine'
        restart: always
        volumes:
            - '/srv/gitlab-runner/config:/etc/gitlab-runner'
            - '/var/run/docker.sock:/var/run/docker.sock'

Configuration du runner de déploiement

Lancer le service gitlab-runner par la commande suivante dans le répertoire où se trouve le fichier docker-compose.yml, disons que ce répertoire s’appelle runner

docker-compose up -d

Voilà le serveur de préprod est presque prêt. Il ne reste qu’a instancier le runner dédié au déploiement dans cet environnement de préprod. Le conteneir gitlab-runner est un service qui prend en charge la création des runner.

Si le répertoire du fichier docker-compose.yml s’appelle runner alors le conteneur s’appelle runner_docker_1. On va s’y connecter par

docker exec -it runner_docker_1 bash

Puis entrer la commande:

gitlab-runner register

Les différents paramètres ont été vus dans le billet précédent et ne changent pas. En revanche le tag devra être renseigné à une valeur qui permettra de spécifier que le runner que l’on est en train de créer est dédié à la preprod. Utilisons par exemple le tag staging.

Quitter le shell bash pour revenir sur le shell initial de notre VM de préprod. Comme on persiste la configuration du gitlab-runner sur l’hôte, on va pouvoir aller la modifier pour relier la socket de docker du conteneur créé par le runner à la socket l’hôte. C’est par ce biais que le docker CLI (de l’image docker ou docker-compose) va communiquer avec le docker engine de l’hôte.

nano /srv/gitlab-runner/config/config.toml

Dans la section volumes apporter la modification suivante:

volumes = ["/var/run/docker.sock:/var/run/docker.sock","/cache"]

INSTLLATION DU SERVEUR DE PRODUCTION

Les actions sont identiques à l’exception qu’il faut utiliser un autre tag disons production à la place de staging.

Configuration du build

Le fichier .gitlab-ci.yml de mon projet blog prend finalement alors la forme ci-après. J’ai utilisé une combinaison de tag plus précise afin de spécifier les runner adaptés à chaque étape. Les tag peuvent être modifiés dans l’interface administrateur de gitlab.

 image:
    name: docker/compose:1.24.0
    entrypoint: [""]



 before_script:
   - docker info
   - docker-compose version

 stages:
   - build
   - test
   - staging
   - production
   
 

 run_blog:
   stage: test
   tags:
     - docker
     - dind
   variables:
    # For non-Kubernetes executors, we use tcp://docker:2375/
    DOCKER_HOST: tcp://docker:2375/
    # When using dind, it's wise to use the overlayfs driver for
    # improved performance.
    DOCKER_DRIVER: overlay2

   services:
     - docker:dind     
   script:
     - echo "run blog for testing"
     - docker-compose up -d
     - docker-compose ps

 #verify_running:
 #  stage: test
 #  tags: 
 #  image: golang # because I know it has curl installed
 #  script:
 #     - sleep 120
 #     - curl -v http://docker:8180
                         
    
 deploy_to_staging:
    stage: staging
    tags:
        - staging
        - docker
    script:
        - echo "deploy to staging"
        - docker-compose down
        - docker-compose up -d
    only:
    - master        
 
 deploy_to_production:
    stage: production
    tags:
        - production
        - docker
    script:
        - echo "deploy to production"
        - docker-compose down
        - docker-compose up -d
    only:
    - master
    when: manual

La prochaine étape sera de mettre sous déploiement continue le conteneur initial gitlab-runner qui a dû être installé manuellement. Ensuite je m’attacherai à la personnalisation de l’image wordpress et ce sera l’occasion de creuser les mise en place du proxy de registry et de relier les dockers engines (de ma machine hôte et ceux des VM de préprod et de prod) à mon propre registry.