Il y a 1 année · 23 minutes · DevOps, Events

Xebia était présent à la DockerCon 16

DockerconAprès avoir participé en fin d’année dernière à l’édition européenne de la DockerCon qui avait eu lieu à Barcelone, nous ne pouvions cacher notre excitation lors de notre départ à Seattle de prendre part à cette édition américaine de la grande messe annuelle de Docker.La DockerCon c’est deux jours intenses d’annonces, de sessions techniques, de démonstrations, d’échanges avec la communauté et de fête.

DOckerCon-view

Voici notre retour de cette énorme conférence…

Pré-inscription

Arrivés samedi sur Seattle, nous avons eu l’occasion de nous pré-inscrire dès dimanche soir afin de récupérer notre badge, le graal pour pouvoir accéder aux sessions durant les deux jours de conférence.bumpup-docker

Cette année Docker a souhaité simplifier les échanges entre les participants grâce à un bracelet connecté permettant de se « Bumper » en entre-choquant les bracelets avec les autres participants. Une application dédiée permet ensuite de récupérer les informations de chaque contact bumpé, une super idée pratique et fun !

En plus de faciliter les mises en relation entre participants ce bracelet permettait de récupérer des points liés à notre activité pendant la conférence (session suivie, participation aux hands-on, mise en relation, etc.). Chaque point collecté permet progressivement d’atteindre le niveau supérieur et de progresser au classement général.

Par ailleurs, les points marqués durant la DockerCon ne resteront pas une action individuelle. En effet l’ensemble des points sont mis en commun afin de débloquer le financement d’un nouveau fond de bourses d’études lancé par Docker lors de la conférence pour le soutien des groupes sous-représentés dans le monde l’IT.

Jour 1

General Session

Début de la première journée avec une General Session. Imaginez 4000 personnes qui se dirigent vers la salle en même temps, c’est énorme et très impressionnant surtout si l’on se rappelle que cette conférence n’existe que depuis 3 ans.

La session commence par l’arrivée de Ben Golub, CEO de Docker, qui nous présente Docker en quelques chiffres. Le nombre de projets conteneurisés continue d’augmenter de manière exponentielle, aujourd’hui presque la moitié des entreprises utilisent Docker en Production. Du côté de la communauté, c’est plus d’une centaine de Pull Requests revues par semaine et toujours près de la moitié des fonctionnalités poussées par la communauté.

Ben tient ensuite à nous présenter plusieurs sessions particulières,

  • une sur le repliement des protéines,
  • une seconde sur l’analyse des données dans les sports,
  • et une dernière sur l’extension d’un jeu vidéo.

Il nous dévoile alors que ces trois initiatives seront présentées par des enfants de moins de 13 ans. Docker est un incroyable « enabler » et ce type de projets le prouve chaque jour… bluffant !

Ben Golub laisse ensuite la place au CTO de Docker, Solomon Hykes, qui nous rappelle que la programmation est en train de changer le monde. Il est alors important de réduire les frictions liées au cycle de développement grâce à des outils qui doivent être simple d’utilisation, s’adapter à chaque utilisation et permettre de réaliser des choses complexes le plus simplement possible. Chez Docker, ces caractéristiques se retrouvent dans chaque produit et doivent rester un vecteur d’innovation.

Pour illustrer ce discours, nous assistons à une première démonstration qui met en évidence la simplicité du cycle de développement avec l’utilisation de Docker for Mac et Docker Cloud. C’est simple à installer et à utiliser, la promesse est atteinte !

La General Session se poursuit avec plusieurs annonces…

La première concerne le passage en Beta public de Docker for Mac or Windows. Avec plus de 70 000 beta testeurs, ce nouvel outil permet d’installer en quelques clics Docker sur son poste de travail et apporte plusieurs fonctionnalités bien pratiques, comme la possibilité de débugger en live son application avec l’utilisation de Docker Compose qui détecte automatiquement les changements puis permet de redéployer à chaud son application. Nous aurons l’occasion d’en reparler à travers notre retour de la session « Docker for Developers – part 1 » présenté par David Gageot.

