Jeedom sur VirtualMachine vs Docker

Bonjour,

J’utilise Jeedom sous VirtualMachine et j’avais lu que Docker était moins gourmand en ressource, un point interessant mais je decouvre …

  • qu’il faut ouvrir le port SSH pour se connecter, hors mon NAS est dans une zone exposée
  • qu’il faut se connecter en dur sur son NAS pour modifier des paramètres
  • qu’il faut installer des containers supplémentaires pour avoir accès correctement au port USB et utiliser des clés bluetooth, 4G…

Au final Docker semble au final bcp moins pratique que VirtualMachine.
Sous VirtualMachine, j’ai ma debian installer proprement, elle détecte reconnait automatiquement mes clés sans chichi, je peux prendre la main en Remote desktop (RDP) depuis mon PC Windows est avoir accès à un environement graphique pour ouvrir un terminal.
Je peux sauvegarder l’ensemble de l’environement très facilement avec un fichier .OVA que je peux reinjecter dans n’importe quel NAS ou le migrer vers VMWare (VMWorkstation ou ESXi)

Au final, j’ai le sentiment qu’il n’y a que des contraintes à utiliser Docker, quels est votre avis si vous connaissez les deux environnements ?

Merci.

Hello

Docker et VM c’est pas du tout le même objectif…

La VM c’est un OS complet … Qui a effectivement accès physiquement à tous les périphériques sans quasiment rien y faire… Tous les programmes qui fonctionnent dans la VM partagent les mêmes ressources.

Un container (docker donc) c’est fait pour faire de l’isolation. Le contenu d’un container se suffit à lui même. Il ne connait de l’extérieur que ce qu’on lui fournit (les volumes, les réseaux, les devices)…
Quand on fait bien les choses, on ne met que le strict nécessaire dans un container (que python par exemple). C’est à ce moment là qu’on gagne en ressources. Rien à voir avec un aspect performance.
De plus 2 containers ne se connaissent pas par défaut…
Par contre certaines mauvaises habitudes consistent à détourner l’usage d’un container en y mettant un OS complet (genre une debian)… Donc en plus de prendre la place pour rien (ça reviens à faire une VM dans une VM), tu es emmerdé avec l’accès aux devices puisque c’est toujours le but fonctionnement de docker.

En gros une VM = une boite d’oeufs. Les containers sont les oeufs…

2 J'aimes

Le docker utilisé moins de resource et plus simple à mettre en place
La VM est une processus complètement séparé, mais également offre plus de fonctions.

Chacun ayant son avantage et inconvénient
A voir les réponses des experts

Je peux t’assurer que VirtualMachine est bien plus simple sauf si un container Docker evitant tout ce que j’évoque existe.

1 J'aime

J’aime bien l’image.
Perso, je préfère largement la boite d’oeufs, car il ne faut pas se batte pour tout.
La solution Jeedom n’étant pas vraiment faite pour Docker de ce que j’en vois.

1 J'aime

Je suis sur Qnap, il est très simple de faire une connection à distance au nas sans ouvrir les ports, depuis l’interface tout est fonctionnel comme en local.
Il semble que l’accès à distance soit différent sur synology, mais je n’ai pas cette expérience

Effectivement faire un unique container, pour y coller, un OS, Jeedom et la base de données n’a pas vraiment de sens. C’est pas l’usage …
Par contre, faire un container pour Jeedom, qui communique avec un autre container pour la base, tout ça dans un réseau spécifique, c’est déjà plus la phylosophie (docker-compose par exemple)

2 J'aimes

VMM utilise beaucoup de ressources par rapport à Docker
Docker est moins simple à installer.

Je t’invite à regarder les tutos que j’ai fait notamment avec un réseau macvlan

Un docker jeedom macvlan (à base de débian) + Un docker dédié au BT pour faire une antenne (toujours à base d’un débian)… ça n’apporte que peu d’avantages par rapport à une VM toute seule, tu peux me PM la liste si tu veux en discuter
Avec un réseau macvlan, ça revient à faire du docker avec du NAT et à avoir accès au matériel quasi en direct. Même si ça simplifie certaines choses ça gomme quasi tout les avantages de l’isolation des containers… C’est une fois de plus un choix architecture particulier

