Motoriste de vos plateformes et agitateur de séries temporelles

Conception, développement, déploiement et exploitation de vos plateformes, applications et données.

Contactez-nous !
Accueil >

Web, Ops & Data - Octobre 2019

kafka traefik kubernetes ksql kafka-streams gke anthos helm

Rendez-vous le 5 Novembre prochain à la seconde édition du Paris Time Series Meetup consacré à QuasarDB pour des cas d’usages autour de la finance et des transports.

Cloud

  • The $10m engineering problem : retour d’expérience intéressant sur l’optimisation de sa facture cloud et donc l’accroissement de sa marge opérationnelle.

Container et Orchestration

  • What’s Going on with GKE and Anthos? : Si on rapproche ça avec le fait que Google ait gardé le lead sur knative plutôt que de le confier à une fondation, on peut avoir quelques sueurs froides sur le potentiel lock-in ou alors d’une offre k8s à 2 vitesses (GKE tel qu’on le connait actuellement et Anthos GKE avec des fonctionnalités & souscriptions additionnelles…). La seule limite que je vois à ça pour le moment est le fait que Google a vendu k8s comme runtime universel de workload et qu’ils ont besoin de garder cela pour piquer des parts de marché à AWS & Azure…
  • Traefik 2.0 with Kubernetes et Advanced Traefik 2.0 with Kubernetes : pas encore implémenté mais a priori tout ce qu’il faut savoir pour passer de Traefik 1.x vers Traefik 2.x sous Kubernetes
  • Helm 2.15.0 Released : dernière version stable à apporter des nouveautés a priori avant migration vers la version 3.0. La version 2.x va passer en maintenance (correctifs de bugs & sécurité) et s’éteindra progressivement (6 mois après la release de Helm 3, elle ne prendra que des correctifs de sécurité et fin du support au bout d’un an). En attendant, cette version apporte notamment le paramètre --output <table|json|yaml> à certaines commandes. Pratique quand on manipule les sorties de Helm dans des scripts…
  • Comparing Ingress controllers for Kubernetes : une comparaison de 11 Ingress Controller (Nginx, Traefik, Kong, HAProxy, etc) sur une douzaine de fonctionnalités.

(Big) data

  • Why I Recommend My Clients NOT Use KSQL and Kafka Streams : la gestion des états et la capacité à pouvoir savoir à quel offset d’un topic kafka reprendre sa consommation peut être un sujet surtout dans le cadre d’une grosse volumétrie qui peut empêcher que le cas de reprendre la consommation du topic depuis son origine. Si Kafka Streams était doté de ce fameux “checkpoint” cela pourrait simplifier la chose. L’autre cas étant sur l’absence de “shuffle sort” utilisé dans des contexte analytiques. Du coup Kafka streams crée des topics supplémentaires pour le besoin et cela peut nuire au bon fonctionnement de votre cluster.
  • Change data capture in production with Apache Flink - David Morin & Yann Pauly : un retour d’expérience très riche et très complet sur l’utilisation de Flink chez OVH, les problématiques qu’ils ont rencontré et comment ils ont itéré sur leur pipeline d’ingestion de données. La version française donnée à DataOps.rocks devrait être disponible sous peu.

Web, Ops & Data - Septembre 2019

kafka traefik service-mesh maesh rook ceph kubernetes kubectl ksql kafka-streams telegraf docker log

Container et Orchestration

Data

  • Say Hello World to event streaming : Confluent publie des tutoriels sur Kafka, Kafka Streams et KSQL pour illustrer différents cas d’usages avec le code associé. Ils ont l’air assez bien fait.

Time Series

  • Release Announcement: Telegraf 1.12.0 : Telegraf, le collecteur de métriques/logs passent en version 1.12 avec 13 nouveaux plugins dont un pour l’ingestion des logs docker et plein d’autres améliorations. L’autre grande nouveauté est l’arrivée des plugins - il est possible d’ajouter des plugins à Telegrad de façon dynamique ; il n’est plus nécessaire de recompiler telegrad avec ces plugins en son sein.

Web, Ops & Data - Aout 2019

gitlab ci cd continous integration continous deployment git diff docker rpi traefik kubernetes ovh helm postgres percona aws partiql redis timeseries influxdb kafka prometheus

Surveillez le Time Series Paris Meetup, car la première édition du Meetup sera annoncée mardi avec une présentation des usages avancées des séries temporelles avec Warp10 (comprendre au-delà du monitoring classique) et une présentation par les équipes OVH sur du monitoring de datacenter aidé par du machine learning et leur offre Préscience.

