Ce soir, il y a la 8ème édition du Paris Time Series Meetup sur AWS TimeStream.

Cloud

• OVHcloud et Google Cloud annoncent un partenariat stratégique pour co-construire une solution de confiance en Europe : Les service Anthos de Google seront disponibles dans les infrastructures et hébergés par les équipes OVHCloud. Cela peut être intéressant pour ceux qui ont envie d’utiliser les services Google (sous réserve qu’ils soient disponible dans une version Anthos) tout en gardant les données à l’abri du cloud act (à vérifier en détail - notamment ce qu’il se gère ou pas au travers de la console cloud google). Une initiative intéressante pour le moins.
• New Clever Cloud Zones on top of OVHcloud in APAC and EMEA : Clever Cloud profite de son partenariat avec OVHCloud pour se déployer également dans de nouvelles zones (Roubaix, Sidney, Sinagpour, et Varsovie).
• Terraform 0.14 Adds the Ability to Redact Sensitive Values in Console Output : Terraform 0.14 (beta) n’affichera plus les informations marquées comme sensibles dans les informations qu’il affiche.
• Terraform 0.14 Adds a New Concise Diff Format to Terraform Plans : Terraform 0.14 (beta) proposera aussi un diff plus compact permettant de mieux appréhender les différences d’un plan à l’autre.

Code

• git-filter-repo : si vous avez besoin de manipuler votre dépot git, comme par ex le fait de déplacer un projet git dans un autre en gardant l’historique, alors git-filter-repo permet de le faire assez facilement.

Container et orchestration

• New Location For Stable and Incubator Charts : le 13/11, les dépots stable et incubator de helm auront migrés. Les versions 2.17.0+ et 3.4.0+ de Helm feront la redirection entre les anciennes et nouvelles urls. Pour des clients plus vieux, il faudra redéclarer les urls de stable et incubator. L’image de tiller bouge également.
• D2iQ Takes the Next Step Forward : D2iQ annonce la fin de son investissement sur DC/OS et sa concentration sur son offre kubernetes (et la transition DC/OS vers kubernetes pour ses clients).
• Setting up Cloud Operations for GKE et Troubleshooting services on GKE : une bonne raison de plus d’avoir un clustr 1.15+ chez GKE. Cloud Operations permet d’avoir un dashboard assez sympathique pour visualiser et diagnostique l’état d’un cluster GKE. Reste ensuite la partie alerting à ajuster à vos besoins.
• Announcing k0s, the Smallest, Simplest Kubernetes Distribution : Mirantis, en plus de Lens, ajoute à son arc une nouvelle distribution kubernetes nommée “k0s”. Multi-usages (Cloud, IoT, Edge, Bare Metal, etc), elle vise à simplifier le dépoiement d’un cluster kubernetes avec un binaire unique contenant tout les éléments nécessaires pour piloter votre cluster.
• OVHcloud Managed Kubernetes certified Kubernetes 1.19 : OVHCloud propose maintenant kubernetes 1.19 (et la version 1.14 ne sera plus disponible à partir de janvier 2021)

SQL

• Announcing Vitess 8 : Vitess, la base distribuée prévue pour un déploiement sur kubernetes et avec une compatibilité MySQL arrive en version 8 et améliore son support de MySQL et des principales librairies et frameworks dans différents langages.

Système

• Deprecating scp : qui n’a pas fait un scp file destination:/path/to/file ? La commande scp est victime de nombreuses failles. Du coup, elle va être dépréciée. Néanmoins une initiative vise à maintenir uen commande scp mais se fondant sur sftp et son modèle de sécurité.
• ogham/dog : dog est une réécriture de dig en rust avec coloration syntaxique et différentes fonctionnalités comme le support de DoH, DoT, etc.
• k6 : k6 est un outil de test de performance avec lequel on peut définir des scénarios plus ou moins élaborés suivant ses besoins ; je l’avais recommandé à un client pour faire des tests de performance d’API; la version 0.29 vient de sortir.

Timeseries