Toujours est-il qu’un docker ça reste une couche d’abstraction DANS une VM (ou un syno)… Donc non seulement ça ne fonctionne pas tout seul, mais c’est forcement un petit peu plus lent que le processus en direct dans une VM.

Une VM qui fait tourner 10 containers python, ça prend moins de ressources que 10 VM qui font tourner 1 python chacune : ça prends moins de place disque sans aucun doute, mais pas forcement moins de CPU/mémoire
Donc dire simplement que ça utilise plus ou moins de ressources, c’est un très gros raccourci, puisque ultra dépendant de l’archi…

1 J'aime

Oui j’ai vu çà… très bien fait ton tuto au passage.
C’est en le lisant que je me suis dis que cela n’allez pas le faire, contrainte vs gain vs securité
En faite, l’empilement Synology + Docker + Jeedom + BT + 4G …est vraiment trop complexe.
Il faudrait un container qui integre tous les composant nécessaire pour résoudre le problème mais je suppose que cela n’existe pas ;(
La philosophie de docker étant d’avoir des oeufs et non boite avec uniquement les oeufs dont nous avons besoin.

La philosophie je m’en tape un peu :joy:

Essaye les deux et choisi ce qui est le mieux pour toi :wink:

Au vu des échanges, je reste sous VirtualMachine, cela n’a finalement aucun intérêt pour moi.

1 J'aime

La charge de ton CPU et ta mémoire sont à combien ?

Je suis à 32%/34% de charge CPU et à 17% de RAM.

Sous Jeedom, j’utilise une clé USB our le zwave, une clé 4G pour les notifs SMS, une clé Bluetooth

Mon NAS enregistre 5 caméras h24 7j7 dont mon interphone.
J’ai d’autres service up & running comme Moments, PhotoStation, AudioStation

J’ai utilisé les deux sous synology et clairement comme il a été dit la VMM est beaucoup plus souple et facile à mettre en place que Docker au final qui demande une certaine expertise.

Au final je reste sur VMM de syno :slight_smile:

DS216+ avec 8Go
4 Clés USB Zwave, Zigbee, RF433, Bluetooth
image

Salut tous,

y’a un truc que j’ai du pas comprendre, pour moi :

VM = réservation des ressources pour son usage
Docker/container : partage des ressources à l’utilisation.

ce qui, sur du petit matériel comme les syno, me fait pencher vers du docker pour le partage des qques coeur et ram entre toutes les applications, non?

Bonjour,

Exact.
Docker évite d’avoir un Syno de compétition pour faire une VMM

Après chacun sa croix ou son idéologie :innocent:

1 J'aime

Humm…

Si c’était si simple… Le syno c’est l’équivalent d’une VM qui fait du NFS (plus dns etc) avec le composant docker installé en plus : c’est juste que l’OS qui fait tourner un Syno, c’est pas une distribution classique comme une debian sur laquelle on aurait installé docker… Et donc tu as pas la main comme ça.

Aujourd’hui que ce soit proxmox ou esxi, les ressources ne sont pas bloquées/dédiées/reservées à une VM : physiquement ton CPU peut avoir N coeurs mais si tu fais la somme des X coeurs virtuels de tes VM X>N ne pose pas de souci. Le temps cpu est distribué en fonction.
Et les mécanismes de ballonning pour la mémoire permettent aussi d’attribuer plus temporairement à une VM si les ressources physiques ne sont pas exploitées au moment de la demande. Ce qui impose donc d’aller piocher dans la reserve des voisins.
Et les VM peuvent faire du swap sur leurs propres disques également (c’est pas le cas du docker).
Dans tous les cas quand les demandes sont supérieures à la capacité réelle de traitement, bien ça rame ou ça patiente

L’avantage que je vois au Syno, c’est que coté utilisateur, il y a presque rien à faire. Coté VM c’est autre chose.

2 J'aimes

Et je compléte ma réponse du dessus.

Coté docker, il y a aussi la capacité à mettre des limites CPU/mémoire sur un container. Dans la pratique c’est assez rare…

1 J'aime