Jeedom sur VirtualMachine vs Docker

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

2 « J'aime »

bonjour
qu’elle clé 4G utilisez vous ? pour des sms ?
merci

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.

Je vous tiens au courant d’ici la fin de l’année.

Bonsoir

Ne pas faire la migration DSM7
Il y a des problèmes avec Docker

Ah ! Oki merci

Ça concerne les périphériques USB ?
J’ai déjà la màj V4 à faire !
Des retours sur ce fameux bouton « Mettre à niveau V4 » depuis la V3 en docker ?

Il n’y a aucun problème à mettre Jeedom en V4 à partir du centre de mise à jour de Jeedom.

Hello @ Didier3L,

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)

Tu peux commencer à regarder ici

Des tests concluant :sunglasses:

1 « J'aime »

Merci, cela m’a bien décoincé!

Que l’on soit en baremetal; en Docker ou en VM, l’exposition des services doit se faire de façon contrôlée.

Pour cela, une Application Gateway est la solution : Load-balacing, exposition des services, contrôle de sécurité L7 et TLS,etc… On, peux par exemple utiliser un HA Proxy ou Traefik.

A ce titre, il n’y a pas plus de complexité à exposer du container au sens large (lxc, docker, etc) que des VMs. Il n’y a pas à configurer les VMs; mais la gateway.
Le VMs sont pas uniquement interesssantes pour les entreprises. On peux s’en servir en laboratoire, avec des services dédiés, gérer les points de défaillances (en HA), etc.
Pour les backups, il suffit simplement de bien les configurer, en fonction des besoins; le tout en se servant de templates. L’important n’est pas forcément d’avoir le système prêt à repartir, mais c’est d’avoir un plan de reprise adapté à ses contraintes :
Exemple pour jeedom : Jeedom à sa propre sauvegarde; pas besoin de sauvegarder la dernière version de la VM de jeedom. Mais avoir un template que l’on démarre avec une installation propre, et remettra le backup de jeedom peux suffire par exemple. Accompagné d’un terraform, ca passe comme une lettre à la poste (quand il y a pas de grève !!)

Avec un proxmox, il y a un plugin HA Proxy par exemple, qui permet d’exposer les services. Pour ma part, je préfère Traefik; dans un docker swarm ; mais utilisable sur kube (K0S; K3S; K8S).
Avec Traefik, j’expose mes services swarms, mes VMs;, mais aussi toutes les routes TCP/UDP internes ou externe (LDAP; REDIS, MQ, Metriques, etc); avec une gestion centralisé de la sécurité.

Pour des applications monolithiques comme Jeedom, les conteneurs ne sont pas les plus adaptés, même si cela fonctionne très bien. Je l’ai fait durant des années (ET SANS UTILISER Mac-Vlan pour information). Mais a force; le temps de démarrage (avec installation des librairies etc;) m’a usé. Et NON ! Conserver l’ensemble du système de fichier (librairie comprise) n’est pas une bonne pratique lorsque l’on parle de conteneur. Ce n’est pas l’objectif. En effet, un conteneur est un consommable. Il peux être détruit et remonté à la volée. Or, avec la multiplication des plugins de Jeedom, et leur dépendances; les limites sont rapidement atteintes. On peux envisager un entrypoint pour faire l’installation des dépendances au redémarrage du conteneur pour les librairies, etc…

Comme le dis @pifou, Docker n’aime pas avoir plusieurs processus en même temps, et c’est là aussi une mauvaise pratique. Or Jeedom à une multitude de processus qui tourne.

