Lors de la XebiCon’19, Ramy Temim, Consultant, chez Publicis Sapient Engineering, a présenté la conférence « Tester ses containers ? Oui c’est possible et c’est simple et rapide ! ».

Lors de la XebiCon’19, Alexis Horgix Chotard, SRE chez Publicis Sapient Engineering, a présenté la conférence « Docker est mort, vive Docker ».

Docker est désormais partout. Mais que fait réellement Docker ? Y a-t-il encore un sens à parler de Docker maintenant qu’il s’agit du simple packaging du projet Moby, qui lui-même n’est qu’une interface vers containerd et runc ?

Le sujet de « build des conteneurs Docker sans Docker » est sur toutes les lèvres de l’écosystème Kubernetes. Côté runtime, Docker en vient de plus en plus a être remplacé. Faisons le point sur cette situation et l’avenir potentiel de Docker.

Découvrez la vidéo :

Toutes les autres vidéos de la XebiCon sont disponibles sur le site de la XebiCon.

Lors de la XebiCon’19, Enrico La Cava, Infrastructure Unreliability Engineer – JobTeaser a présenté la conférence « On demand development environments with Kubernetes ».

When releasing to production 5 times a day or more, any feature should be strongly tested and validated with a dedicated environment that is similar to production.

At JobTeaser, any Pull Request can lead to the bootstrap of such an environment on-the-fly. We call them Feature-envs.

Depending on what you need to test, the production « similarities » can differ. Do you need the same scale as production? Should the URL be customized? How do your manage clean-up?

Today, we will deliver all our secrets to manage those environments at scale with a Kubernetes cluster.

Découvrez la vidéo :

Toutes les autres vidéos de la XebiCon sont disponibles sur le site de la XebiCon.

Lors de la XebiCon’19, Vincent Arrocena, Développeur Full-Stack chez Publicis Sapient a présenté la conférence « Qu’attendre de votre outil de CI/CD en 2019 ».

Tu aimes développer des applications serverless dans ton cloud provider favori et/ou lancer des containers dans Kubernetes, mais continue de traîner une grosse VM de CI/CD à côté de toute cette modernité ? Tu es un héros de l’ombre qui travaille sur des projets legacy et qui souhaite donner un coup de jeune à ta CI/CD.

Ne cherche pas plus loin, c’est le talk qu’il te faut. Nous verrons ce que l’on peut attendre d’un pipeline de CI/CD moderne : des concepts jusqu’aux outils.

Toutes les autres vidéos de la XebiCon sont disponibles sur le site de la XebiCon.

Pour la deuxième édition du Paris Container Day, le 13 juin prochain, Xebia et Wescale n’arriveront pas les mains vides. Les 400 participants pourront découvrir en exclusivité le nouveau TechTrends, dédié… aux conteneurs !

Découvrir le TechTrends Conteneurs

Classiquement, les développements logiciels dans les entreprises s’organisent en suivant trois grandes phases : la construction, le déploiement et la production. Quels que soient le langage ou la technologie utilisés, la phase de construction est bien souvent mature en termes d’outillage et de standardisation. Pour le déploiement, il existe différents outils d’automatisation permettant d’utiliser des solutions adaptées à chaque technologie. Si l’on s’intéresse au run, il existe aussi des solutions automatisées. Cependant, dans l’ensemble, ces outils manquent de standardisation et nécessitent encore aujourd’hui un grand nombre de tâches manuelles lors des opérations de déploiement et de run. Les conteneurs permettent de standardiser ces différentes phases. Ils fournissent un modèle de packaging, de déploiement et d’exécution. Ce modèle est reproductible et portable. Il s’applique tout aussi bien aux solutions techniques sous Linux qu’à celles sous Windows.

L’utilisation de ce nouveau modèle permet de fiabiliser l’ensemble de la chaîne de delivery en définissant un standard commun du développement à la production tout en garantissant une portabilité optimale. Par nature, les conteneurs favorisent l’adoption d’organisation DevOps, car ils concernent l’ensemble de la chaîne de delivery.

Le succès des conteneurs est lié à trois facteurs : la maturité, la simplicité et le packaging. En effet, les solutions d’exécution conteneurisées ne sont pas nées de la dernière pluie. Les namespaces permettent d’isoler un ensemble de processus et de ressources sous Linux depuis 2002. C’est en 2008 que les choses s’accélèrent avec la création des cgroups, qui permettent de maîtriser les ressources allouées aux processus. Ce moment correspond à la naissance des premiers PaaS dont AppEngine, DotCloud et Mesos qui reposent tous dès le départ sur la conteneurisation. Mais c’est aussi l’année de naissance du projet LXC ou Linux Containers, qui fournit un ensemble d’outils et d’APIs facilitant la création et la gestion des conteneurs d’application ou de système.

Enfin, en 2013, l’émergence de Docker popularise leur utilisation. Avec ce nouvel outil, la technologie est devenue abordable et facile à utiliser. Docker fournit, de plus, un modèle de packaging accompagné d’un système de distribution et de déploiement simple, rapide et efficace. Aujourd’hui, les images, tout comme les “wars” dans l’écosystème Java, offrent la garantie d’un package portable pouvant être exécuté sur tous les systèmes supportant les cgroups et les namespaces. Les conteneurs offrent donc l’opportunité d’innover rapidement avec une réversibilité à moindre effort.

Comment pouvez-vous tirer parti de ce nouveau paradigme de packaging et de déploiement ?

• Dans quels contextes leur utilisation est-elle adaptée ?

• Quels sont les défis techniques à adresser ?

• Comment tirer le meilleur de la chaîne de delivery avec ces solutions ?

Pour découvrir la suite, rendez-vous au Paris Container Day. Il ne vous reste que quelques jours avant l’événement, réservez vite votre place.

Le TechTrends Conteneurs, est disponible en téléchargement PDF et EPUB sur xebia.fr.

Redécouvrir les autres TechTrends

Les TechTrends sont l’expression du savoir faire des Xebians ; forgé sur le terrain, auprès des clients dans le cadre des projets que nous menons avec eux. Vous y trouverez les nouvelles tendances technologiques et méthodologiques ainsi que l’état de l’art de notre profession.

Nous tentons de dispenser des conseils directement opérationnels afin de vous guider dans les décisions stratégiques que vous avez à prendre.

Redécouvrez dès à présent les différents TechTrends :

• sur le mouvement DevOps,
• sur les méthodes Agiles,
• sur les bonnes pratiques Craftsmanship,
• sur les bonnes pratiques de développement Front,
• sur la mise en place d’un Data Lab,
• sur les architectures microservices,
• sur le développement d’applications mobiles de qualité,
• sur le Cloud,
• sur l’organisation mise en place chez Xebia Studio pour développer des logiciels de qualité,
• sur l’IoT.

Ne manquez pas la nouvelle formation de Xebia Training dédiée aux conteneurs

Xebia Training est fière de présenter sa formation dédiée à l’écosystème des Conteneurs et de Docker, initiée par deux Xebians, Alexis « Horgix » Chotard et Julien Bonachera.

Cette formation de 4 jours commence par une partie de théorie sur les conteneurs : que sont-ils vraiment ? Pourquoi ont-ils été créés ? Quels en sont les usages ?

La revue de presse hebdomadaire des technologies Big Data, DevOps et Web, architectures Java et mobilité dans des environnements agiles, proposée par Xebia.

Mobilité

Apple annonce iOS11

Par JC Pastant

Comme à son accoutumé, Apple a présenté durant la WWDC 2017 la dernière version de OS phare : iOS 11. Peu de nouveautés pour les développeurs cette année, on retiendra sutout l’ajout du drag&drop ainsi qu’un gestionnaire de fichiers qui vous permettra (enfin !) de parcourir les données stockées sur votre iPhone/iPad comme sur un mac.

Apple s’ouvre au VR et au AR

Par JC Pastant

Comme attendu, Apple a annoncé le support de la VR (Virtual Reality) sur macOS et iOS via une mise à jour de son framework graphique Metal joliment appelé… Metal 2 !

Dans le même temps, iOS hérite d’un framework pour réaliser des scènes en AR (Augmented Reality) : ARKit. Et le résultat semble réussi !

DevOps

Overview de l’orchestration de conteneurs avec Kubernetes

Par Alexis Horgix Chotard

Cette semaine, un des ingénieurs de Onfido partage avec nous un très bon résumé de l’orchestration de conteneurs avec Kubernetes sur de l’AWS, dans un cadre d’intégration continue.

En effet, partant de la base en rappelant pourquoi le besoin d’orchestration se présente rapidement lorsque l’on travaille avec des conteneurs, il y présente les principaux concepts de Kubernetes (master/worker, notion de pod et de deployment, daemonset et replicaset, etc).

Prenant ensuite en compte le fait que le « Kubernetes as a Service » de Google Cloud (GCP) est une solution idéale d’orchestration, il présente néanmoins la solution qu’ils ont retenue pour gérer leur propre cluster Kubernetes sur AWS. Il en profite donc pour rapidement faire le tour de certaines solutions d’automatisation de déploiement d’un cluster Kubernetes (kops, Tectonic, kube-aws et Kraken 2) ainsi que les résultats de leurs essais de ces solutions.

Enfin, la partie « comment déployer une application sur Kubernetes depuis un Pipeline Jenkins » est abordée, s’étendant sur l’exposition du service ainsi déployé.

Pour conclure, les problématiques de logging et monitoring sont rapidement évoquées, ainsi que la partie maintenance avec les points à surveiller.

Un bon résumé d’un des chemins qu’il est possible de suivre losque l’on se lance dans l’orchestration de conteneurs !

Comment faire tourner Chrome (headless)… dans une lambda sur AWS

Par Alexis Horgix Chotard

Avec la popularisation des notions de craftmanship, on parle de plus en plus de browser « headless » (comprendre « faire tourner un navigateur sans avoir celui-ci affiché à l’écran ») permettant notamment de simuler des tests d’applications web sur plusieurs navigateurs.

Côté Cloud et DevOps, la mouvance « serverless » prend également de l’ampleur, avec le service AWS Lambda en tête de file.

Voici donc un article qui propose de combiner ces 2 points… en faisant tourner Chrome dans une lambda. Du lancement de Chrome lui-même en mode headless à la gestion de la lambda, cet article se trouve être à la fois léger et très intéressant puisque détaillant des points rarements abordés. Une bonne lecture pour une fin de semaine !

Mobilité

How to speed up your slow Gradle builds

Par Qian Jin

Quelques semaines après le Google I/O, voici une compilation des astuces extraites depuis la session « Speeding Up Your Android Gradle Builds » avec des explications pour accélérer les builds Gradle dans vos projets Android.

MobileNets: Open-Source Models for Efficient On-Device Vision

Par Qian Jin

Google vient de publier MobileNets, une série des modèles Mobile-First pour TensorFlow. Ces modèles sont conçus pour maximiser efficacement la précision tout en étant conscient des ressources restreintes pour une application sur les devices mobiles. La release contient la définition du modèle en utilisant TF-Slim, ainsi que 16 checkpoints de classification ImageNet pré-entrainés pour les utilisations dans les projets mobiles des toutes les tailles.

Data

Le streaming avec Spark, plus rapide que jamais

Par Loïc DIVAD

Lors du Spark Summit 2017 qui a eu lieu entre le 5 et 7 Juin un nouveau module de Spark a été annoncé : Continuous Processing. Un an après le lancement de Structured Streaming, le composent unifiant l’écriture des traitements batch en temps réel, c’est sur les temps de latence que l’entreprise Databricks a décidé de mettre l’accent cette année. Apache Spark est connu pour avoir un mode streaming basé sur un modèle micro-batch.
L’objectif de ce nouveau module est d’aller plus loin et de permettre l’application continue des requêtes définies via Structured Streaming. La sortie du mode micro batch promet un passage des latences minimales de 100 millisecondes à moins d’une milliseconde. Ce mode d’exécution est disponible sur la plateforme cloud de Databricks et son intégration à Spark est prévu pour la version 2.3.0.

Il a longtemps été question de faire de Spark le moteur de stream processing le plus facile à utiliser, avec Continuous Processing il s’agit maintenant de décrocher le titre de moteur le plus rapide.

Sparkdl, une nouvelle librairie de Deep Learning pour Spark

Par Loïc DIVAD

Le Spark Summit a aussi été l’occasion d’introduire une nouvelle librairie open source dédiée au Deep Learning sur Spark : Deep Learning Pipeline. Même si il existait déjà des initiatives comme TensorFrame ou TensorFlowOnSpark cette nouvelle librairie apporte plusieurs nouvelles fonctionnalités :

