Compte-rendu Devoxx 2017

Le meilleur des Keynotes

Le philosophe qui ne voulait pas partir…

Bon, ce titre n’est pas celui de la présentation d’Eric Sadin, qui nous a introduit à la “responsabilité des ingénieurs”, mais son envie de nous convaincre et de nous apporter des clefs de compréhension était tellement grande qu’il ne voulait plus quitter la scène même avec une intervention du speaker de l’équipe Devoxx… De quoi détendre la salle après une présentation qui nous a fait réfléchir.

Lors de sa présentation, il a mis les ingénieurs au centre des problématiques du monde d’aujourd’hui et en particulier (c’est de bon goût à Devoxx) les “développeurs d’algorithmes” qui régissent les mondes d’aujourd’hui et de demain. Il nous a également demandé de faire attention avec les données remontées par nos objets connectés qui pourraient être à l’avenir de vrais problèmes de société.

Il nous renvoie ainsi à notre responsabilité, à notre devoir à l’égard de la société et nous rappelle que nos décisions nous engagent au delà de nous même.

Je ne saurais vous décrire ici l’ensemble des éléments et des explications donnés, mais je vous recommande de voir cette présentation dès qu’elle sortira sur Internet.

L’IA dans les jeux vidéos

Une présentation très drôle de Laurent Victorino, qui nous a montré des exemples d’IA plus ou moins réussies et qui nous ont amenés à la réflexion : pourquoi sont-elles plus ou moins réussies ?

Les joueurs ont besoin de pouvoir gagner pour pouvoir aimer un jeu. Ce principe est au coeur du développement des jeux, quoi de plus pénible qu’une intelligence qui pourrait nous détecter dès notre apparition et prendrait immédiatement la bonne décision en un temps infime. Pourquoi jouer si on ne peut pas gagner ? À l’inverse, si des bots étaient bloqués par une simple porte entrouverte (faut-il l’ouvrir ou la fermer ?) quel serait l’intérêt de les battre ?

Selon l’expression du speaker, son métier consiste à faire la meilleure IA au monde puis “à la coincer dans un parking sombre et la tabasser” avant le lancement du jeu. Rassurez-vous, aucune IA n’a été maltraitée durant cette conférence.

Pour conclure son propos, l’auteur nous a raconté une légende d’Internet que beaucoup auront déjà entendu : dans le jeu Quake 3, les bots avaient la capacité d’apprendre de leurs erreurs et d’améliorer leur capacité de survie. Un joueur qui n’avait pas touché à son serveur depuis des années est retourné dessus et a constaté que la paix était présente entre les bots. D’après lui, l’IA était suffisamment intelligente pour avoir conclu que la meilleure façon de survivre c’est de ne pas se battre. Un très beau message d’espoir pour conclure cette présentation !

De la responsabilité sociétale des “codeurs”

Une excellente présentation d'Alain Bensoussan, avocat à la Cour d’appel de Paris, qui a tenté de démontrer via des cas d’usage comment la responsabilité des “codeurs” pouvait être actée.

Il a en particulier rappelé le cas des logiciels truqueurs dans les tests écologiques des moteurs diesel, exemple édifiant pour bien faire comprendre un point : il ne s’agit pas de science-fiction mais bien d’une vérité et des pratiques qui existent aujourd’hui et où nous, codeurs, sommes au centre des événements.

Sous la forme d’un plaidoyer troublant, il nous a ensuite mis au coeur d’un procès sur le choix prétendument fait par une voiture autonome de tuer une personne, l’innocent, pour en sauver quatre, les coupables, et à poser les questions suivantes : qui a fait ce choix ? Qui est responsable ? Si à la première question la réponse est évidente : le codeur de l’algorithme, la deuxième suscitera forcément la polémique.

En conclusion, il propose d’établir une “charte du code de demain”, définissant un droit à l’humanité dans nos futurs algorithmes.

La révolution cyberindustrielle

Cette présentation, faite par Laurent Bloch, avait pour centre une critique marquée contre le manque d’ambition de nos dirigeants français et plus largement sur l’ensemble du “vieux continent” envers l’ère qu’il a appelée “cyberindustrielle”.

Au cours d’un bref historique des révolutions industrielles, il a introduit trois étapes marquantes :

• la révolution sidérurgique à la fin du 18ème siècle
• la révolution électrique et du moteur à la fin du 19ème siècle
• la révolution cyberindustrielle à partir de l’invention du microprocesseur à partir des années 1970.

Ces trois révolutions ont chacune bouleversé l’histoire et la société sur les sujets juridiques, politiques et bien sûr économiques. Par exemple, avant la première révolution industrielle, la Chine et l’Inde avaient réciproquement 30% et 20% des richesses, et après celle-ci, ces deux pays étaient les plus pauvres au monde.

