Bonjour,
Je suis bien au courant des problèmes de compatibilité avec Jeedom et Debian 11 ainsi que les recommandations de rester sur debian 10.
Cela dit, je n’utilise pas l’installateur Jeedom, mais le conteneur … et par définition de docker, les conteneurs ne sont pas impacté par les problèmes de compatibilité du système hote.
Je dois refaire toute l’installation de mon serveur pour cause de crash, j’hésite donc entre passé sous debian 11 qui contient le dernier kernel et donc toute la compatibilité matérielle de mon NAS maison, ou passé sous debian 10 et me taper les mises a jour de kernel comme j’avais fais a l’époque.
J’avoue que le passage sous debian 11 m’arrangerai bien, et l’utilisation de Docker pour jeedom devrai résoudre ce problème de compatibilité.
Il y a plusieurs sujets évoquant le fait qu’il est plus que préférable de rester sous Buster.
Certes Jeedom peut tourner dessus mais les plugins et dépendances non.
Entre incompatibilité et versions de paquets incohérents, tu vas au devant de gros soucis.
Tu crois que ça vaut le coup de repartir pour un tour comme pour le passage de Stretch à Buster avec les questions sur le forum à n’en plus finir : euh, pourquoi ça marche pô ?
Pour ma part, j’attend l’annonce officielle Jeedom pour la compatibilité Bullseye. Il y a suffisamment de questions sur l’utilisation standard pour éviter d’en générer d’autres.
Je n’ai pas dit pourquoi cela ne marche pas, j’ai lu beaucoup de doc sur le sujet, je comprends tout à fait que cela ne marche pas sous debian 11, que debian 10 utilise python 2 … c’est normal d’avoir des problèmes de compatibilité.
Mon incompréhension c’est sur le « cela ne marche pas dans tout les cas » qui est exposé partout …
Justement le principe de Docker c’est de pouvoir faire tourner une api peu importe le système … que ce soit debian, ubuntu, windows, mac, fedora ou autre normalement le conteneur fait son bout de chemin dans son coin … J’essai donc juste de comprendre pourquoi un conteneur jeedom sous debian 10 ne fonctionnerai pas installer sur un debian 11.
bonsoir,
tout simplement docker est un empilement si ta couche de départ est du debian 11 les autre couche ne pourront que s’appuyer sur celle-ci …
part sur des VM dans proxmox tu n’aura pas ce problème.
A gauche le conteneur jeedom, a droite mon système hote.
Dans mon debian 11 aucune trace de python, et on voit bien la version 11.1 de debian.
Dans le conteneur Python 2.7.16 et debian 10.10
Cela confirme donc en effet l’utilité des conteneurs, vous m’avez presque mis le doute avec les problèmes de compatibilité alors que le fondement de docker c’est justement d’installer son app avec son système qui va bien … seul le kernel est identique sur les deux systèmes, mais les dépendances sont bien isolé.
Alors comment cela se fait qu’on peut avoir des conteneurs sous alpine linux, d’autre sous debian 8 ou 10 et d’autre sous ubuntu serveur … lorsqu’on est sous debian 11.
Docker n’est pas du tout la meme philosophie qu’un « qemu/VM »
L’image docker est faites pour être dans un mode « lecture seule » (un peu comme un « live cd » a l’époque et avec un clé usb qui contient que ton « home » pour tes fichiers.
Le but de chaque image est de proposer un « service » et pas une VM complète (un pour php, un pour apache, un pour mariadb etc etc…) et l’interconnecter les images (les CDs) avec des volumes « persistants » pour les « datas » (la clé USB)
L’architecture de jeedom ne se prête pas du tout a ce type d’installation (principalement en raison des dépendances et installation apt-get / package )
Sur le principe ca peut fonctionner mais ne pas etre exploité dans un mode « prod » mais plutôt dans un mode « lab »)
J’utilise jeedom en docker depuis 3 ans, et je n’ai jamais eu de problème.
Je suis bien d’accord sur toute la première partie et c’est d’ailleurs le gros avantage de docker, si on fait une boulette on reboot ou on tue et refais…
Par contre, le 2ème gros avantage de docker que tu oublies, ce sont les volumes, c’est justement grâce au volume que ton jeedom sera stable et qu’à chaque reboot rien ne sera perdu …
Cela permet de faire la sauvegarde apache ainsi que mysql a chaque reboot.
De plus, en sauvegardant mon dossier /opt/jeedom/ je sauvegarde jeedom dans son intégralité, ce qui dans mon cas après mon crash m’a permis de relancer l’ensemble des conteneurs en 3min trop chrono juste en rétablissant /opt/
Tu ne dois pas avoir 2 tonnes de dépendance / apt-get qui eux vont écrire ‹ ailleurs › sinon c’est pas ‹ propre › ton histoire ( même si sur le principe ça fonctionne )
Après comme tu le montres tu as ton volume jeedom et ton volume mariadb ça ne devrait pas être dans la même image si tu veux être dans la règle de l’art.
Ensuite comme tu le sais tu as ta « clé USB » = les volumes c’était le moyen de vulgariser le dossier Home / volume c
omme j’ai indiqué a mettre en face le cd live qui lui ne de devrait contenir aucune écriture dedans ( ce que ne peux pas être le cas avec l’architecture de jeedom et la gestion des packages.)
En gros il faudrait que dans l’image de jeedom tu es l’ensemble des packages nécessaire et tu interdits pour les plugins la possibilité de le faire.
A ce moment, la tu pourrais le faire en toute tranquilité.
Avec un jeedom sans dépendance, un usage en jmqtt et ensuite que des images pour les protocoles ça pourrait le faire et ça serait une belle solution qui rend chaque sujet indépendant et avec des moyens de « rollback » de version ( l’avantage des images )
Je vois ce que tu veux dire est c’est vrai pour les dépendances, il faudrait donc mettre aussi /etc/ dans un volume.
Après dans mon utilisation, j’ai beaucoup de dépendance et mes backup jeedom ne font pas loin de 600Mo … et pourtant même quand je reboot le conteneur tout cela se passe très bien. Mais je suis d’accord avec toi que lorsque le conteneur reboot il faut recréer les dépendances, cela va bien sur ma machine assez puissante…
Reboot le container où tu purges ton image que tu vas reprendre sur le hub docker ? Car la ça change tout …
Le but c’est que tu ne fasses pas de mise à jour par le processus jeedom, mais bien que tu récupères la mise à jour d’une image jeedom et si tu fais ça . J’ai comme un doute que ça se passe bien.
Tuto de quoi une personne l’a déjà proposé sur l’ancien forum et Loïc a l’époque avait répondu que ce n’était pas possible dans l’architecture actuelle de jeedom.
Ça n’empêche pas de proposer une image de test c’est le but de docker pour permettre un déploiement facile et rapide sans dépendre du Matériel comme le serait une VM ( driver réseau, divers technologie vmware, virtualbox ou du qemu )
Et je te confirme que je fasse les mises à jour depuis l’image de jeedom ce que je fais tout les 6 mois pour la sécurité, ou depuis jeedom en automatique dans les deux cas cela se passe très bien.
