Point Docker

Après plusieurs mois d'utilisation de Docker, des containers et de Portainer, voici un petit retour en espérant répondre à quelques questions que vous pourriez vous poser avant de vous lancer !

Docker permet d'installer des containers (que l'on peut considérer comme des applications) et portainer permet d'administrer tout ça confortablement à la souris, via une interface web. Une machine avec Docker, portainer et les containers installés n'a pas besoin d'écran, de clavier ou de souris, il faut juste une connexion au réseau : confortable pour du "headless" ou de l'enfoui !

La liste des machines !

Tout à commencé avec une Orange Pi Zero 2, une machine avec un processeur H616 4 coeurs et 1Go de RAM. C'est une machine largement plus puissante qu'une Raspberry Pi 3 RPi3 et légèrement moins puissante qu'une RPi4. La Orange Pi a deux avantages majeurs par rapport aux cartes de la fondation Raspberry : elle est disponible, contrairement aux Raspberries, et son tarif est très contenu, entre 18€ (en Chine) et 30€ en occident.

Le premier essai a été d'installer le LMS (Logitech Media Server), un serveur audio, en tant que container. Cela a très bien fonctionné et a donc a connu de nombreuses suites.

Après avoir configuré le serveur audio sur la OPZ2, c'est la minuscule Raspberry Pi Zero 2 W qui a accueilli Docker + Portainer + squeezelite. Squeezelite est le logiciel de lecture audio qui se connecte au LMS. En expérimentant, j'ai trouvé que même si a priori on installe le système 32 bits sur cette carte (à cause de la RAM limité à 512Ko), dans les faits il faut installer le système 64 bits !

Là encore, ça marche. Dans les lignes ci-dessous on produira quelques indicateurs pour le confirmer.

Je n'ai jamais aimé la Raspberry Pi 4, pour moi - en restant poili - c'est une grosse merde qui chauffe sa race et qui n'est pas assez puissante (sortie à 1.5GHz avec des problèmes de température). Par contre j'aime beaucoup la Pi400 (un ordinateur dans un clavier) qui ne chauffe pas et qui s'overclocke facilement jusqu'à 2.2GHz : de qui faire un bureau graphique joli et performant. Finalement l'OS 64 bits de la fondation -qui a pris son temps - est plutôt très bon et Docker + Portainer et quelques containers en tâche de fond, ça roule ! C'est le même 4 coeurs Broadcaom que la RPi4 mais en révision C0 qui ne chauffe pas et qui adore l'overclock.

La Orange Pi 800 disponible début octobre 2022 est une copie de la Pi400. Pour l'instant l'OS proposé est indigne. C'est aussi testé Manjaro, ça fonctionne et c'est beau, mais c'est Manjaro : "la distro qu'y faut mettre les mains dans le cambouis" et c'est fatiguant. L'ensemble Docker + Portainer fonctionne, mais "offre" quelques soucis quand même. Le produit a besoin d'un bon Linux !

La Raspberry Pi 3 A+ est une SBC (Single Board Computer) avec un Broadcom à 1.4GHz et 4 coeurs. C'est une carte très économique, sans RJ45, seulement 512Ko de RAM, mais avec un bon Wifi 2.4 et 5 GHz. On s'en servait depuis des années pour Octoprint... Et ça marche avec Docker + Portainer + Octoprint dans un container ! J'ai ajouté la stack de monitoring aussi sur cette carte, on en parle ci-dessous. Cela fonctionne : Octoprint gère l'imprimante 3D et il faut que ce soit "blindé", bullet proof, que ça marche tout le temps, que l'impression 3D se termine correctment . Et tel est le cas, c'est génial ce que l'on fait avec 20€ d'ordinateur !

Processeurs ARM, ARM64 ou AMD64 ?

ARM est une entité fabless qui ne fabrique pas de processeurs. ARM vend de la licence. Des fabricants de processeurs tels que Broadcom, AllWinner ou Rockchip achètent les licences et "gravent" ou font graver des processeurs. ARM propose des designs de processeurs avec un jeu d'instruction limité (RISC ou Reduced Instruction Set Computer). TSMC, le fleuron de Taiwan, est un fondeur : il ne conçoit pas les processeurs mais les grave pour les clients.