Pour éviter ce phénomène, toujours selon le speaker, nous devons adapter notre éducation, notre économie mais également nos institutions. Il nous faut également investir dans la recherche, dans les infrastructures, dans la formation de nos ingénieurs, être présents dans les organismes de normalisation,...

Pour conclure sa présentation, il nous a indiqué que la France semble avoir toutes les cartes en mains pour réussir cette révolution et qu’il nous faut juste convaincre nos politiciens de ne pas oublier le virage…

ALEX le robot

Pour finir cette Keynote, Piotr Mirowski nous a présenté un théâtre d’improvisation entre son robot ALEX et lui-même. Il a ainsi récupéré des lieux et des sujets dans le public, et a commencé à improviser une situation où son robot lui répondait (ou pas) dans un sens logique (ou pas). Malgré les difficultés techniques, il a pu nous convaincre de la situation grâce à un certain talent d’acteur.

Ensuite, il nous a expliqué les étapes de l’apprentissage et les futures évolutions de son robot. Dans son parcours d’évolution l’IA a suivi les étapes d’apprentissage de son créateur afin de surmonter la capacité à improviser.

En conclusion, je pense que ce spectacle sera de plus en plus intéressant dans les mois et années qui suivent… à suivre donc !

Les conférences que nous avons suivies

Orchestration de conteneurs : le choix des armes

Pour cette université, Thomas Auffredou, Yannick Lorenzati et Jean-Louis Rigau ont choisi de comparer les 3 orchestrateurs de conteneurs que sont Docker Swarm, Mesos/Marathon ainsi que Kubernetes et leur comportement durant le cycle de vie d’une application.

Après un rappel de ce qu’est un conteneur ainsi qu’un microservice, a été abordé le besoin nécessitant l’utilisation d’un orchestrateur de conteneurs. En effet, il est nécessaire de gérer le cycle de vie des conteneurs par rapport aux ressources de l’hôte et sans une forte dépendance à une équipe d’OPS, dont ce n’est pas le rôle premier.

À partir de cela, la bataille entre orchestrateurs de conteneurs peut commencer. Le socle commun sera de construire et de déployer la même application avec les différentes options proposées.

La conclusion qui s’impose est la suivante : avec des principes de fonctionnement différents, les 3 orchestrateurs réussissent aussi bien à la tâche qui a été donnée, que ce soit dans le déploiement, la mise à disposition des services hors de l’hôte, la gestion persistante de données, ainsi que la résilience qui reste le point le plus important. Seul le couple Mesos/Marathon présente un bémol : la scalabilité n’est pas prévue par défaut.

Serverless, le framework que votre lambda attendait

Lors de ce Tools in Action, Etienne Peiniau d’Ekino et Frédéric Boulet, de Today I learned, nous présentent  les différentes forces de Lambda : le découplage du code applicatif requis, une scalabilité simple, l’absence de besoin d’infrastructure, la disponibilité de nombreuses métriques ainsi qu’une facturation avantageuse. De plus, de nombreux services AWS peuvent être utilisés en tant que source. C’est alors que la complexité apparaît : si on utilise CloudFormation pour le déploiement de nos services, les templates sont rapidement longs et difficiles à gérer.

De ce constat est né Serverless, un framework en Node.js qui permet simplement de créer et déployer nos applications. En effet, les descriptions sont en Yaml avec une abstraction qui facilite la modification de ces mêmes descriptions. Le framework est extensible que ce soit par l’ajout de plugins mais aussi par l’inclusion de ressources CloudFormation aux templates. Cerise sur le gâteau, Serverless supporte non seulement AWS mais aussi Azure et Openwhisk.

DevSecOps - Security at Devops speed with EDF

Brian Fox de Sonatype nous présente ici les raisons pour lesquelles la sécurité est un élément prépondérant de la chaîne DevOps. En effet, de plus en plus d’éléments opensource sont utilisés lors du développement de projets et ceci pour une raison toute simple : un gain important en productivité. Toutefois, un aspect fondamental est souvent oublié : la mise à jour des composants opensource. Et ce sans prendre en compte l’aspect faillible de toute brique logicielle. De ce fait, le moindre point de vulnérabilité peut avoir des impacts désastreux pour une société.

La clé pour éviter ce genre de soucis est de choisir des composants de qualité, d’inventorier précisément l’utilisation de ces composants et de monitorer les failles de sécurité qui peuvent apparaître en fournissant des plans d’actions afin que la chaîne DevOps soit toujours opérationnelle.

Olivier Routier d’EDF nous présente ensuite un cas rencontré chez EDF. Une faille majeure est arrivée sur Apache Struts, utilisé dans une application critique. L’équipe de sécurité ne savait pas que Struts était utilisé. Suite à une analyse sur un logiciel ancien, de nombreuses failles ont été découvertes. Il a dès lors fallu réagir rapidement afin de résoudre ce problème et définir des méthodes afin que ce danger ne se reproduise plus. De ce fait, des outils de vérification ont été mis en place à plusieurs niveaux de la chaîne DevOps : dès le poste du développeur avec des plugins Eclipse et au moment du build sur Jenkins.

