06 décembre 2014

About Docker monolithic design

CoreOS Rocket announcement claim to fix a design / security issue within Docker. They didn't explained much, and as you can imagine this has been discussed during DockerCon.

Docker uses a one-does-all executable model, just like busybox does. Busybox is a minimalist Linux distribution design for embedded use, and as such provides a single executable to cover all common Unix commands. This significantly reduce the distribution size.

Docker did adopt the same model and provide a single "docker" command both for client and daemon - make sense as they share lot's of code to communicate on REST api. The design and security consideration comes on the fact Docker daemon runs as root. The daemon has to be root to manage Linux namespaces and cgroup and few other kernel level stuff (network, ...). From a security perspective having a root component exposed over HTTP(S) to get client commands on the network is unpleasant, and daemon does lot's of stuff that does not require to be root (downloading image layers for sample) that offer a larger surface attack. If you consider Apache httpd design (as a sample), main daemon run as root to bind port 80, but workers process run as non-root to prevent any abuse for http handlers and module possible security issues.

CoreOS point of view is SystemD should be used to manage containers, and the container manager doesn't have to be running as root and delegate to SystemD when some kernel-level container management stuff is required.

Solomon just tweeted this :

solomonstre
So who wants to help make Docker embeddable? Daemon mode would be optional if you prefer another central daemon to be in charge like systemd
06/12/2014 02:28
solomonstre
@solomonstre the difficulty is that some parts of "just run" require managing global system state, eg ip allocation. How do we do this?
06/12/2014 02:46
solomonstre
@solomonstre rocket sweeps this under the rug by putting it all in systemd. But I don't want to tie Docker to systemd, it's too monolithic
06/12/2014 02:48

That's a major point : SystemD does not enough so Docker daemon doesn't need to run as root, so can't just say "let's make Docker rely on SystemD". Also, Docker changed it's design in 0.6 to make the image persistence extensible, so you can use AUFS or device-mapper, maybe alternate Filesystem solution (ZFS for sample) will later plug into docker. Docker team doesn't want to have SystemD as unique solution. So as they use to : define a clean extension point with neutral API, provide a default implementation (current design, with docker daemon running as root) and offer extensibility so you can configure docker to run third-party implementation, maybe relying on SystemD, maybe on other solutions.


Today Docker team is organizing a Hackathon for people still at Amsterdam after DockerCon (~80 hackers have registered afaik). Not sure this will be enough to get this implemented during the week-end, but I expect this will be actively discussed and maybe some plan for a proposal.

05 décembre 2014

#DockerCon !

Cette semaine avait lieu à Amsterdam la première édition de la DockerCon Europe, faisant écho à l'événement équivalent à San Francisco où Docker.com avait annoncé (entre autre) docker 1.0.

A titre personnel, j'étais présent pour creuser la piste du "Continuous Delivery" dans un contexte Dockerizé, sujet que j'ai déjà exploré avec oki docki mais qui n'en est qu'à ses débuts. Je vais y revenir.

Une bonne partie de l'équipe Docker était présente, proposant le premier jour une formation (plus de 100 participants pris en main par la core team Docker) et ce week-end un hackathon. Entre les deux, deux journées de conférence bien remplies.

La conférence avait lieu au Nemo science center, un bâtiment en forme de bateau, on ne pouvait rêvée mieux ! Avec ~500 participants la conférence reste à taille humaine et permet énormément d'échanges. La team Docker a d'ailleurs été d'une disponibilité exceptionnelle pour discuter avec tout le monde, jusque tard dans la nuit jeudi malgré une keynote à préparer. J'ai beaucoup échangé profitant de leur présence ainsi que d'un public très varié et appris plein de choses, ce qui pour ce qui me concerne fait de la conférence un énorme succès.

