CérénIT

Le blog tech de Nicolas Steinmetz (Time Series, IoT, Web, Ops, Data)

Web, Ops & Data - Aout 2018

dockerkubernetescassandrareaperistioservice-meshcloudopensourcerediskafkamysqlpostgresconfluentopenmetricsprometheusfluxlanginfluxdbtimescaledb

Cloud & Open Source

Container et orchestration

(Big) Data & (No)SQL

  • Reaper 1.2 Released : l'outil de gestion des "réparations" des données d'un keyspace Cassandra, initialement réalisé par Spotify et désormais maintenu par The Last Pickle, vient de sortir en version 1.2 avec son lot d'améliorations. Pour un client, il a été déployé, ce qui me permet de pouvoir contribuer modestement (#472, #473, #474)
  • Re-Bootstrapping Without Bootstrapping : que faire lorsqu'un noeud d'un cluster Cassandra est sorti depuis plus longtemps que le temps de grace défini ? Le billet répond à la question pour ne pas repartir de zéro et le faire de façon "marginale".
  • Introducing Confluent Platform 5.0 : à l'occasion de la sortie d'Apache Kafka 2.0, une nouvelle version de la plateforme Confluent sort également avec les dernières nouveautés de KSQL, des améliorations coté stabilité/sécurité (Auth LDAP, Disaster Recovery, etc). Allez lire les notes pour en savoir plus et voir ce qui relève de la version 0SS et de la version Entreprise.
  • Showdown: MySQL 8 vs PostgreSQL 10 – Hacker Noon : l'article confirme qu'avec MySQL 8.0, MySQL rattraperait Postgres au niveau des grandes fonctionnalités de base.

DevOps

  • The Site Reliability Workbook : Google sort un complément à son livre "Site Reliability Engineering". Le livre est sensé donner des conseils pratiques ou partager des eemples issus de la réalité dans le cadre de la mise en place d'une démarche SRE.

Timeseries

  • Querying Prometheus with Flux (video - slides) : Paul Dix, CTO d'InfluxData, montre comment il est possible de requêter des données issues de Prometheus via Flux, le nouveau langage qu'InfluxData est en train de créer et dont l'objectif est de pouvoir manipuler des données temporelles. Ce cas permet de montrer l'utilisation de Flux dans un contexte autre qu'InfluxDB.
  • CNCF to Host OpenMetrics in the Sandbox : OpenMetrics est une initiative de standardisation des formats de métriques - le projet rentre donc dans l'initiative de la CNCF.
  • OpenMetrics to Join the CNCF ; Paul Dix a annoncé le support de ce format comme "citoyen de première classe" pour une version ultérieure d'InfluxDB. Le billet fait l'état des lieux du support au niveau de Telegrad et de Kapacitor.
  • Prometheus Graduates Within CNCF : toujours coté CNCF, Prometheus, la plateforme de métriques, est le second projet (après Kubernetes) à passer au niveau officiel.
  • TimescaleDB vs. InfluxDB: purpose built differently for time-series data : Comparaison par les gens de TimescaleDB entre leur produit TimescaleDB et InfluxDB. Même s"il est forcément un peu biaisé, il reste intéressant.

Web, Ops & Data - Juillet 2018

grafanakubernetesservice-meshansiblebrigadehelmdraftsqldevopsarchitecturemicroservicefluxtickinfluxdbdockerchronograffluxlang

Architecture

  • Goodbye Microservices: From 100s of problem children to 1 superstar : L’article fait pas mal de "bruit" en ce moment mais je ne suis pas sur qu’ils arrivent à la bonne conclusion au final ; Partir de microservices et multiples dépots gits pour revenir à un monolithe/mono dépot git, j'ai l'impression que la réponse au travers des outils n'adresse pas le problème de fond à savoir la gouvernance de l'ensemble. En effet, si les versions différaient tant que cela, l'approche centralisé a peut être mis un terme en forçant tout le monde à se rencentrer sur une version donnée mais s'il n'y a pas de règles, le résultat sera le même prochainement mais ils auront moins de liberté.
  • Miniservices as a Realistic Alternative to Microservices : du coup, pour réduire les frictions, certains proposent de faire des micro-services plus gros avec le risque d'arriver à plein de moyens monolites...
  • Je mets donc pour rappel cet article que j'ai déjà mentionné : Enough with the microservices. Il rappelle que c'est surtout la modularité et une architecture propre du code qui donne de la flexibilité. Et puis tout le monde n'a ni le contexte, ni la maturité pour se lancer dans les micro-services.

