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.

Container et orchestration

• Deprecations AKA KubePug - Pre UpGrade (Checker) : Pas encore testé mais un outil qui validerait les objets kubernettes déployés dans un cluster versus une version d’API donnée. Vous pourriez ainsi identifier et anticiper les dépréciations et évolutions d’API.
• Mirantis will continue to support and develop Docker Swarm : Mirantis, qui a racheté il y a peu Docker Entreprise et aussi l’orchestrateur de conteneurs Swarm, vient d’annonce qu’ils continuaient à développer Swarm sans limite de temps. Mirantis a récemment ajouter la notion de Swarm Jobs et travaille sur la gestion des volumes via les plugins CSI (Container Storage Interface)

Sécurité

• It’s the Boot for TLS 1.0 and TLS 1.1 : Mozilla, Microsoft, Apple et Google se sont mis d’accord pour ne plus supporter les versions 1.0 et 1.1 de TLS pour des raisons évidentes de sécurité. Reste que cela risque de coincer un peu de part les configurations parfois un peu hasardeuses des serveurs et de l’irrégularité de leurs maintenances ou de la vieillesse de certains packages dans certaines distributions.

Time Series

• Monitoring the Linky electricity meter : un exemple d’ingestion et de visualisation des données du compteur Linky avec InfluxDB et Grafana. Mais c’est aussi faisable avec warp10
• Les vidéos du Meetup 4 du Paris Time Series Meetup sont en ligne : David McKay, developer advocate InfluxData nous a présenté InfluxDB 2.0 & Flux ainsi que les bonnes pratiques avec Telegraf. Vous pouvez retrouver des exemples sur le dépot git influxdb-examples ainsi que le projet bring your own telegraf. Les slides sont visibles sur son compte speakerdeck.
• [Interview] How AIM45 uses Warp 10 to analyze ocean races data? : Interview d’Olivier Douillard d’AIM45 qui utilise la solution Warp10 pour collecter les données des bateaux de course au large en vue d’améliorer leurs performances de navigation mais aussi avoir le suivi de nombreux indicateurs matériels, etc. C’est aussi très bien montré sur cette vidéo “Big Data aboard the Maxi Edmond de Rothschild” avec ses 500 points de mesure qui donnent 10 millions de points par heure et quelques gigas de données après une course à analyser.

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 !

Traefik, depuis sa version V1, permet d’envoyer des métriques vers différents backends (StatsD, Prometheus, InfluxDB et Datadog). J’ai enfin pris le temps d’activer cette fonctionnalité et de creuser un peu le sujet étant donné que le dashboard de Traefik V2 n’affiche plus certaines de ses statistiques.

La documentation de Traefik sur le sujet :

• Traefik 1.x - Metrics
• Traefik 2.x - Metrics

Commençons par créer une base traefik dans InfluxDB (version 1.7.8)

influx
Connected to http://localhost:8086 version 1.7.8
InfluxDB shell version: 1.7.9
> auth
username: XXX
password: XXX
> CREATE DATABASE traefik
> CREATE USER traefik WITH PASSWORD '<password>'
> GRANT ALL ON traefik to traefik
> SHOW GRANTS FOR traefik
database privilege
-------- ---------
traefik  ALL PRIVILEGES
> quit

Dans mon cas, l’accès à InfluxDB se fait en https au travers d’une (autre) instance Traefik. J’utilise donc la connexion en http plutôt qu’en udp.

Cela donne les instructions suivantes en mode CLI :

    --metrics=true
    --metrics.influxdb=true
    --metrics.influxdb.address=https://influxdb.domain.tld:443
    --metrics.influxdb.protocol=http
    --metrics.influxdb.database=traefik
    --metrics.influxdb.username=traefik
    --metrics.influxdb.password=<password>

J’ai gardé les valeurs par défaut pour addEntryPointsLabels (true), addServicesLabels (true) et pushInterval (10s).

Cela donne le Deployment suivant :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: traefik2-ingress-controller
  labels:
    k8s-app: traefik2-ingress-lb
spec:
  replicas: 2
  selector:
    matchLabels:
      k8s-app: traefik2-ingress-lb
  template:
    metadata:
      labels:
        k8s-app: traefik2-ingress-lb
        name: traefik2-ingress-lb
    spec:
      serviceAccountName: traefik2-ingress-controller
      terminationGracePeriodSeconds: 60
      containers:
      - image: traefik:2.0.6
        name: traefik2-ingress-lb
        ports:
          - name: web
            containerPort: 80
          - name: admin
            containerPort: 8080
          - name: secure
            containerPort: 443
        readinessProbe:
          httpGet:
            path: /ping
            port: admin
          failureThreshold: 1
          initialDelaySeconds: 10
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 2
        livenessProbe:
          httpGet:
            path: /ping
            port: admin
          failureThreshold: 3
          initialDelaySeconds: 10
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 2
        args:
          - --entryPoints.web.address=:80
          - --entryPoints.secure.address=:443
          - --entryPoints.traefik.address=:8080
          - --api.dashboard=true
          - --api.insecure=true
          - --ping=true
          - --providers.kubernetescrd
          - --providers.kubernetesingress
          - --log.level=ERROR
          - --metrics=true
          - --metrics.influxdb=true
          - --metrics.influxdb.address=https://influxdb.domain.tld:443
          - --metrics.influxdb.protocol=http
          - --metrics.influxdb.database=traefik
          - --metrics.influxdb.username=traefik
          - --metrics.influxdb.password=<password>

Appliquer le contenu du fichier dans votre cluster Kubernetes

kubectl apply -f deployment.yml -n <namespace>

Sur le dashboard Traefik, dans la section “Features”, la boite “Metrics” doit afficher “InfluxDB”, comme ci-dessous :

Vous pouvez alors vous connecter à votre instance InfluxDB pour valider que des données sont bien insérées :

influx
Connected to http://localhost:8086 version 1.7.8
InfluxDB shell version: 1.7.9
> auth
username: traefik
password:
> use traefik
Using database traefik
> show measurements
name: measurements
name
----
traefik.config.reload.lastSuccessTimestamp
traefik.config.reload.total
traefik.entrypoint.connections.open
traefik.entrypoint.request.duration
traefik.entrypoint.requests.total
traefik.service.connections.open
traefik.service.request.duration
traefik.service.requests.total

Il ne vous reste plus qu’à utiliser Chronograf ou Grafana pour visualiser vos données et définir des alertes.

Un exemple rapide avec la répartition des codes HTTP dans Grafana :