CérénIT

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

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à.

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 - Février 2019

kubernetes traefik postgres pandas python docker runc operator ansible vitess tidb sharding timeseries kubedb fsync ovh dns

Container et orchestration

  • The Journey to Traefik Enterprise Edition: Product Evaluation
  • Docker Security Update: CVE-2019-5736 and Container Security Best Practices : Vous avez sans doute tous entendus parlé de la faille de runc, sous le doux nom de CVE-2019-5736. Le billet indique qu’il faut utiliser une version 18.06.2+ pour Docker CE et rappelle quelques bonnes pratiques de gestion de containers. Il n’y a pas que les serveurs à mettre à jour, il y a aussi les postes de développeurs, tout aussi exposés.
  • rancher/runc-cve : Pour les gens qui ne peuvent pas mettre à jour le binaire docker, l’équipe de Rancher met à disposition des versions du binaire runc pour les versions depuis docker 1.12.6 jusqu’à 18.06.1
  • CVE 2019-5736 dans runC : l’article indique une façon d’exploiter la faille de RunC.
  • Ansible Operator: What is it? Why it Matters? What can you do with it? : Ansible ne fournit pas un “oprator” en tant que tel pour Kubernetes mais de quoi permettre de créer un operator en se basant sur des playbooks/roles ansible. Ainsi, si votre ressource change d’état par exemple, alors le playbook associé est joué. Idem pour la gestion d’un upgrade, etc. Cela s’inscrit dans la logique de pouvoir développer ses propres Operator sans avoir à les écrire en Go.
  • Mastering the KUBECONFIG file : différentes astuces autour de la gestion du fichier KUBECONFIG.
  • KubeDB : KubeDB est un operator kubernetes qui vise à pouvoir déployer et gérer différentes bases sur un cluster kubernetes. Les bases supportées sont MySQL, Postgres, Elasticsearch, Redis, MongoDB et Memcached. Le niveau de fonctionnalités dépend beaucoup de la base de données retenus (la réplication semble être gérée pour Postgres mais pas pour MySQL par ex). La version 0.10 vient de sortir, apportant le support du cluster Redis
  • Managed Kubernetes Service : OVH vient de lancer son offre kubernetes managé et pour l’utiliser depuis deux mois maintenant, elle fonctionne plutôt bien.

DNS

(No)SQL

  • Contrainte d’exclusion : nous connaissons tous les contraintes d’unicité mais parfois cela ne suffit pas. L’exmple montre comment mettre en place une contrainte d’exclusion sur la base de filtre de plage de réseaux : 192.168.122.0/28 est compris dans 192.168.122.0/24, donc si le 2nd est entré dans la base, le 1er ne pourra jamais être ajouté car il y a recouvrement. On retrouve un autre exemple de cette contrainte d’exclusion sur des dates dans l’astuce de la semaine de l’édition 289 de Posrgres Weekly.
  • Understanding Database Sharding : un billet très explicite sur le partitionnement (sharding) de base de données, pourquoi et comment le faire. Il rappelle aussi les inconvénients à le faire et ce qu’il vaut mieux faire avant d’en arriver au sharding.
  • TiDB: Distributed NewSQL with Kevin Xu : TIDB est une base qui se déploie sur Kubernetes et qui s’appuie sur RocksDB. Elle se veut “NewSQL” dans le sens où elle veut supporter à la fois des transactions et de l’analytique. Elle veut offrir notamment un support de MySQL mais dans les faits, le support reste encore limité. Pour ceux qui veulemnt déployer du MySQL sur Kubernetes avec du sharding, il vaut mieux aller voir du coté de Vitess
  • Farewell to fsync(): 10× faster database tests with Docker : alors que l’actualité était plutôt sur le fait que Postgres gérait mieux les erreurs lors d’un fsync(), l’astuce consiste ici à désactiver fsync() et/ou à mettre le dossier des données de votre base en RAM pour accélérer les temps de déroiulement de tests. Testé chez un client, c’est un gain d’au moins 20s qui a été constaté sur une opération de quelques minutes (< 5).

Timeseries

  • Tutorial: Time Series Analysis with Pandas : un tutoriel assez progressif et didactique sur la manipulation de données temporelles avec Pandas.
  • TSL: a developer-friendly Time Series query language for all our metrics : L’équipe d’OVH Metrics a crée son propre langage de requêtage orienté séries temporelles pour Prometheus et Warp10. Le billet raconte leur épopée dans le monde des base de données temporelles et comment ils en sont arrivés à créer TSL. On retrouve une syntaxe fonctionnelle et qui se retrouve assez proche de celle de Flux, qui lui supporte InfluxDB et 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

3 4 5 6 7