Bonjour, je voudrais proposer d’intégrer Jeedom dans Docker, ou l’inverse selon les cas, mais d’abords une explication
On peut piloter Docker - sur l’host - depuis un container, comme le ferait par exemple portainer : une application dans un container qui permet d’ajouter / modifier / supprimer d’autres containers à côté de lui. Et j’ai découvert récemment que c’est en fait assez simple, mode d’emploi en 2 étapes :
Je lance un container debian et je partage (mount volume) la socket du démon Docker: docker run -ti -v /var/run/docker.sock:/var/run/docker.sock debian:11 bash
Dans mon container j’installe seulement le package docker-ce-clisuivant la doc officielle (il faut d’abord ajouter les clés et le repository spécifique aux sources apt) apt-get install docker-ce-cli
… Et puis c’est tout, je peux désormais utiliser docker comme s’il était installé dans mon container, sauf qu’il est sur l’host et c’est là que tout se passe. Alors du coup, j’en viens aux suggestions et j’ai 2 propositions pratiques sur des plugins (ne concerne pas le core à priori)
plugin-docker2 ( et / ou plugin-docker ?) depuis mon container Jeedom, je voudrais pouvoir, déjà installer le plugin pour commencer, la procédure étant différente puisqu’on n’a besoin que du package cli … Ensuite, pouvoir gérer les containers autres sur l’host, puis en ajouter ! En vrai, ce n’est que l’installation du plugin qui change, puisque ensuite les commandes docker son identiques
plugin #pyenvJeedom (qui n’a pas encore de tag) de @Michel_F - très bonne initiative en passant ce plugin - depuis mon container Jeedom, je voudrais que l’environnement python soit installé, non pas dans un venv dans mon container, mais dans un container spécifique python dédié.
C’est tout pour le moment, j’attends vos retours avant de me lancer dans des trucs plus poussés. Aussi il y a peut être d’autres possibilités qu’on n’imagine pas encore, ça viendra à l’usage
pyenv est en soit un outil permettant d’installer et d’utiliser différentes versions de python sur la même machine. Ces versions de python sont indépendantes du système et indépendantes entre elles. Il est possible de créer des virtualenv dans une version de python et ces virtualenv sont isolés des autres virtualenv quelle que soit la version python associée.
Donc en soit, pyenv est déjà une bonne solution d’isolation d’environnements python.
pyenv4Jeedom n’est rien de plus qu’un plugin qui sert d’interface entre n’importe quel plugin et pyenv installé une seule fois sur la machine Jeedom dans un sous-répertoire du plugin pyenv4Jeedom.
Selon moi, le fait d’isoler pyenv dans un container est presque inutile ou alors j’ai mal compris le principe que tu expliques. Je précise que ce n’est que mon avis avec ma compréhension actuelle de ce que tu proposes.
En tout cas, comme pyenv isole bien tout ça, je ne vois, à première vue, pas l’intérêt de le mettre dans un container dédié. Sauf bien sûr si autre chose qu’un plugin Jeedom avait besoin de pyenv. Et encore…
Tout à fait, en fait, je voulais vraiment remplacer pyenv et / ou venv par le container dédié. ça n’a en effet aucun intérêt de remettre un pyenv / venv à l’intérieur du container
Et pourquoi ne pas utiliser pyenv au lieu de créer un container dédié qui aurait la même fonction ?
Et si tu fais un container dédié pour cette fonction, il va y avoir quoi dans ce container ?
L’intérêt c’est de simplifier mon container Jeedom, si on arrive à migrer tous les plugins qui utilisent python sur ton plugin, on n’a plus besoin d’installer aucune version python dans le container jeedom. Si c’est plus simple c’est plus stable aussi, plus rapide a arrêter / démarrer, facile à maintenir.
Aussi je me demande jusqu’à quel point on ne pourrait pas pousser une image Docker des démons pour chaque plugin qui en a besoin, mais la ça dépasse le sujet de cette suggestion (une chose à la fois).
Mais ça, ça dépend des devs de chaque plugin. Mon but n’est absolument pas de forcer qui que ce soit à utiliser ce plugin.
Je ne suis carrément pas un spécialiste docker et ne l’ai pour le moment que très peu testé, mais je ne suis pas certain que l’utilisation de docker dédié à chaque fonction soit une solution viable pour les petites configs.
Je plussoie ca simplifierait beaucoup les problèmes de dépendances. Pour bien faire il faudrait adapter le core et les autres plugins en conséquence…
Le principe est de séparer les données variables comme le parametrage du code qui lui ne bouge pas sans quoi des que le container est supprimé les maj qui ne sont pas dans l’image le sont aussi.
Quand c’est pas trop compliqué ex mosquitto on peut passer par des variables au lancement sinon pour les autres cas ex zwavejsui on monte un volume. C’est tres simple une fois qu’on a compris le principe
Pour info j’ai récemment ajouté le support docker au plugin-zwavejs
Il me reste encore faire la PR qui va bien a l’équipe Jeedom en espérant qu’ils l’integreront…
Sympa ton fork j’avais pas vu ton sujet - faut m’excuser je suis pas assez assidu du forum.
Pour bien faire, selon moi, il faudrait que ça n’aie pas d’impact sur le core, et que les plugins puissent automatiquement détecter si c’est inside docker ou version legacy, et je pense que c’est possible, si un plugin prend en charge d’une façon générique l’implémentation d’un démon dans ou hors docker selon le contexte. Donc oui il faudra prendre en charge la gestion des volumes partagés.
c’est mon but pas « forcer », mais du moins, inciter à ce que les plugins proposent le choix entre docker ou legacy install lors de l’installation des dépendances de démons.
