Catégorie : Systeme

Les nouveautés de Glances 2.3

Auteur de l’article Par nicolargo
Date de l’article 02/02/2015
14 commentaires sur Les nouveautés de Glances 2.3

Glances vient de sortir en version 2.3. Cette version propose un grand nombre de nouveautés que nous allons détailler dans cet article. Pour installer ou mettre à jour Glances dans cette dernière version, je vous conseille la lecture de la documentation officielle.

Attachez vos ceintures, c’est parti pour le tour d’horizon…

Le plugin Docker

Ce plugin est développé autour de la librairie Docker-Py et de fonctions maison pour permettre à l’utilisateur de superviser les conteneurs lancés sur la machine à superviser. Le fonctionnement est relativement simple. Glances va identifier, grâce à la librairie Docker-Py, la liste des conteneurs comme le ferait la commande ‘docker ps’. Pour chacun des conteneurs, il va ensuite aller chercher dans les répertoires /sys/fs/cgroup/cpuacct/docker et /sys/fs/cgroup/memory/docker les informations concernant leurs occupations CPU et mémoire.

Le plgin ne s’affiche que si la librairie Docker-Py est installé et si au moins un conteneur est lancé. Le résultat final est le suivant dans un interface console:

Le plugin Docker est également dans l’interface Web de Glances.

Le plugin RAID

La supervision de l’état des contrôleurs RAID des machines est un point critique. Ainsi, cette nouvelle version de Glances inclus un nouveau plugin permettant de remplir cette tâche. Ce plugin ce base sur la librairie PyMdstat que j’ai créé pour l’occasion et qui est utilisable dans d’autres applications.

Le plugin ne s’affiche que si la librairie PyMdstat est installé et qu’un contrôleur RAID est détecté. Par exemple, sur un serveur avec un contrôleur RAID 5 avec 5 disques en bon état, Glances va afficher:

Par contre, dans le cas d’un contrôleur RAID 5 avec 6 disques et l’un de ces disques dans un état pas terrible:

Enfin, avec un contrôleur RAID 5 désactivé:

Le plugin RAID étant un extension du plugin FileSystem, il s’affichera, si nécessaire à gauche dans l’interface console/terminal ou Web de Glances.

Modules d’exports vers Statsd, InfluxDB et CSV

Une refonte complète du module d’exportation des données vers des briques externes a été codé dans cette nouvelle version. Ainsi, il est possible nativement, d’exporter les statistiques remontées par Glances dans un fichier à plat au format CSV et/ou dans des bases de données de type temps/valeurs comme Statsd ou InfluxDB.

Commençons par l’export CSV que l’on peut choisir en mode standalone, pour récupérer les statistiques de notre machine locale ou en mode client pour une machine distante. On doit utiliser l’option suivante:

glances --export-csv /tmp/glances.csv

On se retrouve avec un fichier /tmp/glances.csv qui va contenir toutes les stats disponibles (hormis les processus) parfaitement exploitable dans une bête feuille Excel ou via un script Python avec la fameuse librairie Panda:

load_cpucore,load_min1,load_min5,load_min15,memswap_used,memswap_percent,memswap_free,memswap_sout,memswap_total,memswap_sin,diskio_sda2_key,diskio_sda2_time_since_update,diskio_sda2_read_bytes,diskio_sda2_write_bytes,diskio_sda2_disk_name,diskio_sda3_key,diskio_sda3_time_since_update,diskio_sda3_read_bytes,diskio_sda3_write_bytes,diskio_sda3_disk_name,diskio_sda1_key,diskio_sda1_time_since_update,diskio_sda1_read_bytes,diskio_sda1_write_bytes,diskio_sda1_disk_name,fs_/_mnt_point,fs_/_used,fs_/_percent,fs_/_free,fs_/_device_name,fs_/_fs_type,fs_/_key,fs_/_size,fs_/boot/efi_mnt_point,fs_/boot/efi_used,fs_/boot/efi_percent,fs_/boot/efi_free,fs_/boot/efi_device_name,fs_/boot/efi_fs_type,fs_/boot/efi_key,fs_/boot/efi_size,mem_available,mem_used,mem_cached,mem_percent,mem_free,mem_inactive,mem_active,mem_total,mem_buffers,network_lo_tx,network_lo_cumulative_rx,network_lo_rx,network_lo_cumulative_cx,network_lo_time_since_update,network_lo_cx,network_lo_cumulative_tx,network_lo_key,network_lo_interface_name,network_docker0_tx,network_docker0_cumulative_rx,network_docker0_rx,network_docker0_cumulative_cx,network_docker0_time_since_update,network_docker0_cx,network_docker0_cumulative_tx,network_docker0_key,network_docker0_interface_name,network_wlan0_tx,network_wlan0_cumulative_rx,network_wlan0_rx,network_wlan0_cumulative_cx,network_wlan0_time_since_update,network_wlan0_cx,network_wlan0_cumulative_tx,network_wlan0_key,network_wlan0_interface_name,processcount_running,processcount_total,processcount_thread,processcount_sleeping,cpu_softirq,cpu_iowait,cpu_system,cpu_guest,cpu_idle,cpu_user,cpu_guest_nice,cpu_irq,cpu_total,cpu_steal,cpu_nice
4,0.18,0.2,0.23,0,0.0,8490315776,0,8490315776,0,disk_name,1,933888,413696,sda2,disk_name,1,0,0,sda3,disk_name,1,0,0,sda1,/,145566900224,59.9,97453883392,/dev/sda2,ext4,mnt_point,243020783616,/boot/efi,3510272,0.7,532295680,/dev/sda1,vfat,mnt_point,535805952,6620909568,1652637696,1202855936,20.0,6620909568,1018507264,1797070848,8273547264,204804096,200,356764,200,713528,1,400,356764,interface_name,lo,0,0,0,0,1,0,0,interface_name,docker0,0,21354827,0,26332988,1,0,4978161,interface_name,wlan0,1,200,477,199,0.0,2.2,13.3,0.0,33.3,51.1,0.0,0.0,66.7,0.0,0.0
4,0.17,0.2,0.23,disk_name,3.128045082092285,36864,1003520,sda2,disk_name,3.128045082092285,0,0,sda3,disk_name,3.128045082092285,0,0,sda1,/,145566859264,59.9,97453924352,/dev/sda2,ext4,mnt_point,243020783616,/boot/efi,3510272,0.7,532295680,/dev/sda1,vfat,mnt_point,535805952,6627594240,1645953024,1202880512,19.9,6627594240,1018691584,1789747200,8273547264,204951552,1260,358024,1260,716048,3.131376028060913,2520,358024,interface_name,lo,0,0,0,0,3.131376028060913,0,0,interface_name,docker0,10241,21367420,12593,26355822,3.131376028060913,22834,4988402,interface_name,wlan0,1,200,477,199,0.1,0.5,0.5,0.0,95.3,3.6,0.0,0.0,4.7,0.0,0.0
4,0.17,0.2,0.23,0,0.0,8490315776,0,8490315776,0,disk_name,3.1066739559173584,4096,1376256,sda2,disk_name,3.1066739559173584,0,0,sda3,disk_name,3.1066739559173584,0,0,sda1,/,145566867456,59.9,97453916160,/dev/sda2,ext4,mnt_point,243020783616,/boot/efi,3510272,0.7,532295680,/dev/sda1,vfat,mnt_point,535805952,6626533376,1647013888,1202917376,19.9,6626533376,1018888192,1790480384,8273547264,205172736,509,358533,509,717066,3.1057980060577393,1018,358533,interface_name,lo,0,0,0,0,3.1057980060577393,0,0,interface_name,docker0,4009,21383069,15649,26375480,3.1057980060577393,19658,4992411,interface_name,wlan0,1,199,476,198,0.0,0.6,0.6,0.0,93.9,4.9,0.0,0.0,6.1,0.0,0.0

Plus fun et moderne, l’export vers des bases de données NoSQL de type temps/valeurs. Pour l’instant, Glances supporte les implémentations Statsd et InfluxDB. Par exemple, pour exporter les statistiques vers un serveur InfluxDB, il faut dans un premier temps éditer le fichier de configuration de Glances.

Note: pour connaître l’emplacement du fichier de configuration de Glances utilisé, il suffit de consulter le fichier de log (par défaut /tmp/glances.log). Il est aussi possible de forcer l’utilisation d’un fichier de configuration spécifique avec l’option -C.

Par exemple, pour utiliser un serveur InfluxDB qui tourne sur la machine locale (localhost), sur le port TCP par défaut (8086) avec l’utilisateur/password (root/root) et la base de donnée nommée glances, il suffit d’ajouter la section suivante:

[influxdb]
host=localhost
port=8086
user=root
password=root
db=glances

On lance ensuite Glances avec l’option:

glances --export-influxdb

Et magie de la technologie moderne:

Déclenchement d’actions sur alerte

Réclamée depuis un certain temps par les utilisateurs, cette nouvelle fonction permet de déclencher des alertes pour n’importe quelle alarme levée par Glances. Par exemple, si vous voulez être prévenu par mail quand l’espace disque disponible devient critique, il suffit d’éditer le fichier de configuration de la manière suivante:

[fs]
careful=20
warning=70
critical=90
critical_action=mail -s "Disk almost full..." user@domain.com

Encore mieux, Glances supporte les mustaches {{…}} et permet donc d’utiliser les variables disponibles dans les API pour personnaliser les actions. Ainsi, pour préciser le nom du disque et le pourcentage utilisé, il suffit de changer la configuration de la manière suivante:

[fs]
careful=20
warning=70
critical=90
critical_action=mail -s "Disk {{mnt_point}} almost full: {{percent}}%" user@domain.com

Note: cette fonction se base sur la librairie Pystache.

Support des mots de passe dans le mode browser

La grande nouveauté de la version précédente de Glances (la 2.2) était l’apparition du mode browser permettant à partir d’un client unique de superviser plusieurs serveurs. Il est maintenant possible d’accéder à des serveurs protégés par des mots de passes.

Note: il faut obligatoirement que le client (celui qui lance –browser) et les serveurs (-s) soient à minima dans la version 2.3 pour que cette fonction marche correctement.

Amélioration de l’interface Web

Enfin pour finir en beauté ce panorama des nouveautés de cette version 2.3 je voulais signaler le remarquable travail effectué par Nicolas Hart sur la refonte de l’interface Web avec notamment un optimisation de l’affichage (« responsive design »):

Nicolas travaille en ce moment avec Sylvain Mouquet sur la refonte complète de l’interface Web pour passer sur des technologies dynamiques (utilisation d’AngularJS coté client). Cela devrait normalement arriver dans la prochaine version (Glances 2.4).

J’espère que cette version de Glances répondra à vos besoins. N’hésitez pas à laisser un petit message pour partager avec nous comment vous utilisez Glances au quotidien et également proposer des améliorations.

Étiquettes 2.3, glances

Blog Open-source Systeme vitualisation

Varnish, NGinx et PHP-FPM sous Docker

Auteur de l’article Par nicolargo
Date de l’article 08/10/2014
31 commentaires sur Varnish, NGinx et PHP-FPM sous Docker

Suite au précédent article d’introduction sur Docker (que je vous conseille de lire avant de dévorer cet article), je me suis penché sur le problème suivant: comment créer et maintenir une « stack web » de compétition (Varnish + Nginx + PHP-FPM) basée sur cette technologie de virtualisation par conteneurs.

Quel est l’objectif ?

Nous allons donc, dans ce billet, détailler l’installation et la mise à jour d’une infrastructure, basée sur Docker, qui pourra servir à l’hébergement d’un site personnel, d’un blog ou bien du site d’une PME:

la base de donnée sera portée par l’implémentation libre de MySQL, c’est à dire MariaDB (nous aborderons cette partie dans un deuxième billet)
pour le moteur PHP, j’utilise PHP-FPM
pour le serveur Web, je ne jure que par Nginx (léger, bien documenté)
afin pour tenir la charge (notamment si vous utilisé un moteur de blog de type WordPress, j’utilise le système de cache Varnish)

Dans le reste de de l’article, on appellera machine hôte, la machine qui hébergera Docker (lire ce billet pour la procédure d’installation de Docker).

Cette dernière peut être un PC portable ou bien un serveur dédié. C’est un des avantages de la virtualisation par conteneurs. Une fois validé sur une machine , on est sûr que le conteneur fonctionnera de manière identique sur une autre installation de Docker. Ainsi pour la rédaction de ce billet, j’ai utiisé mon PC portable sous Ubuntu 14.04 et un (superbe) VPS mis à disposition par les amis de Web4All sous Debian 7 (merci Aurélien !).

Pour respecter la philosophie de la virtualisation par conteneur, chaque brique sera mise dans un conteneur dédié. On aura ainsi 4 conteneurs sur une machine hôte.