• InfluxData advances possibilities of time series data with general availability of InfluxDB 2.0 : InfluxDB 2.0 OSS est (enfin) là et un guide de mise à jour 1.x vers 2.x 0SS est disponible
• Announcing InfluxDB IOx – The Future Core of InfluxDB Built with Rust and Arrow : Paul Dix a annoncé le nouveau projet phare autour d’InfluxDB avec une réécriture d’une partie du coeur d’InfluxDB pour traiter les soucis de cardinalité et aller plus loin dans la partie analytique (avec un support de SQL). Cela sera basé sur les projets Apache Arrow, le format de fichier Parquet et ce sera écrit en Rust. A suivre !
• InfluxDays North America 2020 : les supports et vidéo de cette édition sont en ligne. Vous y retrouvez notamment des détails sur le projet IOx par Paul Dix, la roadmap produit par Tim Hall ou encore la mise à jour Influx DB OSS 1.x vers 2.x. Sans oublier les sessions pour se mettre à Flux ou encore l’intégration Flux/Grafana et bien d’autres choses encore.

Astuce du mois

Pour ceux sous Fedora et utilisant podman en alternative au binaire docker, pour se connecter à la registry google (via):

gcloud auth print-access-token | podman login -u oauth2accesstoken --password-stdin gcr.io

Contexte

Saagie souhaite développer un installeur de sa plateforme Data pour la déployer facilement sur des clusters Kubernetes, chez des fournisseurs Cloud ou Bare Metal / On Premises. Cet installeur peut être utilisé tant par des équipes internes Saagie que des équipes externes (Partenaires, Clients, etc)

Notre réponse

Au sein de la Release Team Saagie :

• Développement du configurateur det de l’installeur en Kotlin,
• Mise en place de la chaine de CI et de validation de l’installeur avec Jenkins, Ansible et Terraform
• Mise en place des tests unitaires et des tests d’intégration,
• Rédaction de la documentation,
• Support au déploiement pour les équipes internes et chez les clients

Bénéfices pour Saagie

• Expertise sur Kubernetes et Helm

Bénéfices pour CérénIT

• Apprentissage du langage Kotlin
• Nouvelles expériences de déploiement sous Kubernetes
• Actualisation des connaissances sous Terraform

Code et Outillage

• 18 GitLab features are moving to open source : Gitlab va rendre disponible dans sa version Open Source 18 fonctionnalités de sa version payante. C’est un peu la lutte avec Github et ses Github Actions ou ses dernières évolutions tarifaires.

Container & orchestration

• Announcing the Compose Specification : Docker Inc vient de lancer une spécificiation officielle autour de Compose (celle derrière les docker-compose.yml) pour la rendre plus “cloud native” et plus générique avec une extension au provider cloud d’une part et d’autre part à des solutions comme kubernetes ou Amazone ECS par ex.
• Announcing Traefik 2.2, ainsi que la version Entreprise TraefikEE 2.1 basée dessus : on notera le retour du support des annotations pour gérer les Ingress, le support de l’UDP (en plus de HTTP et TCP), le support d’Elastic APM, le support des stores KV (Consul, Etcd, Redis, etc) et le Dark Mode.
• Scaleway Kubernetes Kapsule : l’offre managée kubernetes de Scaleway est disponible. Dommage que les CPU des profils de machine DEV* soient surprovisionnés et qu’il faille envisager des profils GP* pour avoir des performances correctes. L’offre est du coup moins compétitive en termes de prix pour des petits clusters.
• Kubernetes 1.18 : Fit & Finish : une version de consolidation
• How to detect outdated Kubernetes APIs : présentation de Deprek8 et de Conftest pour vous permettre d’évaluer les ressources kubernetes pour lesquelles vous n’êtes pas à jour au niveau des API.
• Helm 3.2.0 avec un correctif de sécurité sur les versions 3.0.x et 3.1.x et d’autres améliorations (comme le retour de certaines fonctionnalités non encore migrées depuis la 2.x)
• Cortex v1.0 released: The highly scalable, fast Prometheus implementation is generally available for production use : la solution de monitoring distribuée et avec un stockage de long terme basée sur Prometheus arrive en version 1.0. C’est l’occasion de se repencher sur son architecture et son fonctionnement.
• Build your very own self-hosting platform with Raspberry Pi and Kubernetes : une série d’articles pour déployer un cluster kubernetes sur vos raspberrypi avec la distributions k3s et y déployer différentes applications.
• Rook v1.3: Storage Operator Improvements : si vous n’êtes pas dans un environnement cloud, il y a de fortes chances pour que vous utilisiez Rook. La version 1.3 vient de sortir et apporte son lot d’améliorations.
• Sidecar container lifecycle changes in Kubernetes 1.18 : dans la version 1.19, le cycle de vie des sidecars dans kubernetes sera améliorée. Ainsi, ils démarreront avant le conteneur principal et s’arrêteront après. Le billet revient sur les problèmes existant et comment ce nouveau cycle de vie va améliorer la situation.