Sur le contenu, j'ai été déçu par les deux sessions "continuous delivery" que j'ai suivies, l'une très creuse l'autre très théorique. Ce n'était pas ce que j'espérais, mais les échanges en dehors des confs au cours de ces deux jours ont heureusement largement compensé. De nombreux sujets ("Breakout session", "Birds of a Feather") visaient d'ailleurs avant tout à permettre de rencontrer la team Docker et découvrir les développements en cours, il s'agissait donc bien avant toute chose d'un lieu d'échange pour Docker Inc.

La conf a cependant revêtu ses habits de lumière le temps des keynotes, très bien orchestrées, annonçant des choses qui ne sont que des demi-surprises pour tout ceux qui suivent les listes docker-dev. Citons tout de même :

Docker Machine
Initialement proposé comme une commande "docker host" assez polémique, il s'agit finalement d'un outil séparé (comme quoi Docker sait écouter la communauté). Cette commande permet de provisionner des VMs prête à héberger les conteneurs Docker. On crée donc avec une ligne de commande universelle une VM qui soit aussi bien un local VirtualBox qu'une instance sur le Cloud public DigitalOcean (j'attends la version GCE !) et potentiellement sur une infra privée (VMWare, OpenStack, etc) sous réserve que le pilote soit écrit par quelqu'un. Une fois la VM créée, le client docker standard est configuré pour communiquer avec cette VM qui accueillera donc tout les conteneurs qu'on va lancer.

En résumé, imaginez une généralisation de boot2docker à n'importe quelle infra.

Docker Swarm
Anciennement "libSwarm" il s'agit d'un orchestrateur minimal pour Docker. Mimant les API du démon Docker, le client "docker run" demande à cet orchestrateur de déployer les conteneurs sur les machines disponibles. Le but n'est pas de fournir une intelligence à la Mesos ou Kubernetes, mais juste de donner de la flexibilité et une API commune. L'implémentation de base est d'ailleurs le bin packing : remplir au maximum une machine avant de passer à la suivante. C'est donc pratique en développement ou en test ou on se tamponne pas mal de savoir où le conteneur tourne. Par contre en production on passera sur une implémentation alternative plus élaborée.

Ce second point est important, résumé par "la batterie est fournie, mais remplaçable" (à l'inverse d'un MacBook) : Docker fournit un outil basé sur les API du démon docker, et donc compatible avec les outils existants et à venir, et l'implémentation de base (la batterie) fonctionne mais n'est pas bien futée. Selon les besoins et contraintes de chacun, on la remplacera au loisir par n'importe quel outil plus avancé / plus adapté / plus au fait des contraintes locales.

Docker Compose
Il s'agit ici d'une 1/2 annonce car le développement est encore en cours. Si vous connaissez fig vous ne serez pas dépaysé. La seule différence est que pour la proposition en cours la commande fait partie du client docker standard (sujet très contesté) et utilise un fichier "group.yml". Suivez #9459 pour en savoir plus et voir les arguments.

Docker Hub Enterprise
La toute première annonce de produit commercial de Docker Inc, après une offre de support et de formation/accompagnement. Il s'agit du modèle de Github, avec le service qu'on connais sur le web, gratuit pour les repos publics et payant pour les repos privés, apporté on-premises pour ceux qui n'ont pas confiance dans le Net ou qui n'ont pas un accès fibre. Il est difficile à ce stade d'estimer l'adoption possible ou les avantages concrets (il s'agit à ce jour d'une beta privée). Pour info JFrog propose déjà un service Docker dans Artifactory.

Lisez aussi http://blog.docker.com/2014/12/announcing-docker-machine-swarm-and-compose-for-orchestrating-distributed-apps/ pour les annonces détaillées.

Je trouve que les propositions Machine / Swarm / Compose, considérées séparément et discutées ouvertement avec la communauté sont un signal fort sur le fonctionnement du project open-source Docker. Son fonctionnement a été re-précisé en keynote ainsi qu'une proposition d'aménagement. Détail intéressant, les développements internes passent eux aussi par la case pull-request et le contrôle des maintainers. Si les devs Docker Inc. bénéficient d'une approbation plus rapide en moyenne (7 jours contre 9 pour un contributeur externe) il n'y a pas de sauf-conduit: chaque proposition est bien validée au niveau communautaire. On a donc affaire à un projet open-source très sain et qui fait le nécessaire pour le rester dans un contexte de succès phénoménal forcément difficile à gérer.

