Catégories
Uncategorized

Surveillance apache avec Prometheus

Dans le remplacement de Munin par Prometheus, les indicateurs systèmes (OS et docker) sont en place. Avant de supprimer munin de mes machines, il reste encore quelques éléments à reprendre commme les métriques de:

  • Apache (frontal et reverse proxy)
  • KVM
  • Mail
  • Fail2ban
  • Queue d’impression (utile ?)

Commençons par la surveillance de apache

Apache exporter

Sur le site de Prometheus on trouve une liste de logiciels complementaires poir exporter des métriques des composants connus tels que apache. De nombreuses version de cet exporter pour apache sont disponibles, sur github notament, mais je retiendrais les 3 versions suivantes:

  • httpd_exporter de https://github.com/kelein/httpd_exporter
  • apache_exporter de https://github.com/Lusitaniae/apache_exporter
  • prometheus-apache-exporter en paquet debian

Compiler avant d’utiliser…. pas user-friendly

En tant qu’informaticien et développeur à la base la compilation est une étape qui ne devrait pas effrayer. Cela tombe bien car la version de kelein est un exporter dockerisé et demande à faire une compilation avant se pouvoir etre utilisée.

Compiler en docker c’est quoi ?

Dans les projet docker, la phase build consiste à fabriquer l’image avant de pouvoir l’exécuter. Cette phase est normale lors du développement du logiciel mais ne devrait pas être imposée à l’utilisateur du logiciel.

Quand je vais acheter une voiture, elle n’est pas fournie en kit que je dois monter

Differentes stratégies de constructions

Comme l’informaticien est un utilisateur que la compilation n’effrait pas, un petit docker build . ne va pas nous gêner. Si le httpd_exporter de kelein se construit parfaitement du premier coût c’est parce qu’il embarque dans son Dockerfile tout ce qu’il faut: compilation du source en langage Go dans une image intermediaire et création de l’image finale.

httpd_exporter pas compatible avec les tableaux de bord Grafana

Le test de l’image obtenue est concluant pour peu que l’indique bien l’url cible du serveur apache accessible depuis le conteneur via l’argument

--scrape_uri="https://perso.bressure.net/server-status"

Malheureusement les métriques sont exportées sous des noms qui ne ne sont pas ceux attendus par les tableaux de bord Grafana disponibles en libre service. Ces derrniers se base sur l’exportation faite par apache_exporter de Lusitaniae.

Lusitaniae

Cette autre version semble être la plus ancienne dans la sphère Docker. De plus elle est reprise dans le paquet prometheus-apache-exporter de Debian. C’est un signe de qualité et utiliser un exporteur à la fois disponible en version conteneurisés et native permettrait de passer de l’un à l’autre plus simplement.

Autre stratégie de construction

Comme pour httpd_exporter il faut faire un buils avant d’utiliser. Je me sens comme revenu dans en 1998 où pour utiliser le mode graphique sous Linux il fallait parfois encore compiler et jouer du makefile… Cette fois-ci je déchante car le Dockefile attend un binaire dont on a bien le source Go mais pas les instructions de build…. sauf dans la documentation. Il eu été préférable de les avoir dans le source du projet même et idéalement dans un Dockerfile.

On est informaticien ? Alors on compile via les instructions données dans la documentation. Je choisi donc une version de Go un peu récente et lance la compilation via une image docker de Go. La déception ne tarda pas à venir. La construction échoue sur un problème de dépendance dans la définition du projet.

Docker c’est un peu la création de paquet

Cette mésaventure soulève un aspect non négligeable de docker. Contrairement à l’écosystème Java où un seule langage et une seule méthode (si on se réfère au temps glorieux de J2EE) permettent de construire, d’empaqueter et déployer une application, docker offre certe de repondre au problème des dépendances et d’intégration mais il ressemble sur bien des aspects à un mécanisme de paquet des distribution Linux.

Compétences multi-langage requise

En effet le mainteneur d’un paquet doit savoir compiler le logiciel à partir de son source. Cela necessite donc de connaître les mecanismes de constructions propres au langage dans lequel est écrit l’application. Dans le cas des exporter pour appache c’est le langage Go. Pour pouvoir construire l’image il ne suffit pas juste connaitre Docker mais il faut également connaitre Go. J’ai egalement expérimenté le même soucis avec un projet Rails dont l’écosystème avec les Gemfiles m’est totalement étranger.

