[Plugin Tiers] Plugin Docker

Tags: #<Tag:0x00007fcba696c890>

Bonjour,

Je viens de mettre en ligne le plugin Docker.

A l’heure actuelle il permet ceci :

Plugin permettant de :

  • 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)
  • Piloter vos containers (Allumer / Eteindre / Rebooter / Kill )
  • Avoir des informations sur les containers (Nom / Statut / Image source pour le déploiement / date-heure de dernier démarrage)

Ce sujet permettra de suivre les demandes le concernant.

Voici le rendu de la page du plugin :

Le rendu sur le dashboard :

1 J'aime

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 :joy:

  • 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 :star_struck:
  • 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! :smiley:

Hello,

Voici mes réponses :

  • 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.

La partie CPU utilisé et mémoire utilisée a été traitée et ajoutée en beta.

1 J'aime

ok ok prometteur tout ça !

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 :slight_smile:

bonne soirée!

Ok, donc oui pas d’impact pour la lecture/pilotage des quelques informations.

Oui je dev sur une V4 mais je déploie aussi sur ma prod en V3.
Donc j’ai le retour directement du rendu sur les deux versions.

1 J'aime

Bonjour à tous,

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”:

image

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.

Et voilà le résultat:

image

++

Hello,

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.

Merci

Hello,

Un extrait du debug quand j’utilise “sudo”:

[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

Merci
++

Ok, tu n’vais pas appliqué la modif dans le sudoers ?

Merci

Re,

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.

Je me suis basé sur le document ci-après : https://docs.docker.com/install/linux/linux-postinstall/#manage-docker-as-a-non-root-user

Je ne peux pas t’en dire plus car je ne suis pas un spécialiste.

++

Hello,

Ç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.

Salut TaG,

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.

C’est cool. Merci
++

Hello,

Merci pour ton retour.

Oui j’ai plusieurs ajout en cours sur la beta. Le changelog est parlant à ce sujet avec les nouveautés en approche ;)!

Bonsoir @TaG

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

Le lien indique la procédure

To create the docker group and add your user:

  1. Create the docker group.
$ sudo groupadd docker

je me suis donc connecté en ssh à mon Synology
StrokesPlus_EEbe5ObxHU

mais je ne peux aller plus loin …

Hello @Didier3L,

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)
https://www.synology.com/fr-fr/knowledgebase/DSM/help/DSM/AdminCenter/file_group_create

Dis moi si c’est mieux, je mettrai à jour au besoin la documentation avec cette procédure plutôt ;).

Merci

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 :thinking: si vous avez une autre solution je dis pas non :wink:

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 :sob:

  • dans un container à droite niveau hôte il y a toujours du vide est-ce normal?
    image

  • 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 !

Hello,

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

Voir le changelog pour plus de précisions.

@ddelec24, pour le startedAt /startedTs

Tu peux me dire si ça continue à te poser problème s’il te plait ?

Merci

Liste des points à voir :

  • 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…