Chaque conteneur communiquera avec les autres selon le schéma ci-dessus.

Les données (data base DB, page statique du site et cache) seront stockées sur la machine hôte.

Création des conteneurs

Il y a deux méthodes pour choisie les images qui seront à la base de nos conteneurs.

La première, la plus noble mais la plus longue à mettre en œuvre, est d’écrire soit même les DockersFiles permettant l’installation et l’exécution des logiciels. On garde ainsi le contrôle de notre infrastructure et la possibilité de configurer finement les applications (notamment au niveau des options de compilation). Dans ce cas, et pour respecter les « best practices » de Docker, il faudra, pour chaque conteneur, repartir d’une image de base de type Debian sur laquelle on viendra installer les briques logicielles de notre LEMP.

La seconde, que j’ai choisi dans ce billet (pas parce-que je suis un gros fainéant mais par manque de temps), est de partir des images disponibles sur la registry officielle de Docker. On gagne ainsi en rapidité de mise en place. Les composants de notre web stack étant très populaires, on trouve des images supportées et maintenues par la communauté Docker (notamment NGinx). Cependant, on constatera une trop grande diversité dans les systèmes de bases (Ubuntu, CentOS…).

Avant de commencer, nous allons créer un répertoire sur la machine hôte qui hébergera les fichiers utiles à notre infrastructure:

mkdir -p $HOME/data/webstack/conf $HOME/data/webstack/www

Le conteneur NGinx

Pierre angulaire de notre « web stack« , le serveur NGinx est très présent sur la « registry » officielle de Docker (plus de 900 images disponibles au moment de l’écriture de ce billet). J’ai choisi d’utiliser l’image officielle proposé par Docker (elle est conçue à partir de cete DockerFile).

On commence par télécharger les images NGinx officielle:

docker pull nginx

Puis on vérifie que les images sont visibles sur notre machine hôte (NGinx version 1.7.5 au moment de l’écriture de cet article):

$ docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
nginx 1.7.5 d2d79aebd368 7 days ago 100.2 MB
nginx latest d2d79aebd368 7 days ago 100.2 MB
nginx 1 d2d79aebd368 7 days ago 100.2 MB
nginx 1.7 d2d79aebd368 7 days ago 100.2 MB

On lance le conteneur:

$ docker run --name webstack_nginx_1 -v $HOME/data/webstack/www:/usr/share/nginx/html:ro -p 8080:80 -d nginx
f7baa81cebdc8799947327e6470a74ae73fe73bb0eb644ecfb2951847c40154b

Notre conteneur a le doux nom de webstack_nginx_1, il redirige le port TCP/8080 de notre hôte vers le port TCP/80 du conteneur (port par défaut de NGinx) et il assigne, en lecture seule, le volume /usr/share/nginx/html au répertoire hôte $HOME/data/www (à adapter à votre configuration). Pour résumer, toutes les pages HTML disponible dans le répertoire /home/nicolargo/data/www, seront accessible via le port HTTP/8080 de votre machine locale.

On ajoute une page HTML statique de test et une autre pour le test PHP que l’on utilisera dans le chapitre suivant:

echo "My first page" > $HOME/data/webstack/www/index.html
echo "<?php phpinfo(); ?>" > $HOME/data/webstack/www/phpinfo.php

Puis on valide que le serveur NGinx est bien opérationnel:

$ curl http://localhost:8080
My first page

Ou directement depuis votre navigateur Web préféré:

L’image NGinx utilisée redirige les fichiers de log (access.log et error.log vert la sortie standard). Il est donc possible de visualiser les accès à son serveur Web en « attachant » le terminal de notre hôte à la sortie standard du conteneur:

$ docker attach --sig-proxy=false webstack_nginx_1
2014/10/08 13:47:59 [error] 9#0: *1 open() "/usr/share/nginx/html/inconnu.html" failed (2: No such file or directory), client: 172.17.0.103, server: localhost, request: "GET /inconnu.html HTTP/1.1", host: "localhost"
172.17.0.103 - - [08/Oct/2014:13:47:59 +0000] "GET /inconnu.html HTTP/1.1" 404 168 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0" "172.17.42.1"

Note: bien penser à mettre l’option –sig-proxy=true sous peine de stopper le conteneur lors de l’appuie sur ^C. Je vous conseille de créer un alias dans votre shell.

Le conteneur PHP-FPM

Pour le moteur PHP, il n’existe pas d’image officielle. Mon choix s’est donc porté vers l’utilisation du repository de Jprjr basée sur une installation de PHP-FPM sous ArchLinux avec pas mal d’extensions par défaut (voir la liste dans le DockerFile).

On télécharge la dernière version des images avec:

docker pull jprjr/php-fpm

On obtient bien:

$ docker images | grep jprjr
jprjr/php-fpm          latest                 d40698b35f83        6 weeks ago         347.8 MB

On lance le conteneur:

docker run --name webstack_php_01 -p 9000:9000 -d jprjr/php-fpm

Le conteneur est configuré par défaut pour écouter sur le port TCP/9000.

Très bien, on doit donc avoir le serveur NGinx et le moteur PHP-FPM qui sont lancés dans deux conteneurs différents. On va vérifier cela avec la commande:

$ docker ps
CONTAINER ID        IMAGE                  COMMAND                CREATED             STATUS              PORTS                           NAMES
e9dd04e7ceec        jprjr/php-fpm:latest   "php-fpm -F"           13 seconds ago      Up 12 seconds       0.0.0.0:9000->9000/tcp          webstack_php_01        
f7baa81cebdc        nginx:1                "nginx -g 'daemon of   46 minutes ago      Up 46 minutes       443/tcp, 0.0.0.0:8080->80/tcp   webstack_nginx_01

Faire communiquer les deux conteneurs (NGinx & PHP-FPM)

Tout cela est très beau mais les deux conteneurs ne se connaissent pas. Il faut, pour cela, configurer le serveur NGinx pour utiliser le moteur PHP et donc que le conteneur NGinx connaisse l’adresse IP du conteneur PHP-FPM.

Heureusement, Docker propose l’option –link permettant de répondre à ce besoin. Cette option, à utiliser au moment du lancement du conteneur, va créer dynamiquement des entrées dans le fichier host et dans des variables d’environnement du conteneur, permettant ainsi à ce dernier de connaître comment joindre ses congénères.

Par exemple:

$ docker run -it -v --link webstack_php_01:webstack_php nginx /bin/bash

root@2ce3cdb8a767:/# cat /etc/hosts | grep webstack
172.17.0.5	webstack-php

root@d9ff8a80f12a:/# env | grep WEBSTACK
WEBSTACK_PHP_PORT=tcp://172.17.0.5:9000
WEBSTACK_PHP_PORT_9000_TCP=tcp://172.17.0.5:9000
WEBSTACK_PHP_PORT_9000_TCP_ADDR=172.17.0.5
WEBSTACK_PHP_PORT_9000_TCP_PORT=9000
WEBSTACK_PHP_NAME=/webstack_nginx/webstack_php
WEBSTACK_PHP_PORT_9000_TCP_PROTO=tcp

root@2ce3cdb8a767:/# exit
exit

$ docker rm `docker ps -lq`

Maintenant que l’on sait comment faire communiquer les deux conteneurs, il suffit de configurer NGinx pour rediriger les fichier .PHP vers le moteur PHP-FPM du second conteneur.

Pour cela, plusieurs solutions sont là encore possibles. La plus simple est de surcharger la configuration NGinx par défaut(nginx.conf). Sur notre hôte, nous allons créer le fichier de configuration en question:

$ docker webstack_nginx_01/etc/nginx/nginx.conf $HOME/data/webstack/conf/nginx.conf

$ vi $HOME/data/webstack/conf/nginx.conf

daemon off;

user  nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    #gzip  on;

    server {
        listen       80;
        server_name  localhost;

        location / {
            root   /usr/share/nginx/html;
            index  index.html index.htm;
        }

        #error_page  404              /404.html;

        # redirect server error pages to the static page /50x.html
        #
        #error_page   500 502 503 504  /50x.html;
        #location = /50x.html {
        #    root   /usr/share/nginx/html;
        #}

        # Pass PHP scripts to PHP-FPM
        location ~* \.php$ {
            fastcgi_index   index.php;
            fastcgi_pass    webstack_php:9000;
            #fastcgi_pass   unix:/var/run/php-fpm/php-fpm.sock;
            include         fastcgi_params;
            fastcgi_param   SCRIPT_FILENAME    /srv/http$fastcgi_script_name;
            fastcgi_param   SCRIPT_NAME        $fastcgi_script_name;
        }    

        # deny access to .htaccess files, if Apache's document root
        # concurs with nginx's one
        location ~ /\.ht {
            deny  all;
        }
    }

}

Note:

« fastcgi_pass webstack_php:9000; » qui utilise donc le hostname présent dans le fichier host
« fastcgi_param SCRIPT_FILENAME /srv/http$fastcgi_script_name; » qui va permettre à PHP-FPM d’aller chercher les pages PHP dans le même volume que le serveur Nginx mais assigné au répertoire /srv/http du conteneur (c’est la configuration par défaut de notre conteneur PHP-FPM)

Revenons à notre cas. Nous souhaitons que le conteneur NGinx (nommé webstack_nginx_01) connaisse le conteneur PHP (webstack_php_01).

On commence donc par supprimer les deux conteneurs existant:

docker stop webstack_php_01 && docker rm webstack_php_01
docker stop webstack_nginx_01 && docker rm webstack_nginx_01

puis de les recréer avec l’option –link (pour le conteneur NGinx qui va initier la connexion TCP vers le moteur PHP-FPM), la nouvelle configuration de NGinx et les volumes pointant sur notre page HTML et PHP:

docker run --name webstack_php_01 -v $HOME/data/webstack/www:/srv/http:ro -p 9000:9000 -d jprjr/php-fpm
docker run --name webstack_nginx_01 -v $HOME/data/webstack/www:/usr/share/nginx/html:ro -v $HOME/data/webstack/conf/nginx.conf:/nginx.conf:ro -p 8080:80 --link webstack_php_01:webstack_php -d nginx nginx -c /nginx.conf

On teste:

$ curl http://localhost:8080/index.html
My first page

$ curl http://localhost:8080/phpinfo.php
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head>
<style type="text/css">
...

Bingo !

A ce stade, nous avons donc deux conteneurs communiquant entre eux pour nous offrir un serveur Web compatible avec le langage PHP.

Le conteneur Varnish en frontal

Si vous suivez ce blog, vous savez tout le bien que je pense de l’utilisation du cache Varnish pour absorber la montée en charge des sites Web (sinon, vous pouvez effectuer une session de rattrapage en lisant ces articles). Nous allons donc créer un nouveau conteneur qui exposera le port TCP/80 et qui mettra en cache les pages construites par le serveur NGinx (qui est en écoute sur le port TCP/8080 si vous avez bien suivi…).

Nous allons utiliser l’image Varnish mise à disposition et maintenue par le contributeur jacksoncage.

On commence par la récupérer:

docker pull jacksoncage/varnish

Puis on vérifie qu’elle est bien disponible sur notre hôte:

$ docker images | grep jacksoncage
jacksoncage/varnish    latest                 46f0ea7021c1        8 months ago        472.2 MB

Comme il est indiqué dans la documentation de l’image, il faut écrire le fichier de configuration par défaut de Varnish (le fichier default.vcl):

$ vi $HOME/data/webstack/conf/default.vcl

backend default {
    .host = "webstack_nginx";
    .port = "80";
}

On demande donc à Varnish d’aller directement communiquer avec le conteneur NGinx via l’adresse IP webstack-nginx (rappelez-vous que le hostname est créé dynamiquement par Docker au démarrage du conteneur avec l’option –link) et sur le port TCP 80 (attention, ce n’est pas le port TCP/8080 exposé par Docker sur notre hôte mais celui vraiment utilisé par NGinx dans le conteneur).

A noter que cette configuration est à compléter, notamment si vous voulez héberger un blog sous WordPress (des exemples de fichiers de configuration sont disponibles ici). Attentinon, ces exemples sont pour Varnish 4.0, donc à adapter si la version du conteneur jacksoncage/varnish n’est pas en ligne.

Puis lancer le conteneur avec les options suivantes:

docker run --name webstack_varnish_01 -v $HOME/data/webstack/conf/default.vcl:/etc/varnish/default.vcl:ro -p 80:80 --link webstack_nginx_01:webstack_nginx -d jacksoncage/varnish

On redirige le port 80 du conteneur vers le port 80 de votre hôte (il ne doit bien sûr pas y avoir de serveur Web déjà en écoute sur ce port) puis on fait le lien entre le conteneur Varnish et le conteneur NGinx.

On vérifie que nos trois conteneurs sont lancés:

