Dans un précédent post, nous avons vu comment mettre en place l'intégration continue sur un projet web Dans ce second post, nous allons voir comment faire en sorte que notre projet soit automatiquement déployé sur une infrastructure de type Swarm.

Contexte

Pour rappel, dans le précédent article sur le sujet nous avions configuré un projet dans l'objectif de mettre en place une intégration continue. A chaque commit, le runner générait une image docker de notre projet et la poussait sur un registry docker (public ou privé).
Pour cela nous avions utilisé le fichier de configuration gitlab-ci.yml qui permet de décrire les différentes étapes de notre intégration continue.

C'est ce même fichier que nous allons éditer et compléter afin de faire en sorte que notre image, fraichement buildée, puisse être déployée sur un environnement de type Docker Swarm

Pour rappel nous utilisions le fichier gitlab-ci.yml suivant :

image: docker:stable

variables:
  DOCKER_HOST: tcp://docker:2376/
  DOCKER_DRIVER: overlay2

services:
  - docker:dind

stages:
  - package

docker-build:
  stage: package
  script:
    - docker login -u gitlab -p ${CI_REGISTRY_TOKEN} ${CI_REGISTRY_HOST}
    - docker build --build-arg VERSION=${CI_COMMIT_TAG:-nightly} -t ${CI_REGISTRY_HOST}/${CI_BUILD_IMAGE}:${CI_COMMIT_TAG:-nightly} .
    - docker push ${CI_REGISTRY_HOST}/${CI_BUILD_IMAGE}:${CI_COMMIT_TAG:-nightly}
  tags:
    - docker

Livraison continue

Principe

Dans notre contexte actuel, la livraison continue n'est pas vraiment différente de l'intégration continue dans le sens où nous souhaitons faire exécuter des commandes docker à un docker-engine. La seule différence est que nous souhaitons faire exécuter ces commandes sur un docker-engine particulier (celui de notre Swarm).

Afin que cela soit possible, plusieurs solutions s'offrent à nous :

• Faire en sorte que notre runner se connecte à distance au docker-engine de notre Swarm.
• Mettre en place un runner directement dans notre Swarm afin de pouvoir intéragir directement avec le docker-engine

Le mode de déploiement peut quand à lui se faire service par service ou via une stack, définie par le biais d'un fichier compose. C'est d'ailleurs cette dernière solution que nous choisirons par la suite car elle permet d'utiliser la même commande que ce soit pour un premier déploiement ou pour une mise à jour.

Photo by James Pond / Unsplash

Ajout d'un runner

Nous allons choisir d'ajouter un runner dans notre swarm. Il est important qu'il soit déployé sur un manager car, pour rappel, seuls les managers sont habilités à déployer de nouveaux services sur les nodes qui composent le Swarm.

Pour cela nous allons reprendre la configuration et le référencement d'un runner que nous avons vu dans le précédent article (en version plus concise).
Créons dans un premier temps un script d'enregistrerment register.sh :

#!/bin/sh

docker run --rm -it \
    -v $(pwd)/config:/etc/gitlab-runner:rw \
    -v /var/run/docker.sock:/var/run/docker.sock \
    gitlab/gitlab-runner:latest register \
    --non-interactive \
    --executor "docker" \
    --docker-image alpine:3.8 \
    --docker-privileged \
    --url "https://<GITLAB_INSTANCE>/" \
    --registration-token "<GITLAB_TOKEN>" \
    --description "docker-runner-manager" \
    --tag-list "docker,manager,swarm" \
    --run-untagged \
    --locked="false"

Comme dans le précédent article, nous utlisons l'URL GITLAB_URL de notre gitlab et le token GITLAB_TOKEN de notre projet.
Nous avons ajouté deux nouveaux tag (manager et swarm) qui nous seront utiles par la suite afin de cibler le bon runner, en l'occurence celui qui est un manager dans notre swarm.

Voici un petit rappel sur la méthode utilisée pour lancer le runner après sa configuration :

#!/bin/sh

docker rm -f gitlab-runner
docker run -d --name gitlab-runner \
    -v $(pwd)/config:/etc/gitlab-runner \
    -v /var/run/docker.sock:/var/run/docker.sock \
    --restart always \
    --privileged \
    gitlab/gitlab-runner:latest

Etape de livraison

Maintenant que notre nouveau runner est en place, il faut modifier le fichier gitlab-ci.yml de notre projet afin de pouvoir y ajouter une nouvelle étape de pipeline et la configurer.

Nous avons donc le fichier de base suivant :

image: docker:stable

variables:
  DOCKER_HOST: tcp://docker:2376/
  DOCKER_DRIVER: overlay2

services:
  - docker:dind

stages:
  - package

docker-build:
  stage: package
  script:
    - docker login -u gitlab -p ${CI_REGISTRY_TOKEN} ${CI_REGISTRY_HOST}
    - docker build --build-arg VERSION=${CI_COMMIT_TAG:-nightly} -t ${CI_REGISTRY_HOST}/${CI_BUILD_IMAGE}:${CI_COMMIT_TAG:-nightly} .
    - docker push ${CI_REGISTRY_HOST}/${CI_BUILD_IMAGE}:${CI_COMMIT_TAG:-nightly}
  tags:
    - docker

Nous allons ajouter la nouvelle étape delivery dans les stages afin de pouvoir déclarer un nouveau job de livraison. Celui-ci sera le suivant :

docker-deploy:
  stage: delivery
  before_script:
    - unset DOCKER_HOST
    - unset DOCKER_DRIVER
  script:
    - docker login -u gitlab -p ${CI_REGISTRY_TOKEN} ${CI_REGISTRY_HOST}
    - docker stack deploy -c swarm-compose.yml --with-registry-auth ${CI_STACK_NAME}
  tags:
    - docker
    - manager
    - swarm
  only: 
    - master

