avec un conteneur, il est possible d'avoir installé plusieurs applications dedans et de vouloir en désinstaller une seule.
Pour une VM "lourde" (avec un OS complet, juste VMisée histoire de pouvoir la migrer d'hôte par exemple), certes ; pour un conteneur (Docker notamment) il est recommandé de ne mettre qu'une appli par conteneur justement
le fait de savoir désinstaller permet de confirmer que l'on fait ce que l'on pense faire (faire ce qui était prévu et uniquement ce qui était prévu).
Déployer en prod dans des conteneurs jetables (parce que reproductibles, cf. la suite) n'empêche pas de tester en amont ce qu'on fait (tendance au reproducible build, etc).
il me semble plus satisfaisant de maîtriser ce que l'on fait que de jeter tout, mais techniquement/pratiquement/économiquement c'est un compromis sur le fait que de toute façon c'est techniquement difficile alors on va au plus simple / ça coûte moins cher de tout jeter ici « l'écologie/recyclage » on s'en fout mais si ça consomme sûrement plus en énergie / ça permet d'aller vite et c'est tout ce qui compte dans ce monde.
C'est une question de point de vue, avec un conteneur ou avec la compartimentation en groups de systemd par exemple, tu augmentes tes chances de maitriser l'arrêt de ton appli par rapport à "je regarde si j'ai un .pid, ah mince c'est un vieux pas à jour, ah qu'est-ce que j'ai fait de mes fils".
L'analogie avec le recyclage me semble fallacieuse. docker rm génère quand même moins de déchets que mettre ma voiture à la casse plutôt que la réparer.
conceptuellement je trouve étrange de se dire en gros « l'informatique est à mon service et me permet de tout faire » mais bon en fait je suis dépassé, quand j'ai un souci je jette tout. C'est une particularité de l'informatique, heureusement que tous les architectes ne détruisent pas les bâtiments à chaque fois, les mécanos les voitures, etc. C'est une exception de travailler à « ressources quasi-infinies à coût quasi-nul ».
Y a aussi que j'ai plus productif à faire que régler les contingences dont savent s'occuper des outils ? C'est même le but de l'informatique, non ?
Et encore une fois le greenwashing bof.
le fait de ne pas analyser ralentit probablement aussi la découverte de bugs. Exemple bateau : une appli crashe car tel port était déjà ouvert pour une raison non prévue. On la réinstalle, cool ça remarche. Mais on ne sait pas pourquoi et le point ne sera pas corrigé, donc ça tiendra jusqu'au prochain plantage.
Si ton appli n'est pas capable de cracher un message d'erreur "port 1234 already open" au démarrage, je vois pas bien en quoi la lancer dans une VM ou un OS bare metal va changer quoi que ce soit ???
on doit pouvoir trouver d'autres raisons, mais comme on n'est déjà plus vendredi, je vais retourner faire des scripts d'automatisation ansible pour les conteneurs et machines virtuelles de LinuxFr.org...
[^] # Re: Non.
Posté par Sufflope (site web personnel) . En réponse au journal Il faut sauver le soldat Firefox!. Évalué à 4.
Pour une VM "lourde" (avec un OS complet, juste VMisée histoire de pouvoir la migrer d'hôte par exemple), certes ; pour un conteneur (Docker notamment) il est recommandé de ne mettre qu'une appli par conteneur justement
Déployer en prod dans des conteneurs jetables (parce que reproductibles, cf. la suite) n'empêche pas de tester en amont ce qu'on fait (tendance au reproducible build, etc).
C'est une question de point de vue, avec un conteneur ou avec la compartimentation en groups de systemd par exemple, tu augmentes tes chances de maitriser l'arrêt de ton appli par rapport à "je regarde si j'ai un .pid, ah mince c'est un vieux pas à jour, ah qu'est-ce que j'ai fait de mes fils".
L'analogie avec le recyclage me semble fallacieuse. docker rm génère quand même moins de déchets que mettre ma voiture à la casse plutôt que la réparer.
Y a aussi que j'ai plus productif à faire que régler les contingences dont savent s'occuper des outils ? C'est même le but de l'informatique, non ?
Et encore une fois le greenwashing bof.
Si ton appli n'est pas capable de cracher un message d'erreur "port 1234 already open" au démarrage, je vois pas bien en quoi la lancer dans une VM ou un OS bare metal va changer quoi que ce soit ???
Bah voilà on est d'accord.