CérénIT

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

Web, Ops & Data - Janvier 2020

timeseries cloud ovh s3 object storage delta git diff faas containerd raspberrypi influxdb vscode flux warp10 observabilité docker cnab postgresql grafana

Meilleurs voeux à tous pour cette nouvelle année !

Cloud

  • OVHcloud Object Storage clusters support S3 API : pour ceux qui ne voulaient pas aller chez OVH car leur système de stockage objet est basé sur Openstack/Swift et ne voulaient pas modifier leurs appels d’API S3, une bonne nouvelle : le stockage objet d’OVH Cloud supporte l’API S3.

Container & Orchestration

  • Managing the TICK Stack with Docker App : cet article aurait pu être dans la section Time Series mais le focus étant sur Docker et Docker App, il sera dans la section Container. L’article montre comment déployer la stack TICK (Telegraf, InfluxDB, Chronograf et Kapacitor) tout d’abord via un fichier docker-compose.yml et ensuite il montre les apports de Docker App, qui permet d’avoir un niveau de personnalisation supplémentaire. Ainsi, on peut avoir un seul fichier docker-compose.yml de référence et auquel on rajoute un fichier avec des propriétés par environnement ou par client ou par instance par ex. Une combinaison intéressante pour améliorer l’industrialisation de vos containers.
  • Kubernetes 1.17 disponible sur l’offre kubernetes managé d’OVHCloud

DevOps/SRE

  • The 3 Myths of Observability : l’observabilité ne va pas directement baisser votre nombre d’incidents, l’observabilité n’est pas qu’une suite d’outils et elle n’est pas gratuite.

Outillage

  • delta : pour améliorer le rendu de vos diff et certaines commandes git (diff, show, log, stash, reflog). L’outil est réalisé en rust. Cela donne un rendu à la github/gitlab dans votre console. Sympa !

Raspberry Pi

  • faasd - lightweight Serverless for your Raspberry Pi : si vous jugez k3s encore trop gros pour vos raspberry pi pour faire tourner OpenFaaS ou que vous ne voulez pas déployer du kubernetes, vous pourriez trouver la solution du coté de faasd. Une implémentation du projet basée sur containerd (le runtime utilisée par Docker)
  • HypriotOS v1.12.0 : la distribution optimisée pour Raspberry Pi et fournissant Docker arrive en version 1.12. Elle permet d’utiliser Docker sur tous les modèles de Raspberry (0, 1, 2, 3, 4) avec les dernières versions de docker, docker-compose et docker-machine.

SQL

  • Améliorez votre SQL : utilisez des index filtrés : Postgresql permet de définir des index filtrés : plutôt que de créer un index sur toutes les données d’une table, vous pouvez définir un index qui répond à un filtre et ne faire un index que sur ce sous-ensemble de données.

Time Series

  • Grafana v6.6 Released : nouvelle version de Grafana avec comme d’habitude plein d’améliorations à tous les étages (data source, panels, alerting, explore, etc)
  • Release Announcement: Flux VSCode Support : InfluxData a publié une extension VSCode pour le langage flux.
  • InfluxDB 2.0 Open Source Beta Released : InfluxData passe la version OSS d’iInfluxDB 2.0 en béta après une année de versions alpha. On y trouve notamment une approche Configuration As Code avec la possibilité de définir des Tasks, Dashboards, ainsi que de la configuration via des Manifest en YAML et un système de packages. Flux, le nouveau langage de requêtage continue à s’améliorer et enfin le transpiler InfluxQL vers Flux fait son entrée mais demande à s’améliorer au fil du temps. La beta 2 est sortie aussi.
  • telegaf warp10 output : la prochaine version de Telegraf supportera nativement Warp10.
  • Erlenmeyer: Time Series query translator : OVHCloud vient d’opensourcer le code de leur proxy en go qui leur permet de parser des requêtes de différentes bases de données time series (OpenTSDB, PromQL, Prometheus Remote Read, InfluxQL et Graphite) en Warpscript pour requêter les données stockées dans Warp10. Pour rappel, la solution OVHMetrics est basée sur Warp10.
  • Le traitement et l’utilisation de la data dans l’industry 4.0 : SenX, la société éditrice de Warp10, a réalisé une vidéo intéressante sur le traitement et l’utilisation de la data dans l’industrie 4.0. On y voit notamment les 4 niveaux de maturité quant à la donnée et le rôle d’une base de données temporelles dans ce contexte. Un billet de blog (en anglais) est également disponible.

Web, Ops & Data - Mars 2019

