CérénIT

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

Web, Ops & Data - Mai 2019

kafka sécurité s3 aws vscode openebs rook kubedb nginx ingress grafana elasticsearch ansible timeseries timescaledb

Cloud

Container et Orchestration

  • Rook v1.0 — A Major Milestone : Rook atteint le stade de la version 1.0 avec une amélioration de l’opérateur Ceph (simplification de la configuration, gestion des mises à jour, prise en charge des dernières versions de Ceph, etc), le driver Ceph CSI passe en bêta, le support d’EdgeFS passe en bêta également, l’opérateur NFS supporte l’approvisionnement dynamique et l’opérateur Minio a reçu également des améliorations.
  • KubeDB 0.12 : cette version apporte principalement le support du sharding MongoDB et du Clustering MySQL et divers correctifs pour les autres “backends”.
  • Announcing NGINX Ingress Controller for Kubernetes Release 1.5.0 : nouvelle version de l’ingress nginx avec une nouvelle configuration, des métriques (via prometheus), simplification de la gestion des certificats, etc.
  • Grafana v6.2 Stable Release! : améliorations de sécurité sur le chiffrement des données des datasources, une nouvelle gauge et pleins d’autres améliorations.
  • OpenEBS Project Update and whats coming in v1.0 : la solution de stockage sous kubernetes vient de sortir en version 0.9 et de rejoindre la CNCF. C’est l’occasion de faire un point sur le projet et la route vers la version 1.0

(Big) Data

  • Kafka : Migrer un consommateur vers Streams et Connect : retour d’expérience intéressant sur la migration d’une intégration Kafka basée sur les producteurs/consommateurs vers une approche basée sur Kafka Connect et Kafka Streams.
  • Security for Elasticsearch is now free : ces fonctionnalités, prélablement disponibles uniquement dans la version commerciale, font partie de la version gratuite : chiffrement des flux via TLS, authentification et gestion des rôles.

IAC

  • Ansible 2.8 : de nombreuses améliorations au rendez-vous, la liste est très longue. Pour ma part, je note l’arrivée du support de “docker stack” pour gérer des déploiements sur un cluster docker swarm.

IDE

Sécurité

  • The inception bar: a new phishing method : sur mobile, dès lors que l’utilisateur fait défiler sa page, la barre de navigation va disparaitre et du coup il est possible d’injecter une fausse barre de navigation et faire croire à l’utilisateur qu’il est sur un autre site.

Time series

  • Zabbix, Time Series Data and TimescaleDB : le billet explique en quoi Zabbix doit faire face à l’enjeu des séries temporelles dans le cadre d’une solution de monitoring. Comme ils veulent avoir une technologie leur permettant d’utiliser SQL, ils ont fait le choix de TimescaleDB. Le point intéressant est en fin d’article lorsque les performances de Postgres 10 et TimescaleDB sont comparées.

Web, Ops & Data - Aout 2018

docker kubernetes cassandra reaper istio service-mesh cloud opensource redis kafka mysql postgres confluent openmetrics prometheus fluxlang influxdb timescaledb

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 - Juin 2018

mysql redis kubernetes aws terraform cdc debezium kafka azure elasticsearch ksql kapacitor docker docker-compose docker-app buildkit hashicorp consul service-mesh istio

Big Data, Machine Learning & co

Cloud

Container & Orchestration

  • Making Compose Easier to Use with Application Packages : Docker Inc. sort un nouveau produit appelé “docker-app”. Il se veut comme une surcouche à docker-compose en permettant d’injecter des variables dans vos fichiers docker-compose.yml. Ainsi, vous n’auriez plus qu’un seul fichier docker-compose avec ses variables et les valeurs de ses variables dans des fichiers additionnels. Lors de l’exécution du container, docker-app réconcilie les deux et lance le conteneur avec les bonnes valeurs. Docker Swarm et Kubernetes seraient supportés si l’on en croit les exemples. Rigolo, sur le principe, c’est exactement ce que je fais pour une mission actuellement…
  • Découverte de Buildkit : dans le cadre du découpage de Docker en programme modulaire indépendant, Moby avait lancé Buildkit. Il s’agit du builder d’images. L’article présente son fonctionnement et son architecture.
  • HashiCorp Consul 1.2: Service Mesh : Hashicorp sort en beta son offre de service mesh basé sur Consul. Après le “Service Discovery” et le “Service Configuration”, voilà le Service Mesh. A voir dans la vraie vie mais on retrouve apparemment pas mal de fonctionnalités disponibles dans Istio.