A la différence de notre premier job qui avait pour objectif de construire l'image de notre projet en utilisant le service docker, nous avons besoin de nous connecter directement au docker-engine de notre manager.
Pour cela, nous supprimons les variables DOCKER_HOST et DOCKER_DRIVER afin que le runner utilise directement le socket local c'est à dire celui du manager.

Maintenant que notre docker-engine est configuré, nous pouvons exécuter les instructions de déploiement. Dans un premier temps nous allons nous connecter au registry afin d'avoir accès à notre image puis nous allons simplement déployer notre stack avec la commande docker stack deploy.

Ci-dessous une petite explication des paramètres :

• -c swarm-compose.yml permet d'identifier le fichier compose, disponible à la racine de notre projet, qui contient la définition de nos services (Un site et une base de données par exemple)
• --with-registry-auth permet de passer l'authentification à notre registry
• ${CI_STACK_NAME} nous permet enfin de nommer notre stack. Les services qui le composent seront quant à eux nommés selon le pattern <stack-name>_<service-name>.

Comme nous avons également pu le faire dans le premier job, nous allons appliquer une contrainte sur la sélection de notre runner afin d'être sûr de cibler celui présent dans notre swarm. Pour cela nous avons appliqué les tags docker, manager et swarm que nous avions spécifié lors de la configuration du runner.

Finalement, afin de ne pas déployer de version instable, nous appliquons également un filtre sur la branche de notre dépôt git. De cette manière, le service ne sera déployé que s'il s'agit d'une modification de la branche master ce qui permet de limiter grandement le nombre de déploiement tout en s'assurant un minimum de la pérénité de notre code.

Références

• Mettre en place une solution d'intégration continue
• Compose file
• Docker stack

Tout le monde a entendu parler d'intégration continue et de déploiement continue. Mais comment réellement la mettre en place.
En partant du postulat que l'on dispose déjà d'un Gitlab et de connaissances en Docker, voici la procédure pour se préparer à mettre en place l'intégration continue et le déploiement continu (CI/CD) ainsi que des exemples type pour la configuration d'un projet multi-technologies.

Généralités sur l'intégration et le déploiement continu

La philosophie générale de la CI/CD est définie par l'exécution d'une action ou liste d'actions lors d'un événement particulier sur dépôt GIT. Des runners sont alors missionnés pour exécuter une tâche à partir des sources disponibles dans le dépôt à un état donné (un commit ou un tag précis ...).

Généralement, c'est le serveur qui prévient les runners qu'une nouvelle tâche est à réaliser or, dans la philosophie de Gitlab, ce sont les runners qui vont aller vérifier régulièrement auprès du serveur s'il n'y a pas de nouvelle tâche à prendre en charge. Cela permet entre-autre de disposer de runner dans un espace sécurisé, sur un réseau privé par exemple, et surtout sur n'importe quel type de machine.

Mise en place d'un runner

Comme annoncé dans le postulat de départ, nous partons du principe qu'une instance de Gitlab est déjà en place et qu'elle est fonctionnelle.
Nous allons donc configurer un gitlab-runner et le configurer pour qu'il puisse aller récupérer des tâches/jobs sur le serveur. Pour cela, nous allons utiliser Docker
L'ajout d'un runner se déroule en deux étapes :

• Il faut le configurer et le référencer dans un premier temps
• Ensuite il faut le démarrer

Configuration et référencement d'un runner

Dans un premier temps, il est nécessaire de récupérer token d'authentification auprès de notre instance Gitlab. Il est possible de récupérer deux types de tokens :

• Un token projet qui permettra de référencer un runner dans le scope d'un unique projet. Il ne pourra alors exécuter que les tâches associées au projet pour lequel il a été référencé.
• Un token global qui permettra de référencer un runner dans le scope global de Gitlab. Cela veut dire qu'il sera en mesure de réaliser les tâches de n'importe quel projet pour peu que sa configuration soit compatible.

Dans cet article, nous allons nous limiter au scope d'un projet aussi, pour récupérer notre token, il suffit d'aller, dans notre projet, dans le menu Paramètres > Intégration et livraison continue puis d'étendre la section Exécuteurs.
Dans le colonne Exécuteurs spécifiques nous pouvons voir les informations nécessaires à la configuration de notre nouveau runner :

• L'adresse de notre instance Gitlab
• Le token d'authentification spécifique à notre projet

Le référencement d'un runner peut se faire de manière intéractive ou directement en ligne de commande. Quoi qu'il en soit, il est important de sauvegarder la configuration du runner pour s'en reservir ultérieurement.
Afin de faciliter un peu la procédure, Nous allons réaliser un petit script qui permet d'enregistrer un runner. Pour cela, il faut créer le fichier register.sh :

#!/bin/sh

docker run --rm -it \
    -v $(pwd)/config:/etc/gitlab-runner:rw \
    -v /var/run/docker.sock:/var/run/docker.sock \
    gitlab/gitlab-runner:latest register \
    --non-interactive \
    --executor "docker" \
    --docker-image alpine:3.8 \
    --docker-privileged \
    --url "https://<GITLAB_INSTANCE>/" \
    --registration-token "<GITLAB_TOKEN>" \
    --description "docker-runner" \
    --tag-list "docker" \
    --run-untagged \
    --locked="false"

Plus de détails sur les paramètres de la commande docker :

