-
@MartialGeek @waxzce Ça dépend de quel type d’image on parle. Si tu es dans docker, donc dans le paradigme « image immuable », déjà tu n’es pas supposé le faire, mais reconstruire une image (éventuellement en partant de l’image précédente, mais Docker ne le permet pas, pas nativement en tout cas).On twitter.com
Mood -2 🙁
-
@MartialGeek @waxzce Ensuite, Docker ne te facilite pas la tâche, pas de SSH ou autre pour accéder à la machine (cause paradigme single-process & cie), du coup au mieux ça se résume à gros coup de « docker run ». Qui sera de toute façon annulé au prochain redémarrage (on repart de l’image de base).Permalink On twitter.com
Mood 0
-
@MartialGeek @waxzce Si tu parles d’images LXC ou équivalent (ie un véritable système complet et standard, quasiment indistinguable d’une machine physique standard, ce qui était l’objectif initial de la virtualisation), alors « apt update » n’est pas un souci puisqu’on est équivalent à du baremetal.Permalink On twitter.com
Mood 0
-
@MartialGeek @waxzce Et c’est ça aussi le faux argument de docker de « ça marche en dev ça marche en prod ». On n’est pas iso entre baremetal et docker (en tout cas loin de baremetal vs LXC ou virtu). Et généralement pas iso entre prod et dev non plus (docker-compose en dev, k8s en prod)Permalink On twitter.com
Mood -2 🙁
-
@MartialGeek @waxzce Un truc qui tourne en dev, il est très loin de tourner en prod. Et un truc qui est dev hors docker est aussi très loin de tourner en dev dans docker (en tout cas pas the-docker-way).Permalink On twitter.com
Mood -2 🙁
-
@MartialGeek @waxzce La notion de volume est loin d’être transparente. Certaines images refondent toute ton architecture (coucou alpine !). La journalisation n’est pas native (pas de syslog vu que single-process !). Etc.Permalink On twitter.com
❤️ 1 Favorite
Mood 0