CI/CD

  • How to trigger multiple pipelines using GitLab CI/CD : depuis une pipeline d’un dépôt gitlab, il va être possible d’appeler les pipelines des autres projets gitlab. Une fonctionnalité intéressante et qui pourrait lever la dépendance à Jenkins lorsque l’on a des pipelines un peu complexes et inter-projets.
  • New up and coming GitLab CI/CD Features : bilan et perspectives par le responsable produit de gitlab sur les fonctionnalités CI/CD qui ont été rajoutées cette année et celles à venir.

Code

Conteneurs & orchestration

SQL

time series

KubeCon + CloudNativeCon Europe 2019

kubernetes kubecon cncf cloud native

Je me suis rendu à KubeCon + CloudNativeCon Europe 2019 qui s’est tenu à Barcelone du 20 au 23 Mai. C’était la première fois que j’assistais à cette conférence.

Le veille de la conférence officielle, j’ai assisté à la première édition du Continus Delivery Summit organisé par la Continous Delivery Foundation. Différents événements en marge de la conférence officielle sont organisés par la communauté.

Plutôt que de faire un résumé par journée, je vais plutôt faire un résumé global sur ce que je retiens de la conférence.

Tout d’abord un écosystème toujours en ébullition et en pleine évolution :

  • Le village des sponsors était juste gigantesque avec environ 150 sponsors présents.
  • Les plus gros stands étaients ceux des acteurs du cloud et des gros éditeurs (Oracle, Red Hat, Google, Digital Ocean, VMWare, AWS, Azure, Cisco, IBM, etc)
  • Les habitués du secteur : Datadog et d’autres pour le monitoring, Aqua / Neu Vector / Sysdig pour la sécurité, Gitlab / JFrog / CloudBees pour la partie usine logicielle, etc.
  • Une multitude de startups présentant leur produit
  • Des entreprises utilisatrices des technologies CNCF étaient présentes comme Adidas, CookPad ou (la sulfureuse) Palantir - ce ne sont pas ces entreprises que l’on s’attend à voir dans une telle conférence
  • Un stand qui m’a étonné, c’est la petitesse du stand de Docker - s’il est pourtant un sponsor Gold de l’événement, le stand était aussi grand que celui de n’importe quelle startup. On sent vraiment que la mode est passé et que ce n’est plus Docker qui dirige l’écosystème alors que sa technologie, pourtant centrale, est devenue une commodité.

Sur les produits qui ont retenu mon attention :

  • Vitess : Vitess rend MySQL cloud native au sens qu’il gère nativement la réplication, le sharding, la bascule en cas de perte du master, etc.
  • Rook : la solution cloud native de stockage au dessus de Ceph principalement mais pas uniquement.
  • OpenEBS : une solution un peu plus universelle et complète que Rook pour gérer son stockage. Le projet vient de rejoindre la CNCF.
  • Loki : la solution d’ingestion de log de Grafana Labs et qui relie vos logs avec les méta données de prometheus.
  • Jenkins X : Si vous pensiez qu’il ne s’agissait que de Jenkins sur Kubernetes comme moi, vous vous trompiez - c’est une plateforme complète et “opinionated” de gestion de build et de déploiement en s’appuyant sur Kubernetes, Helm, Monocular, Skaffold, Tekton pour la couche logicielle et sur GitOps pour la partie méthodologie/workflow, Le moteur Jenkins n’est d’ailleurs pas forcément présent, il est possible d’utiliser Tekton pour exécuter les pipelines.
  • Tekton : l’outil permet de décrire et exécuter des pipelines dans un contexte Kubernetes. Via les CRD, des objets de type Step, Task et Pipeline sont mis à disposition dans Kubernetes. En les assemblant, on peut alors décrire notre pipeline de bout en bout. Des objets complémentaires permettent de décrire les ressources/propriétés des Pipeline et d’autres de suivre leur exécution.
  • BuildKit : le nouvel outil de création d’images Docker semble vraiment très performant et propose des options intéressantes.
  • Bazel : un outil de build permettant de faire des builds reproductibles.
  • Telepresence : une sorte de proxy bi-directionnel permettant de voir des ressources distantes de votre cluster kubernetes comme des ressources locales et inversement. Pratique pour le développement et le debug.
  • Kind : KinD pour Kubernetes in Docker vous permet de faire tourner un cluster kubernetes dans du docker sur votre poste de développement par ex.
  • Open Policy Agent : un framework de gouvernance et de validation des règles de votre cluster kubrenetes.

Au niveau des buzz word, même si le Service Mesh a encore de bons restes, les buzz word 2019 semblent être Operator, Fédération (communication inter clusters) et la sécurité (Open Policy Agent)

Sur les conférences en elles-mêmes, j’avoue être assez mitigé, voire déçu sur la qualité de nombreux talks. Le format 30mn y est peut être pour quelque chose mais n’explique pas tout - peut être que la conférence voulait surtout permettre à des profils plus jeunes de découvrir cet univers plutôt que de fournir des conférences plus riches. Je suis peut être tombé sur les mauvaises…

