Forum Linux.général Containers de type Docker : le statique du 21e siècle ?

Posté par (page perso) . Licence CC by-sa
9
18
août
2015

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 (page perso) . É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 (page perso) . É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 . Évalué à 1.

    Pourquoi ne pas en faire un journal ?

  • # Oui c'est exactement ça

    Posté par . É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 (page perso) . É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 (page perso) . Évalué à 3. Dernière modification le 22/08/15 à 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 à ceux qui les ont postés. Nous n'en sommes pas responsables.