continous-delivery continous integration cloud opensource* scaleway gpu aws redis elasticsearch grafana kubernetes traefik k3s k3d k9s

CI/CD

  • Introducing the Continuous Delivery Foundation, the new home for Tekton, Jenkins, Jenkins X and Spinnaker : Google, Gitlab, CloudBees et bien d’autres acteurs du monde de la CI/CD lancent la fondation “Countinuous Delivery”. Au delà des projets qui y seront hébergés (en commençant par Jenkins, Jenkins X, Tekton et Spinnaker), la fondation a pour but de prendre en charge l’ensemble du cycle de développement/déploiement d’une application et surtout de favoriser les bonnes pratiques associées. La fondation fera son premier “CDF Summit” la veille de KubeCon Barcelone (où j’aurais le plaisir de me rendre).

Cloud / Scaleway

Cloud vs OSS

Nous en avons beaucoup parlé dans l’épisode 69 de BigData Hebdo - je mets juste les liens et vous renvoie à notre discussion sur le sujet.

Conteneurs et orchestration

  • Red Hat Enterprise Linux 8 Beta: A new set of container tools Intéressant RHEL 8 ne contiendra plus docker mais les alternatives comme podman, buildah et skopeo.
  • Goodbye Docker and Thanks for all the Fish : Le titre est un peu provoc mais l’analyse est bonne du fait de l’évolution de l’écosystème des conteneurs et des techno associées. La modularisation de docker a permis de construire des outils plus spécialisés - reste que le package docker fourni pour le moment une expérience plus agréable et de bout en bout.
  • If You K8s, Please Try K9s… : k9s est un petit outil qui permet d’avoir une vision des ressources d’un cluster kubernetes.
  • k3s.io : une distribution de kubernetes amincie, éditée par les gens de Rancher. Elle n’en est pas moins une distribution certifiée. Cette distribution a fait le choix de supprimer des fonctionnalités non essentielles pour en arriver à un binaire de 40 Mo et un pré-requis de 512 Mo de RAM. Idéal pour des scénarios d’IoT, d’edge computing ou plu simplement pour se former à kubernetes en utilisant vos raspberry pi !
  • k3d - A fast kubernetes dev environment : k3d est un script qui se base sur k3s mais le déploie dans du docker. L’idée est alors d’avoir un mini cluster kubernetes pour tester ses développements. Si le challenge technique peut être intéressant, déployer un environnement via minikube ou un petit cluster kubernetes sur des vms pour du test est peut être plus judicieux…
  • Back to Traefik 2.0 : l’équipe Containous dévoile les nouveautés de Traefik 2.0 : proxy tcp (et plus uniquement http), meilleure intégration kubernetes avec une CRD et plein d’autres choses.
  • ‘Cloud Native DevOps with Kubernetes’ is published! : le livre sur les applications cloud native dans un contexte kubernetes et dont j’ai eu le plaisir de participer à la relecture est (enfin) sorti. Son principal intérêt pour moi est une bonne présentation des concepts de Kubernetes et surtout son retour d’exéprience pragmatique sur les bonnes pratiques autour de kubernetes. Je le recommande vivement !

Data

  • La veille techno dans la data : si vous vous intéressez à la data, un billet utile qui vous donne des nombreuses sources pour alimenter votre veille : newsletters, podcasts, conférence, blogs, etc.
  • Grafana v6.0 Released : La solution de dataviz opensource Grafana sort en version 6 avec comme nouveautés principale un explorateur de données et leur intégration de loki leur nouvelle solution d’ingestion de logs prometheus.

Web, Ops & Data - Janvier 2019

machine-learning recaptcha flink alibaba cloud mongodb aws documentdb postgres test iac kubernetes ingress clusterip loadbalancer volume persistent volume claim nodeport logstash python pip virtualenv pipenv pyenv

Cloud

