Salut Edgar,
Pour te répondre simplement, tu ne peux pas avoir complètement le
beurre et l'argent du beurre...
Pour faire simple, soit tu as un environnement complètement virtualisé
pour être en phase avec la distribution cible, soit tu allèges et tu
prends des conteneurs, mais tu n'es pas complètement iso...
Honnêtement, si tu veux être carré, je te recommande le complètement
virtualisé. Cela demande un peu plus de boulot au démarrage, mais
après ça roule...
Je te conseille proxmox : c'est basé sur Debian et une fois installé
dans un cloud, c'est parfait. C'est cliquodrome (ou pas) et très
souple. Si ton labo a un serveur, il peut être installé dessus ou bien
si tu as des crédits, tu peux louer un truc (OVH en propose par
exemple).
Maintenant, les conteneurs, c'est pratique (pour de l'arrache), mais
rapidement ça coince, parce que tu vas voir qu'il y a plein de soucis
(notamment d'ouverture de ports et autres joyeusetés du même genre).
Et le conteneur, si tu veux que ce soit propre, il faut aussi le
construire, parce que récupérer une image, bof...
Pour info, il y a 2 façons de virtualiser :
- légèrement, en déplaçant le / dans une cage (c'est le principe du
conteneur) et « en gros », c'est du chroot. Tous les conteneurs sont
basés dessus (c'est un poil plus compliqué, car désormais le noyau
intervient bien un peu). C'est très léger, dans les faits, tu as juste
un répertoire de plus dans ton système (qui regroupe tout ton nouveau
système).
- totalement. Tu simules tout le système, au moins à partir du système
de fichier (on peut aussi simuler le processeur, mais alors ça devient
abominablement lent si ça tourne sur une autre archi). Il te faut un
énorme fichier dans lequel tu vas coller l'équivalent de ton disque
dur et tu vas installer ton système d'exploitation complet. L'avantage
est multiple : totalement iso avec une installation sur un système
natif (donc ta valide est totale, contrairement au chroot au le noyau
est celui de ton système par exemple). Tu as en plus plein de gadgets
aujourd'hui (gel du système à la volée, copie du système, duplication,
etc.). Ton temps d'installation est peu ou prou celui que tu aurais
en installant une machine... sauf qu'après, tu as une souplesse
infinie : tu peux dupliquer à l'infini. Le gros désavantage est la
ressource : si tu fais tourner plein de machines (en même temps), il
te faut la RAM et le nombre de CPU ad hoc (car évidemment, tu peux
partager les CPU, mais au détriment des performances). Tu ne peux
évidemment pas partager la RAM. Mais si tu lances séquentiellement tes
machines, les ressources sont faibles. En plus, si tu n'as pas besoin
de graphisme, tu peux très bien avoir peu de ressources...
Après, je n'ai pas compris dans le détail ce que tu fais. Mais tu
gères tes machines comme tu veux : tous les virtualiseurs te proposent
peu ou prou le moyen de les lancer à la main. Ensuite, quand c'est
lancé, tu te connectes aux machines comme sur un serveur.
Pour info :
libvirt : biblio (inventé par RH je crois) pour automatiser un
environnement de virtualisation (création, lancement, gestion), le
tout en ligne de commandes. Tu peux ajouter des interfaces graphiques
(parce qu'au bout d'un moment,; quand y'a des tonnes de machines,
c'est quand même plus facile). Proxmox a sa propre salade (développée
en Perl en plus !). VMWare la sienne aussi. Notez que l'entreprise a
été rachetée récemment et cela semble puer grave pour les clients (qui
ont tous acheté comme des veaux du VMWare, sans savoir ce qu'ils
faisaient, mais parce qu'il y avait une bonne boîte commerciale
derrière).
kvm : virtualiseur utilisé (c'est un module du noyau Linux). C'est une
amélioration de qemu, tordue par F. Bellard, le petit génie français.
Ça permet de court-circuiter intelligemment les I/O par exemple quand
tu écris dans ton fichier au lieu du disque. Le noyau s'appuie sur les
instructions de virtualisation des CPU pour isoler correctement les
processus (tous les procs modernes en ont). qemu virtualise tout et
est extrêmement lent. Mais l'avantage est que tu peux faire tourner
une autre archi dessus (pour le fun, parce que ça rame. Mais pour
simuler un 68k, c'est très sympa !).
Il existe d'autres virtualiseurs, comme XEN (qui était très en avance
il fut un temps). Mais kvm a l'avantage d'être livré nativement avec
le noyau Linux.
PK
Le ven. 24 mai 2024 à 16:57, Edgar Bonet <guilde@???> a écrit :
>
> Bonjour la Guilde !
>
> Je viens voir si il y en a parmi vous qui ont de l'expérience à partager
> sur l'utilisation de machines virtuelles en ligne de commande.
>
> Pour le contexte... Au boulot, je participe au développement d'un soft
> de simulation numérique[1]. Je teste régulièrement son installation et
> son fonctionnement sur Ubuntu, Debian et Rocky Linux. Pour ce faire, je
> trouve Vagrant[2] super-pratique : une fois renseigné un Vagrantfile[3],
> je peux faire par exemple:
>
> vagrant up debian_bookworm
> vagrant ssh debian_bookworm
>
> et me voilà dans une machine Debian bookworm !
>
> Le problème, c'est qu'en août dernier, Vagrant, qui était un logiciel
> libre, est passé à une licence non-libre[4]. Dans la foulée, Canonical a
> décidé de ne plus distribuer des images Vagrant d'Ubuntu[5]. Les
> développeurs Debian vont probablement faire de même[6]. Dans l'immédiat,
> cela ne m'impacte pas trop : je peux continuer à utiliser les images que
> j'ai déjà téléchargées (j'ai attrapé Ubuntu Noble avant que l'image
> disparaisse). Mais à moyen terme il faudra bien que je trouve une
> alternative.
>
> Ce que j'ai envisagé :
>
> 1. Continuer d'utiliser Vagrant avec, si nécessaire, des images
> non-officielles. Je n'aime pas trop cette idée car je n'aime pas
> être dépendant d'un logiciel non-libre, je ne pourrais pas installer
> vagrant avec apt par la suite, et il faut faire confiance aux
> développeurs de ces images. Mais c'est peut-être la solution la plus
> simple à court terme.
>
> 2. Utiliser VirtualBox. C'est ça qui tourne sous le capot de Vagrant,
> mais le clicodrome de VirtualBox est lourd et lent. Il faut se taper
> l'installation de l'OS. Il faut lancer un environnement graphique
> qui m'est inutile juste pour ouvrir un terminal. Je n'oserais pas
> lancer VirtualBox depuis une session ssh -X.
>
> 3. Utiliser des conteneurs. Ça, pour le coup, c'est super léger. Mais
> les images des distributions sont tellement dépouillées que je n'ai
> pas l'impression d'être dans la vraie distribution. Est-ce que je
> peux tester le build du logiciel dans un conteneur Ubuntu Noble et
> prétendre ensuite que ça a été testé sur Ubuntu Noble ? Et je n'aime
> pas l'idée de compiler en tant que root.
>
> 4. Libvirt / qemu / KVM. Là je n'y connais rien. J'ai l'impression que
> ce sont des briques bas niveau, mais peut-être que je me trompe...
>
> Bref, je suis un peu paumé, et je suis preneur d'idées et retours
> d'expériences. Ce que j'aimerais retrouver c'est :
>
> – un outil utilisable en ligne de commande ;
>
> – simple à configurer (c.f. le Vagrantfile) ;
>
> – simple à utiliser (c.f. « vagrant up »).
>
> Bon week-end !
>
> Edgar.
>
> [1] https://feellgood.neel.cnrs.fr
> [2] https://www.vagrantup.com
> [3] https://github.com/feellgood/FeeLLGood/blob/master/ci-tests/Vagrantfile
> [4] https://ir.hashicorp.com/news-releases/news-release-details/hashicorp-adopts-business-source-license-future-releases-its
> [5] https://documentation.ubuntu.com/public-images/en/latest/public-images-explanation/vagrant/#support
> [6] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1049999
>
--
|\ _,,,---,,_ Patrice KARATCHENTZEFF
ZZZzz /,`.-'`' -. ;-;;,_ mailto:patrice.karatchentzeff@gmail.com
|,4- ) )-,_. ,\ ( `'-'
'---''(_/--' `-'\_)