Autre grosse annonce : la sortie d’une nouvelle Release Candidate de Docker 1.12 avec son lot de nouveautés et un gros focus sur l’orchestration. L’orchestration pour les non-experts est difficile à adresser et se traduit généralement par le recrutement d’une armée d’experts où le fait de rester bloqué sur une mise en place longue et fastidieuse. La meilleure manière d’orchestrer Docker ne serait-elle pas finalement de pouvoir le faire directement avec le démon Docker ? C’est maintenant possible grâce au Swarm mode intégré au sein de Docker.

Dockercon-1

Le Swarm mode qu’est-ce que c’est ?

  • La possibilité de combiner ses démons Docker avec Swarm quelque soit la taille du cluster,
  • le déploiement d’un cluster auto-organisé et auto-diagnostiqué,
  • la suppression de la nécessité d’avoir à mettre en place un KeyValue-store externe,
  • une topologie agnostique à l’infrastructure sous-jacente,
  • le redéploiement automatique en cas d’incident sur un noeud du cluster.

Pour configurer un cluster Swarm, rien de plus simple : il suffit d’utiliser la nouvelle commande « swarm »

$ docker swarm init               # initialisation du cluster Swarm
$ docker swarm join <host>:<port> # ajout d’un noeud au sein du cluster
$ docker node ls                  # liste l’ensemble des noeuds du cluster

Autre nouveauté apportée par l’intégration des outils d’orchestration dans Docker, le Cryptographic node identity qui permet l’identification unique de chaque noeud. Le cluster est entièrement sécurisé par défaut grâce à l’utilisation de TLS pour chiffrer l’ensemble des communications entre les noeuds, l’utilisation d’une PKI pour gérer la création des clefs, et offrant également un mécanisme de rotation automatique. Il sera par ailleurs toujours possible de révoquer un noeud à n’importe quel moment.

En parallèle de cette intégration, Docker 1.12 propose la nouvelle Docker Service API dédiée à la gestion des services qui se composent des fonctionnalités suivantes :

  • la gestion de la scalabilité de chaque service,
  • la possibilité de mettre à jour un service en s’appuyant sur un mécanisme de rolling update,
  • la mise en place d’un health-check au niveau application s’appuyant sur la nouvelle instruction HEALTHCHECK du Dockerfile.

Pour créer un service, c’est tout aussi simple :

$ docker service create --name <service> <image_id>  # création d’un service
$ docker service tasks <service>                     # liste de l’ensemble des tâches du service
$ docker service scale <service>=<replicas>          # faire scaler le service
$ docker service update <service> --image <image_id> \
                                  --update-parallelism 2 \
                                  --update-delay 10s # mise à jour du service

Dockercon-2

Également dans les nouveautés, le mécanisme de Routing Mesh qui offre plusieurs fonctionnalités bien pratiques :

  • la gestion de l’overlay network au sein du cluster Swarm,
  • un système de load-balancing natif au niveau conteneur,
  • pas de configuration spécifique pour la gestion du réseau,
  • l’utilisation de IPVS qui offre d’excellentes performances,
  • l’intégration avec la plupart des load balancers du marché.

Pour information, si vous utilisez la beta de Docker for Mac or Windows, vous avez déjà Docker 1.12 installé sur votre machine ;).

Nous avons également assisté à la présentation des améliorations de la gestion des plugins au sein de Docker. Cette fonctionnalité est présenté en 1.12 mais est considérée comme experimentale, ce nouveau mécanisme devrait arriver dans la version 1.13 de Docker. Il s’articule autour de la nouvelle commande « plugin » :

$ docker plugin install <plugin> # installation d'un plugin
$ docker plugin enable <plugin>  # activation d'un plugin
$ docker plugin disable <plugin> # désactivation d'un plugin
$ docker plugin inspect <plugin> # affichage des informations d'un plugin
$ docker plugin rm <plugin>      # suppression d'un plugin