• -v $(pwd)/config:/etc/gitlab-runner:rw permet de sauvegarder la configuration du runner dans le dossier config du répertoire courant.
• --non-interactive désactive le mode intéractif
• --executor "docker" définit le type d'éxécuteur en mode docker
• --docker-image alpine:3.8 définit l'image de base à partir de laquelle seront réalisées les tâches
• --docker-privileged permet de donner des droits plus étendus au runner dont celui d'exécuter un daemon docker
• --url "https://<GITLAB_INSTANCE>/" précise l'URL de notre instance Gitlab pour pouvoir vérifier si de nouvelles tâches doivent être exécutées
• --registration-token "<GITLAB_TOKEN>" précise le token d'authentication de notre runner
• --description "docker-runner" définit le nom du runner
• --tag-list "docker" définit une liste de tag, séparés par une virgule, qui peuvent être utilisés pour sélectionner un runner lors de la définition d'une tâche
• --run-untagged précise que le runner peut exécuter des tâche qui n'ont pas été taggées

Si l'on souhaite pouvoir créer des images Docker dans un runner, il peut être également intéressant d'ajouter le flag --privileged.

Lorsque la commande a été exécutée, nous devrions nous retrouver avec le fichier ./config/config.toml dont le contenu est le suivant :

concurrent = 1
check_interval = 0

[session_server]
  session_timeout = 1800

[[runners]]
  name = "docker-runner"
  url = "https://<GITLAB_INSTANCE>/"
  token = "<GITLAB_TOKEN>"
  executor = "docker"
  [runners.docker]
    tls_verify = false
    image = "alpine:3.8"
    privileged = true
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/cache"]
    shm_size = 0
  [runners.cache]
    [runners.cache.s3]
    [runners.cache.gcs]

Exécution du runner

Pour exécuter le runner, nous procédons de la même manière. Nous créons le script run.sh dont le contenu est le suivant :

#!/bin/sh

docker rm -f gitlab-runner
docker run -d --name gitlab-runner \
    -v $(pwd)/config:/etc/gitlab-runner \
    -v /var/run/docker.sock:/var/run/docker.sock \
    --restart always \
    --privileged \
    gitlab/gitlab-runner:latest

Ce script supprime dans un premier temps tout conteneur nommé gitlab-runner puis en démarre un nouveau qui s'appellera à son tour gitlab-runner.
Voici également le détail des paramètres de la commande docker run :

• -v $(pwd)/config:/etc/gitlab-runner permet de monter dans le conteneur un volume qui contient la configuration créée précédemment
• -v /var/run/docker.sock:/var/run/docker.sock permet de monter le socker docker afin de pouvoir exécuter des commandes docker depuis le runner
• --restart always permet de redémarrer le conteneur en cas d'erreur afin de reprendre les travaux en cours
• --privileged permet au runner de créer des conteneurs

Maintenant que nous avons mis en place notre runner, on doit pouvoir le retrouver sur la page d'administration de notre projet.

L'intégration continue sur un projet Web

Préparation du projet

Avant de rentrer dans le vEn partant du postulat quif du sujet, il est nécessaire de préparer le projet (au sens Gitlab) pour l'intégration continue. Rien de bien compliqué mais il faut tout de même préparer les variables d'intégration continue.
Dans notre cas, nous allons faire en sorte de générer des images docker et de les pousser sur un registry local.

Pour cela nous avons besoin de déclarer quelques variables dans notre projet. Il faut donc se rendre dans la section Paramètres > Intégration et livraison continue puis étendre la section Variables.
Nous allons saisir les variables suivantes :

• CI_REGISTRY_HOST : Adresse du registry docker
• CI_BUILD_IMAGE : Nom de l'image docker que l'on va builder
• CI_REGISTRY_TOKEN : Token d'authentification au registry pour un utilisateur donné (ici on utilisera l'utilisateur gitlab)

Photo by Markus Spiske / Unsplash

Définition des règles d'intégration continue

Afin de définir les étapes de notre intégration continue, il est nécessaire d'ajouter à notre projet un fichier de configuration nommé gitlab-ci.yml. Ce fichier va contenir les instructions nécessaires au runner pour réaliser les tâches que nous lui demanderons de faire, selon le formalisme décrit dans la documentation Gitlab.
L'ensemble des instructions définies se nomme un pipeline et est découpé en étapes (build, test, ...) et en jobs.

Dans l'exemple que je vais donner et expliquer ci-dessous, je pars du postulat que le projet sur lequel nous travaillons est déjà configuré pour être packagé dans une image docker. Il y a donc dans l'arborescence un fichier .Dockerfile qui contient les instructions nécessaire au build de notre image.

Voici donc un exemple relativement simple de fichier gitlab-ci.yml :

image: docker:stable

# Uncomment if runner version lower than 11.11
# See : https://docs.gitlab.com/ce/ci/docker/using_docker_build.html#use-docker-socket-binding
# variables:
#   DOCKER_HOST: tcp://docker:2376/
#   DOCKER_DRIVER: overlay2

# Uncomment if runner version lower than 11.11
# See : https://docs.gitlab.com/ce/ci/docker/using_docker_build.html#use-docker-socket-binding
# services:
#   - docker:dind

stages:
  - package

docker-build:
  stage: package
  script:
    - docker login -u gitlab -p ${CI_REGISTRY_TOKEN} ${CI_REGISTRY_HOST}
    - docker build --build-arg VERSION=${CI_COMMIT_TAG:-nightly} -t ${CI_REGISTRY_HOST}/${CI_BUILD_IMAGE}:${CI_COMMIT_TAG:-nightly} .
    - docker push ${CI_REGISTRY_HOST}/${CI_BUILD_IMAGE}:${CI_COMMIT_TAG:-nightly}
  tags:
    - docker

Ce fichier permet de définir la configuration de notre pipeline. Dans le détail, voici la description des différentes étapes qui sont réalisées :