Fournir des images au lieu des sources

Comme je vois Docker comme une couche au dessus de l’application permettant à celle-ci de s’exécuter sans que l’utilisateur ait à se soucier des dependances où autres plomberie d’intègration, cela me conforte dans l’idée de la nécessité de fournir des images à l’utilisateur et non des souces pour la commande docker build.

Paquet debian prometheus-apache-exporter

Heureusement que d’autres savent mieux que moi comment compiler des sources Go. Debian fournit d’ailleurs un paquet binaire de l’exporter apache basé sur Lusitaniae.

Cherchant la simplicité et puisque mon apache n’est de toute façon pas encore dockerisé, je me suis rabattu sur cette version native de l’exporter. Cela n’est pas sans conséquence car étant installé en service systemd le paramètrage de l’url nécessite de s’accomoder d’un paramétrage propre à l’OS. On fait du système.

Paramètrage de l’exporter apache en service

En allant consulter la documentation Debian, j’apprends que le fichier définition du service installé par le paquet est dans /lib/systemd/system/prometheus-apache-exporter.service et non pas dans /etc/systemd/system/

En allant voir ce fichier on découvre qu’un fichier de variable est utilisé et que la variable ARGS permettra de paramétrer notre exporter.

EnvironmentFile=/etc/default/prometheus-apache-exporter ExecStart=/usr/bin/prometheus-apache-exporter $ARGS

Il ne reste plus qu’à aller ajouter dans /etc/default/prometheus-apache-exporter le paramètre

ARGS='-scrape_uri https://perso.bressure.net/server-status/?auto'

Notez que l’argument ne contient qu’un seul tiret dans le service et deux en ligne de commande docker. Je passe sous silence la sécurisation qui rend l’url du status de apache accessible seulement en local.

Tableau de bord grafana

A ce stade les métriques suivantes sur apache peuvent être disponibles dans Prometheus. Il suffit de déclarer un nouveau job pointant sur le endpoint offert par l’exporter. Par exemple dans le fichier prometheus.yml:

- job_name: apache
honor_timestamps: true
scrape_interval: 15s
scrape_timeout: 10s
metrics_path: /metrics
scheme: http
static_configs:
- targets:
- 192.168.0.12:9117

On peut alors avoir ce genre de graphique:

Graphique prometheus d’une métrique apache

En utilisant un tableau de bord en libre service sur le site de grafana, on peut avoir ce genre de graphiques sans aucune configuration supplémentaire:

Tableau de bord Grafana pour apache

On a réussi facilement à remplacer Munin par Prometheus pour surveiller apache. La prochaine étape sera de passer sous Prometheus la surveillance des VM. La suite au prochain billet.

Catégories
Application Paramétrage

Les alertes avec Prometheus

Remplacer munin par Prometheus se serait complet sans la partie envoi des alertes. Dans mon cas un simple mail suffira.

Alertmanager

Comme tout est dockerisé chez moi, je vais donc ajouter dans mon application de monitoring le service alertmanager. Le rôle de l’alertmanager est de recevoir les demandes de notification quand une métrique a une valeur donnée. Les fonctions de l’alertmanager sont entre autres de temporiser, relayer ou inhiber les notifications.

Grafana peut également envoyer des notifications mais comme je l’ai déjà mentionné, je ne vais l’utiliser que pour sa fonction de tableau de bord. Par ailleurs Grafana peut envoyer des alertes vers l’alertmanager donc ce dernier jouera parfaitement son rôle en recevant les demandes de notification de la part de Promethéus ou Grafana.

Alertes

Créer des alerte est relativement simple. Si munin est fournit avec beaucoup de plugin déjà éprouvés, il va falloir ajouter les alertes de bases comme: la saturation cpu, mémoire ou disque.

Paramétrage d’une destination mail dans l’alertmanager

Comme je définis un volume pour le conteneur alertmanager via mon fichier docker-compose.yml de l’appication de monitoring

   alertmanager:
      image: 'prom/alertmanager'
      restart: always 
      volumes:
        - alertmanager_conf:/etc/alertmanager

