CoreOS a annoncé une version prototype de son nouveau système de conteneurs, Rocket, une alternative à Docker, suite à des désaccords sur le modèle Docker et la direction prise par le projet.
CoreOS n'est pas en accord avec l'expansion des fonctionnalités de Docker, la possibilité de lancer des serveurs cloud, le clustering ou la gestion des réseaux, et ils ont donc construit Rocket afin de se concentrer sur la composabilité, la sécurité, et la vitesse, la création d'un simple conteneur standard, tout en fixant certains des problèmes de Docker.
La décision de ne pas forker Docker est basée sur des déclarations comme quoi le modèle de processus de Docker, tout faire tourner à travers un démon central, est fondamentalement incorrect. Rocket essaie de construire les choses différemment de Docker selon plusieurs aspects :
- Composition : Les outils pour le téléchargement, l'installation et l'exécution de conteneurs doivent être indépendants et composables.
- Sécurité : L'isolation doit être pluggable, avec audit des images et gestion des identités dans l'application.
- Distribution des images : la découverte des images doit être fédérée et distribuée, avec des protocoles alternatifs pluggables tels que BitTorrent ou des systèmes de distribution privés sans un registry.
- Ouvert : Le format et l'exécution doivent être bien définis et développés par une communauté, permettant aux implémentations indépendantes des différents outils d'être cohérentes.
Rocket est un outil de ligne de commande, rkt, qui implémente la spécification App Container créée par CoreOS pour un format de conteneur portable ouvert, composé de :
- App Container image (ACI) : Signé et optionnellement chiffré en tgz avec toutes les inforamtions permettant de lancer le conteneur. L'encryption permet une distribution via BitTorrent, via un stockage objet public, ou des réseaux de miroir.
- Runtime App Container : Environnement dans lequel le conteneur devrait fonctionner, y compris les devices, les variables d'environnement, les privilèges et la définition d'une interface de service méta-données pour exposer les données à l'environnement depuis l'extérieur du conteneur.
- App Container Discovery : protocole fédéré pour trouver et télécharger des images, inspiré par la convention des URL golang pour les chemins d'importation. Les images peuvent être désignées par des noms tels que coreos.com/etcd, permettant des téléchargements sans avoir besoin d'un registre.
Les réactions à l'annonce ont immédiatement suivi. Ben Golub, PDG de Docker Inc., est en désaccord avec certains des arguments et met en cause la rhétorique et le timing de l'annonce de Rocket (la DockerCon Europe était organisée la même semaine) :
Pour l'instant, nous tenons à souligner que cela fait partie d'un processus open source sain. Nous nous félicitons de la libre concurrence des idées et des produits. [...] Alors que nous sommes en désaccord avec certains des arguments, de la rhétorique douteuse et du timing de l'annonce de Rocket, nous espérons que nous pourrons tous continuer à être guidés par ce qui est meilleur pour les utilisateurs et les développeurs.
Ben met en avant l'écosystème et la gouvernance ouverte autour de Docker, un projet avec plus de 700 collaborateurs, dont 95% ne travaillent pas pour Docker Inc., et 65 000 images Docker libres. La société voit encore l'extension multi-conteneur comme la clé des architectures dans le développement de Docker, couvrant les services d'orchestration pour le réseau, le scheduling, la composition, le clustering, etc. Ces capacités d'orchestration devraient être créées ouvertement et livrées comme des API ouvertes, et ne pas être monolithiques, permettant la création de plugins pour changer d'implémentation sans sacrifier la portabilité, de la même manière que cela est fait avec les moteurs d'exécution (libcontainer, LXC) et les systèmes de fichiers (BTRFS, device mapper, AUFS, XFS).
De la même manière, Solomon Hykes, créateur de Docker et CTO de Docker Inc., a réagi à l'annonce de Rocket, se félicitant de la concurrence des outils comme LXD, Rocket et nspawn, bien qu'il était plus critique à propos de l'annonce :
"déçu" décrit à peine ce que je ressens au sujet du comportement et du langage utilisé dans cet article et dans la campagne de presse qui l'accompagne. Si vous voulez entrer dans la compétition, faîtes-le simplement ! Discréditer les autres acteurs n'accomplit rien et va se retourner contre eux à la fin.
Solomon a également démenti les affirmations de la pression des investisseurs de changer de direction pour Docker, ou que la direction du projet soit entraînée uniquement par Docker, Inc. et il a abordé certaines des préoccupations techniques dans l'annonce de Rocket :
Le fait que Docker construit une plate-forme ne signifie pas du tout que «docker», l'outil de ligne de commande, va devenir pléthorique et monolithique. Bien au contraire ! Le thème majeur de Docker est en fait exactement le contraire : le rendre plus modulaire, et rendre plus facile à utiliser une partie sans une autre. En fait, les caractéristiques mêmes mentionnées par le blog CoreOS (gestion de la machine, le regroupement) ne seront pas incorporées dans le binaire Docker.
En revanche, Pivotal, une entreprise utilisant Docker dans leur offre PaaS Cloud Foundry, a déjà annoncé leur participation à l'effort App Container :
La spécification de CoreOS et l'approche d'ingénierie sont alignées avec nos perspectives et les besoins de gestion des processus pour l'exécution de milliers de conteneurs en production. [...] Pivotal est enthousiaste au sujet de l'élaboration de spécifications de conteneurs ouverts et leur potentiel, et invite l'industrie à revoir les spécifications CoreOS, et de s'impliquer.
Malgré l'annonce, CoreOS continuera à intégrer Docker dans leur système d'exploitation, et continuera à contribuer et être présent sur le conseil de gouvernance Docker, où Brandon Philips, co-fondateur et CTO de CoreOS, officie déjà.