Migration vers la version docker de Jeedom

Bonjour.
J’ai décidé de migrer vers la version Docker de Jeedom. Je m’inquiète de savoir comment déplacer mes périphériques vers le nouvel environnement.
Est-ce que je dois réinitialiser les dépendances?,
est-ce que je dois installer le plugin jmqtt à partir de zéro et restaurer à partir d’une sauvegarde ?

Si quelqu’un a une expérience antérieure, merci de m’éclairer.
merci

Hello,

La restauration de la sauvegarde de Jeedom et l’installation des dépendances de jMQTT doit se passer comme d’habitude.

Par contre, en docker, il est recommandé de ne pas installer Mosquitto dans Jeedom, mais dans un container à part (donc de ne pas appuyer sur le bouton installer Mosquitto).
Une fois le container Mosquitto démarré et fonctionnel, il faudra peut être changer l’ip/port connection des équipements au broker mqtt.

Il est possible de restaurer les valeurs déjà présentes dans Mosquitto (retained), mais c’est une autre question/histoire et n’est pas forcément nécessaire.

Bad

OK compris, je vais faire un test.

J’ai lu dans le forum que le pilote MACVLAN networks/driver est recommandé pour une compatibilité totale avec les autres plugins, je vais aussi l’implémenter dans le container MOSQUITTO.
Merci

Ce n’est pas forcément nécessaire pour Mosquitto, mais fonctionnera bien aussi.

Bonjour,

Je suis ce sujet pour voir la suite de tes aventures :slight_smile:
J’apprendrai certainement des choses aussi.

De mon côté, je suis passé aussi en docker avec plusieurs containers pour Jeedom, mosquitto, zigbee2mqtt, zwave-js-ui.

J’ai remonté ma sauvegarde de manière classique.
Comme j’utilise aussi Watchtower (container qui met à jour les images en auto), j’ai préféré exclure Jeedom de la mise à jour automatique.
Et je gère la mise à jour de Jeedom de manière classique.

Pour rappel, les dépendances sont installées de manière temporaire et pas persistante dans le docker.
A chaque redémarrage de mon container Jeedom, je voyais certaines dépendances installées, d’autres non.
J’ai donc mis en place ce scénario que je lance à la main pour le moment.

Enfin, j’ai testé le McVLan sur un docker de test, mais je n’ai pas compris trop l’utilité, à part : avoir une IP différente de l’host.
J’ai donc mis pour le moment :

network_mode: host

Pour mettre mon grain de sel, j’ai eu ce setup là pendant quelques années :smile: je suis passé très récemment à une VM dédiée pour Jeedom (après avoir craqué pour un gros serveur qui est racké dans ma cave pour la virtualisation :angel: ) et je vais expliquer pourquoi :

  • La mise à jour des dépendances à chaque mise a jour de l’image, meme automatisé (et le scénario marche toujours bien) c’est quand même lourd mais malheureusement impossible de faire autrement.
  • La partie réseau, le container jeedom entre l’utilisation des ports et certains plugins et/ou fonctions que je soupçonne de faire du niveau 2 oblige donc un network host ou macvlan. Ca se gère mais avec des vLANS en plus ca commence a devenir un peu sportif…
  • Les mises à jour de sécurité que je peux gérer au niveau OS et de façon automatique (coucou unattended-upgrades)
  • Le fait qu’avec 128Go de RAM sur l’hyperviseur je pouvais me le permettre :wink:

Après sincèrement, bien configuré ca a marché comme un charme pendant au moins 2 ans donc c’est totalement viable. Et je n’avais pas ajouté ce gros hyperviseur j’aurais conservé le container…

Par contre j’ai conservé les containers ZWave et Zigbee qui tournent sur une VM docker dédiée à la domotique. D’ailleurs l’USB et la virtualisation c’est une tannée (j’ai rebooté la VM ce matin suite à un patch kernel et j’ai du la rebooter 3x pour que la VM et le container accèdent correctement à la clé Conbee :cry: )

Par expérience, tu fais bien :sweat_smile:

