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.
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.
1 commentaires:
GCE PR version: https://github.com/docker/machine/pull/7
Enregistrer un commentaire