• Un import et décodage distribué d’image pour de la classification.
• Le transfert learning qui permet d’apprendre à partir de modèles déjà entraînés.
• L’interaction avec des modèles développés avec Kearas ou TensorFlow.
• L’intégration aux pipelines de Machine Learning déjà existantes dans le cadre de tuning de paramètres.
• La possibilité d’enregistrer des réseaux entraînés sous forme d’UDF utilisables en SQL.

Malheureusement cette librairie n’est disponible qu’en python pour l’instant. Aucune information n’a été donnée sur l’intégration de cette librairie dans Pyspark. La question maintenant est de savoir si elle remplira son objectif en rendant accessible le Deep Learning à une population encore plus grande.

Cloud

Enfin de l’autoscaling pour DynamoDB !

Par Alexis Horgix Chotard

Amazon vient tout juste d’annoncer son ajout de la capacité d’autoscaler DynamoDB, une de ses bases de données as a service.

En effet, jusqu’à maintenant, il n’était possible de définir les « read capacity » et « write capacity » que manuellement, forçant à prévoir la charge soi-même et à adapter ces capacités en conséquence.

Désormais, il sera possible d’automatiquement augmenter ou diminuer ces capacités en se basant sur des métriques remontées par DynamoDB dans CloudWatch.

DevOps

Google et Netflix lancent Spinnaker

Par Alexis Horgix Chotard

Google et Netflix viennent d’officialiser la version 1.0 de Spinnaker, la plateforme de gestion de déploiement sur du cloud.

Alors que certains se reposent désormais sur les orchestrateurs de conteneurs (Mesos/Marathon, Swarm, Nomad, Kubernetes), d’autres travaillent toujours avec des machines virtuelles sur des Cloud publics ou privés. Dans ce cadre, une problématique constante à l’heure du continuous delivery est « comment déployer proprement et automatiquement ? »; canary release, blue/green deployment, et tant d’autres méthodes chacune adaptée à des besoins différents.

Spinnaker, créé par Netflix il y a 3 ans, a pour objectif d’être ce gestionnaire de déploiement. Un remplacement Open Source qui semble très crédible face au « scotch » habituel avec CloudFormation (côté AWS) et leurs « ReplacingUpdates » et « RollingUpgrades » qui ne vont souvent pas assez loin et forcent à finir le travail soi-même avec des lambdas.

La revue de presse hebdomadaire des technologies Big Data, DevOps et Web, architectures Java et mobilité dans des environnements agiles, proposée par Xebia.

Mobilité

Swift 4 rétropédale

Par JC Pastant

Suite aux retours de la communauté après la première bêta de Swift 4, la Core team a décidé de retirer la proposal SE-110 de la release finale.

Cette proposition supprimait le coalescing implicite entre f(x,y) et f((x,y)) ce qui, au regard des retours particulièrement négatifs, engendrait une verbosité accrue non négligeable.

Si vous aviez déjà migré sur Swift 4 beta 1, attendez-vous à devoir dé-migrer une partie de votre code ! ;)

Data

Google permet d’entraîner un modèle multi-tâches avec MultiModel

Par Yoann Benoit

Dans un récent article de leur blog, Google Research présente MultiModel, un modèle capable d’être entraîné sur plusieurs tâches (image recognition, translation, speech recognition). Cette implémentation ouvre les portes aux systèmes d’Intelligence Artificielle générale, capables de prendre des décisions dans plusieurs domaines grâce à un seul et même modèle. Il est intéressant de constater que les données par rapport à un domaine spécifique (image captionning par exemple) permettent aussi d’améliorer les performances dans d’autres domaines. MultiModel a été rendu open-source avec la nouvelle librairie Tensor2Tensor de TensorFlow.

DevOps

Déploiement de modèles de machine learning sur Kubernetes par Domino

Par Alexis Horgix Chotard

Domino, proposant à ses utilisateurs de publier leurs modèles de machine learning en Python ou R sous forme d’API REST pour eux, viennent de complètement ré-architecturer leur infrastructure en se basant sur Kubernetes, et nous proposent un retour sur cette mise en place.

Le point principalement mis en avant est celui de la facilité de déploiement offerte par Kubernetes, qui permet en effet de déployer les nouvelles versions de modèles de manière vraiment simple et automatisée.

Malgré cette facilité, la problématique d’exposition des services de manière tout aussi automatique et transparente s’est posée : pour y répondre, ils ont choisi de se tourner vers Traefik, le reverse-proxy/load-balancer dynamique en Go capable de directement se connecter à Kubernetes pour exposer et load-balancer des services.

4 rôles pour un leader DevOps

Par Alexis Horgix Chotard

Mettons pour une fois le côté technique de côté avec cet article de Jaxenter sur les 4 rôles d’un leader DevOps.

Les 4 roles évoqués sont les suivants :

• Role 1 – Tell the Story
• Role 2 – Be the safety guard!
• Role 3 – Build the Kernel team
• Role 4 – Be the communication enabler

En réalité, cet article adresse de manière large la problématique du leadership face au changement, s’appliquant donc logiquement à toute démarche de transformation DevOps. On parle bien ici de leadership, permettant d’inciter ceux concernés par le changement à en être eux-mêmes les acteurs, et non pas de management.

Le Role 1 évoqué ici (« Tell the Story ») correspond au final très bien à ce que Simon Sinek décrit dans sa conférence « Start With Why »; une conférence à regarder pour quiconque intéressé par ces problématiques de leadership !

Une équipe agile doit être autonome et responsable de bout en bout, voilà le casse-tête qu’il faut se préparer à résoudre quand on se lance dans une organisation en Feature Teams. Autonome ne veut pas dire libre ! Quand on oublie le monde des start-ups et qu’on cherche à appliquer ce modèle organisationnel dans une grande entreprise, la confrontation à la réalité est dure. Afin de rendre ce modèle possible, il faut construire des équipes au service des Feature Teams : bienvenue dans une organisation « as-a-service ».

Une équipe capable de livrer un incrément de valeur

Nous parlons régulièrement de Feature Teams sur le blog de Xebia. Prenons la définition du framework agile LeSS qui définit une Feature Team avec les caractéristiques suivantes :

• elle a un backlog orienté fonctionnalité
• elle est cross fonctionnelle et cross composant
• elle est stable et durable
• elle est capable de livrer un incrément de valeur.

Ces caractéristiques vont donner de l’autonomie à l’équipe, moins il y a de dépendances, plus l’équipe sera en mesure de limiter les temps morts et les blocages. La complexité des plannings sera réduite par la même occasion.

Les responsabilités d’une Feature Team

Quand on parle de responsabilités, ça commence à se compliquer. Il vous est peut-être arrivé d’entendre un ops dire après un week-end d’astreinte :  » c’est pas le dev qui va se lever la nuit quand un serveur tombe ! « . Dans une organisation en Feature Team, il faut assumer le revers de la médaille : pour aller plus vite, il faut endosser plus de responsabilités. Si je veux choisir une stack technique plus spécifique ou un OS différent des standards de l’entreprise, je ne peux pas attendre de support d’une équipe tierce : il faudra l’assumer soi-même. Réduire ses dépendances est alléchant mais il faudra accepter les inconvénients de cette stratégie.

Les Platform Teams, une nouvelle organisation des « ops »

Pour que les Feature Teams ne deviennent pas des usines à produire des fonctionnalités impossibles à maintenir, il faut les aider. L’importance des fournisseurs « as-a-service » dans le modèle d’organisation en Feature Teams est fondamentale. Pour aller vite, une Feature Team cherchera sans doute à prendre le service le plus simple pour pouvoir le rendre spécifique à son besoin. C’est le IaaS (Infrastructure as a Service) : « un serveur et les clés du camion ».

Certains fournisseurs vont plus loin et proposent des services plus évolués avec une garantie de maintien en service : le PaaS (Platform as a Service). Ils se peut que les Feature Teams soient heureuses d’utiliser ce service. Attention ! Ce service devra être construit en collaboration pour favoriser l’expérience utilisateur des membres de la Feature Team. Sans ce pré-requis les Feature Teams se tourneront vers le IaaS. Oublier ses utilisateurs en interne a les mêmes répercutions que de ne pas écouter ses clients : ils s’éloignent. Il faudra alors obliger l’utilisation des services PaaS pour des raisons stratégiques ou sécuritaires… Mauvaise idée !

Dernière possibilité, le SaaS (Software as a Service). Une solution dans laquelle les Feature Teams utiliseront un logiciel clé en main, avec les garanties et bien sûr les contraintes. Les Platform Teams pourront soit développer et proposer la solution logicielle, soit acquérir une solution et la proposer. Dans tous les cas, il s’agit de solutions en libre-service mises à disposition sur une plateforme.

Appelons ces équipes des Platform Teams. À l’instar des Feature Teams, ces équipes sont cross fonctionnelles, cross composant, stable et durable. Elles fonctionnent de manière agile et travaillent avec un product owner. Si vous êtes familier du modèle spotify, elles portent le nom d’infrastructures squads et elle ont le rôle de « enable and support » (permettre et supporter). Ces équipes ops « as-a-service » sont des pièces importantes d’une organisation qui se veut devops.

Définir une limite de responsabilité

Afin que les Feature Teams et les Platform Teams puissent travailler ensemble sans se marcher dessus, il faut définir la limite de responsabilité de chacune. C’est le point de découplage. Les Platform Teams doivent livrer sur une plateforme self-service. Ce produit “as-a-service” requiert de la maintenance, de l’innovation et des responsables. Ce modèle permet aux Feature Teams de développer des produits dont elles vont pouvoir garder la responsabilité du cycle de vie en entier. Elles bénéficieront de services avec un support, d’une stack technique et de configurations validées par l’entreprise. Par exemple des distributions d’OS validées, des serveurs avec les patchs de sécurité à jour.

Quelles Platform Teams pour mon organisation ?

Derrière chaque service qui fonctionne avec un système de ticket, il y a sans doute la possibilité de créer une ou plusieurs Platform Teams. Cela implique des changements. Le premier est de passer d’une activité de run à une activité de mise à disposition de service. Ceci se fait concrètement par la production d’API’s qui seront mises à disposition des Feature teams. Par exemple, des DBA’s qui proposent une API de refresh des bases de données ou des administrateurs systèmes qui proposent une API pour redémarrer des serveurs automatiquement. A chaque action automatisée et « APIsée », le temps gagné devra être réinvesti dans la transformation en équipe « as-a-service ». Chaque service de ce type mis à disposition permettra aux Platform Teams de se libérer du temps. Temps qu’il faudra mettre à profit pour étudier les besoins des Feature Teams et proposer des services à forte valeur ajoutée, comme n’importe quelle équipe agile. Peu a peu les Platform Teams apprendront à comprendre leurs utilisateurs pour gagner le badge « build the right thing » en plus de « build the thing right » dans le challenge du continuous delivery.

A la recherche du point D

C’est maintenant le moment de faire une introspection sur votre système d’information. Il n’y a évidemment pas de réponse universelle dans le choix de votre ou vos point(s) de découplage. Par culture, de nombreuses organisations sont très prescriptives et vont vouloir tout encadrer (PaaS voir SaaS) mais est-ce bénéfique dans un contexte agile où les équipes gagnent en autonomie et en responsabilité ? Est-ce que l’énergie, et donc le budget, investis en valent vraiment la peine? Dans ce cas, un point de découplage IaaS donnera sans doute la possibilité de commencer dès demain. Autre exemple, si le service n’est pas critique ou différenciant pour votre métier, le SaaS sera sans doute une alternative intéressante. Développer son outil de post-it virtuel ou son pipeline de déploiement est rarement une stratégie gagnante. Il vous reste donc à vous lancer dans votre transformation en Feature Team avec la définition des responsabilités à l’esprit.

La revue de presse hebdomadaire des technologies Big Data, DevOps et Web, architectures Java et mobilité dans des environnements agiles, proposée par Xebia.

Mobilité

Android Things Console developer preview

Par Qian Jin

Encore une nouveauté sur Android Things pour compléter l’offre de la plateforme ! Google vient d’annoncer la preview pour la console d’Android Things. La console permet de gérer tous les aspects des logiciels de l’objet, y compris la création d’images d’usine, ainsi que la mise à jour du système d’exploitation et des APK fournis par les développeurs.

Craftsmanship

BDD in JavaScript : Getting Started with Cucumber and Gherkin – Craftsmanship

