Debian 11 + docker jeedom

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.

Aucune idée je n’utilise pas docker j’ai juste fait quelques essais a une époque et j’ai pas accrocher du tout.

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 …

-v /opt/jeedom/www:/var/www/html
-v /opt/jeedom/db:/var/lib/mysql

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/

Merci en tout cas pour les échanges.

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…

1 « J'aime »

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.

On s’en fout des règles de l’art qui est surtout une usine à gaz

C’est toujours la même chanson il faudrait faire comme ceci comme cela
Mais on cherche le tuto.

Jeedom fonctionne parfaitement sous Docker avec des répertoires mappes
Et les ressources hardware sont minimum

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 )

Non. Il faut juste vérifier que les Démons se relancent

1 « J'aime »

Il y a du nouveau depuis l’ancien forum :joy::joy::joy:

Pourquoi chercher des tutos exotiques alors que c’est dans la doc officiel :
https://doc.jeedom.com/fr_FR/installation/docker

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.

C’est vrai ! Merci de la correction

Salut par contre je rencontre des problème pour les clé usb entre autre la clé bluetooth qui est pas reconnue par jeedom

Du coup pour les mises à jour tu utilises un container Watchtower pour bien automatiser le tout et avoir la dernière version de jeedom présente sur dockerhub qui pour la stable a été builde ce jour ?

Cf : Docker Hub

Je laisse faire les MAJ direct depuis jeedom pendant à peu près 5 à 6 mois, après je fais la mise a jour manuellement, je préfère controler les retours sur la version avant. Donc je tue le conteneur ainsi que l’image et le re créer.

1 « J'aime »

C’est étrange, normalement tu as accès aux USB de la même manière.

voila ce que vois dans mon debian avec docker

Et dans jeedom

Bonjour @titof2375
Tu dois faire la commande lsusb dans ton conteneur jeedom, pas dans ton système hôte.

Sinon, @tous, sur quelle machine vous avez réussi à utiliser l’image officielle jeedom docker ? Moi sur RPI4 impossible c’est pas compatible, je suis obligé de me la builder en local. Ce n’est que pour mes tests alors je me suis fait un dockerfile spécifique. Sinon avec l’image officielle j’ai cette erreur docker au démarrage:

WARNING: The requested image's platform (linux/amd64) does not match the
  detected host platform (linux/arm/v7) and no specific platform was requested
standard_init_linux.go:228: exec user process caused: exec format error

Je suppose que Watchtower n’est pas utilisable dans ce cas là ?

Sauf pour les clés Bluetooth
Il faut lire le tuto exotique :blush:

1 « J'aime »