De son côté Intel conçoit et fond ses processeurs. Son architecture x86 est de type CISC à jeu d'instructions complexes. Quand la mémoire était chère, à la préhistoire de l'informatique, cela permettait de faire des économies en déportant vers le processeurs via des instructions complexes la consommation de la mémoire. C'est AMD qui a développé l'architecture 64 bits utilisée aujourd'hui par les processeurs Intel et AMD. De son côté Intel et HP avaient développé une architecture 64 bits mais elle était non rétro compatible avec x86 (16 et 32 bits Intel). C'était une bonne idée pour tout changer et obliger tout le monde à tout racheter, mais le marché en a décidé autrement.

Bon maintenant que vous savez tout sur les architectures de processeurs, quelques points :

ARM c'est fini, il n'y aucun avenir et la liste des applications pour cette architecture ne va pas aller en grandissant. Ca veut dire que si vous attendez un logiciel pour votre vieille Pi en 32 bits, il va falloir chercher dans un unvers parallèle, pas dans celui-ci
ARM64 c'est le présent et le futur : de plus en plus de développements sont disponibles
AMD64 c'est la grosse plateforme, celle qui a le plus de développements, mais le vent semble un peu tourner

Bien entendu nos petites cartounettes n'ont que des processeurs ARM64.

Notez qu'installer Docker + Portainer sur de l'AMD64 c'est la même chose, tout aussi simple ! Cela a été réalisé sur un portable Ryzen 7-4800 ainsi qu'un mini serveur à base d'Intel Xeon :

Les machines

En résumé le parc actuel est composé des machines suivantes :

une Orange Pi Zero 2 (serveur LMS et gestion de toutes les autres machines)
deux Raspberry Pi Zero 2 W, squeezelite (lecteur audio) et monitoring
une Raspberry Pi 400 : développements et tests
une Orange Pi800 pour de la veille techno
une vieille Raspberry Pi 3A+ pour la gestion de l'imprimantre 3D
un portable sous Linux et un serveur sour Linux, les deux en AMD64

On notera que toutes les SBCs sont en ARM64 et les deux ordinateurs sont en AMD64.

Les containers

L'avantage de Docker, c'est que les containers sont contingentés. Si on ne veut plus d'un container, on le supprime ainsi que son image et basta. Ca ne laisse pas derrière soit des milliards de merdes comme ça se passe dans l'OS qui commenc par Win et qui finit par dose.

On a installé :

le LMS sur la OPZ2
squeezelite sur les deux Raspberry Pi Zero 2 et la OPZ2
La stack de monitoring sur toutes les machines (on y reviendra)
Portainer sur la OP2 pour gérer tous les agents portainers sur les autres machines
Agent Portainer sur les autres machines
Homer qui permet de créer un "portail" sur la OPZ2
MeTube qui permet de télécharger les vidéos youtube sur le Xeon
PostgreSQL, base de données relationnelle sur OPZ2
FileZilla, Transmission, MiniDNLA, File Browser, des applications pour gérer les vidéos de vacances de Tatie Danielle, sur la OPZ2
Snippet Box sur la OPZ2
Pixel-Server qui permet de gérer via browser des pixels rings, sur les deux RPiZ2

Le monitoring !

Une stack (un groupe de plusieurs containers qui travaillent ensemble) permet d'avoir du monitoring pour les cartes que l'on gère.

Cette stack génère et stocke de l'information sur la machine. C'est promethus qui assure le stockage et c'est Grafana qui graphe les données.

J'ai laissé la stack telle quelle sur la OPZ2. Sur les autres cartes, j'ai supprimé Grafana. Sur la OPZ2 j'ai branché Grafana aux différents prometheus de toutes les cartes, pour avoir un seul Grafana (sur la OPZ2) qui affiche le monitoring des autres cartes.

Voici un exemple de dashboard qui d'un coup d'oeil permet de voir toutes les cartes :

On peut aussi avoir un dashboard spécifique pour chaque carte. Par exemple, pour la RPiA3+ aux ressources limitées que l'on utilise pour gérer l'imprimante 3D, quels sont les valeurs des indicateurs RAM, CPU, Température, Réseau etc... ?

On va regarder sur les dernières 24 heures (on a imprimé quelques pièces) les données.

Ona un joli Dashboard que l'on va détailler. Le container octoprint se nomme "Ender 3".

Qu'est ce qu'il s'est passé sur le processeur sur les dernières 24 heures ?

Globalement pas grand chose côté CPU.

Chaque pic correspond à l'impression d'une pièce.

Au maximum on se trouve à moins de 10% d'occupation processeur.

Côté RAM, nous avons un pic à 318Ko, soit 70% de la mémoire totale disponible qui est de 451Ko.