Ce mécanisme de gestion des plugins s’accompagne d’un nouveau système de permissions qui permettra simplement d’autoriser l’accès où non aux différentes fonctionnalités du démon Docker. Notons également que Docker 1.13 intégrera la notion de plugins globaux, installés automatiquement sur chacun des noeuds.

La General Session fait ensuite un focus sur l’amélioration de l’expérience des Ops quant à l’utilisation de Docker.

Et cela commence par l’annonce du lancement de la beta de Docker for AWS or Azure qui permet d’installer simplement une instance de Docker Datacenter sur Amazon AWS ou Microsoft Azure en s’intégrant avec les services de chaque provider dont :

  • les load-balancers,
  • le système de template,
  • la gestion de clefs SSH,
  • les ACLs,
  • les scaling groups,
  • les règles de firewall.

Concernant Docker for AWS, l’outil s’intègre entièrement avec Cloud Formation afin de pouvoir bootstrapper très rapidement l’installation en seulement quelques clics.

Cette première session se termine sur un état des lieux : finalement, personne ne prête véritablement attention aux conteneurs et c’est bien l’application que l’on livre sous la forme d’un conteneur qui compte !

Dockercon-3

Afin d’améliorer les aspects liés à la distribution des applications conteneurisées, Docker a annoncé le DAB (Distributed Application Bundle), pour le moment en expérimental et qui introduit un nouveau format d’échange d’application multi-conteneur portable. Ce nouveau format permet d’exporter simplement une stack applicative à partir d’un fichier de configuration Docker Compose puis de la déployer tout aussi facilement en utilisant la nouvelle commande « deploy » de Docker.

$ docker-compose bundle       # création d’un DAB
$ docker deploy <bundle_file> # déploiement d’une stack applicative

The Golden Ticket: Docker and High Security Microservices

À travers cette présentation, Aaron Grattafiori nous a parlé de la sécurité au sein des architectures microservices s’appuyant sur Docker. Plusieurs principes doivent être pris en compte afin d’améliorer la sécurité au sein d’une telle architecture. Le premier est le principe de Least Privilege qui a souvent tendance à être oublié lorsque l’on utilise des conteneurs. Il consiste à ce que chaque host et conteneur ne possèdent que les privilèges et ressources nécessaires à leur exécution, et rien de plus. Il est par exemple important d’éviter de lancer les conteneurs en tant que root.

Un autre principe consiste à utiliser une distribution Linux minimaliste sur le host afin de réduire au maximum la surface d’attaque éventuelle au sein de son cluster. Au sein de ces distributions Linux minimalistes vous trouverez plusieurs projets dédiés à l’orchestration de conteneurs privilégiant la sécurité, parmi lesquelles :

Améliorer la sécurité de ses services conteneurisés, c’est aussi faire le bon choix d’OS pour son image de base. Plusieurs critères sont à prendre en compte dans ce choix :

  • les mises à jours sur le système,
  • la compilation des packages,
  • les contrôles d’accès MAC (Mandatory Access Control),
  • les différents paramètres du Kernel,
  • la présence de certains outils tel que sysctl.

Le choix de son image de base est importante cependant cela est rarement suffisant. En effet, même avant d’avoir fait le moindre apt-get install une énorme quantité de librairies exécutables sont probablement déjà présentes au sein de votre conteneur (perl par exemple), ainsi qu’un grand nombre de fichiers qui ne seront pas nécessaires à votre processus par défaut. Davantage il y a de packages installés au sein de votre image de base, davantage vous serez amené à gérer des patchs de sécurité, sans parler de l’espace disque utilisé inutilement. La surface d’attaque est importante et les outils qui peuvent être exploités au sein du conteneur par l’attaquant sont nombreux.

Il existe d’autres techniques qui permettent de créer des images encore plus minimalistes dont voici quelques exemples :

Aaron nous conseille également vivement d’utiliser sysdig afin de tracer les appels système des processus au sein de chaque conteneur.

Dockercon-4

