Posté par jyes .
En réponse au journal L'Écosystème containeurs.
Évalué à 3.
Dernière modification le 27 février 2020 à 09:05.
En l’occurence avec LXC, tu peux faire un conteneur qui ne consomme rien en espace de stockage. Tu peux par exemple lancer ton postfix ou ton nginx installé sur ton sysème dans des conteneurs LXC. De tels conteneurs verront donc le même système de fichiers que on système, mais tourneront dans un espace de processus séparé (il ne pourront pas lister ceux qui tournent sur l’hôte), verront une interface réseau séparée (sur laquelle tu appliquer d’autres règles de parefeu que sur le système), etc, en s’appuyant sur les CGroups. Voir la commande « lxc-execute » pour ça.
Bon avec cette utilisation des conteneurs LXC, on s’éloigne déjà beaucoup du conteneur comme outil de pseudo-virtualisation. Ça pour le faire, il faut exécuter un init (plutôt que directement postfix ou nginx) dans le conteneur après lui avoir installé un système minmal complet dans un chroot. Voir la commande « lxc-start » pour ça. Tu peux aussi installer un système minimal, puis nginx et postfix dans deux conteneurs à partir d’instantanés BTRFS et/ou d’UnionFS par rapport au conteneur système minimal. Après, si tu fais tout ça à la main, c’est dommage, car c’est justement à ça que sert Docker, fabriquer des pseudo-machines virtuelles en superposant des briques réutilisables. Évidemment tout n’est pas réutilisé, ça n’a pas la granularité de ton gestionnaire de paquet qui partage la moindre bibliothèque entre tous tes logiciels, mais c’est quand-même l’objectif du truc à la base. Et une fois que c’est facile de fabriquer de telles pseudo-machines virtuelles, autant les rendre immuables et contrôler ainsi parfaitement leur contenu, et pouf, voilà le Docker moderne.
Au final, ce n’est pas étonnant si pour commencer Docker s’appuyait sur LXC, et même maintenant qu’il ne le fait plus Docker et LXC utilisent de toute façon les mêmes possibilités offertes par le noyau Linux. Tu peux refaire du Docker à la main à partir de LXC, mais si à la fin tu as refait tout Docker, autant utiliser Docker directement, ce sera beaucoup plus pratique.
Donc pour répondre à ta question :
Peut-on conteneuriser des bibliothèques par exemple déjà installées sur le système ?
Non, car ça n’a pas de sens, un conteneur contient un environnement d’exécution, donc ce n’est pas une bibliothèque qu’on conteneurise mais éventuellement les programmes qui l’utilisent. Si veux conteneuriser, à coût nul, un seul programme, LXC le permet (« lxc-execute »). Si tu veux pseudo-virtualiser tout le système, tu peux avec LXC (« lxc-start ») ou Docker. Si tu veux pseudo-virtualiser des logiciels prêts à l’emploi dans leur conteneur avec une gestion facilitée de la construction de conteneurs immuables et des outils pour administrer tout ça, passe à Docker directement, qui fait tout ça très bien.
[^] # Re: Docker...
Posté par jyes . En réponse au journal L'Écosystème containeurs. Évalué à 3. Dernière modification le 27 février 2020 à 09:05.
En l’occurence avec LXC, tu peux faire un conteneur qui ne consomme rien en espace de stockage. Tu peux par exemple lancer ton postfix ou ton nginx installé sur ton sysème dans des conteneurs LXC. De tels conteneurs verront donc le même système de fichiers que on système, mais tourneront dans un espace de processus séparé (il ne pourront pas lister ceux qui tournent sur l’hôte), verront une interface réseau séparée (sur laquelle tu appliquer d’autres règles de parefeu que sur le système), etc, en s’appuyant sur les CGroups. Voir la commande « lxc-execute » pour ça.
Bon avec cette utilisation des conteneurs LXC, on s’éloigne déjà beaucoup du conteneur comme outil de pseudo-virtualisation. Ça pour le faire, il faut exécuter un init (plutôt que directement postfix ou nginx) dans le conteneur après lui avoir installé un système minmal complet dans un chroot. Voir la commande « lxc-start » pour ça. Tu peux aussi installer un système minimal, puis nginx et postfix dans deux conteneurs à partir d’instantanés BTRFS et/ou d’UnionFS par rapport au conteneur système minimal. Après, si tu fais tout ça à la main, c’est dommage, car c’est justement à ça que sert Docker, fabriquer des pseudo-machines virtuelles en superposant des briques réutilisables. Évidemment tout n’est pas réutilisé, ça n’a pas la granularité de ton gestionnaire de paquet qui partage la moindre bibliothèque entre tous tes logiciels, mais c’est quand-même l’objectif du truc à la base. Et une fois que c’est facile de fabriquer de telles pseudo-machines virtuelles, autant les rendre immuables et contrôler ainsi parfaitement leur contenu, et pouf, voilà le Docker moderne.
Au final, ce n’est pas étonnant si pour commencer Docker s’appuyait sur LXC, et même maintenant qu’il ne le fait plus Docker et LXC utilisent de toute façon les mêmes possibilités offertes par le noyau Linux. Tu peux refaire du Docker à la main à partir de LXC, mais si à la fin tu as refait tout Docker, autant utiliser Docker directement, ce sera beaucoup plus pratique.
Donc pour répondre à ta question :
Non, car ça n’a pas de sens, un conteneur contient un environnement d’exécution, donc ce n’est pas une bibliothèque qu’on conteneurise mais éventuellement les programmes qui l’utilisent. Si veux conteneuriser, à coût nul, un seul programme, LXC le permet (« lxc-execute »). Si tu veux pseudo-virtualiser tout le système, tu peux avec LXC (« lxc-start ») ou Docker. Si tu veux pseudo-virtualiser des logiciels prêts à l’emploi dans leur conteneur avec une gestion facilitée de la construction de conteneurs immuables et des outils pour administrer tout ça, passe à Docker directement, qui fait tout ça très bien.