(No)SQL

  • Vitess : J’en avais entendu parler, j’ai profité d’un épisode de Software Engineering Daily pour en savoir un petit peu plus : Je ne suis pas encore au bout du podcast mais cela semble être une couche entre l’application et la DB - elle analyse la requête et la distribue ensuite au sein du cluster. Vitess permettrait notamment que le développeur n’ait pas à connaitre la logique de clustering/sharding des données. L’overhead n’a pas encore été mentionné.
  • Redis 5.0 RC1 : la version 5.0 de Redis pointe le bout de son nez avec notamment le type de donnée Stream - cf Introduction to redis streams
  • Streaming Data out of the Monolith: Building a Highly Reliable CDC Stack : un CDC, Change Data Capture, est un système qui capture les changements de données (INSERT, UPDATE, DELETE) d’une source de données. BlaBlaCar explique ici comment ils ont mis en place leur CDC sur la base de Debezium et Kafka. Un des défis à relever étant la gestion de la déduplication des données.
  • Elasticsearch 6.3.0 Released : plein de nouveautés mais la plus symoblique étant un début de support d’un requêtage SQL dans Elasticsearch.

Sécurité

  • Attacking Private Networks from the Internet with DNS Rebinding : TL;DR Following the wrong link could allow remote attackers to control your WiFi router, Google Home, Roku, Sonos speakers, home thermostats and more. il est donc possible d’abuser un navigateur via un DNS malicieux et donc être en mesure de scanner le réseau local de la personne abusée. Il faut donc considérer le réseau local comme une zone hostile et y appliquer les bonnes pratiques habituelles (authentification, urls en https, etc)

Timeseries

Astuce(s) du mois

Faîtes-vous plaisir et écouter le podcast Artisan Développeur - dans des formats de 10mn environ, un sujet autour de l’agilité, des tests, du TDD, de la responsabilité des développeurs, de SaFE, et de tout ce qui fait partie de notre quotidien de développeurs sont abordés. Depuis quelques épisodes, cela se fait en duo avec d’autres personnes (comme JP Lambert) ce qui rend les échanges encore plus intéressants. Vous retrouvez le podcast sur Soundcloud, Pocketcasts, etc.

Web, Ops & Data - Mai 2018

docker kubernetes containerd github grafana mysql password mot de passe portainer swarm python flask kafka confluent nginx chronograf kapacitor

Big Data, Machine Learning & co

  • Confluent Platform 4.1 with Production-Ready KSQL Now Available : Basé sur Apache Kafka 1.1, la nouvelle mouture de la platform de Confluent signe l’arrivée de KSQL comme “production ready” notamment - a voir si le “Replicator” est dans la version OSS ou bien EE seulement. Le seul souci que j’ai avec kafka, c’est que l’on ne peut pas monitorer finement la consommation des queues vu que l’intelligence est coté consommateur et pas coté broker… Même avec la version EE et le Control Center qui ne remonte que des métriques globaux mais ne donne pas de détail sur l’état du topic.
  • Tensorflow with Javascript Brings Deep Learning to the Browser : j’avais lu l’annonce il y a quelques temps mais sans bien comprendre l’intérêt de la chose. L’idée ici est de pouvoir faire tourner Tensorflox dans le navigateur au travers de Javascript et de WebGL (et donc de tirer parti des capacités de la carte graphique). En plus de rendre accessible le ML aux développeurs Web, cela permettrait aussi de soumettre des modèles ou d’entrainer des modèles dans le navigateur de l’utilisateur. Vers le Machine Learning au plus près de l’utilisateur ?
  • Introducing Confluent Platform Preview Releases : Confluent met à disposition des versions intermédiaires de sa distribution. Cette première version permet de jouer avec KSQL et il semble que l’interface Control Center soit disponible sans frais particuliers. On notera d’ailleurs qu’en plus de la partie KSQL, des efforts ont été faits sur la partie inspection de topic et consumer lag. Cela progresse donc enfin dans l’observabilité et le monitoring d’un cluster kafka.
  • Introducing the Confluent Operator: Apache Kafka® on Kubernetes Made Simple : Confluent va mettre à disposition un “Kubernetes Operator” permettant de déployer Kafka ou Confluent platform de façon (plus) aisée sur un cluster Kubernetes. Les templates Kubernetes et les images Docker vont être mis à disposition le mois prochain et le Kubernetes Operator d’ici le milieu d’année.

