J’ai pas mal utilisé jeedom sur Raspberry et ayant reçu mon nas Syno il y a quelques jours, j’ai décidé de tout y migrer en m’appuyant sur Docker et les réseaux macvlan afin de bénéficier du BroadCast nécessaire au fonctionnement de certains plugins.
J’ai suivi les différents Tuto ([Tuto] ⏩ jeedom/jeedom:latest - Installation de Jeedom sur Synology avec docker en réseau Macvlan) et réussi à obtenir un jeedom parfaitement fonctionnel.
J’ai ensuite modifié le serveur DNS interne à chez moi (Pihole sur le rasp que j’ai passé sur un docker syno) et après modification du DNS sur mon syno et le restart de les autres docker tout c’est bien passé à l’exception du docker jeedom qui n’arrive plus à résoudre le moindre nom DNS.
Mes questions:
Comment sont gérés les serveurs DNS sous docker? Car mes autres docker contiennent bien la bonne ip dans resolv.conf mais le docker jeedom contient 127.0.0.11 => Comprend pas
De plus, nous sommes d’accord que à part les répertoires mappés localement, le reste est bien perdu à l’extinction? Car comme indiqué dans le tuto, le docker-compose ne map que « /var/www/html » or au reboot, la base de données se trouvant dans /var/lib/mysql est bien conservée. C’est également le cas de tous les paquets installés lors de l’installation de dépendances par certains plugins.
Docker est assez nouveau pour moi mais aucun pb techniquement pour tout ce qu’il y a autours pouvant constituer des explications
La réponse est non
Rien n’est perdu quand du éteint ton docker ou Jeedom
Heureusement d’ailleurs
Le mappage des répertoires sert à avoir un mirroir bidirectionnelle de ton système
Pour aller fouiller dans les entrailles de jeedom c’est bien pratique
ça dépends du network auquel est rattaché ton container… En mode Host ou MacVlan, on retrouve les infos de l’hote. En mode bridge, docker créer un range ip par stack
Comme dis @Didier3L, c’est pas le cas. Outre le fait que c’est effectivement un accès direct aux fichiers, en principe les répertoires/fichiers mappés sont à réserver aux fichiers importants si on veut reconstruire le container (config, certificats etc…). Les volumes classiques (qui sont également dans /var/lib/docker/volumes/ ) sont en général à réserver aux fichiers de travail (temp, cache, données périssables) . La grosse différence réside dans la commande « docker system prune ». Les fichiers mappés sont conservés, les autres sont purgés.
ça c’est un cas particulier de l’image docker jeedom. En principe, une image ne contient pas un OS complet, et le service qu’il contient n’installe pas non plus les packages/dépendances à la volée. Pour un tel ajout en principe on construit une image avec les dépendances incluses, c’est le but des overlays. Comme ça, le jour ou on déplace/duplique le container, l’image est directement prête et pas dépendante de sources extérieures. Elle fonctionnera à tous les coups
