Rennes, les 23 et 25 mars : retour sur le Breizhcamp 2016

Le Breizhcamp 2016 s’est déroulé du 23 au 25 mars à Rennes. Comme chaque fois, ces journées étaient très riches, en conférence et rencontres. Retour sur les présentations de nos Zenikéens

Les Zenikéens y étaient et ont animé plusieurs conférences :

• Traefik, a modern reverse-proxy – Emile Vauge
• Rancher, le (petit) orchestrateur docker qui vous veut du bien – Christophe Furmaniak et Youcef Yekhlef
• HTTP2, ce qui va changer ! – Julien Landuré
• Continuous Delivery en contexte Breton – Mathieu Pousse, Julie Bourhis et Maxime Odye
• Une plateforme de continuous delivery en 45 minutes – Sylvain Révéreault et Mathieu Pousse
• Docker pour développeurs : 5 conteneurs pour 5 langages – Mario Loriedo
• Web Dev Experience – Matthieu Lux
• Codons une pompe à Bière connectée sur Arduino Yùn – Gwennaël Buchet
• Kill all the REST with the Falcor – Hugo Wood
• UX 4 DEV – Guillaume Gaulard

Notre stand et la remise des trophées pris sur le vif par M. Canard Nicolas Deloof !

Voici un retour sur quelques-unes des conférences.
 

Rancher, le (petit) orchestrateur docker qui vous veut du bien by Christophe Furmaniak

Christophe a présenté Rancher (dont la version 1.0 vient juste de sortir), un orchestrateur Docker, afin de mettre en évidence les différentes fonctionnalités :

• Répartition des conteneurs entre les différents nœuds d’exécution ;
• Réseau inter-conteneur multi-host ;
• Load balancer avec health-check intégré ;
• Mise à jour des applications avec retour arrière (rollback) ;
• Multi moteurs : support Kubernetes et Docker Swarm.

La majorité de la présentation s’est articulée autour d’une démo illustrant la facilité de montage d’une plateforme avec 4 nœuds et 1 master en partant de machines neuves.
Dans un premier temps, il faut récupérer et instancier l’image rancher/server

docker run -d --restart=always -p 8080:8080 rancher/server

Le présentateur insiste sur la nécessité de protéger par un mot de passe au plus tôt la plateforme, si elle est accessible sur le net.
Ensuite, pour ajouter des nœuds d’exécution, utiliser l’image rancher/agent et spécifier l’ip du master :

docker run -d --privileged -v /var/run/docker.sock:/var/run/docker.sock rancher/agent:v0.8.2
http://<ip master>:8080/v1/projects/1a5/scripts/<registrationToken>

La suite de la démo s’est focalisée sur l’interface graphique mais les opérations sont toutes réalisables en ligne de commande :

• Déploiement d’une application d’une stack avec un redis en maître / esclave, un backend en springboot et un frontend en JS. 2 instances pour le front et autant pour le back ;
• Création d’une route réseau pour permettre l’accès au backend depuis les frontaux via un DNS interne ;
• Création d’un load balancer en amont des frontaux.

Puis Christophe a montré le mécanisme de mise à jour d’une image applicative avec une démo du bon fonctionnement du rollback.

DevOps sur Android : D’un git push à une release sur le Play Store by Jeremie Martinez

Présentation de la solution retenue par CaptainTrain pour avoir des releases automatiques sur Google Play.
Les recommandations de Jeremie :

• Build :
  • Gradle.
• Tests :
  • À ne pas négliger, même sous Android ;
  • Unitaires avec JUnit et Robolectric pour la partie Android ;
  • Attention à ne pas tester Android ;
  • Utiliser un mécanisme d’assertion comme Truth ou AssertJ ;
• Intégration avec Expresso ou Robotium
  • Ne tester que les user flows principaux ;
• Qualité avec SonarQube et un Lint custom
• Packaging :
  • Filtrer les ressources ;
  • Faire un proguard ;
  • Signer et assembler le paquet ;
  • Ne pas oublier le zipalign.
    • Petite astuce, la commande zipalign -z 4 in.apk out.apk active un algorithme plus efficace que celui par défaut qui peut réduire encore plus la taille de l’APK.