Container et orchestration

  • APIServer dry-run and kubectl diff : Un des soucis majeurs avec Kubernetes est l’écriture de fichiers YAML où la moindre faute peut s’insérer très rapidement et à l’insu de son auteur. Le billet présente les efforts fait pour ajouter un mode “dry run” qui simule les modifications et retourne l’objet qui aurait du être créé. Dans la même veine, un kubectl diff montrera les différences entre la ressource existante et celle décrite dans la nouvelle version du fichier yaml.
  • 9 Kubernetes Security Best Practices Everyone Must Follow : rien de transcendental mais une petite piqure de rappel après la faille majeure découverte en fin d’année.
  • Kubernetes NodePort vs LoadBalancer vs Ingress? When should I use what? : billet synthétique sur les avantages et inconvénients d’utiliser un service de type ClusterIP, NodePort, LoadBalancer ou Ingress. Sachant que l’on peut combiner LoadBalancer & Ingress !.
  • Why Is Storage On Kubernetes So Hard? : Les données, c’est tout sauf stateless et le stockage distribué c’est pas facile non plus. Le billet revient sur les logiques de stockages sous Kubernetes (PV, PVC), la couche d’interface de stockage CSI et sur des solutions comme Ceph ou Rook.
  • Stateful Kubernetes with Saad Ali - Software Engineering Daily : une présentation globale des Volumes, Persistent Volume, Persistent Volume Claims et des StorageClass sous Kubernetes et de l’évolution de la gestion du stockage sous k8s
  • Kubernetes Podcast - #36 Rook : une présentation de Rook, un opérateur k8s de gestion de stockage (Ceph, NFS, etc).

Data

IDE

Infrastructure (as Code)

  • Tester son code d’infrastructure avec Terratest : le billet présente terratest, un outil en go qui permet de tester du code Terraform, des templates Packer ou encore des images Docker. La conclusion montre qu’il n’est pas parfait certes mais peut être intéressant.
  • Infrastructure as (real) code : Faire de l’IaC, ce n’est pas que rédiger des fichiers YAML. Le billet montre comment on pourrait avoir de l’IaC avec du vrai code (du go en l’occurence). Avoir un vrai langage et un moteur de template semble en effet plus complet que juste du YAML pour lequel les validateurs sont assez faibles et la probabilité d’écrire une faute assez importante.
  • Reactive planning is a cloud native pattern : Le reactive planning tiendrait dans l’idée que pour une action donnée, il va y avoir un plan et que ce plan est constitué d’une multitude de petites étapes. Chaque étape informant la/les précédentes et voire globalement sur l’état de l’étape en cours et peut décider des étapes suivantes.

Langages

  • Why you should use pyenv + Pipenv for your Python projects : Une solution propre pour mieux gérer ses versions de python installées sur son poste / sur un serveur avec pyenv et pipenv (mix de pip et virtualenv) pour gérer les dépendances. A tester !
  • Pipenv: promises a lot, delivers very little : le billet nuance les propos autour de pipenv comme le nouveau gestionnaire officiel (autopromu) et fait le point sur l’outil.
  • shiv : Shiv permet de packager des applications python en une seule archive zip avec toutes les dépendances incluses. Disponible pour Windows / Linux / OSX, il faut néanmoins builder sur l’OS Cible pour que cela fonctionne - pas de “build one, run everywhere”.

Logs

(No)SQL

Web, Ops & Data - Décembre 2018

python grafana aws confluence licence opensource traefik windows openssh cloud etcd cncf vault hashicorp test kubernetes load-balancer metallb chrome edge

Cloud

  • AWS Re:Invent 2018 : Difficle de passer à coté des annonces d’AWS - AWS re:Invent 2018 - Jour 1, AWS re:Invent 2018 - Jour 2, AWS re:Invent - Jour 3, AWS re:Invent - Jour 4 : le résumé des sorties de la conférence AWS re:Invent 2018 par le cabinet Ippon.
  • #9 - Quentin Adam - Horacio Gonzales - Steven Le-Roux - La guerre du cloud : dans cet épisoide du podcast databuzzword, il est question de guerre du cloud, du multi-cloud, d’AWS et de ses “partenariats” et du cloud chinois et russe.
  • Episode 63 : “Re-Invent le Cloud” : L’épisode 63 de BigDataHebdo s’intéresse aussi aux annonces de la conférence d’AWS et discute aussi d’AWS et du monde de l’opensource.
  • License Changes for Confluent Platform : la sortie de l’offre Kafka managé n’a pas plus à Confluent. A l’instar de Redis et MongoDB, c’est au tour de Confluent d’adopter une licence plus restrictive pour les fournisseurs de cloud dans le cadre de la distribution de sa platforme Confluent. La licence de Kafka est inchangé, cela concerne l’API Rest, la Schema REgistry, KSQL et des connecteurs confluent.
  • Copyleft and community licenses are not without merit, but they are a dead end : Paul Dix, le CTO D’InfluxData donne son avis sur les changements de licences en cours. Un point intéressant est que ce changement de license vers des licences de type “Community” va surtout pénaliser les développeurs en créant une incertitude autour du mode de collaboration/contribution et peuvent aussi chercher à créer un monopole pour les services SasS créés par l’éditeur du produit. Oui il est dommage qu’AWS par ex ne contribue pas à Kafka/Confluent dans le cadre de son offre managée, mais par la même occasion Confluent se crée un monopole de fait sur l’offre SaaS autour de KSQL. Est-ce vraiment mieux ? En ce sens, Paul préfère alors soit du tout open ou tout fermé - mais que la solution du milieu n’est pas si idéale que ça (surtout pour des couches basses des produits sur lequel nous sommes censés bâtir quelque chose).
  • We need Sustainable Free and Open Source Communities : Pour finir sur une note plus optimiste, l’auteur cherche à renverser la conversation en regardant comment créer des communautés soutenables et faire en sorte que la licence permette de soutenir la communauté. Pas sur que les libristes les plus convaincus n’y voient pas une atteinte aux libertés du logiciel justement : “Any commercial activity around the software must further the sustainability of the community, and the potential for commercial benefit must be available to all. The incentives in any commercial model must bend away from the creation of proprietary downstream software”

