Bonjour à tous !
Pour dédié mon RPi4 à HA (méthode Container), j’ai fait l’acquisition d’un NUC.
Je viens d’installer Proxmox et le découvre.
J’ai déjà créé un CT debian pour y installer Docker pour commencer à déplacer mon server de fichier.
Il me reste beaucoup de container encore et je me pose la question suivante :
Faut il installer chaque Container Docker dans la même VM/CT ? Ou bien plusieurs VM contenant un ou plusieurs containers ?
Je précise que j’ai 2 cartes ethernet et que je souhaite repartir les divers containers sur les 2 afin de maximiser la bande passante vers le nuc.
Du coup, avez vous des avis ? Retour d’expériences ?
Ps:
Je vais certainement venir poser plusieurs questions sur proxmox… 
Merci !
Hello,
Le découpage est un peu comme on préfère.
Si tu as assez de ressources moi je partirai sur une VM par type de services (donc avec potentiellement plusieurs containers)
- bdd/grafana/influxdb etc
- fichiers/nas
- mqtt ?
Quand les containers ont besoin de communiquer ensemble c’est plus facile de faire ça dans un fichier docker-compose : même VM/même network, mais isolés du reste du monde. Et comme ça les VM sont gérables individuellement : backup/snapshot etc…
Maintenant si tu faisais tout sur un unique pi jusque là, ça fonctionne aussi avec 1 grosse VM
Merci @Pulpy-Luke de ton retour.
Je partais dans ce sens (1 VM / CT par service) mais je voulais m’assurer de ne pas passer à côté d’une fonctionnalité de Proxmox (surtout dans la gestion des containers 
et/ou réseau )
Tu as raison de préciser pour la gestion réseau 
(cela fait déjà partie de la maximisation de la bande passante pour moi, avant les cartes Ethernets dédiées)
De toute façon, le fait d’être sous Docker permet de pouvoir migrer très simplement
ça c’est la solution de riche
Comme déjà évoqué une VM c’est 10/12Go pour debian… Pour 3 containers, tu bouffes le triple + 1Go/container => env 40Go et à minima 3vCPU … Bien mais on peut optimiser
Dans le cas de grafana/influxdb/chronograph (les outils qui sont tous plus ou moins liés par l’usage/la config), si tu fais 1 VM avec les 3 containers, les perfs seront identiques, tu peux modules les vCPU plus finement, niveau réseau quand les containers communiquent ensemble ça passer par le loopback (donc plus mieux !) et ça prends moins de 20go de disques
C’est à dire? Tu veux avoir 2 réseaux IP différents? 192.168.0.x et 192.168.1.x? Ca peut être source d’ennui assez vite. Ca dépend de ce que tu as comme routeur.
D’après ce que tu as dit tu as une Ethernet à 2.5Gb/s. Tu as un switch qui va bien? Si c’est limité à 1Gb/s, je ferai plutôt du bonding des deux Ethernet. Proxmox sait faire (jamais testé cependant).
Je fais un peu comme Pulpy. 1 VM où je groupe les containers « amis ». Je n’ai pas de container docker au dessus de container LXC. C’est supposé marcher. Mais, pas d’expérience.
LXC, j’ai pas tenu longtemps… mais bon ça reste équivalent sur le principe
Non je veux dédié un carte ethernet à un traffic lent car je ne souhaite pas dépasser le 5mo/s sur l’une d"elle.
Mon serveur de fichiers est utiliser par plusieurs personne et généralement pas en local, je souhaite minimiser la bande passante. Pour l’instant je le fais dans le container (à l’aide de iproute2) mais je souhaite dédié une des 2 cartes ethernet.
Mon broker mosquitto est tout seul dans son container LXC. apt-get install et c’est parti.
Idem, mon freepbx est aussi tout seul sur LXC.
Je n’ai pas empilé Docker sur LXC.
Quand j’utilise docker, je le fais via VM.
Donc, tes deux interfaces ethernet vont être toutes les deux en 192.168.1.X et 192.168.1.Y ?
Ce n’est pas vraiment une bonne idée. Le trafic entrant passera par la « bonne » interface. Le trafic sortant passera par ??? on ne sait pas.
Oui je comptais partir la dessus également, mais ne connaissant pas trop Proxmox et ayant rapidement aperçu ces LXC, je préfère prendre le REX des utilisateurs…
Je comptais partir sur une VM par type de service, mais si jamais quelqu’un me disait que sous Proxmox vaut mieux passer par turnkey blabla…
Je comprends bien… c’est rapide.
Faire du apt-get dans un container, c’est juste pas mon habitude : Si j’ai besoin de faire ça, je build une image, je la pousse dans un repository et je pull dans la VM. Clair que c’est plus long au 1er coup
Je compte créer une VM File-Server avec eth0 puis installer Iproute2 pour brider la connexion puis installer Docker & co.
Ensuite, toutes mes VM « locale » seront sur eth1.
Il me semblait que « sur le papier » on sait par où ça rentre et sort… 
Il me semble qu’il n’utilise pas Docker quand il fait ses « apt-get » mais directement le package deb disponible depuis son LXC debian…
Peut être ai je compris de travers…
C’est ça. J’installe un debian de base dans le container LXC et là, je l’utilise comme un debian « normal », d’ou apt-get.
Ca doit être faisable. Mais, l’orthodoxie TCP/IP ne recommande pas ce genre de pratique.
Les interfaces physiques différentes soit on fait du bonding, soit on fait deux subnets.
Dans ta situation, je ferai du bonding et avec tc tu peux faire du throttling de bande passante vers certaines IP.
1 « J'aime »
je vais me documenter alors
Merci pour le retour
dans ce cas, je fais toujours la limitation de la bande passante dans ma VM ? Ce qui change c’est juste l’agrégation c’est ça ?
Ou placerais tu l’utilisation de tc par ip ?
Sans avoir testé, je ferai tout au niveau de proxmox (le serveur lui-même, pas les VMs). A la base, c’est un debian avec des choses en plus.
Par défaut (config bête de base), toutes les VMs s’appuient sur un Linux Bridge vmbr0, qui lui même est bindé sur l’interface physique.
Donc, si je devais faire ça, je créerai un bonding bond0 avec eth0 et eth1 (à voir le nom de tes interfaces…) dans le bonding.
Une interface vmbr1 qui est bindé sur bond0.
Et j’appliquerai le shaping/throttling sur vmbr1. Donc, toutes les VMs seraient traitées en même temps.
1 « J'aime »