Pour les informations comme le Zwave et autres protocoles, il existe plein de conteneurs pour déporter les services (Zwavejs
mqtt par exemple) en relation avec MQTT.
Pour le BLEA, un Raspi Zero en antenne fonctionne à merveille (et ca peut facilement se placer dans les cloisons derrière une plaque électrique pour une mode « invisible ».

Conclusion : Dans tous les cas, Jeedom fonctionne bien que ce soit dans un « Box », une VM ou du conteneur (même si j’ai pas tester en LXC :D). Mais Jeedom reste une application monolithique et donc certaines technos sont plus adaptées que d’autres.

Après; chacun ses affinités :slight_smile:

2 « J'aime »

Tu as très bien résumé la situation et bien expliqué pourquoi jeedom ne devrait pas être installé en mode container…

1 « J'aime »

La théorie c’est bien
En pratique c’est mieux
VMM : beaucoup de ressources utilisées mais plus facile à installer
Docker : beaucoup moins de ressources utilisées mais moins facile à installer

image

Un débat éternel :wink:
Tu as aussi raison
Mais les containers sont pas trop fait pour ça a la base pour des applications monolithique comme jeedom.

2 « J'aime »

Bon Matin @Didier3L.

Pour ma part, je trouve la consommation de Jeedom relativement faible comme tu le montre sur ton graph, et voici le mien

Parlons côté pratique et non théorique :
Considérant que nous sommes sur des VCpu et de la RAM Balancée; tout ce qui n’est pas consommé par la VM n’est pas attribuée physiquement à la VM et donc la ressource reste disponible pour d’autres VM ou Conteneur (dans le cas de Proxmox par exemple).

en effet, 3% de 4 vCPU et 2,5G RAM consommés, j’avais a peu près la même chose en conteneur. J’ai mis les 2 en parallèles sous métriques pour voir les différence pendant 4 mois. (prometheus, node-exporter, cadvisor, grafana, et je me suis même fait mon propre exporter pour jeedom).
Les différences n’était pas si grosse au niveau de la RAM. et Négligeable niveau CPU

Pas besoin de macvlan par ailleurs pour les VMs.
Soit dit en passant, pas besoin de macvlan pour Jeedom non plus. Il faut garder en tête qu’un réseau macvlan est une facilité pour la communication en réplicant les interfaces physiques. Mais c’est une « hérésie » dans le monde des conteneur. La philosophie des conteneurs est justement de créer de la micro-segmentation entre les services. un réseau macvlan supprime ce concept.

Pour ne pas avoir à faire cela, et limiter le nombre de process dans le conteneur, il semble plus judicieux d’avoir un jeedom dans son monde (microsegmentation) et tous les autres processus qui nécessite du macvlan dans des environnements séparer (VM, docker; sur des raspberry pi 0, etc…)
On passe les flux réseau par une application gateway, et un middleware si nécessaire (un serveur MQ dédié dans un conteneur par exemple). C’est beaucoup plus propre.

voici un exemple avec mon installation pour te donner une idée de ce que cela peux donner.
En service externe à Jeedom, il y a Zwavejs2mqtt, Mqtt dans une docker, node-red pour d’autres protocole au besoin et plein d’autres fonctions, Le tout communique en passant pas Traefik (https, sécurisation des headers, authentification par SSO, etc…). Les antennes BLEA ne sont pas représentées, mais il y en a 4. (4 étages dans la maison !!).

Après @Didier3L, comme je le disait tout cela est une question d’affinité et de ressources. Je n’ai à aucun moment critiqué les choix, juste exposé les faits :slight_smile:

2 « J'aime »

PS : Pour des conseils en architectures, ne pas hésiter à me contacter au besoin. C’est mon boulot :slight_smile:

Merci 1000 fois merci @gyltc ça fait plaisir de lire tes posts de qualité un grand bravo ta solution fait rêver car en éclatant les services tu t’obliger a bien comprendre chaque rouage de ta solution !

Ca montre « le côté illogique » de l’image/container jeedom en l’état du fonctionnement actuel de la solution via 'plugins / package .deb L’équipe des devs. le confirme c’est donc ‹ contre leur vision › (du moins sur la version 4.1 mais les choses évoluent avec la version 4.2 ! ) Malheureusement, au 04/01/2022 ça permet de faire du tests pour les développeurs pas d’appuyer sa domotique de prod dessus.

Venir dire" regardez docker c’est mieux sur mon NAS parceque les VM ça rame", Je trouverai l’approche « un NAS avec un CPU bien souvent faiblard est-il fait pour de la virtualisation ?? » les VMs sous les Freebox c’est du POC mais faut reconnaître que ça rame sévère je suis sur que des containers docker seraient plus efficace pour justement avoir des micro services.

Dans tout les cas si vous voulez de la performance virez la virtualisation ou gestion par container et il faut faire directement l’installation ‹ en dur sur l’OS › sur un PI4 avec un SSD/ USB avec 8Go c’est suffisant si on place sur jeedom et ses plugins dessus.

Bref quand on utilise le mauvais outil pour la mauvaise raison on a rarement la bonne solution d’infrastructure même si ça fonctionne a moyen / long terme ça va casser si on ne prévient pas l’utilisateur pour choisir en âme et conscience.

Sur un Pi oui mais les VM marchent très bien et sont très performantes sur des machines plus performantes type NUC ou autre. Il y a pleins de postes sur la communauté

Of course je tourne sur du proxmox depuis 10 ans :wink:

mais quand on dit la virtualisation c’est moins performant et que docker marche mieux sur mon NAS dans ce cas j’ai envie de dire que rien ne fonctionne mieux que du ‹ direct › :wink:

Comme tu dis les besoins en perf de jeedom sauf cas extrême ne sont pas énormes surtout pour un particulier ‹ normal › avec une 20aine de capteur et quelques scénarios d’où le fait de partir sur un pi4

2 « J'aime »

Merci @PHB_fr pour tes compliments :slight_smile:

En effet, à composants informatiques égaux, les logiciels fonctionnant de façon dédiée sur le matériels en direct sera toujours plus performants. Il n’y a pas toutes les surcouches (que ce soit containerd, lxc; les couches de virtualisations; etc)

Mais toutes choses est relative. Perso j’ai un Rog 8 coeurs 32Gb DDR4 intel I7 et du ssd pour mon serveur de virtualisation. Avec 4 vCPU et 4Gb de RAM alouée pour Jeedom, ca tourne bien mieux que sur un Raspi 4, un Odroid C2 en direct. Je parle même pas d’un Synology genre DS214se :smiley:

Ca dépend des ressources à sa disposition. C’est toute la difficulté en architecture de solution :
1°) Comprendre les besoins. Le plus dur c’est comprendre ses propres besoins. Ce n’est pas si simple qu’on le crois.
2°) Comprendre les contraintes et les risques
3°) Prendre en considération les aspects de maintenabilité et dévolution à court, moyen, long terme
4°) Adapter sa solution en fonction des tous les paramètres importants.