Aaron recommande aussi d’utiliser Seccomp afin de limiter les appels système, à utiliser conjointement avec ce script, disponible sur le repository de Docker sur GitHub qui vous fera gagner un maximum de temps à l’usage.

Les règles à prendre en compte pour atteindre un niveau maximum de sécurité lors de la mise en place d’une architecture microservices s’appuyant sur Docker sont :

  • activer les User Namespaces,
  • déterminer des règles avec AppArmor,
  • limiter les appels sytème avec Seccomp,
  • renforcer le système installé sur le host,
  • restreindre les accès au host,
  • ne pas oublier la sécurité du réseau.

Lors de sa présentation Aaron nous a également rappelé l’importance de bien protéger les échanges réseaux et de correctement gérer l’authentification et les autorisations. En 2016, il n’est effectivement plus en envisageable de ne pas chiffrer un traffic réseau quelqu’il soit et de ne pas utiliser TLS. Concernant la gestion de l’authentification, il faut s’attacher à sécuriser les accès depuis la couche la plus basse possible et contrôler l’ensemble des flux réseaux.

Docker for Developers – part 1

Lors de ce slot se déroulant dans la salle « Docker, Docker, Docker. »David Gageot nous a présenté les nouveautés de Docker 1.12 et de Docker for Mac, s’appuyant sur une application de génération de phrases en microservices.

Dockercon6

Dockercon5
Pour cette démonstration, David a développé une application en Java au sein de son IDE préféré Intellij Idea et nous a montré comment Docker a permis de simplifier le cycle de développement de cette application. Tout d’abord, grâce à l’utilisation d’un fichier de configuration pour Docker Compose, il est très facile de lancer son application en local pour pouvoir la tester dans un environnement complètement iso avec celui de la Production.

La dernière version de Docker for Mac s’appuyant sur Docker 1.12 permet maintenant de simplifier grandement le debugging de son application en détectant automatiquement chaque changement dans le code source et en redéployant ensuite la nouvelle version de l’application. Les modifications sont redéployées à chaud grâce à Docker Compose qui permet véritablement de faire du debugging en live de son application.

Autre fonctionnalité apportée par Docker 1.12, la possibilité de gérer simplement la scalabilité de ses services en local sur sa machine grâce à l’utilisation du Swarm mode.

Une dernière fonctionnalité offerte par la dernière version de Docker, la possibilité de redémarrer automatiquement un conteneur lors d’un arrêt du démon Docker grâce à l’option « –live-restore ». David a quant-à lui montré la possibilité de redémarrer son application grâce à un simple « restart » du service, pour cela il a arrêté son Mac, puis redémarré et vérifié que son application était toujours bien en cours d’exécution, pratique !

Grâce à Docker 1.12 et Docker for Mac, le cycle de développement d’une application n’a jamais été aussi rapide et quant à l’environnement de développement, il n’a jamais été aussi proche de celui de production.

Containerd: Building a Container Supervisor

En allant voir ce talk présenté par Michael Crosby, nous savions déjà à quoi nous attendre connaissant un peu le personnage et nous n’avons pas été déçu !

Michael nous a présenté l’architecture de containerd en commençant par nous rappeler les raisons qui ont poussées à développer cet outil et à l’intégrer dans Docker depuis la version 1.11 : mettre en place un superviseur de container rapide et léger, qui soit capable de jouer le rôle de multiplexer pour OCI, et d’opérer simplement le cycle de vie des conteneurs.

Parmi les fonctionnalités de containerd qu’il faut retenir :

  • l’intégration avec runc,
  • le support de multiples runtimes,
  • le fait de ne plus conserver l’état des conteneurs au sein du système de fichiers,
  • la capacité de faire tourner des conteneurs sans démon.

Containerd utilise un système de shim qui facilite le reparentage du conteneur lorsque le démon Docker redémarre. Grâce à ce mécanisme il est maintenant beaucoup plus simple de mettre à jour le démon Docker sans avoir à arrêter les conteneurs qui restent en cours d’exécution sur le système.