Il suffit depuis l’hôte docker de modifier le fichier /var/lib/docker/volumes/monitoring_alertmanager_conf/_data/alertmanager.yml

Voici le contenu qui permet de configurer l’envoi de mail, à modifier pour adapter à votre configuration de mail !

global:
  resolve_timeout: 5m
  smtp_smarthost: 'mon.serveur.smtp.com:587'
  smtp_from: 'monadresse@mail.com'
route:
  group_by: ['alertname']
  group_wait: 10s
  group_interval: 10s
  repeat_interval: 1h
  receiver: 'mail_to_admin'
receivers:
- name: 'web.hook'
  webhook_configs:
  - url: 'http://127.0.0.1:5001/'
- name: 'mail_to_admin'
  email_configs:
  - to: destinataire@mail.com
inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'instance']

Configuration de prometheus pour utiliser l’alertmanager

L’application de monitoring utilise une image personnalisée de prométheus dont le seul but est de fournir une configuration de base visible dans le fichier prometheus.yml.

La partie importante est celle-ci:

rule_files:
  - '/etc/prometheus/rules/*'
alerting:
  alertmanagers:
  - static_configs:
    - targets: ['alertmanager:9093']
    scheme: http
    timeout: 10s
    api_version: v1

Ajout d’un alerte d’occupation disque

Dans le fichier de configuration prometheus.yml on a indiqué de prendre tous les fichiers du répertoire /etc/prometheus comme règles. Il suffit alors d’ajouter dans ce répertoire les fichiers de règles des alertes. Comme prométheus est dans un conteneur, il faudra aller sur machine hôte dans le répertoire /var/lib/docker/volumes/monitoring_prometheus_conf/_data/rules/

Voici par exemple le contenu d’un fichier qui donne l’alerte quand l’occupation disque dépasse 80%

groups:
- name: disk
  rules:
  - alert: diskUsage
    expr: 1 - node_filesystem_free_bytes / node_filesystem_size_bytes > 0.8
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: consommation disque eleve

Règles enregistrées

On pourra factorisé les calculs de métriques qui peuvent être coûteux et partager le résultat dans des définitions d’alerte. Ainsi dans l’exemple suivant on calcul un seul fois l’occupation d’overcommit et 2 alertes réutilisent le résultat:

groups:
- name: memoire
  rules:
  - record: memoire:overcommit
    expr: node_memory_Committed_AS_bytes / (node_memory_MemTotal_bytes + node_memory_SwapTotal_bytes) 
  - alert: overcommit
    expr: memoire:overcommit > 0.9
    for: 10m
    labels:
      severity: critical
    annotations:
      summary: surconsommation memoire
  - alert: overcommit
    expr: memoire:overcommit > 0.8 and memoire:overcommit <= 0.9
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: surconsommation memoire

L’étape suivante sera la surveillance de l’espace disque occupé par docker. Il peut être intéressant de suivre l’évolution de cette métrique et se sera l’occasion d’apprendre à étendre le node-exporter de prométheus. La suite au prochain billet…

Catégories
Application Paramétrage

Docker sur VM et réseau

J’ai eu surprise de voir que ma surveillance ne fonctionnait plus avant hier. Pourtant d’après la capture prise vendredi soir tout semblait fonctionner.

Il y a 2 jours la connexion entre mon conteneur Prometheus et les conteneurs prom-node et cAdvisor situés sur des VM étaient devenu impossible. Toute la configuration reseau est du standard à savoir:

  • conteneur avec reseau bridge dédié par défaut avec docker-compose
  • VM avec reseau NAT par défaut avec virsh/KVM
connexion conteneur sur hôte vers conteneur sur VM impossible

Un test avec telnet m’a alors montré que depuis la machine hôte on pouvait joindre les conteneurs sur VM avec l’IP des VM gérée par KVM. Cependant depuis le conteneur sur l’hôte si l’accès à l’hôte lui-même était possible, un telnet vers les IP des VM échouait

Il faut dire que tout le paramètrage réseau mis en place par KVM et docker est un peu mystèrieux pour moi et je fais confiance à ceux qui savent plus que moi paramétrer le réseau…