• image: docker:stable : permet de demander au runner d'instancier un conteneur à partir de l'image docker:stable pour réaliser les jobs qui vont être décris pas la suite
• variables : Ce bloc permet d'ajouter des variables qui seront disponible dans le scope global de l'intégration continue. Il est également possible d'en définir dans chacun des jobs. Elles ne seront alors pas disponibles en dehors du scope du job dans lequel elles ont été définies.
• services : Permet de définir un service complémentaire qui sera instancé et accessible pendant l'exécution du pipeline. Ici nous souhaitons utiliser le service docker:dind (docker in docker) afin de pouvoir exécuter n'importe quelle commande docker.
• stages : Permet de définir les étapes de notre pipeline. Elles seront traitées dans l'ordre de définition
• docker-build : Ce n'est pas un mot clé. Nous commençons ici la définition d'un job nommé docker-build
  • stage : Permet d'associer un job à une étape du pipeline.
    Attention, les jobs associés à une même étape sont traités dans un ordre arbitraire.
  • script : Permet de définir une liste de commandes qui seront exécutées par le conteneur.
• tags : Permet de définir quel runner sera utilisé pour exécuter le job, en l'occurence n'importe quel runner disposant du tag docker.

Concentrons-nous un peu plus sur le contenu de la section script.
Nous nous connectons dans un premier temps à notre registry CI_REGISTRY_HOST avec le compte gitlab et le token CI_REGISTRY_TOKEN. Ensuite nous buildons notre image en définissant le paramètre VERSION avec la valeur CI_COMMIT_TAG, une variable de Gitlab correspondant au tag du commit, ou la valeur nightly dans le cas où cette variable n'est pas renseignée puis nous taggons l'image.
Enfin nous poussons l'image générées sur le registry.

C'est un pipeline tout à fait élémentaire mais il présente bien le principe d'intégration continue. Il existe tout un tas d'options de configuration complémentaires qui permettent d'affiner le comportement du runner, en cas d'erreur ou de succès d'un job par exemple.

Il est également possible de compléter un pipeline avec des étapes complémentaire comme les tests ou le déploiement continue car au final, ce ne sont que des commandes qui sont exécutées dans une contexte bien précis.

Références

• Docker
• Gitlab
• Documentation gitlab-ci.yml

Je dispose de quelques Raspberry à la maison et je suis également un grand adepte du serveur freebox. Comme j'essaie le plus possible de ne pas être dépendant de services qui peuvent m'être retirés j'ai envisagé la possibilité de remplacer le serveur freebox, plus particulièrement la fonctionnalité de lecture de contenu local (disque, NAS, ...) par l'application Kodi.

Matériel de base

Au niveau du matériel, je dispose donc d'un Raspberry Pi 3B+ sur lequel j'ai installé la dernière version de Raspbian.
Il n'y a besoin de rien de plus que cela pour la suite de l'article.

Installation de Kodi

Si comme moi vous utilisez Raspbian sans bureau, il convient d'installer au préalables les utilitaires qui permettent d'afficher des interface. En gros, un serveur x :

sudo apt install xinit xutils

Ceci effectué, il suffit ensuite d'exécuter la commande suivante pour installer kodi :

sudo apt install kodi

Démarrage automatique de kodi

Si comme moi, vous souhaitez que kodi démarre automatiquement lorsque vous allumez votre raspberry, il est nécessaire de passer par les étapes ci-dessous :

• On commence par créer un utilisateur qui sera chargé de lancer le programme. Cet utilisateur ne nécessite pas de mot de passe et doit faire parti de différents groupes afin de pouvoir utiliser les ressources nécessaires.

sudo adduser --disabled-password --gecos "User to run Kodi Media Center" <USER>
sudo adduser <USER> audio
sudo adduser <USER> video
sudo adduser <USER> plugdev
sudo adduser <USER> input

• On créé le fichier /etc/systemd/system/kodi.service qui nous permet de déclarer le service kodi. Le contenu est le suivant :

[Unit]
Description = Kodi Media Center

# if you don't need the MySQL DB backend, this should be sufficient
After = systemd-user-sessions.service network.target sound.target

# if you need the MySQL DB backend, use this block instead of the previous
# After = systemd-user-sessions.service network.target sound.target mysql.service
# Wants = mysql.service

[Service]
User = <USER>
Group = <USER>
Type = simple
ExecStart = /usr/bin/kodi-standalone
Restart = always
RestartSec = 15

[Install]
WantedBy = multi-user.target

• Enfin on référence le service que nous venons de créer puis nous le démarrons :

systemctl daemon-reload
systemctl enable kodi.service
systemctl start kodi.service

Désormais, lorsque le Raspberry démarrera, Kodi se lancera automatiquement. Il sera alors possible de le configurer en fonction de votre installation.

Configuration complémentaire

Si l'installation est configurée pour utiliser des dossiers réseaux (répertoires sur un NAS par exemple), il convient de configurer la gestion du cache comme l'indique la documentation.
Pour cela, il faut créer le fichier /home/<USER>/.kodi/userdata/advancedsettings.xml et y ajouter le contenu suivant :

<?xml version="1.0" encoding="UTF-8"?>
<advancedsettings>
  <cache>
    <memorysize>104857600</memorysize>
    <buffermode>1</buffermode>
    <readfactor>4.0</readfactor>
  </cache>
</advancedsettings>

Il est possible d'avoir plus de détails sur les options de configuration du cache dans cette documentation.

Références :

• Wiki Kodi
• Starting Kodi automatically