Dockercon-7

Michael nous a alors expliqué en détail le nouveau cycle de vie d’un conteneur avec l’utilisation de containerd et des shims avec runc, et en particulier comment était réalisé le mécanisme de reparentage lorsque le démon doit redémarrer. Pour cela il s’appuie sur la fonctionnalité de subreaper du kernel Linux grâce à l’utilisation de l’instruction PR_SET_CHILD_SUBREAPER qui permet d’attendre que le processus parent soit bien redémarré avant que l’ensemble des processus enfants lui soit rattachés. 

Windows Server and Docker – The Internals Behind Bringing Docker and Containers to Windows

Dernier slot de la journée avec la présentation de Docker sur Windows Server par Taylor Brown et John Starrks de Microsoft, un slot incroyablement riche quand on voit le travail qui a été réalisé par Microsoft pour implémenter Docker sur Windows Server.

La présentation a commencé par rappeler ce qu’est Docker sur Windows, à ne pas confondre avec Docker pour Windows. En effet, c’est un véritable portage du démon Docker sur Windows exposant la même API et pouvant utiliser les même outils comme Docker Compose ou Swarm. Cette implémentation de Docker s’appuie sur les technologies natives de gestion de conteneurs disponible sur Windows Server 2016 et le dernier Windows 10 et permet d’executer des conteneurs Windows Server sur des hosts Windows, et ne permet donc pas de lancer des conteneurs Linux.

Nous avons alors pu découvrir une comparaison des architectures de Docker sur Linux et sur Windows à travers deux schémas :

DockerCon-8DockerCon-9

Sur Windows, Compute Service vient remplacer containerd et runc en réimplémentant les Control Groups (cgroups), les Namespaces (Pid, net, ipc, mnt, uts) et la partie Layer Capabilities (Union Filesystems) utilisé par Docker sur les systèmes Linux. Pour cela Compute Service s’appuie sur les Job objects, les Object NamespaceProcess Table et le Networking de Windows, ainsi que sur la Registry en tant que Union Filesystem.

Pour utiliser Docker sur Windows il existe plusieurs types de conteneurs :

  • Windows Server Containers
  • Hyper-V Containers

Dockercon10Dockercon11

Les conteneurs Windows Server s’exécutent directement sur le kernel Windows tandis que les conteneurs Hyper-V s’exécutent au sein d’une VM optimisée déployée sur l’hyperviseur Hyper-V. Pour pouvoir utiliser les conteneurs Hyper-V il faut ajouter l’option –isolation=hyperv au lancement du conteneur. La même VM de base sera alors réutilisée pour l’ensemble des conteneurs.

Concernant les images de base pour les conteneurs Windows, il n’existe pas de FROM scratch et il faudra forcément hériter d’une des images officielle distribuées par Microsoft. Aujourd’hui il existe deux images de base pour Windows :

  • windowsservercore : très volumineuse (9.4 Go) mais entièrement compatible
  • nanoserverpetite (810 Mo), rapide mais avec une couverture de l’API plus restreinte

base images

La présentation s’est accompagnée de plusieurs démonstrations durant lesquelles nous avons pu voir les différents types de conteneur s’exécuter sur Windows. Nous avons eu l’occasion de visualiser les processus au sein de la machine Windows mais également au sein du conteneur… bluffant !

alive

DockerCon Party

Fin de la première journée, riche en annonces, en démonstrations et en échanges avec la communauté, place maintenant à la soirée… Cette année Docker avait privatisé l’EMP Museum ainsi que le Space Needle pour l’occasion, rien que ça ! Nous avions la possibilité de visiter le musée et nous ne nous en sommes pas privés ! En passant par une exposition sur les jeux vidéo, une entièrement dédiée à Jimi Hendrix et une sur les effets spéciaux des films de sciences fictions et d’horreur, nous avons pu visiter l’exposition temporaire dédiée à l’univers Star Trek, simplement génial !