Par Sarah Buisson

 Vous avez toujours rêvé de mettre en place des tests BDD sur le front de votre projet sans jamais vous lancer ? Dans son dernier article, Graham Cox vous explique pas à pas les bases du BDD, du gherkins et comment mettre en place des tests de comportements automatisés dans votre projet gâce à Cucumber. Un article très pédagogique, accessible à tous  !

DevOps

Shipping des logs à Algolia

Par Alexis Horgix Chotard

Algolia nous propose cette semaine un rapide retour sur la gestion de leurs logs et sur l’architecture qu’ils ont conçu afin de supporter leur envoi et leur traitement. En effet, leur volumétrie (1 milliard de lignes de logs par jour) ne leur permettait pas de rentrer dans les modèles des solutions en SaaS, et ne permettait pas non plus de se tourner vers les solutions de streaming des principaux fournisseurs de cloud pour des raisons de coût.

Au final, la solution implémentée est un simple Pub/Sub, mais la partie intéressante est l’introduction d’un « orchestrateur » fait maison et servant à envoyer les logs récupérés sous forme de batch afin de réduire les coûts.

Releases : CoreDNS et Deep Learning AMI

Par Alexis Horgix Chotard

Comme chaque mois désormais, voici un résumé des principales releases intéressantes ayant eu lieu ce mois-ci :

• AMI de Deep Learning d’AWS : L’image (AMI) mise à disposition par Amazon et embarquant une installation fonctionnelle des principaux outils de Machine Learning est désormais disponible sous une nouvelle version embarquant Apache MXNet v0.10 and TensorFlow v1.1.
• CoreDNS-008 : Un des changements notables de cette release est l’abandon de logging vers un fichier; désormais, comme toute application 12factor-compliant, CoreDNS ne loggera que vers sa sortie standard. On notera également l’ajout de la notion de prefetch au cache, permettant de re-récupérer un record DNS avant l’expiration de son TTL.
• Gitlab 9.3 : Avec cette nouvelle version, Gitlab nous propose en nouveautés phares l’intégration de la qualité de code et la gestion de pipelines multi-projets pour Gitlab CI. Pour le reste, et comme ils nous y ont habitué, de nombreuses autres nouveautés et améliorations sont disponibles dans l’annonce de cette version !

Il nous semble clair que l’industrie de l’informatique s’est finalement mis d’accord sur trois choses :

1. Nous avons besoin de faire du code de qualité
2. Il faut intégrer le code de manière continue
3. Il faut superviser ce que nous installons

Les pratiques du craftsmanship, en particulier le refactoring, couplées à un ensemble d’outils de test permettent d’affronter le premier. La construction de pipelines d’intégration avec des usines comme Jenkins, GoCD ou TravisCI permettent d’attaquer le deuxième. Cependant, la supervision, la situation n’est pas aussi claire. Du coup, il existe une grande variété de fonctionnalités (stack) pour superviser la JVM, suivre des métriques métiers, gérer des alertes, etc. La popularisation des architectures distribuées (dont les microservices) n’a fait qu’empirer la problématique.

Pour résoudre tous ces problèmes, nous avons choisi une stack composée de Prometheus, CAdvisor et Grafana et nous allons vous montrer comment les utiliser pour superviser une application de site web basée sur Play! framework.

Le choix de la stack de supervision

Finalement, nous avons terminé notre application Play!. Nous avons fait nos tests et notre chaîne d’intégration continue et l’application est même installée dans l’environnement de UAT (User Acceptance Testing). C’est à ce moment-là que nous réalisons que nous n’avons pas pensé à la supervision !

Après une rapide recherche, nous trouvons qu’il existe en fait deux modèles de communication : le push et le pull. Dans le modèle push, l’application monitorée envoie régulièrement ses métriques à l’outil de monitoring. Typiquement, il existe entre l’application et l’outil de monitoring un agent intermédiaire qui est chargé de la collection des métriques. Dans le modèle pull, c’est l’outil de monitoring qui connaît les applications monitorées et les requête à une fréquence spécifique.

En approfondissant notre recherche nous trouvons plusieurs alternatives :

Les alternatives

1. Telegraf + InfluxDB

C’est une stack basée sur une architecture de push.

Telegraf est un agent qui récupère et exporte des métriques vers un système de stockage comme InfluxDB. InfluxDB est une base de données de type time series utilisée pour le stockage de métriques.

Ces deux outils sont en général utilisés avec Kapacitor. Il fait le pilotage des données et la gestion des alertes. Pour exemple, Kapacitor permet d’évaluer une métrique dans une fenêtre de 5 ms, la compare avec un seuil puis envoie une alerte sur Slack.

2. Statsd + Graphite

Également, cette stack est basée sur une architecture de push.

Statsd est un agent réseau (UDP et TCP) qui permet d’écouter des statistiques et de les envoyer vers un autre système comme Graphite.

Graphite est capable de stocker des données de type time series (c’est-à-dire qu’elles sont ordonnées dans le temps) et fournit également un langage de requêtage. Il présente une approche similaire à celui de Telegraf et InfluxDB. L’ajout des informations complémentaires est basée sur la création des nouvelles métriques. Les deux métriques suivantes permettent de compter le nombre de requêtes en succès ou en erreur pour le path /login

stats.api-server.login.get.200 -> 93
stats.api-server.login.get.500 -> 45

Un exemple de l’intégration de graphite se montre comme suit

3. Nagios

Cette stack est basée sur un modèle de pull.

Nagios est un outil spécialisé surtout sur le monitoring de l’infrastructure. Il est donc plutôt utilisé comme une alternative à sensu. Il comporte un nombre important de plugins mais il ne fait pas le stockage des données, nous devons donc recourir à d’autres outils pour gérer la persistance.

Le monitoring d’une application basée sur la JVM (comme Play!) se fait typiquement en utilisant JMX ou en s’intégrant avec statsd.

4. Prometheus

Encore une autre stack qu’utilise une approche de pull.

Prometheus est un système de monitoring et d’alerting. L’approche pull nous intéresse énormément parce que nous pouvons maîtriser les données métier que nous voulons rendre publiques dans les applications de monitoring. En fait pour Prometheus, la seule contrainte imposée à l’application monitorée est d’être capable de produire du texte avec HTTP. Avec cet outil, il est possible d’ajouter des ensembles de clés-valeurs pour rendre le monitoring plus dynamique. La métrique suivante est donc parfaitement valide :

http_request_duration_seconds_bucket{le="0.02",method="GET",path="/assets/:file",status="2xx"} 23

Une vision à plus haut niveau sur l’intégration d’une application avec Prometheus est montrée dans l’image suivante :

Cet outil va rester notre choix pour le reste de cet article.

La visualisation

Cependant, il nous reste à choisir l’outil pour la visualisation de nos métriques. Les alternatives les plus utilisées sont :

• Kibana + Timelion. Kibana est l’outil de visualisation par défaut dans Elasticsearch. Timelion permet l’intégration de timeseries dans Kibana. Ensemble, ces outils aident à la visualisation mais surtout à l’analyse et l’exploration des données au travers de multiples dimensions.
• Grafana. Cet outil a été conçu pour faciliter la visualisation de dashboards complexes basées sur des sources timeseries.

Dans notre exemple, nous n’avons pas besoin d’explorer les données et nos dashboards ne sont pas destinés à un utilisateur final. Ce qui nous intéresse est de pouvoir afficher les métriques, vérifier l’état de santé de notre application et dans le futur, pouvoir créer des alarmes. Grafana sera par conséquent l’outil choisi pour la visualisation de nos métriques.

Les métriques exposées par l’application basée sur Play! Framework

Pour pouvoir exposer les métriques depuis notre application, il nous faut importer une librairie cliente. Nous avons choisi ce client non officiel pour Scala car il s’adapte un peu mieux à la philosophie compile time safe de Scala, mais nous aurions également pu utiliser le client officiel. Pour l’utiliser dans le projet il suffit de l’ajouter dans le fichier build.sbt

libraryDependencies += "org.lyranthe.prometheus" %% "client" % "0.9.0-M1"

L’exposition des métriques

class PrometheusMetricBuilder @Inject()(lifecycle: ApplicationLifecycle, implicit val prometheusRegistry: Registry) { 
  def buildOutputText: String = prometheusRegistry.outputText // prints all metric values
  ... // other metrics
}

@Singleton
class PrometheusMetricsController @Inject()(metricBuilder: PrometheusMetricBuilder) extends Controller {
  def metrics = Action {
    val samples = new StringBuilder()
    val writer = new WriterAdapter(samples)
    writer.write(metricBuilder.buildOutputText)
    writer.close()

    Result(
      header = ResponseHeader(200, Map.empty),
      body = HttpEntity.Strict(ByteString(samples.toString), Some("text/plain"))
    )
  }
}

Nous pouvons exposer ce traitement dans le path que nous souhaitons. L’url /metrics semble être une bonne idée. Rajoutons-là à notre fichier routes.

GET     /metrics                    controllers.PrometheusMetricsController.metrics

Nous n’allons pas rentrer dans le détail des types de métriques, le but étant de rechercher une solution rapide pour les premières métriques de notre nouvelle application. Nous proposons alors les trois métriques suivantes :

Les métriques

1. Le nombre de visites dans l’application

Supposons que nous voulions monitorer le nombre absolu de visiteurs. Notre objectif est de pouvoir nous donner une idée du succès de notre site. Celui-ci est un nombre qui augmentera toujours. Pour créer cette métrique il suffit de construire une instance de type Counter et l’enregistrer auprès d’un Registry de métriques fourni par le client de Prometheus.

@Singleton
class PrometheusMetricBuilder @Inject()(lifecycle: ApplicationLifecycle, implicit val prometheusRegistry: Registry) {
  ...
  val counter = Counter(metric"play_requests_total", "Total requests.").labels().register
  ...
}

Ensuite, nous pouvons l’utiliser dans notre contrôleur.

@Singleton
class HomepageController @Inject()(builder: PrometheusMetricBuilder) extends Controller {
  def index = Action {
    builder.counter.inc()
    Ok(views.html.index("Your new application is ready."))
  }
}

2. Le nombre d’utilisateurs connectés

Le nombre d’utilisateurs connectés est une métrique qui doit pouvoir s’incrémenter et se décrémenter par rapport au nombre de connexions et déconnexions, voire des abandons de page. Prometheus appelle ce type de composant un Gauge. Nous devons également écouter le hook (l’envoi du message) de finalisation de l’application pour prendre en compte les utilisateurs qui ferment leur navigateur. Pour cela nous avons une instance de l’ApplicationLifecycle qui nous donne un callback lors de l’arrêt de l’application. Nous allons procéder de manière similaire à la métrique précédente.

@Singleton
class PrometheusMetricBuilder @Inject()(lifecycle: ApplicationLifecycle, implicit val prometheusRegistry: Registry) {
  ...
  val gauge = Gauge(metric"play_current_users", "Actual connected users").labels().register
  lifecycle.addStopHook { () => Future.successful(gauge.dec()) }
}

Par contre, la logique de ce contrôleur est plus complexe car nous devons augmenter la valeur lors du login, et la réduire lors du fermeture de la session.

@Singleton
class SessionController @Inject()(builder: PrometheusMetricBuilder) extends Controller {
  def login = Action {
    builder.gauge.inc()
    Ok("Logged in ...")
  }
  def logout = Action {
    builder.gauge.dec()
    Ok("Logged out!")
  }
}

3. Le temps de réponse par url

Le temps de réponse est typiquement analysé grâce aux échantillons pris pour chaque route disponible dans notre application. Dans la terminologie de Prometheus, ce type de métrique est appelé un histogramme.

Pour effectuer l’échantillonnage, nous devons créer un filtre qui met à jour un composant de type Histogram avec les informations suivantes:

• La méthode HTTP
• Le path
• Le status de la réponse
• Le temps de réponse

Il suffit d’ajouter le composant dans notre PrometheusMetricBuilder :

@Singleton
class PrometheusMetricBuilder @Inject()(lifecycle: ApplicationLifecycle, implicit val prometheusRegistry: Registry) {
  ...
  val httpRequestLatency =
    Histogram(metric"http_request_duration_seconds",
      "Duration of HTTP request in seconds")(httpHistogramBuckets)
      .labels(label"method", label"path", label"status")
      .register
  ...
}

Nous pouvons écrire ce filtre comme suit :