Container et Orchrestration

  • Announcing Docker Enterprise Edition 2.0 : Docker Inc annonce la version 2.0 de sa version Entreprise. Elle se veut indépendante de tout lock-in (Multi-Linux, Multi-OS, Multi-Cloud) et permettre d’utiliser soit Swarm ou Kubernetes comme orchestrateur. Cette version apporte également un routage avancé au niveau de Swarm (niveau L7).
  • feat(agent): add agent support : Portainer est une solution de gestion d’un environnement Docker ou Docker Swarm. L’inconvénient sous Docker Swarm est que l’instance Portainer ne voit que les containers présents sur le même noeud que le sien et pas l’ensemble des containers (cf [FEATURE REQUEST] Be able to use all the Portainer built-in functionalities in all the containers running in a swarm cluster). Via un mécanisme d’agent (code source fermé) à déployer sur chaque noeud, l’éditeur annonce pouvoir contourner les limitations de l’API Docker. La justification du code fermée est motivée par les efforts de R&D réalisés. Un gist indique comment installer l’agent. Il n’est pas stipulé si en plus d’un code fermé, il y aura une offre commerciale autour ou pas.
  • Traefik 1.6 — Get Our Latest tetedemoine! : la version 1.6 apporte le support des certificats Wildcard Let’s Encrypt, une nouvelle Web UI, le support des outils de tracing Zipkin et OpenTracing, le support du stockage des certficiats dans les secrets Kubernetes, une capacité d’altération des logs en vue du respect de la GDPR et une homogénéisation interne sur la gestion des labels.
  • Open-sourcing gVisor, a sandboxed container runtime : Google vient de rendre opensource gvisor, une mécanisme permettant d’accroitre l’isolation des containers via un mécanisme de Sandbox. C’est “transaprent” pour l’utilisateur au sens qu’il peut utiliser gvisor de la même façon qu’il interagissait avec Docker ou Kubernetes. C’est juste le runtime qui change. C’est codé en go, cela intercepte les appels SYSCALLS et l’équivalent d’un noyaux linux codé en Go répond en lieu et place du noyau linux de la mâchine hôte. Par ailleurs, cette sandbox a un impact sur les performances du containers comme leurs auteurs l’expliquent bien dans le 3ème épisode du Kubernetes Podcast by Google. InfoQ publie également un article sur ce sujet : Google Release “gVisor”, a Lightweight Container Runtime Sandbox Used to Provide Secure Isolation
  • Containers, Security, and Echo Chambers : Une ex employée de Docker ayant travaillé sur la sécurité et l’isolation des containers nuance le marketing autour de gvisor. Elle avait déjà nuancé l’arrivée de Kaniko (le builder d’images Docker make in Google).
  • Introducing Play with Kubernetes : l’équipe Docker Inc, après son Play with Docker qui permet de se former à Docker depuis son poste de travail, annonce officiellement l’existence de son pendant pour Kubernetes : Play with Kubernetes. Officiellement, car le billet indique qu’il existe depuis l’été dernier. Il se base sur le workshop de Jerome Petazzoni.
  • Kubernetes Containerd Integration Goes GA : Containerd est un runtime de containers, venant de chez Docker Inc et placé mainteant sous l’égide de la CNCF. Il semble en bonne voie de devenir le runtime par défaut de Kubernetes en lieu et place de docker. Même si Kubernetes se défend de s’affranchir de Docker, force est de constater qu’il y a des travaux pour s’affranchir des outils estampillés Docker Inc : gvisor pourrait remplacer runc à terme, kaniko pourrait replacer docker build. La registry docker étant aussi en passe de standardisation, on peut s’attendre à voir un nouveau produit arriver. Si Kubernetes (+ Google + CNCF + …) ont encore besoin de la liaison avec Docker d’un point de vue marketing, on a l’impression que cela cherche à s’éloigner des outils Docker Inc et dans une moindre mesure du projet Moby (qui lui même semble aussi avoir quelques distances avec Docker Inc). Certes, le docker engine de Docker Inc est basé sur containerd et donc Docker ne disparait pas de la plateforme mais ça semble bien en prendre le chemin.