Néanmoins, celles que j’ai eu plaisir à voir - la playlist est déjà diponible.

Je recommande aussi la visualisation des vidéos de Keynote pour avoir une vision générale de l’écosystème, des retours d’expérience divers et sur la valorisation de la communauté et de la diversité. Ces deux sujets sont un véritable enjeux pour la pérénité des différents projets. D’ailleurs, on sent que le sujet de la diversité est important avec une petite moitié des keynotes présentée par des femmes. L’animation était aussi répartie entre un homme et une femme, de nombreuses conférences étaient présentées par des femmes. Je crois même au final qu’il s’agit de la conférence où j’ai vu le plus de femmes. C’est une bonne chose !

Sur la partie logistique, c’est très bien organisé - rien à redire de ces trois jours, c’est un véritable tour de force de savoir gérer aussi bien la venue de 7700 personnes.

Enfin, ce fut l’occasion de (re)voir et rencontrer des membres de la communauté (française) et de passer de bons moments en leur compagnie. Une mention spéciale pour l’équipe OVH avec qui j’ai passé une superbe semaine (et indépendamment des goodies et vouchers que j’ai pu obtenir).

Web, Ops & Data - Avril 2019

influxdb timescaledb traefik kubernetes ssh-agent postgres recherche docker log google cloud next serverless apm glowroot docker registry

Deux petites annonces pour démarrer cette édition :

  • Je serai à KubeCon EU du 20 au 23 Mai à Barcelone. Si vous y allez aussi, dites le moi, ce sera une occasion de se rencontrer.
  • Le BigData Hebdo a ouvert son slack - Vous pouvez nous rejoindre par vous même via ce lien

APM

  • Glowroot : Pour ceux qui s’intéressent au sujet de l’APM et qui ne veulent pas aller chez AppDynamics, Dynatrace ou Elastic, j’ai assisté à une démo intéressante sur Glowroot - il est forcément moins riche que ces concurrents mais il a l’air de faire l’essentiel de ce que l’on peut attendre d’un APM. Il ne marche qu’avec la JVM.

Cloud

Container et Orchestration

DevOps

  • JSON as configuration files: please don’t : Si certains pensaient utiliser JSON pour décrire des fichiers de configurations, l’article rappelle que JSON n’est qu’un format d’échange de données et surtout pas de fichiers de configuration. On peut comprendre la tentation mais on a déjà bien assez à faire avec YAML, INI voire XML. Aucun n’est parfait certes mais pas la peine d’en rajouter.
  • In Defense of YAML : L’auteur critique l’abus autour de YAML pour l’utiliser pour tout et n’importe quoi. Comme format de données, il est utilisable mais nous voyons des détournements où du yaml devient du pseudo code. L’auteur cite la CI Gitlab ou encore Tekton. On ne peut que lui donner raison. Il serait plus simpe d’avoir un vrai langage de programmation plutôt que de tout “YAMLiser”.

Licences

  • Deprecation Notice: MIT and BSD (via Les Cast Codeurs) : Intéressant, les licences BSD/MIT serait à considérer comme dépréciée. L’auteur travaille pour le Blue Oak Council qui publie la licence du même nom. On peut éventuellement lui reprocher un certain biais mais il indique quand même que des licences modernes (comme ASL 2.0) seraient plus judicieuses que de rester sur du MIT/BSD.

Sécurité

SQL

Timeseries

Astuce du mois : gestion de la rotation des logs d’un container docker

Dans les bonnes pratiques Docker, il est dit d’utliser stdout/stderr pour avoir les logs de votre conteneur via docker logs. Toutefois, cette pratique va alimenter un fichier de log /var/lib/docker/containers/<container id>/<conteiner id>-json.log. Ce fichier peut donc saturer votre disque et aller jusqu’à corrompre vos conteneurs. L’autre bonne pratique étant que tout fichier de log doit avoir une politique de rotation du fichier associée pour éviter toute saturation de disque ou d’avoir des trop gros fichiers de logs.

Docker permet de configurer le driver de logs au niveau du démon (via /etc/docker/daemon.json), en argument lors d’un docker run ou dans docker-compose.yml.

Si l’on reste sur le driver json-file et que l’on veut piloter la rotation des logs au niveau de docker-compose.yml, cela donne par ex (version simplifiée) :

version: '3'
services:
  service_xxx:
    image: docker_image_xxx
    [...]
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "10"

Vous pouvez alors définir une stratégie de rotation des logs par container si vous le souhaitez. Ainsi, vous gérer la taille maximale de logs qui vont être générés et êtes ainsi assurés de ne pas avoir de mauvaises surprises à ce niveau là.