quand tu lance un VM, tu dédie des morceau de CPU; de RAM a ta VM, ce n est pas le cas des containers, c est un avantage, mais aussi un inconvénient car si un container par en sucette, les autre font être lourdement impacté (sauf si tu met des limites en ressources)
pour les données, justement tu ne les détruits pas forcement, avec un lxc.mount.entry qui permet de partager des subtree dans un LXC.
ensuite avec lxc, tu peux lancer des container en tant que user, sans les droits root, il y a un remaping du user root dans le container (uid + 100000 par défaut), ce qui est pas mal pour tester des choses en mode quick and dirty sans pourir une machine ou installer une VM.(je pense au installation du style curl http://...../truc.sh | bash)
avec le container, cela permet aussi de lancer plein de services sur un systèmes sans que ceux ci interagissent entre eux.
pour la config, je fais un salt ou un puppet ou un ansible qui met au carré la machine, mais cela reste valable pour les containers ou les machines virtuelles ou les réelles.
des que tu a plus de 3 ou 4 machines, investir dans un setup géré par l un de ces systèmes est un gain de temps. si tu ne connais pas, ansible sera peut être le plus abordable. parfois pour gagner du temps il faut en perdre un peu.
si tu vas gérer un parc machine, je te conseil vivement d utiliser cela. car tu ne vas quand même pas aller sur chaque PC et d éditer a la main les configs, ou même faire un scp sur tous ??
[^] # Re: mises à jours et docker
Posté par SauronDeMordor . En réponse au journal Les outils de l'IT pour un FabLab. Évalué à 2.
quand tu lance un VM, tu dédie des morceau de CPU; de RAM a ta VM, ce n est pas le cas des containers, c est un avantage, mais aussi un inconvénient car si un container par en sucette, les autre font être lourdement impacté (sauf si tu met des limites en ressources)
pour les données, justement tu ne les détruits pas forcement, avec un lxc.mount.entry qui permet de partager des subtree dans un LXC.
ensuite avec lxc, tu peux lancer des container en tant que user, sans les droits root, il y a un remaping du user root dans le container (uid + 100000 par défaut), ce qui est pas mal pour tester des choses en mode quick and dirty sans pourir une machine ou installer une VM.(je pense au installation du style curl http://...../truc.sh | bash)
avec le container, cela permet aussi de lancer plein de services sur un systèmes sans que ceux ci interagissent entre eux.
pour la config, je fais un salt ou un puppet ou un ansible qui met au carré la machine, mais cela reste valable pour les containers ou les machines virtuelles ou les réelles.
des que tu a plus de 3 ou 4 machines, investir dans un setup géré par l un de ces systèmes est un gain de temps. si tu ne connais pas, ansible sera peut être le plus abordable. parfois pour gagner du temps il faut en perdre un peu.
si tu vas gérer un parc machine, je te conseil vivement d utiliser cela. car tu ne vas quand même pas aller sur chaque PC et d éditer a la main les configs, ou même faire un scp sur tous ??