class PerformanceFilter @Inject()(implicit
                                  val mat: Materializer,
                                  builder: PrometheusMetricBuilder,
                                  executionContext: ExecutionContext
                                ) extends Filter {
  ...
  def apply(nextFilter: RequestHeader => Future[Result])(
    requestHeader: RequestHeader): Future[Result] = {
    val timer = Timer()
    val future = nextFilter(requestHeader)
    getRouteDetails(requestHeader) match {
      case Some(details) =>
        future.onComplete {
          time(timer) { statusCode =>
            builder.httpRequestLatency.labelValues(
              details.method,
              details.route,
              statusCode)
          }
        }

      case None =>
        // rien à faire ici
    }
    future
  }
}

play_current_users 0.0
play_requests_total 1.0
http_request_duration_seconds_bucket{le="1.0E-4",method="GET",path="/",status="2xx"} 0
http_request_duration_seconds_bucket{le="0.005",method="GET",path="/metrics",status="2xx"} 0
http_request_duration_seconds_bucket{le="0.01",method="GET",path="/metrics",status="2xx"} 1

Tester en local avec docker-compose

Pour éviter de tout installer en local, nous fournissons un repository Github avec la configuration initiale basée sur docker-compose qui vous permettra de démarrer toute l’infrastructure que nous venons de décrire :

• Un container pour Prometheus
• Un container pour CAdvisor
• Un container pour l’application avec le framework Play!
• Un container pour Grafana

Pour tout démarrer, il suffit d’exécuter :

docker-compose up -d

Une fois terminé, vous devriez avoir quatre containers :

Ces differents containers sont liés de la manière suivante :

CAdvisor

Le Container Advisor permet d’exposer la consommation des resources des container docker. Vu que nous allons utiliser Pometheus et d’autres composants dans docker, CAdvisor semble une très bonne idée car il est nativement capable d’exposer des métriques sur la consommation réseau, mémoire et disque vers Prometheus. Si nous allons à  http://localhost:8080/containers/ nous allons voir un résultat similaire à celui-ci :

La configuration de Prometheus

La configuration de Prometheus est basée sur un fichier nommé prometheus.yml dans lequel nous devons spécifier les endpoints de ce que nous allons monitorer. Chacun peut avoir sa propre configuration contenant le target (combinaison hôte et port), le path url où l’application expose ses métriques, l’intervalle d’évaluation et d’autres options si nécessaire.

global:
  scrape_interval:     15s
  evaluation_interval: 15s
  external_labels:
    monitor: 'monitoring-play-app'
scrape_configs:
  - job_name: 'prometheus'
    scrape_interval: 5s
    static_configs:
      - targets: ['cadvisor:8080']
  - job_name: 'playframework-app'
    scrape_interval: 5s
    metrics_path: '/metrics'
    static_configs:
      - targets: ['play-app:9000']

Vu que nous lions les conteneurs entre eux, il est possible d’utiliser le nom de notre container en tant qu’adresse IP. L’exemple précédent permet de monitorer trois services :

• CAdvisor. Qui tourne dans un container appelé cadvisor sur le port 8080.
• notre application Play!. De manière similaire, notre application est disponible à l’url play-app:9000.

Pour vérifier que nos targets sont bien prises en compte il nous suffit de vérifier directement sur Prometheus à l’adresse http://localhost:9090/targets. Ici, nous utilisons localhost pour parler avec le container parce nous sommes sur linux. Vous obtenez le même résultat si vous utilisez Docker for mac ou Docker for windows.

Il est également possible de requêter nos métriques sur http://localhost:9090/graph. Dans cette page nous pouvons :

Vérifier que nos métriques sont bien prises en compte. Vérifier que les métriques se modifient dès que nous requêtons notre application Play! Tester des opérations de regroupement (sommes, moyennes, et autres)
Prévisualiser nos métriques

Cependant, ceci n’est pas vraiment un outil de visualisation et pour cela nous avons besoin d’un logiciel spécialisé.

Grafana

La suite de visualisation de métriques Grafana va nous permettre de suivre en temps réel les métriques de notre application. L’interface est accessible depuis http://localhost:3000.

Nous allons créer une data source pour pouvoir interroger le service de Prometheus, afin de lier nos métriques à la visualisation de Grafana.

Ensuite, nous devons ajouter un dashboard qui affichera les métriques exposées des targets de Prometheus. Heureusement, dans le repository Github nous fournissons un dashboard prêt à l’emploi. Il permet la visualisation des métriques envoyées par notre application et ceux de CAdvisor. Il suffit alors d’importer le fichier Grafana_Dashboard.json. Une fois installé, nous avons un panel qui montre le résultat de nos métriques de visites et d’utilisateurs connectés.

Nous devons avoir également un histogramme avec le temps de réponse des url de notre application :

De plus, grâce au CAdvisor nos avons des métriques de consommation de mémoire, processeur et disque de tous nos containers :

Et voilà, nous avons finalement un outil de monitoring intégré à notre application.

Conclusion

Nous avons abordé les différences entre les modèles push et pull pour la communication avec les outils de monitoring, puis nous avons comparé quelques outils et finalement nous avons choisi Prometheus.

Ensuite, nous avons montré comment exposer des métriques sur un endpoint depuis une application basée sur Play! framework. Finalement nous avons montré le résultat final avec un docker-compose contenant entre autre un dashboard Grafana pour le suivi en temps réel des métriques.

Nous pouvons conclure qu’au final, les outils qui permettent d’avoir des métriques sont maintenant assez simples d’utilisation.

Quelques problèmatiques restent toujours ouvertes comme par exemple la manière d’intégrer de multiples instances de notre application ou l’intégration d’un système d’alertes. Nous aborderons ces sujets lors d’un prochain article.

La revue de presse hebdomadaire des technologies Big Data, DevOps et Web, architectures Java et mobilité dans des environnements agiles, proposée par Xebia.

Agilité

Les neurosciences et le management

Par Gaël Rebmann

Cet article de HBR nous fournit une introduction sur l’utilisation des neurosciences dans notre management. Plus que d’utiliser des outils et des règles préétablies (telles que les moving motivators de Jurgen Appelo), les neurosciences nous promettent la possibilité de comprendre le fonctionnement du cerveau et ainsi de mieux cerner les besoins de nos collaborateurs. La maîtrise de cette science permet alors d’améliorer ces outils et ces règles de management. C’est en tout cas ce que nous promet cet article !

Mobilité

Comparaison entre ARKit et ARCore

Par Jose Antonio Martin Sanchez

Suite à la présentation de ARKit par Apple, Google n’a pas trainé les pieds et il vient de présenter sa toute nouvelle plateforme de réalité augmentée baptisée ARCore. Basée sur la plateforme Tango, elle essaie de contrer l’enthousiasme provoqué par le nouveau framework de la marque à la pomme. Dans cet article, l’auteur Matt Miesnieks décortique les points forts et les points faibles de chaque technologie.

ARCore, la réponse de Google face à Apple et son ARKit

Par Souhaib Guitouni

Google va désormais se concentrer sur ARCore et abandonner progressivement le projet Tango.

Avec une flotte de plus de 100 millions d’appareils compatible à la fin de sa phase de bêta, Google vise à démocratiser l’accès à la réalitée augmentée sous sa plateforme Android. ARCore détermine la position et l’orientation du téléphone pendant qu’on le manipule. Les objets virtuels restent ainsi en place il peut aussi détecter les surfaces horizontales, comme les tables ou les sols, où placer les objets virtuels. Il permet même de mesurer la lumière ambiante afin de permettre aux développeurs d’éclairer les objets virtuels d’une manière réaliste

ARCore mesure la lumière ambiante afin de permettre aux développeurs d’éclairer les objets virtuels d’une manière réaliste.

Les applications comme SnapChat vont-elles s’emparer de ces nouveaux supports pour apporter encore plus de réalisme aux utilisateurs ?

Bientôt des snaps avec vos dragons domestiques de GOT !

IoT

Module LoRaWAN avec Connectivité SigFox

Par Yassir Sennoun

DevOps

Mise en place d’un SSL en toute simplicité

Par Sarah Buisson

 Voici un tutorial  pour mettre en place rapidement, facilement et gratuitement un certificat SSL/TLS (Secure Socket Layer – vous savez, les url en https avec un petits cadenas ) sur vos serveurs publics, le tout grâce à SSL for Free.

La revue de presse hebdomadaire des technologies Big Data, DevOps et Web, architectures Java et mobilité dans des environnements agiles, proposée par Xebia.

Mobile

Android – The rise of Kotlin

Par Thomas Depinoy

Kotlin est un langage qui gagne en popularité depuis quelque temps déjà.

Depuis, la Google IO et l’annonce du support officiel de Kotlin sur Android, ce gain de popularité explose comme nous le montre Realm avec des statistiques intéressantes.

IoT

API.AI c’est fini, il faut maintenant dire Dialogflow

Par Benjamin Lacroix

Google a décidé de renommer son service API.AI en Dialogflow. Initialement conçu comme une API pour ajouter le traitement du langage dans une application, Dialogflow fait bien plus et se définit comme une plateforme complète pour construire des applications proposants une excellente expérience conversationnelle.

Deux nouveautés sont également annoncées :

1. la possibilité d’écrire des fonctions (fulfillment logic) directement dans la console
2. le support multi-langue avec l’ajout de langues et de locales différentes

Craftsmanship

Java: Free at last

Par Diana Ortega

Mike Milinkovich directeur exécutive de la fondation Eclipse a écrit dans son blog « Java: Free At Last », où il analyse une partie des annonces faites début septembre par Mark Reinold et Donald Smith de Oracle.

Les annonces parlent de l’implémentation de releases périodiques du jdk, mais Milinkovich se focalise sur le détail que java deviendrait finalement « free ».

Aujourd’hui les binaires java sont distribués sous la licence « Oracle Binary Code License », mais Oracle a l’intention de les mettre directement avec l’OpenJDK sous licence GPL.

Pour plus d’information vous pouvez voir l’article de Micke Milinkovich. 

Front

Migration d’une base de code en React 16

Par Alban Dauleu

React 16, attendu depuis longtemps par la communauté, est disponible depuis le 26 Septembre dernier et a apporté bon nombre d’améliorations. Dès lors, de nombreux développeurs ont franchi le pas et attaqué la migration de leur base de code. C’est le cas de Michael Greer, qui décrit dans son article les leçons qu’il a tiré de la migration en React 16.

Back

Server-Sent Events

Par Xebia

Dans sa version 5, Spring nous propose une alternative aux web-sockets pour notifier le front des changements coté server : les Server-Sent Events (ou SSE).

Cet article nous présente que sont les SSE et nous explique comment mettre en place dans votre application Spring.

Node.js 8.5

Par Antoine Le Taxin

Une nouvelle release de Node.js vient de sortir !
Principales ajouts à cette version :

• La prise en charge native des imports de modules ESM grâce au tag –experimental-modules.
• L’implémentation d’une Performance Timing API.
• La possibilité d’avoir accès, via la stack, aux traces des évènements async. 
• Une méthode qui permet de directement copier des fichiers grace au module fs.
  

Pour le détail, voir le change log complet, ou une revue par Rising Stack des principales features avec des exemples.

DevOps

Terraform publie son registre de modules

Par Sergio Dos Santos

Terraform est un outil génial qui permet de décrire, créer, modifier et supprimer une infrastructure. Dans ce billet de blog, Hashicorp annonce l’ouverture de son registre de modules.

Les modules sont des templates de ressources pouvant être instanciés avec un paramétrage adapté. Ils pouvaient jusqu’alors être importés depuis des fichiers locaux ou même depuis des dépôts git, github, …

module "my-vpc-1" {
  source = "./modules/vpc"
  cidr = "10.0.0.0/16"
  ...
}
 
module "my-vpc-2" {
  source = "github.com/my-company/my-infra/modules/vpc"
  cidr = "10.0.0.0/16"
  ...
}

Il est désormais possible de les importer directement depuis le registre de modules Terraform.

module "my-vpc" {
  source = "terraform-aws-modules/vpc/aws"
  cidr = "10.0.0.0/16"
  ...
}

Quels sont les apports du registre ? Il apporte en premier lieu la possibilité de dépendre d’une version spécifique d’un module (compatible avec la prochaine release de terraform). Le registre fournit surtout un point d’entrée unique pour la recherche de modules et documente les entrées, sorties et ressources créées de manière homogène.

Certains modules publiés sont vérifiés par Hashicorp et ses partenaires, d’autres sont librement fournis par la communauté. Ne réinventez plus les mêmes templates d’infrastructure encore et encore, cherchez et vous les trouverez – peut-être – et si le coeur vous en dit, publiez les !

Le coin de la technique

Comment conduire un entretien technique

Par Xebia