$ docker ps
CONTAINER ID        IMAGE                        COMMAND                CREATED             STATUS              PORTS                           NAMES
a1b853f1a38e        jacksoncage/varnish:latest   "/start"               4 seconds ago       Up 3 seconds        0.0.0.0:80->80/tcp              webstack_varnish_01                                                                        
c2bd3138864a        nginx:1                      "nginx -c /nginx.con   54 minutes ago      Up 54 minutes       443/tcp, 0.0.0.0:8080->80/tcp   webstack_nginx_01,webstack_varnish_01/webstack-nginx                                          
7cc072bb0df2        jprjr/php-fpm:latest         "php-fpm -F"           54 minutes ago      Up 54 minutes       0.0.0.0:9000->9000/tcp          ...

Et on teste notre serveur de cache Varnish:

$ curl -I http://localhost/index.html

HTTP/1.1 200 OK
Server: nginx/1.7.5
Content-Type: text/html
Last-Modified: Sat, 04 Oct 2014 16:30:45 GMT
ETag: "543020b5-15"
Content-Length: 21
Accept-Ranges: bytes
Date: Sun, 05 Oct 2014 15:26:47 GMT
X-Varnish: 320901887 320901884
Age: 46
Via: 1.1 varnish
Connection: keep-aliv

Le « Via: 1.1 varnish » confirme que notre infra commence à avoir de la gueule :).

En aparté, on peut d’ailleurs juger de la puissance de Varnish en lançant un simple bench tout d’abord directement sur le serveur NGinx (donc en baille-passant Varnish):

$ ab -t 30 -c 5 http://localhost:8080/

