Rocket, ou pourquoi l'équipe de CoreOS lance une alternative à Docker

Posté par  . Édité par Nÿco, Benoît Sibaud, Nils Ratusznik et palm123. Modéré par patrick_g. Licence CC By‑SA.
Étiquettes :
29
2
déc.
2014
Virtualisation

C'est l'information qui a fait parler en ce premier décembre 2014, elle nous vient de l'équipe créatrice de CoreOS. On ne va pas vous faire l'affront de vous expliquer encore ce qu'est et n'est pas Docker, le premier lien de la liste s'en chargera très bien.

Rocket

CoreOS crée Rocket, une alternative à Docker, mais pourquoi ?

Docker

Les raisons

Elles sont multiples. D'une part la stratégie mise en place par l'équipe de Docker, sa diversification vers des univers comme le Cloud, le Clustering, Windows "?", le téléversement ainsi que le téléchargement d'images toutes prêtes… mais aussi son fonctionnement monolithique et obligatoirement en "root" et pour finir la suppression du manifeste de CoreOS pour les conteneurs ont fini par faire déborder le verre/vase/bassin de patience et de respect de ses idéaux à l'équipe de CoreOS.

Oui, mais qu'apporte Rocket par rapport à Docker ?

Modulable

Tous les outils pour le téléchargement, l'installation et l'exécution des conteneurs doivent être interconnectés, mais indépendants et modulables.

Sécuritaire

Isolé, chiffré, le conteneur doit l'être dès sa création et le rester.

La distribution d'images de conteneurs

La recherche des images de conteneurs doit être simple et normée, la récupération de ceux-ci distribuée. Bittorent semble privilégié pour l'instant.

Ouvert

Afin que la communauté puisse l'adapter à ses besoins et ses envies.

L'état des lieux

Aujourd’hui Rocket est disponible en version 0.10 sur GitHub (cf. lien plus haut). Au menu des réjouissances, on pourra noter que Rocket est un outil de ligne de commande, "rkt", qui va créer un "tgz" chiffré et signé qui comprendra toutes les informations nécessaires à la création d'un conteneur, et met en place deux normes (à compléter/modifier par les futurs utilisateurs/développeurs) : l'App Container Image et l'App Container Runtime.

L'App Container image

L'App Container image (ou Image App Container (ACI)) est une spécification pour le format d'image d'un conteneur. C'est une archive simple qui est signée et éventuellement chiffrée.

L'App Container Runtime

L'App Container Runtime définit de façon claire et rigoureuse ce que l'environnement et les installations d'une exécution de conteneurs devraient fournir par défaut. Cela inclut les appareils, variables d'environnement, et privilèges qu'un conteneur devrait atteindre et surtout ne pas dépasser. cela comprend également une définition d'une interface de service de méta-données pour exposer les données de l'environnement à partir de l'extérieur du récipient tout en gardant la problématique sécuritaire en son cœur.

L'App Container Discovery

Comme son nom l'indique, vous permettra de trouver et de télécharger le conteneur dont vous avez besoin.

Une solution et une aventure entre Docker et CoreOS Rocket à suivre de près pendant ces journées hivernales !

