Proxmox VE 7.0 est un hyperviseur permettant de créer et gérer des machines virtuelles. Il propose également une interface de gestion de conteneurs LXC pour installer des distributions en quelques clics, ainsi que des outils clé en main comme EtherPad, Ghost ou WordPress.
Ces dernières années, la virtualisation pure et dure s'est vu opposer une nouvelle façon de gérer plusieurs systèmes au sein d'un même machine à travers les conteneurs. La différence d'approche est simple.
Dans le premier cas, l'hôte dispose d'un hyperviseur lui permettant de partager les ressources matérielles entre des machines virtuelles qui agiront comme autant de systèmes indépendants, chacun disposant de son OS avec sa propre couche logicielle. Dans le cas des conteneurs, l'OS du système hôte sert de base de travail, partageant son noyau. On y déploie simplement des couches logicielles différentes :
L'intérêt est que l'on préserve un certain niveau d'isolation entre elles avec une flexibilité d'usage (on peut déployer et détruire facilement un conteneur), sans subir le « coût » de la virtualisation complète d'une machine avec son OS. Notamment pour ce qui est de l'espace de stockage occupé ou la « lourdeur » de l'hyperviseur.
On a cependant une plus grande dépendance au système de l'hôte. Ainsi, n'espérez pas utiliser une application Windows dans un conteneur Linux et inversement. C'est pour cela que Docker passe par le sous-système Linux (WSL) v2 de Windows 10/11 pour fonctionner : il dispose de son propre noyau Linux.
Ce dernier fournit nativement des fonctions dédiées à l'isolation, comme les espaces de nom pour les processus et les cgroups pour l'accès aux ressources matérielles. Cette solution n'a rien de nouveau dans l'écosystème Unix. On pouvait isoler des processus depuis chroot dès le début des années 80. BSD a renforcé cette possibilité à travers ses Jails 20 ans plus tard. Sous Linux, on pense à des outils récents comme Docker (2013), mais il n'était au départ qu'une extension des LinuX Containers (LXC) introduits en 2008, un projet désormais maintenu par Canonical (Ubuntu).
Comme nous l'avons vu dans notre introduction à Proxmox VE 7.0, ce dernier dispose d'une interface graphique permettant de gérer de tels conteneurs. Voici comment en tirer parti en pratique.
Notre dossier sur Promox VE 7.0 :
- Proxmox VE 7.0 : installation sur un serveur et création d'une machine virtuelle
- Linux Containers (LXC) dans Proxmox VE 7.0 : installez simplement des distributions et services
Récupération des templates
Nous partirons du principe que vous disposez d'un serveur à jour fonctionnant sous Proxmox VE 7.0. Connectez-vous et rendez-vous dans l'un de vos espaces de stockage dans le menu de gauche. Vous verrez plusieurs onglets apparaître, cliquez sur celui nommé CT Templates.
Comme leur nom l'indique, il s'agit de modèles permettant de créer différents types de conteneurs. Ici, plusieurs choix s'offrent à vous : en uploader un depuis votre machine, depuis une URL ou utiliser l'un de ceux proposés par Proxmox. Nous opterons pour ce dernier en cliquant sur Templates afin d'afficher la liste :
Comme on peut le voir, ils sont rangés en trois sections. Tout d'abord Mail pour installer la Mail Gateway de Proxmox. Puis System qui fournit des modèles pour une vingtaine de distributions Linux, d'Alpine à Ubuntu en passant par ArchLinux, CentOS, Debian, Devuan, Fedora, Gentoo ou OpenSUSE, toutes en plusieurs versions.
Enfin, on a droit à une centaine de services issus du hub de Turnkey Linux, dont Drupal, Etherpad, GitLab, GNU Social, Ghost, Matomo, MediaWiki, NextCloud, Nginx, OwnCloud, OSCommerce, PostgreSQL, Wireguard ou Wordpress. Sélectionnez celui de votre choix et cliquez sur Download. Nous utiliserons Debian 11 et EtherPad.
Notez que la gestion peut aussi se faire en lignes de commandes, par exemple pour afficher la liste :
pveam available
pveam available --section system
Ou même télécharger un template dans l'espace de stockage de votre choix (local-btrfs dans notre cas) :
pveam download local-btrfs debian-10-turnkey-etherpad_16.1-1_amd64.tar.gz
Vous pouvez ensuite créer un conteneur de la sorte, la liste complète des commandes se trouve ici.
Création du conteneur
Nous continuerons via l'interface graphique. Elle propose un chemin similaire à la création d'une machine virtuelle, mais avec des choix allégés. On sélectionne la quantité de cœurs CPU, de mémoire, de Go de stockage, mais pas la manière dont ils sont interfacés. Pareil pour le réseau où les choix se limitent à des éléments comme le DHCP et le DNS.
Autre différence notable, la nécessité de choisir pendant la première étape un nom (hostname) et une méthode de protection de l'accès au système du conteneur, mot de passe ou clé publique (OpenSSH). La raison est simple : une fois le conteneur créé, il n'y a pas de phase d'installation à gérer. Comme une instance cloud, tout est automatiquement configuré et fonctionnel en quelques secondes, on peut s'y connecter via la Console ou SSH.
À l'instar d'une machine virtuelle, on dispose d'un onglet Summary qui indique le statut des « composants », on peut modifier l'attribution des ressources ou les paramètres réseau, certaines options, les permissions d'accès, gérer la réplication ou la sauvegarde, créer des instantanés. La liste est simplement plus courte.
Utiliser des conteneurs LXC plutôt que des machines virtuelles permet ainsi d'économiser du temps et des ressources, au prix d'une flexibilité moindre. Vous devrez donc choisir au cas par cas, selon vos besoins.
Accès web et espace utilisé
Si vous créez un second conteneur pour Etherpad, le service sera accessible dès la fin de la procédure via une interface web, à l'adresse correspondant au nom donné à la machine :
https://hostname
Pensez tout de même à vous y connecter en SSH ou via la Console pour la mettre à jour et répondre à quelques questions pour configurer des paramètres de base.
Pour les deux conteneurs, le système installé est réduit. Debian 11 utilisait 732 Mo de l'espace de stockage attribué, contre 1,8 Go dans le cas d'Etherpad. En passant par l'installation complète de Debian 11 dans une machine virtuelle, l'espace occupé par le système (sans interface graphique) est de 1,1 Go.
Les templates occupent, eux, respectivement 233 Mo et 447 Mo d'espace, bien moins que la plupart des images ISO (hors netinstall). C'est aussi pour cela que les conteneurs Alpine Linux sont très appréciés, son template LXC nécessite à peine 2,5 Mo. Après création du conteneur, l'espace occupé par le système est de... 8,8 Mo.
Commentaires (32)
#1
Il est également possible de compléter la collection de conteneurs proposés par proxmox avec ceux générés par linuxcontainer:
#2
Je ne me souviens plus, est-ce que vous avez déjà présenté Proxmox ? Je veux dire, quels sont les cas d’usage et le public visé par cette solution. Ca a l’air puissant, bien propre en tous cas ^_^.
Pour le geek ou le dev qui veut une ou deux VM pour tester des distros ou se monter une VM de dev (très utile quand ton poste du boulot est sous Windows ou macOS), VirtualBox ou VMware Player suffisent (ou éventuellement du Vagrant pour distribuer une devbox au bureau), mais j’imagine que Proxmox cible un tout autre marché. En dehors des
grands maladesméga power users qui ont 5 PC, 2 NAS 5 baies et un LDAP chez eux pour le fun, bien évidemmentThx !
#3
PS : je pense à ça car en entreprise, si l’on a besoin de VMs pour nos projets, c’est plutôt du IaaS que l’on va chercher, avec des technos très différentes. J’ai du mal à voir quelles genres de boites ont du Proxmox.
J’ai connu quelques boites (par ex des grands groupes FR) où les postes de dev étaient tous virtualisés pour être très sécurisés et contrôlés, mais ce n’était pas du Proxmox.
#4
Tout le monde ne veux pas nécessairement placer ses billes dans du SaaS, ou du IaaS. Parfois, la loi intime l’ordre explicite de conserver les données durant 30 ans, et le métier exige une maîtrise verticale sur le logiciel métier, avec des impératifs de disponibilité 24⁄365.
Alors, certaines sociétés vont porter les infrastructures logicielles depuis ses serveurs bare métal vers des VM, avec de la haute disponibilité, des sauvegardes automatiques et du PRA.
Et oui.
Et dans ce cas, la dépendance à des licences propriétaires n’est pas nécessairement vue d’un bon oeil. La non ignorance de la sécurité et des performances de kvm font le reste.
Proxmox a été abordé a de très nombreuses reprises par la rédaction d’Inpact Hardware, qui s’est efforcé d’en exposer les atouts et limites dans une démarche journalistique remarquable.
#5
Toutes les boites ne font pas le choix du cloud public, les outils comme Proxmox permettant d’avoir un certain niveau de souplesse tout en ayant la main sur ce que tu déploies et la manière de faire. Et aussi une certaine maîtrise des coûts. Après ça dépend beaucoup du profil de l’entreprise et les solutions peuvent être complémentaires. Pour l’usage général de l’outil, regarde l’article évoqué en lien dans celui-ci.
#6
Sorry, j’aurais du être plus précis : dans les IaaS (et SaaS etc), il y en a plein on-premise, installé et managé par l’entreprise. Le cloud public n’est biensûr pas envisageable dans plein de contextes.
#7
On a du Proxmox chez nous :) (et du VMware aussi)
Un cluster de 6 serveurs avec Ceph et PBS pour le backup, ça marche plutôt très bien, et je dirais même en toute absence d’objectivité que c’est largement mieux que Vsphere
Cloud interdit de notre côté, OIV inside :)
#8
Salut,
J’ai du Vsphere au boulot, je voulais tester Proxmox :)
Ton avis m’intéresse, pourrais tu détailler ce qui te fait préférer Promox stp?
#9
Ahah j’avais un brouillon sur mon blog pour présenter les containers LXC dans Proxmox car justement c’est une alternative peu connue et très puissante dans cet hyperviseur.
Pas fan des images turnkey qui sont parfois très en retard sur les versions et dont les install sont pas toujours optimales (de mémoire nextcloud c’était bof).
Beau travail de synthèse en tout cas !
#10
ah donc j’ai migré mon Prox vers une infra docker (ce qui a causé la mort de ma CM et 1 mois de vide) parce que j’en avais marre de devoir faire mes CT pour apprendre juste après que Linuxserver fait aussi du Proxmox.
Je reste cool.
#11
Salut, alors pour résumer vite fait:
#12
Question avant que je me lance dans la mise en oeuvre. Pour un serveur perso devant héberger une instance Nextcloud, un serveur JITSI, un reverse proxy et 2 ou 3 autres “services” que conseillez vous entre TrueNAS et ses jails et Proxmox et ses containers LXC ?
#13
Tout dépend si tu te sens plus à l’aise avec FreeBSD ou Linux je dirais, les outils sont aussi différents dans leur approche : TrueNAS est un OS qui vise principalement les besoins de stockage, Proxmox plutôt un hyperviseur. On peut utiliser les deux de la même manière, mais ça change pas mal de choses.
#14
J’aurais une préférence pour Proxmox. TrueNAS est très doué pour gérer des fichiers mais, bien qu’il en offre l’option, est moins destiné à l’exécution de services directement dessus. Tu auras une gestion beaucoup plus fine et un contrôle plus précis de tes services sous Proxmox. Après si tu es joueur tu peux tenter de faire une VM TrueNAS sur ton Proxmox et de lui donner un accès direct aux DD.
#15
Par contre il y a un point à savoir impérativement à mon avis avant de se lancer corps et âmes dans Proxmox. Si l’article évite de comparer LXC avec Docker et des VM (à raison, il s’agit à mon avis d’un entre deux, un container à la docker mais géré à la manière d’une VM) il y a un point sur lequel la comparaison peut faire mal : le partage de fichiers entre CT/machines.
En effet les paramétrages de base d’un container LXC empêche d’accéder à un partage SMB/NFS pour des raisons de sécurité. Il faut alors paramétrer spécifiquement les containers ayant besoins d’accéder à ces ressources soit en élevant les droits (containers privilégiés) ou soit en montant le partage sur l’hôte puis en faisant des points de montages sur les CT, d’une manière beaucoup moins claire et simple que Docker.
C’est à mon sens le principal défaut de LXC. Tout les problèmes que j’ai eu avec se résument à ce sujet .
#16
J’ai un Proxmox sur un serveur OVH qui héberge diverses machines pour mes outils perso (Blog, Nextcloud, TTRSS, Gitea, outils de CI pour piloter tout ça, etc). Simple à administrer et ça marche du tonnerre. Avec Terraform derrière pour faire pop toutes les VM et un peu d’indus Ansible, c’est reconstructible à la volée. (testé et approuvé quand le précédent serveur est littéralement parti dans le Cloud Strasbourgeois
)
La seule complexité est de mettre en oeuvre la table de routage et les règles au niveau de la patte réseau avec les VM pour rediriger le trafic dessus.
Je n’utilise pas ses containers LXC, ayant plutôt préféré une paire de VMs avec Podman.
Pour la partie backup, j’utilise le service Object Storage d’OVH Public Cloud en envoyant les données chiffrées via rclone sur un datacenter différent. Le coût le l’offre est à la limite du négligeable, il me revient à moins de 3€/mois pour environ 180GB de données.
#17
@SebGF J’ai à peu près la même conf, mais chez Scaleway. Je suis curieux de voir ce que donne tes scripts Ansible/conf Terraform, ils sont open source? :)
#18
Je n’avais pas prévu de les rendre disponibles publiquement, mais je peux voir pour déclarer un remote sur Github et m’assurer avant qu’ils sont partageables (au cas où j’aurais commit un truc qu’il faut pas par inadvertance
).
Pour Terraform, c’est clairement la première fois que j’y touchais donc c’est basique, mais ça fait le taff. J’avais fait un article de blog sur comment j’ai procédé avec Proxmox, je pourrai te le partager en message privé si tu veux.
#19
@SebGF oui je veux bien :) (Je suis dispo sur twitter aussi sous l’username wget42). Mon install Proxmox sur Scaleway dispose du full disk encryption avec custom initramfs pour le déverouillage distant. Du coup étant donné que mon install est assez longue, je rechercherais à réautomatiser tout ça :)
#20
Merci à tous les 3 pour vos retours. Comme a priori, les services n’auront pas besoin d’accéder aux mêmes données, je vais peut-être changer mon fusil d’épaule et installer Proxmox à la place de TrueNAS.
Pour le routage entre les différents services, il faut “juste” mettre en place un reverse proxy, non ?
#21
Personnellement j’utilisais du NAT entre l’hôte Proxmox et les CT pour ouvrir les ports et ensuite un reverse proxy pour les services Web. Marchait au poil.
#22
Oui, le reverse proxy peut servir pour les demandes externes et internes.
Dans mon cas, j’ai du mal m’y prendre sur la conf de la patte réseau car le NAT ne fonctionne pas en sortie (ex : Jenkins veut attaquer Gitea, il sort et c’est la Debian Proxmox qui répond, et elle dit Lapin compris). Donc en astuce simple et efficace (et un poil cradounette mais pas eu envie de me prendre le chou), j’ai mis les URL dans le /etc/hosts des VMs pour qu’elles se joignent avec les IP internes plutôt que l’externe.
#23
Merci pour ces précisions.
Je n’ai plus qu’à rebrancher mon HP Microserver Gen8 et trouver les bons tutos.
#24
Copieur !!!!
Mon auto hébergement home-made + NAS était aussi sur cette machine. Il fait encore office de NAS, tout le reste étant parti chez OVH. Une bonne bécanne n’empêche, super silencieux et assez performant.
#25
Ah cool.
Pourrais-je me permettre de te contacter par message si je me retrouve bloqué ?
Bon il faudrait déjà que je règle le problème de mon accès au forum car je n’ai plus (l’ai je eu un jour ?) mon mot de passe et la procédure de récupération de mot de passe merdoie, je ne reçois pas le message sur mon adresse email.
#26
Pour ma part j’ai une OPNsense au cul de la Freebox (en mode bridge), et c’est elle qui ensuite me sert de routeur.
Elle s’occupe aussi de Let’s Encrypt et du Reverse Proxy.
J’ai un DNS override qui pointe mon domaine vers l’OPNsense ( mondomaine.tld >> OPNsense).
Et j’ai un domaine local (pour contacter les machine en direct local.mondomaine.tld).
Et mon hyperviseur est Proxmox, je fais tourner Nextcloud dans une VM et Collabora, Gitea dans des LXC (Perso je préfère LXC à Docker).
J’ai un peu galérer pour la configuration de tout ça mais une fois configurer ça dépote.
Pour le backup j’ai une VM Proxmox Backup Server sur mon Synology.
#27
Je n’avais pas Proxmox dessus, c’est une Debian qui hébergeait directement les services (et maintenant ne fait plus que serveur NFS). Donc je ne serai d’aucune aide malheureusement pour l’installation de la distrib Proxmox en elle-même, surtout que dans mon cas elle a été faite par l’hébergeur (choix de l’OS dans l’interface d’admin du dédié).
Pour la patte réseau, voici ce que j’avais trouvé pour pouvoir faire un NAT entre les VM et le Proxmox. En toute transparence, je n’ai pas la prétention de pouvoir expliquer à chaud tous les paramètres, ce n’est pas le genre de chose que je fais tous les 4 matins
Dans cet exemple, 192.168.10.100 est la VM reverse proxy. En gros ça lui balance tout le trafic 80⁄443 en utilisant vmbr0 comme pont vers la carte physique. Il faut attribuer vmbr1 aux VMs comme carte réseau. A noter qu’il n’y a pas de DHCP, j’ai attribué les IP via Terraform.
Edit : bordel, le bloc code markdown marche pô.
#28
C’est intéressant tous vos commentaires.
J’ajoute ma pierre à l’édifice.
J’ai 2 serveurs, 1 NAS DIY à la maison (fibre 10G) et 1 chez Hetzner (external backup + autre ;) ).
Mon NAS DIY est un peu vieux (2013) mais a subit quelques mis à jour (RAM + CPU) et fait touner Proxmox comme un charme (OMV tourne dans une VM avec les disques montés dedans).
Pour la partie hébergée, je vois que vous êtes nombreux à faire du NAT et autre pour transmettre les flux à un VM “routeur/fw”.
Pourquoi ne pas prendre une seconde IP ?
#29
Merci beaucoup, tes arguments m’ont encouragé à tester.
#30
Oué, intéressant ces commentaires. J’ai appris qu’on pouvait faire du reverse proxy avec opnsense… J’ai pas du tout regardé du côté UTM virtuel.
Y’en aurait d’autres avec GUI qui tournerait sur base debian ? BSD je suis pas un grand connaisseur.
#31
Vaut voir ipfire?
#32
Merci pour l’info.
Bon j’ai regardé, la partie reverse proxy c’est nginx qu’on pilote en ssh. Beaucoup d’alternative payante d’après AlernativeTo… Mais bon pourquoi pas, je compte utiliser Fortiweb au boulot alors… je suis pas a 1k€ près
mais c’est pour les petit client qu’il faut que je trouve un truc décent.