Nous avons ensuite grimpé en haut du Space Needle pour profiter de la vue à 360° de Seattle.Dockercon-13La soirée s’est poursuivie pendant une bonne partie de la nuit à l’intérieur du musée…Dockercon_14

Jour 2

General Session

Bien qu’un peu fatigué par la soirée de la veille, nous sommes toujours autant excités lorsque nous arrivons au centre de conférence pour cette deuxième journée de la DockerCon 16 !

Dockercon-15

Elle commence par une nouvelle General Session durant laquelle Ben Golub nous explique qu’aujourd’hui les chiffres mettent en évidence que les infrastructures et les applications sont hybrides. En effet, en 2016, si nous regardons les cas d’utilisation de Docker dans les projets IT :

  • Docker est présent dans 50% des mises en place des principes du Continuous Delivery,
  • dans 47% des nouvelles applications microservices,
  • dans 43% des migrations d’applications legacy vers une architecture microservices,
  • dans 41% des solutions d’intégration continue,
  • dans 39% des transformations DevOps,
  • et dans 37% des conteneurisations des applications Legacy.

La migration vers les microservices s’apparente à une révolution incrémentale et les entreprises ont besoin de solutions leurs permettant d’adresser cette tranformation. La mise en place d’une plateforme de Container as a Service (CaaS) est la réponse aux besoins de la chaîne de valeur de l’entreprise dans sa globalité :

  • favoriser la conteneurisation à travers la capacité à faire tourner des conteneurs standardisés sur des moteurs de conteneur également standardisés,
  • simplifier l’orchestration afin de construire et déployer des systèmes complexes le plus simplement possible,
  • tourner vers l’entreprise en permettant la livraison de valeur au sein d’entreprises de plus en plus grandes, complexes et en pleine évolution

image2016-6-26-152130.png

 

La réponse de Docker à ce besoin est leur solution commerciale Docker Datacenter qui permet de mettre en place out-of-the-box une solution de CaaS complète.

Dockercon18

Docker Datacenter s’appuie à la fois sur la Docker Trusted Registry qui permet de stocker de manière sécurisée les images Docker et le Docker Universal Control Plane qui permet de gérer toute la partie orchestration et supervision de ces applications conteneurisées. Cette solution utilise le Docker Content Trust afin de signer l’ensemble des images construites avant de les pousser dans la registry et ce, simplement en ajoutant la variable d’environnement DOCKER_CONTENT_TRUST=1. Le Docker Datacenter intègre également une solution de scan de vulnérabilités basée sur l’ancien projet Nautilus et qui permet de vérifier toutes les images poussées au sein de la Docker Trusted Registry.

DockerCon19

DockerCon2à

Cette General Session a été également l’occasion d’annoncer la sortie du Docker Store, place de marché pour logiciels et outils préalablement validés et disponibles au format Docker, à destination des profils métiers et des éditeurs.

 

DockerCon21

Ben a ensuite remercié l’ensemble des partenaires qui composent l’écosystème Docker où Xebia se situe en bonne place dans la partie Consulting & Training !

 

DockerCon22

Nous avons ensuite assisté à une présentation de Docker Datacenter sur Azure par Mark Russinovich CTO de Microsoft Azure. La démonstration a été un peu fastidieuse mais assez bluffante quand nous voyons la simplicité avec laquelle il est possible de déployer une solution de CaaS comme Docker Datacenter sur Azure et de l’intégrer dans son cycle de développement.

Dockercon23

Cette première session s’est terminée par un retour d’expérience sur la place de Docker dans les succès des projets critiques chez ADP présenté par Keith Fulton CTO d’ADP. ADP fournit des solutions de gestion des services de paie et des ressources humaines pour les entreprises de toutes tailles et doivent donc gérer de nombreuses données sensibles.

Le REX a eu un peu de mal à démarrer mais finalement il s’est avéré assez drôle lorsque Keith a commencé à comparer les architectures microservices à des nuggets de poulet et les applications legacy à des poulets !

Dockercon24