Aller plus loin

  • # Dépêche pas très claire...

    Posté par  (site web personnel, Mastodon) . Évalué à 10.

    Je m'intéresse particulièrement à Docker en ce moment, j'ai l'impression qu'il y a un gros enjeu à ce fork mais j'avoue que je ne comprends pas à travers cette dépêche quels sont les tenants et les aboutissants de ce fork.

    #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo

    • [^] # Re: Dépêche pas très claire...

      Posté par  . Évalué à -8.

      il faut lire pour ça : "Oui, mais qu'apporte Rocket par rapport à Docker ?" ce sont les différences principales

      http://lsm2013.out.airtime.pro:8000/lsm2013.ogg Ecoutez Radio RMLL !

      • [^] # Re: Dépêche pas très claire...

        Posté par  . Évalué à 10.

        Quel est le lien entre Docker et CoreOS ? Quelles sont les raisons "politiques" derrière le fork ?

        D'une part la stratégie mise en place par l'équipe de Docker, sa diversification vers des univers comme le Cloud, le Clustering, Windows "?", le téléversement ainsi que le téléchargement d'images toutes prêtes…

        Quels sont les problèmes posés par ces éléments ? A priori, d'un point de vue très extérieur, je n'y vois que des avantages.

        pour finir la suppression du manifeste de CoreOS pour les conteneurs ont fini par faire déborder le verre/vase/bassin de patience et de respect de ses idéaux à l'équipe de CoreOS

        Est-il possible d'avoir un résumé de ce manifeste, des raisons de sa suppression ?

        En gros, j'ai l'impression qu'il y a plein de non-dit dans la dépêche, ça me donne l'impression de passer à côté du sujet.

      • [^] # Re: Dépêche pas très claire...

        Posté par  (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 02 décembre 2014 à 10:46.

        J'ai lu cette partie, et je n'ai pas compris clairement ce qu'apporte Rocket à Docker :

        Modulable

        Tous les outils pour le téléchargement, l'installation et l'exécution des conteneurs doivent être interconnectés, mais indépendants et modulables.

        Est-ce que Rocket fait ça ? Est-ce que Docker ne le fait pas du tout ? Est-ce un cahier des charges ? Pourquoi a-t-on besoin que ces caractéristiques ?

        Sécuritaire

        Isolé, chiffré, le conteneur doit l'être dès sa création et le rester.

        Isolé c'est pas le cas de Docker ? pourquoi un conteneur doit être chiffré ? Si tu es dans une infrastructure d'entreprise, tu n'as pas besoin de chiffrer les conteneurs.

        La distribution d'images de conteneurs

        La recherche des images de conteneurs doit être simple et normée, la récupération de ceux-ci distribuée. Bittorent semble privilégié pour l'instant.

        La recherche des images de conteneurs Docker est simple, non ? Normée par rapport au nom des images ? Est-ce que la distribution est vraiment nécessaire ?

        Docker, en entreprise, tu vas l'utiliser très probablement avec un dépôt local dédié à l'entreprise, pas en mettant des agents sur toutes les machines.

        Ouvert

        Afin que la communauté puisse l'adapter à ses besoins et ses envies.

        Docker n'est pas ouvert ?

        #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo

        • [^] # Re: Dépêche pas très claire...

          Posté par  . Évalué à 6.

          Est-ce que Rocket fait ça ? Est-ce que Docker ne le fait pas du tout ? Est-ce un cahier des charges ? Pourquoi a-t-on besoin que ces caractéristiques ?

          Au départ Docker était assez simple, mais maintenant il est en train de se transformer en un outil qui fait tout.

          Par exemple ils parlent d'ajouter la gestion/deploiement de machines distantes:
          https://github.com/docker/docker/issues/8681

          Avec ce que propose coreos on pourrait par exemple ne prendre que la partie execution d'un conteneur, et gérer autrement le telechargement des images.

          Ca veut pas dire que la facon dont fonctionne Docker n'a pas d'interet. Mais la ils expliquent pourquoi ils ont décidé de créer un projet different.

          Isolé c'est pas le cas de Docker ? pourquoi un conteneur doit être chiffré ? Si tu es dans une infrastructure d'entreprise, tu n'as pas besoin de chiffrer les conteneurs.

          Tout le monde n'est pas dans une infrastructure d'entreprise. Et puis meme dans ce cas, en quoi est ce qu'il n'y aurait pas besoin de chiffrer ?

          La recherche des images de conteneurs Docker est simple, non ? Normée par rapport au nom des images ? Est-ce que la distribution est vraiment nécessaire ?

          La récupération distribuée c'est sans doute pour eviter de consommer trop de bande passante chez celui qui heberge. Ca permet d'éviter de dépendre d'une societé comme Docker pour heberger ses images.

          Docker, en entreprise, tu vas l'utiliser très probablement avec un dépôt local dédié à l'entreprise, pas en mettant des agents sur toutes les machines.

          Pour info, il existe aussi des gens qui font des trucs et qui ne sont pas "en entreprise". Et puis il existe tout types d'entreprises. C'est pas par ce que c'est pas utile dans ton cas que ca ne sert à rien.

          • [^] # Re: Dépêche pas très claire...

            Posté par  . Évalué à 5.

            Tout le monde n'est pas dans une infrastructure d'entreprise. Et puis meme dans ce cas, en quoi est ce qu'il n'y aurait pas besoin de chiffrer ?

            Je ne suis pas persuadé de comprendre l'intérêt du chiffrement pour la confidentialité ici :
            - soit tu n'as pas confiance dans l'infrastructure de déploiement, le chiffrement ne te protégera pas contre une lecture bourrine de la mémoire depuis l'extérieur du contenu. Mémoire dans laquelle il y a peu près tout ce que tu cherches à protéger.
            - soit tu as confiance (ou tu considères que le risque est maîtrisé), mais de toute façon ton chiffrement de conteneur ne te protège pas des intrusions par le réseau (ici c'est un gros risque). Une fois à l'intérieur du conteneur le chiffrement est transparent, donc on peut tout récupérer sans même se rendre compte que c'est chiffré sur disque.

            En fait, le conteneur chiffré ne te protège que d'une seule chose, le vol de l'information, machine (ou conteneur) arrêtée.

            • [^] # Re: Dépêche pas très claire...

              Posté par  (site web personnel) . Évalué à 4.

              Soit tu espères une avancée prodigieuse dans le domaine du chiffrement homomorphe qui permettrait de garder le tout chiffré même pour les admins de la plateforme considérée, mais la question qui arrive alors doit être le coût total en énergie (cela valait-il le coup de chiffrer A et B en local, de l'envoyer sur le serveur de calcul, de lui faire calculer A+B en chiffré, de récupérer le résultat et de le déchiffrer, par rapport à faire le calcul A+B en local en clair).

            • [^] # Re: Dépêche pas très claire...

              Posté par  . Évalué à 6.

              En fait, le conteneur chiffré ne te protège que d'une seule chose, le vol de l'information, machine (ou conteneur) arrêtée.

              Oui je suis d'accord. Je pensais à un chiffrement des images sur le serveur de stockage des images (dans lequel on a pas forcement confiance) et pas sur la machine qui fait tourner les conteneurs.

              Mais en lisant l'annonce originale, ils ne parlent pas de chiffrement, ils disent "the crypto primitives for strong trust, image auditing and application identity should exist from day one". Donc plutot la signature et verification de l'intégrité des images (ce qui manque actuellement à Docker).

        • [^] # Re: Dépêche pas très claire...

          Posté par  . Évalué à 7.

          Si tu es dans une infrastructure d'entreprise, tu n'as pas besoin de chiffrer les conteneurs.

          Vu le nombre d'infrastructure d'entreprise qui se repose (tout ou en partie) sur des hébergements externes, je ne serais pas aussi catégorique.

          « 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: Dépêche pas très claire...

      Posté par  . Évalué à 9.

      Déjà, je pense que rocket n'est pas un fork de Docker (et que donc il faut corriger la dépêche) mais un projet concurrent car ils pensent que Docker a de gros défauts non vraiment corrigeables. Je conseille de lire le dernier lien donné pour en savoir plus, qui est une annonce du projet…

  • # Catégorie Cuisine ?

    Posté par  (site web personnel) . Évalué à 7.

    Vous êtes sûr que c’est de la cuisine ?

  • # Comment ça root ?

    Posté par  (site web personnel) . Évalué à 2.

    mais aussi son fonctionnement monolithique et obligatoirement en "root"

    Bha je viens de tester rocket, et il me demande aussi d'être en root…

    Alors qu'avec docker, mon user est dans le groupe "docker" et je n'ai pas besoin d'être root… J'ai pas compris la remarque donc.

    • [^] # Re: Comment ça root ?

      Posté par  . Évalué à 10.

      Docker nécessite un daemon qui tourne en root, avec lequel on communique par une API (et le groupe "docker" permet de se connecter au socket qui permet d'utiliser cette API). Le daemon fait certains trucs qui nécessitent d'etre root, mais aussi d'autres ou ca n'est pas nécessaire.

      Avec rocket, l'outil qui démarre un container a aussi besoin des droits root, mais ca pourrait etre un binaire suid qui ne fait que ca, sans avoir un daemon complet qui tourne en root.

    • [^] # Re: Comment ça root ?

      Posté par  (site web personnel) . Évalué à 8.

      En sachant au passage que si tu es dans le groupe docker, c'est comme si tu était root ( tu lance un container avec un mount bindé d'un repertoire, tu modifie les permissions pour mettre un +s, hop, tu es root)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.