Solution rapide

Comme depuis l’hôte la connexion vers les conteneurs sur VM NAT est possible alors une solution rapide est d’indiquer à Docker de mettre le conteneur Prometheus dans un réseau de type hôte. Dans le fichier docker-compose.yml au même niveau que image ajouter:

network_mode: "host"
Solution rapide, passer par l’hôte

Solution pérenne : le réseau overlay

La solution précédente enlève l’isolation reseau du conteneur Prometheus avec l’hôte et cela me gêne. De plus le conteneur grafana ne pouvait plus accéder à prometheus par son nom. Il fallait le faire passer par l’IP de l’hôte.

Une autre solution serait de mettre le conteneur prometheus dans une VM, car les VM se voient entre-elles par défaut. Un test telnet m’avait montré que les conteneurs d’une VM pouvait via l’IP des autres VM accéder aux conteneurs de ces VM.

Cette autre solution me gêne également car elle fait reposer la connectivité sur un paramétrage réseau géré par virsh/KVM. Idealement on voit aisément que les conteneurs dévolus au monitoring doivent être dans le même réseau et ce réseau doit chevaucher plusieurs démons docker sur des hôtes différents. C’est un réseau overlay !

Solution idéale : le reseau overlay

La mise en place du reseau overlay est une opération un peu complexe car il faut initialiser un neoud swarm maître sur l’hôte de prometheus, créer un réseau overlay dédié au monitoring, sur les hôtes de cAdvisor/prom-node il faut déclarer docker comme membre du swarm et enfin indiquer des les fichiers docker-compose que tous les conteneurs doivent utiliser le reseau overlay précédemment créé. Ici on avait créé un réseau appelé monitoring-net

networks:
  default:
    external:
       name: monitoring-net

Je ne suis pas allé au bout de la solution idéale de l’overlay car en créant seulement le reseau overlay et en y mettant prometheus, tout est retombé en marche. Je suis alors revenu en arrière et tout continue de fonctionner comme vendredi soir…. Je n’aime pas quand les choses tombent en marche. Affaire à suivre en gardant ce billet sous le coude.

Catégories
Application Paramétrage

Monitorer ses applications (docker) avec Prometheus et Grafana

Après avoir réglé mes soucis de mise à jour de Owncloud, je me suis remis à mes aventures avec Prometheus et Grafana.

Config de Prometheus embarquée

Comme mon infrastructure ne change pas entre mes environnements, j’ai tout d’abord pensé mettre le fichier de configuragion /etc/prometheus/prometheus.yml dans l’image docker de prometheus. Le code source final de cette petite manipulation se trouve ici https://gitlab.bressure.net/docker/services/prometheus

Enrichissement de la couche infra

Puis il suffit de construire l’application monitoring avec docker-compose en ajoutant le service grafana. Le tout devra s’executer sur mon instance docker que je qualifie d’infrastructure car sémantiquement ce n’est ni un poste de développement (bien qu’il ait aussi ce rôle dans les faits), ni de la production.

Nous obtenons alors une application de monitoring dont la seule source de métrique est l’instance de prometheus elle-même qui expose ses propres valeurs. Quand à grafana il faudra lui ajouter une source de données de type prometheus qui sera désignée par son url http://prometheus:9090/. La résolution du nom prometheus sera faite par le DNS de docker au sein du réseau construit par ses soin grâce au docker-compose.yml.

Mon objectif est de faire de prometheus le centralisateur de toutes les métriques et grafana sera le traceur de graphique avec comme unique source de données prometheus.

Ajout des sources à monitorer

Il faut donc ajouter des sources de données dans prometheus. C’est ce qui s’appelle dans la terminologie de prometheus des job avec pour chacun d’eux des endpoints c’est-à-dire des adresses exposant au bon format les valeurs des métriques. Ainsi prometheus lui-même est un endpoint comme vu plus haut.

Gitlab

Mon conteneur GitLab est capable d’exposer des métrique applicative (données métiers) au format prometheus. Cela sans grand effort. Il suffit d’activer prometheus dans GitLab…. même pas c’est sans déjà la cas ! Il ne faut même pas chercher à modifier la configuration dz Gitlab pour rendre le endpoint visible de l’exterieur du conteneur, GitLab fournit déjà une url avec un token secret pour accéder aux metriques. La contrepartie de cette facilité est que le endpoint prometheus du GitLab sera accédé via une url externe ie celle du gitlab !

