CérénIT

Conteneurs

• Docker dans un contexte hybride Windows et Linux : si vous l’avez raté, le retour d’expérience suite à une mission autour de docker dans un environnement Windows et Linux tant au niveau des VMs hôtes que les OS de conteneurs.
• Container isolation gone wrong : un exemple intéressant où des conteneurs a priori indépendant et isolés se marchent l’un sur l’autre au travers des appels au noyau linux. Même si chaque container est “relativement” isolé des autres, il ne faut pas oublier qu’ils reposent tous sur le même kernel parent.
• Containers, VMs… Comment ces technologies fonctionnent et comment les différencier? (Quentin Adam) : l’article précédent m’a rappeler cette vidéo de Quentin Adam à Devoxx expliquant les différences entre containers et VMs. Un conteneur est un process linux relativement isolé les uns des autres mais rien de plus. Les plus ciniques pourraient dire que cela ressemble à de l’hébergement mutualisé d’il y a quelques années avec Apache et mod_php ;-)

Elasticsearch

• X-Pack alternatives : X-Pack est un ensemble de produits additionnels pour ElasticSearch couvrant les besoins de Sécurité, Monitoring, Alterting, Reporting, Graph et Machine Learning. Ce produit est soumis à licence et de mémoire, le prix est assez salé. Le billet liste différentes alternatives suivant les besoins (non testées).
• Construire un bon analyzer français pour Elasticsearch : un tutoriel assez progressif sur la mise en place d’un analyser français pour vos données dans Elasticsearch. Très pédagogique !

HTML5

• It’s time for 2.0! : Polymer, le framework (?) initié par Google et permettant d’utiliser les Web Components sort en version 2.0. Une éternité que je n’avais plus entendu parler de Polymer. Le point intéressant étant de voir que les “polyfills” requis pour faire fonctionner Polymer réduisent significativement au fil du temps et de l’implémentation requis par les Web Components dans les différents navigateurs.

JSON

• JSON Feed : Un Feed RSS/Atom au format JSON plutôt que XML. On a pu tous en rêver à un moment ou à un autre ou le réaliser à la volée via une conversion XML vers JSON. Voilà une première spécification.

Micro-service

• Enough with the microservices : les micro-services, c’est tendance, tout le monde veut en faire à tort ou à raison. Pour autant, faire des microservices, ce n’est pas simple et ce n’est pas la panacée ou la “balle en argent” qui va résoudre tous vos problèmes. Le billet revient sur les défis d’une approche microservice pour conclure qu’avant d’envisager des micro-services, il vaudrait mieux déjà savoir gérer un monolythe modulaire. La modularité peut déjà répondre à beaucoup d’enjeux de scalabilité, découplage, etc sans avoir besoin de rentrer dans le monde des micro-services et des défis techniques et humains associés.

Postgres

• Why Use Postgres (Updated for Last 5 Years) : ou la revue rapide de toutes les fonctionnalités qui vous feront aimer et utiliser Postgres comme base relationnelle.
• Postgres 10.0 beta1 : la fabuleuse base de données Postgres continue son bonhomme de chemin avec des avancées sur la réplication logique, du partitionning, de la recherche full text sur le stockage JSON & JSONB, un rôle dédié au monitoring, etc.
• Les branches if/else/endif dans psql (PostgreSQL 10) : Avec Postgres 10, le client pourra exécuter des boucles conditionnelles (if/else if/else/end) sur la base d’expressions SQL.

Suite à une mission, synthèse sur la possibilité à date de gérer des conteneurs Linux et Windows avec Docker.

Contexte

Les tests ont été réalisés, début mai 2017, sur les environnements suivants :

• VM Ubuntu 16.04 LTS, à jour, avec Docker 17.03-ee
• VM Windows Serveur 2016, à jour, avec Docker 17.03-ee.

En début de mission, il était supposé qu’une application métier en C# pourrait migrer vers ASP.net Core (la version opensource de .Net et sa déclinaison ASP) et donc sur un conteneur Linux. La suite nous prouva que toutes les APIs ne sont pas (et ne seront pas forcément) dans la version opensource de .Net et qu’il nous fallait envisager des conteneurs Windows à court terme et une infrastructure hybride Windows & Linux, tant au niveau des hôtes que des conteneurs.