Fervent utilisateur de Docker, il m'arrive parfois d'être confronté à des difficultés lorsque certains services que je souhaite utiliser ne fonctionnent pas sur ce type d'architecture. Afin de contourner cette difficulté, je me suis penché sur la configuration de Traefik afin de découvrir s'il était possible de rediriger des requêtes HTTP vers un service non dockerisé.

Spoiler, c'est possible !

Configuration de Traefik

Voici la marche à suivre pour mettre en place cette fonctionnalité.
Pour cela, nous avons besoin du module file de traefik qui va nous permettre de prendre en compte la configuration de certains services via des fichiers. Nous avons également besoin de spécifier à traefik de surveiller ces configurations et d'indiquer le fichier ou le répertoire à surveiller.

Pour configurer ces options depuis la ligne de commande, il faut ajouter les labels suivants :

• --file
• --file.watch
• --file.filename ET/OU --file.directory

Vous pouvez également activer ces options depuis le fichier de configuration de traefik. Il faudra pour cela écrire les lignes suivantes :

[file]
  watch = true
  # Uncomment filename to specify a file path
  # filename = /path/of/my/configuration.toml
  # Uncomment directory if you have multiple files
  directory = /path/of/my/files/

Cela peut donner la configuration suivante dans un fichier compose :

  traefik:
    command: --web \
      -c /dev/null \
      --docker \
      --docker.watch \
      --docker.exposedbydefault=false \
      --docker.domain="domain.tld" \
      --accesslogsfile=/dev/stdout \
      --defaultentrypoints="http,https" \
      --entryPoints="Name:http Address::80" \
      --entryPoints="Name:https Address::443 TLS" \
      --entryPoints="Name:traefik Address::8080" \
      --api=true \
      --api.dashboard=true \
      --api.statistics=true \
      --api.statistics.recentErrors=20 \
      --file \
      --file.watch \
      --file.directory=/opt/traefik/config/ \
      --debug
    environment:
      - "affinity:container!=traefik*"
    image: traefik:latest
    networks:
      - docker-net
    ports:
      - "80:80"
      - "443:443"
      - "8080:8080"
    restart: always
    volumes:
      - //var/run/docker.sock:/var/run/docker.sock
      - ./traefik-datas/secure:/root/secure
      - ./traefik-datas/config:/opt/traefik/config:ro

Définition des services

Pour définir vos services, il est possible, selon la configuration que vous avez choisi d'implémenter, de tout configurer dans un fichier unique ou dans des fichiers séparés afin de gagner en lisibilité.
Quoi qu'il en soit, vous trouverez ci-dessous une configuration type de service :

[backends]
  # Name of your backend
  [backends.mybackend]
    # Name of your service
    [backends.mybackend.servers.myservice]
      url = "http://127.0.0.1:9000"

[frontends]
  [frontends.mybackend]
    backend = "mybackend"
    entryPoints = ["http", "https"]
    passHostHeader = true

  # Define headers
  [frontends.mybackend.headers]
    SSLRedirect = true

  # Define rules
  [frontends.mybackend.routes.myservice]
    rule = "Host:my-service.domain.tld"

Cette feature vous permet donc d'intégrer à votre infrastructure Docker des services qui ne fonctionnent pas sur docker et qui peuvent éventuellement être sur des machines distantes.

Depuis que je me suis mis sur docker swarm, ma plus grosse problématique a été la gestion des logs. Cette architecture qui répartie les services entre plusieurs machines répartie également les logs. Pour peu qu'un service redémarre ou qu'un problème survienne, on risque de perdre une partie des logs et ne plus pouvoir inspecter les erreurs d'une application.

Un peu de prospection

J'ai rapidement cherché une solution pour centraliser les logs de mes applications et j'ai souvent été ramené vers Elastic Search et la populaire stack ELK^[1]. Ma contrainte étant la gratuité et la maitrise de mes données cela semblait être une bonne option.
Cependant, le problème de cette stack, de mon point de vue, c'est sa grosse consommation de ressources, et sa configuration pénible à implémenter. De plus je n'ai pas trouvé que logstash soit assez flexible sur le formattage des logs.

Photo by Štefan Štefančík / Unsplash

J'ai également testé une autre stack à base d'Elastic Search mais cette fois avec Fluentd^[2] à la place de Logstash. Dans la configuration que j'ai pu rencontrer il fallait configurer les driver de log sur chacun des services que je souhaitais surveiller. Au final ce n'était pas pratique car la moindre défaillance au niveau de fluentd faisait planter tous les services qui l'utilisaient.

Vers une solution partielle

Du moment ou j'ai commencé à m'intéresser au sujet de centralisation des logs à aujourd'hui, il s'est passé un an. Sur toutes les solutions que j'ai pu observer, Elastic Search et Kibana en étaient très souvent des composants. Par chance, ces deux projets ont également évolué pendant cette période pour être plus faciles d'accès.
Je me suis donc retrouvé avec une solution partielle pour stocker et visualiser mes données. Il ne me restait plus qu'à trouver de quoi collecter et traiter mes logs.

Création d'un outil de collecte

Finalement je me suis retourné vers mes propres compétences en développement pour mettre en place une solution qui corresponde à mon besoin ... et peut-etre à celui d'autres.
J'ai alors développé LogPycker, un petit projet python qui se connecte au daemon docker pour aller lire les logs de chacun des conteneurs déployés. De base, il effectue un parsing sommaire afin de construire un message structuré, au mieux, de la manière suivante :

{
    "date": "August 4th 2018, 10:32:31.384",
    "project": "my-project",
    "service": "my-service",
    "task": "my-task-id",
    "message": "content of my message"
}

Certains attributs du message peuvent ne pas être présent notamment lorsque le conteneur est lancé tout seul. En effet, les attributs project, service et task ne sont disponibles que si le conteneur est lancé par le biais d'une stack (compose ou swarm).