Attention cependant que l’image jeedom est basée sur l’image Debian bullseye qui elle-même vit avec des Security Updates parfois sur des CVE assez importantes. Je ne sais pas si l’équipe Jeedom suit strictement le cycle de vie de l’image bullseye mais une mise à jour régulière de l’image jeedom elle-même me semble quand même essentielle même si tu fais des mises à jour du moteur Jeedom autrement…

Si vous pensez à des évolutions sur le scénarios, dites le moi et je me mettrai dessus

Le mode macvlan permet de faire du niveau 2 sans « parasiter » l’interface réseau de l’hôte (notamment les ports ouverts, le mode promiscuous si besoin, gérer le filtrage spécifiquement sur le container, etc…)

Une introduction aux modes réseau dans les containers :

Personnellement si j’étais resté en container je serais resté en macvlan, mais j’ai dans l’idée de mettre des vLANs dans mon setup et j’ai beaucoup de containers qui tournent. Si tu n’en as que 2 ou 3 et pas de réseau compliqué le mode host fait le job effectivement.

Et au passage j’ai dans ma todolist (longue :sweat_smile: ) de créer un template Zabbix pour Jeedom basé sur la proapi. Je vous le posterai quand je me serai mis dessus

1 « J'aime »

Merci pour ce retour.
De mon côté, je n’ai pas pris un gros serveur, du coup j’économise en ressources utilisées.

Par contre, j’ai bricolé un peu crowdsec, et j’ai réussi à bloquer toute mon infrastructure d’un coup. Le VM docker qui fait tout.
Et ça, c’est moins pratique pour restaurer que ce qui est pété (la VM globale, c’est plus lourd)
Ou alors je reviens sur fail2ban avec le plugin qui existe pour suivre…

Peut-être Snort (NIDS) ou Wazuh (HIDS) ? Sinon tu mets un fail2ban pour faire la « base » et tu gères de l’alerting basé sur les logs avec Graylog (je suis en plein dans Graylog, pas encore déployé pour Jeedom)

Graylog ne prendra pas d’action automatique mais par contre tu peux isoler les logs du container lui meme (pas les logs fichiers que jeedom génère, sauf si ils partent aussi sur le stdout) avec ca dans le docker-compose.yml :

    logging:
      driver: gelf
      options:
        gelf-address: <serveur graylog>
        tag: "Jeedom"

Je note pour voir plus tard.
De mon côté, j’ai un routeur Synology qui fait IPS aussi.

Bonjour.
J’ai déjà passé le test et j’en suis très satisfaite. J’ai suivi les instructions de @Bad.

Pour l’image Jeedom/Docker j’ai suivi la documentation https://doc.jeedom.com/fr_FR/installation/docker

J’ai fait une demande au support Jeedom et … je n’ai pas eu de réponse. C’est la première fois qu’ils ne me répondent pas en deux ou trois jours. Curieux.
La question était de savoir s’il existait un docker-compose.yml plus avancé.

Pour Mosquitto/Docker j’ai aimé ce lien : https://cedalo.com/blog/mosquitto-docker-configuration-ultimate-guide/

La séquence :
1 : installer Mosquito
2 : Test Mosquitto Topic subscribe/publish
3 : Installer Jeedom
4 : restaurer la sauvegarde
5 : Redémarrer les dépendances jMQTT
6 : Configurer le Broker
7 : Test jMQTT Topic subscribe/publish

2:

5: L’option d’installation de Mosquitto a disparu.

6: (Client-Id → jeedom2)

7:

Il ne me reste plus que 34 plugins à tester hahahahahaha
Merci à tous pour vos conseils

2 « J'aime »

Hello,

Merci pour ton retour :slight_smile:

Oui, aucun sens d’installer Mosquitto dans le container, autant qu’il soit dehors, c’est plus simple à gérer.

Mon compose « maison » est ici :

Sinon tu as des choses intéressantes dans ce fil aussi :

C’est probablement ce qui a permit de créer la doc docker officielle que tu cites.

Bad

Liens très intéressants, merci encore