Support de Windows dans le monde des conteneurs.

Avant d’aller plus loin, il faut bien avoir en tête la jeunesse du support de Windows dans le monde des conteneurs. Il faut distinguer deux niveaux de supports de l’OS Windows :

• Support de Windows comme machine hôte et au sein de laquelle seraient exécutés des conteneurs,
• Support de Windows comme OS de conteneur, celui-ci s’exécutant sur une machine hôte Windows et/ou Linux

Support de Windows comme machine hôte :

• Docker Toolbox : annoncé en Aout 2015 avec le pré-requis de Virtualbox pour avoir une VM linux en intermédiaire, le projet est maintenant abandonné au profit de Docker for Windows.
• Docker for Windows 10 : disponible depuis Juillet 2016, il permet d’exécuter soit des containers windows, soit des containers linux mais pas les deux en même temps.
• Docker for Windows Server 2016 : disponible depuis septembre 2016. Il ne supporte que des conteneurs Windows.
• Kubernetes supporte, en version alpha, Windows Server 2016 depuis la version 1.5 (décembre 2016). Néanmoins, toutes les fonctionnalités de Kubernetes ne sont pas encore implémentées à date : Kubernetes 1.5 supporting production workloads & Windows Server Support Comes to Kubernetes
• Rancher supporte Windows en version expérimentale depuis la version 1.3 (Janvier 2017) ; Support de Windows dans Rancher

Support de Windows comme OS de container :

• disponible depuis l’été 2016 pour Docker,
• Depuis fin 2016 pour Kubernetes en version alpha,
• Depuis début 2017 en version expérimentale pour Rancher 1.3+.

Dans le cadre de la DockerCon d’Avril 2017, Docker et Microsoft ont annoncé le support des conteneurs Linux sous Microsoft Server 2016 via Hyper-V. Il devrait alors être possible de pouvoir lancer simultanément des conteneurs Linux ET Windows sous Windows Server 2016. Il n’y a pas de date connue pour la sortie de la version supportant cette nouveauté. Il faudra surveiller les prochaines releases trimestrielles de Docker pour savoir quand cela sera utilisable de façon “stable”.

En somme, en continuant notre test plus loin, nous savons que nous entrons dans un monde immature avec un support incomplet.

Cluster Swarm hybride Windows/Linux

La première surprise fut de voir qu’il était possible de créer un cluster Swarm avec un noeud Windows et un noeud Linux sans pré-requis particulier.

Il faut ensuite créer manuellement le réseau overlay pour son application (ce sera supporté dans docker-compose 1.13+, version 3.2 du format). Si vous utiliser docker-compose, il faudra alors spécifier ce réseau comme un réseau externe afin que l’application s’y attache à son lancement.

Afin de piloter le déploiement des conteneurs sur les bons hôtes, il convient d’ajouter des labels (ou de s’appuyer sur des labels existants comme node.platform.OS). Ainsi, un conteneur Windows se déploira sur un hôte Windows et idem pour du Linux.

Jusque là, tout va bien mais c’est là que les limitations se font sentir :

• Le réseau “Overlay”, permettant de ne faire qu’un réseau virtuel avec l’ensemble des noeuds d’un cluser Swarm, n’est supporté que depuis février 2017. Il faut donc s’assurer d’avoir une VM à jour et le patch correspondant.
• Le “Routing Mesh”, qui permet d’avoir de publier un service sur un port donné et d’accéder à ce service depuis n’importe quel noeud du cluster depuis l’extérieur, n’est pas encore supporté.
• Le Service Discovery sous Swarm se fait normalement via des IPs Virtuelles. Ce mode n’est pas supporté par Windows et il faut se rabbatre sur du DNS Round Robbin. Ce mode sera utilisable dans un fichier docker-compose en version 1.13+ et le format 3.2+. En attendant, il faut déployer les services manuellement.
• Enfin, pour exposer des ports, il est obligatoire de les publier au niveau de l’hôte faute de quoi vos conteneurs ne pourront pas communiquer ensemble. L’allocation des ports est dynamique par défaut mais semble être figeable (non testé sous Windows).

Donc au final :

