Web, Ops, IoT & Time Series

Pour un projet en cours de finalisation, j’ai utilisé le CMS Grav et j’ai décidé tant pour mon développement en local que pour l’environnement de production de déployer cela sous la forme de container docker et d’utiliser Traefik comme reverse-proxy et m’appuyer notamment sur son support natif et dynamique des containers docker.

Premiers pas…

J’avais initialement publié une image nsteinmetz/grav basée sur l’image officielle PHP:apache mais elle ne me convenait pas totalement :

• Utilisation d’apache2 alors que j’ai basculé depuis longtemps sur nginx
• L’image PHP:apache est basée sur Debian (taille plus importante qu’une image basée sur Alpine)
• Pas d’utilisation des volumes (je n’ai pas pris le temps de les déclarer)

Pour mémoire et à toutes fins utiles, le Dockerfile - nsteinmetz/docker-grav :

Container & orchrestration

• Kompose: a tool to go from Docker-compose to Kubernetes : en cours d’incubation chez Kubernetes, ce projet permet de faciliter la transition de Docker à Kubernetes en transformant les fichier docker-compose.yml en fichiers Manifests Kubernetes. Un pivot intéressant si on considère que les développeurs vont utiliser Docker (et au mieux Swarm) pour leurs environnements de développement et en production éventuellement Swarm et ensuite vouloir migrer vers Kubernetes pour ses fonctionnalités plus évoluées.
• Introducing Distributed Cheese: Traefik 1.1 Camembert Is Out! : Traefik, le reverse proxy moderne qui sait s’interfacer notamment avec Docker, Consul, Kubernetes et plein d’autres est sorti en version 1.1.x. Cette version apporte notamment le support de l’API Docker Swarm (Docker 1.12+), une meilleure gestion des contraintes, le support de Mesos, une meilleure gestion des affinités de sessions, un mode cluster pour Traefik (expérimental) et une image officielle docker basée sur alpine. J’ai profité de l’installation d’un nouveau serveur pour déployer Traefik et c’est vraiment agréable de pouvoir déclarer dynamiquement ses containers docker. Par ailleurs, je rappelle que je maintiens des images docker de Traefik pour sa version ARM
• Docker for AWS Public Beta : l’offre Docker pour AWS passe d’une version alpha à une verion beta. On notera essentiellement qu’il s’agit d’une version plus intégrée avec l’offre AWS que si l’on déployait un docker soi-même. A suivre mais attention à vérifier qu’il n’y a pas un lock-in qui se crée à la fin, que l’intégration apporte un plus et ne nuit pas à la portabilité des containers.

Dashboard, Monitoring

• What’s new in Grafana v4.0 : la fonctionnalité phare de cette version est la capacité de définir des alertes au niveau de chaque élément d’un dashboard. Pour se faire il faut définir les règles à appliquer et ensuite s’appuyer sur la partie notification. Pour ceux qui étaient tentés d’installer Chronograf 1.1 (béta) pour avoir cet alerting en plus des dashboards adhoc de Grafana, ils pourraient bien finalement rester dans Grafana (dont la maturité n’est plus à prouver) plutôt que d’attendre que Chronograf se stabilise… A moins que Chonograf n’apporte une valeur ajoutée de part son intégration native avec Telegraf.

Pépites

• Si vous pensiez que toutes les villes commencent par une lettre, maintenant vous savez que c’est faux avec la ville de ’s_Herenelderen. Vous pouvez mettre vos regexp à jour !
• These unlucky poeple have names that break computers : même si l’article concède que ce problème est de moins en moins vrai au fur et à mesure des progrès réalisés et de la prise de conscience par les développeurs, mais s’appeller “Null” ou avoir un nom de famille très long (36 caractères dans l’exemple donné ou même 8 au Japon quand l’habitude est de 4…), cela pose des tas de problèmes dans la vie du quotidien.

J’étais à DevOps Rex hier ; elle m’avait intéressé de part son intitulé :

La conférence devops 100% retour d’expérience.

En attendant les vidéos, vous pouvez déjà retrouver les slides sur le compte slideshare devopsrex.