Cela laisse assez de marge, on imprime depuis plusieurs semaines avec cette solution et le monitoring a été mis en place il y a presque 3 semaines : tout roule !

Conclusion sur le Monitoring

"Quand on veut savoir, on mesure" : c'est juste une approche scientifique. On peut expérimenter, tester, essayer. Mais quand on a les moyens de mesurer, alors on n'est pas dans le vague, le ressenti ou le "je crois que".

Par exemple, avec le monitoring, j'ai pu aussi supprimer deux coeurs sur quatre et descendre la fréquence à 400MHz sur une RPi2 W et constater que cela fonctionne correctement : c'est un bel outil

A mon avis la stack de monitoring représente la méga cerise sur le gâteau de tout le bazar. Oui, elle prend un peu de ressources. Mais on peut déporter grafana sur une autre machine (et donc le supprimer de la stack locale). Je trouve cela excellent, trés professionnel, un must have.

Un point à signaler avec toutes les données récoltées sur différentes machines / architectures / CPU / RAM. Finalement le processeur est assez peu sollicité en général, par contre la mémoire vive est très utilisée. Les chiffres montrent que dans mes cas d'usage, pour une machine sur laquelle on espère installer un grand nombre de containers, il faut vraiment privilégier la RAM !

Portainer et l'agent portainer

Un zoli dessin, tiré de la documentation de portainer, qui dit que l'on installe portainer sur la machine docker01 et les agents sur les autres machines.

La machine docker01 du schéma, c'est la Orange Pi Zero 2, et les autres dockers se sont toutes les autres machines.

Ensuite, avec la OPZ2 on peut se connecter aux différents agents / machines :

Ci-contre l'interface ouaibe de la OPZ2 qui permet de se connecter "à elle-même" mais aussi aux autres machines qui ont l'agent portainer installé.

La Pi800 est en rouge (Down) parce que la machine est éteinte.

On a des informations globales pour chaque machine et quand on sélectionne une machine, on peut la gérer.

Nous voici connectés sur Gustard X16 qui est la machine "lecteur audio" connectée au DAC Gustard X16.

Sur cette Raspberry on voit les différents containers :

ceux de la stack de monitoring (Grafana a été supprimé)
pixel-server qui permet de gérer le néopixel-ring connecté à la Rasp
l'agent portainer (vous savez ce que c'est)
squeeze_c200 : c'est le squeezelite connecté au DAC SMSL C200, actuellement branché sur une autre machine
squeeze_X16 : le squeezelite connecté au Gustard, en vert, running, parce que c'est le lecteur du salon.

C'est quoi une machine headless ? Et ben vous voyez, dans le pied de la fusée se trouve le lecteur audio, la Raspberry Pi Zero 2 W. C'est contrôlé via un navigateur, il n'y a pas d'écran ni de clavier.

Et vous voyez les petites LEDs rouges qui s'allument au moment de la mise à feu de la fusée ? C'est géré par le container pixel-server.

Pardon pour la photo un peu rubrique-à-brac.

Pixel-server, c'est beau comme une architecture stalinienne. C'est la Traban du site ouaibe.

Mais c'est simple et ça marche, ça permet de choisir des animations, des couleurs et des vitesses d'exécution.

Pour une fusée, c'est normal d'avoir un nuage de fumée qui s'éclaire, non ?

Le néo pixel ring, c'est un anneau composé de néopixels. En réalité chaque "pixel" est un ensemble de 3 leds adressables individuellement. Cela permet d'obtenir la couleur que l'on souhaite selon l'habituelle idée RGB "Rouge Vert Bleu".

Il ne faut pas confondre RGB avec RBG, le dernier acronyme caractérisant la merde de "meta", anciennement face de bouc, l'IA raciste et folle de la compagnie de Mark, euthanasié après 48 heures.

Ha oui, il faut expliquer : RBG c'est Random Bullshit Generator. Yann Le Cum, le Monsieur Modeste de l'IA connaît un nouvel échec : on s'en félicite ! Période faste quand les résultats de meta sont merdiques, que les crypto monnaies se cassent la gueule et qu'Amazon souffre. De temps en temps le bon sens pointe le bout de son nez.

Conclusion

A priori je ne pensais pas que Docker puisse fonctionner avec les toutes petites cartes et dans mes cas d'usages cela fonctionne très bien. J'espère avec ce petit point avoir réussi à partager mon enthousiasme sur le sujet.

Page updated

Google Sites

Report abuse