En résumé, des annonces et des rencontres passionnantes, et si rien d'inattendu n'a été révélé, il s'agissait d'une très belle conférence menée de main de maître.

01 décembre 2014

Docker, Rocket et tout ça

L'écosystème Docker a été secoué par l'annonce de Rocket, un runtime alternatif à Docker développé par CoreOS.

Le constat de CoreOS est que Docker ne repose pas sur des bases suffisamment sécurisées (un démon central tournant sous root) ni flexibles. Leur idée est de coller à l'esprit unix : des outils très spécialisés, faisant bien une tâche et une seule, qu'on intègre ensembles. Sauf que Docker va dans une direction un peu différente. Les évolutions proposées et développements en cours visent à doter docker de capacités d'orchestration, de provisioning, et de gestion réseau. Il s'agit de proposer des points d'extension dont docker serait le maître d'orchestre, pour contrôler N machines sur lesquelles vous déploierez X containers reliés entre eux par un réseau privé.

Là où ça clashe, c'est dans le ton utilisé par CoreOS (lisez leur blog) qui est tout de même assez dur. Salomon a d'ailleurs répondu sur twitter en expliquant la philosophie d'une part du projet docker (oss) et de la compagnie :

solomonstre
1) interface to the app and developer should be standardized, and enforced ruthlessly to prevent fragmentation #dockerway
01/12/2014 22:11
solomonstre
2) infrastructure should be pluggable and composable to the extreme via drivers & plugins #dockerway
01/12/2014 22:11
solomonstre
3) batteries included but removable. Docker should ship a default, swappable implementation good enough for the 80% case #dockerway
01/12/2014 22:11
solomonstre
4) toolkit model. Whenever it doesn't hurt the user experience, allow using one piece of the platform without the others. #dockerway
01/12/2014 22:11
solomonstre
5) Developers and Ops are equally important users. It is possible and necessary to make both happy. #dockerway
01/12/2014 22:12
solomonstre
6) If you buy into Docker as a platform, we'll support and help you. If you don't, we'll support and help you :) #dockerway
01/12/2014 22:12
solomonstre
7) Protect the integrity of the project at all cost. No design decision in the project has EVER been driven by revenue. #dockerway
01/12/2014 22:12
solomonstre
8) Docker inc. in a nutshell: provide basic infrastructure, sell services which make the project more successful, not less. #dockerway
01/12/2014 22:12

etc (suivez @solomonstre si vous voulez la totale :P)
ayant un MacBook j'aime bien le #3 :D

Bon bref, l'idée de Docker c'est de fournir un outil clé en main qui couvre les cas principaux (le fameux 80%) tout en laissant l'implémentation remplaçable via des API standardisées, pour s'adapter aux besoins de chacun.

La réponse "officielle" de docker.com n'a pas tardé non plus, même si elle ne nous avance pas beaucoup.

Bon et alors. D'une part rocket est en 0.1, aussi c'est peut être très bien fait mais euh bon voilà. D'autre part, l'idée  - plutôt bonne a priori - de définir un format standard de container, indépendant de l'implémentation du runtime, est malheureusement à ce jour uniquement implémentée par rocket. Il ne s'agit donc pas de prendre l'existant Docker, d'en "standardiser" une partie (autrement dit un standard de facto), et de proposer une implémentation différente.

Donc même si on peut prêter attention aux arguments de CoreOS ça semble être à ce jour essentiellement un FUD. Un peu comme si je vous disais que le code de Jenkins est tout pourri et que je lance le projet Jarvis, disponible on 0.0.1 sur mon github (hey, cherchez pas, c'est un exemple).

Bref, à moins que CoreOS ait du concret a dégainer rapidement ça va juste être un mauvais coup, 48h avant la DockerCon europe, genre totalement par hasard ...