Compte-rendu BreizhCamp 2017

La DockerCon comme si vous y étiez

Lors de cette présentation, Nicolas de Loof était accompagné de Sylvain Riversault pour assurer le spectacle autour du thème de la DockerCon.
Les keynotes de la DockerCon étant sujettes à des démonstrations et des annonces de nouvelles fonctionnalités, ils ont fait un retour sur les différentes annonces des dernières années de cette conférence (que ce soit la version US ou Européenne).
Les deux speakers sont ensuite revenus plus en détails sur les annonces de cette année :

• Moby, projet open-source permettant de construire sa propre plateforme de containers. Docker CE et Docker EE seront basés sur Moby
• Multi-stage builds pour créer des images plus petites
• LinuxKit afin de minimaliser le système d’exploitation nécessaire pour faire tourner un container.

Skynet vs Planète des singes, fight !

Il s’agit ici d’un combat entre 2 clusters Docker, Skynet étant représenté par Adrien Blind et Laurent Grangeau, la Planète des singes par Ludovic Piot. Nous vivons à BreizhCamp l’épisode 2, le premier ayant eu lieu lors d’un BOF à Devoxx France. La suite des épisodes durant les prochaines conférences de l’année (RivieraDev, Devoxx Luxembourg, …).
La première plateforme Skynet construite à Devoxx consistait en des instances AWS lancées avec des AMI customisées dans un ASG. C’était un bon début mais ça ne correspond pas au but recherché.
En effet, la plateforme construite doit être hébergée sur différents fournisseurs de cloud, sans dépendances aux fonctionnalités avancées de ceux-ci. De plus, le stockage est réalisé via Infinit, ce qui permet la création d’un stockage résilient et redondant en utilisant les éléments de stockage des différents fournisseurs de cloud. Docker ayant été choisi pour faire tourner l’application, un registry est instancié sur tous les noeuds du cluster en utilisant ce stockage distribué. Une démonstration de la création d’un cluster sur AWS et Azure en utilisant Terraform pour initialiser l’ensemble des composants, dont l’application pour se défendre de l’attaque de la Planète des singes. Afin de s’assurer de la résilience du cluster, une image Docker avec Terraform est utilisée régulièrement, le stockage distribué permettant d’éviter un lancement multiple de cette image.

Maintenant, au tour de la Planète des singes de présenter son infrastructure et ses outils. Cette infrastructure sera constituée d’un cluster Kubernetes. Pour l’attaque, l’outil Chaos Monkey de Netflix sera utilisé. Toutefois, celui-ci nécessite désormais l’installation de Spinnaker, un outil composé de nombreuses briques. Heureusement, Helm, le “package manager” de Kubernetes vient à la rescousse. Il existe un package pour installer les différents éléments de Spinnaker. Ce package a été modifié afin d’intégrer l’installation de Chaos Monkey. Une démonstration du déploiement du cluster Kubernetes avec l’outil Kops ainsi que du Chaos Monkey termine la présentation.
Le code source de ces infrastructures sera prochainement disponible sur le repository Github dédié. Plus d’informations en suivant le hashtag suivant sur twitter : #skynetvsapes.

Les problèmes que l’on rencontre en microservice : configuration, authentification et autres joyeusetés

Quentin Adam de CleverCloud nous présente pour quel raison il aime les microservices ainsi que des conseils sur ce qu’il faut faire avec ceux-ci.
Les microservices facilitent en effet :

• l’utilisation de plusieurs stacks logicielles
• un agenda de scaling différent par microservice, ce qui permet de ne servir que ce qui est nécessaire au bon moment
• l’évolution : remplacer une brique de l’architecture est de ce fait plus simple.

Toutefois, un réseau totalement fiable n’existe pas. De ce fait, chaque communication entre services doit être authentifiée, chiffrée et surtout auditable. De plus, afin d’échanger des messages entre eux, en raison de ces problèmes de fiabilité, il faut mettre en place des messages brokers (RabbitMQ/Kafka, …) qui permettront de pallier ces faiblesses.
Nous poursuivons ce talk par une question importante : comment réaliser le découpage en microservices. Il faut éviter un découpage trop important, car cela générera énormément d’échanges sur le réseau, ce qui va provoquer des lenteurs pour vos services. Le découpage doit se faire suivant différents critères :

• le microservice doit fournir en service en lui-même
• est ce que les services partagent du code ?
• est ce que les données sont partagées ?
• quel est le besoin en agenda de scaling ?

