Bonjour,
Docker est partout, de plus en plus présent. Mais voilà, pourquoi j'ai l'impression que c'est un peu comme compiler avec des bibliothèques en statique, mais avec quelques trucs en plus liés aux containers (ressources limitables, etc.) ?
Certaines personnes parlent même du futur de la distributions de paquets par containers…
Mais je trouve ça pas super, surtout que les mises-à-jour de sécurité d'une bibliothèque implique de reconstruire toutes les images dockers !
Pourquoi tout le monde trouve ça si bien ? Je passe à côté de quelque chose ?
# Statique, en pire ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
D'après un article que j'ai lu récemment, c'est pire encore. Un conteneur Docker conçu comme c'est censé, c'est un système d'exploitation plus ou moins minimal, avec un logiciel particulier qui est, avec ses fils éventuels, le seul à être démarré.
Par conséquent, toutes les subtilités introduites par les administrateurs et autres développeurs de distributions, tels que cron ou logrotate, ne tournent pas. Or ces trucs ont bien été introduits pour une raison…
[^] # Re: Statique, en pire ?
Posté par claudex . Évalué à 3.
Logrotate n'a aucun sens dans un container docker qui est fait pour avoir une courte durée de vie. Il faut exporter tes logs ailleurs (par exemple dans un autre container qui les stock hors du container et avoir, par exemple, un troisième qui fait la rotation des logs).
Pour ton cron, il peut tourner dans un container dédié.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Journal
Posté par max22 . Évalué à 1.
Pourquoi ne pas en faire un journal ?
[^] # Re: Journal
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Pour rester dans les technologies hype : pourquoi ne pas en faire une entrée journald ?
[^] # Re: Journal
Posté par Jiehong (site web personnel) . Évalué à 2.
Ce n'est qu'une question, et je vais sûrement me faire jeter pour un journal(d) ;)
# Oui c'est exactement ça
Posté par romain11 . Évalué à 2.
De ce que je comprends, les "gros" (genre Google, cf source) règlent ce problème en recyclant rapidement les containers :
http://www.theregister.co.uk/2014/05/23/google_containerization_two_billion/
C'est sur qu'on peut se demander si une telle solution est applicable pour des plus petites structures…
# Readonly
Posté par claudex . Évalué à 3.
L'intérêt, c'est d'avoir un système qui se construit facilement, et donc tu ajoute facilement des instances en prod pour répartir la charge. De plus, ce que tu test en preprod, tu es sûr de le retrouver en prod, ça évite les surprises.
Perso, je ne suis pas super convaincu, surtout que les surprises, ça arrive plus avec les données en prod pour des cas non testés que parce qu'une lib n'était pas dans la bonne version.
Après, ça introduit des concepts intéressant comme un système readonly, et donc pas moyen qu'un attaquant viennent uploader ses scripts pourris. Le recyclage rapide des containers évite aussi qu'un attaquant puisse passer trop de temps sur une machine.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Readonly
Posté par flan (site web personnel) . Évalué à 3. Dernière modification le 22 août 2015 à 19:50.
J'ai l'impression que ça complique quand même pas mal le cycle de vie pour avoir quelque chose à jour. Il faut reconstruire le conteneur, puis l'envoyer sur le miroir, puis le redéployer partout. Ça fait également un miroir supplémentaire à mettre en place.
Je n'ai jamais utilisé Docker, c'est peut-être pour ça que je suis aussi sceptique, mais je n'ai pas l'impression qu'on y gagne beaucoup par rapport à des technos comme Puppet (sauf quand on a un environnement de prod super hétérogène et qu'on ne maîtrise pas totalement).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.