Dans leur cas, ils évitent la livraison continue pas adaptée sur mobile car les utilisateurs n’aiment pas les mises à jour trop fréquentes. Ils ont donc adopté un rythme de livraison toutes les 6 semaines.
Donc toutes les 6 semaines, le mardi, un merge de la branche de dev est effectué dans le master. S’en suit un test bêta d’une semaine puis un rollout progressif de 5% à 100% qui dure aussi une semaine. Il est important de préciser que toute fonctionnalité non finalisée ou suffisamment testée lors de la release sera pour la release suivante.
Les captures d’écran sont un élément important de la page Google Play, ils doivent encourager le client à télécharger l’application. Ceux-ci sont donc automatisés par un outil maison, mais les outils Square ou Screengrab font le travail. Ceci est aussi un gain de temps énorme pour les applications localisées, car le nombre de captures explose rapidement avec plusieurs langues.
Avant la publication, il est important de vérifier permissions de son application car des dépendances peuvent en ajouter, et les utilisateurs ont peur des applications qui demandent trop de permissions.
Enfin, il est possible de scripter l’envoi d’une nouvelle version vers le Play Store avec le Google Play Store Developer API.

Envoyer des informations via le réseau Sigfox by Nicolas Lesconnec

Sigfox est une société qui promeut l’interconnexion des appareils de type IOT et le cloud. Pour ce faire, ils fournissent un service de télécommunication radio permettant très simplement à des appareils industriels ou amateurs d’émettre et de recevoir des trames de 12 octets et 140 message par jour max (!!) sur une distance de plusieurs dizaines de km. Nous sommes très loin des volumes que nous manipulons habituellement …
Les paquets transitent alors sur une plateforme dédiée qui est capable d’appeler un service REST pour publier la donnée sur son propre serveur. Plus de détails ici.
La présentation de Nicolas s’est articulée autour d’une démo avec une carte composé d’un Arduino Uno et un modem M2M. Le programme, ou sketch dans le jargon Arduino, consistait à émettre un message court. Le code est très simple, il suffit de configurer le module via une communication série et de lui envoyer des commandes AT (comme nos vieux modems 56k). Une fois le message envoyé, Nicolas s’est connecté sur une application en ligne et a affiché le message transmis avec toutes ses caractéristiques : puissance d’émission, borne ayant reçu le message, timestamp etc…
L’ensemble consomme quelques micro ampères au repos et monte à quelques milliampères lors de l’émission.
La communication utilise la bande libre d’usage des 868 MHz (valable pour l’Europe). Bien que nous étions dans un amphithéatre du campus de Beaulieu, le message a été reçu par une station à Vitré, soit à 30 km environ !
La donnée utilisable d’un paquet est faible car il y a des limitations réglementaires en termes de partage de bande de fréquence et par la présence de somme de contrôle, de signature du paquet et d’identifiant empêchant une ré-émission de celui-ci par le biais d’une attaque Man-In-the-Middle.

Docker en Production ? Et quid de la sécurité ? by Jean-Marc Meessen

Jean-Marc (alias Captain Igloo) nous a fait un tour des questions à se poser lorsque l’on veut mettre en place Docker en production. Il a commencé par nous lister les attaques types auxquelles nous pourrions être confronté (les kernels exploits, DOS, container breakout, poisoned images, etc.).
Ensuite il est revenu sur l’historique de Docker, sur l’implémentation des diverses normes de sécurité Linux pour nous expliquer que depuis les dernières versions de Docker (1.9, 1.10), nous avons un produit vraiment robuste et une production ready en terme de sécurité.
3 fonctionnalités ont été détaillées :

• Le capability drop qui permet d’avoir une gestion plus fine que root/non-root en donnant accès à certaines fonctionnalités systèmes (cap-add) ou interdire l’accès à autres (cap-drop). Il a pris l’exemple suivant d’un daemon ntp :

  docker run --cap-drop ALL --cap-add SYSTEM_TIME ntpd