Automatisation

  • Ansible 2.6: Your Time Has Come! : une version de consolidation avec des améliorations coté cloud et surtout sur l'utilisation de la mémoire lordque l'on utilise les "Dynamic Includes".

Container et Orchestration

  • Blog: Kubernetes 1.11: In-Cluster Load Balancing and CoreDNS Plugin Graduate to General Availability : Kubernetes continue son travail de consolidation et de stabilisation.
  • Service Mesh: Promise or Peril? : si les service mesh peuvent paraitre attrayant, leur intégration n'est pas forcément évidente et il faut aussi prévoir cette couche intermédiaire dans le développement de votre application. Leur utilisation n'est donc pas toujours recommmandée/souhaitable - l'article propose de faire le point sur le sujet.
  • Container Native Development with Ralph Squillace : cet épisode de podcast petmet d'avoir une présentation d'Helm (package manager), Bridage (gestion de workflow kubernetes) et Draft (aide à la conteneurisation d'une app). D'autres outils sont mentionnés en fin d'épisode pour agrémenter son quotidien (extension vscode, etc).
  • Extending Support Cycle for Docker Community Edition : A l'occasion de la sortie de Docker CE 18.06, quelques ajustements : les versions stables sortiront tous les 6 mois maintenant (et plus tous les 3 mois) et avec une période de maintenance de 7 mois, le canal edge (monthly release) est arrêté au profit d’un canal nightly, docker for Windows/Mac gardent une release mensuelle (pour le canal edge), plus de packaging par distribution pour mieux coller à l’actualité de la distribution.

Dataviz

DevOps

(No)SQL

Timeseries

Web, Ops & Data - Mars 2018

grafanatickchronografinfluxdbdatavizansiblesparkdockerkubernetescncfsupersetjavaLet's encryptpostgrespythond3.js

Automatisation

  • Ansible 2.5: Traveling space and time : au programme de cette nouvelle version : des namespaces pour les "facts", la capacité d'interdire des modules, des nouvelles "variables magiques" (les magic vars sont des variables spécifiques à Ansible et l'exécution des playbooks). On notera aussi des améliorations sur le support Windows, des nouveaux modules cloud (AWS, GCP, Azure, VMWare) et des nouveaux plugins.

Container et Orchrestration

Dataviz

Java

  • No Free Java LTS Version? : Oracle change ses pratiques de distribution du JDK Oracle (Une version majeure tous les 6 mois, moins de report de patches, etc).

Let's encrypt

  • ACME v2 and Wildcard Certificate Support is Live : Let's Encrypt va donc fournir des certificats wildcard (*.domaine.fr). Si je m'étais réjoui de l'idée au début, je ne vois finalement pas ou peu l'intérêt du fait de la méthode de validation (enregistrement DNS avec le temps de propagation associé). En dehors du cas où l'on dépassait les limites d'enregistrement de Let's Encrypt en terme de nombre de certificats, la génération dynmique et unitaire via une méthode HTTP me semble plus simple. Surtout quand on utilise Traefik ;-)

Postgres

Python

TICK

Astuce(s) du mois

J'utilise Ansible dans une logique d'IAC et pour automatiser un maximum des actions pour la gestion de l'infrastructure et des applications de mes clients. Toutefois, chaque client avait son arborescence et la réutilisation d'un composant d'un client à l'autre était fastidieuse (copier/coller).

Un premier travail a consisté à extraire les rôles commun dans un dépôt git tiers et faire des liens symboliques mais cela n'était pas très pratique. Suite à un travail chez un autre client, j'ai revu mon approche et je pars pour le moment sur la solution suivante :

  • Un dépôt "global", contenant la configuration ansible, les plugins, les playbooks, les variables d'hotes ou de groupes, l'inventaire et les rôles.
  • Pour chaque rôle, je repars sur le principe d'extensibilité du code avec un rôle générique et des extensions par clients. Il y aura donc un répertoire du nom du composant et un répertoire <composant>.<client> ou <client>.<composant> (le choix n'est pas encore arrêté). Le second répertoire contenant les éléments spécifiques au client.

Exemple avec un rôle MariaDB :

mariadb/
├── README.md
├── defaults
│   └── main.yml
├── files
├── handlers
│   └── main.yml
├── meta
├── tasks
│   └── main.yml
├── templates
│   └── my.cnf.j2
└── vars
   └── main.yml
co.mariadb/
├── README.md
├── handlers
│   └── main.yml
├── tasks
│   └── main.yml
├── templates
│   ├── my-primary.cnf.j2
│   └── my-replica.cnf.j2