Les entretiens! Nous avons tous déjà été interviewés, nous avons tous des trucs, astuces et histoires à raconter. Moins connu est l’autre coté de la négociation: le point de vue de l’interviewer. Dans cet article, Gregory Brandon nous explique comment conduire un entretien technique.

Comme promis, Docker n’a pas tardé à publier l’ensemble des vidéos de la DockerCon 2017 à Copenhague.

Et puisque vous n’avez probablement pas 6 jours à consacrer à leur visionnage intégral, voici notre petite sélection, complètement subjective :

La première session générale

Foncez directement à 58’55 pour voir l’intervention la plus réussie, celle de Solomon Hykes. Et la démo de David Gageot à 1’16’48.

Les Black Belt

1. How and Why Prometheus’ New Storage Engine Pushes the Limits of Time Series Database, Goutham Veeramachaneni
2. LinuxKit Deep Dive, Rolf Neugebauer
3. Deeper Dive in Docker Overlay Networks, Laurent Bernaille
4. Kubernetes on Docker, Daniel Hiltgen et Alex Mavrogiannis

Quelques autres sessions :

1. Looking Under The Hood: containerD, Scott Coulton
2. Creating Effective Docker Images,  Abby Fuller
3. Small, Simple, and Secure: Alpine Linux under the Microscope, Natanael Copa
   
4. My Journey to Go, Ashley McNamara
5. Et le grand éclat de rire de la conférence : Rock Stars, Builders, and Janitors: You’re Doing it Wrong, Alice Goldfuss

Il y a maintenant 1 mois, j’ai eu la chance d’aller au RustFest, une conférence sur le langage Rust s’étant tenue à Zürich. Cet article est un retour sur les conférences que j’ai pu y voir, d’un point de vue très personnel et y incluant mes propres opinions.

Ce RustFest 2017 était composé de conférences le samedi, et d’ateliers le dimanche. La journée du samedi ayant été relativement dense, avec pas moins de 14 talks successifs sur une seule track, je vais tenter ici de vous résumer les points principaux ayant retenu mon attention, et me permettrai de passer sous silence les points non pertinents afin d’éviter de vous faire perdre votre temps.

tl;dr : rendez-vous à la conclusion en fin d’article !

Keynote: A RustFest Carol

• Speaker : Felix Klock (@pnkfelix) – Research Engineer @ Mozilla
• Vidéo
• Slides

Felix Klock débute la journée en nous présentant un historique de Rust via une narration sous forme de conte. L’objectif ? Nous présenter les principaux points d’évolutions de Rust, que ce soit dans le langage lui-même ou ses bibliothèques principales telles que Serde, et ce depuis les prémices de Rust jusqu’à aujourd’hui, avec comme message principal « ne pas avoir peur du changement ».

Pour ceux qui voudraient le rencontrer, Felix est quelqu’un de très sympathique avec beaucoup de recul sur Rust et il organise le meetup Rust Paris; n’hésitez donc pas à aller y faire un tour !

Rust: an alternative to high-level programming languages?

• Speaker : Élisabeth Henry (@lise_henry / @crowdagger) – Fantasy novel writer
• Vidéo
• Slides

Ce second talk apporte un point de vue très intéressant : celui d’un utilisateur « haut niveau » de Rust. L’utilisateur en question ? Une utilisatrice : Elisabeth Henry, auteure française, qui se sert de Rust pour transformer ses livres qu’elle écrit en Markdown vers du HTML et PDF (ce qui me fait vraiment penser à Pandoc mais là n’est pas la question) !

Le profil n’est donc pas celui de quelqu’un qui attache une grande importance au langage en lui-même, mais vraiment à son utilisation.

Pour commencer, elle nous présente sa définition de « high level » : des outils en ligne de commande, applications graphiques, petits jeux, etc., dans lesquels ni la performance ni la stabilité ne sont des problématiques critiques. Des applications sans réel besoin d’interactions bas niveau, et sur lesquelles ont se situerait donc plus au niveau de Java/Python/Ruby en terme de comparaison de cas d’usage.

Elle dresse ensuite un portrait ma foi assez réaliste des langages impératifs : la plupart permettent de faire rapidement et facilement émerger un résultat, mais en autorisant bien souvent d’arriver à ce résultat un peu n’importe comment (« the wrong way »). Les plus populaires sont faciles à prendre en main, mais cachent en réalité beaucoup de complexité, ce qui ne rend pas les choses plus simples sur le long terme.

Malgré son utilisation haut niveau, Élisabeth a pris le temps de comprendre la  notion de références de Rust, qui peuvent être soit partagées, soit mutables, mais pas les deux ! Au final, Rust lui apporte vraiment de la memory safety et évite les data races, et même un utilisateur haut niveau fini par se rendre compte de ces avantages.

Pour résumer : en comparaison à la plupart des langages impératifs, Rust s’avère bénéfique sur le long terme plutôt que le court terme. En effet, la courbe d’apprentissage du langage a beau être relativement raide, le jeu en vaut la chandelle et le langage rend les choses bien plus faciles par la suite, imposant une certaine rigueur qui facilite notamment la gestion des anomalies, la maintenance, ou encore l’acceptation des contributions, et ce dans la mesure où il est presque ardu de faire des erreurs d’implémentation. Au final, les alternatives sur ces avantages seraient les langages fonctionnels qui n’autorisent pas du tout de mutations, mais qui sont moins répandus et potentiellement plus complexes encore à prendre en main.

Macromancy – an introduction to Rust macros

• Speaker : Geoffroy Couprie (@gcouprie) – Security & QA @ CleverCloud
• Vidéo

Talk très intéressant sur les macros en Rust… mais de mon point de vue, qui en présente une utilisation impossible à maintenir et tellement loin de l’esprit craftsmanship que je ne m’attarderai pas dessus malgré le côté séduisant de faire le plus de choses possibles lors de la compilation. Les points principaux évoqués sont : macros récursives, imbriquées, et trace macros pour afficher l’expansion des macros.

En résumé : les macros de Rust permettent de faire énormément de choses… presque trop.

Impractical Macros

• Speaker : Alex Burka (@durka42)
• Vidéo

Pour appuyer le talk précédent, Alex Burka nous a présenté un interpréteur Brainfuck en pures macros Rust, donc capable de comprendre et d’exécuter du code Brainfuck à la compilation.

Bien que très intriguant et démonstratif, ce talk n’a pas vraiment de raison d’être détaillé, sachez juste que c’est possible… For science!

Antimony: a real time distributed stream processing system

• Speakers :
  • Mohammed Makhlouf (@msmakhlouf) – Software/Security Engineer @ Qatar CERT
  • Mohammad Samir (@_msamir_)
• Vidéo
• Slides
• Site web – antimony.rs

Mon point de vue sur ce talk est relativement mitigé. Il nous a été présenté un système d’analyse temps réel de requêtes DNS en Rust basé sur Apache Storm afin de détecter des malwares, par exemple via des noms de domaines connus ou proches, ou via des critères tels que la longueur.

Le talk pourrait se résumer en « On a pris Apache Storm, on a surchargé nos cluster Zookeeper, et on a fini par drastiquement sur-provisionner TOUT et par lancer chaque topologie sur un cluster Storm séparé avec des clusters Zookeeper séparés ». Mention honorable cependant pour pyleus, le framework Python de Yelp pour développer et gérer des topologies Storm. Très peu de Rust donc, même si la présentation de l’architecture mise en place et des problématiques inhérentes reste intéressante.

Au final, la partie la plus intéressante reste sans doute la mention du papier « Héron » de Twitter sur le stream processing, ainsi que la rapide mention des bibliothèques Tokio et Mio pour les IO asynchrones en Rust, sur lesquelles je reviendrai plus tard.

Testing strategies and pattern for efficient TDD in Rust

• Speaker : Thomas Wickham (@mackwic) – Consultant @ Octo
• Vidéo
• Slides

Je ne suis pas très objectif sur ce talk ; en effet, le speaker est un ami ! Mais vu qu’il s’agit d’un talk plus sur le côté TDD que l’aspect Rust, je pense que vous pourrez en retrouver la majorité sur le reste du blog ou sur son podcast café-craft.

Élément principal côté « TDD en Rust » à retenir : au final le compilateur vérifie déjà tellement de choses et garanti une telle safety par les contraintes qu’il impose que les tests en sont relativement réduits et qu’on peut se concentrer sur les points vraiment utiles plutôt que d’avoir des tonnes de « edge cases ». Par ailleurs, Rust a tendance à faciliter la gestion des cas d’erreurs, ce qui permet de faire émerger un design solide et complet.

A Rust-based Runtime for the Internet of Things

• Speaker : Niklas Adolfsson (@niklasad1) – Embedded software developer @ Cybercom
• Vidéo
• Slides
• Site web – tockos.org
• PDF de la thèse sur le sujet

Ce talk nous présentait TockOS, un OS écrit en Rust pour tout ce qui est IoT : semblant de micro-kernel, isolation mémoire, processus en user-space, …

Pourquoi Rust dans un tel contexte ?

• Memory safety et type safety
• Contrôle fin sur la mémoire
• Très peu d’overhead au runtime

Le design de l’OS lui même et des éléments écrits en Rust est disponible dans la documentation de TockOS.

Au final, Rust permet d’avoir exactement ce qu’on cherche sur de l’IoT : de la fiabilité, du contrôle bas niveau et une très faible consommation de ressources.

A hammer you can only hold by the handle

• Speaker : Andrea Lattuada (@utaal) – Researcher @ ETH Zürich
• Vidéo
• Slides

Cette présentation d’Andrea Lattuada était de mon point de vue tout simplement géniale. Elle abordait sous un angle limpide les notions d’ownership et de borrow de variables en Rust, qui sont souvent les notions les plus ardues à « prendre en main » lorsque l’on débute avec le langage.

Ce n’est par conséquent pas vraiment un talk facile à résumer, sans vous renvoyer vers la documentation de Rust… Mais pour préciser un peu, il a réalisé une analogie très intéressante de l’allocation d’objets et de la gestion de leur durée de vie ainsi que l’accès concurrentiel par rapport à une lettre que l’on souhaiterait envoyer :

• Enveloppe = type Option contenant potentiellement une lettre
• Lettre = struct
• Shipping = méthode utilisant l’enveloppe.

Avec cet exemple, il a démontré comment les primitives du langage nous permettent d’avoir une garantie d’« exactly once » sur certains appels, une garantie d’ordre ainsi qu’une garantie de drop/free.

Fearless concurrency in your microcontroller

• Speaker : Jorge Aparicio (@japaricious) – Self-proclaimed roboticist
• Vidéo
• Slides

Ce talk présentait une gestion bas niveau de la concurrence en Rust, avec comme fil rouge la problématique suivante :

• Tâche 1 : doit se lancer toutes les 10ms et prend 2ms à s’exécuter
• Tâche 2 : doit se lancer toutes les 1ms et prend 100µs à s’exécuter
• Est-il possible de respecter ces contraintes en utilisant du multitasking coopératif ?

Au final, la problématique n’est pas spécifique à Rust, mais le langage permet de la résoudre en restant complètement memory safe, avec une absence de deadlocks, et des data races détectées à la compilation. Tout ça sur des microcontrôleurs d’un seul cœur, sans avoir à se reposer sur un garbage collector; soit exactement le type de points positifs  dont on souhaiterait bénéficier lorsque l’on travaille avec des microcontrôleurs !

Le blog post réalisé bien avant ce talk par son auteur vous donnera bien plus de détails que ce que je ne serais capable d’inclure dans ce résumé.

Mistakes to avoid when writing a wrapper around a C library

• Speaker : Pierre Krieger (@tomaka17) – Graphics programmer
• Vidéo
• Slides (sources)

Rust étant régulièrement comparé à « du C, mais en plus safe », il est logique de se retrouver avec des besoins communs. Mais plutôt que de réimplémenter intégralement les bibliothèques bas niveau en C, un choix souvent fait est celui de wrapper ces bibliothèques C avec du Rust afin d’exposer une API plus safe sans pour autant réimplémenter toute la logique.

Ce talk présentait 9 « erreurs » à éviter lors du wrapping d’une bibliothèque C en Rust, et en voici le résumé :

Cliquez ici pour découvrir les 9 erreurs à éviter

Un talk plein de bon sens, qui nous rappelle les problèmes de sûreté du C et qui nous donne des pistes pour les éviter.

Conclusion sur ce talk : lire le Rustonomicon !

Rust In Rhymes

• Speaker : Andre Bogus (@llogiq)
• Vidéo

Que dire… Ce talk était un véritable show, entièrement en rimes, avec comme principal intérêt le fait de se décontracter après un slot bien technique.

