Bonjour,
Le 13/11/20 à 23h44, Marmotte garamotte@gmail.com a écrit :
Bonsoir,
Ce n'est pas du KVM ni du Xen, mais as-tu regardé systemd-nspawn ?
Je connaissais pas, je vais regarder, mais tu n'as pas les même pbs qu'avec lxc3 : - devoir mettre du nested = 1 dans la conf du conteneur sur le host - devoir rester en legacy cgroup hierarchy - devoir définir pleins d'overrides systemd dans les conteneurs pour que les services tournent normalement (en gros faire sauter toutes les limitations systemd, du genre mettre à false PrivateDevices / PrivateTmp / ProtectControlGroups / ProtectKernelModules / ProtectSystem / …) - devoir revoir les conf apparmor
Tout ça est pénible mais va surtout à l'encontre des principes d'isolation recherchés. C'est ça qui me pousse à passer à kvm.
Ça me semble correspondre à ton besoin. Il a remplacé LXC depuis quelques temps sur mes serveurs perso, et c'est pareil en plus simple à l'usage.
Plus simple ? J'avoue avoir un doute, car ce que j'avais avec lxc2 était vraiment simplissime, mais je vais regarder ;-)
Par rapport à tes contraintes :
- Tu peux utiliser un LV par conteneur, ou un subvolume btrfs (cloner un conteneur devient juste faire un snapshot rw du subvolume et copier un fichier de conf).
J'utilise btrfs seulement sur le serveur de backup, pas en prod car j'ai eu trop de misères (ça freeze de manière imprédictible et pour une durée indéterminée après certaines manip sur les subvolumes, surtout les delete, c'est tolérable sur le backup mais pas sur la prod).
Mais dupliquer un lv reste assez simple.
- La gestion du réseau est automatique. Tu peux définir une zone dans la section "[Network]" du fichier de configuration ("Zone=public" par exemple créera un bridge nommé "vz-public" sur le host).
- C'est du conteneur, donc tout tourne sur le noyau de l'hôte, comme avec LXC.
- Il gère la règle snat pour sortir tout seul, les interfaces sont en DHCP est par défaut (mais tu peux configurer des IP fixes si tu préfères t'embêter).
C'est plutôt de devoir gérer du dhcp qui m'embête ;-)
J'ai déjà un resolver unbound par host sur le lan, ils gèrent ma zone statique (toutes les ip du lan) à partir d'une simple liste nom ip (avec un script qui déploie les modifs et reload les resolvers après chaque modif de la liste). Du coup pour créer un fichier de conf lxc j'avais juste un script qui récupère l'ip d'après le nom dans le dns et la met dans le fichier de conf.
Autres éléments :
- libnss-mymachines permet la résolution DNS des noms des conteneurs depuis l'hôte et les conteneurs.
- On peut aussi utiliser libnss-mymachines pour résoudre les noms des UID/GID des conteneurs depuis l'hôte (il lance les conteneurs en "private" par défaut, donc avec un range de UID/GID différent par conteneur).
- Pour créer un conteneur, mon process est en gros "btrfs subvolume create /var/lib/machines/container-name; debootstrap; vi /etc/systemd/nspawn/container-name.nspawn; machinectl start container-name" + la conf dans le conteneur (activation de systemd-networkd, etc.).
systemd-networkd, j'avoue que c'est le premier truc que je vire, passé pas mal d'heures à essayer d'y répliquer ce qui marchait avec /etc/network/interfaces sans succès, je suis revenu au legacy.
- La migration depuis LXC, c'était simplement déplacer le rootfs vers /var/lib/machines/container-name et créer le fichier de conf dans /etc/systemd/nspawn (qui contient principalement la "zone" pour le bridge).
- Les containers sont gérés par des units systemd (systemd-nspawn@container-name.service), donc on peut définir l'ordonnancement (After/Before/Wants/etc.) comme pour n'importe quel autre service.
Globalement, ça ne fait "que" gérer des cgroups pour isoler les ressources.
Ok, une alternative à lxc, je vais regarder ça de plus près, merci pour cette piste.