Nous finissons sur deux points : la configuration et l’authentification. Bien évidemment, la configuration ne doit pas se trouver dans le code. Le concept d’immutable infrastructure est important pour CleverCloud, la configuration doit être dans des variables d’environnements. Si la configuration doit être modifiée, ces variables sont modifiées et une nouvelle instance du microservice est lancée avant de supprimer la précédente. Des services tels que ETCD ou Consul peuvent être utilisés. Enfin, l’authentification distribuée pour les microservices est une chose complexe. Après avoir détaillé les solutions existantes et les défauts associés, les solutions utilisables sont JWT, qui permet une authentification via un token en JSON passant de service en service sans besoin supplémentaire du serveur d’authentification, ainsi que Macaroons qui fonctionne sur le même principe avec une possibilité de délégation de l’authentification.
Pour conclure, une bonne architecture de microservices rend le développeur heureux, il est donc important de se poser les bonnes questions avant de commencer.

Containers et configuration : de la promesse au concret avec git et confd

Christophe Furmaniak, consultant chez Zenika, aborde dans cette présentation les problèmes rencontrés avec la gestion de la configuration des containers. En effet, les containers sont un moyen élégant de packager les applications. Toutefois, les environnements ne sont pas tous égaux et la configuration ne peut donc pas être portée par l’image de container. De plus, suivant le nombre d’environnements à gérer, souvent associé un nombre d’équipes dans les mêmes proportions, ce sujet peut devenir épineux. De ce fait, comment faire pour générer la configuration et l’apporter aux containers, comment la gérer (qui peut la définir, l’historisation, …) ?
La configuration étant constituée de fichiers lisibles ou de binaires (certificats/chiffrement), il est difficilement envisageable d’utiliser des variables d’environnement à transmettre aux containers. Il est possible d’utiliser une seconde image stockant la configuration, associée au container applicatif, le point négatif étant la génération d’image à chaque changement de configuration souhaité.
La solution alors proposée est d’utiliser git pour la gestion des droits ainsi que l’historique et Confd, un système de templates en Go qui seront stockés sur les images applicatives et qui peut récupérer les options de configuration sur différents backends tels que Consul, ETCD, Zookeeper et beaucoup d’autres. La présentation s’est terminée par une démonstration de l’utilisation de cet outil, qui se révèle assez sympathique.

Parenting 2.1 : calmer son bébé avec du machine learning et un Raspberry Pi

Giulia Bianchi de Xebia nous présente un exemple de mise en place de Machine Learning basé sur une histoire vraie. Le but est de traiter les problèmes de sommeil d’un bébé, en diffusant une musique douce en cas de pleurs, ce qui sera fonctionnel en cas de cauchemar. De façon très simple, le Machine Learning consiste à partir d’un jeu de données, d'entraîner ici notre logiciel à reconnaître les sons afin de pouvoir prédire si le son enregistré est un pleur. Les enregistrements sont réalisés par chevauchement et si trois échantillons correspondent, la prédiction est validée. La présentation s’est terminée par une démo, le logiciel est codé en python, packagé dans une image Docker et tourne sur un Raspberry Pi.

Quand internet sera gouverné par les |chats> de Schrödinger

Derrière le titre de ce talk, Nicolas de Loof nous a parlé d’informatique quantique, que ce soit pour le calcul ou pour la communication. Il nous sera difficile d’en faire un résumé compréhensible tant le sujet est complexe, même si traité avec légèreté. Nous ne pouvons que vous inviter à regarder la vidéo bientôt disponible sur Youtube.

Introduction à Unikernel

Tomas Rodriguez et Jean-Baptiste Claramonte de Xebia nous présentent ce qu’est Unikernel. Nous pouvons constater que la virtualisation est actuellement fortement utilisée. Toutefois, afin de fonctionner, les différentes couches de virtualisation ont forcément un impact sur les performances. En effet, le kernel Linux contient bien trop de choses pour faire tourner une seule application. Les librairies chargées par la machine virtuelle constituent une surface d’attaque plus large et de ce fait, la sécurité pour héberger une seule application est affaiblie.
Une réponse à cela est Unikernel : un kernel fortement allégé, seule la portion utilisée par l’application des librairies systèmes est intégrée ainsi que l’application, bien évidemment. De ce fait, un seul processus est autorisé.
Maintenant, si nous voulons tester les Unikernel, nous pouvons nous tourner vers Unik, OSv, ClickOS parmi tant d’autres que vous pouvez trouver ici
Pour terminer, une présentation a été réalisée pour le déploiement d’une application serveur en Java via OSv, de la construction de l’image au run.

Conclusion

Nous ne pouvons que conclure cet article comme nous l’avons fait dans notre compte-rendu sur Devoxx. Certaines présentations seront disponibles en vidéo. Cette conférence nous a permis de voir des talks intéressants et de faire de belles rencontres. Nous ne pouvons que vous conseiller de vous inscrire l’année prochaine et venir voir de vous même la conférence “à l’Ouest”.