Je ne peux résister à mentionner la sortie de l’épisode 100 du BigDataHebdo, podcast où j’ai le plaisir de contribuer. Pour ce numéro spécial (épisode 100 et 6 ans du podcast), nous avons fait appel aux membres de la communauté pour partager avec nous leur base de données favorite, la technologie qui les a le plus impressionée durant ces 6 dernières années et celle qu’ils voient comme majeure pour les 6 prochaines années. Allez l’écouter !

Cloud

• Announcing the Terraform Visual Studio Code Extension v2.0.0 : Hashicorp prend en main le support de l’extension Terraform pour VSCode, en sort une nouvelle version et apporte différentes améliorations comme un meilleur support de Terraform 0.12 et l’utilisation du Terraform Language Server.

Container et orchestration

• Introducing the Telegraf Operator: Kubernetes Sidecars Made Simple : Présentation de l’operator kubernetes pour telegraf qui permet de déployer un agent telegraf sous la forme d’un sidecar dans un pod et de récupérer les métriques associés.
• Kubernetes 1.18.x officiellement disponible chez OVHCloud
• Longhorn Simplifies Distributed Block Storage in Kubernetes : Rancher vient de sortir la version 1.0 de Longhorn. C’est une solution de stockage pour Kubernetes que l’on peut utiliser avec ou sans Rancher. Il faut la voir comme une solution de stockage légère et simple à mettre en oeuvre. Un système de réplication permet d’éviter les pertes de données et d’amélioer la durabilité des données. Des fonctionnalités de backup/restore existent également. Elle semble plus simple à mettre en oeuvre que Rook/Ceph par ex mais sera moins complète que ce dernier.
• Understanding Kubernetes & Understanding Istio : Aurélie Vache réalise des sketchnotes pour vulgariser Kubernetes et Istio. Un joli travail de vulgarisation.

IoT

• 8GB Raspberry Pi 4 on sale now at $75 : Le Raspberry Pi 4 arrive en version 8Go de RAM, Raspberry PI OS arrive en 64 bits, le support du boot sur usb arrive aussi (adieu la SDCard) et plein d’autres choses. Le tout au prix de 75$.

Ops

• Sismology: Iguana Solutions’ Monitoring System : retour d’expérience sur une plateforme de monitoring initiée sur Prometheus et qui évolue vers VictoriaMetrics en prenant les aspects de stockage à long terme, le multi-tenant et la haute disponibilité de la plateforme.

Time Series

• Release Announcement: InfluxDB 2.0.0 Beta 12 : une beta de plus avec l’ajout notamment d’influx stacks pour faire du CRUD sur des groupes de ressources InfluxDB (dashboard, labels, tasks, etc).
• Warp 10, The Most Advanced Time Series Platform, now provides multi-architecture docker images. : vous pouvez donc déployer des images docker warp10 sur des plateformes amd64/armv7/arm64.
• May 2020: Warp 10 release 2.6.0 : Pleins d’améliorations et de correctifs et notamment la capacité de dialoguer directement avec Warp10 via le protocole Protobuf ou via Arrow.
• Time series forecasts in WarpScript : Présentation de l’extension Warpscript permettant d’appliquer des algorithmes de prévisions (ARIMA, SARIMA, HOLTWINTERS, etc) sur des séries temporelles. Précision: il s’agit d’une extension propriétaire mais vous pouvez l’évaluer sur la sandbox Warp10 mise à disposition par SenX.

Le mois prochain, dans le cadre d’InfluxDays London, j’aurai le plaisir de présenter un talk sur le passage d’un monitoring Bare Metal vers un monitoring dans un monde Kubernetes avec Telegraf et InfluxDB.

Cloud

