A priori, les efforts se concentrent sur l'ajout dans le noyau de patches pouvant génériquement servir aux solutions de virtualisation/conteneurs, plutôt que l'intégration de solutions complètes, pour l'instant...
... une solution complète sera probablement intégrée à terme, mais pour l'instant, comme le dit patrick_g, l'heure est à un "long travail visant à masquer toutes les ressources globales du noyau (systèmes de fichiers, identifiants des processus, interfaces réseaux etc.) derrière une couche d'abstraction afin de pouvoir gérer des conteneurs séparés".
Chacun y vient petit à petit, comme chez FreeBSD, avec la virtualisation de la pile réseau [1]
D'ailleurs, à ce titre, les développeurs de solutions de conteneurs participent à patcher le noyau petit à petit, en tout cas, chez OpenVZ [2] (j'imagine qu'ils le font aussi chez VServer), que je découvre après 6 mois de VServer, que je trouvais déjà très bien, mais qui est bien moins polyvalent au niveau réseau :
- VServer isole des interfaces de l'hôte, en les faisant discuter via le loopback, ce qui empêche de laisser le loopback grand ouvert, si on veut firewaller entre les conteneurs, et ce qui empêche aussi d'avoir un loopback dans le conteneur (on est forcé de rechercher toutes les occurences de 127.0.0.1 et de les remplacer par du localhost, qu'on a manuellement fait correspondre à l'adresse IP du conteneur... voire de forcer manuellement les services sur cette adresse)...
- OpenVZ virtualise le dialogue réseau en faisant intervenir une interface virtuelle qui permet de réaliser le routage entre les conteneurs, qui disposent donc d'un loopback à eux... a priori, ils sont chacun sur un /32 en point à point avec l'interface virtuelle, mais on peut leur donner un peu plus de capacités, pour qu'ils aient leurs propres iptables, routes, qu'on puisse les bridger avec le reste, par exemple pour mettre une sonde d'IDS en promiscuous, qu'ils puissent avoir du broadcast, et même qu'ils gèrent une interface réseau physique, sans que l'hôte n'y ait accès, voire même, qu'ils aillent jusqu'à router eux-aussi...
... sur ce point OpenVZ roxorise des famille-ours ! Dommage que le kernel binaire et l'outil de migration (enfin, ça, encore... faut avoir assez de machines, pour ça... mais c'est assez classe à voir [3]) ne soient pas directement packagés dans Debian... et que le miroir des kernels fza soit dans un composant "openvz" bizarre (et pas dans un "main"), ce qui fait qu'on ne peut pas l'inclure via debian-cd/simple-cdd...
En tout cas, si on n'a pas besoin de faire tourner plusieurs kernels, les conteneurs, c'est génial.
[^] # Re: Virtualisation?
Posté par Aefron . En réponse à la dépêche Sortie du noyau Linux 2.6.26. Évalué à 5.
... une solution complète sera probablement intégrée à terme, mais pour l'instant, comme le dit patrick_g, l'heure est à un "long travail visant à masquer toutes les ressources globales du noyau (systèmes de fichiers, identifiants des processus, interfaces réseaux etc.) derrière une couche d'abstraction afin de pouvoir gérer des conteneurs séparés".
Chacun y vient petit à petit, comme chez FreeBSD, avec la virtualisation de la pile réseau [1]
D'ailleurs, à ce titre, les développeurs de solutions de conteneurs participent à patcher le noyau petit à petit, en tout cas, chez OpenVZ [2] (j'imagine qu'ils le font aussi chez VServer), que je découvre après 6 mois de VServer, que je trouvais déjà très bien, mais qui est bien moins polyvalent au niveau réseau :
- VServer isole des interfaces de l'hôte, en les faisant discuter via le loopback, ce qui empêche de laisser le loopback grand ouvert, si on veut firewaller entre les conteneurs, et ce qui empêche aussi d'avoir un loopback dans le conteneur (on est forcé de rechercher toutes les occurences de 127.0.0.1 et de les remplacer par du localhost, qu'on a manuellement fait correspondre à l'adresse IP du conteneur... voire de forcer manuellement les services sur cette adresse)...
- OpenVZ virtualise le dialogue réseau en faisant intervenir une interface virtuelle qui permet de réaliser le routage entre les conteneurs, qui disposent donc d'un loopback à eux... a priori, ils sont chacun sur un /32 en point à point avec l'interface virtuelle, mais on peut leur donner un peu plus de capacités, pour qu'ils aient leurs propres iptables, routes, qu'on puisse les bridger avec le reste, par exemple pour mettre une sonde d'IDS en promiscuous, qu'ils puissent avoir du broadcast, et même qu'ils gèrent une interface réseau physique, sans que l'hôte n'y ait accès, voire même, qu'ils aillent jusqu'à router eux-aussi...
... sur ce point OpenVZ roxorise des famille-ours ! Dommage que le kernel binaire et l'outil de migration (enfin, ça, encore... faut avoir assez de machines, pour ça... mais c'est assez classe à voir [3]) ne soient pas directement packagés dans Debian... et que le miroir des kernels fza soit dans un composant "openvz" bizarre (et pas dans un "main"), ce qui fait qu'on ne peut pas l'inclure via debian-cd/simple-cdd...
En tout cas, si on n'a pas besoin de faire tourner plusieurs kernels, les conteneurs, c'est génial.
[1] http://imunes.tel.fer.hr/virtnet/
[2] http://community.livejournal.com/openvz/22369.html
[3] http://www.montanalinux.org/openvz-live-migration-demo.html