et surtout surtout surtout; le plus important : TESTER, EVALUER, MESURER, et se remettre en question afin de s’adapter au besoin.

Pour cette raison, dans mon cas, j’ai analysé les + et le - de docker (Swarm et Kubernetes) vs VM vs Bare-metal. Et la solution qui ME convient le mieux par rapport à MES besoins, mes attentes et mes ressources c’est la VMs. Ca peux être différents pour d’autres. Il faut l’accepter

Après, comme c’est mon domaine professionnel, je vois tout cela de part ma vision et mon expérience métier.
Autre aspect intéressant que tu apportes @PHB_fr, Beaucoup de personne vont avoir une expérience accompagnée d’un biais cognitif par rapport à leur récent achat, etc. : 'Je viens d’acheter ce NAS dernier cri, j’ai tester avec Docker et c’est mieux que tout avant". A cela je dirais ceci :

Dans le monde professionnel, même sur des équipements très haut niveau pour des NAS, on ne fera JAMAIS tourner des VMs et des conteneurs dessus (Ou alors l’architecture qui a conçu cela devrait changer de boulot). Cela va avoir un impact majeur sur l’IOPS. Or ce que l’on demande à un NAS c’est d’envoyer du débit sur le stockage. On aura des serveur dédiés pour l’hébergement des services. C’est pour cela que je reste mitiger sur l’utilisation d’un NAS « ayant un OS permetttant » la contenérisation ou la virtualisation. Pour le grand public et de façon modéré, ca peux encore aller. Mais si vous avez un serveur de média (Jellyfin, Plex, Emby par exemple) cela va avoir un impact sur les transferts de flux et dégrader les performances au niveau du NAS lui même.

Je dirais donc que c’est bien pour 2/3 services n’ayant pas besoin d’avoir de grosses perf. Sinon, utilisez un serveur dédié.

Pour finir ce message voici ce que je dirais pour le personne qui se demande vers quelle solution se tourner :

  • Essayer la VM, Docker et en bare metal pendant 1 temps (2/3mois). Voyez ce qui vous conviens le mieux pour VOUS et puis foncer.

:slight_smile:

EDIT : Détail qui a son importance également.
L’une des raisons qui m’a également poussé à ce type d’architecture est également la sécurité autour de l’IOT. Les objets connectés peuvent être une faille de sécurité dans un réseau domotique. Aussi, une hackers peut facilement trouver une faille dans Amazon Echo, Google, etc. voir dans des équipements dédiés (pont domotique, etc.). Aussi, afin de sécuriser tous mes PCs persos, bureau, mes serveurs, etc. mon réseaux personnels est composé de 2 LANs et 8 VLANs dont 1 pour l’IOT. Vous l’aurez compris, tous les équipements ont leurs propres VLAN et des règles de pare-feu pour permette à la stacks domotique d’interroger les équipements, mais les équipements ne peuvent pas communiquer en direct avec la stack domotique (diode logique).
Voici un vieux schéma (pas à jour) qui montre un peu le principe pour les personnes intéressées


.

2 « J'aime »