Voilà pourquoi ma configuration de Prometheus ne peut pas être entièrement dans l’image Prometheus car le token secret dépend de l’instance GitLab c’est donc applicatif et pas structurel. De plus ce secret ne doit pas aller dans le code source que je veux public !

Métriques systèmes

Sur le schéma précédent on voit en vers Prometheus servant à lui lui-même de endpoint et en bleu la liaison avec GitLab.

Une fonction de munin, qui est sans doute la première, est le monitoring des constantes du système (mémoire, cpu, disque ….). Avec prometheus, ce sont les node exporter installé sur chaque machine qui vont exposer ses métriques sous forme de endpoint Prometheus. J’installe donc ces node exporter sur chacune de mes VM, bien entendu dans leur version dockerisée what else ? Le source trivial de cette manipulation se trouve ici https://gitlab.bressure.net/docker/applications/prom-node

Métriques docker

L’application docker, le démon docker, est elle-même une application intéressante à surveiller. Avec munin j’utilisais une sonde qui remontait l’utilisation cpu et mémoire de chaque conteneur. Pour Prometheus j’ai testé 2 solutions.

Le démon docker lui-même peut exporter des métriques prometheus. Il faut activer cette fonction expérimentale dans le fichier /etc/docker/daemon.json

{
"metrics-addr" : "IP_HOTE:9323", "experimental" : true
}

L’autre solution s’appelle cAdvisor une image docker dont google est à l’origine et qui expose un plus grand nombre de métrique que celles exposées par le démon docker lui-même. Comment ce fait-il ? En montant les répertoires systèmes de l’hôte dans le conteneur cAdvisor:

sudo docker run \ --volume=/:/rootfs:ro \ --volume=/var/run:/var/run:ro \ --volume=/sys:/sys:ro \ --volume=/var/lib/docker/:/var/lib/docker:ro \ --volume=/dev/disk/:/dev/disk:ro \ --publish=8080:8080 \ --detach=true \ --name=cadvisor \ gcr.io/google-containers/cadvisor:latest

Node exporter, cAdvisor, démon docker

Le trio gagnant des outils d’export de métriques semble être:

  • Le démon docker lui-même mais exporte seulement les données essentielles et ce n’est pas une fonctionnalité pérenne
  • cAdvisor qui est beaucoup plus complet mais demande un accès également complet au système de fichiers hôte en lecture certes mais….
  • Le node exporter de prometheus moins riche que cAdvisor mais avec une possibilité d’extension
Trio gagnant des sondes à métriques

On voit que les sondes node exporter de prometheus et cAdvisor de google, sont des composants réutilisables et installables en bloc sur mes différents environnements: infra, staging et production. Je vais donc avantageusement les regrouper dans un projet docker compose prom-node. Finalement l’architecture de monitoring devient la suivante:

Bilan

Avec quelque configuration qui se résument à assembler des conteneurs entre eux, j’arrive à avoir une solution uniquement visuelle pour l’instant, de surveillance de mon infra. Je m’appuie pour cela sur:

  1. une image de Prométheus avec une configuration taillée sur mesure. Ce point est facultatif et je pouvais me contenter de l’image originale https://gitlab.bressure.net/docker/services/prometheus
  2. une application combinant Prometheus pour la collecte et Grafana pour la restitution https://gitlab.bressure.net/docker/applications/monitoring
  3. Des sondes sous forme de conteneur qui expose les métriques pour Prometheus https://gitlab.bressure.net/docker/applications/monitoring
  4. Un configuration des démons docker pour exposer des métriques Prometheus. Attention fonctionnalité expérimentale selon docker.

La prochaine étape sera d’ajouter des alertes afin de reproduire toutes les fonctions de munin.

Catégories
Application Paramétrage

Mise à jour owncloud dockerisé et plugin non supporté

J’ai voulu mettre à jour mon instance de owncloud dockerisée pour utiliser la derniere version. Pour cela il me suffit de changer la version qui se trouve dans un fichier .env comme on le voit ici https://gitlab.bressure.net/docker/applications/owncloud

