Rechercher dans la communauté

1. Préambule Ce guide a pour but de permettre à tout un chacun de centraliser la gestion de ses conteneurs sur une seule et même instance Docker, et ce de manière sécurisée. Sur une distribution Linux classique ou même Windows il est possible d'exposer une instance Docker via TCP, donc la rendre accessible sur un port de la machine hôte, 2375 en non-sécurisé, 2376 par TLS. De manière générale c'est quelque chose qu'on évite, car Docker possède des privilèges élevés sur sa machine hôte, c'est donc une source de contamination potentiellement dévastatrice. En prenant soin de placer un certain nombre de garde-fous, et en maîtrisant les points de sécurisation abordés dans les tutoriels références du forum (en premier lieu celui sur la sécurisation), l'idée devient tout à fait envisageable. Il y a deux avantages majeurs à cette méthode : - Elle est applicable à n'importe quelle machine, votre NAS, un PC sous Linux, un micro-processeur type Raspberry, un VPS, un serveur dédié, etc... - Elle permet de s'affranchir des limitations de certains OS, typiquement DSM. On peut tout à fait exposer par TCP l'instance Docker d'un NAS Syno sans passer par un proxy sauf qu'à chaque redémarrage les modifications sont effacées et il faudra de nouveau modifier la ligne de commande de démarrage du démon Docker. Un script pourrait sûrement tout à fait se charger de la tâche, reste que l'on touche à des fichiers systèmes sensibles, je suis partisan du fait de garder un DSM "stock" pour éviter des problèmes lors des mises à jour et des incompatibilités/bugs qui en découlent fréquemment. 2. Prérequis Savoir protéger ses périphériques (pare-feu) Savoir établir une connexion suffisamment sécurisée entre deux machines Savoir rediriger un port Avoir des bases concernant Docker (voir tutoriel introductif) Savoir se connecter en SSH à un périphérique Avoir défini un nom de domaine entièrement qualifié (FQDN en anglais - Fully Qualified Domain Name) pour l'instance Docker cible Difficulté : Moyenne 3. Sécurisation Pour garantir un certain degré de sécurité, l'idée va être d'exposer le socket Docker via un proxy, ce qui sera réalisé par un conteneur sur l'hôte cible, avec lequel nous établirons une connexion TLS depuis l'instance centralisatrice. Sa localisation peut être quelconque : sur le même réseau local, accessible à distance par HTTPS ou encore par VPN. Le choix de la solution et la sécurisation de l'environnement sont à votre discrétion et découlent des pré-requis stipulés ci-dessus. 4. Portainer Pour faciliter la visualisation de mes instances Docker (ou environment) et mes conteneurs, j'utilise l'application Portainer sur la machine qui va servir de centre névralgique pour toutes mes instances. Elle a l'avantage de fournir une interface claire, efficace et intuitive. (Notons qu'il est tout à fait possible de s'en passer et de se cantonner à de la ligne de commande, voir documentation Docker dont le lien est donné plus loin). Un fichier docker-compose.yml adapté aux NAS pour Portainer : version: '2.1' services: portainer: image: portainer/portainer-ce container_name: portainer network_mode: bridge volumes: - /volume1/docker/portainer/data:/data - /var/run/docker.sock:/var/run/docker.sock ports: - 9000:9000 restart: unless-stopped Puis on se place dans le dossier où se trouve le fichier docker-compose.yml précédent et on tape la commande suivante : docker-compose up -d Ou on passe par lignes de commande : docker create \ --name=portainer \ --net=bridge \ --restart=unless-stopped \ -v /volume1/docker/portainer/data:/data \ -v /var/run/docker.sock:/var/run/docker.sock \ -p 9000:9000 \ portainer/portainer-ce Puis on tape : docker start portainer Remarque : /volume1/docker/portainer/data est un emplacement adapté pour un NAS Synology, il faudra auparavant créer le dossier portainer et data dans le dossier partagé docker dans File Station. La première fois qu'on se connecte (via http://IP:9000), on est amené à choisir un login et un mot de passe admin. Ce faisant on arrive sur un écran demandant de choisir l'environment qu'on souhaite configurer, il faut choisir local et valider successivement les écrans. On arrive rapidement à un écran de la sorte : Je ne rentre pas dans le détail de l'utilisation de Portainer, on trouve des tutoriels relativement bien faits sur Youtube et Google, et c'est de toute façon assez simple à prendre en main : - https://www.youtube.com/watch?v=GNG6PDFxQyQ (à 1:36 on parle précisément de ce qu'on cherche à faire dans ce guide) - https://domopi.eu/ameliorer-la-gestion-de-vos-containers-docker-avec-portainer/ 5. Méthodes au choix Plusieurs méthodes sont disponibles : 5-A. Portainer-agent Avantage : - Facile et rapide à mettre en place Inconvénients : - Utilisation de certificats client/serveur auto-signés - Fonctionne uniquement avec Portainer Utilisation recommandée : réseau local ou VPN Pour le mettre en place sur le serveur distant qu'on souhaite superviser via notre instance centralisatrice, on passera par Docker-compose ou par lignes de commande : Par docker-compose : version: '2.1' services: portainer-agent: image: portainer/agent container_name: portainer-agent network_mode: bridge volumes: - /var/lib/docker/volumes:/var/lib/docker/volumes - /var/run/docker.sock:/var/run/docker.sock ports: - 9001:9001 restart: unless-stopped Puis : docker-compose up -d Par lignes de commande : docker create \ --name=portainer-agent \ --net=bridge \ --restart=unless-stopped \ -v /var/lib/docker/volumes:/var/lib/docker/volumes \ -v /var/run/docker.sock:/var/run/docker.sock \ -p 9001:9001 \ portainer/agent Puis : docker start portainer-agent Remarques : On monte le dossier contenant les volumes Docker, dont le principe est repris dans le tutoriel introductif. Cela permettra de parcourir ces dossiers depuis l'interface Portainer, très pratique pour aller télécharger certains fichiers internes au conteneur (logs, fichiers de configuration, etc...) : On remplace /var/lib/docker/volumes:/var/lib/docker/volumes par /volume1/@docker/volumes:/var/lib/docker/volumes si l'agent est installé sur un NAS Synology. On remplace /var/lib/docker/volumes:/var/lib/docker/volumes par /volume1/.@plugins/AppCentral/docker-ce/docker_lib/volumes:/var/lib/docker/volumes si l'agent est installé sur un NAS Asustor (merci à @MilesTEG1) On expose le port 9001 du conteneur sur le port 9001 de l'hôte (ou un autre port quelconque non utilisé). Si la machine cliente est derrière un routeur, on pense à faire la redirection du port 9001 vers celle-ci. Et que son pare-feu autorise les connexions ce port. Rendez-vous au paragraphe 6-A pour l'ajout de notre agent dans l'interface Portainer. 5-B. Portainer Edge agent A venir. 5-C. Liaison TLS + Proxy 5-C-1. Préambule Avantage : - Sécurisé par certificat client/serveur auto-signé (mais généré par vous-même donc auto-signé). - Utilisable dans toutes les utilisations envisageables d'une liaison TLS entre un serveur et un client, pas seulement dans le cadre de Docker. Inconvénients : - Plus long à mettre en place Utilisation recommandée : réseau local / VPN ou serveur distant Ici je vais prendre l'exemple d'un VPS OVH entrée de gamme. 5-C-2. Préparation La première étape consiste à se connecter en SSH avec l'utilisateur de notre choix sur la cible (le VPS en l'occurence pour moi) et de définir la variable HOST avec le FQDN de notre machine. Dans mon cas, j'utilise le nom de domaine que j'ai défini dans ma zone DNS OVH via un enregistrement A vers l'IP fixe de mon VPS. De manière générale, le FQDN peut être local ou externe, peu importe, car c'est un certificat auto-signé que nous allons générer pour l'atteindre, le tout étant que la résolution du FQDN soit adaptée à l'environnement (je ne peux pas utiliser vps.local si je passe par une résolution externe). Cela peut donc se faire comme moi avec un FQDN externe, si vous souhaitez gérer l'instance Docker d'un raspberry de votre réseau local, il peut s'agir de son enregistrement A correspondant dans votre serveur DNS local, ou simplement ce que vous avez renseigné dans le fichier /etc/hosts de votre instance centralisatrice. Pour l'exemple : HOST=target.ndd.tld En tapant : echo $HOST On doit obtenir le FQDN défini ci-avant. 5-C-3. Certificat serveur On va créer un dossier docker_tls dans le /home de notre utilisateur et on commence à suivre (pas bêtement, mais presque) les consignes de la documentation Docker, les étapes étant parfaitement décrites, je ménage vos touches Alt+Tab ou vous évite un torticolis si vous êtes en double écran en recopiant les étapes ici. 😉 Si vous souhaitez plus de détail sur l'explication de chaque étape, Rendez-vous sur la page. mkdir docker_tls cd docker_tls Puis on poursuit avec les commandes fournies par le guide : openssl genrsa -aes256 -out ca-key.pem 4096 openssl req -new -x509 -days 365 -key ca-key.pem -sha256 -out ca.pem openssl genrsa -out server-key.pem 4096 openssl req -subj "/CN=$HOST" -sha256 -new -key server-key.pem -out server.csr [[[ ATTENTION : Il se peut que vous obteniez l'erreur suivante : Il suffit dans ce cas-là de créer le fichier manquant : touch .rnd et de recommencer ]]] Arrive le passage le plus subtil, il va falloir définir les IP et les FQDN capables d'accéder à cette instance, ça se présente sous cette forme : echo subjectAltName = DNS:,IP: >> extfile.cnf Évidemment, il va falloir renseigner les valeurs de manière exhaustive, sous peine de devoir recommencer depuis cette étape. Ce passage permet de renforcer la sécurisation également, car tout nom de domaine (et donc IP associée) et IP non déclarés se verront refuser l'accès au socket (Connection refused sur Portainer). Il faudra au minimum ajouter $HOST (que l'hôte puisse accéder à sa propre instance, ça ne mange pas de pain), la boucle locale 127.0.0.1, et le FQDN et/ou l'IP de notre instance centralisatrice. Un exemple, où j'autorise en plus par exemple : - l'IP fixe publique de mon instance centralisatrice 51.25.152.236 (fictive) (en cas d'un problème de résolution DNS, je peux toujours y accéder) - l'enregistrement A qui lui est associé central.ndd.tld (ça peut également être mon dynhost pour les IP dynamiques) - l'IP privée de mon instance centralisatrice lorsque connectée au serveur VPN de mon VPS 10.0.0.2 echo subjectAltName = DNS:$HOST,DNS:central.ndd.tld,IP:51.25.152.236,IP:10.0.0.2,IP:127.0.0.1 >> extfile.cnf On poursuit : echo extendedKeyUsage = serverAuth >> extfile.cnf openssl x509 -req -days 365 -sha256 -in server.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem -extfile extfile.cnf . 5-C-4. Certificat client Par facilité, on va rester sur la machine hôte et créer les certificats et la clé privée client. openssl genrsa -out key.pem 4096 openssl req -subj '/CN=client' -new -key key.pem -out client.csr echo extendedKeyUsage = clientAuth > extfile-client.cnf openssl x509 -req -days 365 -sha256 -in client.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out cert.pem -extfile extfile-client.cnf rm -v client.csr server.csr extfile.cnf extfile-client.cnf chmod -v 0400 ca-key.pem key.pem server-key.pem chmod -v 0444 ca.pem server-cert.pem cert.pem 5-C-5. Récapitulatif Si tout s'est bien déroulé, un petit ls -lt devrait donner ceci : 5-C-6. Proxy Il nous faut maintenant créer le conteneur servant de proxy, dont voici la page GitHub de l'image. Un modèle de fichier docker-compose : version: '2.1' services: docker-socket-proxy: image: sjawhar/docker-socket-proxy container_name: docker-socket-proxy network_mode: bridge volumes: - /path/to/the/server/certs:/run/secrets:ro - /var/run/docker.sock:/var/run/docker.sock:ro ports: - 2376:2376 restart: unless-stopped Puis : docker-compose up -d Ou par lignes de commande : docker create \ --name=docker-socket-proxy \ --net=bridge \ --restart=unless-stopped \ -v /path/to/the/server/certs:/run/secrets:ro \ -v /var/run/docker.sock:/var/run/docker.sock:ro \ -p 2376:2376 \ sjawhar/docker-socket-proxy Puis : docker start docker-socket-proxy Remarques : - /path/to/the/server/certs représente le dossier dans lequel vous allez placer vos certificats, cela dépend de l'OS de la machine cliente. Sur une distribution Linux classique, ça peut être dans le /home d'un utilisateur, dans /root ou partout ailleurs. Parmi les huit fichiers restants, trois nous intéressent pour ce conteneur : ca.pem, server-key.pem, server-cert.pem Ces trois fichiers doivent se trouver dans le chemin que vous aurez choisi pour /path/to/the/server/certs, pour ma part j'ai créé un sous-dossier certs dans le dossier du conteneur et je les y ai copiés. Le port 2376 est à ouvrir (et rediriger si besoin) sur la machine cible, évidemment. Et que le pare-feu de la machine, s'il y en a un, autorise les connexions sur ce port. Une fois le conteneur démarré, si tout va bien les logs du conteneur n'affichent rien, on le vérifie en tapant : docker logs docker-socket-proxy 6. Ajout de l'environment sur Portainer 6-A. Portainer agent On va ajouter l'agent en cliquant simplement dans Environment dans le menu latéral, puis + Add environment. On sélectionne Agent, puis on complète de cette manière : L'IP 192.168.1.50 est un exemple évidemment, on pense à préciser le port. On peut éventuellement ajouter des tags pour trier facilement les environments (utile si on supervise beaucoup de machines). Si vous cliquez sur Home dans le menu latéral, vous voyez maintenant votre instance distante avec le statut Up. 6-B. Proxy On commence par rapatrier les trois fichiers utiles pour le client : ca.pem (le même que pour le serveur), cert.pem et key.pem. La sélection des fichiers se fera par une fenêtre de parcours, comme sur une interface graphique classique Linux ou Windows. Pour ceux que ça n'aide pas, j'ai utilisé scp et ai mis les fichiers sur mon bureau Linux (attention à la majuscule, c'est -P, pas -p) scp -P <port-SSH> ca.pem cert.pem key.pem toto@central.ndd.tld:~/Bureau Pour Windows, vous pouvez récupérer les fichiers avec WinSCP par exemple via connexion SSH. Le serveur est maintenant accessible, il ne reste plus qu'à se connecter à Portainer et ajouter l'environment. Dans le menu déroulant de gauche, on clique sur Environment, puis + Add environment. Puis on complète de la sorte, en adaptant évidemment à ses propres données : On notera la sélection des certificats et de la clé en bas de la page. On clique ensuite sur "Add environment". Si vous cliquez sur Home dans le menu latéral, vous voyez maintenant votre instance distante avec le statut Up. 7. Utilisation de Github comme source des fichiers compose Il est possible de créer un dépôt personnel sur Github (ou tout autre logiciel git-compatible type Gitea, etc... notamment auto-hébergé 😉) afin d'y stocker ses fichiers compose, au lieu de les stocker sur la machine cible ou en utilisant les outils de Portainer. L'avantage est d'avoir accès depuis n'importe où, avec le niveau de sécurité que l'on a établi pour sa connexion à Github (2FA par exemple), à l'ensemble des fichiers de configuration de ses applications. Mieux, si on modifie un fichier, Portainer le détectera ou en sera informé et recréera le conteneur avec ses nouveaux paramètres. Pour cela, on va devoir dans un premier temps créer un token d'accès à Github pour Portainer. 7-A. Génération d'un personal acces token Tout d'abord, il faut créer un compte Github. Une fois ceci fait, on clique sur son portrait, puis Settings : Puis Developer settings tout en bas du menu à la gauche de l'écran -> Personal access tokens -> Generate new token : Ce sont, de mes tests, les permissions minimales à accorder via ce token à Portainer pour pull correctement les fichiers lors du déploiement de la pile (stack). On clique ensuite sur Generate token. ON NOTE BIEN LE TOKEN, SI ON LE PERD IL N'Y A AUCUN MOYEN DE LE RECUPERER. Il faudra alors en recréer un. On va maintenant créer un dépôt pour stocker nos fichiers. 7-B. Création d'un dépôt On clique sur son portrait puis Your repositories. Puis New. Voici un exemple de dépôt : On clique sur Create repository. On arrive sur notre dépôt, vide de tout fichier sauf du README qui contient la description entrée ci-avant. On pourra évidemment en faire une documentation si on en éprouve le besoin. On va maintenant changer le nom de la branche principale, pour qu'il corresponde à celui pré-établi par Portainer lors de la création d'une pile git. On clique sur branch : Puis, on clique sur l'icône en forme de crayon tout à droite de la ligne de la branche "main". On la renomme en master et on valide. On revient sur la page d'accueil du dépôt en cliquant sur Code. On va maintenant pouvoir ajouter ou créer nos premiers fichiers. 7-C. Création & ajout d'un fichier compose On a plusieurs possibilités : On clique sur Add file (voir impression d'écran ci-avant) : On télécharge sur le dépôt un fichier compose existant via Upload files. On crée un nouveau fichier en cliquant sur Create new file. On utilise git depuis sa machine pour alimenter son dépôt (non traîté). On va ajouter un fichier docker-compose existant depuis mon PC. On clique sur Upload files, on peut déposer le fichier à la volée ou parcourir l'arborescence, puis on clique sur Commit changes. Une fois le fichier ajouté, il est à la racine du dépôt. Si on souhaite créer une arborescence, il n'y a pas de fonction créer un dossier dans Github. Pour ce faire il faut éditer le fichier en question, en cliquant sur le fichier nouvellement ajouté puis la même icône crayon en haut à droite du cadre contenant le code du fichier. Si vous regardez en haut de l'impression d'écran, j'ai créé un chemin synology/docker-compose_exemple.yml Pour cela, j'ai simplement ajouté synology/ devant le nom du fichier compose, Github reconnaît une arborescence dès qu'on ajouté un /. Je conseille également de renommer les fichiers docker-compose.yml en ajoutant l'application en question, ce sera nécessaire pour dissocier les fichiers les uns des autres. Remarques : Vous noterez que j'ai déposé le fichier compose de Portainer, c'est purement pour l'exemple. C'est évidemment le seul fichier compose qu'on ne pourra pas exploiter via Portainer. 😉 Il n'y a pas d'adaptation spécifique à faire au niveau du contenu des fichiers compose par rapport à ce que vous avez l'habitude de faire directement via Portainer à la création d'une pile ou en ligne de commande. Et maintenant direction Portainer ! 7-D. Création de la pile Dans Portainer, on sélectionne l'environnement où l'on souhaite déployer la pile, puis on clique sur Add stack. On lui donne un nom, puis on choisit l'option Git repository. On complète de la façon suivante : Repository URL : On y met l'adresse de notre dépôt, concaténé à partir du nom d'utilisateur Github et du nom du dépôt, à c/c depuis Github. Repository reference : c'est la raison pour laquelle je vous ai fait changer le nom de la branche, Portainer propose master par défaut. Compose path : le chemin du fichier compose sur le dépôt. Il est possible de le c/c directement depuis le fichier en question : Authentication : Vu qu'on est sur un dépôt privé, il faut s'authentifer, c'est ici qu'on entre notre nom d'utilisateur Github ainsi que le PAT (Personal access token) généré précédemment. Automatic updates : Gros intérêt de ce procédé, les conteneurs sont dynamiquement liés à leurs fichiers de configuration sur Github. Deux moyens de procéder : Polling : Par défaut, toutes les 5 minutes, Portainer ira vérifier si le fichier a changé, si oui, il recréer le conteneur. Méthode la plus simple et recommandée Webhook : C'est Github qui signalera à Portainer que le fichier a changé. Quand vous utilisez cette option, Portainer crée un lien vers son API, lien à renseigner dans Github. Cette méthode a plusieurs implications. Il faut que les IP suivantes puissent accéder à votre instance Portainer (donc attention au pare-feu et au géo-blocage) : - 192.30.252.0/22 - 185.199.108.0/22 - 140.82.112.0/20 - 143.55.64.0/20 - 2a0a:a440::/29 - 2606:50c0::/32 De plus, il faut aller renseigner le lien vers Portainer dans Github, pour cela on va sur notre dépôt : On clique sur Add webhook puis : On entre l'URL fournie par Portainer, pas besoin d'ajouter de secret. Si on utilise un proxy inversé ou le port sécurisé de Portainer, on laisse activée la vérification SSL. Des tests que j'avais faits, seuls les commit comments ont besoin d'être cochés. Si ça ne fonctionne pas, choisissez Send me everything et éventuellement procédez par élimination pour trouver les événements nécessaires. Je recommande la méthode du polling, pas de problème d'accès car la requête part de Portainer. Il ne vous reste plus qu'à déployer les piles. 🙂 7-E. Variables d'environnement Il est possible, comme avec les outils natifs Portainer, de spécifier la valeur de variables d'environnement lors du déploiement de la pile. Par exemple, dans le fichier compose : environment: - MYSQL_ROOT_PASSWORD = ${MYSQL_ROOT_PASSWORD} Au moment du déploiement : Pour les férus de sécurité uniquement. 😉 MàJ : 11/11/2022

