Avoir un résumé sur votre/vos Docker(s) (Nombre de containers total / allumé / en pause / arrêté. version du docker / nombres d’image installées sur Docker / Online)
Bien intéressant, merci de t’être penché sur ce plugin de monitoring!
J’ai vu le multidocker avec accès ssh, parfait je pourrais monitorer mon local et un pre-prod distant.
J’aurais besoin de 3 précisions, qui feront peut être un TODO qui sait
je n’ai pas vu dans ta doc si le plugin renvoyait un docker stats (pour avoir les containers les plus gourmands en %CPU et %MEM surtout)
y a t’il une implémentation d’alerte de prévu? si à la récupération docker inspect on a un State avec une clé dead à true ou un error non vide par exemple
pas de soucis à l’utilisation avec userns-remap activé? (j’utilise Traefik donc je ne l’ai pas d’activé car pas compatible mais ça changera peut être donc ça me vient à l’esprit)
Pour finir, pourrais-tu fournir quelques screenshot histoire de voir si c’est friendly?
merci encore, si c’est good pour moi, début Mars c’est sur mon Panel!
A l’heure actuelle je ne remonte pas de Statistiques, si c’est un besoin, je peux l’étudier
le docker inspect récupère l’état du container, il suffit de se mettre une alerte (télégram/mail/sms si status == X ou Y ou Z ou bien si status != de X ou Y ou Z
Je ne connais pas ton usage avec userns-remap, mais si tu m’explique son usage, je pourrais t’y répondre, ou bien si tu n’as plus accès en SSH à ton docker à cause de userns-remap, oui tu risques d’avoir un problème.
J’ai ajouté deux copies d’écran dans le premier message.
La partie rendu sur le dashboard n’est pas « friendly », mais c’est l’intêret de jeedom, avoir du personnalisable. La bascule en V4 n’est pas encore sèche de mon point de vue, donc faire un widget dédié serait contre productif à l’heure actuelle.
En annexe :
La modale santé arrivera je pense dans une prochaine version.
l’user namespace c’est juste pour isoler un peu plus et rajouter de la sécu et évitant d’utiliser le login root sur la machine host quand il y a besoin du root dans le container, mais en réfléchissant ça doit rien bloquer pour la lecture des infos.
je ferais effectivement mon propre widget pour avoir mes infos, et je suis en v3 actuellement donc je sais pas si tu dev uniquement en v4, jai pas vu de logo sur le market donc ça doit être bon
Tout d’abord un grand merci à TaG pour ce plugin !
Je vous demande d’être indulgent avec moi car je suis totalement débutant sur JeeDom.
Mon instance de JeeDom tournant dans un container Docker hébergé sur un Xpenology, J’ai dû procéder à quelques « adaptations » afin que le plugin renvoie effectivement les informations.
Ma connexion dans le plugin Docker se fait avec le compte « admin »:
Ensuite, je me suis connecté en ssh sur le XPenology et j’ai fait ceci:
synogroup --add docker admin
J’ai ensuite supprimé toutes les occurrence de « sudo » dans le fichier « docker.class.php »:
// Récupération de la liste de tous les containers, pour le debug si besoin
$request = "sudo /usr/local/bin/docker ps -a --no-trunc";
$result = ssh2_exec($connection, $request . ' 2>&1');
stream_set_blocking($result, true);
$dockerList = stream_get_contents($result);
log::add('docker', 'debug', 'On appelle la commande qui récupère la liste de tous les containers sur docker' . $dockerList);
devient donc:
// Récupération de la liste de tous les containers, pour le debug si besoin
$request = "/usr/local/bin/docker ps -a --no-trunc";
$result = ssh2_exec($connection, $request . ' 2>&1');
stream_set_blocking($result, true);
$dockerList = stream_get_contents($result);
log::add('docker', 'debug', 'On appelle la commande qui récupère la liste de tous les containers sur docker' . $dockerList);
Suivi par un redémarrage du paquet « Docker » dans le « Centre de paquets » du XPenology.
Je suis étonné que le simple ajout dans le groupe docker de ton compte admin t’évite le passage par sudo.
Avec ça ne marchait pas ?
xpenology étant une vieille version, ça peut surement venir de là.
tu peux me montrer le log en debug quand tu attaques avec sudo ?
J’ai prévu d’adapter les pages équipements pour ajouter une case ou deux afin de savoir si syno/linux classique / je vais donc rajouter xpenology dans ce cas si c’est utile.
[2020-01-28 15:54:11][DEBUG] : On appel la fonction getDockerInformation
[2020-01-28 15:54:11][INFO] : ========================================================
[2020-01-28 15:54:11][INFO] : ========== Début du log getDockerInformation ===========
[2020-01-28 15:54:11][INFO] : ========================================================
[2020-01-28 15:54:11][DEBUG] : Login utilisé : admin - Ip du docker : 192.168.0. - Port SSH du docker : 2 - Nom Docker sur XPenology
[2020-01-28 15:54:11][INFO] : Docker joignable
[2020-01-28 15:54:11][INFO] : Connexion OK au Docker
[2020-01-28 15:54:11][DEBUG] : On appelle la commande qui liste les VMs sur l’Docker
[2020-01-28 15:54:11][DEBUG] : On appelle la commande qui récupère la liste de tous les containers sur dockersudo: no tty present and no askpass program specified
Ma version de DSM n’est pas si ancienne que ça : DSM 6.2-23739
Si la question est de savoir si j’ai touché au fichier « sudoers » alors la réponse est non.
Je me suis contenté de lancer la commande « synogroup » qui a créé le groupe « docker » (qui n’existait pas) et a ajouté l’utilisateur « admin » dans ce groupe.
Ça m’a été confirmé que ça passe bien cette procédure.
Je vais modifier le plugin dans ce sens.
Ça sera plus simple comme gestion.
C’est pas faute d’avoir cherché une solution sans le sudoers.
Re @pippobimbo, j’ai fais une modification, disponible en beta ou j’ai ajouté un menu déroulant pour indiquer si l’hote docker est de type Linux ou Syno/xpenology afin de correspondre à ce mécanisme.
Si tu es en beta, merci pour ton retour.
J’attends des retours de mon coté également.
Mes tests étant concluants à l’heure actuelle sur un syno.
J’étais sur la version « stable » mais j’ai tout supprimé et j’ai pris la version « beta ».
J’ai coché l’hôte « Synology/XPenology » et cela fonctionne parfaitement.
Au passage, il me semble avoir vu les informations « CPU utilisé » et « mémoire utilisée ». Je ne crois pas les avoir vues la première fois.
Je fais tourner jeedom sur un Synology avec le paquet Docker
J’ai commencer à lire la documentation
Sur un synology, créer un groupe docker (attention à la case), y placer l’utilisateur que vous venez de créer et relancer le package docker sur votre synology via le gestionnaire de package, Procédure
Oui, le lien n’est qu’une aide sur le principe à suivre.
Tu peux utiliser cette procédure pour ajouter un groupe (attention, pas de majuscule sur le nom du groupe docker)
Dis moi si c’est mieux, je mettrai à jour au besoin la documentation avec cette procédure plutôt ;).
Hello!
petit retour après achat et installation. Jeedom 3.3.39 et plugin en stable
j’ai eu quelques heurts pour avoir l’accès sous un serv distant en debian stretch (9), voilà donc ma démarche, commandes exécutées en root:
1/ on créé un utilisateur useradd <MONUSER>
2/ ajout aux sudoers usermod -aG sudo <MONUSER>
3/ ajout aux autorisations de login ssh nano /etc/ssh/sshd_config
chercher « AllowUsers » et si inexistant rajouter la ligne puis ajouter votre nouvel utilisateur dans les utilisateurs autorisés à se logguer en ssh, user1 user2 étant les autres utilisateurs existants et susceptibles de se connecter en ssh. AllowUsers user1 user2 <MONUSER>
puis un service ssh restart pour la prise en compte
4/ Eviter le message « no tty present and no askpass program specified » j’ai bien vu le message plus haut, mais j’ai réussi uniquement par cette méthode:
faire un visudo et ajouter <MONUSER> ALL=(ALL) NOPASSWD: ALL
5/ Pour terminer, mon binaire docker n’est pas au même endroit que celui défini dans le plugin, j’ai donc créé un lien symbolique ln -s /usr/bin/docker /usr/local/bin/docker
Voilà je ne crois avoir oublié aucune étape, le visudo me plaît pas trop mais bon si vous avez une autre solution je dis pas non
Suggestions/Remarques:
si suppression serveur, supprimer les containers liés ou du moins le proposer? sur ce seul serveur j’ai eu 21 containers à me taper à la main
dans un container à droite niveau hôte il y a toujours du vide est-ce normal?
En général on travail sur les 12 premiers caractères des ID, lorsque j’ajoute un container sur le dashboard il est en entier, possibilité de le tronquer à l’affichage? ou je le ferais lors de la personnalisation sinon, pas grave.
Dans l’affichage d’un container toujours, Dernier démarrage est toujours vide
Logs: valeur de la variable bootTime Template parsing error: template: :1:8: executing "" at <.State.StartedTs>: map has no entry for key "StartedTs"
j’ai un « StartedAt » par contre. Docker version 19.03.6 si c’est important
Je peux donc avoir un visu rapide sur ce qui se passe maintenant même si il me manque le dernier démarrage, merci bien pour le plugin qui va me permettre de gagner du temps quand je suis en déplacement !
Je viens de pousser en stable la version beta qui date de fin janvier.
Je n’avais pas abandonné le plugin, mais j’ai déménagé, démissionné etc :).
Donc je reprends les modifications/mises à jours/corrections.
Typiquement le champ Hote docker était déjà corrigé dans la dernière beta.
Je vous laisse voir les points à surveiller sur cette dernière version. Il y a typiquement une recherche du chemin pour l’executable docker en fonction de si c’est un syno ou non.
Donc ATTENTION à bien modifier vos hôtes docker en ce sens via le menu déroulant.
Ajout d’un menu de gauche en easteregg en cliquant sur la petite maison, etc
Container recrée après une mise à jour de ce dernier
StartedTS/StartedAt
tronquer l’affichage de l’ID du docker
Voir comment gérer la suppression des containers ( même si j’ai eu la même remarque coté VMWARE).
Et voici ce que j’avais répondu. si par inadvertance, le serveur est supprimé, on n’a pas besoin de refaire tous les scénarios des containers qui eux n’ont pas été touchés.
Exemple :
Serveur avec 21 containers
15 scénarios différents sur les containers
Tu supprimes par inadvertance le serveur
Tes 15 containers sont en orphelin (section qui n’apparait que si un container n’a plus son serveur)
Tu remets ton serveur avec le même nom
les containers rebasculent sous le serveur, et tu reprends ton chemin :).
J’avais imaginé plusieurs choses, genre, containers qui ne réponds plus alors on supprime au bout de X fois, mais au final je trouve ça trop risqué.
Pour mon boulot, je l’aurais géré, mais là c’est un peu trop risqué, si quelqu’un est en vacances par exemple et son serveur docker tombe sans pouvoir le rallumer :), il rentre et tout à reprendre dans jeedom…
si vous avez une autre solution je dis pas non 
