18 octobre 2014

Upgrade to Docker 1.3.0

Après une chouette journée passé à bdx.io (je laisse le soin à d'autres de vous faire un résumé, parce que je suis  une grosse faignasse), retour à Rennes avec 6h de transport en TGV.

Pendant que Laurent bricole son nouveau jouet je récupère l'installer de Docker 1.3.0 tout juste publié (merci la 4G en gare de Bordeaux).

Parmi les nouveautés de Docker 1.3.0, la sécurisation de la communication entre un client et le démon docker est un point majeur. 

Jusqu'ici, pour parler à un démon distant on avait une simple interface HTTP, sans aucune sécurisation pas même un login/password. Pratique sur un poste de développement mais un peu léger pour vos serveurs de production :P

Docker 1.3.0 corrige ce défaut en utilisant une authentification par certificat client sur SSL.


Au passage, le port par défaut du démon docker change en 2376 (jusqu'ici 2375). Si vous installez cette version pensez donc à mettre à jour votre .bash_profile avec les variables d'environnement :

DOCKER_HOST=tcp://boot2docker:2376
DOCKER_TLS_VERIFY=1
FORWARD_DOCKER_PORTS=1
DOCKER_CERT_PATH=/Users/nicolas/.boot2docker/certs/boot2docker-vm

boot2docker up vous l'indique également, mais si vous êtes comme moi vous ne faites pas trop attention à ce genre de message :-\

J'ai ensuite voulu faire mumuse avec l'API client, sans passer par le client docker natif. 

J'ai rapidement renoncé à mettre à niveau docker-java car je n'y connais rien en jersey ni à sa configuration avancée pour assurer ce type d'authentification sur https (et sans Net entre Bordeaux et Paris c'est pas facile à deviner)

La documentation officielle suggère une commande curl utilisant les clés générées automatiquement pour nous par l'installateur boot2docker. Et là "oups". 

➜ ~ curl --insecure --cert ~/.boot2docker/certs/boot2docker-vm/cert.pem --key ~/.boot2docker/certs/boot2docker-vm/key.pem https://boot2docker:2376/images/json
curl: (35) Unknown SSL protocol error in connection to boot2docker:-9825

Comme la version OSX de curl est ancienne est un peu customisée à la sauce Apple, j'ai aussi essayé avec la version homebrew ... qui ne marche pas non plus mais par pour la même raison !

➜ ~ /usr/local/Cellar/curl/7.38.0/bin/curl --insecure --cert ~/.boot2docker/certs/boot2docker-vm/cert.pem --key ~/.boot2docker/certs/boot2docker-vm/key.pem https://boot2docker:2376/images/json
curl: (58) SSL: Can't load the certificate "/Users/nicolas/.boot2docker/certs/boot2docker-vm/cert.pem" and its private key: OSStatus -25299

J'ai pu vérifier que les certificats sont corrects, car wget - lui - s'en sort sans soucis

➜ ~ wget --no-check-certificate --certificate=~/.boot2docker/certs/boot2docker-vm/cert.pem --private-key=~/.boot2docker/certs/boot2docker-vm/key.pem https://boot2docker:2376/images/json -O - -q
[{"Created":1413235207,"Id":"9cbaf023786cd79dfba46f49d9a04b2fe9f18017db1257094d1d4cbe7ccb00f1","ParentId":"03db2b23cf0332af20d600e1e0306a629235f4d3b2cfcab2cad0bc3d3443b2b7","RepoTags":["ubuntu:14.04"],"Size":0,"VirtualSize":192754576}


J'ai poussé une pull-request pour documenter cette commande alternative, au cas où je ne serais pas un cas isolé.

Si vous voulez passer en Docker 1.3.0 vous risquez de tomber sur des soucis de ce type. Et surtout si vous utilisez des librairies cliente docker dans vos outils (typiquement, le plugin jenkins docker qui est une aberration mais ça c'est un autre débat) vous êtes cuits. Ce qui m'encourage dans mon plugin à moi (qui lui est une merveille, qui en douterait) à continuer à utiliser le client docker officiel.




16 octobre 2014

Du docker dans Windows ?

L'annonce n'a pas du vous échapper, Microsoft ne laisse pas le buzz Docker lui échapper et annonce un partenariat pour porter la technologies sur Windows.

Petit décryptage.

Microsoft ne veut évidemment pas laisser passer le train, et l'équipe Docker sait pertinemment que Docker ne peut pas éternellement se contenter du monde Linux. Le rapprochement est donc logique. Par contre ne vous y trompez pas, il ne s'agit pas de faire tourner un conteneur Linux en natif sur votre Windows, ou l'inverse - pour le développeur, boot2docker a encore de beaux jours devant lui.

Rappelons que le principe même des conteneurs est que le noyau OS est commun entre l'hôte et l'environnement virtuel ("conteneur") contrairement à une machine virtuelle. Il s'agit bien de faire tourner un (on N) process windows dans un conteneur, sur un système windows.


On va donc avoir des images Docker pour des conteneurs Windows d'une part, et les images Linux qu'on connait déjà de l'autre - séparation qu'on a déjà par exemple pour les images Docker visant les architectures ARM (bon bien sur y'en a pas des masses).



Ce qu'on nous annonce :

  • A Microsoft led initiative to add container capabilities (e.g. the equivalent of namespaces and cgroups) to Windows
En gros ici il ne s'agit que d'une annonce d'intention. On aura donc peut être un concept d'isolation équivalent aux namespaces dans Windows Server 2020. Le développement de cette fonctionnalité sous Linux a tout de même pris 10 ans. Evidemment Microsoft peut aller beaucoup plus vite, mais ce ne sera pas pour noël prochain.

  • A new Docker Windows Daemon, which will be built in open source under the aegis and governance of the Docker project, with input from Microsoft, Docker, Inc, and the broader Docker community
Il s'agit globalement de développer dans le cadre du projet Docker OSS un portage de libContainer sous Windows, le genre de chose sur lequel travaillent également les personnes de FreeBSD ou d'IBM. Le démon Docker Windows sera donc compatible avec l'API Docker, ce qui est une bonne nouvelle : tout votre outillage sera alors 100% utilisable.

  • The overall Docker platform, which will also be extended (in the open) to support both the Docker Windows Daemon and the Docker Linux Daemon.
Plus précisément, Microsoft va investir sur la librairie LibSwarm pour permettre l'orchestration de containers sur son OS.

Bref, Microsoft adopte la technologie qui monte et le fait en bonne entente avec la communauté, ce qui est une bonne nouvelle pour tout le monde.

Reste à savoir si Apple suivra la même démarche...

15 octobre 2014

docker exec preview

A new feature to come in docker 1.3 I'm waiting for is docker exec command. This one will make docker-enter hack an official command. This command will let you attach a new process to an existing container, for diagnostic or monitoring purpose (for sample) or some more advanced hacks I have in mind :-D

As I wanted to test it before official release, I had to check how to build Docker from latest sources.

Docker build system is based on Docker. Don't ask me how debian folks can follow their "build from source" principle, anyway it makes our life easier.

On my Ubuntu box, I just had to clone docker git repository and run make binary to get the latest an greatest docker binary and give it a try, but I wanted also to get it on my good old MacBook.

make cross is designed to build alternate docker binaries for non linux/x64 systems (i386, arm, darwin, freebsd). It works well, but then I need to retrieve the generated binary from the build container.

I'm using boot2docker with VirtualBox guest additions, waiting for 1.3 to offer this by default. But when ran remotely (in boot2docker VM) the Makefile require to setup a BIND directory for docker working copy to be mounted in the container at expected location. I wasn't able to make it work, for some odd reason the dind script fail to start.

Anyway, David gave me to find a workaround.

make build gives me the container image ID for an environment ready to build docker from sources. I can then run a (privileged) container, equivalent to the one ran by make binary,  as a shell and run the hack/make.sh cross command by myself. As a result, this container has all the cross-compiled binaries build in bundles folder.

I then run another docker command from OSX to retrieve the built OSX binary form the (still running) build container : 
docker cp 987654321:/go/src/github.com/docker/docker/bundles/1.2.0-dev/cross/darwin/amd64/docker-1.2.0-dev/docker ./docker-osx

So I now have docker client 1.2.0-dev (a java developer would name it "1.3.0-SNAPSHOT") available on my OS.

I have to do the same on my boot2docker VM so it run 1.2.0-dev daemon. Just need to stop the docker daemon and replace /usr/local/bin/docker. Please note this change won't be persisted if you restart the boot2docker VM. Would need to build a custom iso, but I'm lazy here :-P

Anyway, I now can play with the new docker exec command

➜  docker-1.2.0-dev ./docker version
Client version: 1.2.0-dev
Client API version: 1.15
Go version (client): go1.3.3
Git commit (client): dc243c8
OS/Arch (client): darwin/amd64
Server version: 1.2.0-dev
Server API version: 1.15
Go version (server): go1.3.3
Git commit (server): dc243c8
➜  docker-1.2.0-dev ./docker run -d ubuntu sleep 1000
fc17ce405dba8417d7995218bd142041877cadcf49751f2233aecf01a7c25114
➜  docker-1.2.0-dev ./docker exec -it fc17 bash
root@fc17ce405dba:/# ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 13:44 ?        00:00:00 sleep 1000
root         7     0  4 13:44 ?        00:00:00 bash
root        21     7  0 13:44 ?        00:00:00 ps -ef
root@fc17ce405dba:/# 

I organize a local edition of Docker Global Hack Day on october 30th. Hacking with such a new command is an option to experiment with new usages and design some crazy tool. Join !