Photo by Oskars Sylwan / Unsplash

Utilisation de Log Pycker

Comme je l'ai dit plus tôt, mon objectif premier était de disposer d'un aggrégateur de log simple à mettre en place. Outre la configuration du point daccès vers Elastic Search , s'il n'y a rien à configurer de particulier pour récupérer des logs, on ne peut que mieux se porter.

Je me suis donc basé sur la stack ELK^[1:1] afin de mettre en place mon outil. Cela m'a faut aboutir à la stack suivante (en mode compose) :

version: "3.2"

networks:
  logger-net:
  docker-net:
    external: true

services:
  elastic:
    environment:
      discovery.type: single-node
    image: docker.elastic.co/elasticsearch/elasticsearch:6.3.1
    networks:
      - logger-net
    restart: always

  pycker:
    depends_on:
      - elastic
    environment:
      elastic.url: http://elastic
    image: xylphid/log-pycker:latest
    links:
      - elastic
    networks:
      - logger-net
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

  kibana:
    depends_on:
      - elastic
    environment:
      ELASTICSEARCH_URL: http://elastic:9200
    image: docker.elastic.co/kibana/kibana:6.3.1
    labels:
      traefik.enable: "true"
      traefik.backend: "Monitor"
      traefik.docker.network: "docker-net"
      traefik.frontend.headers.SSLRedirect: "true"
      traefik.frontend.rule: "Host: monitor.docker"
      traefik.port: "5601"
    links:
      - elastic
    networks:
      - docker-net
      - logger-net

Note : J'utilise Traefik^[3] afin de pouvoir accéder à kibana via l'adresse http://monitor.docker (domaine local)

Comme on peut le voir, le service pycker est relativement facile à configurer. Il n'a besoin que de connaitre l'adresse d'Elastic Search et d'avoir accès, par le biais du volume, au daemon docker.

Pour aller un peu plus loin

Le besoin d'analyse des logs pouvant être différent selon les services que l'on souhaite surveiller, j'ai souhaité mettre en place un mécanisme qui permette, depuis chaque conteneur, de spécifier un format d'extraction des données.
Pour cela, il suffit de définir un label de conteneur avec une expression régulière spécifiant le pattern d'extraction.
Voici un exemple de ce que j'utilise pour extraire le niveau de log d'un projet Play Framework! :

version: "3.2"
services:
  web-app:
    image: my-web-app-play
    labels:
      log.pycker.pattern: "(?P<level>(?:[[])?(?:INFO|DEBUG|ERROR)(?:[]])?)\\s*"
    restart: always

Comment cela fonctionne ?
Assez simplement au final. L'expression régulière utilise des groupes nommés qui serviront à définir les attributs complémentaires de notre objet message. Si le message match un des groupes il sera extrait et nettoyé.

Voici un message avant traitement :

{
    "message": "INFO ~ [LogManager][before] Requested URI : GET:/"
}

Et voici le même message après avoir été analysé avec le pattern :

{
    "level": "INFO",
    "message": "~ [LogManager][before] Requested URI : GET:/"
}

Il est également possible de détecter automatiquement les messages multiligne. Pour cela, il faut activer l'option via un label de conteneur.
Dans cette première version de l'application, cette option est très fortement liée à la présence de la date. Ainsi un message avec une date sera systématiquement considéré comme un nouveau message alors qu'un message n'ayant pas cette information sera rattaché au précédent.

Si l'on reprend notre stack précédente, nous avons modifié la définition comme suit :

version: "3.2"
services:
  web-app:
    image: my-web-app-play
    labels:
      log.pycker.pattern: "(?P<level>(?:[[])?(?:INFO|DEBUG|ERROR)(?:[]])?)\\s*"
      log.pycker.multiline.enabled: "true"
    restart: always

Ces deux options permettent d'améliorer la qualité des informations récupérées par l'outil de collecte et, pour peu que l'on manipule correctement les expressions régulières, d'avoir un détail relativement fin dans le découpage des logs.

Amélioration à venir

Voici les quelques évolutions que j'envisage de mettre en place à ce jour afin d'améliorer les performances de l'application :

• Utiliser une message queue pour stocker les messages en cas d'erreur réseau (avec un fallback en local)
• Récupérer tout l'historique de log d'un conteneur.

Remonter un bug ou contribuer

Le projet est actuellement en phase de test sur une petite architecture qui héberge une vingtaine de services.
Vous pouvez, si vous le souhaitez, le tester sur votre propre infrastructure et remonter vos bugs via github.

Il y a peu, j'ai dû m'intéresser au sujet de la mesure d'audience d'un site et plus particulièrement valider que le plan de marquage (clics, affichage, auto-promo) soit correctement implémenté.

La régie en question ? AT-Internet^[1].

Comme énoncé en introduction, je me suis plus particulièrement penché sur les trois types de marqueurs suivants :