Développement

  • Using Github CODEOWNERS file : Github, via un fichier CODEOWNERS, permet d’indiquer qui sont les responsables présumés d’une Pull Request. De quoi simplifier son workflow.

Dataviz

  • Grafana v5.1 Released : en plus de la consolidation de la version 5.x, les deux ajouts significatis sont une heatmap pour Prometheus et l’arrivée de SQL Server comme data source et donc faire des graphs sur vos données SQL Server.

Infrastructure as code

(No)SQL

  • What’s New in MySQL 8.0? (Generally Available) : même si je n’utilise plus trop MySQL (au mieux MariaDB pour quelques clients), il est intéressant de voir la progression significative de cette base avec cette nouvelle version : Window functions, Document Store, support du JSON, etc. Elle pourrait presque recommencer à concurrencer Postgres ;-)
  • Installing MySQL 8.0 on Ubuntu 16.04 LTS in Five Minutes : tout est dans le titre - cela permet de déclarer le dépot Oracle/MySQL et d’accéder à differentes versions de MySQL, dont la 8.0.

Python

Sécurité

  • Use A Good Password Generator : revue de différents outils de génération et gestion de mots de passe. La feuille de calcul contient plusieurs onglets et permet de faire le tour des solutions existantes.

TICK Platform (Telegaf, InfluxDB, Chronograf, Kapacitor)

  • Kapacitor and Continuous Queries: How To Decide Which Tool You Need : la question m’a été posée à Breizhcamp et je n’avais pas forcément de réponse à fournir. Elle est fournie par l’éditeur : Conitunous Queries pour l’échantillonage et Kapacitor pour les requêtes custom et éventuellement déporter des workloads consommatrice de ressources. Le mode streaming de kapacitor permet aussi de faire vos requêtes au fil de l’eau et consommer moins de ressources (mais plus régulièrement)
  • Intelligent Monitoring: Automating Dashboard Annotations in Chronograf : tutoriel intéressant qui montre comment l’on peut générer dynamiquement des annotations sur vos graphs dans Chronograf au travers de Kapacitor. Intéressant, car en général, les annotations sont souvent posées manuellement et a posteriori par des humains et pas de façon automatique/continue.
  • Chronograf 1.5 and Kapacitor 1.5 Released : Chronograf permet maintenant d’avoir une vue tabulaire des données (et pas uniquement un graph ou une donnée) et Kapacitor peut maintenant envoyer des alertes vers Kafka, vers plusieurs canaux Slack.

Web

Web, Ops & Data - Février 2018

grafana docker docker-compose kafka graphql swarm git https certificat sécurité inspec

API, Rest, GraphQL

  • GraphQL at the REST-aurant : une introduction à GraphQL et à ses avantages par rapport à un modèle REST en faisant une analogie avec un REST-aurant. J’ai découvert les “persisted queries”.

Container & orchestration

  • Going Production with Docker and Swarm : une présentation repassant les bonnes et mauvaises pratiques de Docker et Docker Swarm, les outils disponibles, des éléments de sizing de cluster swarm, etc. Globalement en phase avec ce que je pratique chez un client actuellement. Prochaine étape, ne plus utiliser “latest” comme référence d’images !

Dataviz

  • What’s New in Grafana v5.0 : Grosse refonte de Grafana pour l’arrivée de cette version 5.0 : nouveau système de dashboard, gestion des permissions, gestion de groupes, gestion de dossiers, nouvelle UX, etc.