• Swarm, en dehors d’apporter une résolution DNS, n’apporte pas grand chose pour le moment. Si les ports sont figeables et sous réserve de ne pas avoir plusieurs instances d’un même composant pour cause d’unicité de port, alors cela permettrait de faire un peu plus de choses.
• Docker-compose en version 1.13 et le format 3.2+ permettrait de piloter une application déployable sur un cluster Swarm en étant capable de gérer la partie réseau et le endpoint dnsrr. Il faudra attendre la prochaine version stable de docker-ee sous Windows pour le valider.

Bon à savoir également :

• Published Ports On Windows Containers Don’t Do Loopback. Cela vous évitera de perdre du temps à comprendre pourquoi votre conteneur ne répond pas sur localhost sur votre poste windows.
• Pour une docker registry privée supportant les images Windows, il faut une version 2.5+ de la Docker Registry. La version actuelle est 2.6+

Une série de trois vidéos, publiées il y a quelques jours, montrent bien ce qu’il est possible de faire avec Swarm à ce jour.

Pour conclure, il est possible d’utiliser des conteneurs Windows mais que ce n’est pas encore la panacée. Cela reste néanmoins prometteur et les annonces de Microsoft vont dans le bon sens. Il va falloir attendre quelques mois pour envisager cela plus sereinement.

Update 16/8/2017 : La version 17.06 entreprise edition semble résoudre les limites évoquées précédemment.

Container & Orchestration

• Kubernetes 1.6: Multi-user, Multi-workloads at Scale : à l’occasion de KubeCon à Berlin, sortie d’une nouvelle version de Kubernetes avec son lot de nouveautés, de nouvelles fonctionnalités et de fonctionnalités qui évolue de alpha > beta > stable en fonction de leurs maturités respectives. 4 grands axes d’amélioration : scaling avec le support jusqu’à 5.000 noeuds / 150.000 pods est supporté via la fédération de clusters, sécurité avec la mise en place de RBAC (Role Based Access Control) et amélioration de kubeadm pour initialiser votre cluster, scheduling amélioré pour mieux gérer la distribution des workloads sur votre cluster et enfin le provisionning dynamique du stockage pour simplifier la vie et la gestion du stockage par une allocation à la demande.

DevOps

• Déployer son infrastructure Google Cloud Platform grâce à Terraform : Introduction à Terraform, l’outil de provisionning d’infrastructure développé par HashiCorp dans un contexte Google Cloud. D’ailleurs Terraform 0.9 vient de sortir.
• Terraform & Scaleway - Getting Started : un autre exemple d’utilisation de Terraform assez bien expliqué dans un contexte Scaleway
• IT Landscape for sysadmins : Panorama des solutions et outils opensource à usage des profils sysadmin/devops regroupés par catégories.
• Tutorial: How to test your docker image in half a second : Ce tutoriel montre comment tester le bon fonctionnement d’une image docker via l’outil goss. Goss, une alternative à serverspec, permet de tester et valider la configuration d’un serveur ou d’un container dans le cas présent.
• Announcing Longhorn: an open source project for microservices-based distributed block storage : Rancher sort le projet Longhorn, un système de stockage block distribué (et non pas un système de fichier distribué comme Ceph, GlusterFS ou Minio). Compatible uniquement avec Docker pour le moment, prochainement avec Kubernetes, reste à voir justement comment la partie système de fichiers sera traitée. Projet intéressant en tous cas.
• RancherOS Hits General Availability : la mini-distribution Linux optimisée pour lancer des containers Docker, Rancher OS, sort en version GA.

HTML5

• Practical CSS Grid: Adding Grid to an Existing Design : la dernière nouveauté CSS, c’est la grille. Une fois cette grille définie, on peut y positionner les éléments de son choix. L’article permet de voir un cas pratique de mise en place de cette grille dans le cadre de la refonte d’un blog. On y voit aussi les quelques limitations et soucis que l’on peut actuellement rencontrer avec ce nouveau système disponible dans tous les navigateurs ou presque depuis Mars 2017.

Javascript

• What’s new in Angular 4? ou Angular 4.0: La version 4.0 vient de sortir, revue des nouveautés et des changements pour ceux qui s’intéressent (encore) à AngularJS.

Kafka

