Bonjour,
je suis en train de tester plusieurs solutions pour gérer les containers sur mon server.
J'ai besoin de faire tourner des containers compatibles dockers car ils sont souvent fournis par les dev, , des VM, et si possible des containers linux
J'ai pour le moment testé docker sur debian, et la distribution proxmox (VM et LXC). Il me reste à tester podman, cockpit, LXD, CRI-O (sur debien bien évidement)
Le choix est vaste, je suis un peu perdu. Avez vous de l'expérience en gestion de containers-VM ? Que me conseillez vous ?
Choix d'un gestionaire de container
-
piratebab
- Site Admin
- Messages : 5851
- Inscription : 24 avr. 2016, 18:41
- Localisation : sud ouest
- Status : En ligne
Et j'ai oublié le peit dernier, Incus, qui est en train de monter en popilarité suite à l'arret du support de LXD par canonical.
https://linuxcontainers.org/incus/
Avouez qu'il y a de quoi étre perdu!
https://linuxcontainers.org/incus/
Avouez qu'il y a de quoi étre perdu!
-
piratebab
- Site Admin
- Messages : 5851
- Inscription : 24 avr. 2016, 18:41
- Localisation : sud ouest
- Status : En ligne
Prochains tests:
debian 12 incus (paquets debian backport), et incus-ui (dépot zabbly https://github.com/zabbly/incus/blob/daily/README.md)
Je pourrais ainsi gérer les containers LXC et les VM.
Pour les mivroservices, je vais installer postman et portainer dans un container LXC (je ne sais pas encore trop sur quelle base, probablement debian par facilité)
si vous avez des remarques, je suis preneur.
debian 12 incus (paquets debian backport), et incus-ui (dépot zabbly https://github.com/zabbly/incus/blob/daily/README.md)
Je pourrais ainsi gérer les containers LXC et les VM.
Pour les mivroservices, je vais installer postman et portainer dans un container LXC (je ne sais pas encore trop sur quelle base, probablement debian par facilité)
si vous avez des remarques, je suis preneur.
-
piratebab
- Site Admin
- Messages : 5851
- Inscription : 24 avr. 2016, 18:41
- Localisation : sud ouest
- Status : En ligne
Pas beaucoup de réponse à mes interrogations ...Je continue à décrire mes avancées sur le sujet car il y a pas mal de lecteurs :)
J'ai installé une debian 12, puis incueset incus-ui via les dépôts zabbly.
L'interface graphique ressemble fortement à celle de proxmox pour gérer les containers et VM. Il n'y a pas la partie gestion de la debian, il faut le faire classiquement via ssh.
Le petit +, c'est l'utilisation de profils pour lancer les containers. On peux utiliser différents profils pour plusieurs familles de containers ou VM.
Le plus grosse différence concerne la configuration du réseaux par défaut.
Avec proxmox on a un bridge simple. Chaque invité partage une adresse sur le resau de l'interface de l’hôte (mon LAN)
Avec incus, il y a un routeur virtuel qui crée un réseau spécifique pour les invités. Les invités ont accès au lan et internet, mais pour y accéder via le LAN, il faut créer une route spécifique car la plage d'adresse est différente
Je préfère la config type proxmox, plus adaptés à mon cas. Je regarde ce soir pour changer la config par défaut d'incus. (incus et proxmox proposent tout les 2 plusieurs options pour le bridge, c'est juste l'option par défaut qui est différente)
Ce qui m'a fait choisir incus plutôt que promox, c'est que la debian d'incus reconnaît bien les 4 interfaces réseau, alors qu'avec promox, j'avais un problème de firmware. Vu que ça fonctionne maintenant , je ne cherche pas plus loin.
En première conclusion, si on maîtrise debian, on peux prendre incus plutôt que proxmox, on se retrouve à gérer une debian des plus classique. (PROXMOX fait visiblement des ajustements sur la debian sous-jacente).
J'ai installé une debian 12, puis incueset incus-ui via les dépôts zabbly.
L'interface graphique ressemble fortement à celle de proxmox pour gérer les containers et VM. Il n'y a pas la partie gestion de la debian, il faut le faire classiquement via ssh.
Le petit +, c'est l'utilisation de profils pour lancer les containers. On peux utiliser différents profils pour plusieurs familles de containers ou VM.
Le plus grosse différence concerne la configuration du réseaux par défaut.
Avec proxmox on a un bridge simple. Chaque invité partage une adresse sur le resau de l'interface de l’hôte (mon LAN)
Avec incus, il y a un routeur virtuel qui crée un réseau spécifique pour les invités. Les invités ont accès au lan et internet, mais pour y accéder via le LAN, il faut créer une route spécifique car la plage d'adresse est différente
Je préfère la config type proxmox, plus adaptés à mon cas. Je regarde ce soir pour changer la config par défaut d'incus. (incus et proxmox proposent tout les 2 plusieurs options pour le bridge, c'est juste l'option par défaut qui est différente)
Ce qui m'a fait choisir incus plutôt que promox, c'est que la debian d'incus reconnaît bien les 4 interfaces réseau, alors qu'avec promox, j'avais un problème de firmware. Vu que ça fonctionne maintenant , je ne cherche pas plus loin.
En première conclusion, si on maîtrise debian, on peux prendre incus plutôt que proxmox, on se retrouve à gérer une debian des plus classique. (PROXMOX fait visiblement des ajustements sur la debian sous-jacente).
-
AVCESAR
- Messages : 3
- Inscription : 13 avr. 2025, 22:45
- Status : Hors-ligne
Bonjour,
Personnellement pour les VMs, j'irai sur une debian sans interface graphique avec juste un tiler du types i3 ou hyprland (pas encore dispo en debian stable). Un choix est a faire entre pipewire et pulseaudio si il faut gérer le son. Dans le tiler, il est possible de lancer un virt-manger et d'avoir l'audio des VMs KVM.
Pour les conteneurs j'irai sur une VM Debian minimale sans interface graphique avec uniquement les outils vraiment nécessaires. Ça permet de réduire la surface d'attaque pour la sécurité du machin.
J'utilise podman et buildah pour gérer mes conteneurs, comme ça on reste dans l'open source.
Un jenkins, scripts maison ou autres pour administrer les conteneurs ne me parait pas déconnant.
Il parait que Kubernetes est bien pour gérer ses conteneurs mais avec google dedans je me méfies. Ils ont déjà dénaturé linux avec android et rien ne les empêche de faire pareil avec Kubernetes.
Personnellement pour les VMs, j'irai sur une debian sans interface graphique avec juste un tiler du types i3 ou hyprland (pas encore dispo en debian stable). Un choix est a faire entre pipewire et pulseaudio si il faut gérer le son. Dans le tiler, il est possible de lancer un virt-manger et d'avoir l'audio des VMs KVM.
Pour les conteneurs j'irai sur une VM Debian minimale sans interface graphique avec uniquement les outils vraiment nécessaires. Ça permet de réduire la surface d'attaque pour la sécurité du machin.
J'utilise podman et buildah pour gérer mes conteneurs, comme ça on reste dans l'open source.
Un jenkins, scripts maison ou autres pour administrer les conteneurs ne me parait pas déconnant.
Il parait que Kubernetes est bien pour gérer ses conteneurs mais avec google dedans je me méfies. Ils ont déjà dénaturé linux avec android et rien ne les empêche de faire pareil avec Kubernetes.
-
piratebab
- Site Admin
- Messages : 5851
- Inscription : 24 avr. 2016, 18:41
- Localisation : sud ouest
- Status : En ligne
Je vais resté sur la config debian + incus pour lancer des containers systèmes, ça fonctionne bien.
Ensuite pour les microservices, je lance un container debian stable, et je gére les microservices avec podman et portainer.
Comme toi, je reste au maximum sur du communautaire. Je vais regarder buildah.
La prochaine grosse étape va étre du mixer de l'audio avec un ardour en microservice. Ardour se lance, mais il faut maintenant récupérer le son sur ma machine principale. Le son doit traverser 2 containers, le syeteme hote, le LAN, pour arriver sur la machine de travail.
Ensuite pour les microservices, je lance un container debian stable, et je gére les microservices avec podman et portainer.
Comme toi, je reste au maximum sur du communautaire. Je vais regarder buildah.
La prochaine grosse étape va étre du mixer de l'audio avec un ardour en microservice. Ardour se lance, mais il faut maintenant récupérer le son sur ma machine principale. Le son doit traverser 2 containers, le syeteme hote, le LAN, pour arriver sur la machine de travail.