Containers' Jungle. Docker, Rocket, RunC, LXD ... WTF ?

Nicolas de Loof et Yoann Dubreuil de CloudBees nous aident à y voir plus clair parmi toutes les solutions de conteneurisation.

L’histoire des conteneurs

Pour cela, ils retracent l’histoire de l’informatique en partant de la carte perforée (une tâche à la fois : mono-utilisateur / mono-processeur) pour arriver aux systèmes Unix des années 70, où pour une question d’optimisation des ressources, nous aboutissons à des solutions multi-tâches / multi-utilisateurs.

Ces aspects multi-tâches / multi-utilisateurs ont par ailleurs introduit les premiers mécanismes d’isolation intégrés aux primitives systèmes : systèmes de permissions et ACL.

Finalement, un conteneur s’exécute sur un runtime de conteneur qui est un assemblage de primitives systèmes permettant de gérer :

• l’isolation entre conteneurs. Pour cela les noyaux Linux reposent sur les namespaces qui permettent de “cloisonner” des données : identifiants de processus, points de montages, échanges réseaux, hostnames (UTS), communication inter-processus (IPC) et user IDs.
• la limitation des ressources (CPU, mémoire, I/O, ...) via les control groups
• le contrôle des appels faits au sein d’un conteneur via seccomp
• des couches de protection supplémentaires comme AppArmor ou SELinux

On notera que SystemD est quelque part un runtime de conteneurs.

L’assemblage de toutes ces solutions pouvant être différent (périmètre / version), nous pouvons avoir différents runtime de conteneurs.

Historiquement, c’est OpenVZ qui se présente comme le premier runtime de conteneurs, repris par LXC, lui-même repris par Docker dans les premiers temps. En parallèle, Rocket (Rkt) est apparu.

Cette disparité de solutions a donné lieu à une initiative de standardisation : Open Container Initiative dont RunC constitue une première implémentation.

Pourquoi réécrire un runtime? Parce-qu’au-dessus du runtime de conteneurs, on trouve un orchestrateur de conteneurs qui peut fournir des fonctionnalités spécifiques. Par exemple, Mesos qui souhaite tirer profit des GPU.

Les différentes approches de conteneurisation

Trois utilisations des conteneurs existent:

• “machine container” : il s’agit de faire tourner plusieurs processus au sein du même conteneur. On se retrouve alors avec un conteneur proche d’une VM dans sa gestion.
• “process container” : un seul process tourne au sein de mon conteneur. Par exemple, la remontée des logs et des métriques se fera par deux conteneurs supplémentaires.
• “packaging container” : on parle aussi de builder ; le conteneur contient un ensemble de dépendances coûteuses à télécharger ainsi que des outils de build identifiés et figés.

Dans le cadre de “Blue Ocean”, la nouvelle interface de Jenkins, Nicolas et Yoann se sont heurtés au problème du “nested container”, c’est à dire des conteneurs qui doivent lancer d’autres conteneurs en interne.

Leur retour est que la question de l’imbrication des control groups et namespaces, en particulier au niveau du systèmes de fichiers, n’est aujourd’hui pas pleinement résolue.
Ils ont notamment testé Zfs (licence non GPL) et Btrfs. Leur choix s’est porté sur Btrfs qui fonctionne plutôt bien tant qu’il ne s’agit pas prod...

Les alternatives pour faire du “nested container” sont :

• Docker in Docker : cette approche n’a pas été retenue car jugée peu stable et peu élégante.
• Side cars container : la socket du démon docker /var/run/docker.sock est accessible à tous les conteneurs ; on va éviter pour des raisons de sécurité !
• Nested VM : si cela est trop complexe dans le monde du conteneur, pourquoi ne pas revenir aux VM ? Car cela n’est pas possible sur du cloud public AWS ou GCE, or, la CI Blue Ocean tourne sur AWS.
• Passer sur une autre technologie de runtime : par exemple LXC/LXD développé par Canonical … c’est ce qui a été retenu pour l’intégration continue de Blue Ocean. La combinaison gagnante est donc LXC/LXD sur EC2  + Btrfs ; pour du build, pas de la production.

Au secours ma prod est sous Docker

Dans cette conférence, François Teychene, DevOps chez TabMo, revient sur son expérience avec la production à base de conteneurs. Son constat est assez simple, la tendance des conteneurs est portée par les Devs, d’abord sur leurs postes, puis ils sont intégrés dans les serveurs d’intégration continue et tout le monde est content. Vient enfin le moment du passage à la production où les choses se compliquent rapidement après les premières heures de joies d’avoir enfin des conteneurs en production.