• Kafka Streams 101 : un article simple et pédagogique sur Kafka Streams, la librairie Java qui permet de consommer ou de produire des messages dans un topic kafka.

MySQL

• How we Upgraded a 22TB MySQL Cluster from 5.6 to 5.7 (in 9 months) : retour d’expérience sur la migration d’un cluster MySQL de 22 To de MySQL 5.6 vers 5.7 et les écueils rencontrés. Intéressant.

Postgres

• https://github.com/begriffs/postgrest : Pour permettre de mettre une API Rest devant votre base Postgres. Un écosystème existe autour de cette solution pour facilement l’intégrer dans votre projet.

Python

• Python’s Instance, Class, and Static Methods Demystified : Tout est dans le titre ! Je connaissais peu les “class methods” et “static methods”. Cela aurait pu m’être utile pour mon précédent projet !
• Building microservices with Python (Part 1, Part 2, Part 3) : un récit assez complet pour batir un microservice s’appuyant sur Flask. Les autres outils intéressants sont connexions (API, oAuth, OpenAPI Specs), Flask-injector pour l’injection de dépendance et fastavro

Admin Sys

• l y a un poisson dans ma coquille ! : J’avais fait il y a quelques années un détour par le shell zsh via “Oh My ZSH” mais je n’étais pas allé bien loin, revenant au final au bon vieux bash. L’article m’a donné envie d’essayer fish et pour le moment, je trouve ça plutôt pas mal. Ne pas se fier à la première impression du site :)
• Pour faire fonctionner virtualenv(wrapper) avec Fish: VirtualFish
• Pour enrichir votre Fish, vous pouvez vous appuyer sur fisherman ou le projet oh-my-fish

Containers

