Je suis en train de faire évoluer mon serveur qui était jusque là dédié à HA et maintenant je souhaite avoir d’autres utilisation (VM et Containers Docker).
Je suis donc en train de regarder du côté de PROXMOX qui me semble parfait.
J’ai besoin de vos retour d’expérience (et de vos expériences réseau) pour débuter sous PROXMOX « correctement ».
J’ai plusieurs questions :
Je comptais faire une VM avec HAOS (aujourd’hui j’utilise HA container sur mon Rpi4). Y’a-t-il un avantage quelconque à passer sur HAOS ? Quelle alternative sinon ? (je voudrais avec une VM dédié HA (HAOS ou avec docker container…)
Je pensais dédier une VM à tous mes containers Docker.
J’ai vu beaucoup d’utilisateurs du forum avoir des containers ou VM alors que les add-on HA existent (adguard, Wireguard, nginx, influxdb…). Pourquoi ?
Haos est tout intégré donc facile quand on ne connaît pas où qu’on ne maîtrise pas assez linux. Le problème c’est souvent de pouvoir contourner une erreur pour la corriger. On est dépendant de l’installation ha et de la version alpine qui n’offre pas tous les binaires d’une distribution classique.
Par ailleurs version haos et supervised offrent l’accès aux addons. J’y trouve personnellement un certain confort.
Ensuite concernant les container, j’ aurait quand même tendance à faire un découpage entre plusieurs vm qui font du container et pas une unique grosse qui prends tout… Même si les container sont isolés de base (à condition d’avoir des stacks différentes), faire un découpage vm apporte plus de souplesse dans le sizing, le backup, le suivi, les mises à jour etc
même s’il existe tout un tas de scripts pour faciliter l’install en docker de HA et de pas mal de modules
voir :
personnellement je préfère passer par HAOS, docker and Co c’est pas mon métier, si tu te sens capable, pourquoi pas
mais là, l’intégration a du sens a mon avis.
j’ai qu’un seul container dans lequel j’ai un docker pour frigate et a chaque mise a jour de celui ci c’est mode panique … vive les sauvegardes de Proxmox…
La première question à se poser, à mon avis, c’est « quel est mon niveau de connaissance actuel en linux » ?
Si sur une échelle de 0 à 10, tu te donnes moins de 7, alors les trucs tout faits, HA OS et les scripts de tteck déjà mentionnés, c’est parfait.
Si malgré tout, tu veux apprendre (et donc ça va être long et pas forcément simple), les chemins de traverses avec debian, installation de docker à la main, HA Container, c’est intéressant.
@golfvert: Oui je commence à m’y connaitre un peu. Docker je commence à m’y habituer. J’utilise déjà HA Supervised sur mon Rpi4: rien à dire.
En fait, je pensais que HAOS était plus rapide et/ou plus fiable d’où le fait d’y passer. Si ce n’est pas forcément le cas, je vais rester sur une VM avec HA supervised.
Par contre, tout les addons sur HA (Wireguard, Adguard…), faut-il les conserver en Addon de HA ou avoir des docker indépendants ? Je n’ai rencontré aucun soucis avec les add-ons et je les trouve souvent simple de configuration.
Faire ça, ce n’est pas connaitre docker
Docker est totalement masqué comme dans HA OS.
Ni l’un ni l’autre.
Je n’ai jamais accroché à HA supervised.
Il y a, à nouveau, avis perso, deux cas:
Je ne veux pas m’embêter, je ne connais pas linux, je n’ai pas envie d’installer debian alors, je prends HA OS.
Je me débrouille en linux (je sais installer debian) alors HA Container (voir virtual env) permet de garder le contrôle.
Supervised qui suppose à la fois d’installer debian mais après de passer à un truc « clé en main » HA supervised ou l’on n’a pas de contrôle, je n’accroche pas.
Certes, ça permet d’avoir les add-on. Mais, tous (ou la plupart) des add-on existent en container hors HA. Donc, les installer, ce n’est pas plus difficile que d’installer debian. En tout cas, je trouve.
J’ai enfin, une réticence à mettre sur HA des trucs qui n’ont rien à voir avec la domotique (ad guard, wireguard, niginx,…) sur la machine domotique dépendant de la machine domotique. Intellectuellement, ça me choque. Mais, chacun fait comme il veut
Ok pour Docker, ce n’est pas là où je voulais en venir: je voulais parler de la fiabilité de cette version. Je ne suis pas un pro de Docker (ni informaticien) mais je commence à bien comprendre l’architecture des Dockerfile (j’utilise Streamlit un peu comme un serveur que j’interroge pour certains calculs récurrents que je suis amené à utiliser au quotidien).
J’ai envie de cloisonner les add-ons, c’est la raison pour laquelle je pose ces questions. Je considère aussi que séparer les choses est une bonne chose. Je ne vois simplement pas comment le lien se réalise entre les add-ons et HA (je lis actuellement pas mal de posts pour en apprendre un peu plus).
Si les « add-on » sont installés comme des containers docker indépendants (donc pas des « add-on »!), le lien entre HA et les containers suivent diverses méthodes.
Pour zigbee2mqtt, ça ne change (presque) rien.
Pour NodeRed, que j’utilise, le lien est très simple faire. Entrer une adresse IP et un token.
Pour d’autres, ça ne change rien du tout. Il faut simplement éditer le fichier de config à la main, hors HA.
En plus de la gestion/monitoring/sauvegarde, je souhaite profiter de proxmox pour centraliser la protection. Typiquement, je voudrais que mon Nginx / Adguard / Wiregard soient au-dessus des autres VM. Je me documente sur CrowdSec.
A aujourd’hui, tout existe ce qui est sur ce schéma existe sauf Frigate. Je pense aussi intégrer un serveur mail.
C’est une option
Frigate marche mieux dans lxc que dans une VM. Je n’ai pas cherché pourquoi. Mais, une instance frigate dans un container docker sur lxc me donne des bien meilleures perf (sur le même hard) que frigate dans un container sur une VM.
« Au dessus » n’existe pas vraiment. Si ton nuc a une seule interface réseau et à moins de vouloir beaucoup se compliquer la vie, tout le monde sur le même subnet IP c’est quand même largement plus simple.
Avec deux interfaces Ethernet, tu peux mettre un firewall comme opnsense en VM (même si d’un point de vue sécurité ce n’est pas parfait), qui protège ton réseau, te permet de faire un vpn (wireguard ou autre),…
Hello
Pourquoi ne pas utiliser directement un docker par application sous Linux ?
Quel avantage de mettre une VM entre Linux et les dockers ?
Pas les sauvegardes en tous cas car les répertoires dockers se sauvegardent très facilement
ATTENTION, je ne suis pas un gourou de l’informatique, ou des réseaux et encore moins de Proxmox ou Docker
Pour aller droit au but, je te conseillerais de garder HAOS SUpervised sur une VM à part pour te faciliter la mise en place et l’évolution rapide de ta domotique.
Si’ la mise en place de service sur docker ne pose pas de problème et qu’il y a un intérêt alors externalises les mais si trop compliqués, tu te laisses la possibilité de commencer à t’ amuser rapidement et quasi plug an play.
Pour ma part, j’ai HAOS dans une VM Proxmox et tous les conteneurs docker dans une autre VM.
HAOS en VM, pour bénéficier rapidement du supervised, si besoin d’installer un add-on rapidement sans configuration, qui sert seulement home Assistant (par exemple l’addon pour mon boitier Argon quand je l’avais encore ou encore celui pour ma balance connectée avant que je la passe à ESPHome).
VM Debian + Docker : Pour Mosquitto, Z2MQTT, Wiregard, Swag, etc etc.
VM Debian + Docker : Pour ESPHome et mes tests, car ESPhome nécessite le reboot de la VM lorsque je branche un nouveau device USB (Pour injecter le Firmware dans mes ESP, la première fois).
Une VM pour mon NAS OMV.
Je pense modifier un peu mon réseau pour approfondir les VLans avec.
Une VM pour HAOS,
Une VM pour les containeurs liés à la domotique,
Une VM pour le réseau (Adguard, Swag etc)
Mais ce n’est pas pour tout de suite
Avis personnel
Je n’arrive pas à comprendre l’intérêt d’avoir une VM par conteneur ou type de conteneur.
La réponse souvent donnée est l’isolation/ la séparation pour plus de sécurité. Mais j’ai l’impression que celle-ci peut se faire via des réseaux sous docker.
Une VM par containeur, cela veut dire de gérer un OS par conteneur et donc ses mises à jour, exposer les ports de ses dockers s’ils doivent communiquer avec une autre VM etc etc.
Je dois louper quelques choses, car tout le monde a l’air de faire comme ca.
C’est une autre méthode de sauvegarde. Et tu peux par exemple faire de la haute disponibilité avec les VM dans un cluster proxmox, au lieu le faire avec du swarm sous docker.
Et le fait de répartir les container dans des VM permets de ne déplacer (et donc interrompre) que les services impactés.
Dans l’absolu, oui il faut isoler les containers avec un network dédié à la stack (comprendre un groupe containers qui offrent un service global, par exemple apache et tomcat d’un coté, nginx et php de l’autre) que tu veux gérer… Par contre ça n’empêche pas qu’au sain d’une même VM, tous les containers ‹ piochent › dans les éléments de ladite VM. Et donc, si un container a une faille qui permet de devenir root hors du container… Alors tous les containers hébergés par la VM sont potentiellement compromis.
Donc la bonne pratique c’est pas de faire une séparation par VM OU par stack, mais par VM ET par stack.
J’entends déjà dire : « Ouais mais dans un container, c’est déjà assez sécurisé »… C’est presque vrai : Avec un container c’est HYPER facile de faire une image, d’y coller un service hyper sympa que tout le monde déploie et d’ajouter un petit bout d’appli qui n’a rien à y foutre…Sauf à ne prendre QUE des images officielles sur dockerhub, à regarder les sources du container, on prends un risque.
De plus la gestion de la mise à jour de l’os est plus simple avec des containers qu’avec des applications installées en direct. Puisqu’on ‹ virtualise › dans l’image, le fait d’avoir une debian 10, 11 ou 12 n’a qu’un impact limité du moment que docker fonctionne.
Exact. Malgré tout, quand le découpage est là, c’est facile d’utiliser la fonction quand on en a besoin (ou de pas l’utiliser).
Par contre quand il faut tout refaire … c’est vite un frein
si on garde l’analogie domotique, ça revient à tirer des neutres dans les inter : c’est pas indispensable mais quand ils y sont c’est vachement plus simple