1. Qu'est-ce que Docker ? Docker est un outil qui peut empaqueter une application et ses dépendances dans un conteneur isolé, qui pourra être exécuté sur n'importe quel serveur. On ne parle pas ici de virtualisation mais de conteneurisation, une forme plus légère, qui s'appuie sur certaines parties de la machine hôte pour son fonctionnement. En effet, une machine virtuelle nécessite son propre système d'exploitation et nécessite donc une certaine quantité de mémoire dédiée, tout cela parfois dans le but de faire tourner une seule application. Synology fournit sa propre version du moteur Docker via le centre de paquets. 2. Prérequis On peut trouver la liste des modèles compatibles sur le site de Synology. 3. Pourquoi utiliser Docker sur un NAS Synology ? DSM est un système basé sur un noyau Linux, cependant c'est un système propriétaire et si certains éditeurs de logiciels font l'effort et ont les ressources pour développer un paquet adapté, force est de reconnaître que ça reste limité. SynoCommunity fournit certains paquets très utiles, mais les paquets étant maintenus sur la base du volontariat, les mises à jour sont fréquemment en retard par rapport aux versions officielles. DSM fournit une interface relativement claire et épurée pour Docker, mais limitée pour certains cas d'utilisation. Vous pouvez a priori exécuter n'importe quelle application disponible pour une distribution Linux classique. Enfin, le point le plus intéressant, le système n'est en rien affecté et aucune dépendance n'a besoin d'être installée. Corollairement, sous réserve que le paquet Docker soit implémenté correctement par Synology, les mises à jour de DSM (même majeures) ne devraient poser aucun problème de compatibilité. 4. Aller plus loin J'ai réalisé quelques autres tutoriels sur le forum qui permettent une fois les bases acquises, de mettre en place quelques outils intéressants via Dcker, que ce soit par la réflexion que ça amène ou leur finalité, souvent les deux 😉 Mise à jour automatisée de ses images et conteneurs (en cours d'adaptation pour watchtower au lieu d'ouroboros) : https://www.nas-forum.com/forum/topic/63740-tuto-mise-à-jour-automatique-des-containers-docker/ Centralisation de la gestion de plusieurs instances Docker : https://www.nas-forum.com/forum/topic/66422-tuto-centralisation-des-instances-docker/ Monitoring du réseau via Telegraf - InfluxDB - Grafana : https://www.nas-forum.com/forum/topic/63273-tuto-monitoring-nas-et-réseau/ (pour le monitoring de la Freebox voir le tutoriel de @bruno78 : https://www.nas-forum.com/forum/topic/66394-tuto-monitorer-sa-freebox-revolution/) Gestion de certificat SSL et proxy inversé : https://www.nas-forum.com/forum/topic/67311-tuto-certificat-ssl-reverse-proxy-via-docker/ Mise en place du serveur d'authentification Authelia : https://www.nas-forum.com/forum/topic/71875-tuto-docker-authelia-serveur-dauthentification/ Installation de Pi-hole via réseau macvlan sur un NAS (ou tout autre périphérique) : https://www.nas-forum.com/forum/topic/69319-tuto-docker-macvlan-pi-hole/ Utilisation de SMBv1 de manière sécurisée : https://www.nas-forum.com/forum/topic/72162-tuto-docker-smbv1/ Audio multiroom avec Mopidy/Iris/Snapcast : https://www.nas-forum.com/forum/topic/77063-tuto-audio-multiroom-mopidyirissnapcast/ 5. Comment utiliser Docker ? Nous verrons trois méthodes pour créer des conteneurs : Par l'interface intégrée à DSM via SSH par ligne de commande via SSH en utilisant docker-compose La première peut paraître séduisante mais on est vite limité dans nos possibilités, dans les faits l'utilisation de docker-compose (qui permet une sorte de mise en forme analytique de la ligne de commande) est un excellent compromis entre de la ligne de commande pure et dure et une interface graphique. Pour ceux qui tiennent absolument à avoir une interface graphique, il peut être intéressant de s'orienter vers Portainer, dont je propose un guide d'installation dans mon tutoriel sur la centralisation des instances Docker. 6. Installation de Docker et bonnes pratiques 6-A. Installation et mise en place de Docker Pour installer Docker, il suffit de se rendre dans le centre de paquets et de chercher Docker dans la liste des paquets tiers, on clique sur Installer. Done ! Suite à une remarque de @oracle7, assurez-vous de ne pas avoir créé de dossier partagé "docker" en amont de son installation, cela peut amener à des erreurs dûes au fait que le dossier existe déjà. Il est aussi recommandé de créer un groupe "docker" auquel on pourra ajouter des utilisateurs pour lesquels on souhaite autoriser son utilisation. Direction DSM -> Panneau de configuration -> Groupe (ou Utilisateur & Groupe sous DSM7) -> Créer groupe. On y ajoute les utilisateurs qu'on souhaite voir accéder au dossier partagé créé ci-avant. On autorise également l'accès en lecture/écriture pour ce dossier. On valide. 6-B. Recommandations Avant de commencer le tutoriel et de télécharger vos premières images, quelques recommandations : Docker Hub est un centre de dépôts où la qualité des images peut très fortement varier, dès lors à moins de ne pas avoir le choix, évitez les images qui ne fournissent aucune documentation. Parfois, la page Docker Hub d'une image ne fournit pas beaucoup d'information, vous trouverez généralement plus d'informations concernant la dite image sur GitHub (page GitHub / page DockerHub). En cas de difficulté pour créer un conteneur fonctionnel, il est toujours intéressant d'aller consulter les pages relatives au support (généralement appelé "wiki" et dont le lien est rapidement donné dans le Readme, ou la page liée aux soucis techniques sur GitHub (https://github.com/linuxserver/Heimdall/issues). Il n'est pas toujours plus simple d'utiliser la version conteneurisée d'une application que sa version native (paquet DSM ou paquet Linux classique). Si pour X ou Y raisons il existe des incompatibilités avec un NAS Synology, s'il y a des problèmes de droit d'écriture (ça représente une bonne partie des difficultés qu'on peut rencontrer avec Docker sur un NAS), si les difficultés sont trop nombreuses, si la documentation fait cruellement défaut, ou encore que l'image est à l'abandon, je vous conseille d'opter pour une machine virtuelle et réaliser une installation classique. Ou déporter l'ensemble sur un Raspberry Pi par exemple. C'est du temps gagné et des cheveux épargnés. 🙂 Pour illustrer le tutoriel j'utiliserai comme exemple Heimdall, qui est une dashboard permettant de créer des liens rapidement vers ses applications via des épingles. 7. Interface de Docker dans DSM On clique sur Docker pour arriver sur cette interface : On peut voir l'utilisation globale du processeur et de la mémoire, ainsi que l'utilisation des ressources pour chaque conteneur créé. Dans l'onglet Conteneur, on peut venir éditer nos différents conteneurs : les arrêter et les démarrer (interrupteur à droite), les modifier, les supprimer, etc... L'onglet Registre est celui qui permet de télécharger les images des applications qui nous intéressent. Ce sont les images que l'on trouve dans le dépôt publique d'images Docker, disponible ici, il peut être intéressant d'y faire un tour. L'onglet Image liste les images qu'on a téléchargées sur le NAS et la taille qu'elles occupent dans l'espace de stockage dédié : L'onglet Réseau définit les réseaux (ou interfaces) sur lesquels nos conteneurs seront actifs. L'onglet Journal est un fichier log des différentes actions réalisées (création et suppression de conteneurs, téléchargement d'images, etc...) 7-A. Chronologie La logique est la suivante : On télécharge l'image d'une application qui nous intéresse. Cette image correspond à notre application, qu'on va adapter à nos besoins en 2). On crée un conteneur basé sur cette image en personnalisant les données à notre utilisation : les variables (un login/mdp, l'utilisateur du NAS qui va exécuter l'application, un fuseau horaire, etc...), les ports (comment on y accède), les volumes (souhaite-t-on stocker des données de manière persistante? par défaut, Docker supprime les données lorsqu'un conteneur est arrêté ou supprimé), les réseaux (liés à l'accessibilité et à la communication), etc... On démarre le conteneur. 7-B. Exemple 7-B-1. Image Je reprends l'exemple de l'image linuxserver/heimdall : le terme à gauche est le nom de l'éditeur de l'image, à droite le nom de l'application. Par défaut, toutes les images qu'on peut rechercher dans l'interface Docker de DSM correspondent aux images hébergées sur Docker Hub. Il est possible d'ajouter des registres supplémentaires (GitLab et d'autres). Il suffit de cliquer sur Paramètres puis Ajouter. Dans 99% des cas Docker Hub est la seule source dont vous avez besoin. Pour notre image en question, on trouve différentes informations : Le tag latest correspond à la dernière version stable en date, development parle d'elle-même, vous pouvez également avoir des numéros de version spécifique, si vous ne souhaitez sur une version bien précise de l'image. La plupart du temps, c'est la version latest qui nous intéressera. Par convention (respectée dans l'immense majorité), si le tag n'est pas précisé, on parle de la version latest. On retourne dans l'onglet Registre, et on double-clique sur l'image une fois trouvée via le champ de recherche : On sélectionne le tag latest. L'image se télécharge, on peut voir l'avancement dans l'onglet Image, à droite la taille que l'image occupe sur votre NAS : L'image est téléchargée, on va maintenant pouvoir créer le conteneur. 7-B-2. Paramétrage du Conteneur On va donc créer notre conteneur, ce sera la version exécutée de notre image. Pour en créer un, il suffit de double-cliquer sur l'image qu'on a fini de télécharger : Un nom nous est proposé par défaut, on peut évidemment le modifier pour quelque chose de plus simple. On laisse décoché Exécuter le conteneur à l'aide de privilèges élevés car cela revient à donner un accès root au conteneur, sauf cas très précis c'est déconseillé. C'est une des rares options dans Docker qui peut compromettre l'intégrité de votre NAS si mal utilisée. Si un tutoriel demande à cocher cette option, prenez le temps de comprendre pourquoi et vous demander si c'est vraiment utile. On peut limiter la quantité de mémoire que le conteneur utilisera pour s'exécuter. On clique ensuite sur Paramètres avancés pour poursuivre la configuration du conteneur. 7-B-2-a. Conditions d'exécution En cas d'arrêt inopportun du NAS ou du paquet Docker, on peut autoriser le redémarrage automatique, suivant l'application concernée c'est généralement un paramètre intéressant, on le coche donc. On peut créer un raccourci sur le bureau si on le souhaite. D'autres comportements que le redémarrage automatique sont disponibles mais à ma connaissance, non sélectionnables via l'interface graphique Docker de DSM. 7-B-2-b. Volumes Pour utiliser une application via Docker, les données de cette application doivent bien être écrites quelque part. Précisions : Il n'est pas possible de gérer cet aspect de Docker via l'interface de DSM, uniquement en ligne de commande ou par Docker-compose. Sans aucune précision de votre part concernant l'emplacement de ces données, elles sont écrites, sur nos NAS, dans /volume1/@docker/volumes/ (à ne pas confondre avec /volume1/docker, le premier étant un dossier "caché" dans File Station (visiblement uniquement via SSH/Telnet), le deuxième visible, accessible et créé par nos soins), et sur une distribution Linux classique, /var/lib/docker/volumes/. Si l'image prévoit la création de volumes (visible dans le Dockerfile d'une image via la commande EXPOSE volume), Docker les créera, si vous les déclarez vous pourrez choisir leur emplacement, dans le dossier partagé docker ou ailleurs, si vous ne les déclarez pas, ils seront créés dans les dossiers mentionnés dans le paragraphe précédent. Dans le deuxième cas, si vous supprimez le conteneur, les données ne seront pas effacées, mais les volumes seront laissés à l'abandon (dangling en anglais), et ne seront pas réutilisés en cas de recréation ultérieure. Le plus simple est donc de les déclarer, qu'on souhaite les mettre dans un dossier accessible via File Station, ou non. On assure ainsi la persistance des données. En ce cas, trois méthodes sont possibles : On définit un volume au moment de la création du conteneur, voir ici. Ce volume ne sera pas supprimé à la suppression du conteneur, en revanche il n'est utilisable que par le conteneur en question. => Pratique pour l'essai rapide d'une application On définit un volume indépendamment d'un conteneur. Il est donc autonome des conteneurs qui l'utilisent, car en effet n'importe quel conteneur peut décider d'accéder son contenu en son sein à sa création. => Intéressant si on souhaite que plusieurs applications partagent un même volume On demande au conteneur d'utiliser des dossiers existants du NAS pour y lire ou écrire des données existantes. Ce ne sont pas des volumes Docker à proprement parler. Donc toutes les opérations disponibles via la commande docker volume ne sont pas disponibles pour ce procédé, on appelle plus généralement ces volumes des bind pour les différencier des volumes Docker. => Cette troisième solution est celle qui est le plus souvent utilisée car généralement, on souhaite que l'application qu'on déploie puisse mettre à disposition soit le contenu de dossiers déjà peuplés du NAS, soit permettre que les données générées par l'application ou envoyées vers celle-ci écrivent dans un dossier du NAS accessible par File Station Pour illustrer ce que contient un conteneur, à l'instar de tout système d'exploitation, il est tout à fait possible d'explorer l’arborescence d'un conteneur comme on le ferait pour notre NAS ou n'importe quelle autre machine. Ci-dessous, l’arborescence à la racine du NAS (à gauche) et l'arborescence du conteneur (à droite) : Reprenons les directives du créateur de l'image : On s'intéresse aux paramètres précédés d'un -v, ici on nous dit que /config (chemin dans le conteneur, que les plus observateurs auront vu dans l'arborescence du conteneur sur l'image de droite un peu plus haut) peut être monté vers le NAS si on souhaite assurer la persistance (on le veut dans ce cas, on n'a pas envie de tout reconfigurer à chaque redémarrage du conteneur). On va donc dans l'onglet Volume : Et on clique sur Ajouter un dossier. On est alors amené à choisir le dossier dans lequel on va monter /config. Lorsqu'on installe Docker sur son NAS, un dossier partagé docker est créé, libre à vous de vous organiser de la manière qui vous conviendra le mieux. Souvent, on crée un dossier par conteneur. Je choisis mon dossier et valide : Dans la colonne Chemin d'accès, je suis venu écrire manuellement le chemin absolu du dossier dans lequel je vais monter mes données. 7-B-2-c. Réseau Pour l'accessibilité du tutoriel, je ne mentionne dans cette partie que deux types de réseau : le mode bridge (défaut) et le mode host. Le fonctionnement avancé des réseaux faisant l'objet d'une description plus exhaustive en fin de tutoriel pour ceux que ça intéresse. 7-B-2-c-1. Bridge Par défaut, le mode bridge est sélectionné. Dans ce mode, lorsqu'un conteneur est créé, il obtient une adresse IP privée libre dans le sous-réseau 172.17.0.0/16. La passerelle de ce conteneur sera toujours 172.17.0.1, qui est une des nouvelles interfaces du NAS (consécutivement à l'installation de Docker). Pour s'en assurer, connectez-vous en SSH sur votre NAS et tapez : ifconfig Vous verrez une interface docker0 avec l'IP 172.17.0.1, c'est la porte vers le monde extérieur (LAN + WAN) pour tous les conteneurs dans le réseau bridge 172.17.0.0/24 : c'est l'équivalent de votre box par rapport à Internet. En mode bridge, si les ports ne sont pas translatés de la passerelle (le NAS) vers le conteneur, le conteneur n'est pas accessible depuis votre réseau local (hormis le NAS). On a un fonctionnement similaire à un routeur auquel on dit de translater certains ports vers une machine de notre réseau pour y accéder de l'extérieur. 7-B-2-c-2. host Le mode host permet lui d'exposer directement le conteneur sur le NAS, à la manière de n'importe quel paquet Synology. En gardant l'avantage de conserver les dépendances en son sein et de ne pas impacter le système d'exploitation. Il n'y a dans ce cas aucune redirection de ports à effectuer, ils sont directement joignables sur l'IP du NAS (sous réserve que le pare-feu l'autorise). Dans l'onglet Réseau, on va donc laisser tel quel pour rester en mode bridge : Si on veut passer en mode host, il faut cocher l'option Utiliser le même réseau que Docker host. On notera en dernier lieu qu'il est possible par l'intermédiaire du "+" de créer des réseaux bridge différents de celui par défaut, on appelle ça des réseaux bridge personnalisés ou définis par l'utilisateur. Les réseaux bridge personnalisés font l'objet de remarques supplémentaires en fin de tutoriel. 7-B-2-d. Ports Si on a choisi le mode bridge, Docker liste par défaut les différents ports qu'utilise le conteneur, en proposant la valeur Auto pour le port du NAS. Si vous laissez Auto, alors un port libre aléatoire sera choisi par le système. Dans l'extrême majorité des cas, on préfère définir nous même les ports à exposer, il faut simplement s'assurer qu'ils ne sont pas déjà en cours d'utilisation par un autre service en utilisant via SSH en root la commande : sudo netstat -tulpn | grep LISTEN Autrement, DSM nous préviendra au moment de la création du conteneur que le ou les ports choisis sont déjà utilisés et la création échouera. On aurait pu garder les mêmes ports que dans le conteneur, mais dans le cas présent, 80 est le port utilisé par Web Station, et 443 est utilisé par Nginx, donc j'en ai choisi d'autres qui, eux, sont libres : NDLR : Lorsque la documentation ne précise pas le protocole du transport des données par le dit port, on parle du port TCP par défaut. NOTE : Si on a choisi le mode host, on n'a pas besoin de faire de redirection de ports 7-B-2-e. Liens Les liens permettent de connecter plusieurs conteneurs entre eux, dans la partie de gauche on choisit un autre conteneur, dans la partie de droite un alias, qui permettra de personnaliser des variables d'environnement dans le conteneur lié. Cette fonctionnalité étant dépréciée, je ne m'étendrai pas plus dessus, voir le chapitre Réseau en fin de tutoriel pour une méthode alternative. 7-B-2-f. Variables d'environnement Elles permettent de personnaliser le conteneur pour notre utilisation personnelle. Dans l'image ci-dessus, elles sont identifiées par le -e, on en identifie donc trois : PUID, PGID et TZ Dans l'onglet correspondant, je crée ces trois variables en utilisant le "+" en haut à gauche du cadre : Concernant les variables PUID et PGID, elles vont permettre de définir l'utilisateur du NAS qui exécutera le conteneur. On les retrouve par exemple, mais pas seulement, dans toutes les images Linuxserver, qui est un collectif de développeurs réalisant le portage d'applications phares vers des images Docker standardisées et surtout NAS friendly. Lorsque vous cherchez une application, je vous conseille en premier lieu d'aller jeter un oeil à la liste de leur releases, les ajouts sont fréquents et les mises à jour encore plus. Pour connaître les valeurs numériques à entrer, il faut se connecter en SSH sur le NAS, et taper : id user user étant l'utilisateur qu'on souhaite employer. On obtient plusieurs valeurs, un UID >= 1026, un GID = 100 ou plus, d'autres valeurs de GID dont on ne se servira pas ici. On fait correspondre le PUID au UID et le PGID au GID. Il faut également remplir deux autres conditions pour ne pas avoir de problème de permissions d'écriture dans nos volumes : que l'utilisateur choisi a des droits suffisants dans les dossiers partagés qui seront utilisés, dans mon cas le dossier partagé docker que l'utilisateur soit idéalement propriétaire du dossier heimdall, dans lequel j'ai décidé de monter /config du conteneur. Ces conditions sont très importantes pour que tout fonctionne sans accroc. Les NAS sont généralement assez capricieux au niveau des permissions, car les dossiers sont régis par des ACL (Access Control List), ce qui correspond à l'onglet Utilisateur et Groupe dans le panneau de configuration de DSM. On rencontre beaucoup moins de problèmes sur une distrubition Linux classique. Pour TZ, c'est une variable permettant de définir le fuseau horaire à l'intérieur du conteneur, vous pouvez trouver sur cette page une liste des valeurs à entrer suivant votre localisation. 7-B-3. Création du conteneur On valide les Paramètres avancés, et on clique sur Suivant, un dernier écran propose un récapitulatif de la configuration du conteneur, on applique. On peut vérifier dans l'onglet Conteneur que le conteneur est en cours d'exécution. Il ne reste plus qu'à aller sur notre navigateur et entrer l'adresse du NAS suivi du port HTTP qu'on a translaté depuis le conteneur vers le NAS : Et pour la version HTTPS : 7-B-4. Aperçu et Logs du conteneur Dans notre cas c'est merveilleux tout marche bien, mais il faut savoir que toutes les images ne sont pas aussi bien documentées, et qu'on n'est jamais à l'abri d'une erreur. Dans l'onglet Conteneur, si on en sélectionne un et qu'on clique sur Détail, on peut avoir un aperçu des statistiques du conteneur, et surtout les logs du conteneur dans l'onglet Journal, c'est la première chose à regarder en cas de conteneur non fonctionnel (accès impossible, redémarrage en boucle, etc...). ________________________________________ Ceci conclut la partie destinée à l'interface Docker de DSM, elle conviendra pour la majorité de vos besoins mais peut clairement révéler des insuffisances dans des cas plus poussés. 8. Docker via SSH 8-A. Analyse Un des principaux problèmes qu'on peut rencontrer avec l'interface de DSM c'est l'impossibilité de choisir des dossiers sur le NAS en dehors de /volume1, or Docker s'appuyant sur le système d'exploitation de l'hôte, il peut avoir besoin d'accéder à ses ressources. il est possible de contourner ce problème avec l'interface DSM de Docker via des liens symboliques (symlink) mais je trouve ça plus personnellement plus compliqué qu'un bête script. Par chance, pour les images comportant peu d'infos, il y a souvent a minima le script de démarrage du conteneur, exemple avec l'image utilisée ci-avant : On comprend assez vite la correspondance entre ce qu'on a fait précédemment et ce qu'on lit ici, quelques remarques tout de même : les \ permettent d'effectuer un retour à la ligne et de rendre le script présentable, il est tout à fait possible d'écrire tout à la suite. si j'écris -p 8080:80, je demande de faire correspondre le port 8080 de l'hôte avec le port 80 du conteneur, l'ordre est donc primordial. de la même manière qu'on peut mapper les ports, on peut mapper les volumes : /volume1/docker/heimdall est ici mon dossier sur le NAS, /config mon dossier dans le conteneur, j'écrirai donc ça : -v /volume1/docker/heimdall:/config on voit qu'ici il est possible de définir un autre type de comportement pour le redémarrage (celui qu'on avait validé dans l'interface correspondant à --restart always), ici on empêche le redémarrage automatique si le conteneur a été stoppé correctement. la dernière ligne reprend le nom de l'image, si aucun tag n'est précisé alors latest est implicite. il n'est pas nécessaire de télécharger l'image au préalable, au lancement du script il va aller chercher la version la plus récente du tag demandé, la re-télécharger si l'image est obsolète et enchaîner sur la création du conteneur. il faut ajouter sudo en début de commande si on n'est pas connecté en root au terminal. Cette commande permet de créer le conteneur, on doit ensuite taper : docker start heimdall pour exécuter le conteneur (pensez à ajouter sudo aux commandes docker si vous n'êtes pas connecté en root). 8-B. En détail Voyons plus en détail les possibilités pour chaque paramètre. Lorsqu'un paramètre n'est pas précisé lors de la création du conteneur, Docker regarde dans son démon, à savoir un fichier qui contient des directives à utiliser par défaut sans précision contradictoire de la part de l'utilisateur. Ce fichier se trouve à l'emplacement : /var/packages/Docker/etc/dockerd.json 8-B-1. Restart policies L'argument restart permet de définir le comportement de redémarrage du conteneur : --restart=no : C'est le comportement par défaut, le conteneur ne redémarrera pas s'il s'arrête, que ce soit proprement ou à cause d'une erreur. --restart=always : A contrario, le conteneur tente continuellement d'être redémarré, sauf s'il a été stoppé manuellement. Par contre, en cas de redémarrage du service Docker ou du NAS, le conteneur sera redémarré. --restart=unless-stopped : En cas d'erreur, le conteneur tentera de redémarrer indéfiniment. S'il est arrête manuellement, le conteneur ne sera pas relancé. En cas de redémarrage du service Docker ou du NAS, le conteneur ne sera pas redémarré. --restart=on-failure[:4] : Le conteneur ne sera redémarré qu'en cas d'arrêt pour cause d'erreur, et ce par exemple ici dans une limite de quatre fois. 8-B-2. Network L'argument network permet de définir la connectivité d'un conteneur par rapport à son environnement : --network=none : le conteneur est totalement isolé et autonome, le seul moyen d'y accéder est par terminal. --network=my-network : permet de se connecter à un réseau bridge personnalisé ou macvlan nommé my-network. Si on ne précise rien, le conteneur rejoint le réseau bridge par défaut (voir 7-B-2-c-1). 8-B-3. Ports La gestion des ports permet de rendre une application dans un conteneur accessible sur son hôte via des ports spécifiques. C'est indispensable si on souhaite accéder à un conteneur sur un réseau bridge. Un conteneur sur réseau macvlan a tous ses ports exposés sur sa propre IP, il est comme une machine à part entière sur le réseau, tous ses ports sont accessibles sur le réseau sur lequel il se trouve. 8-B-3-a. Interfaces Pour translater un port, on désigne le port sur lequel l'application est exposée dans le conteneur ainsi que le port sur l'hôte par lequel on accède à cette application. Par exemple : -p 8080:80 L'application disponible sur le port 80 dans le conteneur est translatée sur le port 8080 de l'hôte. -p 0.0.0.0:8080:80 Écrire 8080:80 revient à écrire 0.0.0.0:8080:80 0.0.0.0:8080 signifie l'application est disponible sur le port 8080 de l'hôte sur toutes ses interfaces. Que ce soit localhost (127.0.0.1 => seul l'hôte peut y accéder), l'IP local (par exemple 192.168.0.10), l'IP passerelle bridge 172.17.0.1 ou encore l'IP VPN. Je voudrais par exemple pouvoir vouloir n'accéder à une application que lorsque la requête arrive sur l'IP VPN de l'hôte : -p 10.0.8.1:8080:80 http://10.0.8.1:8080 aboutira, alors que 192.168.0.10:8080 ne donnera rien. 8-B-3-b. Protocoles Si on souhaite autoriser uniquement un protocole, il suffit de le préciser à la fin de l'argument : -p 8080:80/tcp -p 1194:1194/udp 8-B-4. Commandes utiles Assez intuitivement, pour arrêter le conteneur on tape : docker stop heimdall Pour supprimer le conteneur : docker rm heimdall Pour voir la liste des conteneurs actifs, on écrit la commande : docker ps Pour voir les logs d'un conteneur en direct, on écrit (CTRL+C pour arrêter la visualisation) : docker logs -f heimdall Pour gérer les réseaux, reportez-vous à l'aide via la commande : docker network --help Enfin, ça peut être parfois très utile, il est possible de se connecter à l'intérieur d'un conteneur, pour cela : docker exec -it heimdall bash Notes : En général, le paquet bash est présent dans la plupart des images que vous utiliserez. Parfois, si bash ne fonctionne pas, essayez ash. Si bash n'est pas disponible, rien ne vous empêche de taper directement la commande qui vous intéresse, par exemple : docker exec -it heimdall ls -la /etc Pour sortir du conteneur, tapez exit. A vous d'explorer l'ensemble des commandes à votre disposition en consultant le manuel d'aide : docker --help En dernier lieu, je vous invite à parcourir la documentation de Docker, bien que touffue elle est extrêmement claire : https://docs.docker.com/ Comme je disais au début du chapitre, le gros avantage de cette méthode est qu'elle permet de définir des chemins absolus hors /volume1 pour nos volumes. Rien ne m'empêcherait d'aller mapper /var/lib/temperature pour un dossier quelconque du conteneur. Cette possibilité est particulièrement utile quand une application va devoir utiliser le cœur de docker, le fichier /var/run/docker.sock. Ce fichier est particulièrement important, car à partir du moment où on le mappe en tant que volume vers un conteneur, on peut prendre le contrôle de Docker avec cette application. Typiquement, Portainer est une interface graphique à la manière de l'interface Docker de DSM pour gérer ses conteneurs, ses images, et toutes les infos exploitables (mais en mieux 😛). Avertissement !! A partir du moment où vous donnez accès à d'autres dossiers que ceux dans /volume1, le conteneur sera nécessairement lancé avec l'utilsateur root du NAS, car seul lui a accès à cette partie du système. Soyez donc attentifs aux nécessaires précautions que cela implique. 9. Docker-compose via SSH Docker-compose vient compenser les lacunes de la création de conteneur par Docker, dont voici un exemple : Les points forts de docker-compose sont : - écriture analytique, plus lisible qu'un script - possède beaucoup plus de fonctionnalités (dont on n'aborde ici qu'une infime partie) - possibilité de définir plus applications (appelés services) au sein d'un même fichier Dans un fichier docker-compose.yml, on peut définir 3 types d'objets : - des services : ce sont les applications en elles-mêmes - des volumes : ce sont des dossiers dans lesquels on va pouvoir écrire des données de manière persistante - des réseaux (networks) : ils définissent la manière dont sont exposés les conteneurs Il suffit de placer ce fichier dans un dossier, d'en faire le répertoire de travail dans son terminal, et de taper : docker-compose up -d Si je souhaite supprimer les conteneurs (et les éventuels réseaux définis dans le fichier), il me suffit de taper : docker-compose down Ça a également l'avantage de garder la configuration du conteneur au sein d'un fichier. Ce fichier docker-compose.yml peut être créé par Notepad++ sous Windows, ou via l'éditeur de texte sous Linux. Attention !! le fichier ne doit pas contenir de tabulation, tous les décalages sont réalisés à partir d'espace !! Plus d'infos sur Docker-compose à cette page. 10. Quelques autres commandes utiles docker stats Affiche les ressources utilisées par vos conteneurs, se rafraîchit constamment. docker network inspect <nom_du_réseau> Permet d'avoir toutes les informations relatives à un réseau donné. docker rmi <nom_image> Permet de supprimer l'image avec le nom spécifié. 11. Informations complémentaires 11-A. Réseaux Le mode bridge par défaut (c'est-à-dire si on utilise le driver bridge, et qu'on ne rattache le conteneur à aucun réseau bridge particulier) n'est pas idéal si l'on souhaite isoler les conteneurs les uns des autres. Tous les conteneurs appartenant au réseau bridge par défaut peuvent communiquer les uns avec les autres par leur IP, et se situent sur un même sous-réseau (par exemple 172.17.0.0). Si on souhaite s'affranchir des adresses IP (qui peuvent changer entre chaque création et suppression de conteneur) et utiliser plutôt le nom du conteneur pour communiquer avec, il existe deux méthodes : Les liens (évoqués plus avant) : c'est une fonctionnalité officiellement dépréciée dans les nouvelles versions de Docker, elle est cependant présente dans l'inteface Docker de DSM, dans l'onglet Lien lorsqu'on crée ou modifie un conteneur. En précisant le nom d'un autre conteneur, on autorise la communication notre conteneur en devenir et celui-ci. Les réseaux bridge définis par l'utilisateur : la commande docker network permet de gérer les réseaux docker et donc d'en créer de nouveaux. Lorsqu'on crée un réseau bridge, celui-ci aura la propriété intrinsèque que tous les conteneurs qui y sont connectés pourront communiquer entre eux via leurs noms de conteneur. Le réseau 172.17.0.0/24 étant réservé au réseau bridge par défaut, le premier réseau disponible est le 172.18.0.0/24, et ce jusqu'à 172.32.0.0/24. Un réseau de type bridge créé dans l'interface Docker de DSM est un réseau de cette catégorie. 11-A-1. Création du réseau macvlan Il existe un autre type de réseau appelé macvlan : il permet de donner une IP sur le réseau physique à un conteneur, donc par exemple 192.168.0.0/24, et sera donc directement accessible par les autres périphériques de votre réseau local. Merci à @bruno78 pour son apport sur ce sujet en particulier, la suite est très largement inspirée de ses commentaires, et @Didier3L dont les questions ont permis de défricher le terrain. Ce driver possède de gros avantages et un gros défaut : Si le conteneur a une IP sur le réseau physique, elle est directement accessible via tous ses ports. C'est excessivement pratique si certaines applications de l'hôte, ici le NAS, utilisent déjà certains ports : 80, 443, 53, etc... Prenez l'exemple parlant de Pihole, ce dernier utilise le port 80 pour plusieurs tâches, ainsi que le port 53 qui est le port DNS non sécurisé. Si vous utilisez le paquet DNS Server du NAS, le port 53 est déjà en écoute, pareil avec le port 80 si Webstation est exécuté. Nous avons précédemment vu qu'il était possible de translater, sauf que certains ports comme le port 53 ne sont pas réellement déplaçables sur un autre port. Je n'ai donc aucune redirection à faire, j'accéderai à mon application via par exemple 192.168.0.101:80, tout simplement, sans me soucier de ce que le NAS utilise. Attention cependant, en macvlan, l'hôte ne peut plus communiquer, via son interface physique, avec le conteneur !! Ce n'est pas gênant dans le cas du contrôleur Unifi d'Ubiquity, mais beaucoup plus dans le cas de Pihole par exemple. Pour créer un réseau macvlan, on peut le créer de manière externe, via docker network via ligne de commande ou de manière interne lors de l'écriture d'un script ou dans un fichier docker-compose. Dans ce cas, on va créer le réseau macvlan toto de façon externe : docker network create -d macvlan \ --subnet=192.168.0.0/24 \ --ip-range=192.168.0.144/28 \ --gateway=192.168.0.254 \ -o parent=ovs_eth0 \ toto Notes : (les valeurs sont données à titre d'exemple évidemment) - subnet => on choisit le sous-réseau physique, celui de nos machines. - ip-range => on va définir la plage d'IP couverte par le réseau, un calculateur d'IP sera d'une grande aide pour définir le nombre d'IP qu'on réserve et ajuster à notre besoin. Important !! Il est fortement recommandé que la plage d'IP couverte par le serveur DHCP de votre réseau soit dissociée de la plage d'IP allouée au réseau macvlan. - gateway => c'est notre passerelle, vu qu'on est sur le réseau physique c'est généralement votre box ou votre routeur. - parent => c'est le nom de l'interface physique (tapez ifconfig pour vérifier) On valide et notre réseau est créé. Maintenant, il reste un problème à résoudre ; comme évoqué plus haut, tout conteneur dans ce réseau ne sera pas joignable par l'hôte, quelque soit le protocole (ICMP, TCP, UDP, HTTP, etc...) 11-A-2. Création de l'interface virtuelle Une solution existe toutefois, il suffit de créer une nouvelle interface sur le NAS, une interface virtuelle, par lequel il sera aussi normalement accessible que par son interface physique. Pour illustrer, si j'accède à DSM via 192.168.0.100:5000 en temps normal, je pourrai depuis un conteneur sur le réseau macvlan y accéder via l'adresse 192.168.0.200:5000 Le conteneur pourra donc communiquer avec le NAS via cette nouvelle interface. Pour cela, il suffit de taper quelques lignes de commande en SSH : ip link add <nom_interface_macvlan> link <interface_physique> type macvlan mode bridge ip addr add <IP_virtuelle>/32 dev <nom_interface_macvlan> ip link set dev <nom_interface_macvlan> address <adresse_MAC> ip link set <nom_interface_macvlan> up ip route add <Plage_DHCP_réseau_macvlan> dev <nom_interface_macvlan> Si on veut faire correspondre à l'exemple du réseau ci-dessus : - <nom_interface_macvlan> => un nom au hasard, pas de caractères spéciaux, macvlan_int par exemple, peu importe - <interface_physique> => ovs_eth0 - <IP_virtuelle> => on avait choisi arbitrairement l'adresse 192.168.0.140, on vérifie que cette IP n'est pas dans la plage couverte par le réseau macvlan toto - <adresse MAC> => on peut définir une adresse MAC pour notre interface - <Plage_DHCP_réseau_macvlan> => ça correspond à --ip-range dans le script plus haut Vous devriez maintenant avoir maintenant une nouvelle interface visible en tapant ifconfig en SSH. Vous verrez également cette interface sur l'assistant Synology par exemple. Si vous tentez un ping depuis votre NAS vers un conteneur sur le réseau macvlan, cela devrait marcher. Inconvénient majeur : Au reboot, l'interface sera supprimée et le code précédent devra être réintroduit. Pour éviter cela, on peut créer une tâche dans le planificateur de tâches, à exécuter au démarrage du NAS, qui exécute un script comprenant toutes les commandes ci-dessus (celles commençant par IP). On peut également ajouter un sleep 60 pour temporiser 60 secondes avant l'exécution du script, on s'assure ainsi que la machine a bien démarré avant toute chose. MàJ : 08/07/2023

