C’est pas le mode host/bridge/macvlan qui determine le fait d’avoir accès ou non aux devices usb. La preuve ici il y a au moins 2 cas qui fonctionnent dont le tien. Le mode va déterminer le fonctionnement du réseau et sa visibilité/accessibilité par rapport au reste du monde :
Host : host et container partagent une même ip unique
Bridge = container à une ip dans son propre vlan et ne sait que passer par le host pour communiquer avec l’extérieur.
macvlan = host et container disposent chacun d’une ip individuelle dans le vlan du host
Dans ton cas, passer sur une vm risque de consommer un peu plus de ressources. À ta place je ferai un nouveau container v4. Une fois fonctionnel, restauration backup, bascule des clés et arrêt de l’ancien.
Avec un docker-compose j’irai même jusqu’à ne changer que l’image, et garder le même container mais pas sûr que ce soit applicable au syno.
Sans changer de container tu peux essayer de mettre à jour le container en téléchargent à nouveau l’image (si la v4 est la même ressource).
Par contre pour les depndances, je ne sais pas comment ca va fonctionner…
Backup bien avant sur ton NAS jeedom ailleurs que dans le container…
Pour ma part je ne comprends tjs pas comment les dependances du container peuvent être gérées proprement et persistantes pour jeedom.
Pour l’affectation des ports USB, même probleme avec des VM syno. Je pense que c’est plutôt un problème du syno lui même
C’est justement pour cela que Docker ne répond pas a l’architecture de Jeedom, alors certes ca « dépanne » mais c’est pas conforme a l’usage initiale de docker.
C’est comme un CD rom réinscriptible ! l’utiliser comme disque dur c’est un « concept » mais ca ne veut pas dire que ca ne fonctionne pas, jusque que ce n’est pas fait pour.
Oui je suis en phase avec toi !
Certains le font marcher, bien à priori, mais ça demande tout un tas de customisation du docker.
Pas fait pour ça à la base.
C’est vrai que c’est pas forcément une priorité… mais si on peut faire en sorte de respecter les standards, c’est mieux Pour la facilité d’installation (aujourd’hui, faut bien avouer, installer une image docker jeedom c’est le chemin de croix), aussi pour maintenir plus facilement nos scripts Dockerfile / docker-compose & co, ça sera toujours plus simple si on a suivi les « normes » de développement Docker.
Moi perso je n’utilise jeedom sous docker que pour du test / développement, et sans plugin USB pour le moment, c’est le cas d’usage optimal. Je me suis fait une image perso sans la BDD pour commencer mais j’envisage d’aller plus loin dans la séparation des containers:
1 container BDD
1 container reverse proxy (nginx ou traffic)
1 container jeedom sans apache avec seulement le cron donc.
1 container mosquito MQTT pour les plugins compatibles
C’est déjà un bon début Ensuite il faudra séparer les « gros » plugins ceux avec cron ou démon dans leur propre container s’ils ne peuvent pas utiliser MQTT. Les plugins non invasif, sans cron ni démon sont intégré dans le container jeedom sans problème, faut pas non plus couper les cheveux en 4.
Bref, pour moi Docker actuellement je l’utilise juste à titre de développement.
Là je ne comprend pas, un plugin a besoin de l’intégralité du core de jeedom pour tourner donc comment veux-tu mettre uniquement un plugin dans un container?
Je pense qu’il veut dire gros plugin + core.
De mon coté si je devais etudier le passage sous docker j’adopterais ta methode qui est proche de celle que tu enonces @pifou
serveur web, apache, php and cie (avec fichier www sur hote)
mariadb (avec bdd sur l’hôte)
un core pour le système cron
Les plugins etant stockés sur l’hote dans www je pense que c’est la maniere la plus simple.
Pas simple car il faudrait une doc d’archi de jeedom pour confirmer le meilleur schema
Si tu veux partir sur docker extrait aussi les protocoles et communique le protocole et ton jeedom a travers mqtt c’est pas le top mais ça sera le plus propre.
Sous jeedom tu as le plugins mqtt
Et tu as une image docker par ‹ cle usb › zigate, zwave etc…
Oui « système cron » c’est le démon du cron, c’est un processus distinct et Docker n’aime pas avoir 2 processus dans le même container, d’où l’idée de mettre apache dans 1 container et le cron dans 1 autre. Peut être en effet le mieux est de mettre le source jeedom dans un répertoire partagé dans le host, disponible pour tous les containers.
Pour les gros plugins je pensais à ceux qui ont un demon justement, qui est souvent indépendant parce qu’il est en python et n’a pas besoin du core (genre z-wave) ça correspond sans doute à ceux qui ont leur propre protocole, donc pourquoi pas utiliser MQTT.
Perso, je préfère docker. Jeedom fonctionne très bien et l’installation + lancement très simple.
l’inconvénient des VM, c’est si on en a plusieurs, les sauvegardes deviennent imposantes en terme d’espace.
De plus, au niveau sécurité, si on expose les VM à l’extérieur, il faut le faire sur chaque système de la VM. Ce qui peut être assez lourd à gérer si on en a beaucoup.
pareil pour les mise à jour.
avec le docker, on c’est plus simple et il utilise beaucoup moins de ressources et d’espaces de stockages (pour les backups). les mises à jour sont plus simples et rapides. La sécurité est centralisée pour tout les containers.
Pour avoir longtemps utilisé proxmox, je suis passé à docker. Les VM sont intéressantes pour les entreprises où plusieurs informaticiens travaillent sur la sécurité et les mises à jours.
Jeedom n’est pas fait de base pour tourner sur docker. Plusieurs le font sans problème (non sans mal) mais c’est plus complexe a gerer pour quelqu’un qui n’est pas « bidouilleur ».
J’ai exposé les raisons plus haut. Notamment sa dependance à l’OS, mise a jour, etc… .
Le faire correctement necessite plusieurs dockers et un travail important.
On y gagne en perf, c’est logique puisqu’on enleve la couche de virtualisation de l’OS.
Concernant la secu, mes VM ne sont pas exposées sur le web malgré que jeedom et autres applis soient dispo sur le net. Et même si elles devaient l’etre ca ne pose pas de soucis si tu maitrises ton routeur/firewall et quelques composants type fail2ban.
Perso, je n’ai que mon reverse proxy qui est exposé, les redirectionss sur les VM ce n’est qu’en local. De plus ca simplifie l’ouverture des ports web puisque tu n’as que le 80 et 443 quelque soit le nombre de vm ou de serveurs ou même de docker
Huawei pour ma part
Mais attention aux modeles et au firmware.
Il y plusieurs modes possibles.
Sino’ un truc pas mal que j essaye de faire : acces internet de backup a la fibre sur un routeur mikrotik. Ca ca marche pas de soucis. Mais envoi de sms en appelant fonctions mikrotik.
Sinon si tu as un device avec jpi avec SIM, possible aussi
Merci pour vos retours @naboleo@loic69@PHB_fr@Didier3L et @pifou !
Bon je suis tjs sur docker en v3.3.57, c’est super stable, plus aucun problème d’affectation des ports, ça fonctionne à merveille.
Depuis quelque temps, il y a un joli bouton « Mettre à niveau V4 » dans le centre de mise à jour, mais j’avoue ne pas avoir pris le temps de faire la démarche (travail en présentiel à 100% sans arrêt et c’était plutôt une année travaux le reste du temps) mais c’est pour bientôt d’autant que Syno vient de sortir DSM 7…
Je devrais pouvoir dupliquer la BDD ainsi que le conteneur pour en migrer une en V4 et garder l’autre sous le coude le temps de tout remettre d’équerre.
Perso, l’install sous docker a été super simple, la configuration aussi.
J’ai récemment galéré pour migrer de MariaDB 5 à MariaDB10 sur le syno car mon MDP de la BDD jeedom n’était plus en règle avec les nouvelles et qu’il m’a fallut dégoté le fichier common.config.php pour le modifier.
a-t-on des nouvelles sur le fait de pouvoir faire fonctionner le container Jeedom sous Docker en mode macvlan sous DSM 7?
Pour ma part (en plus de mes instances de prod sur Freebox Delta et RPI 4b) j’avais une instance de test/préprod dans un container Docker sur mon NAS Synology (DS415+ qui ne supporte pas VMM a priori) via ta procédure, et sans utiliser de clef USB sur le NAS (pour un certains nombres de raisons, mais en particulier car je n’en ai plus de libre car utilisation de HDD externes).
Cela fonctionnait très bien sous DSM 6.2.
J’ai migré pendant les vacances en DSM 7 et là effectivement, mon container n’est plus accessible… alors qu’il démarre très bien sans encombre.
Est-ce un soucis dû au macvlan?
Quelqu’un a -t-il contourné ce problème? (Ok je vais créer un nouveau topic pour ces questions)
Pour la facilité d’installation (aujourd’hui, faut bien avouer, installer une image docker jeedom c’est le chemin de croix), aussi pour maintenir plus facilement nos scripts Dockerfile / docker-compose & co, ça sera toujours plus simple si on a suivi les « normes » de développement Docker.
Ensuite il faudra séparer les « gros » plugins ceux avec cron ou démon dans leur propre container s’ils ne peuvent pas utiliser MQTT. Les plugins non invasif, sans cron ni démon sont intégré dans le container jeedom sans problème, faut pas non plus couper les cheveux en 4.