• Affichage : Permet de mesurer l'audience d'une page (le nombre d'affichage). Il faut faire attention car dans certains cas il est aussi nécessaire de mesurer l'audience d'une partie de page chargée en AJAX.
• Clics : Permet de mesurer l'audience d'un bouton ou d'un lien
• Auto-Promo : Permet de mesurer n'importe quel élément dans l'optique générale d'en mesurer l'impact. On souhaite souvent savoir si un lien, ou un encart a plus d'impact qu'un autre selon sa position sur la page.

Photo by Olloweb Solutions / Unsplash

Généralités

Fonctionnement de l'outil de monitoring d'audience

Afin de mettre en place des tests valides, il est important de comprendre le fonctionnement de l'outil et de connaitre les pré-requis au bon marquage d'une page, d'un lien ou de tout autre élément.
Pour commencer, il faut rappeler que la mesure d'audience est réalisée par le biais de requêtes vers les-dis outils. Cela peut se faire en affichant un pixel transparent sur une page ou en effectuant une requête asynchrone. Ces requêtes comportent des paramètres particuliers qui permettent d'identifier le compte, l'action ainsi que d'autres données utiles. Ce sont ces paramètres qui nous permettrons de valider le plan de marquage d'une application.

Fonctionnement de Testcafé

Photo by Robb Leahy / Unsplash

Testcafé^[2] est un outil de test end-to-end utilisé pour valider une interface Web et son comportement selon le navigateur utilisé par un visiteur. Il permet de scénariser la visite d'un internaute avec des instructions simples afin de s'assurer que l'application se comporte correctement.
Cet outil permet également de surveiller les requêtes émises par l'application comme un chargement de fichier ou un appel asynchrone. C'est cette fonction qui va plus particulièrement nous intéresser car elle va nous permettre de récupérer toutes les requêtes sortantes vers l'outils Xiti.

Je ne rentrerai pas dans le détail de la configuration de l'outil car il est relativement facile à prendre en main et dispose d'une solide documentation^[3]. Je mettrai cependant suffisamment de commentaires pour que chaque portion de code soit compréhensible.

Mise en place des tests

Photo by Luca Bravo / Unsplash

Valider l'affichage d'une page

Pour valider l'affichage d'une page il est nécessaire de connaitre la valeurs de plusieurs variables :

• Nom de page
• Chapitrage : Il est facultatif et peut être découpé en trois parties (chapitre 1, chapitre 2 et chapitre 3). Généralement il s'apparente à l'arborescence du site.

Une fois ces données connues, nous pouvons écrire notre test dans le fichier load.js :

// Import required modules
import { Selector, RequestLogger } from 'testcafe';

// Set URL pattern for request logger
const xiti = /xiti.com/
// Set request logger
const logger = RequestLogger(xiti, {
    logRequestHeaders: true,
    logResponseHeaders: true,
    logResponseBody: true
});

// Declare fixture
fixture `Page Load`
    // Attach logger for all tests
    .requestHooks( logger );

test
    // Navigate
    .page( 'http://www.example.com' )
    ('Test name', async t => {
        const pageName = 'homepage';

        await t
            // Wait 5 seconds until the page is loaded (libs, images, DOMContentLoaded event)
            .wait(5000)
            // Expect that ...
            .expect(
                // At least one HTTP request ...
                logger.contains(record => {
                    var url = require( 'url' );
                    var request = new url.URL(record.request.url);

                    // Contains parameters with the correct value
                    return request.searchParams.get("p") == pageName;
                })
            )
            // Validate test or display error
            .ok('Error : Tag failed');
    });

Pour résumer rapidement ce test, nous allons afficher une page et attendre 5 secondes qu'elle soit complètement chargée. Pendant son chargement nous allons capturer toutes les requêtes vers le domaine xiti.com. Nous allons ensuite parcourir toutes les requêtes vers xiti.com afin de vérifier qu'au moins l'une d'entre elle comporte le paramètre p avec la bonne valeur.

Pour lancer le test nous exécutons la commande suivante :

$> docker run \
    --rm \
    --name testcafe \
    -a stdout \
    -a stderr \
    -v $(pwd):/tests \
    testcafe/testcafe \
    firefox /tests/load.js
    
 Running tests in:
 - Firefox 57.0.0 / Linux 0.0.0

 Page Load
 ✓ Test name

Valider un clic de navigation

Globalement, il ne va pas se passer grand chose de plus que sur l'affichage d'une page. La seule différence consiste à intéragir avec la page, à savoir cliquer sur un élément.
Les pages d'un site étant relativement vivantes de nos jour, il n'est pas rare de devoir naviguer un peu avant d'atteindre l'élément que l'on souhaite tester si celui-ci n'est pas visible par défaut.

Il y a également des paramètres différents à valider :

• Chapitrage
• Libellé du clic
• Type de clic : exit, download, action ou navigation
• Identifiant

Nous rédigeons notre test dans le fichier click.js :

// Import required modules
import { Selector, RequestLogger } from 'testcafe';
// Set URL pattern for request logger
const xiti = /xiti.com/
// Set request logger
const logger = RequestLogger(xiti, {
    logRequestHeaders: true,
    logResponseHeaders: true,
    logResponseBody: true
});
// Click type object
const clickType = {
    exit: 'S',
    download: 'T',
    navigation: 'N',
    action: 'A'
};

// Declare fixture
fixture `Click`
    // Attach logger
    .requestHooks( logger );

test
    // Navigate
    .page( 'http://www.example.com' )
    ('Click submenu1', async t => {
        const type = 'navigation',
            chapter1 = 'myChapter1',
            chapter3 = 'myChapter3',
            label = 'monitoredLink',
            marker = chapter1 + "::" + chapter3 + "::" + label,
            targets = [
                '#menu a.submenu1',
                '#submenu1 a.out'
                ];

        // Wait 5 seconds until the page is loaded (libs, images, DOMContentLoaded event)
        await t.wait(5000);
        
        // Clear logged requests
        logger.clear();
        
        // Navigate to the final target
        for (let i = 0; i < targets.length; i++) {
            await t.click( targets[i] );    
        }
        
        // Test click tag
        await t
             // Expect that ...
            .expect(
                // At least one HTTP request ...
                logger.contains(record => {
                    var url = require( 'url' );
                    var request = new url.URL(record.request.url);

                    // Contains parameters with the correct value
                    return request.searchParams.get("p") == marker &&
                        request.searchParams.get("click") == clickType[type];
                })
            )
            // Validate test or display error
            .ok('Errorr : Tag failed');
    });

Il ne reste plus qu'à valider le test

Comme dans l'exemple précédent, nous allons afficher la page et attendre 5 secondes qu'elle soit complètement chargée. Nous nettoyons ensuite l'ensemble des requêtes capturées afin de ne pas polluer notre monitoring avec des données qui pourraient être fausses.
Afin d'accéder à l'élément à tester, un sous-menu fictif non affiché par défaut, nous simulons les actions d'un utilisateur pour le rendre visible. Ensuite, comme pour le cas précédent, nous allons parcourir toutes les requêtes vers xiti.com afin de vérifier qu'au moins l'une d'entre elle comporte les bonnes valeurs de paramètre (ici nous allons tester les paramètres p et click).

Nous lançons ce nouveau test avec la commande suivante :

$> docker run \
    --rm \
    --name testcafe \
    -a stdout \
    -a stderr \
    -v $(pwd):/tests \
    testcafe/testcafe \
    firefox /tests/click.js
    
 Running tests in:
 - Firefox 57.0.0 / Linux 0.0.0

 Click
 ✓ Click submenu1

Valider une auto-promotion

Avant de rentrer dans le détail de l'implémentation il faut savoir qu'une auto-promotion n'est ni plus ni moins que la combinaison des deux types de marqueurs précédents à la différence qu'on ne teste pas les mêmes paramètres.
En effet, une auto-promotion consiste à effectuer au moins un des événements suivants :

• Afficher un élément promu
• Cliquer sur un élément promu

Il y aura donc deux événements à surveiller. Le premier au chargement de la page et le second, s'il est activé, au clic sur un élément promu.

Nous rédigeons notre test dans le fichier self-promoted.js :

// Import required modules
import { Selector, RequestLogger } from 'testcafe';

// Set URL pattern for request logger
const xiti = /xiti.com/
// Set request logger
const logger = RequestLogger(xiti, {
    logRequestHeaders: true,
    logResponseHeaders: true,
    logResponseBody: true
});

// Declare fixture
fixture `Click`
    // Attach logger
    .requestHooks( logger );
    // Navigate
    .page( 'http://www.example.com' )

test
    ('Web callback', async t => {
        const id = 11,
            chapter1 = 'myChapter1',
            chapter2 = 'myChapter2',
            chapter3 = 'myChapter3',
            label = 'monitoredLink',
            marker = 'INT-' + id + '-[' + chapter1 + '::' + chapter2 + '::' + chapter3 + '::' + label + ']',
            target = '#callBack';

        // Test print tag
        await t
            // Wait 5 seconds until the page is loaded (libs, images, DOMContentLoaded event)
            .wait(5000)
            // Expect that ...
            .expect(
                // At least one HTTP request ...
                logger.contains(record => {
                    var url = require( 'url' );
                    var request = new url.URL(record.request.url);

                    // Contains parameters with the correct value (sort of :) )
                    return request.searchParams.get("ati").indexOf(marker) != -1;
                })
            )
            .ok('Error : Print tag failed');

        // Clear logged requests
        logger.clear();

        // Test click tag
        await t.click( target )
            // Expect that ...
            .expect(
                // At least one HTTP request ...
                logger.contains(record => {
                    var url = require( 'url' );
                    var request = new url.URL(record.request.url);

                    // Contains parameters with the correct value
                    return request.searchParams.get("atc") && 
                        request.searchParams.get("atc").indexOf(marker) != -1;
                })
            )
            // Validate test or display error
            .ok('Error : Click tag failed');
    });

Nous allons donc dans un premier temps valider, après le chargement de la page qu'un tag d'impression soit envoyé puis nous allons simuler une action utilisateur afin de valider par la suite que le tag de clic soit bien envoyé à son tour.
Il faut noter que les paramètres à tester ne sont plus les mêmes car il dépendent du type de tag mis en place.

Nous lançons maintenant le nouveau test avec la commande suivante :

$> docker run \
    --rm \
    --name testcafe \
    -a stdout \
    -a stderr \
    -v $(pwd):/tests \
    testcafe/testcafe \
    firefox /tests/self-promoted.js
    
 Running tests in:
 - Firefox 57.0.0 / Linux 0.0.0

 Click
 ✓ Web callback

Conclusion

Avec quelques outils et très peu de configuration, il est possible de valider la mise en place d'une solution de suivi d'audience telle que Xiti. Il est à mon avis tout à fait possible de réaliser la même chose avec Google Analytics.

Allez on se lance.

Depuis le temps que je me dis qu'il faut que j'écrive quelques articles sur ce que je fais... me voila !

Photo by Patrick Perkins / Unsplash

Pour me présenter rapidement, je suis Anthony PERIQUET, un ingénieur en informatique plutôt orienté développement et agilité mais tout de même intéressé par le reste des possibilités qu'offre ce grand domaine technologique. Je me suis passionné dernièrement pour Docker, aussi je pense qu'une bonne partie des articles à venir abordera ce sujet ou ce qui tourne autour.

Globalement je suis assez curieux de comprendre comment fonctionne les choses et il n'est pas rare que je réinvente la roue afin d'être sûr de bien m'être approprié le sujet. Je suis aussi ce que l'on pourrait qualifier d'Artisan informatique car je préfère globalement tout faire moi-même afin de maitriser la totalité de mon travail. Ce n'est pas forcément optimal en terme de productivité c'est pourquoi j'adopte plutôt cette pratique sur mes projets personnels plutôt que professionnels :).

Bon, assez parlé de moi ...
A une prochaine fois pour un sujet plus technique :)