En effet, le principe des conteneurs (jail BSD, OpenVZ, VServer) est d'avoir des sortes de super-chroots, qui utilisent tous le même kernel (en fait, ils n'ont pas accès à toutes les fonctions de celui-ci : par exemple, pour accéder à des périphs ou à l'interface réseau de l'hôte, il faut leur donner accès à des capacités spéciales du kernel), tout en étant isolés les uns des autres.
Après, est-ce que c'est moins consommateur d'énergie ? Je ne sais pas : peut-être un peu moins, vu que les instructions de virtualisation ne sont pas sollicitées. Mais à mon avis, l'avantage est surtout en ce que, n'ayant pas besoin de ces instructions, peu ou prou n'importe quel proc (x86 ou AMD64 - ça reste des patchs maintenus en dehors de Vanilla, même si, aussi bien pour VServer qu'OpenVZ, il y a pas mal de contribution au kernel de base, pour en venir un jour à supporter les conteneurs nativement) peut faire l'affaire, pourvu qu'il y ait assez de RAM sur la bête (en modifiant un poil le debootstrap de base, ie en n'utilisant syslog-ng au lieu de rsyslog, j'arrive à faire tourner des VM qui n'allouent pas plus de 5Mio de RAM... évidemment, ça gonfle selon les services utilisés).
Après, il y a sans doute un peu d'overhead, dû à la séparation, mais, c'est peu ou prou invisible, même sur mes vieilles machines.
Sinon, pour l'installation des softs, je me méfie comme la peste du contrôle de la VM directement à partir du shell de l'hôte (il peut y avoir des problèmes d'inaccessibilité des VT et cie... et c'est très chiant)... Par contre, une fois dans le conteneur (par SSH, par exemple, ou, sous OpenVZ, en faisant "vzctl enter ID_DE_LA_MACHINE, ce qui lance un sous-shell de l'invité sur l'hôte), pas de problème : au /dev (atrophié et statique : ce que je trouve très bien), et aux capacités du noyau près (ce qui inclue le réseau, sauf si, sous OpenVZ, on donne accès à la conf réseau en utilisant une interface virtuelle plus avancée), ça fonctionne exactement comme une machine courante. L'un de mes conteneurs est d'ailleurs un approx qui sert de cache/miroir deb local à toutes mes machines (oui, je suis très Debian) - on installe ce qu'on veut, il y a un init tout ce qu'il y a de plus classique, ... c'est transparent.
[^] # Re: Conteneurs
Posté par Aefron . En réponse au journal La virtualisation en production. Évalué à 5.
Après, est-ce que c'est moins consommateur d'énergie ? Je ne sais pas : peut-être un peu moins, vu que les instructions de virtualisation ne sont pas sollicitées. Mais à mon avis, l'avantage est surtout en ce que, n'ayant pas besoin de ces instructions, peu ou prou n'importe quel proc (x86 ou AMD64 - ça reste des patchs maintenus en dehors de Vanilla, même si, aussi bien pour VServer qu'OpenVZ, il y a pas mal de contribution au kernel de base, pour en venir un jour à supporter les conteneurs nativement) peut faire l'affaire, pourvu qu'il y ait assez de RAM sur la bête (en modifiant un poil le debootstrap de base, ie en n'utilisant syslog-ng au lieu de rsyslog, j'arrive à faire tourner des VM qui n'allouent pas plus de 5Mio de RAM... évidemment, ça gonfle selon les services utilisés).
Après, il y a sans doute un peu d'overhead, dû à la séparation, mais, c'est peu ou prou invisible, même sur mes vieilles machines.
Sinon, pour l'installation des softs, je me méfie comme la peste du contrôle de la VM directement à partir du shell de l'hôte (il peut y avoir des problèmes d'inaccessibilité des VT et cie... et c'est très chiant)... Par contre, une fois dans le conteneur (par SSH, par exemple, ou, sous OpenVZ, en faisant "vzctl enter ID_DE_LA_MACHINE, ce qui lance un sous-shell de l'invité sur l'hôte), pas de problème : au /dev (atrophié et statique : ce que je trouve très bien), et aux capacités du noyau près (ce qui inclue le réseau, sauf si, sous OpenVZ, on donne accès à la conf réseau en utilisant une interface virtuelle plus avancée), ça fonctionne exactement comme une machine courante. L'un de mes conteneurs est d'ailleurs un approx qui sert de cache/miroir deb local à toutes mes machines (oui, je suis très Debian) - on installe ce qu'on veut, il y a un init tout ce qu'il y a de plus classique, ... c'est transparent.