La conférence a plutôt bien tenu son objectif au travers de 9 talks mélangeant des réussites et des échecs mais aussi des contextes de petites et grosses entreprises.

En synthèse :

• DevOps, c’est avant tout une culture, un état d’esprit et des pratiques, bien avant d’être des outils. J’en suis convaincu, la salle le semblait aussi. C’est déjà ça d’acquis mais l’audience était biaisée.
• L’agile, c’est bien car cela rapproche Métier et Développeurs mais s’il n’y a pas du DevOps dans la foulée pour déployer au fur et à mesure la valeur apportée par les cycles itératifs, c’est idiot. La valeur n’existe que si la fonctionnalité est livrée en production. Il faut donc envisager le “Biz/Dev/Ops” comme j’en ai parlé à l’E1 Conférence lors de mon talk sur le Généraliste (transcript
• Des synergies également entre DevOps et le Lean dans tout ce qui touche à la réduction de gaspillage et à l’amélioration continue : fournir l’architecture adaptée (pas de sur-engineering), itérer, etc.
• Notion de juste investissement :
  • Tout automatiser n’a pas de sens mais plutôt que d’avoir des formules complexes pour mesurer le ROI de l’automatisation, prendre simplement une règle de douleur comprise entre 1 et 10 et automatiser tout ce qui représente une douleur supérieure à 5.
  • Le juste investissement fait aussi référence à l’équilibre entre l’agilité et la flexibilité que l’on veut avoir et l’automasation/industrialisation. Cette dernière peut parfois nuire à cette agilité/flexibilité tout comme elle peut la faciliter (en ayant automatisé un sujet, on a du temps pour autre chose)
• Au delà de la notion de culture et d’automatisation, on retrouve la notion de mesure et de partage des indicateurs (KPI). La mesure permet de factualiser/objectiver les choses et d’avoir du feedback sur nos actions. En partageant nos indicateurs et en connaissant les indicateurs des équipes avec lesquelles on travaille, cela peut être utile qu’ils y aient accès mais nous pouvons aussi les prendre en compte pour nos activités.
• Dans un contexte de grande entreprise, où la maturité devops peut varier, il est plus intéressant de partager les indicateurs que d’imposer des outils. En laissant chaque équipe adopter les outils dont elle a besoin mais en remontant des indicateurs commun, on évite que des équipes perdent du temps à réimplmenter leurs pratiques actuelles dans un autre outil sans leur apporter une réelle valeur ajoutée mais on leur demande de remonter des indicateurs communs afin de pouvoir évaluer la progression d’ensemble de l’entreprise.
• Pour mettre en place une démarche DevOps, s’il faut bien partir de la littérature existante, il convient surtout de la contextualiser à son entreprise et ensuite aux équipes voire à l’application concernée afin d’être pertinent.
• Comme tout “transformation”, il est important d’avoir un management facilitateur a minima voir sponsor. Le succès se fait tant via des initiatives bottom/up que top/down. S’il est important que les objectifs soient définis globalement et éventuellement par le management, il est tout aussi important de laisser une forte autonomie aux équipes opérationnelles pour leur permettre de trouver leur organisation afin de répondre à ses objectifs.

Pas de véritable découverte durant cette conférence pour moi. Plutôt une confirmation et une objectivation d’opinions et/ou d’intuitions que je pouvais avoir jusqu’à présent et de quoi alimenter certaines réflexions.

Kubernetes

• Introducing Operators: Putting Operational Knowledge into Software : l’équipe de CoreOS vient de dévoiler les Operators, un complément à Kubernetes permettant, pour des applications stateful, de gérer une logique “métier” (création/suppression, perte d’un composant, mise à jour, sauvegarde, etc). Autant pour des applications stateless, il suffit d’instancier une nouvelle instance du composant, autant pour des applications stateful, il faut parfois avoir des commandes supplémentaires ou récupérer des informations des autres composants. C’est cette logique que les Operators apportent. On le comprend mieux en lisant les billets sur l’Operator d’etcd ou celui de Prometheus

TICK (Telegraf, InfluxDB, Chronograf, Kapacitor)

• InfluxDB 1.1 released with up to 60% performance increase and new query functionality : des améliorations en termes de performance, stabilité (RAM) mais aussi de nouveaux filtres de requêtage.
• Kubernetes monitoring and utoscaling with Telegraf and Kapacitor : un exemple d’utilisation de la plateforme TICK pour monitorer son cluter Kubernetes mais aussi gérer de l’autoscaling via Kapacitor.
• Announcing the new Chronograf, a UI for the TICK stack & a complete open source monitoring solution : L’ancienne version de Chronograf se voulait une copie de Grafana et elle est abandonnée. La nouvelle version semble vouloir inspecter les données stockées dans Influxdb pour vous présenter des dashboards mais surtout faciliter l’interaction avec Kapacitor pour définir facilement des seuils et des alertes. La nouvelle version de Chronograf co-existerait donc avec Grafana dont elle pourrait reprendre des dashboards via l’API. Comme le dit l’annonce, c’est encore une version alpha de Chronograf qui est présentée ici, cela doit évoluer tous les 15 jours environ en fonction des retours de la communauté. A noter que le produit est (enfin) open source comme le reste des composants. Pour plus d’info, voir le dépot de chronograf et la doc d’installation

Gestion des données personnelles

• Anonymisation des données : après la fuite des données chez Michael Page pour défaut d’anonymisation des données sur un environnement hors production, le billet sur les stratégies d’anonymisation des données est fort utile et judicieux. Comme le rappelle le billet, avec la nouvelle réglementation européenne sur la protection des données(RGPD), l’entreprise ayant une fuite de données peut être condamnée à payer jusqu’à 4% de son chiffre d’affaires et 20 millions d’euros à compter de mai 2018 - le réglement est applicable depuis mai 2016.

Elasticsearch

• Elastic Stack 5.0.0 Released : La version 5.0 de l’Elastic Stack (Elasticsearch, Kibana, Beats, Logtstash) vient de sortir. Concernant Elasticsearch, on notre l’arrive d’une ingest node pour mieux traiter vos données, des améliorations de performances et plein d’autres choses dont on a parlé ici précédemment.
• Les leviers d’Elasticsearch pour le traitement des spécificités linguistiques : le billet présente les différentes capacités d’Elasticsearch pour analyser plus ou moins finement un texte en fonction de vos besoins. Assez bien documenté pour voir les comportements des différents filtres d’Elasticsearch.

Conteneurs

• Stratégies de placement de conteneurs Docker (partie 1) et Stratégie de placement de conteneurs Docker (partie 2) : les billets cherchent à présenter et synthériser les stratégies de placement de containers offertes par les différents solutions : Nomad, Fleet, (Docker) Swarm et Kubernetes. Le premier billet porte plutôt sur la labellisation des ressources et d’une stratégie de déploiement associée et le second porte d’avantage sur la stratégie de déploiement 1 noeud / 1 container ou bien 1 noeud / n containers

CMS

• Wagtail 1.7: Elasticsearch 2, Smaller Images, CloudFront : Tout est dans le titre ou presque : support d’Elasticsearch 2, une plus grande flexibilité sur le degré de compression des images et le support du CDN Amazon CloudFront.
• Grav 1.1.8 : le CMS Grav continue à améliorer sa version 1.1.x ; terminant un premier projet avec Grav, je suis à la fois séduit par son potentiel et sa flexibilité que frustré par quelques défauts de jeunesse (?). Cela fera l’objet d’un futur billet…

DevOps

• Ansible 2.2 Delivers New Automation Capabilities for Containers, Networks and Cloud Services : Mise à jour mineure d’Ansible qui lui aussi s’améliore au fil des versions. Cette version apporte surtout des mises à jour sur les composants networks (gestion d’équipements réseau), des améliorations sur la gestion des plateformes cloud et sur la couche réseau de docker (docker_network)

Javascript

• Yarn: A new package manager for JavaScript : Facebook sort une alternative à npm, se voulant plus fiable et prédictive (voire idempotent ?) pour le contenu de node_modules, plus rapide (parallélisation et cache hors ligne) et plus sûr avec des mécanismes de contrôle de signature de fichiers. yarn reste compatible avec npm et son registre.
• Angular 2 Is Out: Should You Start Using It? : la réponse courte est non pour des projets professionnels pour de bonnes raisons (l’écosystème n’est pas encore à jour, peu de personnes expérimentées avec Angular2, le manque de recul/stabilité sur cette version, les changements à venir, etc) et de moins (?) bonnes raisons (documentation incomplète, le pré-requis sur TypeScript). Donc à apparendre tranquillement ou à utiliser pour des POC mais pour le reste, capitalsier sur la version 1.5 et profiter du fait qu’avec les dernières version d’Angular, on peut écrire du code dans l’objectif d’Angular2.

MySQL

• Using the loose_ option prefix in my.cnf : Une bonne astuce à savoir dans MySQL, en préfixant une variable avec loose_, alors au lancement, MySQL va ignorer cette option si elle ne la connait pas. Le billet donne pour cas d’exemple la mutualisation d’un fichier de configuration entre la version MySQL de Percona (qui a ses propres variables) et celle de MySQL ou encore l’anticipation de la mise à jour de MySQL qui permet de déployer un futur fichier de configuration sans craine l’arrêt du service.
• MySQL 5.7 Performance Tuning Immediately After Installation : l’optimisation d’une base MySQL ressemble parfois à de la magie noire, à moins d’avoir lu High Performance MySQL. Le billet permet de voir les premières variables à ajuster et donne des pistes vers d’autres points à surveiller.

DevOps

• Ansible Galaxy (Via) : Ansible Galaxy est un hub (public) pour l’outil d’automatisation Ansible où il est possible de diffuser/partager/réutiliser des roles ansible, que l’on peut ensuire réintégrer dans ses playbooks. Red Hat vient de décider de la publication de son code source, permettant ainsi d’avoir son progre serveur Galaxy dans vos murs et partager ainsi vos rôles ansible au sein de votre organisation. Vous pouvez aussi contribuer au code pour améliorer le Galaxy public !

Vie Privée

• Your Social Media Fingerprint : Comment permerttre à un tiers (ici les services en ligne) de récolter des données à votre insu juste grâce au favicon de leur site. L’exmple est connu mais bien expliqué. Il en est de même pour les polices (fonts) hébergées chez Google & co et plus généralement pour les ressources distantes. Toutes les ressources distantes ne vont pas donner le même volume d’information mais a minima, on a votre IP, la date et le site source… Dans la mesure du possible et pour protéger vos utilisateurs, pensez à rappatrier les ressources distantes sur votre site.

Container & Orchestration

• Docker a annoncé un partenariat avec Microsoft pour le support de Docker dans le cadre de Windows Server 2016 mais aussi sur la plateforme Azure. Docker a publié deux billets sur l’introduction à Docker sur Windows Server 2016 et la création et l’exécution de containers Docker dans un environnement Windows. Si l’on peut saluer la plus grande simplicité à gérer des containers docker sous Windows, aller jusqu’à les déployer sur des environnements Windows, c’est un autre pas…
• Kubernetes 1.4: Making it easy to run on Kubernetes anywhere : La version 1.4 porte essentiellement sur la facilité à installer et déployer un cluster Kubernetes avec l’arrivée notamment de kubeadm ou encore le Dashboard. Cette version apporte plein d’autres améliorations, chacun devrait y trouver son compte.
• Forkera ou pas, cela s’agite dans l’univers des containers : A docker fork, the split is now on the table, certains reprochaient il y a quelques semaines à Docker Inc une instabilité et l’ajout de fonctionnalités rendant compliqué le fait de baser des outils sur docker quand Docker Inc cherchent à toujours avancé. On vient de franchir un nouveau pas avec RedHat et Google qui cherchent à créer un nouveau format pour s’affranchir de Docker et de rkt, supporté par CoreOS. Au final, via CRI-O, le but serait surtout d’avoir une interface permettant aux différents moteurs de containers (docker, rkt, etc) de s’interconnecter facilement avec Kubernetes. La conclusion de ce dernier article est finalement peut-être la plus éclairante sur le sujet : c’est davantage la façon d’orchestrer qui va prévaloir que ce que l’on orchestre.

Ansible

• Ansible Container 0.2.0 Release : ansible-container est une extension ansible qui doit permettre de créer des images docker et de les orchestrer depuis des playbooks Ansible. Cette version 0.2 montre les améliorations apportées grâce aux retours de la communauté et le chemin restant à faire pour être plus facile à utiliser.

Base de données

• Postgres 9.6 Released ! : comme tous les ans au mois de septembre, une nouvelle version de la base de données Postgres. Au programme notamment de cette version 9.6 : parallélisme des requêtes, nouveaux mode de réplication synchrone et de fédération, amélioration des recherches orientée phrase (ie ensemble de mots).
• RethinkDB is shutting down : l’entité commercial derrière RethinkDB (base documentaire orientée temps réel) ferme faute d’avoir trouvé un modèle économique adéquat. Il y a une réflexion pour voir comment la communauté peut continuer à maintenir RethinkDB et à ouvrir le code d’Horizon.

Elasticsearch

• An Elasticsearch cheat sheet : une collection de commandes utiles pour gérer un cluster Elasticsearch dès lors que l’on sort d’un usage basique.
• Docker Stats Monitoring: Taking Dockbeat for a Ride : une introduction à Dockbeat (anciennement Dockerbeat) et son intégration dans une plateforme ELK. Il a le mérite de remonter des métriques sur vos containers (CPU, RAM, etc). Cela n’empêchera pas de devoir ajouter une seconde solution pour la remontée des logs systèmes / applicatifs.

Frontend

• Vue 2.0 is Here! : le framework Javascript qui fait de l’ombre à AngularJS voir même à Réact sort en version 2.0 avec des améliorations de performances, améliorations des API, etc. Pas encore eu le temps de tester ça mais de la présentation vue à DevoxxFR cela semblait plus léger et moins inutilement complexe qu’AngularJS.

Docker

• Lessons learned from using Docker Swarm mode in production : ce retour d’expérience confirme mon ressenti (pas encore mis à l’épreuve des faits) sur Docker et l’intégration de Swarm depuis la version 0.12. A la fois il est très simple de créer et opérer un cluster Docker Swarm mais il reste quelques défauts de jeunesse. A voir comment les prochaines version de docker vont consolider/maturer tout cela.
• ARM Fixes for Docker Machine 1.8.0 : Si comme moi vous souhaitez utiliser docker-machine depuis un PC 64 bits vers un cluster de machines ARM (Raspberry, etc) utilisant HypriotOS ou Raspbian.

Logs

• 5 Logstash Alternatives : Le billet compare Logstash avec Filebeat, rsyslog, syslogng, logagent et fluentd. Il donne les forces/faiblesses de chaque solution et les cas d’usage les plus adaptés pour chaque solution. Cela reste très orienté dans un contexte Elasticsearch, on pourrait par ex songer à Telegraf et à la plateforme TICK

Sécurité

• Is HTTP Public Key Pinning Dead? : dans l’édition précédente, j’ai parlé du Mozilla Observatory qui évalue notamment cette fonctionnalité qui est HPKP. Ce billet montre les limites et les risques de l’implémentation actuelle. Le risque le plus grand étant que le propriétaire du site perde les clés requises au bon fonctionnement d’HPKP et se retrouve à la porte de son site…

Elasticsearch

• Running High Performance Fault-tolerant Elasticsearch Clusters on Docker - vidéo : une présentation des options et des bonnes pratiques pour utiliser Elasticsearch dans un contexte Docker.
• Elastic Stack Release - 5.0.0-beta1 : l’écosystème Elastic continue son bonhomme de chemin vers la 5.0 avec la sortie de la version 5.0-beta1. Au delà des diverses améliorations, il est noté que Elastic requiert 2Go de RAM par défaut (au lieu de 1 Go); de quoi écarter Elasticsearch d’une utilisation dans un contexte ARM (Raspberry, etc) ?

Base de données temps réel

• Firebase, le nouveau Parse ? : historiquement une base de données temps réel, Firebase est devenue une plateforme pour développer et déployer des applications mobiles avec bon nombre de services pratiques/utiles (Remote storage, Cross platform, Push, Remote Config, Test Lab, etc). Le billet fait un état des lieux mais insiste en fin de billet sur les limites qui sont la consolidation de données chez Google et les tarifs si vous avez une utilisation intensive. Si c’est surtout le coté base de données temps réel qui vous intéresse, il vaut peut être mieux regarder du côté de RethinkDB et leur service Horizon qui package RethinkDB avec Node.JS pour avoir des API et des services complémentaires (authentification, etc)

Containers

• Security Best Practices for Kubernetes Deployment : les points ne sont pas propres à Kubernetes : segmentation applicative via les namespaces, segmentation réseau, quota de ressources, utilisation d’images approuvées, maintient des images à jour, etc.
• Docker + Golang : le billet présente des astuces pour compiler un programme Go au travers de containers pour illustrer différents besoins (cross-compilation, etc)
• 12 fractured apps : une revue des bonnes pratiques à adopter pour gérer les fichiers de configurations, les connections à des bases de données dans un monde orientée micro-services.

AngularJS

• AngularJS 2.0 : la version 2 du framework Javascript AngularJS de Google est (enfin) sorti et se dote d’un nouveau site angular.io. Etrangement, j’ai l’impression que c’est un non événement ? Cette version mainte fois discutée, tant attendue et au final ? Ou peut être que React est passé par là et à occuper le trou laissé par cette réécriture d’Angular ?

Kafka

• Event sourcing, CQRS, stream processing and Apache Kafka: What’s the connection? : après un rappel sur ce qu’est CQRS et l’Event Sourcing, le billet décrit les apports de Kafka (et Kafka Streams / Kafka Connect) pour ce type de projet.
• Announcing the Certified DataStax Connector for Confluent Platform, Kafka Connect se dôte d’un connecteur Cassandra. Il s’agit d’un connecteur de type “Sink’, c’est à dire que vous pouvez pousser des données de Kafka vers Cassandra.

TICK (Telegraf, InfluxDB, Chronograf et Kapacitor)

• La plateforme TICK atteint le palier de la version 1.0 ; InfluxDB, Telegraf et Kapacitor. Pas de grosses nouveautés dans ces releases, juste une stabilisation et le tampon 1.0 ; Chronograf est aussi estampillé 1.0 même s’il s’est fait discret depuis la version 0.13. A voir s’il rattrape son retard sur Grafana…

Sécurité

• Obtenir une bonne note sur Mozilla Observatory : HTTPS/CSP/SRI/CORS/HSTS/HPKP/etc. : Le Mozilla Observatory est un outil d’aide à l’évaluation de la sécurité de votre site web. Le billet vulgarise les technoligies sous-jacentes et donne des pistes pour avoir une bonne note à ce test et améliorer la sécurté de vos sites.

Postgres

• Is Bi-Directional Replication (BDR) in Postgres Transactional? : En gros BDR fonctionne si vous n’avez pas de contraintes transactionnelles fortes. D’autres solutions sont présentées sur le wiki de la fondation Postgres: Replication, Clustering, and Connection Pooling

Petite collection de liens pour reprendre les bonnes habitudes en cette période de rentrée…

Laravel

• Résumé de la Laracon EU 2016 : reconsidérant l’écosytème PHP, je regarde de près Laravel et espère y trouver un framework plus léger que Symfony et plus dans la lignée d’un framework comme Django

Docker

• Releasing HypriotOS 1.0.0 “Blackbeard” : l’équipe Hypriot qui assure le port de Docker sur l’architecture ARM vient de sortir la version 1.0 de son OS avec Docker 1.12 et les dernières versions de docker-compose et docker-machine. De quoi pouvoir tester les apports de la version 1.12 sur vos Raspberry Pi.

Lean

• Lean et Architecture IT : l’architecture et l’ingénierie sont au service de la valeur que l’on apporte aux clients. Il faut donc batir non pas la plateforme idéale mais la plateforme adaptée aux besoins du client. Toujours utile de le rappeeler et totalement en phase avec cette idée, puisque c’est notre philosophie.