Du coup, il n’y a pas grand chose à en résumer à l’écrit, et son appréciation dépendra grandement de votre humour ! Si vous souhaitez vous laisser tenter, le lien vers la vidéo est un peu plus haut.

Create Rust games easily

• Speaker : Lisa – Product team @ Travis CI
• Vidéo

Honnêtement, ce talk bien qu’intéressant m’a un peu déçu. Du live coding à base de copier/coller, trop rapide pour être réellement suivi, et avec un résultat final relativement minimal.

SHAR: Rust’s gamedev experience

• Speaker : Fedor Logachev – Game programmer
• Vidéo
• Site web – SHAR project

Retour plus intéressant que le précédent… mais la partie jeu vidéo est un peu trop spécialisée pour que je sois à même de la critiquer; si vous voulez en savoir plus n’hésitez pas à jeter un œil à la vidéo !

Type-safe & high-perf distributed actor systems with Rust

• Speaker : Anselm Eickhoff (@ae_play) – Computer science dentue
• Vidéo
• Github – Citybound

LA surprise de cette fin de journée. Concrètement, tout est dans le titre, et le talk était une énorme démonstration du résultat avec explications sur l’implémentation. Globalement : création d’un simulateur de ville à base d’Acteurs distribués, en Rust, avec des performances vraiment impressionnantes.

Pour être honête, je n’ai pas pris énormément de notes tellement le talk était passionnant. Je vous invite cependant à en regarder la vidéo dont le lien est disponible ci-dessus et qui en vaut le détour ! La partie intéressante était plus la logique en elle-même que ce qui est fait en Rust ; le point à retenir sur Rust étant la possibilité d’implémenter un tel design d’acteurs distribués de manière vraiment propre et solide notamment grâce à la type-safety fournie par Rust, le tout avec un résultat performant.

Async I/O and Tokio

• Speaker : Alex Crichton – Rust developer
• Vidéo
• Slides
• Site web – tokio.rs
• Article sur l’implémentation des Futures en Rust

Ce talk est le seul ayant eu lieu le dimanche matin avant les ateliers.

Pour contexte, Alex Crichton est un des Core développeurs de Rust ayant été employé pendant 4 ans par Mozilla pour travailler sur le langage et son compilateur. C’est aussi un des principaux auteurs de Cargo, le gestionnaire de dépendances de Rust, ainsi qu’un des mainteneurs de la lib standard de Rust et de Tokio, LA bibliothèque pour des I/O asynchrones en Rust, sur laquelle cette présentation portait justement.

Ce talk, contrairement à ce qui pourrait sembler à la lecture du titre, n’est PAS une présentation de « comment faire de l’async avec Tokio », mais plutôt… « comment on implémente de l’async, en vrai ? ». En effet, c’est super d’avoir de l’asynchrone en tant qu’utilisateur, mais quels sont les mécanismes utilisés derrière ? Cette approche en fait donc définitivement le talk le plus intéressant de ce RustFest, ce qui en fait une très belle clôture mais aussi quelque chose de difficile à vraiment résumer.

Commençons par le début : qu’est ce que Tokio ?

• Tokio = Mio + Futures
• Mio = « Metal I/O », une bibliothèque d’I/O cross-platform en Rust
• Futures = pensez aux « promises » de JS mais côté Rust (il s’agit en réalité du même pattern Future/Promise): il s’agit de sentinelles pour des valeurs « en cours de calcul ». En interne, une Future capture un état pour finir par produire une valeur. Les Futures dans Rust sont implémentées sous forme de Traits et sont composables.

Ceci étant posé, qu’est-ce que Tokio fait en réalité ? Un exemple d’utilisation abstrait serait le suivant :

1. Utilisateur : « Je voudrais le contenu de https://blog.engineering.publicissapient.fr/ »
   
2. Tokio : « OK, tiens, voilà un Future<Vec<u8>> »


Cette Future contiendra alors le résultat lorsque le contenu aura été récupéré et la promesse résolue : Tokio combine ici Mio et les Futures de Rust afin de nous proposer des I/O asynchrones d’un point de vue utilisateur, et ce pour une grande variété de moyens de communication : TCP, UDP, Sockets UNIX, Named pipes, signaux, HTTP, HTTP/2, websockets, …

Pour ce qui est de l’implémentation des cet asynchronisme, on aurait pu instinctivement penser à la réaliser sous forme de callbacks, mais ceux-ci présentent les inconvénients notoires de mener à du code peu clair, compliqué à maintenir  et de nécessiter une certaine « gymnastique » en cas de multithreading. C’est pourquoi Tokio nous propose plutôt une event loop, responsable de bloquer le thread courant et basée sur un concept de Task. Une Task est composée de plusieurs Futures, et devient l‘unité de concurrence, étant donc en ce sens très similaire aux green/lightweight threads.

Enfin, dernier point expliqué avec brio par Alex : comment savoir quand la Future est « résolue » et qu’en est-il du polling ?
Supposons que nous allions demander périodiquement à la Future (on Poll, donc) dans quel état elle se trouve :

• Une valeur de retour de la Future à None (type Option) signifie « not ready »
• Un retour de Some résout la Future

… mais du coup, en cas de None, quand rappeler poll ? Il a déjà été établi que dans le cadre de Tokio, les Futures appartiennent à une Task. Si la Future n’est pas prête… c’est cette Task qui doit réessayer plus tard, et donc savoir quand réessayer ! Une valeur de retour à None signifie donc implicitement et automatiquement « je te notifierai plus tard ».

En résumé : dans Tokio, TOUT est une Future. Ces Futures peuvent potentiellement nécessiter d’attendre des I/O, et le rôle de Tokio est donc de router les notifications d’I/O vers ces Tasks. Ces notifications ne sont autres que celles fournies par le kernel Linux lui même : « Le file descriptor 42 est prêt pour que tu ailles lire dessus » par exemple; et si vous avez suivi jusqu’ici, vous savez désormais que Tokio ira donc réveiller la Task en attente de l’I/O en question. Il n’existe visiblement pas de notifications d’I/O de ce genre sur Windows, et Tokio fait donc recours au polling en dernier recours dans ce cas, j’avoue ne pas avoir été vérifier.

Pour conclure, l’implémentation des Futures de Rust est vraiment passionnante, et l’event loop de Tokio se charge de « traduire » les notifications d’I/O du kernel en notifications pour les Tasks qui wrappent ces Futures. Au final, Tokio nous propose ici une manière élégante de faire des I/O asynchrones en Rust à base d’event loop et de Futures, nous évitant ainsi le légendaire callback hell.

Remarques diverses sur l’évènement lui-même

• Le format des slots, 30min, était vraiment agréable
• Les organisateurs proposaient 2 couleurs de tour-de-cou pour les badges : noir ou rouge, le noir signifiant « OK pour les photos » et le rouge « Je ne souhaite pas être pris en photo durant l’évènement ». Un grand bravo à eux pour avoir songé au côté vie privée, tant il est maintenant courant de photographier tout et tout le monde lors de conférences pour ensuite tout publier en ligne.
• Toutes les vidéos sont disponibles sur la playlist YouTube officielle du RustFest

Conclusion

Cette conférence était vraiment une excellente vue d’ensemble sur ce qui se fait en Rust, avec des retours et des exemples de cas d’usage très variés, mais toujours avec le même point commun : le gros avantage de Rust, c’est la safety qu’il apporte ! Mention spéciale à Tokio, la bibliothèque d’I/O asynchrones en Rust, et au talk d’Alex Crichton à ce sujet que je vous invite à regarder.

L’exemple typique de cas d’utilisation parfait pour Rust semble être l’embarqué et les tâches vraiment bas niveau avec besoin de contrôle fin sur la mémoire tout en gardant une certaine solidité. Ce n’est bien sûr pas le seul, mais c’est en tout cas le plus représentatif. Par ailelurs, choisir Rust semble vraiment être un investissement sur la stabilité et la vie à long terme d’un projet.

Au final, ce RustFest confirme mon sentiment que Rust est vraiment approprié lorsque les besoins de safety et d’un langage complet se font sentir, là où Go, qui lui est souvent opposé, est, je trouve, plus approprié pour prototyper rapidement. Typiquement, je verrais très bien des orchestrateurs ou des composants système bas niveau en Rust ! En revanche, je n’ai vu aucun talk évoquant la construction d’API REST en Rust lors de cette conférence, bien que ce soit évidemment possible et facilité par des bibliothèques telles que Rocket. Si ce point vous intéresse, je vous invite à vous tourner vers la page « are we web yet? » de Rust

Dernier point, notez que le prochain RustFest se tiendra à Paris en 2018, et je vous y donne donc rendez-vous :)

Summary of what everyone says about #Rust at @RustFest : compiler and language help a ton despite the steep learning curve, keep going :) pic.twitter.com/sxKdjrvPfZ

— Alexis Chotard (@Horgix) 30 septembre 2017

Cette année l’AWS re:Invent avait lieu à Las Vegas du 27 novembre au 1^er décembre. L’occasion pour nos Xebians de vous résumer les annonces qui ont retenu leur attention.

Au programme : des conteneurs, du Serverless, du GraphQL et bien d’autres nouveautés chez AWS… tant d’annonces que nous vous les présenterons sous forme diluée au cours des prochaines semaines, en guise d’ersatz de calendrier de l’avent, avec comme cadeau de Noël un retour sur les services que nous aurons testé d’ici là !

Vous pourrez donc retrouver un résumé des annonces nous ayant marqué, regroupées par thématique :

1. Vendredi 8 décembre : Orchestration de conteneurs (vous êtes ici)
2. Lundi 11 décembre : Une flopée d’annonces pour Lambda
3. Jeudi 14 décembre : Stockage de données
4. Lundi 18 décembre : Service mobile, EC2 et Active MQ
5. Jeudi 21 décembre : Réalité virtuelle & augmentée et Machine Learning
   

Enfin du Kubernetes managé

Par Alexis Horgix Chotard

 Annonce sans une once de surprise tant elle était attendue, mais néanmoins fracassante : EKS, de son nom complet Amazon Elastic Container (ECS) pour Kubernetes.

Pour rappel, Kubernetes est un orchestrateur de conteneurs open-source développé par Google et désormais sous la direction de la Cloud Native Computing Foundation (CNCF). Ce côté GIFEE l’a rapidement propulsé et a entraîné une dynamique communautaire qui en fait maintenant un projet très complet et plébiscité par de plus en plus d’entreprises.

Outre la possibilité d’héberger un cluster Kubernetes chez soi grâce à son côté Open Source, Google propose de son côté GKE, un cluster Kubernetes managé sur Google Cloud Platform. Même Microsoft propose du Kubernetes sur Azure ! De son côté, Docker vient d’annoncer le support de Kubernetes, et Mesosphere a présenté le support de Kubernetes comme framework DC/OS il y a déjà un bon moment.

Bon dernier dans la course à Kubernetes, AWS ne fournissait jusqu’ici qu’ECS pour gérer des conteneurs, et vient donc combler l’écart avec la concurrence. C’était assez prévisible au vu des éléments précédemment évoqués.

AWS propose donc désormais de gérer un cluster Kubernetes pour vous, avec la prise en charge de tous les pain points habituels : haute disponibilité, ajout de noeuds, mise à jour, monitoring du cluster, … L’intégration avec les autres services d’AWS est également un gros point positif : load balancing par ELB, gestion des permissions par le service IAM, partie réseau via VPC, PrivateLink, etc.

En revanche, il est toujours nécessaire de gérer la quantité de noeuds pour les clusters ECS/EKS « manuellement », ce dont on aimerait bien se passer et qui sera notamment possible avec AWS Fargate, lui aussi annoncé lors de cette re:Invent 2017.

Fargate, ou comment lancer des conteneurs sans se soucier de l’infrastructure

Par Alexis Horgix Chotard

… en parlant d’AWS Fargate, celui-ci fait justement partie des nouveaux services annoncés lors de ce re:Invent 2017 !

Fargate est là pour palier le bémol associé plus haut dans cet article à ECS/EKS : celui de la gestion des instances sous-jacentes du cluster ECS/EKS. En effet, le but de Fargate est de totalement abstraire la notion d’instances sur lesquelles l’orchestrateur de conteneurs va tourner ! Ainsi, on est vraiment sur de l’orchestration de conteneurs « as a service », ne se souciant que de ces derniers.

Les questions qui se posent immédiatement sont :