WATCHTOWER 1. Préambule Le but de ce tutoriel est de mettre en place une application, containrrr/watchtower (Docker Hub, Github) qui va vérifier suivant un intervalle que vous définirez la présence d'une nouvelle version pour totalité ou partie de vos images Docker. C'est un fork de v2tec/watchtower qui n'est maintenant plus mis à jour depuis près de deux ans. Ce tutoriel se basait historiquement sur l'image pyouroboros/ouroboros, qui n'est plus maintenue. NOTES : Les commentaires concernant watchtower (et pas ouroboros) commencent au milieu de la page 2. Avantages : - Plus besoin de vérifier via Docker Hub si une mise à jour est disponible - Processus entièrement automatisé - Ne consomme quasi aucune ressource Inconvénients : - Nécessite un accès à docker.sock, d'un point de vue sécurité ça peut être gênant pour certains - Suivant l'intervalle de vérification que vous définissez, la quantité de données échangée peut être importante, à surveiller si vous avez un quota - On ne peut l'installer par l'interface Docker de DSM (en fait si, mais c'est fastidieux). Je pondérerai le volet concernant la sécurité, si vous avez bien respecté les conseils de sécurité développés dans les tutoriels de référence de ce forum vous ne devriez pas avoir de souci à vous faire. 2. Prérequis - Savoir se connecter en SSH (root) - Avoir Docker installé sur son NAS C'est parti ! On commence par se connecter en SSH avec l'utilisateur root (voir le tutoriel [TUTO] Accès SSH et ROOT via DSM 6). On télécharge l'image : docker pull containrrr/watchtower Il ne reste plus qu'à créer le conteneur, mais il est avant tout intéressant de voir les fonctionnalités que l'application propose dans la documentation, et en particulier sur cette page. C3es paramètres sont personnalisés par l'ajout de variables d'environnement à la création du conteneur. 3. Configuration 3-A. Fréquence de mise à jour - INTERVAL : Définit un intervalle de mise à jour en secondes. Ex : WATCHTOWER_POLL_INTERVAL=300 - SCHEDULING : Le plus intéressant pour des particuliers je trouve, cron permet de définir une périodicité très personnalisable : tous les x jours, tous les mardi, 3 fois par jour le mercredi et le vendredi, à telle heure, x fois par mois, etc... la documentation de l'image renvoie vers ce site, mais je trouve ce générateur ou celui-ci très pratiques. L'image utilise un format CRON à 6 champs, contrairement aux liens ci-avant qui n'utilisent que 5 champs, en réalité, tous les champs sont décalés vers la droite pour proposer un réglage sur les secondes. Donc au lieu d'avoir : minutes | heures | jour du mois | mois | jour de la semaine vous avez secondes | minutes | heures | jour du mois | mois | jour de la semaine Ex : WATCHTOWER_SCHEDULE=0 0 5 * * 6 Cela correspond à une exécution hebdomadaire, tous les samedi matin à 5:00 Un conseil : Évitez d'utiliser 2:00 ou 3:00, à cause des changements d'heure 😉 Ces deux méthodes sont exclusives, c'est donc l'une ou l'autre. 3-B. Tri sélectif Par défaut, watchtower surveille tous les conteneurs. Mais on ne souhaite pas spécialement mettre à jour tous ses conteneurs automatiquement, certains sont gérés par des scripts de mise à jour (Bitwarden par exemple), d'autres sont peu maintenus, et il est plus risqué de mettre à jour aveuglément ce type d'images que celles issues de collectifs reconnus (Linuxserver, Bitnami, etc...). Plusieurs méthodes de tri sont proposées : - LABEL ENABLE : Permet d'utiliser les labels (des tags en quelque sorte) comme signes de distinction. Lorsqu'on crée un conteneur, on peut décider de lui ajouter un label, composé d'un intitulé et d'une valeur de type chaîne ou entier. Pour permettre à watchtower de mettre à jour un conteneur donné, il doit avoir parmi ses labels : com.centurylinklabs.watchtower.enable=true L' avantage énorme c'est que le nom du conteneur cible n'a pas d'importance, le fait qu'il n'existerait plus à un instant t n'a pas davantage d'incidence. Pour faire en sorte que la sélection des conteneurs à surveiller se fasse par label, il faut ajouter la variable suivante à la création du conteneur watchtower : WATCHTOWER_LABEL_ENABLE=true - FULL EXCLUDE (Ce n'est pas une variable d'environnement !!) : L'approche est exclusive au lieu d'être inclusive, elle se base sur le comportement par défaut de watchtower (surveillance de tous les conteneurs), mais il n'y a ici aucune variable d'environnement à préciser à la création du conteneur watchtower, en revanche les conteneurs que vous ne souhaiteriez pas surveiller doivent avoir le label suivant : com.centurylinklabs.watchtower.enable=false Notes : - Il n'est pas possible d'ajouter un label à un conteneur déjà existant. Il faut le recréer et insérer le label dans le script de création du conteneur. Si vous savez les recréer facilement (peu de paramètres à entrer, vos volumes sont persistants et les fichiers de configuration sont maintenus à la suppression du conteneur, ou si vous utilisez docker-compose) alors je préconise la méthode des labels, dans le cas contraire préférez la méthode FULL EXCLUDE. - La documentation est particulièrement claire à ce sujet. 3-C. Gestion des images - CLEANUP : Supprime la version précédente de l'image quand une plus récente a été téléchargée et qu'un nouveau conteneur a été créé. Cette fonctionnalité est désactivée par défaut. Ex : WATCHTOWER_CLEANUP=true - ROLLING RESTART : Par défaut, watchtower met à jour toutes les images avant de relancer les conteneurs, cette variable d'environnement permet de relancer les conteneurs au fur et à mesure, utilise si on souhaite réduire les périodes d'indisponibilités. Ex : WATCHTOWER_ROLLING_RESTART=true - WAIT UNTIL TIMEOUT : Par défaut, watchtower attend 10 secondes qu'un conteneur s'arrête une fois le signal d'extinction transmis. Certaines applications lourdes nécessitent plus de temps, cette variable permet d'ajuster ce délai. Ex : WATCHTOWER_TIMEOUT=30s Notes : - On notera la présence du "s" pour "seconde". - LINKED CONTAINERS : Certains conteneurs peuvent nécessiter que d'autres conteneurs soient opérationnels avant d'être créés, on prend souvent comme exemple le cas typique d'une application et d'une base de données. Afin d'éviter des erreurs, on souhaite que la base de données soit disponible avant l'application à la création, et inversement à la suppression. Ces relations existent par exemple lorsqu'on utilise l'argument --link en ligne de commande, ou avec l'instruction depends_on via docker-compose. On peut écraser ces réglages via le label : com.centurylinklabs.watchtower.depends-on tel que par exemple, si on applique ce label à un conteneur MariaDB : com.centurylinklabs.watchtower.depends-on=wordpress,caldav En cas de mise à jour disponible pour ce dernier, watchtower arrêtera au préalable les conteneurs wordpress et caldav. 3-D. Autres paramètres - DEBUG : Augmente le niveau de verbosité du stdout dans les logs du conteneur. Ex : WATCHTOWER_DEBUG=true - TRACE : Un debug encore plus verbeux, attention les credentials éventuels sont en clair ! Ex : WATCHTOWER_TRACE=true - TZ : Permet de définir le fuseau horaire, assure le lien entre la variable CRON si vous l'utilisez et votre fuseau horaire. La liste des timezone est disponible à cette adresse. Ex : TZ=Europe/Brussels Il y a encore énormément de fonctionnalités que je n'aborderai pas ici, citons parmi les plus notables : - les notifications => https://containrrr.dev/watchtower/notifications/ - La supervision de plusieurs instances Docker via un seul conteneur watchtower => https://containrrr.dev/watchtower/remote-hosts/ et https://containrrr.dev/watchtower/secure-connections/ (pour une connexion sécurisée (TLS), une lecture de https://www.nas-forum.com/forum/topic/66422-tuto-centralisation-des-instances-docker/ peut être instructive 😉) - la possibilité d'exécuter des scripts avant et après la mise à jour (par l'utilisation de labels) => https://containrrr.dev/watchtower/lifecycle-hooks/ - la possibilité d'utiliser d'autres dépôts que Docker Hub, ouvrant la voie à des dépôts privés => https://containrrr.dev/watchtower/private-registries/ Au final ce tutoriel se contente de traduire et de mettre en valeur les variables importantes, la documentation (je crois que je me répète 😛) est très complète. 4. Création du conteneur On a maintenant tous les outils en main, on va pouvoir créer notre conteneur. Pour se faire, plusieurs possibilités : 4-A. En lignes de commande (SSH) Voici un exemple de configuration : docker create --name=watchtower \ --hostname=watchtower-nas --restart=unless-stopped \ --label "com.centurylinklabs.watchtower.enable=true" \ -e WATCHTOWER_CLEANUP=true \ -e WATCHTOWER_DEBUG=true \ -e WATCHTOWER_LABEL_ENABLE=true\ -e WATCHTOWER_TIMEOUT=30s \ -e WATCHTOWER_SCHEDULE="0 0 5 * * 6"\ -e TZ=Europe/Brussels \ -v /var/run/docker.sock:/var/run/docker.sock \ containrrr/watchtower Notes : - On est obligé de monter en volume le socket Docker au vu des opérations que doit pouvoir effectuer watchtower sur les autres conteneurs. - On peut tout à fait demander via le label de mise à jour que watchtower se mette lui-même à jour. Si tout a bien fonctionné, vous devriez avoir comme retour une suite de chiffres et de lettres (correspondant à l'ID du conteneur), il ne reste plus qu'à le démarrer : docker start watchtower 4-B. Par Docker-compose (SSH) Une autre personnalisation de l'image au format docker-compose : docker-compose.yml version: '2.1' services: watchtower: image: containrrr/watchtower container_name: watchtower hostname: watchtower-nas network_mode: bridge environment: - WATCHTOWER_NOTIFICATIONS=email - WATCHTOWER_CLEANUP=true - WATCHTOWER_DEBUG=true - WATCHTOWER_LABEL_ENABLE=true - WATCHTOWER_TIMEOUT=30s - WATCHTOWER_SCHEDULE=0 0 5 * * 6 - TZ=Europe/Brussels env_file: - /volume1/docker/watchtower/watchtower.env labels: - "com.centurylinklabs.watchtower.enable=true" volumes: - /var/run/docker.sock:/var/run/docker.sock - /volume1/docker/watchtower/config.json:/root/.docker/config.json restart: unless-stopped Notes : - J'ai cette fois-ci ajouté les notifications par mail, mais on remarque qu'on ne retrouve pas les autres variables qui sont liées au relais SMTP (https://containrrr.dev/watchtower/notifications/#email). En réalité, pour des raisons de confidentialié, j'ai regroupé les variables qui sont plus "sensibles" dans un fichier .env qui est invoqué par : env_file: - /volume1/docker/watchtower/watchtower.env Fichier qui se présente sous la forme, et dont les permissions sont correctement réglées pour assurer le niveau de confidentialité désiré : WATCHTOWER_NOTIFICATION_EMAIL_FROM=... WATCHTOWER_NOTIFICATION_EMAIL_TO=... WATCHTOWER_NOTIFICATION_EMAIL_SERVER=... WATCHTOWER_NOTIFICATION_EMAIL_SERVER_USER=... WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PASSWORD=... WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PORT=... WATCHTOWER_NOTIFICATION_EMAIL_SUBJECTTAG=... - J'ai monté le fichier config.json pour y ajouter des credentials pour des dépôts privés. Pour créer le conteneur, on se place (cd) dans le dossier où se trouve le fichier docker-compose.yml et on tape : docker-compose up -d 5. Configuration Ci-après un exemple de logs suite à un déclenchement programmé de Watchtower : 2020-11-14 05:01:31 (info): Found new grafana/grafana:latest image (sha256:68f75fcab5a9372fb0844f5898c65a40b0ca34cff4176e269bade17ddb17ee75) 2020-11-14 05:01:48 (info): Found new telegraf:latest image (sha256:146c415345a26f48f8ef06c2f62ebde90c8ca4ca518db5d88137e60eeb0abeec) 2020-11-14 05:01:59 (info): Found new authelia/authelia:latest image (sha256:d05b2f15beecd4c164a861e0464ddfef1d574b1c67f8e343779daec26c7bbde9) 2020-11-14 05:03:17 (info): Found new linuxserver/mariadb:latest image (sha256:f48f265a3ed8b786973e85c2c681f2f79db1b64d38660c43900bfc48651c6f83) 2020-11-14 05:03:19 (info): Stopping /grafana (bfdbba3a284d51c1a5c5c807f8583857a0c6a03718a083e93e5bcf9671f7130f) with SIGTERM 2020-11-14 05:03:21 (info): Stopping /telegraf (56e1c8624a98344cba07ca6f745c0cd8a93d66b36ebc0af8992cac210c8e0d51) with SIGTERM 2020-11-14 05:03:22 (info): Stopping /authelia (6d4202898398cf0b46886d38c6591a15b83334e00fe20a0025fcd4437747f84c) with SIGTERM 2020-11-14 05:03:23 (info): Stopping /mariadb (763aeebe73c029c20de2a15d114c054ba70b26879fdaf82b3019944179f31573) with SIGTERM 2020-11-14 05:03:27 (info): Creating /mariadb 2020-11-14 05:03:31 (info): Creating /authelia 2020-11-14 05:03:34 (info): Creating /telegraf 2020-11-14 05:03:40 (info): Creating /grafana 2020-11-14 05:03:42 (info): Removing image sha256:ec8e3ebf50429170fa6387bb04e64e5b5f3d87f3221c42750b7fb5d922c5e978 2020-11-14 05:03:43 (info): Removing image sha256:48121fbe19c845fa401be9fdbf3cbeef50840b7537d8a0b9ca2eab081117beb6 2020-11-14 05:03:43 (info): Removing image sha256:7606d5ee069fcab20036c4bd521e1133ac8ca31e44f7d241f0d83a36315d6ca6 2020-11-14 05:03:43 (info): Removing image sha256:900b03b57e41a8bf7f43b8979872bb2d6642d9a4bcb738d053fb67e1d989e926 MàJ : 10/04/2021

AVERTISSEMENT : Ce tutoriel est adapté à InfluxDB 1.8.x, qui n'est plus la dernière version d'InfluxDB qui existe maintenant en version 2.x, dont le fonctionnement est grandement différent. 1. Préambule Ce tutoriel est dédié à la mise en service de trois applications qui œuvrent de concert pour récolter (Telegraf), stocker (InfluxDB) et afficher (Grafana) sous la forme désirée des métriques liées à des équipements informatiques. Les applications sont extrêmement vastes, cela va de la surveillance d'un système domotique, un système d'arrosage piloté par une vanne intelligente par exemple, à la supervision d'une infrastructure réseau, d'un serveur VPS, etc... Ce trio d'applications va être mis en service par le biais de Docker, un paquet disponible dans le centre de paquets Synology pour les modèles "haut de gamme" du constructeur. Comme vous le constaterez si vous parcourez les nombreuses pages de commentaires de ce tutoriel, des membres du forum ont activement apporté leur contribution à l'amélioration de ce fil et je les en remercie tous grandement, nous avons tous appris les uns des autres. Pour illustrer le propos, quelques exemples de tableaux de bord qu'il est possible de réaliser via Grafana : Fig. 1 Supervision d'un serveur Linux sous Debian 10 Fig. 2 Mise en place d'un speedtest régulier pour mesurer les performances de sa connexion (@oracle7 @bruno78) Fig. 3 Supervision combinée d'un DS920+ et d'un RT2600AC (@MilesTEG1) Fig. 4 Supervision d'une Freebox (@bruno78) Fig. 5 Supervision du trafic Wifi d'un routeur RT2600AC (@oracle7) 2. Prérequis Difficulté : facile-moyenne Ce tutoriel prend le temps d'expliciter la très grande majorité des commandes, néanmoins, afin de mieux comprendre ce qui est expliqué ici, il est conseillé de prendre connaissance des bases du fonctionnement de Docker, un tutoriel introductif est disponible sur le forum : Il est également important de savoir se connecter en SSH : 3. Matériel nécessaire Docker est un logiciel multiplateforme : Linux, Mac, Windows Ce tutoriel aborde en particulier les spécificités liées à DSM et à son implémentation de Docker, mais il est transposable (surtout via docker-compose) à toutes les machines compatibles. Avoir un NAS n'est donc pas une obligation pour mener ce tutoriel à terme. Vous pouvez vérifier quels NAS Synology sont capables d'utiliser Docker à cette adresse. 4. Outils et informations utiles 4-A. Docker-compose Docker-compose est une commande embarquée avec le paquet Docker de Synology, codé en Python et disponible via SSH. Il permet de structurer, de manière plus analytique qu'un script docker en ligne de commande, les variables, volumes, etc... d'un conteneur au sein d'un fichier au format yaml/yml. Ce fichier reste après création du conteneur, on conserve ainsi les paramètres de personnalisation de notre image Docker à tout moment. Pour crée un fichier docker-compose.yml, c'est assez simple : 4-A-1. Linux Si vous utilisez une distribution avec interface graphique, vous pouvez utiliser l'éditeur de texte embarqué. Sur DSM, vous avez le paquet éditeur de texte qui convient parfaitement. En ligne de commande, utilisez l'outil qui vous convient le mieux : vi, vim, nano, emacs, etc... Conseil : nano est un des éditeurs les plus simples à prendre en main, pour l'installer sur votre NAS (DSM ne l'embarque pas par défaut), vous pouvez télécharger le paquet SynoCli File Tools du dépôt Synocommunity. Je recommande d'ailleurs vivement l'installation de la suite de paquets SynoCli, ils sont très pratiques dès que vous commencez à prendre vos aises avec l'interface en ligne de commande. 4-A-1. Mac La plupart des éditeurs de texte font l'affaire, sinon via le Terminal. 4-A-1. Windows Je vous conseille d'utiliser Notepad++ Une fois lancé, aller dans le menu Encodage et vérifier que "Encoder en UTF-8" est sélectionné. Une fois votre fichier prêt, Enregistrer sous pour nommer le fichier et choisir le type : YAML Ain't Makeup Language (fin de la liste déroulante). A des fins de simplification du tutoriel, veuillez toujours nommer le fichier docker-compose (hors extension), cela permettra d'exécuter la commande de création de conteneur avec le moins d'arguments possibles. 4-B. Persistance des données Afin de stocker de manière pérenne les données d'un conteneur, on va créer un dossier par conteneur (ou groupe de conteneurs travaillant ensemble). A l'installation de Docker sur DSM, un dossier partagé "docker" est automatiquement créé, donc autant l'utiliser pour y stocker nos différents dossiers. Par exemple, pour Telegraf, le chemin absolu de son dossier sera /volume1/docker/telegraf Rien ne vous oblige à respecter cette règle. Quelque soit le dossier choisi, on va généralement y placer le fichier docker-compose.yml 4-C. SNMP Aucune connaissance réellement nécessaire pour la stricte application du tutoriel, mais si vous comptez faire de la surveillance d'autres équipements réseaux, ce sera incontournable d'en comprendre le fonctionnement global. On trouve la plupart des informations sur la page wikipédia (notamment les deux premiers paragraphes). 4-D. Fichiers MIB Les fichiers MIB traduisent traduisent et mettent en forme pour les humains les données qui sont mises à disposition par un système pour sa supervision. Exemple : .1.3.6.1.4.1.6574.5 => synologyDiskSMART La suite de caractères à gauche de la flèche est un OID, et à droite son nom : synologyDiskSMART. L'OID se construit via une arborescence : pour inspecter les sous-catégories de synologyDiskSMART, l'OID va s'enrichir de nouveaux caractères : .1.3.6.1.4.1.6574.5.1 => diskSMARTInfoIndex .1.3.6.1.4.1.6574.5.7 => diskSMARTAttrThreshold .1.3.6.1.4.1.6574.5.9 => diskSMARTAttrStatus Ainsi de suite... Synology met à disposition un PDF comprenant la liste non exhaustive des OID principaux disponibles dans DSM. 5. Serveur SNMP Pour pouvoir récolter les informations mises à disposition par le NAS, il faut d'abord activer le serveur SNMP, désactivé par défaut. Pour y remédier, on va dans Panneau de configuration -> Terminal & SNMP -> SNMP pour arriver à l'écran suivant : Fig. 6 Activation du protocole SNMP Remarques : - SNMPv2 est parfaitement adapté à une utilisation locale. Si vous souhaitiez superviser un NAS distant depuis votre NAS local, SNMPv3 est un choix plus avisé de par sa sécurité renforcée. - Je vous recommande de changer le nom de la communauté, j'utilise la logique suivante pour nommer mes périphériques : <nom_du_périphérique><suite_de_chiffres_XYZ> Exemples : vpsXYZ, nas1XYZ, raspberrypiXYZ, etc... - Au niveau du pare-feu, veuillez vous assurer d'avoir autorisé la plage d'IP 172.16.0.0/255.240.0.0 à communiquer avec le NAS, c'est la plage d'IP utilisée par Docker. A minima, autorisez le port UDP 161 depuis cette plage IP, si vous ne souhaitez pas autoriser tous les ports. 6. Alchimie L'ensemble de ces trois applications, qu'on retrouve parfois sous l'appellation TIG (Telegraf InfluxDB Grafana), opère de la sorte : - Telegraf C'est un agent de récupération de métriques (entendez des données relatives au fonctionnement du système que vous souhaitez surveiller). - InfluxDB InfluxDB est une base de données qui va stocker les métriques recueillies par Telegraf. - Grafana C'est un outil de supervision et d'agrégation de métriques, ce qui va nous permettre de manipuler les données stockées dans InfluxDB. 7. Mise en place 7-A. Images On télécharge les trois images docker suivantes (voir tutoriel introductif) : telegraf influxdb:1.8 grafana/grafana ATTENTION : InfluxDB 2.x nécessite une configuration totalement et un usage au sein de Grafana totalement différents de ce qui est abordé par la suite. Ce tutoriel ne s'adresse donc qu'aux installations utilisant les versions 1.x de InfluxDB. 7-B. Création d'un réseau bridge personnalisé (user-defined bridge network) Pour permettre la communication entre deux conteneurs, on distingue deux méthodes : 7-B-1. Lien On utilise la fonction de lien (link) présente dans l'interface de création d'un conteneur sur DSM qui pointe vers le conteneur avec lequel on souhaite établir une communication. Cette méthode fonctionne encore, mais est dépréciée par Docker. 7-B-2. Réseau Il y a deux catégories de réseau bridge : le réseau bridge par défaut et le réseau bridge personnalisé. 7-B-2-a. Bridge par défaut Le conteneur est isolé dans le sous-réseau 172.17.0.0/255.255.0.0 Depuis le conteneur, le NAS est accessible à l'adresse 172.17.0.1, il est sa passerelle vers le monde extérieur. Un conteneur attaché à ce réseau est joignable uniquement par son IP (pas de résolution DNS possible). 7-B-2-b. Bridge personnalisé C'est un réseau créé par l'utilisateur. Tous les conteneurs qui feront partie de ce réseau pourront communiquer via leur nom de conteneur, cette résolution DNS est extrêmement pratique car elle ne fait pas intervenir les IP qui peuvent être amenées à changer d'une fois à l'autre. Via docker-compose, si on ne précise rien concernant le réseau dans le fichier docker-compose.yml, Docker créera un réseau bridge personnalisé dédié au(x) service(s) de façon automatique. C'est ce qu'on appelle un réseau interne, car il est créé dans la foulée de la mise en route d'un service Ici, nous allons créer un réseau externe, comme ça même si tous les conteneurs sont supprimés, le réseau persiste et est prêt à accueillir de nouveaux conteneurs. Remarque : Au sein d'un réseau bridge personnalisé, les ports des conteneurs sont intégralement exposés les uns envers les autres, il est donc primordial de ne placer dans un même réseau que des conteneurs qui ont vocation à communiquer entre eux. 7-B-2-b-1. Par DSM Pour créer un réseau bridge personnalisé sur DSM, c'est très simple, on clique sur le paquet Docker -> Réseau -> Ajouter -> Fig. 7 Création du réseau bridge personnalisé via DSM On peut tout à fait choisir d'obtenir une configuration automatique, mais cela ne coûte pas bien plus cher de définir la configuration de notre réseau. Tous nos conteneurs auront des IP dans la plage 172.18.0.1 à 172.18.0.254, l'adresse 172.18.0.1 étant réservée au NAS (passerelle), à la manière du réseau bridge par défaut. On valide, le réseau est maintenant créé, il suffira d'indiquer à nos conteneurs de s'y connecter à leur création. 7-B-2-b-2. Par ligne de commande (CLI) Alternative à l'interface DSM, via SSH, on tape la commande suivante : docker network create -d bridge \ --subnet=172.18.0.0/24 \ --gateway=172.18.0.1 \ --opt "com.docker.network.bridge.name"="br_monitoring" \ monitoring L'avantage avec cette méthode est qu'on définit le nom de l'interface, sinon une suite de caractères aléatoires est générée, utiliser ifconfig pour le vérifier. Remarques : - Penser à ajouter "sudo" devant la commande si vous n'êtes pas connecté en root. - Il est possible de faire rejoindre d'autres réseaux à un conteneur après sa création, voir dans la documentation officielle de Docker. 7-C. Docker-compose : fichiers multiples ou fichier unique Un fichier docker-compose a l'avantage de pouvoir gérer plusieurs services simultanément (un service entrainant la création d'un conteneur), définir un ordre de démarrage, des paramètres (volumes et réseaux par exemple) communs, etc... La méthode du fichier unique est donc toute indiquée ici, car nos conteneurs sont dépendants les uns des autres. Cependant, à des fins didactiques, je proposerai pour chacune des applications un code autonome. Je présente dans un premier temps la méthode avec des fichiers séparés, rendez-vous au point 9. pour des détails concernant l'utilisation d'un fichier unique. 8. Création des conteneurs 8-A. InfluxDB 8-A-1. Configuration L'ordre dans lequel on ajoute les services dans le fichier docker-compose.yml n'a pas d'importance, c'est le paramètre "depends_on" qui permettra de définir un ordre de mise en route (uniquement pour un fichier unique, voir plus loin). Commençons par définir les paramètres de notre conteneur InfluxDB. La liste des variables d'environnement pour InfluxDB est disponible à cette adresse. Cela peut être utile si vous souhaitez définir une police de rétention des données. On crée un dossier influxdb dans le dossier partagé docker, soit par File Station, soit en SSH : mkdir /volume1/docker/influxdb Puis on va créer le fichier docker-compose.yml : IMPORTANT: Un fichier docker-compose.yml n'accepte pas les tabulations !!! Seuls les espaces sont acceptés !! version: '2.1' services: influxdb: image: influxdb:1.8 container_name: influxdb networks: - monitoring environment: - INFLUXDB_DB=nas_telegraf - INFLUXDB_ADMIN_USER=admin - INFLUXDB_ADMIN_PASSWORD=admin - INFLUXDB_USER=nas_telegraf - INFLUXDB_USER_PASSWORD=nas_telegraf - INFLUXDB_HTTP_AUTH_ENABLED=true - INFLUXDB_META_RETENTION_AUTOCREATE=false # ports: # Optionnel # - 8086:8086 # Optionnel volumes: - /volume1/docker/influxdb/data:/var/lib/influxdb restart: unless-stopped networks: monitoring: external: true Une fois ceci fait, on se place dans le répertoire d'InfluxDB : cd /volume1/docker/influxdb On va devoir créer un dossier data dans le dossier présent : mkdir data Puis : docker-compose up -d En cas d'erreur, pour supprimer un conteneur par docker-compose, c'est tout simplement : docker-compose down Remarques : Concernant la forme, le nombre d'espaces n'a pas d'importance, le tout étant de garder la même logique, et d'aligner les éléments comme proposé. Concernant le fond : - On a défini un nom pour notre conteneur : influxdb - On a créé une base de données par défaut => nas_telegraf - On a créé un utilisateur administrateur pour gérer l'ensemble des base de données dans InfluxDB => admin / admin - On a créé un utilisateur avec les droits de lecture et écriture sur la base de données nas_telegraf => nas_telegraf / nas_telegraf - On a activé l'authentification HTTP (nécessaire pour que les autres variables d'environnement soient prises en compte). - Le dossier data créé ci-avant comportera ce qu'on trouvera dans le conteneur dans son dossier /var/lib/influxdb. Autre remarque : Ici on n'utilise pas la dernière version d'InfluxDB mais on précise qu'on souhaite avoir la version 1.8 (dans image), car les versions 1.8.x sont les dernières supportées par ce tutoriel. ATTENTION : Il est important de noter que la translation de ports n'est nécessaire que si d'autres périphériques doivent accéder à cette instance d'InfluxDB. Par exemple un conteneur Telegraf sur un Raspberry Pi qui enverrait ses données vers InfluxDB. Par défaut, je commente (avec le # en début de ligne) les lignes relatives à la translation de ports. En effet, les trois applications étant dans le même réseau personnalisé, tous leurs ports sont exposés les uns aux autres, aucun besoin de redirection en ce cas. Si on souhaite que des instances Telegraf externes au NAS (sur une autre machine du réseau), décommentez la définition des ports (supprimez les #), supprimez le conteneur et recréez-le. 8-A-2. Définition de la police de rétention des données Par défaut, InfluxDB attribue des polices de rétention de données d'une durée d'un an si on ne lui dit pas de faire autrement. Or un an peut paraître excessif lorsque parfois seuls les derniers jours ou semaines nous intéressent. C'est le but de la variable d'environnement : - INFLUXDB_META_RETENTION_AUTOCREATE=false définie dans le fichier docker-compose ci-avant. En revanche, il est donc nécessaire d'en définir une manuellement après création du conteneur. Pour se faire, on va dans le terminal et ton tape la commande suivante : docker exec -it influxdb influx -username admin -password admin Ce qui va nous faire entrer dans l'interpréteur de requête propre au conteneur InfluxDB : On doit d'abord préciser quelle base de données utiliser : USE nas_telegraf Puis on va, par exemple, créer une police de rétention nommé rp_8w de 8 semaines pour notre instance nas_telegraf : CREATE RETENTION POLICY "rp_8w" ON "nas_telegraf" DURATION 8w REPLICATION 1 DEFAULT Pour s'assurer que ça a fonctionné, on tape la commande suivante : SHOW RETENTION POLICIES Qui doit renvoyer une liste de polices de rétention pour cette base de données : Pour sortir du conteneur, on tape simplement exit. Notre instance InfluxDB est donc maintenant prête à accueillir des données depuis Telegraf. 8-B. Telegraf MISE A JOUR : depuis la version 1.20.3 de Telegraf, il est nécessaire de créer un utilisateur dédié à Telegraf pour pouvoir l'exploiter de manière sécurisée. C'est donc la première étape à réaliser. 8-B-1. Création d'un utilisateur dédié On commence par se rendre dans DSM, et on va dans Panneau de configuration -> Utilisateur -> Créer. A l'écran de sélection des groupes, on l'adjoint au groupe docker. Fig. 8 Ajout de l'utilisateur telegraf au groupe docker On s'assure que cette appartenance lui confère les droits nécessaires sur le dossier partagé docker : On peut également lui refuser l'accès à toutes les applications de DSM : Fig. 9 Suppression des droits d'utilisation des applications Synology Ceci fait, on a un utilisateur dédié pour Telegraf. En réalité, cette étape n'était pas nécessaire pour son utilisation la plus basique, à savoir superviser les informations données par DSM. Ce sera nécessaire si l'on souhaite superviser Docker ou d'autres éléments du système non pris en charge nativement par les fichiers MIB de Synology (voir plus loin). On cherche à connaître les ID de l'utilisateur telegraf et du groupe docker : id telegraf Dans cet exemple, ce seraient les valeurs 1040 et 65536 qui nous intéressent. Prenez-en note. On les insèrera dans le fichier docker-compose (point 8-B-4). 8-B-2. Génération du fichier de configuration Telegraf utilise un fichier de configuration .conf, qu'on va générer en amont de la création du conteneur. Comme pour InfluxDB on crée un dossier telegraf : mkdir /volume1/docker/telegraf Puis on va dans le dossier de Telegraf : cd /volume1/docker/telegraf Puis : docker run --rm telegraf telegraf config > telegraf.conf Un fichier telegraf.conf va apparaître dans le dossier, avant de l'éditer je vous conseille d'en faire une copie, en SSH il suffit de taper la commande suivante (merci @unPixel pour la suggestion) : cp telegraf.conf telegraf.conf.back Maintenant qu'on a créé tous les fichiers dont on a besoin, on va lancer File Station, et se rendre dans le dossier partagé docker, on clic droit sur le dossier telegraf, puis on va successivement choisir, dans l'onglet Propriétaire, le groupe users (vérifiez bien que c'est un groupe, on distingue deux personnages au lieu d'un devant son nom) et l'utilisateur telegraf. L'option d'application à tous les dossiers et fichiers enfants doit également être cochée dans les deux cas. Fig. 10 & 11 Application des ACL au dossier telegraf Pour la suite, libre à vous d'éditer le fichier de configuration via File Station et le paquet Éditeur de texte, ou de le faire par le terminal via nano. 8-B-3. Paramétrage Le fichier de configuration de Telegraf se décompose en trois sections : - Les paramètres globaux de Telegraf - Les plugins de sortie - Les plugins d'entrée 8-B-3-a. Global Ce sont les paramètres globaux de Telegraf, c'est-à-dire ceux qui s'appliqueront si un plugin ne contient pas une directive contraire (intervalle de récolte des données par exemple). # Telegraf Configuration # # Telegraf is entirely plugin driven. All metrics are gathered from the # declared inputs, and sent to the declared outputs. # # Plugins must be declared in here to be active. # To deactivate a plugin, comment out the name and any variables. # # Use 'telegraf -config telegraf.conf -test' to see what metrics a config # file would generate. # # Environment variables can be used anywhere in this config file, simply prepend # them with $. For strings the variable must be within quotes (ie, "$STR_VAR"), # for numbers and booleans they should be plain (ie, $INT_VAR, $BOOL_VAR) # Global tags can be specified here in key="value" format. [global_tags] # dc = "us-east-1" # will tag all metrics with dc=us-east-1 # rack = "1a" ## Environment variables can be used as tags, and throughout the config file # user = "$USER" # Configuration for telegraf agent [agent] ## Default data collection interval for all inputs interval = "60s" ## Rounds collection interval to 'interval' ## ie, if interval="10s" then always collect on :00, :10, :20, etc. round_interval = true ## Telegraf will send metrics to outputs in batches of at most ## metric_batch_size metrics. ## This controls the size of writes that Telegraf sends to output plugins. metric_batch_size = 1000 ## For failed writes, telegraf will cache metric_buffer_limit metrics for each ## output, and will flush this buffer on a successful write. Oldest metrics ## are dropped first when this buffer fills. ## This buffer only fills when writes fail to output plugin(s). metric_buffer_limit = 10000 ## Collection jitter is used to jitter the collection by a random amount. ## Each plugin will sleep for a random time within jitter before collecting. ## This can be used to avoid many plugins querying things like sysfs at the ## same time, which can have a measurable effect on the system. collection_jitter = "0s" ## Default flushing interval for all outputs. Maximum flush_interval will be ## flush_interval + flush_jitter flush_interval = "10s" ## Jitter the flush interval by a random amount. This is primarily to avoid ## large write spikes for users running a large number of telegraf instances. ## ie, a jitter of 5s and interval 10s means flushes will happen every 10-15s flush_jitter = "0s" ## By default or when set to "0s", precision will be set to the same ## timestamp order as the collection interval, with the maximum being 1s. ## ie, when interval = "10s", precision will be "1s" ## when interval = "250ms", precision will be "1ms" ## Precision will NOT be used for service inputs. It is up to each individual ## service input to set the timestamp at the appropriate precision. ## Valid time units are "ns", "us" (or "µs"), "ms", "s". precision = "" ## Logging configuration: ## Run telegraf with debug log messages. debug = true ## Run telegraf in quiet mode (error log messages only). quiet = false ## Specify the log file name. The empty string means to log to stderr. logfile = "" ## Override default hostname, if empty use os.Hostname() hostname = "" ## If set to true, do no set the "host" tag in the telegraf agent. omit_hostname = false Les champs importants sont : - le champ interval dans la section [agent] : il définit à quel intervalle les données sont récoltées, 60s est un bon compromis. - le champ debug dans la même section : le passer à true passe le niveau de verbosité à debug, c'est un réglage que je conseille pour une première mise en route, cela vous aidera à diagnostiquer les dysfonctionnements. 8-B-3-b. InfluxDB ############################################################################### # OUTPUT PLUGINS # ############################################################################### # Configuration for sending metrics to InfluxDB [[outputs.influxdb]] ## The full HTTP or UDP URL for your InfluxDB instance. ## ## Multiple URLs can be specified for a single cluster, only ONE of the ## urls will be written to each interval. # urls = ["unix:///var/run/influxdb.sock"] # urls = ["udp://127.0.0.1:8089"] # urls = ["http://127.0.0.1:8086"] urls = ["http://influxdb:8086"] ## The target database for metrics; will be created as needed. ## For UDP url endpoint database needs to be configured on server side. database = "nas_telegraf" ## The value of this tag will be used to determine the database. If this ## tag is not set the 'database' option is used as the default. # database_tag = "" ## If true, no CREATE DATABASE queries will be sent. Set to true when using ## Telegraf with a user without permissions to create databases or when the ## database already exists. skip_database_creation = true ## Name of existing retention policy to write to. Empty string writes to ## the default retention policy. Only takes effect when using HTTP. retention_policy = "" ## Write consistency (clusters only), can be: "any", "one", "quorum", "all". ## Only takes effect when using HTTP. # write_consistency = "any" ## Timeout for HTTP messages. timeout = "5s" ## HTTP Basic Auth username = "nas_telegraf" password = "nas_telegraf" ## HTTP User-Agent # user_agent = "telegraf" ## UDP payload size is the maximum packet size to send. # udp_payload = "512B" ## Optional TLS Config for use on HTTP connections. # tls_ca = "/etc/telegraf/ca.pem" # tls_cert = "/etc/telegraf/cert.pem" # tls_key = "/etc/telegraf/key.pem" ## Use TLS but skip chain & host verification # insecure_skip_verify = false ## HTTP Proxy override, if unset values the standard proxy environment ## variables are consulted to determine which proxy, if any, should be used. # http_proxy = "http://corporate.proxy:3128" ## Additional HTTP headers # http_headers = {"X-Special-Header" = "Special-Value"} ## HTTP Content-Encoding for write request body, can be set to "gzip" to ## compress body or "identity" to apply no encoding. # content_encoding = "identity" ## When true, Telegraf will output unsigned integers as unsigned values, ## i.e.: "42u". You will need a version of InfluxDB supporting unsigned ## integer values. Enabling this option will result in field type errors if ## existing data has been written. # influx_uint_support = false Remarques : - urls = ["http://influxdb:8086"] -> Si vous avez bien suivi, notre conteneur Telegraf peut contacter InfluxDB directement par son nom de conteneur, et tous les ports étant exposés entre eux, on peut l'écrire de la sorte. - database = "nas_telegraf" -> c'est le nom qu'on a donné à notre base de données lors de la création du conteneur influxdb (variable d'environnement INFLUXDB_DB). - skip_database_creation = true -> créée en même temps que le conteneur influxdb, on peut régler cette option sur "true". - HTTP Basic Auth : on entre le nom d'utilisateur et le mot de passe (respectivement les variables d'environnement INFLUXDB_USER et INFLUXDB_USER_PASSWORD) qu'on a également définis dans notre fichier docker-compose pour InfluxDB : nas_telegraf / nas_telegraf En l'état, le fichier de configuration est suffisamment paramétré pour envoyer certaines données que Telegraf collecte par défaut à notre base de données InfluxDB : CPU, mémoire, kernel, etc... C'est là que vont intervenir les fichiers MIB, ceux-ci permettent une supervision plus poussée du NAS, mais pour cela il va falloir donner à Telegraf les OID relatifs aux informations que Synology fournit via SNMP. 8-B-3-c. SNMP Pour cela on peut se baser sur le travail de jperillo sur Github, notamment son listing des OID de DSM. Au fil des mois, les différents contributeurs de ce tutoriel ont fourni une aide précieuse pour compléter les OID liés au monitoring d'un onduleur branché au NAS, vous retrouverez dans le fichier suivant une version plus complète que ce proposé sur le lien ci-dessus : snmp-dsm.conf Le contenu de ce fichier est à placer juste après le début de la section INPUT PLUGINS. Il reste quelques champs à personnaliser. 8-B-3-c-1. agents agents = [ "xxx.xxx.xxx.xxx", "xxx.xxx.xxx.xxx" ] Ce sont les IP des NAS à superviser, vous pouvez parfaitement passer par l'IP passerelle du NAS sur lequel Telegraf est installé : 172.18.0.1 (si le réseau bridge utilisé est 172.18.0.0, à adapter au besoin). Si vous souhaitez superviser d'autres NAS, il faut entrer l'IP par laquelle vous-même les contacteriez : IP locale si sur le réseau local, IP publique si NAS à distance, etc... Si vous ne supervisez qu'un seul NAS, pensez à supprimer la virgule et le deuxième bloc IP : agents = [ "xxx.xxx.xxx.xxx" ] 8-B-3-c-2. community On pense à changer le nom de la communauté si on l'a modifié dans DSM. 8-B-3-c-3. interval Intervalle entre chaque récolte de données (écrase la valeur donnée dans les paramètres généraux de Telegraf pour ce plugin uniquement). 8-B-4. Fichier docker-compose version: '2.1' services: telegraf: image: telegraf container_name: telegraf networks: - monitoring user: 1040:65536 # A adapter suivant vos valeurs # ports: # Optionnel # - 8125:8125 # Optionnel # - 8092:8092/udp # Optionnel # - 8094:8094 # Optionnel volumes: - /volume1/docker/telegraf/telegraf.conf:/etc/telegraf/telegraf.conf:ro - /usr/share/snmp/mibs:/usr/share/snmp/mibs:ro - /etc/localtime:/etc/localtime:ro - /etc/TZ:/etc/timezone:ro restart: unless-stopped networks: monitoring: external: true On vérifie qu'on se trouve bien dans /volume1/docker/telegraf puis : docker-compose up -d Remarques : - Le suffixe ":ro" à la fin du montage de volume signifie read-only (lecture seule), pour éviter toute modification indésirable des fichiers par le conteneur. - Les fichiers MIB de Synology sont déjà présents sur le NAS, on va donc monter le dossier dans le conteneur pour que Telegraf y ait accès. - Si votre instance Telegraf collecte les données d'un NAS distant, et que l'hôte de Telegraf n'est pas un NAS Synology, il aura besoin des fichiers MIB disponibles à cette adresse. - Une fois de plus je n'expose aucun port sur le NAS même, ce serait utile uniquement si je souhaitais qu'un script envoie des données à Telegraf par exemple. - On spécifie pour le paramètre user les ID relevées au point 8-B-1. Telegraf va dorénavant envoyer périodiquement les métriques à InfluxDB, on peut le vérifier en tapant dans le dossier de Telegraf : docker-compose logs -f telegraf | 2021-01-08T23:55:02Z D! [outputs.influxdb] Wrote batch of 469 metrics in 109.726214ms telegraf | 2021-01-08T23:55:02Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:55:12Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:55:22Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:55:32Z D! [outputs.influxdb] Wrote batch of 469 metrics in 144.489076ms telegraf | 2021-01-08T23:55:32Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:55:42Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:55:52Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:56:02Z D! [outputs.influxdb] Wrote batch of 469 metrics in 145.368898ms telegraf | 2021-01-08T23:56:02Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:56:12Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:56:22Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:56:32Z D! [outputs.influxdb] Wrote batch of 469 metrics in 119.228603ms telegraf | 2021-01-08T23:56:32Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:56:42Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics et vérifier dans InfluxDB également en se plaçant dans son dossier et en utilisant la même commande : [httpd] 172.18.0.3,172.18.0.2 - nas_telegraf [08/Jan/2021:23:59:07 +0000] "POST /write?consistency=any&db=nas_telegraf HTTP/1.1" 204 0 "-" "Telegraf/1.16.3 Go/1.15.2" 7e616302-520d-11eb-aead-0242ac130002 15706 8-C. Grafana 8-C-1. Fichier docker-compose Il ne reste plus qu'à configurer Grafana pour pouvoir visualiser les données stockées dans InfluxDB. Comme pour les deux autres conteneurs, on crée un dossier dédié pour Grafana, et un dossier data dans ce dernier. version: '2.1' services: grafana: image: grafana/grafana container_name: grafana networks: - monitoring volumes: - /volume1/docker/grafana/data:/var/lib/grafana ports: - 3000:3000 restart: unless-stopped networks: monitoring: external: true A la différence des autres logiciels, on va devoir ici étendre les permissions du dossier contenant les données de Grafana à tous les utilisateurs : cd /volume1/docker/grafana chmod 777 data Puis : docker-compose up -d Remarques : - Ici je suis forcé de translater le port correspondant à l'interface de Grafana si je souhaite pouvoir y accéder d'une autre machine que le NAS, ce qui sera nécessairement le cas. - Il est possible d'accéder à Grafana au travers d'un proxy inversé. 8-C-2. Création de la source de données On se rend sur la page http://IP_DU_NAS:3000 (ou le port qu'on a choisi) pour accéder à Grafana : Fig. 12 Page d'authentification de Grafana Les accès par défaut sont admin/admin, la première fois qu'on se connecte on nous invite à changer le mot de passe du compte admin. Fig. 13 Écran d'accueil de Grafana On suit les indications de Grafana et on commence par ajouter la source de données, ici notre conteneur InfluxDB. On clique sur Add data source. On choisit InfluxDB. On remplit ensuite l'écran suivant de la sorte : Fig. 14 Configuration de la source de données InfluxDB pour les données du NAS Remarques : - On donne un nom à notre datasource, ici j'ai choisi NAS_InfluxDB. - influxdb dans http://influxdb:8086 représente le nom que vous avez donné au conteneur. - On coche Basic Auth car on a activé l'authentification http à la création du conteneur InfluxDB. - Les informations à entrer dans "InfluxDB Details" correspondent aux variables d'environnement du conteneur InfluxDB : Database : INFLUXDB_DB User : INFLUXDB_USER Password : INFLUXDB_USER_PASSWORD - Basic Auth Details : User : INFLUXDB_USER Password : INFLUXDB_USER_PASSWORD On clique sur Save & Test, on obtient un message écrit en vert Datasource is working si tout est bien paramétré. 8-C-3. Création d'un tableau de bord (dashboard) On peut soit créer son propre tableau de bord, soit en importer un, pour cela il suffit d'aller sur le site de Grafana, plus précisément sur cette page. En tapant Synology dans le cadre de recherche, on peut par exemple choisir le tableau de bord de Yann Bizeul. Fig. 15 Page du tableau de bord publique de Yann Bizeul sur le site de Grafana On clique sur "Copy ID to Clipboard", on retourne sur notre instance de Grafana et on clique sur import dans le menu rapide à la gauche de l'écran : Fig. 16 Importation d'un tableau de bord 1/2 Dans l'écran suivant on colle dans "Grafana.com dashboard" le numéro de du tableau de bord qu'on a choisi. On valide en cliquant sur "Load" et on arrive sur l'écran suivant : Fig. 17 Importation d'un tableau de bord 2/2 Dans InfluxDB on choisit la datasource définie ci-avant, on valide en cliquant sur "Import". Il est aussi possible d'importer des tableaux de bord depuis un fichier JSON, n'hésitez pas à en demander sur ce fil, plusieurs des participants sont prêts à partager les leurs (impressions d'écran en début de tutoriel). 9. Fichier docker-compose unique Si on avait voulu le définir en un seul fichier, on aurait pu faire ainsi : - Créer un dossier monitoring dans /volume1/docker : cd /volume1/docker mkdir monitoring Puis créer des dossiers data pour InfluxDB et Grafana : mkdir influxdb-data grafana-data telegraf-data Et créer enfin un fichier docker-compose.yml : version: '2.1' services: influxdb: image: influxdb:1.8 container_name: influxdb networks: - monitoring environment: - INFLUXDB_DB=nas_telegraf - INFLUXDB_ADMIN_USER=admin - INFLUXDB_ADMIN_PASSWORD=admin - INFLUXDB_USER=nas_telegraf - INFLUXDB_USER_PASSWORD=nas_telegraf - INFLUXDB_HTTP_AUTH_ENABLED=true - INFLUXDB_META_RETENTION_AUTOCREATE=false # ports: # Optionnel # - 8086:8086 # Optionnel volumes: - /volume1/docker/monitoring/influxdb-data:/var/lib/influxdb restart: unless-stopped grafana: image: grafana/grafana container_name: grafana networks: - monitoring volumes: - /volume1/docker/monitoring/grafana-data:/var/lib/grafana ports: - 3000:3000 depends_on: - telegraf - influxdb restart: unless-stopped telegraf: image: telegraf container_name: telegraf networks: - monitoring user: 1040:65536 # A adapter suivant vos valeurs # ports: # Optionnel # - 8125:8125 # Optionnel # - 8092:8092/udp # Optionnel # - 8094:8094 # Optionnel depends_on: - influxdb volumes: - /volume1/docker/monitoring/telegraf-data/telegraf.conf:/etc/telegraf/telegraf.conf:ro - /usr/share/snmp/mibs:/usr/share/snmp/mibs:ro - /etc/localtime:/etc/localtime:ro - /etc/TZ:/etc/timezone:ro restart: unless-stopped networks: monitoring: external: true __________________________________________ 10. Supervision de Docker La manipulation est très simple, dans le fichier telegraf.conf, il suffit de décommenter les options qui nous intéressent. Il y a possibilité de trier les conteneurs dont on souhaite réaliser la surveillance suivant différents critères : nom, état, label... # # Read metrics about docker containers [[inputs.docker]] # ## Docker Endpoint # ## To use TCP, set endpoint = "tcp://[ip]:[port]" # ## To use environment variables (ie, docker-machine), set endpoint = "ENV" endpoint = "unix:///var/run/docker.sock" # # ## Set to true to collect Swarm metrics(desired_replicas, running_replicas) # gather_services = false # # ## Set the source tag for the metrics to the container ID hostname, eg first 12 chars # source_tag = false # # ## Containers to include and exclude. Globs accepted. # ## Note that an empty array for both will include all containers # container_name_include = [] # container_name_exclude = [] # # ## Container states to include and exclude. Globs accepted. # ## When empty only containers in the "running" state will be captured. # ## example: container_state_include = ["created", "restarting", "running", "removing", "paused", "exited", "dead"] # ## example: container_state_exclude = ["created", "restarting", "running", "removing", "paused", "exited", "dead"] container_state_include = [ "created" , "restarting" , "running" , "removing" , "paused" , "exited" , "dead" ] container_state_exclude = [] # # ## Timeout for docker list, info, and stats commands # timeout = "5s" # # ## Specifies for which classes a per-device metric should be issued # ## Possible values are 'cpu' (cpu0, cpu1, ...), 'blkio' (8:0, 8:1, ...) and 'network' (eth0, eth1, ...) # ## Please note that this setting has no effect if 'perdevice' is set to 'true' perdevice_include = [ "cpu" , "blkio" , "network" ] # # ## Specifies for which classes a total metric should be issued. Total is an aggregated of the 'perdevice' values. # ## Possible values are 'cpu', 'blkio' and 'network' # ## Total 'cpu' is reported directly by Docker daemon, and 'network' and 'blkio' totals are aggregated by this plugin. # ## Please note that this setting has no effect if 'total' is set to 'false' total_include = [ "cpu" , "blkio" , "network" ] # # ## Which environment variables should we use as a tag # ##tag_env = ["JAVA_HOME", "HEAP_SIZE"] # # ## docker labels to include and exclude as tags. Globs accepted. # ## Note that an empty array for both will include all labels as tags # docker_label_include = [] # docker_label_exclude = [] # # ## Optional TLS Config # # tls_ca = "/etc/telegraf/ca.pem" # # tls_cert = "/etc/telegraf/cert.pem" # # tls_key = "/etc/telegraf/key.pem" # ## Use TLS but skip chain & host verification # # insecure_skip_verify = false Une étape supplémentaire est nécessaire, il faut qu'on donne accès au fichier docker.sock en lecture seule à Telegraf, il suffit pour cela de rajouter dans le fichier docker-compose de Telegraf (ou pour le fichier unique, le service telegraf) le volume suivant : - /var/run/docker.sock:/var/run/docker.sock:ro On relance le conteneur, en SSH via la commande suivante : docker restart telegraf 11. Supervision de Raspi OS (ou tout autre distribution Linux) Dans mon cas, j'ai choisi de continuer à utiliser l'instance InfluxDB du NAS et avoir une instance de Telegraf sur le Raspberry Pi, pourquoi ? Vous aurez pu remarquer qu'InfluxDB est friand de mémoire vive. Donc autant limiter la charge sur le Raspberry Pi, dont les performances sont généralement en deçà d'un modèle de NAS "+". 11-A. Docker ATTENTION : Si vous n'avez pas activé l'accès SSH sur votre Raspberry Pi, c'est une option à cocher sur le bureau, le service SSH est désactivé par défaut à l'installation depuis 2016, voir guide ici. Pour installer Docker sous Raspbian, on passe par le script tout-en-un. Si vous n'utilisez pas Raspbian, mais une Debian, Ubuntu, ou autre... sélectionnez votre système d'exploitation sur cette page et suivez le guide. Si vous avez une installation précédente de Docker et que vous ne seriez pas passé par cette méthode, vous risquez de vous retrouver avec des versions obsolètes du Docker Engine et donc potentiellement de Docker-compose (merci @Jeff777), veuillez donc avant tout désinstaller Docker et ses reliques en suivant ces étapes. Remarques : On n'oublie pas d'ajouter notre utilisateur au groupe docker, ça évitera par la suite de devoir utiliser "sudo" pour chaque commande liée à Docker, pour l'utilisateur "pi" par exemple : sudo usermod -aG docker pi Pour que la modification soit effective, il faut redémarrer sa session SSH. 11-B. Docker-compose Pour installer Docker-compose, on va utiliser la source la plus à jour : pip3 Toujours en SSH : sudo apt-get install -y libffi-dev libssl-dev python3 python3-pip sudo pip3 install docker-compose 11-C. Telegraf On télécharge l'image de Telegraf : docker pull telegraf Comme précédemment on va créer un dossier dans lequel stocker notre fichier telegraf.conf, personnellement j'ai utilisé le dossier /opt qui est généralement réservé aux applications tierces : sudo mkdir -p /opt/containers/telegraf On va générer le fichier originel telegraf.conf : cd /opt/containers/telegraf docker run --rm telegraf telegraf config | sudo tee telegraf.conf Une fois la configuration faite, on va créer le fichier docker-compose.yml pour Telegraf. On s'inspire du fichier docker-compose qu'on a utilisé pour le NAS, en opérant quelques modifications : version: '2.1' services: telegraf: image: telegraf container_name: telegraf hostname: raspberrypi network_mode: bridge environment: - HOST_PROC=/hostfs/proc - HOST_MOUNT_PREFIX=/hostfs # ports: # Optionnel # - 8125:8125 # Optionnel # - 8092:8092/udp # Optionnel # - 8094:8094 # Optionnel volumes: - /opt/containers/telegraf/telegraf.conf:/etc/telegraf/telegraf.conf:ro - /proc:/hostfs/proc:ro - /run/udev:/run/udev:ro - /etc/localtime:/etc/localtime:ro - /etc/timezone:/etc/timezone:ro restart: unless-stopped Remarques : - Pour plus d'info sur les variables et volumes avec "hostfs", voir : https://github.com/influxdata/telegraf/blob/master/docs/FAQ.md - On remarquera l'ajout du paramètres hostname, qui permettra de voir un nom à la place d'une suite de chiffres dans Grafana. - On remarquera également le paramètre network_mode: bridge => Ici je n'ai pas créé de réseau bridge personnalisé, mon conteneur telegraf est tout seul, il peut être donc être dans le réseau bridge par défaut. Pour l'instant on ne démarre pas le conteneur, il va falloir créer la base de données dans laquelle stocker nos informations. 11-D. Création d'une base de données dans InfluxDB Rappelez-vous, sur le NAS nous avions précisé dans le fichier telegraf.conf un nom de base de données à utiliser, ainsi que les données d'identification pour les droits d'écriture. Cette base de données avait été créée à la création du conteneur influxdb, donc il n'y avait rien eu à configurer manuellement. Ici on va stocker les données dans une base de données séparée, donc il va falloir créer un nouvel utilisateur, et une nouvelle base de données. Pour cela il faut se connecter directement dans le conteneur influxdb du NAS. Donc retour en SSH sur celui-ci. On se connecte en root et on entre la commande suivante : docker exec -it influxdb influx -username admin -password admin Remarques : docker exec -it influxdb permet la connexion au conteneur influxdb, influx c'est la commande ouvrant la base de données, si on avait écrit bash à la place on serait arrivé sur l'invite de commande propre au conteneur et on aurait pu écrire influx pour faire la même chose, mais en plus long. 😛 Vu qu'on a activé l'authentification HTTP dans notre conteneur, si on ne précise rien à la connexion, toute tentative de modification se soldera pas un échec dû à un défaut de permission. De plus, vu qu'on souhaite créer de nouveaux éléments, il faut que le compte utilisé ait les pouvoirs d'administration. Il faut donc préciser les données d'authentification administrateur au lancement de la commande influx. Ces données sont celles que l'on avait renseignées à la création du conteneur InfluxDB, dans le tutoriel on a choisi admin / admin comme username / password. Fig. 14 Connexion à InfluxDB par ligne de commande Première étape : on crée la base de données, il suffit de taper la commande suivante : CREATE DATABASE raspi_telegraf puis on sélectionne la base de données qu'on vient juste de créer : USE raspi_telegraf On crée maintenant l'utilisateur dédié au raspberry : CREATE USER raspi_telegraf WITH PASSWORD 'raspi_telegraf' On peut également choisir sa police de rétention de données (voir point 8-A-2) : CREATE RETENTION POLICY "rp_8w" ON "raspi_telegraf" DURATION 8w REPLICATION 1 DEFAULT Remarques - Si on s'est trompé dans l'écriture, il est toujours possible de supprimer un utilisateur ou une base de données avec les commandes DROP USER nom_utilisateur et DROP DATABASE nom_bdd. On peut vérifier à ce stade que tout se passe bien, il suffit de taper les commandes SHOW DATABASES et SHOW USERS : Fig. 15 Listing utilisateurs et bases de données dans InfluxDB La dernière étape consiste à donner des droits à notre utilisateur raspi_telegraf sur la base de données du même nom, ce qui se fait par la commande : GRANT ALL ON raspi_telegraf TO raspi_telegraf On tape ensuite exit pour sortir de influx (gestion de la base de données). On relance ensuite le conteneur pour s'assurer que les modifications ont été prises en compte : docker restart influxdb On peut maintenant quitter la session SSH sur le NAS et revenir sur celle du Raspberry Pi. A ce stade, notre base de données est prête à l'emploi, il suffit maintenant de renseigner dans notre fichier telegraf.conf sur le Raspberry Pi les données d'exportation vers influxdb sur le NAS. On peut le faire avec la commande nano ou vi : cd /opt/containers/telegraf nano telegraf.conf ############################################################################### # OUTPUT PLUGINS # ############################################################################### # Configuration for sending metrics to InfluxDB [[outputs.influxdb]] ## The full HTTP or UDP URL for your InfluxDB instance. ## ## Multiple URLs can be specified for a single cluster, only ONE of the ## urls will be written to each interval. # urls = ["unix:///var/run/influxdb.sock"] # urls = ["udp://127.0.0.1:8089"] # urls = ["http://127.0.0.1:8086"] urls = ["http://192.168.0.51:8086"] ## The target database for metrics; will be created as needed. ## For UDP url endpoint database needs to be configured on server side. database = "raspi_telegraf" ## The value of this tag will be used to determine the database. If this ## tag is not set the 'database' option is used as the default. database_tag = "" ## If true, no CREATE DATABASE queries will be sent. Set to true when using ## Telegraf with a user without permissions to create databases or when the ## database already exists. skip_database_creation = true ## Name of existing retention policy to write to. Empty string writes to ## the default retention policy. Only takes effect when using HTTP. retention_policy = "" ## Write consistency (clusters only), can be: "any", "one", "quorum", "all". ## Only takes effect when using HTTP. write_consistency = "any" ## Timeout for HTTP messages. timeout = "5s" ## HTTP Basic Auth username = "raspi_telegraf" password = "raspi_telegraf" Notes : - Dans urls, on doit entrer l'adresse IP locale du NAS (ou son nom NetBios), et préciser le port sur lequel InfluxDB est exposé, par défaut 8086 dans notre installation précédente. - On s'assure d'avoir exposé le port 8086 du conteneur influxdb sur le NAS (ce qui était optionnel ne l'est plus). - On pense bien à préciser le nom de la base de données dans database et les login/password de notre utlisateur dans la partie HTTP Basic Auth. - On passe skip_database_creation à true. Tout est maintenant configuré sur le Raspberry Pi, il suffit de lancer le conteneur Telegraf : docker-compose -f /opt/containers/telegraf/docker-compose.yml up -d L'argument -f permet de créer un conteneur depuis un fichier compose n'importe où, et avec un nom différent de "docker-compose.yml". Cela permet d'éviter de devoir se placer dans le dossier du fichier docker-compose.yml avant d'exécuter la commande. 11-D. Création de la source de données Direction Grafana => panneau latéral : Configuration (roue dentée) => Datasources On clique sur Add data source : Fig. 16 Configuration de la source de données InfluxDB pour les données du Raspberry Pi On valide, si tout a bien été configuré, on verra le message "Datasource is working" apparaître en vert au moment du clic. 11-D. Création d'un tableau de bord Il s'agit juste ici de vérifier que les données sont accessibles : Fig. 17 Exemple de configuration d'une requête Ici j'ai créé un graphique pour suivre l'état d'utilisation de la mémoire vive : - On notera le choix de la datasource relative au raspberry. - Dans la liste "host" vous devriez voir le nom que vous avez précisé dans le champ hostname du script de création du conteneur. Si vous avez laissé le réglage par défaut, il affichera la valeur hostname du système. MàJ : 29/03/2022