• Le user namespace (qui n’est toujours pas activé par défaut, il faut rajouter l’option –userns-remap au daemon Docker) qui permet d’avoir des ids d’utilisateur différents dans un container afin d’éviter qu’un utilisateur puisse modifier des fichiers root de l’hôte ;
• Le fait que depuis la version 1.10, les layers d’une image sont identifiés via un hash plutôt qu’un id aléatoire permet de mieux identifier les layers et donc mieux savoir ce que l’on embarque.

Il nous a rapidement parlé de la problématique de la signature des images et d’échange de clef. Docker Inc. a fait le choix de la clef physique (du type yubikey) pour répondre à ce problème. Il a évoqué aussi le projet Nautilus qui permet de scanner une image pour chercher des vulnérabilités (pas à jour, faille de sécurité, etc.) ainsi que le projet Notary pour vérifier l’auteur des images et la non-altération du contenu et enfin Trusted Registry avec TLS.
Ses recommandations au final :

• Maintenir à jour vos hosts/images ;
• Cloisonner les containers, volumes
  • Partition docker dédiée ;
  • Docker dans une VM.
• Limiter les communications inter-container ;
• Log & audit ;
• Contrôle d’accès ;
• Utiliser un user applicatif dans container.

Jenkins 2.0 – On jette tout et on recommence? By Arnaud Héritier

Arnaud nous a présenté les nouveautés et la roadmap de Jenkins 2.0 et au-delà.
Jenkins a maintenant plus de 10 ans et Kohsuke Kawaguchi a annoncé le début du projet Jenkins 2.0 au mois de septembre dernier. Les réactions ont été mitigées. D’un côté, c’est plutôt chouette car cela annonce l’arrivée de plein de nouveautés ! De l’autre, mince, va falloir tout refaire !
Les problèmes actuels de Jenkins sont :

• Une base de code vieillissante (certaines dépendances datent de 10 ans) ;
• Une architecture monolithique qui n’aide pas à la disponibilité de la solution (plus de master, plus rien ne marche) ;
• Des centaines de plugins à connaitre pour réussir à faire ce que l’on veut ;
• Facile de lancer Jenkins, mais après plein de configurations à faire pour avoir une instance secure.

Tout ne pouvait pas être traité pour la version 2.0, l’accent a été mis sur :

• Un rafraichissement de l’interface graphique sans casser les plugins actuels ;
• Une mise à jour de la base de code ;
• Un nouveau wizard pour (mieux) sécuriser et plus facilement son instance ;
• Et grosse nouveauté, l’introduction du Jenkinsfile, qui permet de faire un “pipeline as code”.

Un autre fonctionnalité, vraiment intéressante, est la création automatique de jobs par rapport aux branches d’un projet.
Les autres points comme l’aspect monolithique de Jenkins seront adressés dans les prochaines versions majeures de Jenkins.
Vous pouvez d’ores et déjà tester jenkins 2.0 :

docker pull jenkinsci/jenkins:2.0-beta-1

Spécifications en milieu agile by Arnaud Lemaire

Pour démarrer cette présentation très riche, Arnaud Lemaire a commencé par clarifier ce qu’étaient les spécifications : il ne s’agit pas de l’expression du besoin client mais plutôt d’une solution à ce besoin. Et même si ce besoin change rarement au cours du projet, la solution elle, évoluera tout au long de celui-ci, d’où la nécessité de faire évoluer les spécifications au fil de l’eau.
Il a ensuite exposé une série d’étapes permettant de construire ces spécifications en proposant à chaque fois des outils pouvant aider.
La première étape consiste à cibler le problème du client. Le cahier des charges décrit déjà un début de solution, il est important de s’assurer que cette dernière répond bien au problème.
Pour cela, Arnaud nous propose les outils suivants :

• Les 5 « pourquoi » : cela consiste à se poser la question du “pourquoi” de manière répétée pour remonter à la racine du problème.
• La définition récursive : consiste à clarifier tous les mots vagues du problème afin de le cibler plus précisément.

