new Blog( perso );

Docker "machine" is a new command created by Docker team to manage docker servers you can deploy containers to. Think about boot2docker you use to run on your development workstation, but applied to all possible Cloud and on-premises hosting services.

"machine" is actually an OSX / BSD command, so conflict with your installation (#2). To prevent this I've moved it to my go/bin and declared this first in PATH.

➜ machine create -d virtualbox local
INFO[0000] Downloading boot2docker...                   
INFO[0039] Creating SSH key...                          
INFO[0039] Creating VirtualBox VM...                    
INFO[0044] Starting VirtualBox VM...                    
INFO[0044] Waiting for VM to start...                   
INFO[0075] "local" has been created and is now the active machine. Docker commands will now run against that machine. 
➜ echo $DOCKER_HOST
tcp://boot2docker:2376
➜ export DOCKER_HOST=`machine url` DOCKER_AUTH=identity
➜ echo $DOCKER_HOST
tcp://192.168.99.100:2376

➜  machine ip local
192.168.99.100
➜  machine ssh local
                        ##        .
                  ## ## ##       ==
               ## ## ## ##      ===
           /""""""""""""""""\___/ ===
      ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
           \______ o          __/
             \    \        __/
              \____\______/
 _                 _   ____     _            _
| |__   ___   ___ | |_|___ \ __| | ___   ___| | _____ _ __
| '_ \ / _ \ / _ \| __| __) / _` |/ _ \ / __| |/ / _ \ '__|
| |_) | (_) | (_) | |_ / __/ (_| | (_) | (__|   <  __/ |
|_.__/ \___/ \___/ \__|_____\__,_|\___/ \___|_|\_\___|_|
boot2docker: 1.2.0
             master : 8a06c1f - Fri Nov 28 17:03:52 UTC 2014
docker@boot2docker:~$ ls /Users/nicolas/
Applications/     Library/          bin/              
Boulot/           Movies/           
Desktop/          Music/            
Documents/        Pictures/         dotfiles/
Downloads/        Public/           go/
Dropbox/          VirtualBox VMs/   google-cloud-sdk/
docker@boot2docker:~$ exit
➜  docker ps
The authenticity of host "192.168.99.100:2376" can't be established.
Remote key ID EJF7:BPI4:GKOC:GR7H:RKZL:KH5J:LOBB:YZRU:HCWR:JYXZ:AOGH:OOEO
Are you sure you want to continue connecting (yes/no)? yes
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
➜  docker run --rm -ti ubuntu bash
Unable to find image 'ubuntu:latest' locally
ubuntu:latest: The image you are pulling has been verified
511136ea3c5a: Pull complete 
01bf15a18638: Downloading 9.731 MB/201.6 MB 20m43s
30541f8f3062: Download complete 
e1cdf371fbde: Download complete 
9bd07e480c5b: Download complete

...

So I get a classic Boot2Docker installation on machine, with /Users shared volume and all expected setup. Also get equivalent commands I use to run with boot2docker client command.

The user experience here is very comparable to boot2docker, so I don't worry you'll get quickly used with it.

Let's no switch to a Cloud provider. Google Compute Engine is not (yet) supported, so was an opportunity to give Microsoft Azure a try, as this is terra incognita for me ...

First need to subscribe - then get your subscriber ID. Authentication on Azure is based on client certificate, so need to create a cert file, that you then have to register on https://manage.windowsazure.com. As it took me some time to discover where to upload it, here is a screenshot :


test

➜  machine create  -d azure --azure-subscription-id="c33.....ec5" --azure-subscription-cert="mycert.pem" azure
INFO[0000] Creating Azure host...                       
INFO[0072] Waiting for SSH...                           
INFO[0161] Waiting for docker daemon on host to be available... 
INFO[0202] "azure" has been created and is now the active machine. Docker commands will now run against that machine. 
➜  export DOCKER_HOST=`machine url` DOCKER_AUTH=identity
➜  docker run --rm -it debian bash
FATA[0000] TLS Handshake error: tls: oversized record received with length 20527 

wtf ? This is actually a know issue. I have the same issue running docker client 1.3.2. I'm still stuck here.

Also, provisionning Azure host took a looooong time, "Waiting for SSH". I have no idea this is just me due to some misconfiguration, or something expected on Azure. I'm used with GCE to give me SSH prompt within 10 seconds... :P #troll

Anyway, the question here is not if provider A is better than B, but the option Docker Machine offer to change provider without changing the toolchain. Assuming I have a production delivery pipeline based on Docker containers, I'd be happy I can run the same both locally and provisioning Cloud instances by whatever IaaS provider.

Isn't that cool ?

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

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.