• Adventures in GELF : où l’on apprend notamment que les logs sont par défaut au format JSON et surtout qu’il n’y a pas de rotation des journaux par défaut :’( ; l’article montre ensuite les intérêts du format GELF (avoir un message sous la forme d’un dictionnaire/tableau au format clé/valeur) et les limites (connextion UDP) avec les solutions de contournement actuelles et les solutions à venir prochainement.
• Announcing Docker Entreprise Edition : Docker Inc annonce une version “Docker Community Edition” et une version “Docker Entreprise Edition” (avec support). Il y aura désormais une version stable trimestrielle (avec changement de versionning à la Ubuntu : YY.MM et une politique de support de 4 mois) ou une version “bleeding edge” mensuelle pour la version communautaire (support mensuel). Pour la version entreprise, c’est trimestrielle avec 1 an de support & maintenance. Docker Inc se dote également d’un programme de certification pour la partie matérielle, système sous jacent, les plugins et les conteneurs en eux même. Une réponse notamment fait à Docker de trop changer le comportement de docker et de ses composants/fonctionnalités d’une version à une autre.
• CoreOS a l’intention de donner rkt à la Cloud Native Computing Foundation qui hébergedéjà de nombreux projets cloud dont Kubernetes. Docker Inc va faire de même avec containerd. Si le billet de CoreOS laissait penser un travail commun, le billet de Docker ne me donne pas cette impression. Donc a priori chacun va travailler de son côté et on regarde qui sort vainqueur à la fin ? La guerre des containers n’est pas finie…
• From dotCloud to docker : Une retrospective sur l’histoire de Docker.

Cloud

• Google Cloud Platform: your Next home in the cloud : Google avait jusqu’à présent plutôt un positionnement de marché de niche où pour aller sur leur cloud il fallait adopter leurs produits. Avec la Conférence Google Cloud Next 2017, s’opère un sacré changement et que Google semble revendiquer : devenir un acteur global du cloud et être en mesure d’accompagner ses clients sur l’ensemble de leurs sujets. S’il ne fallait qu’un exemple, je pendrais bien celui de la certification de SAP HANA sur GCP. On notera aussi l’arrivée de Postgresql en service managé, de nouveaux langages pour App Engine, etc. Je vous laisse trouver les nouveautés mais pour moi la nouveauté est ce changement de positionnement de Google. Les autres fournisseurs de cloud ne doivent pas forcément être ravis de ce changement ; reste à voir si Google convaincra les autres clients. Si par ailleurs, les clients sont déjà chez Google Suite, on peut imaginer qu’ils passent plus aisément dans Google Cloud pour n’avoir qu’un fournisseur…
• 100 announcements from Google Cloud Next 17 : la liste complète des 100!! annonces…

DevOps

• Site Reliability Engineering : le terme de Site Reliability Engineering (SRE) prend de plus en plus d’ampleur depuis quelques mois. Un SRE est une personne avec un profil plutôt développeur mais qui est aussi à l’aise sur la partie “opérations” et donc en mesure d’assurer l’exploitation de son application (avec les incidents liés) ; il travaille donc sur les 2 tableaux pour son application. Google partage dans ce livre son expérience de la mise en place de ses équipes SRE pour une partie de leurs produits.

GraphQL

• Use all the databases - part1 et Use all the databases - part 2 : Deux billets présentant GraphQL qui se veut un successeur de REST. L’article montre comment avec une seule requête faite sur un endpoint GraphQL, on peut aller récupérer des données dans plusieurs bases de données. Intéressant, mais à voir si cela n’est pas trop magique et si on ne crée pas un SPOF de l’application en procédant ainsi.
• GraphQL Guide : site du livre en cours de préparation sur GraphQL
• Appolo : le client de référence sur GraphQL utilisable notamment avec React (Native), AngularJS, iOS & Android.

HTML5

• Managing Push Subscriptions : nouvel article d’une série sur les bonnes pratiques à adaopter lorsque l’on génère des notifications en Push via WebPush.
• State of Responsive Images 2017 : en version courte, c’est mieux, mais c’est pas encore tout à fait ça. Plus sérieusement, un état des lieux sur les images responsives, ce qui a été fait, les chantiers incomplets voire ratés.

Javascript

• NPM vs Yarn : une revue assez détaillée des avantages de Yarn sur NPM.

Opensource

• What it feels like to be an open-source maintainer, Sustainable Open Source: The Maintainers Perspective or: How I Learned to Stop Caring and Love Open Source et Time to leave : Le premier billet revient sur la difficulté et la peine à maintenir un projet open source rencontrant un certain succès. Les deux autres billets sont des réactions à ce premier billet encourgeant soit à apprendre à ne plus se soucier autant du projet, voire à quitter le projet. Des réflexions intéressantes que l’on peut appliquer aussi à sa façon de gérer un projet et la rapidité à laquelle on répond aux sollicitations de ces clients…

Queues & Messages

• Why Messaging Queues Suck : Réflexion intéressante autour des bus de messages et de la soi-disante agnosticité des producteurs de topics vis à vis de leur consommateurs. Au final, de part les procédures de définition d’accès à un topic (dans un contexte cloud), la partie agnosticité est toute relative. Du coup, pour l’auteur, il est plus intéressant de faire des “endpoints” HTTP entre 2 services et que ce soit le client qui implémente son propre système de queue en interne. Cela mérite réflexion et peut avoir ses intérêts en fonction de votre architecture.

Sécurité

• Announcing the first SHA1 collision : Google a annoncé la première collision obtenue avec le protocole de chiffrement SHA-1. Une collision est obtenue lorsque la signature de deux fichiers est identique, alors que théoriquement, chaque fichier devrait avoir une signature unique. Même si les conditions pour obtenir cette collision reste assez peu exploitable de part les ressources nécessaires pour le faire, la dépréciation de SHA-1 est accélérée. Par ex, Firefox, qui avait prévu de le finaliser l’abandon du support de SHA-1 avec la version 52 du navigateur vient de le faire en accéléré suite à cette publication et Google Chrome en a fait de même.
• Incident report on memory leak caused by Cloudflare parser bug : un bug identifié par l’équipe de Google a révélé que depuis septembre 2016 et jusqu’à fin février 2017, un composant de l’infrastructure de Cloudflare divulguait des informations sensibles (identifiants, cookies, etc) de ses utilisateurs lorsqu’il parsait des pages HTML mal formées. L’article de NextImpact l’explique bien, il faut globalement changer vos mots de passes et renouveller vos cookies pour les sites utilisant Cloudflare (une liste ici ou ce site)
• HTTPS : De SSL à TLS 1.3 : rétrospective et explications sur les différents mécanismes de chiffrement disponibles, leurs forces/faiblesses et l’avenir avec TLS 1.3