• Quid de la facturation, qui n’est donc plus basée sur les tailles d’instances EC2 ? 
• Qu’en est-il de l’isolation ? AWS fait-il entièrement confiance aux namespaces et cgroups sur lesquels reposent les conteneurs, ou y a t-il toujours un niveau de virtualisation qu’il nous abstrait totalement ?

Pour le premier point, on se retrouve sur un modèle de facturation se rapprochant des Lambdas : $0.0506 par vCPU par heure, $0.0127 par Go de mémoire par heure, avec une facturation effectuée à la seconde. On est donc bien sur un esprit de conteneurisation, où l’on préfèrera des unités d’exécution minimales mais en grand nombre.

Pour l’isolation, le mystère reste entier, mais il y a fort à parier qu’Amazon conserve une couche de virtualisation en dessous des conteneurs.

Enfin, notons que Fargate n’est actuellement disponible que pour des tâches ECS, et non EKS, dont le support est prévu pour 2018. En revanche, la gestion de la cohabitation de Fargate et EC2 comme supports pour ECS est la bienvenue : il est possible d’avoir des clusters ECS hétérogènes, ayant des tâches à la fois sur des instances EC2 ou reposant sur Fargate.

Notons au passage qu’une fois les tâches EKS gérées par Fargate, nous serons enfin dans le cas tant demandé depuis des mois :

Introduction

En général, on ne fait pas trop attention au gestionnaire de sources (SCM) utilisé dans nos projets, mais il est toujours là. Bien connaitre les possibilités fournies par son SCM est très important pour mener à bien nos projets. Dans cet article nous allons voir les particularités de GitFlow, un workflow Git qui mérite le détour et qui fait débat.

Avant de te préoccuper de la route, inquiète-toi du compagnon

Dicton oriental

Nous, les développeurs, quelle que soit notre spécialité, avons toujours un ami qui nous accompagne pour le meilleur et pour le pire, jusqu’à ce que la mort – ou le changement de projet – nous sépare : le gestionnaire de sources. Notre SCM est le gardien du bien le plus précieux d’un projet, notre code source, et est la pierre angulaire sur laquelle le travail en équipe va reposer. C’est pour cela que bien connaitre son SCM est vital pour mener à bien nos projets. Néanmoins, toutes les équipes ou organisations n’ont pas les mêmes besoins.

• Doit-on gérer plusieurs versions de notre application en même temps ?
• Une fonctionnalité peut-elle être développée par plusieurs personnes au même moment ?
• A-t-on une plateforme CI/CD (Continuous Integration / Continuous Deployment) à notre disposition pour tester rapidement les évolutions de notre application ?

Pour donner une réponse aux spécificités de chaque projet, la communauté des utilisateurs de Git propose plusieurs workflows que nous pouvons adapter à nos besoins. Dans cet article, nous allons approfondir l’un d’entre eux : Gitflow. Dans un premier temps, on introduira théoriquement le workflow pour ensuite creuser et essayer de cerner ses avantages et inconvénients (qui sont vite oubliés dans la plupart des articles sur le sujet). Pour finir, on introduira quelques billes pour faciliter la mise en place de ce workflow sur un projet.

Le but de cet article n’est pas de présenter en détail le fonctionnement de Gitflow. Si vous voulez approfondir sur ce sujet, je vous encourage à consulter les articles suivants :

• A successful Git branching model : Article original de Vincent Driessen dans lequel il présente Gitflow
• Gitflow Workflow : Article de la société Atlassian dans lequel Gitflow est présenté d’une manière très graphique. Dans la page consacrée à Git, on peut trouver d’autres workflows ainsi qu’un tutoriel
• Git-flow cheatsheet : Extensions Git pour mettre en place plus facilement Gitflow

Les schémas utilisés dans cette article sont issus de l’article d’Atlassian. Ces images ont été publiées sous licence Creative Commons Attribution 2.5 Australia License.

Gitflow en quelques mots

Gitflow sépare sur des branches isolées le code en cours de développement et le code validé et testé. Pour cela, il s’appuie sur la création de plusieurs branches dont le cycle de vie est bien défini. Voici une table contenant leurs noms, leurs cycles de vie et leurs fonctions :

 Afin de visualiser l’interaction de toutes ces branches, vous pouvez trouver un schéma ci-dessous :

Comme vous pouvez le constater, ce workflow est une extension du Feature Branch workflow avec quelques branches en plus. Bon, assez de théorie pour aujourd’hui. Parlons des faits !

Les avantages

Branch all the things!

L’un des avantages de Git par rapport aux autres SCM comme SVN est la simplicité et la rapidité lors de la création/changement des branches. Cela a permis l’apparition de plusieurs workflows multibranches comme par exemple le Feature Branch workflow ou le Gitflow workflow. Cette approche a de multiples avantages que l’on va énumérer ci-dessous :

Développer isolément une nouvelle fonctionnalité

Travailler en équipe, c’est bien mais chacun a besoin de son propre espace. Lorsqu’on développe une nouvelle fonctionnalité, c’est essentiel de s’isoler des modifications non-liées à la fonctionnalité sur laquelle on travaille. Pourquoi ? Parce que lorsqu’on développe, notre code peut engendrer des régressions. Et si l’on travaille tous sur la même branche, on aura du mal à trouver l’origine de la régression. Est-ce suite à notre développement, ou à celui d’un collègue? Ceci peut nous faire perdre beaucoup de temps.

Un autre avantage lié à cette approche est que l’on peut écarter une fonctionnalité si elle sort du scope du sprint courant sans impacter le reste des fonctionnalités et sans perdre le code généré. Ceci peut arriver quand, par exemple, on s’est rendu compte que la fonctionnalité n’est pas bien définie ou quand on ne finit pas à temps pour la fin du sprint. Voici un schéma montrant ceci :

Comme on peut le constater, la deuxième branche feature n’a pas été fusionnée sur la branche develop. Par conséquent, on pourrait la merger pour la prochaine version.

Expérimentation

Avez-vous envie de tester la nouvelle version de votre framework préféré et évaluer l’impact sur votre application ? Voulez-vous changer vos pom.xml pour optimiser vos builds ? Pas de souci ! Vous pouvez créer une branche d’expérimentation pour travailler tranquillement. Et tout cela sans risquer l’intégrité de l’application et sans déranger vos collègues.

Bugfix for Dummies

La gestion des bugs en production est assez ennuyeuse en règle générale. Gitflow permet de gérer cette situation très facilement. Voici un petit exercice de mise en situation :

(Lundi 9h du matin). Développeur lambda arrive au bureau avec une envie irréfrénable de café quand tout à coup il reçoit un coup de fil de son product owner

Product Owner: Qu’est-ce que vous avez foutu lors de la dernière MEP ? J’ai reçu plusieurs mails d’utilisateurs fous furieux car il y a un bug bloquant qui les empêche de travailler ! A CORRIGER ASAP !

Dev lambda: Ne vous inquiétez pas. Je gère

Product Owner: Je l’espère bien. Tenez-moi au courant -raccroche-

Dev lambda panique. Il n’a pas beaucoup d’expérience et tous les autres développeurs sont en congé. 

En général, les développeurs n’aiment pas travailler sous pression. Encore moins quand ils n’ont pas encore bu leur café. Malheureusement, ce genre de situation est fréquente et il faut savoir comment réagir. Dans notre cas, comment notre développeur va-t-il s’en sortir ? Pas de panique ! Gitflow a la solution à notre problème. Comme vous le savez, la branche  master contient le code de la dernière MEP réalisée, par conséquence, on n’a qu’à créer une branche nommée hotfix-bug-du-lundi-matin à partir de la branche master. Voici un schéma concernant le cycle de vie de la branche hotfix :

Comment on peut constater, lorsque un bug est corrigé, la branche créée pour le résoudre est mergée sur deux branches différentes :

• master : Pour faire ensuite une nouvelle release et faire une MEP dès que possible
• develop : Pour s’assurer que la version en cours embarquera la correction du bug

(Lundi 11h du matin). Développeur lambda appelle son responsable

Dev lambda: Bonjour monsieur, j’ai trouvé le bug et je l’ai corrigé sur la branche bugfix-bug-du-lundi-matin. On a créé un nouveau test unitaire pour que cette situation ne se répète plus. Tous les test sont au vert et la branche bugfix a été mergée sur la branche master. On est prêt pour la release

Product Owner: C’est fabuleux. N’oubliez pas de merger aussi sur la branche develop pour que la modification soit embarquée dans la version en cours de développement

Dev lambda: C’est fait

Product Owner: Magnifique ! Faites la release

Le superpouvoir de la branche release

Si vous jetez à nouveau un coup d’œil sur le schéma général de Gitflow, vous allez sans doute vous poser des questions par rapport à la branche release. A quoi sert-elle ? Lorsqu’on a fini toutes les fonctionnalités, la phase de recette commence. Sauf catastrophe, il s’agit d’une étape assez tranquille pour les développeurs, seuls quelques ajustements sont normalement nécessaires. Pendant cette étape, Gitflow permet aux équipes de se scinder en deux :

• Correcteurs de bugs : certains développeurs doivent corriger les bugs trouvés par les recetteurs. Ils vont travailler sur la branche release.
• Développeurs : le reste de développeurs peuvent commencer, si possible, les features du sprint prochain. Pour cela, il faut qu’ils créent des branches feature à partir de la branche develop

La composition des deux équipes peut varier de manière dynamique selon le nombre de bugs détectés.

Une fois la recette terminée, on mergera la branche release sur la branche master pour tagger notre dépôt et sur la branche develop pour intégrer les dernières corrections sur la prochaine version.

Adapté aux méthodologies agiles…

Beaucoup de sociétés se sont rendues compte que si elles veulent réduire le « time to market » (TTM), les anciennes méthodes de conception logiciel ne sont plus valables. C’est pour cela que les méthodes agiles comme Scrum sont de plus en plus répandues. L’intégration de Gitflow au sein d’une équipe Scrum est assez naturelle car il y a une relation directe entre les artefacts Scrum et les branches du workflow :

et au déploiement en continu

La mise en place d’une démarche de déploiement en continu est assez simple car il y une liaison forte entre les types de branches et les envionnements cibles. Voici une table contenant les types de branches et leurs environnements :

Ce que l’on ne dit pas

Malgré les avantages évidents de ce workflow, il y a des inconvénients qui se manifestent lors de sa mise en place. Voici quelques difficultés que l’on peut rencontrer :

Complexité

Lorsqu’on se penche la première fois sur ce workflow notre instinct nous dit qu’il est complexe. Et notre instinct ne ment pas ! D’ailleurs, ce framework génère des avis assez contraires en ce qui concerne sa complexité. Pour certains, le workflow est inutilement complexe car :

• On doit appréhender les cycles de vie de 5 types de branches différentes: master, develop, feature, hotfix, release
• Dans le cadre de certains projets les branches master et develop sont redondantes
• Dans certaines conditions, on ne doit pas faire un mais deux merges consécutifs sur des branches différentes (finalisation d’un hotfix ou finalitation d’une release). Voici un exemple :

En effet, ce workflow est complexe et il ne s’adapte pas très bien aux petits projets et aux projets menés par des personnes qui n’ont pas beaucoup d’expérience avec Git.

Historique difficile à suivre

Dans l’article d’origine de Gitflow, Vincent Driessen propose de merger les branches avec l’option -no-ff afin de créer des commits à chaque merge (même quand un fast-forward est possible). L’auteur jusitifie ce choix pour ne pas perdre l’historique des branches feature qu’ont été déjà mergées mais, dans la vie réelle, ceci peut générer un historique git difficilement lisible.

Régressions suite aux merges automatiques

Git est assez bon pour gérer les merges automatiquement. S’il n’est pas capable de faire le merge tout seul, il aura besoin d’une intervention humaine pour corriger les problèmes de merge manuellement. Git prévient dans ces cas avec un message d’erreur assez explicite.

CONFLICT (content): Merge conflict in <fileName>
Automatic merge failed; fix conflicts and then commit the result.

Néanmoins, dans certaines conditions git effectue des merges automatiques qui ne sont pas corrects. Et tout cela sans prévenir le développeur qui fait le merge ! En effet, ce n’est pas une situation courante mais cela arrive. Ceci est une source potentielle de régressions.

Astuces pour réussir

Après avoir discuté des avantages et inconvénients de ce workflow, on doit se poser la question, ce workflow est-il pour moi ? Malgré ses inconvénients, Gitflow répond d’une manière élégante à la plupart des problèmes de la vie des développeurs. Voici quelques astuces pour une mise en place sereine de Gitflow.

Sensibilisation de l’équipe

