pour les techno de conteneur il n y a pas que docker, lxc est très bien, en mode UTS par exemple ou alors, ce que je préfère c est l'utilisation de systemd-nspawn.
l avantage des conteneur type UTS, je vais prendre LXC comme support, tu te fais un template ou tu en prend 1 de base fourni par lxc, tu démarre un conteneur, et ensuite tu install tes soft dedans comme si c’était une machine réelle, ou une VM, c'est l utilisation du conteneur en temps que machine, un peu comme une VM, mais a moindre coup car si tu ne fait rien, la ram ou le cpu ne sont pas utilisées.
avantage, si tu a un soft uniquement pour une vielle version de debian, et bien tu peu upgrader la machine, mettre un conteneur de vielle debian, et mettre ton soft. les données sont persistantes.
ensuite si tu veux tester un upgrade d os, ou de version de soft, tu clone ton conteneur, puis fait ta procédure d upgrade, si ça déconne, tu trash le clone, et tu n'as rien perdu
et quand on parle de reproductibilité, c est qu il n y a pas un humain derrière qui fait des modif dans la machine, donc que cela soit docker, lxc, nspawn, cela s'inscrit dans une démarche d'industrialisation et d automatisation (pour éviter de dire devops).
perso je fait cela aussi souvent que possible, même sur les machine perso, comme ça lancer un nouveau service, c'est un conteneur, un setup/config (via puppet,ansible ou salt), que la seule variable c'est le type de service. et si un jour 1 service devient trop gros, et bien je le déplace sur une machine plus grosse
a la conf kernel recipes, on a vu un conférencier qui lançait des conteneurs sur une machine type x86 pour lancer des conteneurs arm64, l environnement du conteneur était en arm64, et l exécution de code faite par qemu-system-arm, c'est une utilisation détournée, mais plutôt sympa.
je pourrais continuer longtemps sur les bienfaits des conteneurs...donc je m arrête là :)
[^] # Re: mises à jours et docker
Posté par SauronDeMordor . En réponse au journal Les outils de l'IT pour un FabLab. Évalué à 7.
pour les techno de conteneur il n y a pas que docker, lxc est très bien, en mode UTS par exemple ou alors, ce que je préfère c est l'utilisation de systemd-nspawn.
l avantage des conteneur type UTS, je vais prendre LXC comme support, tu te fais un template ou tu en prend 1 de base fourni par lxc, tu démarre un conteneur, et ensuite tu install tes soft dedans comme si c’était une machine réelle, ou une VM, c'est l utilisation du conteneur en temps que machine, un peu comme une VM, mais a moindre coup car si tu ne fait rien, la ram ou le cpu ne sont pas utilisées.
avantage, si tu a un soft uniquement pour une vielle version de debian, et bien tu peu upgrader la machine, mettre un conteneur de vielle debian, et mettre ton soft. les données sont persistantes.
ensuite si tu veux tester un upgrade d os, ou de version de soft, tu clone ton conteneur, puis fait ta procédure d upgrade, si ça déconne, tu trash le clone, et tu n'as rien perdu
et quand on parle de reproductibilité, c est qu il n y a pas un humain derrière qui fait des modif dans la machine, donc que cela soit docker, lxc, nspawn, cela s'inscrit dans une démarche d'industrialisation et d automatisation (pour éviter de dire devops).
perso je fait cela aussi souvent que possible, même sur les machine perso, comme ça lancer un nouveau service, c'est un conteneur, un setup/config (via puppet,ansible ou salt), que la seule variable c'est le type de service. et si un jour 1 service devient trop gros, et bien je le déplace sur une machine plus grosse
a la conf kernel recipes, on a vu un conférencier qui lançait des conteneurs sur une machine type x86 pour lancer des conteneurs arm64, l environnement du conteneur était en arm64, et l exécution de code faite par qemu-system-arm, c'est une utilisation détournée, mais plutôt sympa.
je pourrais continuer longtemps sur les bienfaits des conteneurs...donc je m arrête là :)