CérénIT

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

Web, Ops & Data - Juin 2020

terraform telegraf kubernetes operator rancher longhorn raspberrypi prometheus victoria-metrics monitoring influxdb warp10 forecast

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

Container et orchestration

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

Web, Ops & Data - Mai 2020

docker ovh openstack fedora harbor registry traefik maesh percona mysql operator timescaledb grafana kubernetes terraform iac cert-manager devops raspberrypi

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

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

IoT

Time Series

Revue rapide des operators et alternatives pour déployer du Postgresql sur Kubernetes

postgresql helm kubernetes chart operator

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

URLhttps://github.com/helm/charts/tree/master/stable/postgresql
MainteneurBitnami
Version actuelle8.2.1
Version testée7.6 & 8.2.1
Version PG disponible9.6, 10.11, 11.6, 12.1
Version PG testée11.6
ReplicationO
FailoverN
BackupN
Gestion Upgrade PGO
MetricsPrometheus

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

URLhttps://github.com/sorintlab/stolon
MainteneurSorint OSS
Version actuelle0.15.0
Version testée-
Version PG disponible9.4+, 10, 11, 12
Version PG testée-
ReplicationO
FailoverO
BackupN
Gestion Upgrade PG?
Metrics?

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

URLhttps://kubedb.com/
MainteneurAppsCode
Version actuelle0.13.0-rc0
Version testée0.13.0-rc0
Version PG disponible9.5/9.6, 10.2/10.6, 11.1
Version PG testée11.1
ReplicationO
Failover?
BackupO
Gestion Upgrade PG?
MetricsPrometheus

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

URLhttps://access.crunchydata.com/documentation/postgres-operator/4.1.0/
MainteneurCruncyData
Version actuelle4.1
Version testée-
Version PG disponible9.5/9.6, 10.10, 11.5
Version PG testée-
ReplicationO
FailoverO
BackupO
Gestion Upgrade PG?
MetricsPrometheus

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

URLhttps://github.com/zalando/postgres-operator
MainteneurZalando
Version actuelle1.3.1
Version testée-
Version PG disponible9.6, 10, 11
Version PG testée-
ReplicationO
Failover?
BackupO
Gestion Upgrade PG?
MetricsPrometheus

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…

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.