(Big) Data

• Confluent Raises $250M and Kicks Off Project Metamorphosis : Confluent, la soéciété éditrice de la Confluent Platform et d’Apache Kafka, vient de lever 250 millions de dollars et annonce le projet Metamorphosis et prévoit des annonces tous les mois sur Apache Kafka, Confluent Platform et ce projet à compter du mois de Mai. On en reparlera très certainement sur BigData Hebdo.
• Cassandra: The Definitive Guide, 3rd Edition : nouvelle édition de l’ouvrage de référence sur Cassandra, mis à jour notamment pour Cassandra 4.0 (version à venir)
• Announcing Kafka-on-Pulsar: bring native Kafka protocol support to Apache Pulsar : On en parle dans le prochain épisode de BigData Hebdo, mais Pulsar est une plateforme vraiment intéressante (Pulsar 101 en français ou en anglais) et les équipes d’OVHCloud viennent de publier un connecteur qui permet d’utliser l’API Kafka mais que les messages soient stockés dans Pulsar. Il existe aussi une vidéo sur Kafka on Pulsar et un article sur le blog d’OVHCloud.

Time Series

• Release Announcement: Telegraf 1.14.0 : 9 nouveaux inputs, 3 nouveaux processors et 1 nouvel output warp10 sont au programme de cette version. Les versions 1.14.1 et 1.14.2 sont sorties également avec quelques corrections.
• Release Announcement: InfluxDB 1.8.0 with Long-Awaited Features : la branche 1.x d’InfluxDB se voit donc dotée d’une version récente de flux qui se veut “production ready” et les endpoints d’InfluxDB 2.x sont aussi disponibles. Ce qui permet d’utiliser les nouveaux clients officiels InfluxDB prévus pour la 2.x d’une part et de faire des requêtes en Flux d’autre part.
• Release Announcement: InfluxDB 2.0.0 Beta 9 : mise à jour de Flux, autocomplétion flux dans l’éditeur de requêtes et amélioration de la CLI.
• InfluxDB Templates: Easily Share Your Monitoring Expertise : le billet a pour intérêt de présenter des bonnes pratiques sur la réalisation de templates InfluxDB. Pour rappel, les templates InfluxDB sont des “ressources” que l’on peut déclarer, exporter et importer dans une instance InfluxDB 2.x. Cela concerne des variables, labels, tasks, dashboards, alertes, etc.
• April 2020: Warp 10 release 2.5.0 : La version 2.5 de Warp10 apporte notamment un Accelerator c’est à dire un cache en mémoire pour les versions standalones. D’autres corrections et améliorations font également partie de cette release.
• WarpScript ❤️ Kafka Streams : si vous utiliser Kafka Streams et que vous voulez utiliser Warpscript pour consommer, processer et envoyer des données vers Kafka, c’est possible.
• Forecasting : Microsoft publie des exemples et des bonnes pratiques autour de la prévision à base de séries temporelles. Il y a des exemples en Python / R et quelques exemples avec Azure-ML.
• TimescaleDB 1.7: fast continuous aggregates with real-time views, PostgreSQL 12 support, and more Community features : Nouvelle version de TimeScaleDB apportant la compatibilité avec Postgresql 12.x, des aggrégats en temps réel et des fonctionnalités de gestion de données (réordonnancement et rétention) de la version Entreprise sont maintenant disponibles dans la version Community.

Web

• jQuery 3.5.0 Released! : une faille XSS a été identifiée sur jQuery.htmlFilter pour toutes les versions inférieures à 3.5.0 ; il est vivement encouragé de mettre à jour vos sites. Pour le reste, je vous renvoie à la lecture de l’article.

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…