Complete requests:      7107
Requests per second:    232.24 [#/sec] (mean)
Time per request:       21.529 [ms] (mean)
Time per request:       4.306 [ms] (mean, across all concurrent requests)

Puis en faisant le même test en passant par Varnish:

$ ab -t 30 -c 5 http://localhost/

Complete requests:      50000
Requests per second:    3694.60 [#/sec] (mean)
Time per request:       1.353 [ms] (mean)
Time per request:       0.271 [ms] (mean, across all concurrent requests)

Les chiffres parlent d’eux même…

Gestion des conteneurs

Un simple pull sur les images préalablement téléchargé s’occupera de leurs mises à jour:

docker pull nginx
docker pull jprjr/php-fpm
docker pull jacksoncage/varnish

Comme l’on reconstruit notre infrastructure à partir de ces images, il suffira ensuite d’arrêter et de relancer les conteneurs:

docker stop webstack_varnish_01 && docker rm webstack_varnish_01
docker stop webstack_nginx_01 && docker rm webstack_nginx_01
docker stop webstack_php_01 && docker rm webstack_php_01

docker run --name webstack_php_01 -v $HOME/data/webstack/www:/srv/http:ro -p 9000:9000 -d jprjr/php-fpm
docker run --name webstack_nginx_01 -v $HOME/data/webstack/www:/usr/share/nginx/html:ro -v $HOME/data/webstack/conf/nginx.conf:/nginx.conf:ro -p 8080:80 --link webstack_php_01:webstack_php -d nginx nginx -c /nginx.conf
docker run --name webstack_varnish_01 -v $HOME/data/webstack/conf/default.vcl:/etc/varnish/default.vcl:ro -p 80:80 --link webstack_nginx_01:webstack_nginx -d jacksoncage/varnish

Note: Il est également possible de créer des images maison (avec commit + tag) et de les relancer. Cette phase peut être utile dans le cadre d’un déploiement d’une infrastructure à une autre.

Orchestration de l’infrastructure

On vient de voir que le lancement d’une infrastructure basée sur Docker peut rapidement devenir compliqué. Les conteneurs doivent être lancés dans un certain ordre, avec des options spécifiques. Il est toujours possible de scripter les commandes du chapitre précédent ou plus simplement d’utiliser un outil d’orchestration.

Vagrant vous vient en tête ? Pourtant, ce n’est pas la solution que nous allons utiliser dans ce billet.

Nous allons nous tourner vers docker-compose (anciennement Fig). C’est un logiciel en ligne de commande permettant de d’écrire son infrastructure Docker à partir d’un fichier de configuration texte au format YAML.

L’installation de Fig se fait via la commande:

sudo pip install docker-compose

Note: pour d’autre méthode d’installation, consultez la documentation sur le site officiel.

Le fichier de configuration Fig correspondant à notre infrastructure est le suivant (à éditer dans le fichier $HOME/data/webstack/docker-compose.yml):

# Webstack PHP
php:
    image: jprjr/php-fpm
    volumes:
    - www:/srv/http
    ports:
    - 9000:9000
# Webstack NGINX
nginx:
    image: nginx
    links:
    - php:webstack_php
    volumes:
    - www:/usr/share/nginx/html
    - conf/nginx.conf:/nginx.conf
    ports:
    - 8080:80
    command: nginx -c /nginx.conf
# Webstack VARNISH
varnish:
    image: jacksoncage/varnish
    links:
    - nginx:webstack_nginx
    volumes:
    - conf/default.vcl:/etc/varnish/default.vcl
    ports:
    - 80:80

On lance ensuite notre infrastructure en une seule et unique commande:

$ docker-compose up -d
Creating webstack_php_1...
Creating webstack_nginx_1...
Creating webstack_varnish_1...

Tout comme avec la ligne de commande Docker, on peut voir les conteneurs en cours d’exécution:

$ docker-compose ps
       Name                Command          State           Ports         
-------------------------------------------------------------------------
webstack_php_1                              Up      9000->9000/tcp        
webstack_nginx_1     nginx -c /nginx.conf   Up      443/tcp, 8080->80/tcp 
webstack_varnish_1   /start                 Up      80->80/tcp

Les arrêter (sans les supprimer):

$ docker-compose stop
Stopping webstack_varnish_1...
Stopping webstack_nginx_1...
Stopping webstack_php_1...

Les relancer:

$ docker-compose start
Starting webstack_php_1...
Starting webstack_nginx_1...
Starting webstack_varnish_1...

Les supprimer:

docker-compose stop && docker-compose rm

Je vous laisse découvrir les autres commandes de docker-compose sur le site officiel de la documentation.

Conclusion

Nous venons de créer les bases d’une infrastructure Web performante, facilement maintenable et évolutive. Il est ainsi facile d’y ajouter d’autres services comme une base de donnée (type MariaDB), un serveur sFTP (pour la mise à jour des pages Web) ou bien encore un outil d’analyse des logs (Varnish et NGinx).

Et de votre coté, avez-vous mis en place une infrastructure Docker pour votre serveur Web ? Si oui comment ?

Partagez votre expérience avec nous !

Étiquettes docker, docker-compose, fig, lemp, nginx, php-fpm, varnish, web stack

Open-source Planet-libre Systeme

Voici Glances 2.1 qui pointe son nez

Auteur de l’article Par nicolargo
Date de l’article 02/09/2014
2 commentaires sur Voici Glances 2.1 qui pointe son nez

La nouvelle version de Glances vient d’être publiée. En voici les nouveautés.

Comment installer Glances 2.1 ?

La première solution et la plus simple est d’utiliser le script d’autoinstall (uniquement fonctionnel pour certaines distribution GNU/Linux):

curl -L http://bit.ly/glances | /bin/bash

ou alors en consultant la documentation.

Amélioration de l’affichage des processus

Cette version de Glances apporte les fonctionnalités suivantes pour l’affichage des processus dans Glances:

possibilité d‘appliquer un filtre (sous la forme d’une expression régulière) sur le nom et la ligne de commande des processus à afficher. Pour cela, il suffit d’appuyer sur la touche ENTREE puis de saisir le filtre. Par exemple, le filtre firefox va afficher le ou les processus du navigateur Firefox tandis que le filtre .*firefox.* va afficher tous les programmes ou le mot clé Firefox apparaît dans la ligne de commande (à noter que cette nouvelle fonction est, pour l’instant, uniquement disponible dans le mode standalone de Glances).
informations complémentaire pour le ‘top process’ (le processus que Glances juge le plus consommateur de ressources): CPU affinity, extended memory information (shared, text, lib, datat, dirty, swap), openned threads/files and TCP/UDP network sessions, IO nice level (à noter que cette nouvelle fonction est, pour l’instant, uniquement disponible dans le mode standalone de Glances).
optimisation du nombre de processus surveillés par Glances: dans les anciennes versions, Glances recupérait l’ensemble des statisiques pour tous les processus (même ceux qui n’étaient pas affichés). Dans cette version le nombre de processus est configurable via la clé de configuration max_processes du fichier de configuration (par défaut top 10) .Cette version apporte donc un gain de footprint CPU d’environ 15% à 30%:Ainsi, pour augmenter à 20 le nombre de processus affiché, il suffit d’éditer le fichier de configuration de la manière suivante:
```
[processlist]
# Maximum number of processes to show in the UI
# Note: Only limit number of showed processes (not the one returned by the API)
# Default is 20 processes (Top 20)
max_processes=20
```
Note: si aucune configuration n’est faite alors Glances affichera tous les processus.
il est maintenant possible de basculer entre l’affichage actuel du nom du processus (qui affiche le nom court ou la ligne de commande complète selon la place disponible) et un mode ou uniquement le nom court est affiché. Pour cela, on peut utiliser le tag –process-short-name au niveau de la ligne de commande ou bien la touche ‘/’ pendant le fonctionnement de Glances.Mode shortname:
Mode standard:

Alias pour le nom des disques, interfaces réseau et sensors

Les noms des disques (sda par exemple sous Linux), des interfaces réseau (eth0, wlan0) et des sensors (temp1) n’est pas forcement très parlant pour un humain normalement constitué (!geek). Glances permet donc de configurer des alias qui seront affichés en lieu et place des noms « barbares ». La définition se fait dans le fichier de configuration:

[network]
# WLAN0 alias name
wlan0_alias=Wireless

[diskio]
# Alias for sda1
sda1_alias=IntDisk

[sensors]
# Sensors alias
temp1_alias=Motherboard 0
temp2_alias=Motherboard 1
core 0_alias=CPU Core 0
core 1_alias=CPU Core 1

Rien de bien compliqué. On doit utiliser la syntaxe: <nom barbare>_alias = <nom humain>.

Cette fonction est surtout utile pour les utilisateurs de Windows ou les noms sont vraiment… comment dire… Windowsiens…

API RESTFull pour le serveur Web

Le serveur HTTP intégrant l’interface Web (option -w) disponible dans Glances depuis la version 2.0 ne disposait pas d’une API RESFull. C’est maintenant le cas. Il est donc possible à partir d’une application tierce de faire des requêtes du type suivant:

http://<serverglances>:61209/api/v2/mem

qui donnera une réponse HTTP avec un code 200 et:

{"available": 5071183872, "used": 3255848960, "cached": 1827352576, "percent": 39.1, "free": 5071183872, "inactive": 1388982272, "active": 3679604736, "total": 8327032832, "buffers": 477982720}

La documentation complète de l’API est disponible sur la page suivante dans le Wiki.

Fonction expérimentale de génération de graphes

J’ai ajouté dans cette version une fonction expérimentale (uniquement disponible dans le mode standalone de Glances) qui sera améliorée dans les prochaines versions en cas de demande de la part des utilisateurs. L’objectif de cette fonction est de générer des graphiques des statistiques (CPU, LOAD et MEM) quand l’utilisateur clique sur la touche ‘g’. Concrètement, Glances va mémoriser les statistiques et les « grapher » en utilisant la librairy Matplotlib (qui doit être présente sur votre système).

Les graphes sont générés dans le répertoire /tmp:

ll /tmp/glances*.png
-rw-rw-r-- 1 nicolargo nicolargo 22911 août  31 16:09 /tmp/glances_cpu.png
-rw-rw-r-- 1 nicolargo nicolargo 19962 août  31 16:09 /tmp/glances_load.png
-rw-rw-r-- 1 nicolargo nicolargo 12059 août  31 16:09 /tmp/glances_mem.png

En appuyant sur la touche ‘r’, l’utilisateur peut ré-initialiser l’historique et donc repartir avec un nouveau graphe (attention pour l’instant les graphes sont écrasés à chaque appui sur le bouton ‘g’).

Des logs et un mode debug

Il manquait à Glances un vrai mode débug avec un fichier de log permettant de facilement identifier les problèmes d’utilisation et d’exécution de ce logiciel. C’est maintenant chose faite avec cette version 2.1 ou un gros travail a été fait sur la généralisation des message de logs standards et debug (en utilisant l’option -d au niveau de la ligne de commande).

Le fichier de log de Glances est disponible dans le fichier /tmp/glances.log, en voici un extrait en mode normal (sans le -d):

2014-08-31 15:52:00,312 -- INFO -- Start Glances 2.1_RC7
2014-08-31 15:52:00,312 -- INFO -- CPython 2.7.6 and PSutil 2.1.1 detected
2014-08-31 15:52:00,316 -- INFO -- Read configuration file ./conf/glances-test.conf
2014-08-31 15:52:00,316 -- INFO -- Start standalone mode
2014-08-31 15:52:10,465 -- INFO -- Set process filter to firefox
2014-08-31 15:52:15,180 -- INFO -- Stop Glances

et en mode debug (-d):

2014-08-31 15:52:47,185 -- INFO -- Start Glances 2.1_RC7
2014-08-31 15:52:47,185 -- INFO -- CPython 2.7.6 and PSutil 2.1.1 detected
2014-08-31 15:52:47,190 -- INFO -- Read configuration file ./conf/glances-test.conf
2014-08-31 15:52:47,190 -- INFO -- Start standalone mode
2014-08-31 15:52:47,218 -- DEBUG -- Available plugins list: ['load', 'core', 'uptime', 'fs', 'monitor', 'percpu', 'mem', 'cpu', 'help', 'system', 'alert', 'psutilversion', 'memswap', 'diskio', 'hddtemp', 'processcount', 'batpercent', 'now', 'processlist', 'sensors', 'network']
2014-08-31 15:52:47,219 -- DEBUG -- Monitor plugin configuration detected in the configuration file
2014-08-31 15:52:47,220 -- DEBUG -- Limit maximum displayed processes to 20
2014-08-31 15:52:47,220 -- DEBUG -- Extended stats for top process is enabled (default behavor)
2014-08-31 15:52:53,140 -- DEBUG -- User enters the following process filter patern: firefox 
2014-08-31 15:52:53,140 -- INFO -- Set process filter to firefox
2014-08-31 15:52:53,140 -- DEBUG -- Process filter regular expression compilation OK: firefox
2014-08-31 15:52:57,344 -- INFO -- Stop Glances

Cette nouvelle fonction permettra, je l’espère, de facilité les rapports de bugs remontés dans GitHub.

Et pour finir…

En plus des corrections de bugs et amélioration diverses et variés, Glances 2.1 permet un affichage optimisé pour les tordus d’entre vous utilisant un fond blanc pour leur terminal (option –theme-white) ainsi que le support des routeurs Cisco et des serveurs VMWare ESXi pour le fallback SNMP en mode client/serveur.

Comme d’habitude, les bugs/demandes de fonctions sont à remonter dans GitHub en suivant cette procédure.

Merci à vous !

Étiquettes 2.1, glances

Open-source Planet-libre Systeme

Glances version 2.0 est là

Auteur de l’article Par nicolargo
Date de l’article 16/06/2014
12 commentaires sur Glances version 2.0 est là

Après plusieurs mois de travail, la nouvelle version majeure de Glances vient d’être publié. L’objectif de ce billet est de faire une rapide présentation des nouveautés, un article plus complet est disponible sur LinuxFR.

Pour ceux d’entre vous qui ne connaissent pas encore Glances, c’est un logiciel permettant de superviser le plus simplement possible ses machines en disposant sur une seule et unique page (terminal ou interface Web) les informations importantes (CPU, mémoire, charge, processus…).

Il peut être utilisé dans des configurations différentes:

standalone: superviser la machine sur laquelle on se trouve à partir d’une interface Curse
client/serveur: superviser une machine distante à partir d’une interface Curse
serveur Web: superviser une machine distante à partir d’un navigateur Internet
API: accès aux statistique via une API XML/RPC

Comment installer cette nouvelle version ?

Le plus simple est de passer par le gestionnaire de paquet de Python (PiPy).

Pour une installation complète avec toutes les dépendances:

sudo pip install glances pysnmp bottle batinfo https://bitbucket.org/gleb_zhulik/py3sensors/get/tip.tar.gz

Note: selon votre configuration, il est peut être nécessaire d’installer certains pré-requis avant de faire cette installation. Par exemple sur un système Debian/Ubuntu:

sudo apt-get install -y python-dev python-pip lm-sensors

Pour la mise à jour d’une version existante et l’installation des dépendances:

sudo pip install pysnmp bottle batinfo https://bitbucket.org/gleb_zhulik/py3sensors/get/tip.tar.gz
sudo pip install --upgrade glances

Les nouveautés…

Au niveau du code

La plus grande nouveauté n’est pas visible car c’est un refactoring complet du code avec notamment l’utilisation d’un système de plugins. Toutes les statistiques collectées par Glances sont des plugins. Le principal avantage de cette architecture est une rapidité de développement accrue pour les nouvelles fonctionnalités par rapport à la version précédente. Chaque plugin hérite de méthodes communes permettant de factoriser le code.

Cette version a été développée en suivant le workfow Git Flow et les prochains correctifs et nouvelles fonctions devront respecter ce processus (j’ai ajouté une page sur le sujet dans le Wiki).

Interface Curse

L’interface standalone a été optimisée pour afficher le maximum d’informations de la manière la plus lisible et dans un minimum d’espace. L’objectif principal et le but de Glance étant que le problème de performance d’une machine saute aux yeux.

Interface Web

A la suite de pas mal de demandes, Glances v2.0 intègre maintenant un mode serveur Web qui permet d’accéder simplement au statistique depuis n’importe quel navigateur Internet à travers une page HTML5/CSS3 (plus ou moins « Responsive Web Design » mais je suis pas un pro sur le sujet).

Pour lancer le mode serveur Web:

# glances -w

Bottle v0.12.7 server starting up (using WSGIRefServer())...
Listening on http://0.0.0.0:61208/
Hit Ctrl-C to quit.

Par exemple sur ma tablette Nexus 5, cela donne cela:

Le mode fallback SNMP

Dans le cas ou il n’est pas possible de lancer un serveur Glances sur une machine (problème de droit ou « appliance »), il est maintenant possible d’accéder à certaines statistiques via le protocole SNMP (limitation actuelle au mode SNMP v2/2c).

Quand vous lancez Glances en mode client, il va d’abord essayer de détecter un serveur Glances puis essayer le protocole SNMP:

# glances -c localhost

Info: Connection to Glances server failed. Trying fallback to SNMP...

C’est pour l’instant une fonction expérimentale qui ne fonctionne pas avec tous les agents SNMP. Des évolutions sont prévues dans les prochaines version et je suis à la recherche de contributeurs sur ce point (notamment pour un accès aux statistiques des machines Cisco et autres équipementiers réseau).

Amélioration du fichier de configuration

Si vous utilisiez un fichier de configuration (notamment pour fixer vos propres limites au niveau des statistiques), il va falloir l’adapter pour cette nouvelle version. Un fichier par défaut se trouve sous GNU/Linux dans /etc/glances/glances.conf. Je vous conseille de vous inspirer de ce fichier: https://github.com/nicolargo/glances/blob/master/conf/glances-monitor.conf.

Conclusion

En attendant que vous lisiez le billet sur LinuxFr, j’espère que cette mise en bouche vous a convaincu d’essayer cette nouvelle version.

J’attends vos avis avec impatiente !

Étiquettes 2.0, glances

Blog Developpement Open-source Reseau Systeme Web

Un sacré programme pour les SophiaConf 2014

Auteur de l’article Par nicolargo
Date de l’article 03/06/2014

Cette année encore, la Telecom Valley nous gâte avec une série de 4 soirées de conférences accessible gratuitement sur le campus SophiaTech à Sophia-Antipolis (06).

Lundi 30/06

Internet Of Things/ M2M / Do It Yourself

Mardi 01/07

Big data, No SQL, BI et sécurité du cloud

Mercredi 02/07

Web Sémantique : de la recherche à l’usage – enfin?

Jeudi 03/07

Nouvelles tendances de développement web

Lieux

Campus SophiaTech

Horaires

Accueil à 17h45

18h00 – 20h00

Accueil à 17h45

18h00 – 20h00

Accueil à 17h45

18h00 – 20h00

Accueil à 17h45

18h00 – 20h00

Intervenants

Pascal BODIN
(Orange)

Alexis MOUSSINE-POUCHKINE Google
(à confirmer)

Alexandru CARACAS
(IBM Zurich)

Jean DEMARTINI
(Demtech)

Benjamin CABE
(Fondation Eclipse)

Julien HOLTZER (Pobot)

Didier GIRARD (SFEIR, Google Developer Expert)

Aurélien GOUJET (MapR)

Edmond CISSE
(Uraeus Consult)

Cyril GROSJEAN
(Janua)

Aurélien MAZOYER
(France Labs)

Olivier TAVARD
(France Labs)

Julien MARECHAL
(Air France)

Jérémy MEYER
(Amadeus)

Fabien GANDON
(Inria)

Christophe DESCLAUX
(Reador)

Mylène LEITZELMAN
(Mnemotix)

Laurent BIHANIC
(Atos)

Guillaume VILAND

(Orange Portail)

A lexis MOUSSINE-POUCHKINE
(Google europe)

Bertrand LAPORTE
(Amadeus)

Benoît CHARBONIER
(Amadeus)

Matti SCHNEIDER

Pawel KOZLOWSKI
(Amadeus)

Infos pratiques

Entrée gratuite, inscription obligatoire

Inscrivez-vous en cliquant ici.

Vous pouvez vous inscrire en ligne à partir du site officiel: http://www.telecom-valley.fr/webform/inscription-sophiaconf2014

Étiquettes 2014, sophiaconf

Developpement Open-source Planet-libre Reseau Systeme

Virtualisation légère avec Docker

Auteur de l’article Par nicolargo
Date de l’article 02/06/2014
35 commentaires sur Virtualisation légère avec Docker

Dans le petit monde des DevOps, la solution de virtualisation Docker a le vent en poupe. Nous allons dans ce billet essayer de décrypter ce qui ce cache derrière ce nouvel outil et proposer un tutoriel sur l’installation et les premiers pas pour une utilisation souple et efficace.

C’est quoi donc ?

Docker est un logiciel open-source (sous licence Apache 2.0) et un service en ligne optionnel (Docker.io) permettant de gérer des conteneurs (« dockers »).

Contrairement aux machines virtuelles classiques qui comprennent un système hôte (« guest OS ») et les librairies/applications, les conteneurs ne contiennent, au maximum, que les applications/librairies.

Quand je dis au maximum c’est qu’une copie d’un conteneur qui ne change que la partie application ne contiendra que les différences par rapport au conteneur initial.

Le système hôte est ainsi géré directement par le Docker Engine (en vert dans le premier schéma). On a ainsi une mutualisation qui permet de lancer les conteneurs de manière très rapide: le temps de lancement d’un conteneur est presque le même que le temps de lancement des applications qu’il contient. En effet, le système d’exploitation est déjà lancé. Donc pas de phase de démarrage ni d’initialisation de cette couche. Il faut quand même avoir à l’esprit que même si l’on est pas dans une machine virtuelle, on dispose tout de même d’un environnement isolé (processus, système de fichier, ports réseau). L’utilisateur n’a qu’à se préoccuper que de ce qu’il veut virtualiser (les applications/services) et ne s’occupe pas du reste.

L’autre gros avantage de cette technologie est la portabilité. En effet, il est tout à fait possible de concevoir un conteneur sur son PC portable puis ensuite de le déployer sur son infrastructure de production physique ou virtuelle. La taille des conteneurs étant relativement réduite, on peut donc imaginer un workflow de déploiement basée sur un repo central (type Git) et des Docker Engine installés sur les machines qui font elle même tourner des conteneurs. Il n’y a pas vraiment de limite au nombre de conteneurs qu’une machine puisse faire tourner. La limite vient de l’occupation mémoire/CPU/réseau de vos applications.

Si vous avez encore des questions sur la différence entre Docker et VM, je vous conseille la lecture de cette question sur StackOverflow: « How is Docker.io different from a normal virtual-machine ?« .

Installation de Docker

Note (merci à @jb_barth pour le commentaire): jusqu’à la version 0.9, Docker se basait sur la technologie LXC (« Linux Containers ») du noyau Linux et ne fonctionnait donc que sur des distributions GNU/Linux avec un noyau >= 2.6.24. La dépendance stricte à LXC a sauté depuis la v0.9.0, le driver par défaut est maintenant libcontainer, une lib pur go produite par le projet pour accéder de façon propre aux APIs dispos dans le kernel. C’est ce qui a permis de supporter des noyaux aussi vieux d’ailleurs, au début c’était >= 3.8

Voici les étapes à suivre pour installer Docker sur une distribution Ubuntu 14.04 LTS. A noter, pour les miséreux développeurs sous Windows ou Mac OS, il est est toujours possible de faire tourner une VM Ubuntu (par exemple avec VirtualBox) et de suivre cette installation.

Docker est directement disponible dans les repositories d’Ubuntu, donc un simple:

sudo apt-get install docker.io
sudo ln -sf /usr/bin/docker.io /usr/local/bin/docker

suffit pour effectuer l’installation complète de Docker sur notre machine comprenant:

le Docker Engine (ou service Docker)
le Docker Client (permettant de discuter avec le Docker Engine)

Cependant si vous souhaiter travailler avec une version plus ressente il faut utiliser les commandes suivantes:

sudo apt-key adv --keyserver hkp://pgp.mit.edu:80 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D
sudo sh -c "echo deb https://apt.dockerproject.org/repo ubuntu-trusty main \ > /etc/apt/sources.list.d/docker.list"
sudo apt-get update
sudo apt-get purge lxc-docker*
sudo apt-get install docker-engine

Comme les conteneurs vont utiliser les serveurs DNS de la machine hôte, il est nécessaire de configurer les adresses des serveurs DNS dans le fichier /etc/default/docker.io (par exemple avec les serveurs OpenDNS):

$ vi /etc/default/docker.io

# Use DOCKER_OPTS to modify the daemon startup options.
DOCKER_OPTS="-dns 208.67.220.220 -dns 208.67.220.222"

Pour que la configuration soit prise en compte, il faut relancer le service Docker avec la commande:

sudo service docker restart

Un petit ps permet de voir que le service est bien lancé:

0.0   0.1  563M 9.65M   733 root         0 S  0:00.46     0     0 /usr/bin/docker.io -d -dns 208.67.220.220 -dns 208.67.220.222

Récupération des images système

Nous allons commencer par récupérer des images qui vont servir de de bases à notre conteneur. Une liste assez conséquente d’images sont disponibles sur le site officiel du projet. Vous pouvez ainsi récupérer celle qui est le plus proche de l’environnement que vous recherché. Un moteur de recherche est disponible à l’adresse https://index.docker.io/ pour trouver des images conçues par les développeurs du projet et par des contributeurs.

On retrouve ainsi des distributions GNU/Linux minimales comme Ubuntu, CentOS, BusyBox pour ne siter que les images officiellement supportées par le projet Docker.io (il existe également des repos non officiels avec Fedora, RH, Arch…).

Petit mention spéciale pour les images BusyBox qui sont vraiment très légère (moins de 10 Mo) pour un système fonctionnel !

Même si il est possible de directement télécharger l’image au lancement du conteneur, je préfère avoir sur ma machine les images des différentes versions de l’OS que j’utilise le plus: Ubuntu.

Pour récupérer l’ensemble des images du repo Ubuntu qui contient les versio minimale d’Ubuntu de la version 10.04 à 14.04), il faut saisir la commande suivante:

$ sudo docker pull ubuntu

74fe38d11401: Pulling dependent layers
316b678ddf48: Pulling dependent layers
3db9c44f4520: Pulling dependent layers
5e019ab7bf6d: Pulling dependent layers
99ec81b80c55: Pulling dependent layers
a7cf8ae4e998: Pulling dependent layers
511136ea3c5a: Download complete
e2aa6665d371: Downloading [==>                                                ] 2.027 MB/40.16 MB 6m14s

Note: le téléchargement initial des images peut prendre un peu de temps selon la vitesse de votre liaison Internet.

Il est également possible de faire de même avec les autres distributions citées ci-dessus:

$ sudo docker pull centos

$ sudo docker pull busybox

Une fois le téléchargement terminé, on peut demandé à Docker un status de son état actuel:

$ sudo docker info
Containers: 64
Images: 46
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Dirs: 174
Execution Driver: native-0.1
Kernel Version: 3.13.0-24-generic
WARNING: No swap limit support

ainsi que la liste des images disponibles:

$ sudo docker images
REPOSITORY          TAG                   IMAGE ID            CREATED             VIRTUAL SIZE
busybox             buildroot-2013.08.1   352f47ad2ecf        17 hours ago        2.489 MB
busybox             ubuntu-14.04          6a95c08a9391        17 hours ago        5.609 MB
busybox             ubuntu-12.04          1720a1681f1c        17 hours ago        5.455 MB
busybox             buildroot-2014.02     f66342b343ae        17 hours ago        2.433 MB
busybox             latest                f66342b343ae        17 hours ago        2.433 MB
ubuntu              glances_develop       a483f92d9ab3        24 hours ago        556.8 MB
ubuntu              14.04_nicolargo       8574cc29575e        28 hours ago        440.8 MB
ubuntu              13.10                 5e019ab7bf6d        4 weeks ago         180 MB
ubuntu              saucy                 5e019ab7bf6d        4 weeks ago         180 MB
ubuntu              12.04                 74fe38d11401        4 weeks ago         209.6 MB
ubuntu              precise               74fe38d11401        4 weeks ago         209.6 MB
ubuntu              12.10                 a7cf8ae4e998        4 weeks ago         171.3 MB
ubuntu              quantal               a7cf8ae4e998        4 weeks ago         171.3 MB
ubuntu              14.04                 99ec81b80c55        4 weeks ago         266 MB
ubuntu              latest                99ec81b80c55        4 weeks ago         266 MB
ubuntu              trusty                99ec81b80c55        4 weeks ago         266 MB
ubuntu              13.04                 316b678ddf48        4 weeks ago         169.4 MB
ubuntu              raring                316b678ddf48        4 weeks ago         169.4 MB
ubuntu              lucid                 3db9c44f4520        5 weeks ago         183 MB
ubuntu              10.04                 3db9c44f4520        5 weeks ago         183 MB
centos              centos6               0b443ba03958        6 weeks ago         297.6 MB
centos              6.4                   539c0211cd76        14 months ago       300.6 MB
centos              latest                539c0211cd76        14 months ago       300.6 MB

Comme alternative du moteur de recherche https://index.docker.io/, il est bien sûr possible d’utiliser la ligne de commande. Par exemple pour trouver toutes les images Ubuntu disponibles sur le repo central:

sudo docker search ubuntu | less

A noter qu’il est tout à fait possible, si vous ne trouvez pas votre bonheur de concevoir « from scratch » votre propre image système en suivant cette documentation sur le site officiel (la procédure se base sur DebootStrap).

Création de son premier conteneur

Bon assez de préliminaires, nous allons maintenant pourvoir créer notre premier conteneur qui va se limiter à exécuter la commande ‘ls’ (si c’est pas du conteneur de compétition):

$ sudo docker run ubuntu:latest /bin/ls -alF

total 8280
drwxr-xr-x  46 root root    4096 May 28 06:50 ./
drwxr-xr-x  46 root root    4096 May 28 06:50 ../
-rw-r--r--   1 root root     102 May 28 06:50 .dockerenv
-rwx------   1 root root 8394118 May 27 15:37 .dockerinit*
drwxr-xr-x   2 root root    4096 Apr 16 20:36 bin/
drwxr-xr-x   2 root root    4096 Apr 10 22:12 boot/
drwxr-xr-x   4 root root    4096 May 28 06:50 dev/
drwxr-xr-x  64 root root    4096 May 28 06:50 etc/
drwxr-xr-x   2 root root    4096 Apr 10 22:12 home/
drwxr-xr-x  12 root root    4096 Apr 16 20:36 lib/
drwxr-xr-x   2 root root    4096 Apr 16 20:35 lib64/
drwxr-xr-x   2 root root    4096 Apr 16 20:35 media/
drwxr-xr-x   2 root root    4096 Apr 10 22:12 mnt/
drwxr-xr-x   2 root root    4096 Apr 16 20:35 opt/
dr-xr-xr-x 236 root root       0 May 28 06:50 proc/
drwx------   2 root root    4096 Apr 16 20:36 root/
drwxr-xr-x   7 root root    4096 Apr 16 20:36 run/
drwxr-xr-x   2 root root    4096 Apr 24 16:17 sbin/
drwxr-xr-x   2 root root    4096 Apr 16 20:35 srv/
dr-xr-xr-x  13 root root       0 May 28 06:50 sys/
drwxrwxrwt   2 root root    4096 Apr 24 16:17 tmp/
drwxr-xr-x  11 root root    4096 Apr 16 20:35 usr/
drwxr-xr-x  14 root root    4096 Apr 16 20:36 var/

Arrêtons-nous un peu sur la commande: sudo docker.io run ubuntu:latest /bin/ls -alF

On demande donc le lancement (run) d’un conteneur basée sur la dernière version d’Ubuntu (ubuntu:latest qui est un lien vers l’image minimale de la version 14.04) qui va exécuter la commande ls (/bin/ls -alF). Comme vous pouvez le voir dans le résultat de la commande, on est dans un environnement isolé avec son propre système de fichier.

Première constatation, la vitesse d’exécution de notre environnement virtuel est vraiment impressionnante. Sur une petit commande,on peut voir que l’overhead de lancement du conteneur est négligeable:

$ time sudo docker run ubuntu:latest ls -alF /
...
real	0m0.331s
user	0m0.014s
sys	0m0.012s

$ time ls -alF /
...
real	0m0.007s
user	0m0.003s
sys	0m0.004s

Puis un conteneur persistant

Passons maintenant à la création d’un conteneur persistant, c’est à dire un conteneur qui va faire tourner une tache pendant un temps indéterminé (je prends par exemple un pin infini vers le site Google).

$ sudo docker run -d ubuntu:latest ping www.google.fr
7404bfa4beca4ba97459c96f8d93242c4fba6ecf2c5b11d18c09acd2fce9991e

Noter le -d dans la ligne de commande pour détacher le conteneur et ainsi lui permettre de tourner en tache de fond.

En retour on obtient le numéro d’identifiant unique du conteneur qui va nous permettre de le contrôler.

On commence donc par vérifier qu’il tourne bien:

$ sudo docker ps
CONTAINER ID        IMAGE               COMMAND              CREATED             STATUS              PORTS               NAMES
7404bfa4beca        ubuntu:14.04        ping www.google.fr   3 minutes ago       Up 3 minutes                            mad_lumiere

On peut ainsi, l’arrêter:

sudo docker stop 7404bfa4beca

Le démarrer:

sudo docker start 7404bfa4beca

Le redémarrer (l’équivalent d’un stop/start):

sudo docker restart 7404bfa4beca

Lui envoyer des signaux:

sudo docker kill 7404bfa4beca

Ensute on supprime le conteneur avec la séquence stop/rm:

sudo docker stop 7404bfa4beca

sudo docker rm 7404bfa4beca

Un Shell dans un conteneur

Pour accéder à un shell dans le conteneur, il faut utiliser les options suivantes dans la ligne de commande:

-t: Allocate a pseudo-tty
-i: Keep STDIN open even if not attached

$ sudo docker run -i -t ubuntu:latest bash
root@bb89ed6cdd3c:/#

Structurer la création des conteneurs avec les Dockerfiles

Les Dockerfiles sont des fichiers textes décrivant les différentes étapes pour la création d’un conteneur. Idéalement, ce sont ces fichiers que vous aller gérer en configuration et que vous aller partager avec les différentes personnes utilisatrices de votre projet. Pour illustrer mes dires, je vais prendre l’exemple d’un dockerfile qui va permettre aux contributeurs du projet Glances de tester simplement la branche de développement du logiciel.

En gros, le dockfile doit:

utiliser un OS de base (Ubuntu 14.04 LTS)
installer les pré-requis système
télécharger la dernière version de Glances sous Github

Le dockfile glances_develop_install correspondant est alors le suivant:

# Install Glances Development branch
#
# $ sudo docker build -t ubuntu:glances_develop - < glances_develop_install
#
# VERSION 1.0

# Use the ubuntu base image provided by dotCloud
FROM ubuntu
MAINTAINER Nicolargo, nicolas@nicolargo.com

# Make sure the package repository is up to date
RUN apt-get -y update

# Install prerequirement
RUN apt-get install -y python-dev python-pip git lm-sensors
RUN pip install psutil bottle batinfo https://bitbucket.org/gleb_zhulik/py3sensors/get/tip.tar.gz

# Patch for current Docker version
RUN ln -s /proc/mounts /etc/mtab

# Install Glances from the Pipy repository
RUN git clone -b develop https://github.com/nicolargo/glances.git

Voyons un peu en détail le contenu du fichier. On commence donc par définir l’OS de base:

FROM ubuntu

On peut bien sûr utiliser l’image/tag que l’on souhaite.

Ensuite on passe aux commandes que l’on souhaite exécuter:

RUN apt-get -y update

RUN apt-get install -y python-dev python-pip git lm-sensors

RUN pip install psutil bottle batinfo https://bitbucket.org/gleb_zhulik/py3sensors/get/tip.tar.gz

RUN ln -s /proc/mounts /etc/mtab

RUN git clone -b develop https://github.com/nicolargo/glances.git

Rien de bien compliqué, il suffit de faire précéder la commande Unix par le mot clé RUN…

Il ne reste plus qu’à lancer la construction du conteneur et son exportation vers une nouvelle image (nommé ubuntu:glances_develop) à partir de la ligne de commande:

sudo docker build -t ubuntu:glances_develop - < glances_develop_install

ou alors directement depuis un repos (par exemple GitHub) ou vos Dockers files sont gérés en configuration:

sudo docker build -t ubuntu:glances_develop https://raw.githubusercontent.com/nicolargo/dockersfiles/master/glances_develop_install

On vérifie ensuite que l’image a bien été créée:

$ sudo docker images | grep glances
ubuntu glances_develop a483f92d9ab3 31 hours ago 556.8 MB

Puis on lance Glances depuis ce conteneur (en le metant à jour par un pull avant le lancement):

sudo docker run -i -t --entrypoint /bin/bash ubuntu:glances_develop -c "cd glances ; git pull origin develop ; python -m glances"

Et hop c’est magique:

Un des trucs fun avec Docker c’est que si l’on souhaite modifier un conteneur en ajoutant par exemple l’installation d’un nouveau logiciel, il suffit de modifier le Docker file puis de refaire la commande de build. L’installation ne se fera que par delta par rapport au premier conteneur.

Controler la CPU et la mémoire de ses conteneurs

Une fonction intéressante de Docker est sa capacité de contraindre un conteneur en terme de CPU et de MEM. Par exemple on peut limiter le conteneur à 512 Mo de RAM et donner un priorité moins forte en terme de CPU à ce conteneur par rapport aux autres. Il faut cependant que le hôte qu héberge Docker soit compatible avec ces options ce qui n’est pas mon cas:

$ sudo docker run -m 512m -i -t --entrypoint /bin/bash ubuntu:glances_develop -c "cd glances ; git pull origin develop ; python -m glances"

WARNING: Your kernel does not support swap limit capabilities. Limitation discarded.

Pour activer ces options sous Ubuntu, il faut modifier la configuration du Kernel via GRUB. Pour cela, il est nécessaire de suivre cette procédure.

Conclusion

L’approche est vraiment différente des solutions de virtualisation classiques mais si vous cherchez un outil simple pour valider vos applications Linux dans un environnement controlé alors Docker est définitivement une solution à envisager. Sa souplesse et sa légéreté en font une solution idéale à embarquer sur son PC portable ou à mettre en production sur son infrastructure.

Je vous conseille de vous plonger dans la documentation officielle qui est vraiment complète et très bien faite.

Des expériences à nous faire partager sur l’utilisation de Docker ?

Quelques références:

Étiquettes devops, docker, docker.io

Developpement Open-source Reseau Systeme

Glances v2.0 RC – J’ai besoin de vous !

Auteur de l’article Par nicolargo
Date de l’article 27/05/2014
3 commentaires sur Glances v2.0 RC – J’ai besoin de vous !

Cela fait maintenant plusieurs mois que je délaisse mon bébé blog pour me consacrer au développement de la version 2.0 de Glances. Avec l’aide d’Alessio Sergi, nous avons effectué un refactoring complet du code et apporté de nouvelles fonctions qui, je l’espère, vous serons utiles.

Cependant, avant la mise à disposition officielle, j’ai besoin de vous pour tester la première Release Candidate (RC1). Le développement ayant été fait sous Ubuntu 14.04, je recherche donc des personnes de bonne volonté pour valider cette RC1 sur d’autres système d’exploitation: autres distributions GNU/Linux, BSD, Mac OS, Windows.

Comment tester Glances v2.0 RC1 ?

Le plus simple est de suivre les instructions de la page Wiki qui va vous permettre de tester cette nouvelle version sans impacter votre système existant (utilisation d’un environnement virtuel avec virtualenv).

Il est important de bien vérifier que l’on est sur la branche DEVELOP avant de lancer les tests suivants. Pour vérifier cela:

cd ~/tmp/glances
LANGUAGE=en_US.utf8  ~/glances-venv/bin/python -m glances -V

devrait afficher comme résultat:

Glances v2.0_RC1 with psutil v2.1.0

Quoi tester?

A vrai dire un peut tout…

Le mode standalone

Le plus simple est de commencer par lancer Glances en mode standalone (supervision de son propre système):

cd ~/tmp/glances
LANGUAGE=en_US.utf8  ~/glances-venv/bin/python -m glances -C ~/tmp/glances/conf/glances-monitor.conf

Votre terminal devrait afficher les statistiques (rafraîchissement par défaut de 3 secondes). En appuyant sur la touche ‘h’, vous obtiendrez une liste des différentes fonctions.

Mode client/serveur classique

Je vous propose ensuite de passer au mode client/serveur qui peut être testé sur une unique machine (le client et le serveur étant lancé sur la même machine) ou bien sur deux machines différentes.

On commence par lancer le serveur:

cd ~/tmp/glances
LANGUAGE=en_US.utf8  ~/glances-venv/bin/python -m glances -C ~/tmp/glances/conf/glances-monitor.conf -s

Puis le client:

cd ~/tmp/glances
LANGUAGE=en_US.utf8  ~/glances-venv/bin/python -m glances -C ~/tmp/glances/conf/glances-monitor.conf -c @IPSERVER

Votre terminal va alors afficher les statistiques du serveur.

Mode client/serveur SNMP

C’est une nouveauté de la version 2.0. Ce mode permet de lancer un client vers une machine ou le serveur Glances n’est pas lancé. Il va ainsi essayé de se connecter a un serveur SNMP (si celui-ci est installé sur votre serveur). Cette fonction est encore expérimentale et ne fonctionne correctement qu’avec des agents SNMP GNU/Linux.

Pour tester, il suffit de lancer le client:

cd ~/tmp/glances
LANGUAGE=en_US.utf8  ~/glances-venv/bin/python -m glances -C ~/tmp/glances/conf/glances-monitor.conf -c @IPSERVER

Votre terminal va alors afficher les statistiques minimale du serveur (par exemple, on a pas la liste des processus).

Mode Web serveur

Egalement une nouveauté de la version 2.0, ce mode permet de lancer un serveur Glances qui va proposer une interface Web. Glances utilise pour cela le framework Bootle qui a déjà fait ses preuves dans de nombreux autres projets libres.

Pour lancer le serveur en mode Web, il faut saisir la ligne de commande suivante:

cd ~/tmp/glances
LANGUAGE=en_US.utf8  ~/glances-venv/bin/python -m glances -C ~/tmp/glances/conf/glances-monitor.conf -w

Puis pointer son navigateur Web préféré sur l’adresse suivante: http://<ip serveur>:61208/

Comment remonter un bug ou une demande d’amélioration ?

Il faut disposer d’un compte Github et de cliquer sur le lien suivant: Remonter un bug dans Glances.

Dans la description, faire systématiquement apparaître:

la version de Glances testée ( ~/glances-venv/bin/python -m glances -V)
votre environnement de test (système d’exploitation, hardware, version de Python…)
un descriptif le plus précis du problème et de la manière de le reproduire (en Anglais de préférence)

Je compte sur vous 🙂

Étiquettes glances, rc, test, v2, v2.0

Developpement Open-source Planet-libre Reseau Systeme

Glances 1.7.4 est dans les bacs !

Auteur de l’article Par nicolargo
Date de l’article 20/01/2014
3 commentaires sur Glances 1.7.4 est dans les bacs !

Nouvelle version pour Glances, l’outil de supervision système que je développe avec d’autres contributeurs depuis maintenant quelques années. On commence par le traditionnel screenshot du client en mode console:

Installation et mise à jour

L’installation de Glances sur votre machine (Linux, Mac ou même Windows) se fait via la ligne de commande:

pip install glances

La mise à jour n’est pas plus compliquée:

pip install --upgrade glances

Au chapitre des nouveautés

On commence par la modification de l’affichage de la ligne résumant l’état des processus. On a séparé la notion de ‘tasks’ et de ‘threads’:

Une nouvelle statistique au niveau de la CPU des machines GNU/Linux est affiché et disponible via l’API: la steal qui peut être utile de surveiller notamment si votre machine est virtuelle (plus d’information sur la mémoire steal en lisant ce très bon billet sur le sujet).

On a également ajouté l’information d’uptime (temps écoulé depuis le dernier redémarrage de la machine). Cette information est disponible en haut à droite dans l’interface et bien évidement comme toutes les statistiques via l’API (methode getUptime).

Il est maintenant possible, via le fichier de configuration de Glances de cacher certains disques ou interfaces réseau:

[iodisk]
# Define the list of hidden disks (comma separeted)
hide=sda2,sda5

[network]
# Define the list of hidden network interfaces (comma separeted)
hide=lo

Vous serez également heureux d’apprendre que Glances 1.7.4 consomme environ 10% de moins de CPU que la version précédente. En effet, certaines statistiques qui ne nécessite pas un rafraîchissement très fréquent sont maintenant mis en cache.

Enfin, un certain nombre de bugs ont été corrigés (voir la liste exhaustive ici).

Un grand merci aux contributeurs (Alessio en tête), aux packagers (qui vont avoir un peu de boulot) et aux bêta-testeurs !

En route pour la version Glances 2.0 (re-factoring complet, gestion par plugins…) !

Étiquettes 1.7.4, glances, release note

Open-source Planet-libre Systeme

Dropbox et la ligne de commande

Auteur de l’article Par nicolargo
Date de l’article 17/09/2013
6 commentaires sur Dropbox et la ligne de commande

Je suis utilisateur du service Dropbox depuis maintenant quelques temps. Il me permet de synchroniser les fichiers entres mes différentes machines (même les serveurs). Depuis ses débuts, Dropbox propose un client pour système GNU/Linux complètement intégré dans l’environnement graphique.

Ce qui est moins connu, c’est l’utilisation de la bonne vieille ligne de commande pour profiter de ce service. C’est ce que nous allons voir ensemble dans ce billet en parcourant quelques fonctions disponibles.

Ré-initialiser du cache

Dans certains cas, il se peut que votre client Dropbox tourne dans le vide (l’icône de notification reste bloqué sur une mise à jour de fichier). Je suis bien placé pour le savoir car cela vient de m’arriver…

Pour repartir d’une configuration propre, il est nécessaire de nettoyer le cache de Dropbox. Il n’y a pas de commande à proprement parler pour faire cela mais un simple:

rm -R ~/Dropbox/.dropbox.cache/*

devrait suffire à remettre votre Dropbox dans le droit chemin de la synchronisation.

Arrêter puis relancer Dropbox en ligne de commande

Si vous avez à écrire un script shell qui va générer des fichiers non désirables (ou bien trop volumineux) dans un des répertoire de votre Dropbox, il peut être utile d’arrêter puis de relancer le service depuis le script. On évitera ainsi de saturer sa ligne internet avec des transferts inutiles.

Pour cela on utilisera les commandes:

dropbox stop
...
<votre script ici>
...
dropbox start

Obtenir des informations sur l’état de Dropbox

Pour obtenir le status du démon Dropbox (processus dropboxd), il est possible d’utiliser:

$ dropbox  status
Idle

Note: la commande ‘dropbox running’ renvoie le code retour 1 si le démon Dropbox est lancé, 0 sinon.

Si vous souhaitez avoir l’état de synchronisation de votre répertoire ~/Dropbox:

$ dropbox filestatus ~/Dropbox/
/home/nicolargo/Dropbox/: up to date

Il est possible de passer en paramètre de cette dernière fonction un fichier (ou un répertoire):

$ dropbox filestatus ~/Dropbox/Public/ESIL2010-Cloud.pdf 
/home/nicolargo/Dropbox/Public/ESIL2010-Cloud.pdf: up to date

Obtenir l’URL publique des fichiers de votre Dropbox

Last but not least, Dropbox permet de partager vos fichiers en générant une URL publique. Celle-ci peut être obtenue en ligne de commande (ou dans vos scripts) via:

$ dropbox puburl ~/Dropbox/Public/ESIL2010-Cloud.pdf 
https://dl.dropboxusercontent.com/u/1112933/ESIL2010-Cloud.pdf

Pour aller plus loin: l’API Python

Si (comme moi), vous développez en Python, il existe une API permettant de jouer avec le service Dropbox. Je vous conseille la lecture de la page officielle sur le sujet.

Étiquettes cli, dropbox

Open-source Planet-libre Reseau Systeme

Distributed Monitoring Nagios à l’aide de Mod-Gearman

Auteur de l’article Par Laurent Hugot
Date de l’article 04/09/2013
10 commentaires sur Distributed Monitoring Nagios à l’aide de Mod-Gearman

Pour nous parler de Nagios et de supervision distribuée, j’ai le plaisir d’accueillir sur ce blog, en tant que rédacteur invité, Laurent Hugot. Laurent travaille actuellement pour la société Altair en Belgique et à en charge les activités de supervision.

===

Le « Distributed Monitoring » est une solution utilisée lorsque l’on veut surveiller plusieurs sites avec une seule installation de Nagios, qu’elle soit redondante ou non. La solution mise en avant dans ce billet est Mod-Gearman qui est un module Nagios abouti, performant et fiable.

Que nécessite cette solution ?

Le DistributedMonitoring de Nagios avec Mod-Gearman nécessite au minimum deux éléments :

Un serveur qui sera à la fois le serveur Nagios et le serveur de jobs Mod-Gearman
Un Worker qui peut être indépendant ou présent sur le serveur de jobs Mod-Gearman

Comment cela fonctionne-t-il ?

Mod-Gearman fonctionne de cette façon :

Un côté Job Server qui distribuera les jobs et rapatriera les résultats
Et un côté Worker qui réalisera les checks sur les hôtes de ses hostgroups

De manière plus précise le fonctionnement détaillé est le suivant:

Le serveur de Jobs attend d’être contacté par des workers
Lorsque les workers contactent le job server , ils s’authentifient auprès de lui, et il les répertorie
Le serveur de jobs dispose d’un Event Broker que l’on insère dans Nagios
Il remplacera donc la partie de Nagios qui réalise les checks, pour pouvoir les distribuer à sa guise

Un worker peut avoir plusieurs hostgroups d’assignés. Pour chaque hostgroup auquel il sera assigné, il prendra les jobs que le serveur de jobs mettra à disposition.

Côté technique

Le serveur de Jobs ne contacte pas les workers. Ce sont les workers qui contactent le serveur de jobs.

Cela implique qu’il soit joignable depuis l’extérieur, mais cela implique surtout que vos workers , à l’abris derrière des firewalls bien configurés, pourront communiquer sans le moindre souci avec votre serveur de jobs. Cela vous épargne de devoir percer le moindre trou dans les Firewalls de vos précieux clients.

Les connexions entre vos workers et votre (ou vos) job server(s) sont chiffrées, vous pouvez configurer votre structure pour désactiver ce chiffrement, si vous le souhaitez. On peut configurer la structure pour gérer les hosts et les services ou alors gérer les hostgroups. Ici j’aborderai la solution Hostgroups, pour le distributed monitoring, le mode host&services serait plutôt du failOver et loadbalancing pur.

Côté pratique

Pour faire simple (mais alors vraiment simple): on installe le serveur jobs sur le serveur de Nagios, on configure le NEB (Nagios Event Broker) dans la configuration de Nagios, et ensuite on configure un worker par site à surveiller, on le branche et c’est terminé. (Oui, aussi simple.)

Plus sérieusement : la configuration sera expliquée plus bas, mais le système est fait de telle façon à accueillir chaque worker qui se connecte au serveur de jobs, et de cette façon la distribution est totalement automatique tant que la configuration des hostgroups et du worker est faite comme il se doit.

Un peu de théorie

Avant de parler d’installation et de configuration, apprenons le concept, et le fonctionnement d’un Nagios fonctionnant avec un Mod-Gearman.

Voici un schéma illustrant mon serveur Nagios en production:

nagios-modgearman

On voit ici la façon dont j’ai architecturé mon Nagios pour gérer des clients facilement.

Chaque dossier client qui se trouve dans /etc/nagios3/conf.d/hosts/ contient un fichier de définition de hostgroup , et un fichier par machine , et un dernier fichier comprennant les personnes de contact à mailer pour les alertes, et les plages horaires.

Le reste des fichiers de configuration sont dans /etc/nagios3/conf.d/

Ici sont les templates utilisés pour tous les clients , et les templates /contacts / timeperiods utilisés pour notre infrastructure.

J’ai représenté deux workers qui contactent, à travers plusieurs Firewalls mon serveur de jobs , qui prend les checks à nagios et qui lui restitue les résultats.

Il n’y a pas de modifications à apporter à Nagios pour dire. Une mention pour chaque hôte lui spécifiant quel worker doit se charger de lui, un Event Broker dans /etc/nagios3/nagios.cfg et c’est tout. Pour le reste c’est de la config de Workers.

Préparatifs et installation étape par étape

Pour préparer un serveur de jobs et un worker, il faut suivre quelques étapes cruciales.

Nous avons besoin avant de commencer :

Un Serveur Nagios 3.4.1 sur une Debian 7 (la manœuvre ne diffère pas beaucoup selon les OS , juste la façon de compiler qui devrait être différente, mais je n’expliquerai ici que la méthode que j’ai réalisé pour Debian, travaillant exclusivement sur cet OS. Merci Antoine Habran 😀 )

Et en bonus : Un Worker Raspberry Pi mod. B. (ou sinon un autre pc.)

En bonus car on peut s’en passer, car le Job Server peut contenir un Worker. Mais l’idée c’est de mettre le Worker ailleurs sur le net et le voir contacter notre serveur, pas vrai ? 

Explications

Nous allons télécharger et installer sur notre serveur Nagios « Gearmand » qui est le « moteur » de mod-gearman , et ensuite, mod-gearman. La seconde étape consiste à configurer Nagios en mode Broker et à configurer le job server. Ensuite, on passera à la création d’un hôte d’exemple pour expliquer comment il sera géré et que vous puissiez vous en inspirer. Pour terminer on configurera un Worker (je ferai un exemple d’un worker Raspberry Pi Mod.B et un worker sur un debian 7 normal sur VM machine physique)

Installation de Mod-Gearman

Ah ouais, là on y est ! les prochaines lignes vont décrire les étapes nécessaires a l’installation de mod-gearman , et on va procéder comme suit :

Installation des packages pour l’installation
Téléchargement de la source de Gearmand
Décompression de la source Gearmand
Compilation de Gearmand
Installation de Gearmand
Téléchargement de la source de mod-gearman
Décompression de la source mod-gearman
Compilation de mod-gearman
Installation de mod-gearman
Configuration du job server mod-gearman
Configuration du N.E.B de Nagios
Configuration du Worker mod-gearman

Là nous aurons un serveur mod-gearman complet et opérationnel.

Il ne manquera qu’un Worker pour surveiller un site distant, mais le serveur sera fonctionnel et autonome, déjà.

D’abord avant de faire quoi que ce soit, il faut installer tous les prérequis pour la compilation et l’installation de gearmand, et mod-gearman.

Donc , si vous avez bien mis à jour votre système (apt-get update , apt-get upgrade)

On lance ceci :

apt-get install libcurl4-gnutls-dev autoconf automake make gcc g++ netcat uuid-dev libltdl7 libltdl-dev libncurses5-dev libevent-dev libboost-dev libboost-graph-dev libboost-iostreams-dev libboost-program-options-dev build-essential libboost-thread-dev libcloog-ppl0

On devrait avoir à ce stade tous les éléments pour la compilation, sauf un (libgearman6) qui doit s’installer après.

On passe ensuite au téléchargement et décompression des sources de Mod-Gearman:

cd /tmp
wget https://launchpad.net/gearmand/1.2/1.1.9/+download/gearmand-1.1.9.tar.gz
tar zxvf gearmand-1.1.9.tar.gz
cd gearmand-1.1.9

Maintenant on prépare le système pour réaliser l’installation de gearmand dans le dossier /opt/ en faisant comme ça , on peut le mettre à jour très facilement et proprement , ou le supprimer. Tapons ces deux lignes :

echo «opt/lib/» /etc/ld.so.conf.d/opt_lib.conf
ldconfig

On lance l’installation:

./configure --prefix=/opt
make
make install

Et si jusqu’ici tout a bien fonctionné et que vous n’avez pas d’erreurs : Le plus dur est fait !.

Maintenant que Gearmand est installé, on peut installer Mod-Gearman.

cd /tmp
wget http://labs.consol.de/wp-content/uploads/2010/09/mod_gearman-1.4.2.tar.gz
tar zxvf mod-gearman-1.4.2.tar.gz
cd mod-gearman-1.4.2

Puis on lance l’installation:

./configure --prefix=/opt --with-gearman=/opt --with-user=nagios --with-init-dir=/etc/init.d
make
make install
make install-config

On doit maintenant copier un fichier vers /etc/init.d pour pouvoir lancer proprement gearmand.

cp ./extras/gearmand-init /etc/init.d/gearmand

ensuite il faut ajouter un shell a l’utilisateur Nagios 

chsh nagios
>> /bin/bash

chmod –R 770 /opt/var/log/mod_gearman
chown –R nagios:nagios /opt/var/log/mod_gearman

Voila qui est fait.

Note: Correction du script de démarrage de Gearmand

Si vous subissez un plantage lorsque vous tentez de démarrer gearmand , (ce qui était systématiquement mon cas…) il y a une modification à faire dans le script de démarrage /etc/init.d/gearmand

Démarrez gearmand :

/etc/init.d/gearmand start

Si vous avez un crash, c’est quasi obligatoirement ceci : La ligne 89 du script contient un argument de verbosité qui fait planter gearmand.

Supprimez l’argument de verbosité dans cette ligne :

CMD= »$DAEMON -p $PORT -P $PIDFILE $OPTIONS –log-file=$LOGFILE –verbose=2 –listen=$LISTEN »

Et retirez le –verbose=2

Cette option, pour une raison qui m’échappe fait planter gearmand.

Si tout fonctionne, arrêtez Gearmand (On le rallumera plus tard).

/etc/init.d/gearmand stop

Configuration du Job Server sur le serveur

Configurons le serveur de jobs pour l’intégrer à nagios et le rendre prêt à accueuillir un worker.

Éditons le fichier de config /opt/etc/mod_gearman_neb.conf:

debug=0
logfile=/opt/var/log/mod_gearman/mod_gearman_neb.log
server=127.0.0.1:4730
do_hostchecks=yes
encryption=yes
key=Superpasswordquidéchire
use_uniq_jobs=on
localhostgroups=
localservicegroups=
queue_custom_variable=WORKER
result_workers=1
perfdata=no
perfdata_mode=1
orphan_host_checks=yes
orphan_service_checks=yes
accept_clear_results=no

Ici l’important, c’est la key, elle doit être identique sur votre fichier NEB et sur vos workers.

La « queue_custom_variable » est essentielle aussi, elle définit ce qui qualifie un worker pour la configuration d’un hôte. Vous verrez pourquoi on définit cette valeur plus loin.

On va passer au worker maintenant.

Configuration du Worker sur le serveur

On va configurer notre serveur pour qu’il surveille le site dans lequel il se trouve. En faisant cela, notre serveur Nagios – mod-Gearmand va surveiller le hostgroup dans lequel vous avez mis toutes vos machines, un peu comme avant l’installation de mod-gearman.

Pour ça , on édite le fichier /opt/etc/mod_gearman_worker.conf (avec quelques informations masquées… je conserve un peu de secret concernant mon infrastructure de production :D):

debug=0
hostgroups=hostgroup1-servers,hostgroup2-servers
logfile=/opt/var/log/mod_gearman/mod_gearman_worker.log
server=127.0.0.1:4730
encryption=yes
key=Superpasswordquidéchire
job_timeout=60
min-worker=5
max-worker=50
idle-timeout=30
max-jobs=1000
spawn-rate=1
fork_on_exec=no
load_limit1=0
load_limit5=0
load_limit15=0
show_error_output=yes
enable_embedded_perl=on
use_embedded_perl_implicitly=off
use_perl_cache=on
p1_file=/opt/share/mod_gearman/mod_gearman_p1.pl
workaround_rc_25=off

Voila, c’est une configuration basique, pour le worker du serveur. Ajoutez les hostgroups que vous souhaitez checker avec CE worker , le mot de passe partagé par le serveur et les workers, et l’ip du serveur. Le reste sert à gérer le comportement du worker, ses limites, seuils.

A partir de là , le système est prêt à fonctionner, mais… pas la configuration de Nagios. On va donc s’occuper de ça !

Configuration de Nagios

Nous devons éditer Nagios pour lui dire que maintenant c’est papa qui s’occupe des checks.

ATTENTION : Ne JAMAIS inclure ou retirer de module BROKER (comme on va faire là) a chaud, ne jamais modifier quelque fichier que ce soit d’un module BROKER a chaud.

Distinction entre fichiers de module et fichier de config de mod-gearman toutefois.

Mod-gearman est indépendant du module broker et peut être redémarrer pendant que nagios tourne. Pour l’inclusion du Broker dans nagios, on arrête celui-ci.

/etc/init.d/nagios3 stop

On va éditer son fichier de configuration /etc/nagios3/nagios.cfg

Broker_module=/opt/lib/mod_gearman/mod_gearman.o config=/opt/etc/mod_gearman_neb.conf

Note: En une ligne séparé d’un espace.

Configuration des hostgroups

Il nous est nécessaire d’avoir une configuration orientée hostgroups pour mettre en place votre architecture distribuée.

Je vais illustrer cette configuration comme sur le schéma du début du document. On va donc créer deux hostgroups : hostgroup1-servers et hostgroup2-servers :

touch /etc/nagios3/conf.d/hosts/client1/hostgroup1.cfg
touch /etc/nagios3/conf.d/hosts/client2/hostgroup2.cfg

ensuite on va ajouter des machines, il nous faut au moins une machine par hostgroup.

touch /etc/nagios3/conf.d/hosts/client1/serveurnagios.cfg
touch /etc/nagios3/conf.d/hosts/client2/serveurlambda.cfg

il nous faut un worker sur le site distant, disons que le client2 est a 200Km d’où je me trouve, je me rend sur place, je déploie un worker, dont on parlera plus bas, et je ne m’en occupe plus, mais il faut le surveiller aussi le petit coquin 

touch /etc/nagios3/conf.d/hosts/client2/worker.cfg

Voici le fichier contenu de mon fichier hostgroup1.cfg:

define hostgroup{
hostgroup_name hostgroup1-servers
alias mes serveurs du hostgroup 1
members hostgroup1-serveurnagios
}

define hostextinfo{
hostgroup_name hostgroup1-servers
notes serveurs du hostgroup1
icon_image base/uneimage.png
icon_image_alt hostgroup1 logo
vrml_image base/uneimage.png
statusmap_image base/uneimage.png
}

Ici rien de spécial, comme vous le voyez. Le hostgroup est défini normalement.

Voici un fichier pour l’hôte « hostgroup1-serveurnagios » /etc/nagios3/conf.d/hosts/hostgroup1/serveurnagios.cfg

define host{
       use generic-host
       host_name hostgroup1-serveurnagios
       alias hostgroup1-serveurnagios
       address 127.0.0.1
       _WORKER hostgroup_hostgroup1-servers
       }

define service{
       use generic-service
       host_name hostgroup1-serveurnagios
       check_command check_ssh
       }

Voila un fichier d’hôte lambda, pour aller avec le fichier de hostgroup correspondant. J’ai mis un service lambda aussi, un check ssh.

Le second hostgroup sera comme suit :

define hostgroup{
hostgroup_name hostgroup2-servers
alias mes serveurs du hostgroup 2
members hostgroup2-serveurlambda,hostgroup2-worker
}

define hostextinfo{
hostgroup_name hostgroup2-servers
notes serveurs du hostgroup2
icon_image base/uneimage2.png
icon_image_alt hostgroup2 logo
vrml_image base/uneimage2.png
statusmap_image base/uneimage2.png
}

Voici le fichier hôte de la machine serveur lambda:

define host{
       use generic-host
       host_name hostgroup2-serveurlambda
       alias hostgroup2-serveurlambda
       address 192.168.1.200
       _WORKER hostgroup_hostgroup2-servers
       }

define service{
       use generic-service
       host_name hostgroup2-serveurlambda
       check_command check_ssh
       }

et le fichier de config du worker

define host{
       use generic-host
       host_name hostgroup2-worker
       alias hostgroup2-worker
       address 192.168.1.100
       _WORKER hostgroup_hostgroup2-servers
       }

define service{
       use generic-service
       host_name hostgroup2-worker
       check_command check_ssh
       }

Configuration du worker présent sur le serveur

Alez sur votre serveur éditer le fichier de config /opt/etc/mod_gearman_worker.conf et modifiez pour que la ligne:

hostgroups=

soit :

hostgroups=hostgroup1-servers

Démarrage de l’infrastructure

D’abord, on va démarrer Nagios, gearmand, ensuite le worker mod-gearman.

/etc/init.d/nagios3 start

/etc/init.d/gearmand start

Et ensuite :

su nagios -c '/etc/init.d/mod_gearman_worker start'

Le worker doit être démarré par l’utilisateur Nagios pour fonctionner. Donc on l’éxécute avec la commande su et l’option -c .

Pour faciliter les choses, éditez /etc/rc.local et ajoutez les deux lignes :

/etc/init.d/gearmand start
su nagios -c '/etc/init.d/mod_gearman_worker start'

Note: AVANT la ligne “exit 0” (sinon ça ne fonctionnera pas)

Et comme ça à chaque reboot vos services seront exécutés comme il se doit.

Là tout devrait tourner proprement, et les checks pour votre serveur Nagios être exécutés, pas les autres.

Le worker du hostgroup2 et le serveur lambda du hostgroup2 qui n’existent d’ailleurs pas ne devraient pas rendre de critical car ils ne sont pas pris en charge.Il vous faudra ajouter un worker avec la ligne :

Hostgroups=hostgroup2-servers

On peut évidemment mettre plusieurs workers pour un seul hostgroup, il suffit de les mettre avec la même configuration.

Worker Raspberry Pi Mod. B

Ce que je trouve magique avec l’architecture distribuée Gearman , c’est qu’elle peut être utilisée avec des Raspberry… Si vous ne connaissez pas, vous devriez vraiment vous pencher sur ces machines merveilleuses !

Pour réaliser un worker sur un raspberry PI mod.B , rien de plus simple. Une fois l’installation du Raspbian faite sur votre carte SD, lancez votre raspberry, configurez le avec le raspi-config, et ensuite mettez le à jour . (apt-get update , apt-get upgrade)

Ensuite, on tape :

apt-get install mod-gearman-worker

Il va s’installer, et vous n’aurez qu’à le configurer basiquement pour qu’il soit pris en charge 

Exemple de config : /etc/mod-gearman-worker/worker.conf

server=ippublique:4730
key= Superpasswordquidéchire
hostgroup=hostgroup2-servers
encryption=yes
job_timeout=60
p1_file=/usr/share/mod-gearman/mod_gearman_p1.pl

Ouais… C’est tout!

Par défaut il va gérer le worker comme un petit chef, rien besoin de plus que ceci.

Le serveur, le password, le(s) hostgroup(s) , l’encryption, et par contre…

SURTOUT spécifier ce job_timeout=60 (60 ou ce qui conviendra à vos check, si vous avez par ex. un check qui met 2Mn à rendre son résultat, montez la valeur)

Si vous ne le faites pas et qu’un check « casse » en route, suite à un souci de connexion ou autre, votre worker attendra vita aeternam le résultat , et sera par conséquent… Planté ! ça ne vous ferait pas plaisir de faire 200Km en voiture pour débrancher et rebrancher un pc grand comme une carte de crédit, pas vrai ? (Comment ça, ça sent le vécu ? Je ne vous perm… oui c’est vrai.)

Donc , créez une machine virtuelle ou autre, sur une range inaccessible par votre serveur Nagios, avec l’ip spécifiée dans le fichier de config, (192.168.1.200) configurez la pour qu’elle réponde au ping et au ssh. Ensuite branchez un worker configuré comme expliqué sur le réseau ou elle se trouve… (en respectant la config d’ip selon le fichier de config dans nagios bien sûr)

Et comme par magie les deux machines seront prises en charge, de part leur configuration , le worker va contacter le job server, lui signaler sa présence, et là il enverra des tâches de check au worker qui les éxécutera et renverra le résultat au job server qui lui-même répondra à Nagios.

Surveillance des jobs

Je vous vois venir, vous pensez : « Mais comment est-ce que je vois ce qui se passe derrière tout ça ?

Et bien il y a une solution toute faite : gearman_top !

Il se trouve dans /opt/bin/

On peut ajouter son path dans la variable path en ajoutant :

PATH=$PATH:/opt/bin

Dans le fichier /root/.bashrc

Comme ça, vous pourrez le lancer comme n’importe quelle commande.

Lancez le , et admirez :

capture_115

Voici une petite illustration d’une infrastructure avec 8 hostgroups , et des workers.

J’ai mis un serveur qui en gère 6 à lui seul , et 2 workers qui en gèrent un chacun.

J’ai utilisé des noms de clients donc je les ai censurés pour cet exemple.

Performances

Mod-gearman améliore énormément les performances de Nagios !

Même si vous ne comptez ni utiliser le distributed monitoring, ni le load balancing, ou le fail over, le choix d’utiliser mod-gearman sur votre nagios améliorera très nettement (on parle là de la moitié de consommation processeur, mesdammes !) les performances du serveur Nagios.

Pour les cas testés, et pas uniquement par moi, les gains de performances sont de pratiquement 50%

Tests réalisés sur des serveurs qui ont une utilisation moyenne de 55-60% de processeur, le fait de juste passer sur Gearman fait chuter la consommation processeur vers les 25%.

Mod-gearman EST un must, chers amis !

Problèmes rencontrés

Voici une petite liste des problèmes que j’ai rencontré en démarrant seul sans aucune info sur mod-gearman , le jour ou j’ai décidé de me pencher sur cette technologie et d’apprendre a partir de rien à m’en servir.

Timeout sur workers :

Au début je n’avais pas défini de temps de timeout sur les workers… ça m’a vallu un déplacement aussi long qu’inutile pour aller reboot le raspberry pi, n’oubliez pas de définir le job_timeout= sur vos workers…

Compilation gearman :

En temps normal je me contente de faire apt-get install lorsque j’ai besoin de quelque chose.

Or quand j’ai commencé à me servir de mod-gearman, les packages n’étaient pas disponibles en repo pour l’apt-get install… donc j’ai du me mettre à le compiler moi-même , d’où la procédure ou on voit sa compilation alors que des versions (évidemment pas aussi à jour que celle expliquée ici, au jour ou j’écris ceci) sont disponible en repo…

Je n’ai certainement pas réalisé le sans fautes, probable que certains packages dans la phase d’installation des paquets ne sont pas essentiels, mais j’ai trié au maximum et je pense avoir fait ça proprement. Je suis preneur pour toute suggestion ou remarque 

Plantage gearmand au lancement :

Comme je le décris dans la procédure, il y a un plantage qui peut survenir au lancement de gearmand , qui se corrige par une modification du fichier dans /etc/init.d , ce problème m’a fait perdre pas loin d’une semaine, en ayant retourné le problème dans TOUS les sens , j’étais loin de suspecter qu’une option de verbosité, normalement présente pour aider a la résolution de problèmes de pantages, soit la cause du problème que je traquais… Comme quoi, il faut se méfier de tout.

Surveillance des workers

Je conclus cette rubrique par ce point, la surveillance de vos workers.

Si vous avez bien compris le fonctionnement des workers, on peut déceler une faille…

Si un worker n’est plus accessible, comment va-t-il répondre au job server pour dire qu’il n’est pas accessible ? On est d’accord c’est impossible. Alors, comment déterminer si un worker est OOR (out of range) ou non ?

J’ai pondu un petit script utilisant gearman_top qui permet ça. Le voici :

Le script:

#!/bin/bash

basevalue=`/opt/bin/gearman_top -b | grep "hostgroup_$1-servers"`

value1=`echo $basevalue | cut -d "|" -f3 | tr -d ' '`

value2=`echo $basevalue | cut -d "|" -f4 | tr -d ' '`

value3=`echo $basevalue | cut -d "|" -f2 | tr -d ' '`

critical=$2

threshold=$(($2/2))

if [[ $value1 -gt $critical ]]

then    if [[ $value2 -gt $threshold ]]

       then

               echo " Accumulation de Jobs sur le worker $1, attention!"

               echo " $value1 jobs en attente , $value2 jobs en cours "

               retval=1;

               else

               echo " Le worker $1 ne prend plus de Jobs, Critical! "

               echo " $value1 jobs en attente!"

               retval=2;

       fi

else

echo "Tout va bien. $value1 Wait $value2 run $value3 avail"

echo "$value1 jobs en attente, $value2 jobs en cours et $value3 workers dispo."

retval=0;

fi

exit $retval;

le fichier de definition de commande:

define command{

       command_name    check_workers

       command_line    /usr/lib/nagios/plugins/check_workers.sh $ARG1$ $ARG2$

       }

Et un exemple utilisé sur mon serveur :

define service{

       use                     generic-service

       host_name               ALTAIR-SRV-NAGIOS01

       service_description     Worker Altair

       check_command           check_workers!altair!15

       }

Ma société veut que les jobs en attente, en exécution et les workers prêts à traiter pour le hostgroup altair me soit rendus, et dans le script , j’éxécute gearman_top avec l’option –b qui ne rend qu’une réponse, et utilisable en script, je trie avec un grep pour obtenir le nom qui m’intéresse, et ensuite je décortique les chiffres, et définis selon le nombre de jobs waiting que je veux d’avoir une alerte s’ils atteignent ce seuil, avec une petite sécurité toutefois, s’il y a une accumulation de checks pour une raison , peu importe laquelle, mais que mon worker travaille, je ne veux pas recevoir d’alerte. Je le laisse bosser…

Étiquettes distributed, mod-gearman, nagios