Container et orchestration

  • Introducing Traefik Enterprise Edition : le reverse proxy Traefik voit apparaitre une version Entreprise qui se veut plus distribuée avec l’apparition d’un “data plane” qui gère les connexions et joue le rôle de reverse proxy et un “control plane” qui coordonne le bon fonctionnement des noeuds.
  • CNCF to Host etcd : la base clé/valeur distribuée etcd et qui sert notamment de datastore pour kubernetes va être hébergé par la CNCF. Elle fut développée initiallement par CoreOS, désormais propriété de Red Hat (et donc IBM).
  • [Podcast] PodCTL – Kube Security, Kube 1.13 and KubeCon :
  • MetalLB : MetalLB propose de fournir un service de type load balancer prévu pour cluster Kubernetes dans un contexte bare metal (ie non cloud).
  • MetalLB, with David Anderson : Episode du Kubernetes Podcast sur MetalLB avec son auteur pour une présentation de la solution.

Dataviz

  • Grafana v5.4 Released : une version de consolidation avec des améliorations sur la temporisation des alertes avant de l’émettre. D’autres améliorations sur l’intégration Google Stackdriver, l’éditeur de requêtes MySQL et des améliorations sur les panels et des préférences d’équipes.

Langages

Il ne me reste plus qu’à vous souhaiter de bonnes fêtes de fin d’année et à vous retrouver l’année prochaine pour de nouvelles aventures.

Méthodologie

  • Infliger de l’aide : Quand une personne demande de l’aide et qu’on n’y met pas d’empathie, on peut alors lui infliger de l’aide - Je pense que je vais reprendre ce concept et l’appliquer.

Sécurité

Tests

Web

Windows

Voxxeddays Microservices Paris

microservice voxxeddays cloud distributed systems ddd bounded context

J’ai participé à la première édition de Voxxeddays Microservices Paris qui a eu lieu du 29 au 31 oct, sous la forme de deux jours de conférences et un jour de workshop. Je ne suis allé qu’aux deux jours de conférences.

Globalement :

  • Je crois que c’est la première conférence tech où je vois autant de femmes témoigner - après recomptage, il n’y en avait que 8 sur 45 speakers, mais 2 des 3 keynoters étaient des femmes. 1/6 c’est encore peu mais c’est mieux que d’habitude. L’assistance m’a aussi paru plus féminine que d’habitude. Le mardi, la majorité des conférences auxquelles j’ai assisté étaient assurées par des femmes.
  • Deux journées denses avec des formats de conférences variées (15/25/45 minutes) et des sujets variés également (Techno, Retours d’exéprience, Architecture, Problématiques, etc).

Sur les keynotes qui devaient articuler le passé, le présent et le futur des microservices :

Distant past of microservices - Ken Finnigén (Red Hat)

  • Tout n’est que système distribué au final - les microservices n’en sont qu’une variante, après SOA, après le client/serveur, etc.
  • Il y a un cycle des systèmes distribués : gestion toute imbriquée (“embedded”), passage par des librairies, puis des middlewares et enfin par de la gestion d’environnement (et de ses variables). Il est donc probable que l’on revienne vers du tout en un prochainement. Même s’il y a des améliorations incrémentables d’un cycle à l’autre, on reste sur la même boucle.
  • “Old is the new new” - il faudrait cesser de réinventer la roue pour la simple raison que nous pouvons le faire. il faudrait plutôt chercher à résoudre des problèmes qui n’ont pas encore été résolu. Cela me fait penser aux nouveaux langages ou frameworks qui se créent sans tenir (trop) compte des langages précédents : ils se retrouvent au final à devoir traiter les mêmes problèmes que leurs prédécesseurs et sans forcément trouver une réponse plus satisfaisante.
  • Réflexion autour de la notion de “quescient state” comme prochain but à atteindre.