Rendez-vous le 21 janvier prochain à la troisième édition du Paris Time Series Meetup consacré à TSL (billet introductif à TSL : TSL: a developer-friendly Time Series query language for all our metrics) et le module RedisTimeSeries qui apporte des fonctionnalités et des structures Time Seriies à Redis. Le meetup était prévu initialement le mardi 17 décembre mais a été reporté du fait des grèves.

Container et orchestration

• DockerSlim : le projet vise à réduire la taille de vos images et à améliorer leur sécurité en procédant à différentes optimisations. Cela peut être intéressant dans une stratégie d’améliorations de vos images docker mais à tester néanmoins. Les exemples données partent d’Ubuntu 14.04 dont l’image fait 60 / 65 Mo alors que l’image Ubuntu 16.04 fait moitié moins et Alpine fait 30 fois moins. Donc certains gains semblent faciles à obtenir, à creuser plus en détail.
• Kubernetes 1.17: Stability : après une version 1.16 marquée notamment par la dépréciation de certaines APIs, cette version se veut plus une consolidation autour des “Cloud Provider Labels” qui passent en GA, le snapshot de volumes qui passe en beta, ainsi que la couche de stockage CSI avec la poursuite de la migration des plugins “in-tree” vs “out-of-tree”. La fin de cette migration est prévue pour les versions 1.19 / 1.20 et le retrait complet des plugins “in-tree” pour les versions 1.21 / 1.22.
• A visual guide on troubleshooting Kubernetes deployments : un guide du troublehooting des déploiements sous kubernetes avec un joli diagramme des cas possibles et les explications associées en repartant d’un exemple simple.
• How to migrate from Helm v2 to Helm v3 : les opérations à mener pour migrer de Helm V2 à Helm V3.
• Traefik 2.1 : le provider Consul Catalog fait son retour (il était absent en 2.0.x) et diverses améliorations sur la CRD Kubernetes ont été apportées pour mieux gérer le mirroring du traffic, les déploiements canary et la gestion des sessions. La migration ne consistant pas seulement à changer le numéro de version et suite à une remarque de ma part, une note a été ajoutée pour la migration 2.0.x vers 2.1.x

Dataviz

• Pro Tips: Dashboard Navigation Using Links : améliorer vos dashboards Grafana avec des liens à différents niveaux dans l’interface pour pointer vers des ressources utiles.

NoSQL

• Cassandra Reaper 2.0 was released : la solution de réparation de vos clusters Cassandra passe en 2.0 ; elle apporte un déploiement en mode sidecar (reaper est lancé dans la même jvm que Cassandra), le support d’Apache Cassandra 4.0 (pas encore officiellement disponible), de nouveaux thèmes, une amélioration du support de Postgresql comme backend de déploiement et pleins d’autres choses.

Time Series

• Release Announcement: InfluxDB 2.0.0 Alpha 21 : Cette version alpha apporte notamment le début de la transpilation des requêtes InfluxQL en Flux. C’est peut être un des plus gros enjeux pour la migration entre la version 1.x et 2.x d’InfluxDB et la gestion de l’écosystème associé.
• Warp 10™ release 2.3.0 : la plateforme Warp10 continue son chemin avec une fonctionnalité intéressante permettant de mieux définir les points que l’on veut récupérer pour une requête donnée (nombre de points, échantillonage, points du début et de fin, etc)
• Motion Split : Présentation d’une autre fonctionnalité intéressante de Warp10 2.3.0 si vous suivez des objets qui se déplacent et que vous voulez définir des groupes de points en fonction d’un délai, d’une distance, d’arrêts.
• New: Helm Charts for deploying TimescaleDB on Kubernetes : pour ceux qui utilisent TimescaleDB, des charts helm sont à votre disposition pour déployer une instance, avec gestion de la réplication des données.
• Time series features extraction using Fourier and Wavelet transforms on ECG data : Application de la théorie des signaux sur des séries temporelles dans le cadre d’analyse d’électrocardiogramme. Cela complète les articles du mois précédent.

Je n’ai plus qu’à vous souhaiter des bonnes fêtes de fin d’année ; nous nous retrouvons l’année prochaine !