La grande promesse du conteneur qui permet de créer les mêmes environnements du dev à la production est largement dévoyée.

Il cite quelques-unes de ses désillusions lors du passage à la production :

• Le fait que le conteneur se comporte bien hors production a tendance à faire oublier que la production reste un défi.
• Upgrade - Ou comment gérer le déploiement et les mises à jour des conteneurs sans rupture.
• Dépendances - Docker Compose c’est parfait pour une machine unique mais il faut un orchestrateur pour déployer un ensemble de conteneurs dépendants en production.
• Reprises sur erreurs - Comment gérer les conteneurs cassés, surtout si l’applicatif qui tourne à l’intérieur est mort alors que le conteneur lui même continue à s’exécuter.
• Monitoring - Les conteneurs sont un peu des boites noires tant pour les logs que pour les métriques, il faut donc penser à fournir une solution de monitoring complète adaptée.

En bref, que l’on fasse du conteneur ou pas, les problématiques de production restent les mêmes. La principale différence étant qu’on doit les adresser avec de nouvelles solutions (orchestrateur, service discovery, plugin de stockage, plugin de réseau, plugin de monitoring, et sous-système de log). Un slot qui a le mérite de rappeler la réalité de la production aux foules fanatiques des conteneurs. Nous noterons quelques impasses tout de même comme par exemple la gestion des dépôts d’images, le rythme de mises à jour du démon Docker et les éventuels soucis de sécurité. Le message que nous retiendrons est bien que les conteneurs sont des processus d’isolation de ressources, point final. Il permettent de densifier les infrastructures et nous obligent à sortir du paradigme de la gestion des serveurs comme des animaux de compagnie.

Deploy Master by Edson Yanaga

Edson Yanaga, directeur “developer experience” chez Red Hat nous a présenté les différentes stratégies de déploiement qui tendent vers le zero downtime.

Pourquoi le zero downtime ?

• DevOps repose sur une boucle de feedback courte. Si les cycles sont trop longs, les développeurs ne se rappellent plus ce qui a été fait le mois précédent, voire la semaine précédente.
• Un cycle de déploiement court suppose de petits périmètres en parallèle.
• Zero downtime est obligatoire pour du déploiement continu sur de petits périmètres.

À ce stade, nous avons eu droit à une démonstration sur une infrastructure Kubernetes/OpenShift provisionnée dans une VM de 8 Go de RAM : Red Hat Container Dev Kit.

Les stratégies zero downtime démontrées au sein de Kubernetes seul :

• blue / green
• canary deployment
• rolling upgrade : suppose des tests de vie (liveliness : si KO, l’instance est tuée) et santé (healthcheck : si KO, est exclue du load balancer)
• canary deployment

Pour aller plus loin, parlons A/B testing, qui implique des métriques métiers pour prendre une décision de garder A ou B

• Répartition arithmétique : 50% A / 50% B. Dans ce cas, Kubernetes ne suffit pas et suppose du routage géré par OpenShift
• Ou selon une logique plus poussée: nécessite un routeur avancé. En l'occurrence Zuul de Netflix qui gère des règles de routage via du code groovy.

Pour finir, Edson a abordé le feature toggling en présentant FF4J, un framework de gestion de features pour Java.

Être geek en SSII : guide de survie en milieu hostile

Charlotte Cavalier et Christophe Pont nous expliquent de quelle façon ils ont résolu les problèmes et désillusions que peuvent rencontrer des prestataires lors de leur arrivée dans une grande société où le fonctionnement est “politique” et tend vers un immobilisme assez important.
Cette solution est un combat de longue haleine afin de pouvoir organiser des BBL (Brown Bag Lunch), c’est à dire des présentations sur le temps de la pause déjeuner. Combat de longue haleine car il faut réussir à convaincre la hiérarchie afin de pouvoir réaliser cela, sans compter le fait de convaincre les employés de participer à ce genre d’activité. Mais après avoir réussi à réaliser cela, le succès est tellement important que tout le monde en redemande et que cela s’est étendu à la tenue de formations en interne, d’agile games, le tout de plus en plus régulièrement.

Si vous êtes triste dans votre mission, vous savez ce qu’il vous reste à faire.

Conclusion

Ce compte rendu illustre quelques conférences que nous avons suivies lors de l’édition 2017 de Devoxx France. Toutefois, ce n’est qu’une maigre partie de l’ensemble des présentations qui ont été dispensées durant ces 3 jours de conférences. Nous ne pouvons que vous conseiller d’aller sur la chaîne Youtube de Devoxx France où l’ensemble des conférences seront disponibles très prochainement.

Nous nous retrouverons prochainement pour différents articles sur Breizhcamp, dotScale et le Paris Container Day.