N’ayant pas lu les instructions concernant les plugins (appelés application dans Owncloud), certains ne pouvaient pas être mis à jour lors du démarrage de la nouvelle version de Owncloud.

Log du conteneur owncloud

docker logs owncloud_owncloud_1

Ce dernier restait alors en mode maintenance et du point de vue de docker le conteneur restait dans l’état en démarrage rendant impossible toute connexion via un docker exec -it owncloud_owncloud_1 /bin/bash. Il est alors impossible d’utiliser la commande occ pour administrer owncloud en commande php.

Comme le service (conteneur) de base de données fonctionnait bien, j’ai dû passer par des requêtes SQL pour désactiver les applications (plugin) problématiques.

Connexion au conteneur de base de données

docker exec -it owncloud_db_1 /bin/bash

Connexion au service de base de données

mysql -u root -p

Modification de la configuration Owncloud par SQL

update oc_appconfig set configvalue="no" where appid="files_videoplayer" and configkey="enabled";
update oc_appconfig set configvalue="no" where appid="drawio" and configkey="enabled";

Reinstallation de drawio

Ce plugin m’est utile pour faire des diagramme par le web sur mon cloud privé. Comme la version de owncloud est maintrnant 10.3.2.2 il faut modifier les specfication du plugin drawio pour pouvoir l’activer. Il « suffit » de modifier le fichier appinfo/info.xml mais la signature du plugin n’alors plus vérifié. Il faudra attendre que le mainteneur du plugin drawio fasse une livraison officielle.

Catégories
Uncategorized

Monitorer ses applications avec Prometheus et Grafana

Jusque là j’utilisais le bien connu munin pour suivre l’état de mes serveurs et services. Cet outil assez ancien se positionne bien en tant que surveillance système et pour des alertes en cas de détection de valeurs anormales. Étant depuis plusieurs mois passé à une infra dockerisé, mon outils de monitoring était encore en natif. De plus son ihm n’était plus dans l’air du temps et il ne permet pas de faire des requêtes arbitraires sur l’historique des valeurs voire de d’agréger des indicateurs comme ce que ElasticSearch/Logstash/Kibana, ELK le poids lourd de la catégorie, permet.

Alternative légère

Avant de se lancer dans ELK plus fait pour de l’analyse de log que le suivi d’indicateur métriques, je souhaitais me limiter à une solution plus moderne que munin mais également peu gourmande en ressources tout en offrant la monitoring système de base de munin: les indicateurs mémoire, cpu, système de fichiers etc.

Prometheus est la solution mise en avant dans GitLab pour surveiller les performances des applications dans leurs environnement d’exécution. Un tour sur le site de Prometheus permet de voir que son architecture est bien au goût du jour c’est-à-dire à la sauce épicée des conteneurs:

On remarque le brique Grafana qui permet d’ajouter des capacités de visualisation et d’export des données en plus de l’interface web basique de Prometheus. Je vais également l’utiliser pour avoir de jolis graphiques dans l’air du temps.

Prometheus, Grafana, Docker

Comme je suis dans un univers dockerisé maintenant, je vais donc installer le couple Prometheus et Grafana en version conteneurisée. Dans un premier temps pour me familiariser avec ces outils, je vais installer la solution pour monitorer mes démons docker et les indicateurs systèmes de mes machines.

Mais avant tout, fidèle au principe de s’appliquer à soit même ses précepte, je commence par créer un projet dans mon GitLab et sera destiné à mettre en place mon application de monitoring. Ainsi toute ma phase de mise au point sera sous IC/DC comme dans un monde idéal.

https://gitlab.bressure.net/docker/applications/monitoring

La suite de mes aventures avec Prometheus, Grafana et docker dans le prochain billet… pour très bientôt.

Catégories
Uncategorized

Intégration continue la solution au syndrome du développeur

Ça marche chez moi

Tout responsable d’équipe de développement ou participant à une réunion production/développeur a été confronté au cas du logiciel fonctionnant sur le poste du développeur et pas ailleurs. Le développeur assure de bonne fois que ça marche chez lui et en production l’utilisateur constate le contraire. Les causes d’une telle situation sont entre autres les jeux d’essais et la configuration du poste du développeur.