The endless now : distributed systems and teams - Bridget Kromhout

  • C’est dommage que l’oratrice ait forcément voulu raccrocher des technologies et des outils à son propos car cela a nuit à son message. Je n’ai pas vu la raison ou l’intérêt de mentionner ces outils.
  • Le propos était d’appliquer les principes du CAP sur les équipes et les systèmes :
    • “Consistency” : les containers ont apporté cette reproductabilité des déploiements
    • “Avilability” : les outils d’orchestration répondent à ce besoin et à cette gestion de la disponibilité de nos applications
    • “Fault/Partition tolerance” : il faut travailler sur les effets du bus factor, la loi de Conway et la communication entre les équipes pour éviter la dépendance à une personne et développer la résilience de l’équipe et du système.

Preparing for a future microsdervices journey - Susanne Kaiser

Ma keynote préférée - l’oratrice reparcourt tout ce qui fait un micro-service et les bonnes pratiques associées :

  • Pour un simple/petit micro-service, il faut bien avoir en tête tout l’écosystème que l’on emmène avec soi (solutions et infrastructure cloud, CI/CD, etc)
  • Parcours des bonnes pratiques et des “cloud native citizen principles”
  • Elle prone le focus sur notre coeur d’activité et d’externaliser le reste en ayant recours à des services managés. Toutefois, elle fait une très belle remarque en rappelant qu’il ne faut pas négliger la charge cognitive liée à ces services managés. Ils résolvent des problèmes et font gagner du temps mais ne sont pas neutres pour autant (ex: les primitives de Kubernetes et d’un service mesh comme Istio)

Pour les conférences, celles que j’ai préféré :

Hexagonal at scale with DDD and microservices ! - Cyrille Martare (Arolla)

  • L’orateur rappelle que les microservices requiert une approche DDD puis les principes de DDD en eux même. Il rajoute que les architectures 3 tiers, par couche, par technologie ou encore que le découpage par entités ne vont pas créer de bons microservices et ne sont pas dans une approche DDD. Il faut donc définir avec le métier les fameux domaines et leurs frontières (“bounded context”). L’orateur a alors parcouru les différents heuristiques permettant de les définir.
  • Si nous avons été habitués à avoir une approche DRY (Don’t reapeat yourself"), dans une approche DDD et Microservices, cela perd son sens. Il vaut mieux accepter de la duplication de données afin d’avoir du code moins couplé et donc avoir une meilleure indépendance des microservices entre eux.

Microservices Lessons Learned - Susanne Kaiser

Dans la continuité de sa Keynote, Suzanne fait un bilan de ce qu’elle a pu faire et de comment il aurait fallu le faire. Je vous invite à voir son talk et récupérer les slides.

Coté Outils…

Quelques outils qui m’ont semblé intéressants :

  • Jenkins X : l’idée est de déployer sur un cluster Kubernetes un noeud maitre Jenkins et un Nexus (ou autre produit de stockage d’artefacts) et ensuite d’instancier les agents Jenkins à la volée pour vos besoins de CI/CD.
  • Teeid ou l’ancien site : solution permettant de définir une ou plusieurs bases virtuelles au dessus d’une base existante. Cela peut être pratique dans le cadre de la sortie d’un monolithe vers des microservices. L’idée est de permettre au micro-service d’avoir la nouvelle vue tout en conservant l’ancien système.
  • Micronaut se veut un framework java minimaliste pour être adapté aux microservices mais sans affecter la productivité des développeurs. Il est développé par l’équipe qui a réalisé Grails. Il se veut plus léger/performant que Microprofile qui est en gros la version microservice du framework JEE. Micronaut serait plus proche de Vertx.
  • Strimzi : Il s’agit d’un projet Red Hat pour fournir un Cluster Kafka à déployer sur Kubernetes ou Openshift
  • Debezium : Plateforme de Change Data Capture (CDC) - Elle est basée sur Kafka et Kafka Connect. Elle permet de récupérer les changements de vos bases MySQL/Postgres/MongoDB sous forme d’événements et de les communiquer à qui de droit en mode streaming.
  • gRPC : si vous n’avez pas besoin d’une API REST, que vous manipulez plutôt des RPC que des ressources (REST), que vous n’êtes pas dans un contexte CRUD, alors gRPC peut être fait pour vous.
  • Dependency Check et Dependency Track sont deux projets de l’OWASP permettant d’analyser vos dépendances et de surveiller les vulnérabilités de votre base de code. Ils s’intègrent notamment avec Jenkins.
1 2