Une fois le problème ciblé, l’objectif est de trouver la solution qui maximise l’impact sur le client, c’est-à-dire de se concentrer sur ce qui apporte de la valeur au client en évitant que le périmètre fonctionnel ne grossisse de manière incontrôlable.
Pour cela, Arnaud nous propose l’Impact mapping. En partant du problème, il construit un arbre en se posant successivement les questions Qui ? Comment ? et Quoi ?. D’après lui, cet outil apporte une vision commune de la solution qui peut ensuite facilement être transposé en User Stories : En tant que [Qui?], Je peux [Quoi ?] afin de [Comment ?].
Ensuite vient l’étape d’étude du contexte métier et l’outil proposé est l’Event Storming. Cette méthode de conception permet de partir des évènements métiers pour échanger autour des processus sans se soucier des contraintes techniques qui peuvent perturber la discussion. Cette pratique apporte une vision commune du métier et permet une découpe en ensembles cohérents qui ne sont pas sans rappeler les bounded contexts du Domain Driven Design.
Dernière étape, la vision temporelle du projet ou quoi développer et dans quel ordre ? Pour changer Arnaud nous propose un outil, le User Story Mapping qui consiste à :

• Lister des activités ou scénarios et de créer une colonne pour chacune ;
• Pour chaque activité, de lister ses étapes et d’ajouter une sous-colonne pour chacune ;
• Pour chaque étape, de lister les détails associés et d’en faire un post-it qui viendra compléter la colonne.

Le jeu consiste ensuite à tracer une ligne horizontale et de laisser au dessus les détails qui seront implémentés en premier, et en dessous les détails qui seront implémentés plus tard.
Arnaud nous explique que cet outil apporte une vision d’ensemble plus riche que le backlog produit et est davantage axé sur l’usage qu’en fera l’utilisateur final.
Pour conclure, Arnaud nous rappelle que ces étapes sont bien sur à répéter tout au long du projet, on parle bien de spécifications agiles !
 

Continuous Delivery en contexte Breton by Mathieu Pousse, Julie Bourhis, Maxime Odye et autres invités surprise…

Mention spéciale pour nos collègues de Zenika qui nous ont offert un spectacle qui a ravi les amateurs de gastronomie bretonne et de présentations bien ficelées !
Guettez la mise en ligne des vidéos, ca vaut le coup d’oeil 😉
 

Les requêtes HTTP de l’extrême by Vincent Cassé

Vincent nous a présenté les problèmes auxquels il a dû faire face lors du développement d’une application de stockage de fichiers en ligne (en PHP).
Comment répondre au problème de téléchargement de plusieurs fichiers ?

•  Impossible pour un navigateur ;
•  Un zip calculé sur le serveur serait une mauvaise idée car on cherche à éviter d’avoir les fichiers en local sur le serveur, et risquerait de provoquer des timeout. ;
•  La solution mise en place est stream zip avec cURL return.

Et pour l’envoi de dossiers ?

• API Filesystem disponible mais uniquement sur Chrome qui l’a déprécié ;
• WebAPI pourrait être l’avenir pour cette problématique.

Il nous a ensuite raconté comment son équipe a réussi à travailler pour résoudre un bug particulièrement coriace.
Certains utilisateurs font part d’une erreur HTTP 0 lors de l’upload de gros fichiers. Mais d’après des sources sûres, cette erreur n’existe même pas dans les spécifications HTTP.
Il précise aussi que lorsque cette erreur se produit sous Internet Explorer, le callback d’erreur n’est même pas appelé, empêchant même de savoir que l’erreur s’est produite.
Côté serveur, on ne détecte qu’une coupure côté client, le timeout PHP est exclu car cURL ne compte pas.
Après quelques tentatives de correction échouées, il s’est avéré que ce qui provoquait cette erreur était Firebug, qui arrête les connexions après 100Mo de transfert.
Pour finir, quelques retours rapides sur l’expérience de maintien de plusieurs navigateurs, avec quelques anecdotes sur Internet Explorer qui change les extensions des fichiers .jpeg en .pjpeg sans raison lorsqu’ils sont uploadés, ou l’absence d’implémentation du bouton dans Windows Phone 8.0.

Merci à Mathias Bernardeau, Eric Briand, Antoine Cailly, Christophe Furminiak et Delphine Millet pour avoir contribué à la rédaction de cet article