La base est bonne mais attention dans ta gestion tu ne tiens pas compte lors d’une mise a jour de l’image des dépendances et des packages qui sont installés par les plugins
comment tu déclenchés l’ensemble de mise a jour des dépendances , le relancement des services a la fin ?
Non, en effet ce n’est que une base, de toute façon chaque plugins installent ses propres dépendances, c’est automatique. Enfin si, j’ai mis quelques dépendances ( en particulier python & co ) mais le but c’est surtout d’avoir le jeedom core, une image docker stable.
Par contre, à chacun de se faire une sauvegarde de son image docker après installation des plugins, ça peut être utile et je ne pense pas que jeedom le gère dans son backup (?)
Faut que la philosophie de docker c’est pas de faire des images qui deviennent des VM 
Ce qu’il faudrait c’est un backup de jeedom ( si le volume persistant est /var/www ok mais dans ce cas tu ne peux plus fournir une image contenant une mise a jour du core … )
Lors de la restauration il faudrait que l’ensemble des dépendances se lancent ( mais pas en même temps sinon Apt va devenir fou ) et relance a la fin les services quand on refait ou relance une image et ou le contenaire …
Ok alors en vrai, je ne connais pas vraiment les VM ( et du reste je suis assez nouveau sur docker aussi 
)
Dans mon build, il n’y a pas de volume persistant, donc en fait, la sauvegarde de l’image docker suffit à la fois pour jeedom (core & plugins) et les dépendances, il ne manquera que le backup de la bdd.
Je suis parti sur le même principe.
J’ai créé mon image sur la base de Debian Buster, jeedom v4 et avec un réseau macvlan.
et sans volume persistant, à l’exception du répertoire Backup
Pour la sauvegarde complète, je transforme mon conteneur en image.
et je sauvegarde l’image sur un disque ou une clé USB
Si besoin je peux restaurer mon image en conteneur
Vous perdez totalement le coté image / contenaire multiple voir scalable et avec update auto de l’image a chaque mise a jour …
Bref c’est tout sauf du docker… un peu de lecture 
Containers ou VM : comment faire le bon choix ? - Le Monde Informatique
PS : L’image jeedom ne devrait pas inclure ni la BDD, ni php tout ca devrait dans d’autres images linker pour ne pas se farcir les mises a jour de toute l’image alors qu’il y a que jeedom par exemple.
Jeedom c’est l’application, si tu n’inclu pas jeedom dans l’image jeedom ce n’est pas une image jeedom, c’est une simple image linux apache server… qui se crée en 1 seule ligne. ça parait donc logique de mettre jeedom dans l’image jeedom ou sinon à la limite dans un volume partagé, donc dans le « host » mais dans ce cas aucun backup du jeedom core ?
Mon installa donc bien 2 containers: Jeedom et mariadb.
J’ai vu des exemples avec 3 containers: un serveur nginx, configuré en mode « reverse proxy », un autre pour php en mode CLI + l’application jeedom (pas de serveur apache) et le 3eme pour la BDD. Mais à priori apache ne permet pas ce genre de séparation.
J’ai déjà lu ce genre de discours sur la mauvaise utilisation de Docker.
Sauf que :
systemctl
Alors on fait au mieux.
Qu’est-ce que cela peut bien faire de ne pas utiliser la philosophie de Docker.
Du moment que le conteneur tourne avec un minimum de CPU et de RAM.
Pour finir, on attend toujours que les « spécialistes » de docker créé des tutoriels pour nous aider …
Bonjour,
Je t’invite à aller lire les nouvelles modifications apportées par Jeedom sur leur image docker.
C’est un choix de jeedom de ne pas respecter les principes de docker…C’est leur bébé, je respecte ce choix même si j’aurais aimé autrement. 
Donc, les utilisateurs font ce qu’ils peuvent pour avoir du jeedom sous docker avec la matière que jeedom fournit.
C’est bien de repréciser les best practices mais il faut rester dans le contexte jeedom aussi. Si la matière n’est pas top (prévue pour docker) à la base, il ne faut pas s’attendre aussi à des miracles. 
Le principe des tutos est de donner différentes pistes pour du Jeedom/Docker. Pas de donner des cours sur Docker ou d’imposer sa solution. 
Je considère que qq un qui se lance dans un installation Jeedom/docker, non conseillé par jeedom, sait ce qu’il fait et a un minimum de connaissance sur docker. 
Bonne réponse zaibakker, Sauf que ce « pré-requis » ou contrainte n’est pas mis en avant, et qu’il ne permet pas l’usage des :latest avec des mises a jours des images en auto ( comme le propose https://github.com/containrrr/watchtower ) par exemple.
Pour les images il faudrait prévoir :
Mariadb
PHP
Et ngnix / jeedom
Avec un link du tout et juste sortir le port 80 du container jeedom.
Pour le volume il faudrait uniquement faire une resortie du dossier plugins et thème / widget
Après lors du démarrage ( je ne crois pas que ce soit possible c’est aussi pour ça que jeedom ne propose pas d’image !! Dites vous bien qu’il y a quand même une raison) . Il faudrait pouvoir forcer la possibilité de faire un contrôle de l’ensemble des dépendances du dossier plugins
Avec un Split des containers et les apt-get des plugins ça risque d’être tendu et de provoquer la réinstallation de l’ensemble des packages PHP par exemple et la tout l’intérêt de docker s’effondre.
Donc c’est bien de donner des pistes mais si le but c’est de mettre tout le monde dans le fossé !!! Je vous laisse gérer ensuite les utilisateurs qui viendront se plaindre que jeedom ne fonctionne plus !! Sauf que la ça sera pas le tuto qui sera mis au clou mais jeedom directement !
On est tous impatient de lire ton prochain tuto pour savoir comment il faut faire
oui @PHB_fr j’insiste aussi sur le fait que c’est juste un autre tuto, pas l’image officielle ou l’install officielle, comme dit @zaibakker, ceux qui vont le tenter savent un minimum ce qu’il en est. Et je t’invite volontier à l’améliorer
Comme je disais, j’ai déjà séparé en 2 containers (mariaDB d’un côté, le reste du monde de l’autre) et si l’on veut séparer en 3, la bonne séparation c’est celle ci:
Dans ce cas il suffirait de modifier le FROM de mon docker file : FROM php:7.3-apache-buster par FROM php:7.3-fpm-buster par exemple (FPM pour FastCGI Process Manager) mais par contre il faut ajouter nginx avec sa configuration spécifique que je ne connais pas.
J’ai parfois eu des erreurs systemctl lors de l’install jeedom sous docker, vu dans les logs… Mais ça n’a pas d’impact, je veux dire ça n’empêche pas jeedom de s’installer & démarrer, c’est quoi ce systemctl et quel est le problème ?
Bonne approche @pifou pifou ta séparation ça serait effectivement une bonne ( voir très bonne ) base.
Il me semble que les scripts jeedom lors de l’installation cherche a relancer des services d’où le systemctl ( apache ou d’autre service pour être sûr qu’il soit actif au démarrage ? ) c’est peut être une explication au problème ?!?
@Didier3L je vais pas faire une image docker ou quoique ce soit. A la base jeedom n’a pas du tout une orientation pour fonctionner sur ce mode je vais pas m’amuser a aller contre nature. Quand je dis qu’un rond rentre pas dans un carré c’est un constat pas besoin d’être architecte ou menuisier en coupant la pièce pour la faire rentrer !. Il suffit juste d’un peu de bon sens et de connaître l’environnement qu’on utilise ( ici docker ).
Si tu veux un jour faire une image docker ‹ propre › il fautdrait commencer a travailler sur jeedom ( déjà un relancement automatique des dépendances de tous les scripts seraient une avancé et ça en amont de la création d’une image )
( Ça veut dire aussi chercher dans la bdd de jeedom s’il y a un moment de savoir qu’on part d’une nouvelle image pour que tout se relance, cherche un bdd en base ou via un volume ? )
Merci pour tes conseils
Mais mon conteneur fonctionne parfaitement et je ne rencontre pas les problèmes que tu cites
Un conteneur qui fonctionne chez toi, c’est bien… un conteneur qui pourrait fonctionner chez tout le monde, c’est mieux les bonnes pratiques vont nous aider à atteindre ce but! (enfin si on y arrive)
Alors moi, je n’utilise plus ce script dans mon conteneur : j’utilise la base PHP+Apache, j’ajoute un max de dépendances pour Jeedom, et puis c’est tout
Ensuite, Jeedom à la 1ere exécution nous demande les paramètres de connexion à la bdd (donc il faut l’avoir installée dans un autre conteneur), et c’est la qu’il installe des trucs en plus que je n’ai pas encore réussi à mettre dans dockerfile :
Par ailleurs, mon build ne lance pas le cron, il s’ensuit que jeedom croit qu’il n’est pas démarré et je dois lancer manuellement les taches (dans le menu « moteur de tâches »)
Une image ‹ propre › ne doit pas forcément avoir toutes les dépendances des plugins, il suffit pour ça d’aller dans la page ‹ santé › de jeedom, voir et relancer les dépendances des plugins KO et le tour est joué.
Je viens de voir que Loïc a fait une image d’installation ISO de jeedom
Il faudrait peut être regarder dedans voir s’il y a des scripts un peu plus spécifique. il le semble avoir lu que lors de la restauration d’un backup jeedom relance les dépendances des plugins c’est plutôt une bonne nouvelle il faudrait dans l’image de contrôler voir s’il y a un fichier de backup dans un volume , restaurer le fichier et le modifier pour ne pas le relancer a chaque démarrage.
Une image ISO ce n’est pas docker, quoique l’objectif est le même: dans les 2 cas, on veut générer une image propre, qui s’installe tout seul -ou presque-, charge ensuite à l’utilisateur d’importer son backup (backup jeedom avec les données et les plugins)
Mais une image ISO, c’est pour graver directement sur une carte microSD, rien à voir avec docker et il n’y a pas non plus de volume partagé, il faut importer ton backup dans jeedom manuellement.
Comme tu le dis il y a un processus dans l’iso ( et peut être aussi les bons packages a mettre de base ) c’est plus pour décortiquer ce qui est dedans
PS : je sais bien qu’une ISO c’est pas une image ou un container ;)) c’est juste le processus d’installation qui est dedans qui pourrait ( peut être ) être analyser pour le transposer
Quand jeedom est redémarré il ne relance pas de dépendances.
Il vérifie si les Démon sont OK ou NOK
Quand il m’arrive de redémarrer mon conteneur, jeedom exécute de lui-même cette fonction
Pour les ISO ; ce sont des images mise à disposition sur le docker Hub qui sont toutes « presque » à l’emploi. Le core de jeedom y est installé.
Les images master et latest sont restées sur le Hub pendant deux ans avant de disparaitre il y a quelques mois.
C’est pourquoi j’ai mon tuto en « obsoléte » et j’en créé un autre sur la base de Debian Buster et avec réseau macvlan
Et effectivement, une image latest a refait surface qu’il va falloir tester.
Mais faut pas rêver ! on ne trouvera pas la « philosophie » docker avec un découpage de service dedans
D’ailleurs en avril Loïc écrivait :
By the way I begin to develop a package manager inside jeedom core the purpose is to simplify install.sh, install.sh just install need package to start and pass the work to packages.php which install missing package.
Donc dans le fichier packages.php c’est ce qui permet ou permettrait de relancer les dépendances par exemple.