Ainsi, la partie générique et la partie spécifique à mon client sont isolées. Il faut juste envisager le séquencement entre les deux rôles pour que cela se passe bien. Pour le moment, le seul code dupliqué se retrouve au niveau des handlers.

Si je devais donner accès à mes clients à leurs playbooks respectifs, il faudrait que je revois l'organisation pour ne leur donner accès qu'à leurs données. Il faudrait alors recréeer n dépots mais avec cette méthode, il est aussi facile de reconstruire a posteriori des dépots par clients depuis un dépot global. L'intérêt étant pour moi de conserver ma flexibilité et d'améliorer la réutilisabilité de mes composants.

Web, Ops & Data - Novembre 2017

sparkgrafanatickcloud-initelasticsearchelkgraphqlkafkapostgresinfluxdbprometheuscodeurs en seine

Big Data

  • Compte rendu du Spark Summit 2017 (Dublin) : La conférence européenne annulle de l'éditeur de Spark, Databricks, a cherché à montrer que le Streaming et le Deep Learning sont/seront bientôt plus accessibles via Spark et également la plateforme cloud DataBricks.

Dataviz

  • Grafana 4.6 Released : Nouvelle version de l'outil de visualisation des bases de données time series mais pas uniquement avec l'ajout de la source Postgres, du support de l'alerting pour Amazon Cloudwatch, des annotations simplifiées sur les graphs et autres améliorations sur la base prometheus.
  • Wizzy : il s'agit d'un ensemble de script pour versionner et se simplifier la gestion de ses dashboards réalisés sous Grafana. Pas encore testé, sous peu !

Cloud

  • Bootstrapping a Cloud with Cloud-Init and HypriotOS : j'avais croisé Cloud-Init dans Rancher OS mais n'avais pas eu le temps d'investiguer le sujet. Récemment, un podcast avec son créateur m'a permis d'en savoir plus sur le projet, à savoir que c'est un ensemble de script python qui permettent de configurer une machine lors de son initialisation (boot). Cet article permet du coup d'en avoir un exemple pratique par la configuration d'une image pour un Raspberry Pi 3 installant automatiquement le logiciel NextCloud sous la forme d'un container Docker.

Elasticsearch

  • An Ansible role to Manage your Elasticsearch Clusters : Synthesio publie son playbook ansible pour gérer des clusters Elasticsearch ; vu les clusters gérés, il y a surement de bonnes choses à récupérer - la limite étant peut être que pour un cluster de débutant, cela pourrait être trop complexe au regard du besoin. A évaluer suivant votre contexte.
  • Operating Large Elasticsearch Clusters : un retour d'expérience de l'équipe Synthesio sur la bonne gestion de leurs clusters ElasticSearch lors des Sysadmindays il y a peu.
  • La Stack ELK passe en 6.0 :
    • Elasticsearch 6.0.0 GA released : mise à jour sans downtime, index filtré, meilleures performances, meilleure résilience et meilleure sécurité (mot de passe, usage de TLS).
    • Logstash 6.0.0 GA released : il est désormais possible d'avoir des pipelines dont l'exécution se fait en parallèle et via X-Pack, il y a maintenant une UI pour piloter vos pipelines.
    • Kibana 6.0.0 GA released : Plein d'améliorations au programme : Export CSV, Amélioration de l'UI, Mode lecture seule pour pouvoir partager des dashboards et d'autres nouveautés spécifiques à X-Pack.
    • Beats 6.0.0 GA released : capture des données Docker/Kubernetes, auditbeat pour captuer les données d'auditd, une meilleure gestion des modules et de leur configuration, amélioration de performance et du stockage des données.
  • Devez-vous migrer vers Elasticsearch 6 : l'équipe Jolicode passe en revue les avancées de la version 6 et globalement conseille de passer vers cette version 6.