Keith conclut sa présentation en exposant que les entreprises en pleine mutation ont besoin de faire cohabiter ces deux mondes : applications legacy et architectures microservices. Et pour cela Docker facilite grandement la tâche, l’utilisation des conteneurs permet de simplifier le déploiement des applications legacy et de gagner du temps qui peut être réutilisé pour refactorer plus rapidement ces mêmes applications vers des architecture microservices.

Unikernels and Docker: From Revolution to Evolution

Début 2016, Docker faisait l’acquisition de Unikernel. Les unikernels sont un sujet assez controversé. Ils détournent l’usage des OS traditionnels, lesquels sont génériques, multi-utilisateurs, ségréguant les opérations système des opérations utilisateur. Par ailleurs, le sujet est très technique et l’utilisation des unikernels se révèle du domaine des experts.

Dockercon25

Cette session est donc l’occasion pour Mindy Preston de revenir sur la présentation des unikernels, comment ils contribuent à l’environnement Docker et quels peuvent être les cas d’utilisations futurs.

Unikernel propose de créer un artefact contenant uniquement ce qui est nécessaire à l’exécution d’une application, y compris les éléments nécessaires de l’OS. En conséquence, l’artefact est de taille minimale, moins exposé aux vulnérabilités et peut être exécuté directement sur une machine, physique ou virtuelle.

Dockercon26

Dockercon27

Les contributions de l’équipe d’Unikernel à Docker sont indirectes mais c’est à eux que l’on doit en autre le composant VPNKit. Ce composant réutilise l’implémentation de la pile TCP de MirageOS, OS dédié aux unikernels. Ils ont ainsi participé à la qualité de Docker Beta, dont la gestion du réseau repose sur VPNKit.

Tout comme la keynote fut l’occasion de remettre les conteneurs au service des applications, le discours quant à l’utilisation d’Unikernel est le même : « Nobody cares about unikernels ». Le contrat est respecté, la technologie fonctionne, il reste désormais à la démocratiser pour que d’autres y trouvent un usage. C’est là que Docker peut être un vecteur d’adoption en réduisant la complexité technique et en offrant la richesse de son écosystème.

Sharding containers: Make Go Apps Computer-Friendly Again

Andrey Sibiryov est un récidiviste de la Dockercon, à Barcelone il nous présentait ses travaux et le projet gorb, un loadbalancer pour conteneur reposant sur IPVS.

Cette année il revient avec Tesson, un utilitaire qui va un peu à contre-courant de l’abstraction des ressources en tenant compte du matériel.

Andrey part d’un constat, les architectures matérielles de nos serveurs ont évoluées et sont désormais très proches des architecture applicatives. On y trouve des bus de communications, des éléments de stockage de données et des services chargés d’effectuer des calculs. S’il parait évident de placer une base de données au plus près de l’application, on pense moins souvent à optimiser les communications au sein d’un serveur en exécutant une application au plus près de la mémoire ou faire du loadbalancing en local.

sharding

Tesson analyse les CPU et les noeuds NUMA du serveur pour en déterminer les capacités puis utilise Docker pour instancier le nombre d’instances optimal et faire du « CPU pinning » sur les processus. La charge est alors répartie sur les processus avec IPVS. Conséquence : sur un worker écrit en go, le gain est de 30%. Évidemment, cela dépend du matériel et du langage utilisé, mais la démarche reste très intéressante. La compréhension de l’environnement est une solution moins couteuse que la scalabilité à outrance.

Conclusion

Après deux jours intenses de conférence il est maintenant temps de rentrer sur Paris… La DockerCon 16 a été riche en nouveautés et en annonces. Nous avons déjà en tête une quantité incroyable de choses à tester puis à mettre en place chez nos clients !

Nous n’avons pas oublié tout ceux qui n’ont pas pu participer à cette conférence et nous rentrons bien chargés de quantité de goodies… il devrait y en avoir pour tout le monde !

Dockercon40

Jean-Louis Rigau
Jean-Louis est expert DevOps chez Xebia. Il est également formateur au sein de Xebia Training .

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *