Le monde du monitoring est sûrement plus stable que les services et produits qui sont eux-mêmes « monitorés ». C'est pourquoi j'ai eu envie de voir ce que l'on pouvait faire à ce niveau-là avec les technologies d'aujourd'hui… Force est de constater que je ne m'attendais pas à un tel résultat.
Allons-y, je vais vous conter mes péripéties.
1. Préparation des paquetages avant l'ascension
Plutôt que d'utiliser une solution de monitoring « tout-en-un », je préfère une fois de plus construire mon système grâce à différentes briques que je juge complémentaires. Ma distribution serveur du moment étant Ubuntu, cet article se base sur la dernière version « LTS » (soit Ubuntu 16.04). Cependant, vu que nous allons utiliser Docker, la distribution de l'OS n'aura au final que très peu d'importance.
1.1 Installation de Docker
J’espère que vous êtes bien harnachés, car c’est parti.
Nous allons installer Docker « Community Edition » avec la dernière méthode en date.
Tout d’abord les « prérequis » :
$ sudo apt-get install -y apt-transport-https software-properties-common ca-certificates curl
Ajoutons ensuite le dépôt adéquat :
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
$ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
Il faut désormais mettre à jour la liste de nos dépôts afin de prendre en compte l’ajout :
$ sudo apt-get update
Et enfin, nous pouvons installer la dernière version de Docker ainsi que docker-compose que nous utiliserons pour gérer nos containers :
$ sudo apt-get -y install docker-ce docker-compose
L’étape suivante n’est pas obligatoire, mais j’aime bien configurer mes installations de Docker de la sorte. Il s’agit simplement d’ajouter son utilisateur au groupe docker afin de pouvoir lancer Docker sans passer « sudo » :
$ sudo usermod -aG docker MonUser
Afin de prendre en compte les changements, vous devrez vous déconnecter / reconnecter.
1.2 Configuration du réseau Docker
Dans la partie qui va suivre, nous allons voir comment créer un réseau « dédié » à nos containers de monitoring. Pour une fois, nous allons pouvoir ajouter une couche de sécurité tout en ajoutant aussi une couche de praticité. Qui a dit qu’il fallait choisir entre sécurité et praticité ?
En effet, par défaut Docker crée ses containers avec des IP dynamiques et les changent à chaque redémarrage des containers.
Nous ajoutons donc le côté pratique d’avoir une IP fixe et un nom d’hôte pour chaque container tout en isolant les containers du réseau principal. Cette isolation va permettre à nos containers d’ouvrir des ports uniquement visibles par eux-mêmes et non pas par le reste du monde.
$ docker network create --driver bridge br0
Vérifions que notre nouveau réseau est disponible avec la commande suivante :
$ docker network ls
NETWORK ID NAME DRIVER SCOPE
f5fa89b94de4 br0 bridge local
193d033921f1 bridge bridge local
49e3217679f9 host host local
d7e622968ebb none null local
Et… voilà, c’est tout ! Docker est installé et fonctionnel, voilà le premier palier franchi.
2. Récupération et lancement des images
Attaquons-nous au palier suivant, mais n’ayez crainte, l’ascension n’en sera pas pour autant plus compliquée. En cas de chute, je suis là et je tiens la corde.
J’ai pour habitude de placer mes images Docker dans un répertoire dédié :
$ sudo mkdir -p /srv/data/apps/{glances,influxdb,grafana,nginx}
$ chown -R MonUser: /srv/data
2.1 InfluxDB
À partir du bon répertoire, construisons un fichier /srv/data/apps/influxdb/docker-compose.yml :
# docker-compose for influxDB
version: '2'
services:
influxdb:
image: influxdb
container_name: influxdb
ports:
# - "8083:8083"
- "8086:8086"
- "2003:2003"
volumes:
- influxdb-storage:/var/lib/influxdb
environment:
- INFLUXDB_GRAPHITE_ENABLED=true
restart: always
networks:
default:
aliases:
- influxdb
networks:
default:
external:
name: br0
volumes:
influxdb-storage:
Nous pouvons désormais lancer notre premier container. Vu qu’il s’agit du premier lancement, la dernière image en date d'InfluxDB sera aussi téléchargée :
$ docker-compose up -d
Afin de vérifier que tout est en ordre, nous pouvons exécuter la commande suivante :
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
01c53fe77784 influxdb "/entrypoint.sh in..." 20 minutes ago Up 20 minutes 0.0.0.0:2003->2003/tcp, 8086/tcp influxdb
Vous constaterez que le statut du container nommé influxdb indique Up : cela veut dire que tout fonctionne.
Ensuite, nous devons créer une base de données au sein d’InfluxDB afin d’y stocker les statistiques venant de Glances. La première étape consiste à entrer dans le container d’InfluxDB :
$ docker exec -it influxdb bash
Une fois dans le container, connectons-nous à InfluxDB :
$ influx
La dernière étape consiste à créer la base, l’utilisateur, et lui donner les droits :
Connected to http://localhost:8086 version 1.2.2
InfluxDB shell version: 1.2.2
> create database glances
> create user "glances" with password 'MyPass'
> grant all on "glances" to "glances"
> exit
Pour quitter le container et revenir à notre hôte, un simple <Ctrl> + <d> suffit.
Attaquons-nous désormais à la collecte des statistiques avec Glances [1].
2.2 Glances
Même procédure que précédemment ; nous nous plaçons dans le bon répertoire et créons notre fichier de configuration principal /srv/data/apps/glances/docker-compose.yml :
# docker-compose for Glances
version: '2'
services:
glances:
image: docker.io/nicolargo/glances
container_name: glances
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
- ./conf/glances.conf:/glances/conf/glances.conf
- ./scripts:/scripts
# - /home/MonUser/fake:/srv/fake
environment:
- GLANCES_OPT=-q --export-influxdb
pid: "host"
restart: always
networks:
default:
aliases:
- glances
networks:
default:
external:
name: br0
En fonction de votre partitionnement, il se peut que le container de Glances ne voit pas toutes vos partitions. Dans ce cas, je vous recommande de créer un dossier « bidon » sur les partitions en question et de le monter via le fichier docker-compose.yml (cf. le dossier /srv/fake dans ma config).
Ensuite, nous allons créer les dossiers, fichiers de configuration et points de montage nécessaires au lancement de Glances en nous basant sur le fichier que nous venons de créer :
$ mkdir {conf,scripts}
Pour ce qui est de la configuration de Glances, elle se trouve dans /srv/data/apps/glances/conf/glances.conf. Je vous présente uniquement les parties les plus « intéressantes », le reste étant les valeurs par défaut. De plus, vous trouverez tous mes fichiers de configuration sur mon GitHub [2].
[load]
careful=0.7
warning=1.0
critical=5.0
critical_action=sh /scripts/send_sms.sh "Load:: `uptime`"
[mem]
careful=50
warning=70
ceitical=90
critical_action=sh /scripts/send_sms.sh "Free mem: `free -m | grep Mem | awk '{print $4}'`"
[fs]
careful=50
warning=70
critical=90
critical_action=sh /scripts/send_sms.sh "Disk: `df -h | grep md | grep 9[0-9]`"
[influxdb]
host=influxdb
port=8086
user=glances
password=MyPass
db=glances
prefix=ubunmonit
[amp_nginx]
enable=true
regex=nginx
refresh=60
one_line=false
status_url=http://nginx/nginx_status
Comme nous pouvons le voir dans la config ci-dessus, j’utilise un script « maison » pour envoyer des alertes par SMS lorsqu’un seuil critique est atteint. Voici le script scripts/send_sms.sh en question :
#!/bin/bash
curl -k "https://smsapi.free-mobile.fr/sendmsg?user=MonUser&pass=MyPass&msg=Ubunmonit - $1"
N’oubliez pas de rendre votre script exécutable :
$ chmod +x scripts/send_sms.sh
Ce script permet d’envoyer des SMS via l’API Free mobile [3]. Dans le cas où vous n’utiliseriez pas Free, il existe des méthodes similaires (ou basées sur l’envoi de mails) chez les autres opérateurs, voire chez des prestataires externes.
Construisons notre container :
$ docker-compose up -d
Encore une fois, nous pouvons vérifier que tout fonctionne avec docker ps. En cas d’erreur, pour « débugger » , nous pouvons utiliser la commande docker logs -f glances, ou encore docker exec -it glances bash (si le container est Up) pour aller « fouiller » dans le container.
Admettons que tout fonctionne, et allons voir dans notre base InfluxDB si nous avons récolté des données :
$ docker exec -it influxdb bash
root@01c53fe77784:/# influx
Connected to http://localhost:8086 version 1.2.2
InfluxDB shell version: 1.2.2
> show databases
name: databases
name
----
_internal
glances
> use glances
Using database glances
> show measurements
name: measurements
name
----
ubunmonit.cpu
ubunmonit.diskio
ubunmonit.docker
ubunmonit.fs
ubunmonit.ip
ubunmonit.load
ubunmonit.mem
ubunmonit.memswap
ubunmonit.network
ubunmonit.percpu
ubunmonit.processcount
ubunmonit.sensors
ubunmonit.uptime
Parfait ! Glances communique avec InfluxDB et la base commence à stocker nos différentes statistiques.
J’ai beau adorer mon terminal, quand il s’agit de statistiques je préfère quand même avoir des graphiques et une représentation plus « visuelle ». Ça tombe bien, c’est exactement le rôle de Grafana.
2.3 Grafana
Pour ne pas déroger à la règle, nous allons créer le fichier suivant /srv/data/apps/grafana/docker-compose.yml :
# docker-compose for Grafana
version: '2'
services:
grafana:
image: grafana/grafana
container_name: grafana
# ports:
# - "3000:3000"
volumes:
- grafana-storage:/var/lib/grafana
environment:
- GF_SECURITY_ADMIN_PASSWORD=An0th3rP4ss
restart: always
networks:
default:
aliases:
- grafana
networks:
default:
external:
name: br0
volumes:
grafana-storage:
Et nous lançons le container :
$ docker-compose up -d
Comme vous pouvez le remarquer, j’ai décidé de ne pas « exposer » le port 3000. C’est-à-dire qu’à l’heure actuelle, notre interface graphique n’est pas visible depuis l’extérieur de notre serveur.
Vérifions :
$ netstat -tulpn
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp6 0 0 :::2003 :::* LISTEN -
tcp6 0 0 :::22 :::* LISTEN -
udp 0 0 0.0.0.0:68 0.0.0.0:* -
Effectivement, seuls SSH (22/tcp), DHCP (68/udp) et 2003/tcp sont visibles depuis l’extérieur. Pour ce qui est du port 2003/tcp, il provient du container InfluxDB et correspond à une base Graphite dans laquelle je stocke les informations provenant de mon NAS (nous verrons cela plus tard).
Un simple docker ps nous confirme tout de même que le port 3000 (par exemple) est utilisé :
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
6a061326eb47 grafana/grafana "/run.sh" 6 minutes ago Up 6 minutes 3000/tcp grafana
01c53fe77784 influxdb "/entrypoint.sh in..." 32 minutes ago Up 32 minutes 0.0.0.0:2003->2003/tcp, 8086/tcp influxdb
93e983755929 docker.io/nicolargo/glances "/bin/sh -c 'pytho..." 43 minutes ago Up 21 minutes 61208-61209/tcp glances
Mais comment allons-nous y accéder ? La réponse à cette question après la pu… ou plutôt après un petit bonus : récupérer les stats de FreeNAS.
2.4 Bonus : FreeNAS
J’utilise un NAS « maison » basé sur FreeNAS. Ce dernier propose d’envoyer ses statistiques vers une « base de données » Graphite.
Côté FreeNAS 9.x, il faut aller dans , et renseigner l’adresse de votre serveur InfluxDB dans la partie .
Côté InfluxDB, la configuration est faite via le fichier docker-compose.yml que nous avons utilisé. Voilà, c’est tout ! En admettant qu’il n’y ait pas de pare-feu entre votre NAS et le serveur qui fait tourner votre container InfluxDB, cela fonctionnera.
Il est grand temps d’afficher tout ce que nous sommes en train de collecter. Pour ce faire, nous allons utiliser un reverse proxy NGiNX avec des certificats « SSL » (notez les guillemets).
3. Consultation des stats via un reverse proxy
Troisième et avant-dernier palier. Le sommet est en vue, mais l’oxygène se raréfie. Essayons tout de même de rester concentrés.
3.1 Du httpS pour tous !
Tout d’abord, un grand merci à toute l’équipe de Let’s Encrypt [4]. Grâce à leur projet, nous pouvons désormais utiliser des certificats « SSL » facilement et gratuitement. Il n’y a donc aucune raison de s’en passer. Installons le paquetage certbot pour gérer nos certificats :
$ sudo add-apt-repository ppa:certbot/certbot
$ sudo apt-get update
$ sudo apt-get install -y letsencrypt
Ensuite, nous générons le certificat pour notre virtual host Grafana. J’utilise un sous-domaine du genre grafana.monserveur.com :
$ sudo letsencrypt certonly --standalone -d grafana.monserveur.com
Afin que Let’s Encrypt puisse vous attribuer un certificat, il faut que votre sous-domaine soit valide. C’est-à-dire qu’un enregistrement DNS doit exister et pointer vers l’IP de votre serveur.
Répondez aux questions et voilà, si tout s’est passé comme prévu, vous trouverez vos certificats et clefs dans :
$ sudo ls -l /etc/letsencrypt/
total 24
drwx------ 4 root root 4096 Oct 27 07:31 accounts
drwx------ 14 root root 4096 Nov 28 05:37 archive
drwxr-xr-x 2 root root 4096 Apr 22 02:50 csr
drwx------ 2 root root 4096 Apr 22 02:50 keys
drwx------ 14 root root 4096 Nov 28 05:37 live
drwxr-xr-x 2 root root 4096 Apr 22 02:50 renewal
Le seul « inconvénient » avec Let’s Encrypt, c’est que les certificats ne sont valables que trois mois. Il est donc nécessaire de mettre en place un renouvellement automatique. C’est que nous allons faire avec systemd (oui, oui, l’horrible systemd).
Il faut tout d’abord créer un service /etc/systemd/system/renew-letsencrypt.service :
[Unit]
Description=Renew Let's Encrypt certificates
[Service]
Type=oneshot
# check for renewal, only start/stop nginx if certs need to be renewed
ExecStart=/usr/bin/letsencrypt renew --agree-tos --pre-hook "/usr/bin/docker stop nginx" --post-hook "/usr/bin/docker start nginx"
Ensuite un timer /etc/systemd/system/renew-letsencrypt.timer :
[Unit]
Description=Daily renewal of Let's Encrypt's certificates
[Timer]
# once a day, at 2AM
OnCalendar=*-*-* 02:00:00
# Be kind to the Let's Encrypt servers: add a random delay of 3600 seconds
RandomizedDelaySec=3600
Persistent=true
[Install]
WantedBy=timers.target
Indiquons à systemd que nous venons d’ajouter un service :
$ sudo systemctl daemon-reload
Ensuite, démarrons le service :
$ sudo systemctl start renew-letsencrypt.timer
Et si tout se passe bien, alors activons ce service pour qu’il se lance automatiquement à chaque démarrage du serveur :
$ sudo systemctl enable renew-letsencrypt.timer
Vous pouvez vérifier que votre timer a bien été pris en compte avec la commande suivante :
$ sudo systemctl list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES
Thu 2017-04-27 07:49:57 PDT 1h 17min left Thu 2017-04-27 01:01:20 PDT 5h 30min ago apt-daily.timer apt-daily.service
Thu 2017-04-27 12:06:28 PDT 5h 34min left Thu 2017-04-27 00:48:40 PDT 5h 43min ago certbot.timer certbot.service
Fri 2017-04-28 02:29:20 PDT 19h left Thu 2017-04-27 02:29:20 PDT 4h 2min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean
3 timers listed.
3.2 Mise en place du reverse proxy
Encore une fois, et cette fois-ci, promis, c’est la dernière : nous allons créer un nouveau fichier docker-compose.ymldans /srv/data/apps/nginx qui ressemblera à cela :
# docker-compose for Nginx
version: '2'
services:
nginx:
image: nginx
container_name: nginx
ports:
- "443:443"
- "80:80"
volumes:
- ./conf.d:/etc/nginx/conf.d
- /etc/letsencrypt:/etc/nginx/ssl
- /srv/data/ssl/dhparam.pem:/etc/nginx/cert/dhparam.pem
#environment:
restart: always
networks:
default:
aliases:
- nginx
networks:
default:
external:
name: br0
Les configurations de nos virtual hosts résident dans un dossier dédié :
$ mkdir -p /srv/data/apps/nginx/conf.d/vhost
Préparons la voie pour la config « SSL » :
$ mkdir /srv/data/ssl
$ cd /srv/data/ssl/ && openssl dhparam -out dhparam.pem 4096
Commençons par créer un vhost pour obtenir le statut de NGiNX lui-même afin que Glances puisse collecter des statistiques sur son usage (fichier /srv/data/apps/nginx/conf.d/vhost/status.conf) :
server {
listen 80;
location /nginx_status {
stub_status on;
access_log off;
allow 172.0.0.0/8;
deny all;
}
}
Ensuite le vhost pour Grafana (fichier grafana.conf dans le même répertoire) :
server {
listen 80;
server_name grafana.monserveur.com;
return 301 https://$server_name$request_uri;
}
server {
listen 443 ssl;
ssl_certificate /etc/nginx/ssl/live/grafana.monserveur.com/fullchain.pem;
ssl_certificate_key /etc/nginx/ssl/live/grafana.monserveur.com/privkey.pem;
ssl_dhparam /etc/nginx/cert/dhparam.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
server_name grafana.monserveur.com;
access_log on;
location / {
proxy_pass http://grafana:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-for $remote_addr;
port_in_redirect off;
proxy_connect_timeout 300;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/local/nginx/html;
}
}
Notez bien les valeurs ssl_certificate et ssl_certificate_key qui pointent vers votre dossier Let’s Encrypt qui a été monté dans le container via le fichier docker-compose.yml.
N’oublions pas de créer des liens symboliques depuis le dossier conf.d vers le dossier contenant nos vhosts. De la sorte, il sera plus facile d’ajouter/supprimer des vhosts à notre serveur web :
$ cd /srv/data/apps/nginx/conf.d
$ ln -s vhost/status.conf status.conf
$ ln -s vhost/grafana.conf grafana.conf
Et on démarre notre container :
$ cd /srv/data/apps/nginx
$ docker-compose up -d
L’heure de vérité a sonné, essayons de nous connecter à Grafana !
4. Visualisation des stats dans Grafana
Ouvrez votre navigateur et rendez-vous sur : https://grafana.monserveur.com ! Le login par défaut est admin, et le mot de passe An0th3rP4ss (ou celui que vous avez entré dans le fichier docker-compose.yml correspondant à Grafana).
Cerise sur le gâteau, votre site passe parfaitement le test du certificat « SSL », et vous obtenez la meilleure note possible, A+ ! [5]
4.1 Ajout des sources
La toute première chose à faire (sans parler de changer le mot de passe et/ou créer des utilisateurs) consiste à définir vos « Data sources ». Pour ce faire, il faut cliquer dans le coin supérieur gauche sur le .
La première source que nous allons ajouter sera Glances. Nommez donc la source comme bon vous semble puis sélectionnez comme type. Pour l’URL, il s’agit de http://influxdb:8086, l’access sur proxy, et enfin les informations concernant la base, à savoir glances comme nom de base et d’utilisateur et le mot de passe défini dans la section influxdb.
Si vous utilisez FreeNAS, répétez la même opération avec les informations adéquates.
4.2 Aperçu des possibilités
Il serait trop long d’expliquer Grafana en détail, je vais donc simplement donner un aperçu du fonctionnement ainsi que de ses possibilités.
Tout d’abord, Grafana fonctionne par dashboard (tableau de bord dans notre langue). J’utilise par exemple un tableau de bord par périphérique. Pour illustrer cet article, nous aurions donc un tableau de bord pour notre serveur surveillé via Glances et un second pour notre NAS.
Au sein de chaque tableau de bord, vous allez pouvoir ajouter le suivi de différentes statistiques. Admettons que vous vouliez voir l’usage de la mémoire au fil du temps, alors vous allez probablement utiliser un graphe. Par contre, si vous voulez obtenir le nombre de processus à un instant t, alors vous préfèrerez probablement avoir une simple valeur en évidence sur votre tableau de bord. Ces différents éléments sont appelés des panels (panneaux en français, même si cela ne sonne pas très bien). Il existe tout un tas de panneaux, comme des tableaux, des listes, des cartes du monde, des camemberts, etc.
Ces panneaux ainsi que les tableaux de bord peuvent être téléchargés via le site officiel et sont produits par la « communauté ».
4.3 Gestion des dashboards
Venons-en donc aux fameux tableaux de bord. Il s’agit d’un ensemble de panneaux qui forment un tout plus ou moins cohérent.
Pour vous donner un exemple, le tableau de bord correspondant à mon serveur me donne :
- des graphes d’utilisation CPU/mémoire/disque/ressources par containers ;
- un instantané du nombre de processus/espace disque, etc.
Ces tableaux de bord peuvent être facilement importés/exportés sous forme de fichier .json.
Vous remarquez que la « data source » est souvent indiquée directement dans le fichier .json, ainsi que le nom des interfaces réseaux par exemple. Pensez donc à modifier ce fichier avant de l’importer afin de ne pas avoir à le faire graphiquement (ce qui sera plus contraignant).
Conclusion
Félicitations, nous voici arrivés au sommet, et en un seul morceau !
Durant notre ascension, nous avons vu comment tirer profit de technologies assez diverses et récentes pour construire un système de monitoring sur mesure. Je ne prétends pas que ce système est parfait, ni même viable en production. Je l’utilise uniquement sur un serveur personnel et j’ai mis en place cette solution dans le but de me familiariser avec ces technologies. Ayant trouvé l’expérience intéressante, j’ai décidé de la partager avec vous.
Les possibilités sont nombreuses. Il est par exemple possible de surveiller des appareils envoyant des données via SNMP (comme pfSense par exemple, ou des APs Cisco).
Malheureusement, mettre au point un tel système prend un temps certain. On ne parle clairement pas d’une solution « clef en main » comme du Zabbix. C’est de la « bidouille », mais c’est aussi pour cela qu’on aime le faire, n’est-ce pas ?
Pour aller encore plus haut...
Comme je le disais précédemment, ce système est très modulaire et les possibilités sont nombreuses, tout comme les améliorations. Vous avez peut-être retenu que nous avions utilisé un léger « hack » avec des points de montage bidons dans le container de Glances pour afficher les partitions manquantes. Il reste cependant un problème avec Glances dans un container, c’est qu’il ne voit pas l’interface réseau physique de notre serveur ! Impossible donc de surveiller en l’état cette interface.
De plus, aucun de nos containers n'est capable (tels qu’ils sont configurés) d’envoyer des e-mails, cela peut poser problème pour envoyer un message de création de compte et/ou oubli de mot de passe depuis Grafana par exemple…
Comme souvent dans ce domaine, le travail n’est jamais fini… et il y aura encore de la place pour améliorer et optimiser au fur et à mesure des installations et/ou des nouveaux outils disponibles.
Références
[1] Site officiel de Glances par nicolargo : https://nicolargo.github.io/glances/
[2] Les différents fichiers de configuration sur GitHub : https://github.com/Nesousx/glaraflux
[3] Fonctionnement de l’API SMS Free : http://www.universfreebox.com/article/26337/Nouveau-Free-Mobile-lance-un-systeme-de-notification-SMS-pour-vos-appareils-connectes
[4] Let’s Encrypt - le httpS pour tous : https://letsencrypt.org/
[5] Testez votre certificat « SSL » : https://www.ssllabs.com/ssltest/