GraphQL

  • Modernisez vos API, passez à GraphQL ! (slides et vidéo) : Une introduction à GraphQL présentée à Codeurs en Seine 2017. Je reste toujours sceptique sur GraphQL, si coté client cela semble magique, personne ne montre la partie backend pour que la "magie" opère.
  • The GraphQL stack: How everything fits together : état des lieux suite à GraphQL Summit 2017 sur les parties cache, tracing (suivi d'une requête de bout en bout du système) et composabilité d'API (une requête GraphQL qui intérogge plusieurs API au lieu d'une).

Kafka

  • Apache Kafka Goes 1.0 : cette version 1.0 représente plutôt la complétude à l'égard d'une vision de ce que devait être Kafka que de sa stabilité ou de sa capacité à être utilisé en production. Le billet énoncce les derniers apports mais reviens surtout sur tout cette génése et la vision associée au produit.

(No)SQL

Time Series

select(db:"foo")
 .where(exp:{"_measurement"=="cpu" AND 
             "_field"=="usage_system" AND 
             "service"=="app-server"})
 .range(start:-12h)
 .window(every:10m)
 .max()

Web, Ops & Data - Semaine 46

kubernetestickinfluxdbchronografanonymisation

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)

Gestion des données personnelles

Web, Ops & Data - Semaine 37

kafkapostgreskubernetesclusterreplicationinfluxdbticksécuritéangularjshttpshstscorscspsrihpkptelegrafkapacitorcqrsevent sourcing

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

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é

Postgres

Web, Ops & Data - Semaine 14

reverse-proxydockerkuberneteselasticsearchkibanavncsshopenshitinfluxdbtickreindex

Infrastructure

Container

  • Elastikube : une solution de gestion d'une infrastructure Kubernetes ; cela fait penser à une version allégée d'Openshift. Containers
  • Containers are not VM : Une clarification par l'équipe Docker sur la différence entre un container et une VM sur la base de l'analogie avec l'appartement (le container) et la maison (la VM). Une maison (VM) contient tout ce dont elle a besoin pour fonctionner alors que pour un immeuble, des ressources sont partagées et chaque appartement de l'immeuble en profite dans une certaine mesure.
  • Docker a annoncé Docker pour Windows/Mac (beta) ; cela permet d'utiliser Docker de façon plus native et intuitive sous Windows/Mac. Pour Windows, cela demande d'avoir Windows 10 pour bénéficier de l'hypervision via Hyper-V. Sur ce sujet, l'équipe Hypriot dans leur revue de Docker pour Mac et Docker pour Windows montre le bonus (easter egg) de cette version à savoir qu'il est possible de faire tourner des conteneurs ARM sous environnement OSX/Windows ; cela permettrait de batir des conteurs pour Raspberry ou des projets IoT plus facilement. Je ne peux hélas pas le tester pour le moment, mais cela semble plus prometteur que Docker Toolbox qui reste un peu complexe à mettre en oeuvre.
  • Rancher, une solution d'orchestration de conteneurs, après avoir annoncé le support de Kubernetes, vient d'annoncer la sortie de la version 1.0. A suivre, même si la notion d'environnement ne permettrait pas une allocation optimale des capacités d'infrastructure (chaque environnement aurait ses hôtes alors que Kubernetes pourrait a priori permettre une mutualisation totale via la gestion des "namespaces" ; à creuser !).
  • Kubernetes, la solution d'orchestration de container (Docker/Rocket) développée par Google, est sorti en version 1.2 avec diverses améliorations et notamment une nouvelle GUI.
  • Kubernetes on ARM vient de sortir sous la version 0.7.0 ; de quoi se faire la main sur Kubernetes avec vos Raspberry ;-) ; une image Rancher est d'ailleurs disponible.
  • Docker en production : la bataille sanglante des orchestrateurs de conteneurs : Pour conclure, Octo compare Docker Swarm, Kubernetes et Openshift et donnant Kubernetes gagant pour le moment. Personellement, vu qu'a minima pour Kubernetes et Docker Swarm, on peut utiliser des containers docker, il est peut être intéressant de combiner les 2 solutions qui répondent plus ou moins bien à différentes problématiques. Je vois assez bien l'utilisation de Docker Swarm dans une logique de développement / labs et plus Kubernetes en effet dans une logique de production pure. Il ne faut pas se cacher que Kubernetes est plutôt "Ops friendly" et remonte la chaine de valeur vers les développeurs quand Docker fait le contraire...

Elasticsearch & friends

InfluxDB & Friends

Sysadmin

  • Teleport ; Une passerelle (bastion) SSH qui permet d'accéder à ses serveurs via SSH ou en HTTPS via une IHM Web. A tester !

Sécurité

  • VNCFail ; vous reprendrez bien un peu de non sécurité: l'analyse des 4 milliards de plage IPv4 remonte 5 millions d'adresse pour lesquelles le logiciel VNC (prise de contrôle à distance) est accessible et au final 2.246 hotes avec des systèmes accessibles sans mot de passe dont des systèmes sensibles (contrôle d'aération, usine éléctrique, etc).
4 / 4 Suivant →