Mais ça marche chez moi

Dans ce dernier cas la solution est l’intégration continue qui s’assure que le logiciel se construit sur une machine vierge de tout paramétrage qui ne serait pas inclus dans le projet lui-même.

Docker

L’utilisation de docker pour empaqueter le logiciel nous assure de son côté que toute la configuration est portable. En réalité la configuration est faite une fois pour toute et embarquée dans l’image. J’entends par configuration la plomberie de paramétrage des composants et la configuration système.

Il est tentant alors pour le développeur de produire une image comme livrable. Cela pose hélas des problèmes majeurs.

Tout d’abord le poste du developpeur devient le référentiel de construction. Or le developpeur sous pression des délais utilise une méthode qui a fait ses preuves dite  » Larache ». Si bien que la configuration complète qui fait tomber en marche la construction n’est pas connue. Il faudrait donc pour bien faire également fournir le poste du développeur comme source du projet !

Docker un simple outil de construction

L’utilisation de docker comme commande de construction ne dédouane pas de passer par l’intégration continue afin se s’assurer de la

Répetablité de la construction

Par ailleurs comme le test d’execution a été fait sur le poste du developpeur, il y également le biais que l’exécution tire partie d’une spécificité du poste du développeur. En effet c’est la même installation de docker qui a fait la construction qui va faire l’exécution sur le poste du developpeur.

Ainsi une même image construite en dehors de l’intégration continue ne fonctionnera peut-être pas ailleurs que sur le poste du développeur !

Integration continue un prérequis

L’integration continue est un garant de la qualité du logiciel en assurant la répetablité de la construction par la seule l’utilisation des sources obligeant ainsi à décrire explicitement toute la configuration permettant de faire cette construction.

Avec GitLab cela est poussé à l’extrême car GitLab encourage l’utilisation docker pour la construction: la commande de construction est elle-même conteneurisée ce qui assure que la configuration de docker est explicitement décrite. La construction est ainsi répétable.

Une erreur est de croire que docker permet de se passer de l’IC. Docker n’est qu’un outils de construction au même titre que maven. Cependant la prise en compte de l’IC dans le processus de création du logiciel se heurte plus à l’acceptation d’une méthodologie qu’autre chose.

Aussi le syndrôme du développeur ca marche chez moi traduit plutôt le mode de développement solitaire où les sources ne sont pas partagées (absence Git commun).

Une autre erreur est je crois de confondre DevOps avec le développement en production. Dans une informatique non indusrielle le developpeur a le pouvoir de modifier directement en production. Poste du developpeur ou poste de production c’est la même chose. Dans une informatique industrialisée ce n’est pas possible. Dans ce cas il faut faire un lien entre le poste du développeur et la machine de production.

L’intégration continue est ce lien !

Du bon usage de l’IC

Ce qui n’est pas sous IC n’existe pas

Je crois que tout développement qui a pour vocation a devenir indistriel, doit commencer par l’IC. Si le développement est purement un POC local, la mise en place de l’IC est un surcoût qui ne se justifie pas.

En revanche si le projet a vocation à entrer dans un processus industriel il faut prendre le temps de mettre en place l’IC avant tout développement. Il y a pour cela les raisons suivantes:

  • Empêcher le source de s’appuyer sur des spécificités du poste du développeur
  • Empêcher le processus de construction et d’exécution de s’appuyer des spécificités du poste du développement
  • Empêcher l’amalgame des sources ayant des objectifs différents et permettre une structuration correcte du projet dès le départ

Ce dernier point mérite une attention particulière car si la mise sous IC et la modularisation du projet intervient tardivement, le travail de séparation peut être difficile car l’imbrication de la construction a des effets de bord qui font tomber en marche mais qui ne passent pas l’IC. Cela freine l’adoption de l’IC continue auprès des équipes de développement qui verront surtout le surcoût de refactoring du projet pour l’intégrer à l’IC.

Conclusion

L’intégration continue et son évolution en déploiement continue sont des bonnes pratiques dont la pertinence n’est pas à démontrer. Leur mise en place doit être un prérequis avant tout développement.