Git

  • –force considered harmful; understanding git’s –force-with-lease : Si l’usage de git --force est déconseillée si ce n’est proscrite, sa variante git --force-with-lease est plus intéressante et permet d’éviter d’écraser le travail de vos camarades alors que vous pensiez juste faire un push en force sur une branche distante suite à un rebase local.
  • Advantages of monolithic version control : le débat mono-dépot vs multi-dépots est récurrent - celui- ci donne des raisons pro mono dépôt. Au delà du mono/multi dépôt, c’est surtout l’architecture d’une application et sa modularité qui sont prépondérants.

Kafka

Sécurité & Compliance

  • La fin d’une époque… : si vous utilisez des certificats issues de chez Thawte, GeoTrust et RapidSSL ayant été générés avant le 1er juin 2016 pour la 1er vague ou avant le 1er décembre 2017 (date de rachat de l’autorité de Symantec par Digicert), alors vos sites risquent d’être bloqués par les version de printemps et d’automne de Firefox et Chrome. Il vous faut renouveller vos certificats. Si votre certificat a été généré après le 1er Décembre 2017, vous n’avez rien à faire.
  • Chef InSpec 2.0 Puts the Security into DevSecOps : la spécification InSpec permet de définir/tester/valider l’état d’une machine au regard de règles de conformité et de sécurité. Cette spécification a été initiée par l’entreprise Chef (éditrice du logiciel du même nom et d’Habitat entre autres). La version 2.0 vient de sortir et apporte une intégration AWS/Azure, de nouvelles ressources de validation (docker, configuration serveurs web, clés & certificats, etc) et une amélioration des performances.

Astuce(s) du mois

Lorsque l’on déploie une même application dans plusieurs contextes via docker-compose, il est intéressant d’utiliser le COMPOSE_PROJECT_NAME qui permet de donner un préfixe à vos réseaux et containers docker a minima.

L’inconvénient est qu’il faut ajouter à vos commandes un -p <project_name> :

docker-compose -p instancea build --pull
docker-compose -p instancea up -d
docker-compose -p instancea logs -f
docker-compose -p instancea stop <service>
docker-compose -p instancea down
...

Ainsi, vos conteneurs seront nommés instancea_<service name>_<occurence> et votre réseau instancea_<network name>.

Mais il est possible d’aller plus loin avec les fichiers d’environnement .env.

Dans votre fichier .env à la racine de votre dossier où se trouve votre fichier docker-compose.yml, définissez la/les variable(s) dont vous avez besoin. Ici, nous allons nous limiter à COMPOSE_PROJET_NAME mais ne vous privez pas.

COMPOSE_PROJECT_NAME=instancea

A partir de ce moment-là, plus besoin de précier l’argument -p <project name>, vos commandes redeviennent :

docker-compose build --pull
docker-compose up -d
docker-compose logs -f
docker-compose stop <service>
docker-compose down
...

… et pour autant, vos réseaux et containers ont le bon préfix car le fichier .env est lu à l’exécution de la commande docker-compose avant de parser docker-compose.yml.

On peut aller encore plus loin en utilisant ce COMPOSE_PROJECT_NAME dans le taggage des images d’un container par ex ou

version: '3'
services:
  nginx:
    build:
      context: ./nginx/
    image: "registry.mycompany.com/nginx:${COMPOSE_PROJECT_NAME}"

Lors de la phase de build, l’image sera tagguée avec le nom passé au projet compose. Ensuite, vous pouvez poussez sur la registry de votre entreprise puis déployer cette version sur votre cluster Swarm par ex.

A noter justement une limitation actuelle de docker stack deploy <stack name> -c docker-compose.yml qui ne lit pas le fichier .env en amont et donc COMPOSE_PROJECT_NAME reste vide lors de la lecture du fichier docker-compose.yml.

Une solution possible est par ex dans le script (simplifié) de déploiement :

cd $BUILDDIR/compose/
source .env

# Remplace la variable COMPOSE_PROJECT_NAME par sa valeur
sed -i -e "s/\${COMPOSE_PROJECT_NAME}/${COMPOSE_PROJECT_NAME}/g" docker-compose.yml

docker stack deploy ${COMPOSE_PROJECT_NAME} -c docker-compose.yml

Et voilà !

1 2 3 4