• Terraform v0.13.0 beta program : Terraform 0.13 (beta) devrait supporter au niveau des modules depends_on, count et for_each. Cela devrait éviter des dépendances parfois cryptiques.
• Deploy Any Resource With The New Kubernetes Provider for HashiCorp Terraform : la prochaine version du provider kubernetes de terraform permettra de déployer n’importe quelle ressource. Pratique ! Il vous faudra un cluster kubernetes 1.17+ pour utliser la fonctionnalité “Server Side Apply”.
• OVH : Utilisation de l’API OpenStack : Tutoriel pour le déploiement d’un wordpress sur un cluser k3s chez OVH en utilisant l’API OpenStack ; le reste du blog La Grotte du Barbu fournit plein de ressources sur kubernetes, traefik, docker, etc.

Container & orchestration

• How To Install Docker On Fedora 32 Or 31 (And Alternatives) : Même si l’utilisation de podman est recommandée en lieu et place de docke-ce depuis Fedora 31, il peut être nécessaire de vouloir utiliser docker-ce sous Fedora. Avec Fedora 32, il faut en plus des cgroups v1 à activer, il y a une règle firewall à ajouter pour que vos conteneurs aient accès au réseau / à internet.
• Harbor 2.0 : Version 2.0 de la registry Harbor qui permet d’héberger aussi des charts Helm. Pour la partie scan de vulnérabilités, le produit Clair de Quay a été remplacé par Aqua Trivy
• Announcing Maesh 1.2 : la solution de Service Mesh de Containous basée sur Traefik sort en 1.2 ; elle se base sur Traefik 2.2 et apporte donc le support de l’UDP au niveau reverse proxy. Cette version permet aussi des améliorations au niveau ACL, gestion de la configuration et gestion des middlewares par service.
• Introduction to Percona Kubernetes Operator for Percona XtraDB Cluster
• Cert-manager v0.15 and beyond
• CDK for Kubernetes : AWS vient de sortir un “Cloud Development Kit” permettant de manipuler et déployer des ressources kubernetes en python, typescript ou javascript.

DevOps

• DevOps : Discovering, Learning and Sharing (code source) : Guilhem vient de publier sa formation de culture DevOps ; à consulter !
• Radio DevOps : un podcast qui s’améliore d’épisode en épisode et plutôt adressé à des débutants dans le monde du DevOps.

IoT

• Raspberry Pi 4 USB mass storage beta (beta means it not ready yet, and not officially released!) : Le Raspberry Pi 4 va pouvoir démarrer sur un périphérique USB (clé USB, disque SSD, etc) avec l’arrivée du prochain firmware. La nécessité de la SDCard va disparaitre.

Time Series

• A multi-node, elastic, petabyte scale, time-series database on Postgres for free (and more ways we are investing in our community) : Timescale annonce que sa version cluster de TimescaleDB sera gratuite (sous licence Timescale, source code available mais pas le droit de faire un produit SaaS avec). La version monoserveur reste sous licence Apache 2.
• Grafana v7.0 released: New plugin architecture, visualizations, transformations, native trace support, and more : A l’occasion de la GrafanaCon 2020, Grafana Labs a sorti notamment Grafana 7.0 avec des tonnes d’amélioration. Il va falloir un peu de temps pour bien apprécier tout cela.
• GrafanaCon 2020 : la conférence annuelle de Grafana s’est tenue tout le mois de Mai, les vidéos sont accessibles sur la page de chaque talk après avoir saisi son email. Je n’ai malheureusement pas encore eu le temps de les visionner. Cortex 1.1 et Loki 1.5 y ont notamment été annoncés.

Dans le cadre du déploiement d’applications stateful sur un cluster kubernetes, je me suis posé la question des solutions me permettant de déployer une instance PostgreSQL. Ce comparatif est succint et comporte surement un certain nombre d’approximations. C’est le résultat de quelques heures de veille et de tests sur le sujet (jusqu’à plusieurs semaines pour KubeDB).

Chart helm PostgreSQL

Le chart est basé sur des images custom Bitnami plutôt que sur les images officielles Postgresql. Il reste toutefois possible d’utiliser les images officielles. Ce choix d’image custom se justifie par la fonctionnalité de réplication et d’avoir des images non root. Il faudra partir sur une version Debian (10.0 pour la version 8+ du chart), CentOS 7.0 ou Oracle Linux 7.