C’est vrai, Gitflow est un peu complexe si on le compare avec d’autres workflows. Parfois, on est tenté de trouver des raccourcis pour avancer plus vite. Un exemple flagrant qu’on peut constater est de ne pas faire des merges mais de cherrypicker les commits. Il est très important de respecter les règles du workflow. Si l’équipe n’est pas mûre, il est nécessaire de trouver un développeur plus expérimenté pour se porter garant du suivi du workflow pendant la montée en compétences du reste de l’équipe.

Definition of Done (DoD)

L’engagement de tous les membres de l’équipe est fondamental pour conduire un projet vers la réussite.

Au sein d’une équipe, le développeur doit être responsable du code qu’il produit. Par conséquent, c’est à lui d’assurer que le code fait par ses soins est correct. Gitflow n’impose aucune action spéciale avant de merger une branche feature sur develop. Voici quelques recommandations :

• Vérifier que tous les tests unitaires et d’intégration sont au vert
• Lancer l’application en local et vérifier manuellement si le fonctionnement est en accord avec la demande du product owner
• Réaliser un analyse en local du nouveau code à l’aide d’un outil de détection de défauts comme Sonarqube. Cet outil peut s’intégrer directement sur l’IDE de notre choix à l’aide des plugins comme SonarLint.
• Demander systématiquement à un collègue de faire une code review de votre code avant de merger sur develop. Cette pratique va permettre d’avoir un avis extérieur du code modifié et peut permettre à l’équipe de mieux contrôler la dette technique du projet. Sur certains outils comme GitLab cela peut être fait sous la forme d’une merge request.

Installation des extensions Git Gitflow

Voici le premier postulat de The three great virtues of a programmer de Larry Wall :

1 Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful and document what you wrote so you don’t have to answer so many questions about it

Il ne faut pas sous-estimer la vérité qui se cache derrière cette phrase. Nous les développeurs, on est paresseux par définition mais il ne faut pas cupabiliser, c’est notre esprit d’ingénieur. Afin d’automatiser au maximum la gestion des branches, on peut installer des extensions git qu’on peut trouver ici.

Intégration continue et dette technique

Dans n’importe quel projet, il est recommandé d’avoir une plateforme d’intégration continue. Ceci permet d’intégrer automatiquement les modifications réalisées sur le code et de notifier les développeurs lorsqu’un test ne passe plus. Une autre bonne pratique est l’intégration avec un outil de détection de la dette technique comme Sonarqube par exemple.

Comme on a vu précédemment, Git peut introduire des régressions dans notre code lors d’un merge automatique. C’est vital de détecter rapidement ce genre de situations. Pour faire ceci, on peut s’appuyer sur deux aspects : la couverture de tests et le build automatique des branches clé. Voici une mise en situation : suite à plusieurs merges des features sur la branche master, git introduit une régression sans notifier personne.

• Jenkins détecte un changement sur la branche master. Il lance donc un build
• Le build échoue car un ou plusieurs tests ne marchent plus.
• Jenkins notifie l’équipe du problème via mail, slack, etc.
• L’équipe traite ce problème en priorité et corrige le problème

Pour que cette démarche fonctionne, on ne doit pas désactiver les tests. Interdit d’utiliser @Ignore 

Voici une table contenant une proposition de configuration des branches sur Jenkins :

Tout ça c’est bien mais, comment je peux configurer tout ça sur ma plateforme CI ? Si on utilise Jenkins, on peut utiliser le plugin pipeline multibranch de Jenkins. Voici quelques liens contenant des informations concernant ce plugin Jenkins et son utilisation dans le cadre de Gitflow :

• Configuring a Multi-Branch Pipeline in Jenkins – Adventures in Learning 
• Pipeline-as-code with Multibranch Workflows in Jenkins
• Make Jenkins speak Git Flow

Déploiement automatique

Si on part du fait que l’on a déjà une plateforme d’intégration continue fonctionnelle, l’étape suivante est d’automatiser les déploiements sur les différents environnements. Comme vu lors de la présentation des avantages de Gitflow, il y a un lien fort entre les types de branches et les environnements que l’on a normalement à disposition. Ne serait-il pas génial de pouvoir lancer un déploiement sur l’environnement de développement à chaque modification de la branche develop ? Le déploiement en continu présente beaucoup d’avantages mais il s’agit d’un processus long, périlleux et dans la plupart des cas frustrant pour différentes raisons :

• L’automatisation des déploiements est une tâche longue qui n’aporte pas de la valeur au produit dans un premier temps. Il s’agit d’un investissement à long terme.
• Automatiser un déploiement est une tâche complexe qui nécessite des gens formés et motivés.
• Pour donner le pouvoir aux développeurs pour faire des déploiements à la demande, un changement de mentalité est nécessaire. Pour faire ceci, il faut que les développeurs et les opérationnels se rapprochent pour collaborer ensemble d’une manière plus fluide est naturelle. Cette organisation est connue sous le nom de DevOps. La mise en place d’une stratégie DevOps est spécialement difficile dans les grandes structures où les différents départements ont des objectifs différents et dans la plupart des cas contraires.

Bien tester les features avant le merge sur develop :

Qu’est-ce que le merge d’une branche feature veut dire ? Lorsqu’on merge une branche feature sur la branche develop, on indique que la fonctionnalité est terminée et prête pour la recette. Qu’est-ce que « prête » veut dire ? Cela dépend de la DoD accordé sur chaque projet.

L’un des principes du software craftsmanship est que les développeurs doivent être responsables du code qu’ils produisent. C’est pour cela qu’un développeur doit s’assurer que la fonctionnalité implémentée réponde au besoin du Product Owner. Néanmmoins, une fois la fonctionnalité terminée, on doit pouvoir tester on-live. On peut tester en local mais un avis exterieur est nécessaire car, en règle générale, c’est une mauvaise pratique qu’une fonctionnalité soit testée par la même personne qui l’a développée.

Dans ce contexte, une question se pose, comment peut-on faire mieux ? Ne serait-il pas génial de mettre à disposition des recetteurs des environnements pour chaque feature pour qu’ils testent au fur et à mesure que les fonctionnalités aboutissent ? Beaucoup d’évolutions se sont produites dans ce sens-là ces derniers années avec l’apparition des outils comme Docker ou Kubernetes. Il y a même des SCM comme Gitlab qui proposent le concept de review apps permettant la création et le déploiement des applications à partir d’une branche. Ce type de solutions sort du cadre de cet article mais on peut trouver quelques liens intéressants ci-dessous :

• Introducing review apps
• Behind the scenes: How we built Review Apps
• Introduction à l’orchestrateur de conteneurs Kubernetes

Bien entendu, même si on arrive à mettre en place une solution de ce genre, une phase de recette sera nécessaire lorsque toutes les branches feature seront mergées. Cependant, la plupart des bugs seront déjà corrigés.

Cette année encore, nous ne pouvions pas manquer l’événement incontournable des développeurs : Devoxx France.

Du 18 au 20 avril prochain, les 3 000 participants attendus seront tous réunis au Palais des Congrès pour assister à 235 conférences. Parmi eux, une trentaine de Xebians se mêleront à la foule, en tant que participants mais aussi comme speakers !

Hands’on

• Entrevue avec Vue.js par Ludovic Ladeu et Thomas Champion

Venez découvrir ou redécouvrir Vue.js, le challenger de React et Angular, au travers d’une présentation endiablée.

Votre mission sera ensuite de construire une application étape par étape afin d’appliquer les différents concepts présentés. Le niveau du Hands-on étant progressif, il permettra aux débutants d’assimiler les bases et les bonnes pratiques de Vue.js. Les plus téméraires arriveront-ils à atteindre la dernière étape ?

Ce slot vous apportera les clés qui vous permettront de construire une application Vue.js, ainsi que d’approfondir l’écosystème qui s’est construit autour.

• Protéger ses API avec Hystrix par Nicolas Jozwiak, Sergio Dos Santos

Dans des environnements microservices et distribués, des interruptions, dégradations de services et autres problèmes se produisent fréquemment. Dans le pire des cas, ces aléas peuvent entraîner l’écroulement du système entier. Développé par Netflix en 2011, Hystrix permet de gérer efficacement ces problématiques en proposant des outils d’isolation de services, de fallback, de gestion des ressources, etc.

Au travers de ce hands-on, nous vous proposons une série d’exercices qui vous permettront de découvrir et mettre en place les principaux mécanismes d’Hystrix. Vous étudierez notamment les notions de fallback, cache, gestion des threads et sémaphores. Enfin, nous vous présenterons l’outil de Dashboard qu’Hystrix propose.

• Hand’s-on Kotlin par Sergio Dos Santos et Fabian Gutierrez

Kotlin est un langage qui fait beaucoup parler de lui… mais vous n’avez encore jamais osé vous y mettre ou eu l’occasion de le pratiquer ? Cet atelier d’apprentissage du langage est fait pour vous !
À travers d’exercices de difficulté croissante, vous aurez la possibilité d’apprendre les notions de base du langage mais aussi des fonctionnalités assez avancées. De niveau débutant à intermédiaire, à l’issue de cet atelier vous repartirez avec des bases solides pour progresser en Kotlin.

Conférence

• Optimisation et performance sur Spark par Bruno Bouchahoua et Ivan Beauvais

Spark le moteur d’exécution multi langages, multi usages, multi plate-formes est devenu au fil des années incontournable dans le monde de la data. Sa diversité lui permet d’être utilisé par une multitude de profils développeurs ayant des degrés d’expérience différents sur les systèmes distribués.

Malgré la réputation de rapidité, les performances ne sont pourtant pas toujours au rendez-vous.

Dans cette présentation, nous allons voir ensemble des cas tirés de situations réelles avec des problèmes de performance. Comment les expliquer et les optimiser.

Quickies

• Mutation Testing: comment vous assurer de la qualité de vos tests par Sarah Buisson

Rares sont les projets sans tests unitaires. Mais votre couverture de tests est-elle vraiment pertinente? Avec Pitest, les tests de mutations vont vous permettre de valider l’efficacité de vos tests.

• Laissez tomber Express, passez à son successeur Koa par Anthony Giniers

« Koa is superior to Express in my opinion, having written them both »

Le créateur de Koa.js et Express.js le dit lui-même : Koa devait être la version 5 d’Express, mais l’API était trop différente, d’où la création d’un module séparé.

Mais alors, pourquoi Koa commence-t-il seulement à gagner du terrain sur Express (19k vs 31k stars sur GitHub) dans la lutte du framework web Node.js le plus populaire ? Qu’est-ce qui rend Koa supérieur, palliant ainsi les limites d’Express ? C’est ce que nous verrons dans ce quickie.

Tools In Action

• Prometheus, un outil pour les monitorer tous par Ivan Beauvais

On ne discute plus aujourd’hui le besoin de collecter, analyser et grapher les métriques issues de nos applications.

Que ce soit mon application Java, le système, un serveur web ou même une solution custom, Prometheus propose des solutions simples à mettre en place afin de pouvoir exploiter ces informations et réagir. Dans ce tools in action, déouvrez un aperçu des possibilités de cet outil : en quoi diffère-t-il des autres solutions ? Comment l’installer ? Comment monitorer ? Et comment exploiter ses métriques notamment via Grafana ?

BOF

• BOF Scala construction d’un serveur HTTP par Charles Dufour et Fabian Gutierrez

Vous êtes un(e) développeur(euse) Java et vous vous intéressez au Scala ? Vous faites déjà du Scala au quotidien et vous avez envie d’en discuter ? Vous n’avez aucune idée de quelles bibliothèques utiliser pour construire votre serveur HTTP ? Nous ferons deux courtes présentations de Akka HTTP et PlayFramework !

Découvrir les retours des Xebians sur certaines conférences de Devoxx Fr 2018

Pour cette nouvelle édition de Devoxx France, les Xebians étaient présents. Ils vous proposent à travers de découvrir leur avis sur certaines des conférences présentées.

Découvrez leurs retours sur les conférences du jeudi ainsi que celles de vendredi.

Le kit de vidéos pour se préparer à Devoxx France et aux autres conférences 2018

Vous souhaitez vous préparer à Devoxx comme il se doit ? Xebia vous donne déjà quelques sujets à revoir (en vidéos) avant :

• Blockchain & IoT Le nouveau contrat de confiance ?

• Chatbots état de l’art et prochains challenges

• REX akka dans une architecture microservice

• Déploiement continu de modèle de Machine Learning

• Réalité Augmentée pour les terminaux IOS

• Continuous Delivery chez Société Générale GTS

Et toutes les autres vidéos de la XebiCon’17 sont aussi disponibles.

Bon visionnage !