Le chart offre d’autres fonctionnalités (authentification ldap, personnalisation de pg_hba.conf, etc) et s’avère assez riche. Il peut donc a priori gérer des cas basiques à plus avancés.

Il existe un chart pour avoir une version Postgresql High Availability (non testé).

Stolon

La solution s’appuie par défaut sur les images officielles Postgresql mais il est possible d’utiliser ses propres images. Si la solution semble intéressante, je l’ai trouvé complexe, même si cela se justifie. Le fait d’avoir de multiples composants (keeper pour les instances Postgresql, des proxy pour la gestion de la connexion à la base de données et enfin des sentinels qui surveillent le tout) m’a un peu rebuté, tout comme le fait d’avoir un binaire de plus à utiliser. La documentation est assez rudimentaire également pour bien apprécier le produit.

KubeDB

Le produit est prometteur mais manque encore de stabilité : il se base sur un operateur, il est édité par une société assez implémentée dans l’écosystème kubernetes et il permet de gérer plusieurs bases de données, dont Postgresql.

L’initialisation est assez simple et le produit semble bien pensé et offre l’ensemble des fonctionnalités que l’on peut attendre d’un operator pour gérer une base Postgresql (initialisation, réplication, sauvegarde, monitoring, etc)

Pour les backups, le produit s’appuie sur stash pour faire des backups dans des espace de stockages distants (S3, Swift, etc). Pour Restic et Swift, il faut un conteneur de type object storage ’normal’. En voulant utiliser le stockage Cloud Archive d’OVH, l’intégration ne fonctionnait pas bien.

Je ne l’ai pas retenu notant des restart des pods à répétition en lisaison avec le mécanisme d’élection de leaders qui n’aboutissait pas. J’espère que les prochaines versions vont me permettre de tester à nouveau le produit.

Crunchy

Déjà, voir que l’installation se fait via Ansible ou via des commandes bash et qu’il faut un binaire spécifique pour interagir avec la plateforme, je coince un peu. La solution semble aussi très riche mais complexe à prendre en main. Venant de KubeDB, j’avoue avoir passé rapidement mon chemin.

Zalando Postgres Operator

Zalando a rendu public son operator kubernetes. Il s’appuie sur leur solution patroni pour créer un cluster haute disponibilité. Sortant de mon test KubeDB, j’ai trouvé leur modèle trop complexe et avec des fonctionnalités dont on a a priori pas besoin (les Teams ?). J’ai du coup moins l’impression de manipuler une base de données Postgres classique.

EDB Postgres on Kubernetes

EntrepriseDB, un acteur majeur de l’écosystème Postgres, a publié en septembre dernier son operator : EDB Postgres on Kubernetes. Il ne semble pas open source et l’accès aux conteneurs demande une authentification. Je ne suis donc pas allé plus loin.

Conclusion

Alors que mes besoins sont très simples (hébergement d’instances NextCloud pour quelques utilisateurs à chaque fois) et que j’utilisais pour le moment des instances Postgresql sur un seul serveur dans des conteneurs Docker (avec la gestion des backups via un container dédié), j’avoue être resté un peu sur ma fin. J’avais fondé beaucoup d’espoirs sur KubeDB mais qui tardent à se réaliser. En attendant, je suis repassé sur le chart helm qui fonctionne bien. Il faut juste prévoir un job annexe pour les backups.

Certains pourront me dire qu’il est encore trop tôt pour faire du statefull sur kubernetes ou bien qu’il faut utiliser des base de données “cloud native”. Pour le premier point, c’est aussi avec ces petits instances non critiques que l’on peut se faire la main sur le sujet et après tout, je fais ça depuis des années avec des containers Docker sans soucis. Pour le second point, faut-il encore que ces bases existent et que les outils associés les utilisent…

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

• Attaques récentes contre les noms de domaine, que se passe-t-il ? et Détails techniques sur les récentes attaques contre les noms de domaine : deux articles autour de l’actualité autour des attaques DNS évoquée ces derniers jours. Cela permet de distinguer le vrai du faux et de mieux comprendre le fonctionnement de ces attaques dans la chaine 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.