Web, Ops & Data - Février 2020


26/02/2020 kubernetes tls swarm docker warp10 ptsm influxdata telegraf linky grafana

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

Bilan 2019 et perspectives 2020


08/02/2020 bilan perspective cérénit timeseries bigdatahebdo influxace

Rien de tel que la finalisation du bilan de cette troisième année d’activité pour faire un petit bilan sur l’année écoulée et les perspectives pour 2020. Vous pouvez retrouver le bilan des années précédentes 2018 et 2017.

Bilan 2019

Au global, tout va toujours bien, tant d’un point de vue comptable que d’activité. Une année plutôt bien remplie, voir trop remplie en nombre de jours facturés. Cela change des années précédentes où cela avait pu être un problème.

D’un point de vue comptable, cela donne :

2019 2018 2017 Variation n/n-1
Chiffre d’affaires ~150 K€ ~132 K€ ~100 K€ +14%
Résultat après impôts ~13.5 K€ ~10 K€ ~20 K€ +31%
Jours facturés ~210 ~190 ~160 +10%
TJM ~714€ ~685€ 625€ +4%

J’avais espéré retrouvé mon delta de chiffre d’affaires de façon plus sensible dans mon résultat. Ce n’est pas le cas principalement pour les raisons suivantes :

  • Le choix de meilleures mutuelle et système de prévoyance, ainsi que la mise en place d’un financement de retraites complémentaires au niveau de l’entreprise,
  • Des investissements matériels du fait d’un travail en remote à mon domicile depuis le mois de juillet et pour le Meetup Paris Time Series,
  • Des dépenses pour la réalisation d’une nouvelle identité graphique pour CérénIT, BigData Hebo et pour le Meetup Paris Time Series.

Comme chaque année, j’en profite pour remercier Fabrice et son équipe pour son accompagnement. Je l’ai déjà dit, mais avoir confiance dans son expert comptable et pouvoir compter sur lui pour apporter de bons conseils aux bons moments et être serein sur la gestion de l’entreprise, c’est indispensable.

D’un point de vue activité, c’est aussi une bonne année :

  • Contraitement aux années précédentes, avoir des missions plus régulières m’a permis de ne pas avoir le déséquilibre entre le premier et le second semestre,
  • Fin d’une mission de 18 mois au final chez LesFurets.com et depuis 6 mois, une mission en cours che Saagie ; les détails de ces missions sont disponibles sur la page Références.
  • L’investissement sur Kubernetes depuis courant 2018 m’a permis de décrocher plusieurs missions et ainsi d’avoir des références “officielles” en la matière.
  • J’avais fait le choix d’aller à moins de conférences mais je me suis rendu à KubeCon Europe à Barcelone, aux InfluxDays à Londres et au Sysadmin_Days à Paris,
  • J’ai eu le plaisir de rejoindre l’équipe du podcast BigData Hebo et d’être nominé InfluxAces. Nomination qui m’a permis de lancer et d’animer le Meetup Paris Time Series depuis le mois de septembre,
  • J’ai pu rejoindre le réseau d’indépendants CollectiveMakers qui permet de partager de l’information et d’avoir un réseau d’entraide sur des problématiques Ops/Cloud/DevOps/Sécurité.
  • Enfin, j’ai même pu me verser mes premiers dividendes, preuve de la bonne santé de l’entreprise.

Perspectives 2020

Avec la nomination d’InfluxAces, le travail sur le Meetup Paris Time Series et une première mission sur les séries temporelles, l’objectif 2020 est de développer cette activité. Je compte donc passer une partie de l’année à améliorer ma maitrise de la plateforme InfluxDB 2.0 mais aussi de la plateforme Warp10. Pour se faire, je suis passé à 4/5ème sur ma mission actuelle pour avoir un temps dédié à ce sujet et quelques autres projets à finir.

Outre cette activité, j’ai aussi prévu d’améliorer/renforcer mes compétences en matière de développement. Je m’étais rapidement formé à Go en vue d’une mission qui s’est finalement faite en Kotlin. Je compte donc creuser un peu plus le monde de la JVM (Java, Gradle, Kotlin) pour mieux comprendre son fonctionnement mais aussi voir du coté de Rust qui m’a plus séduit que Go. Avoir raté une belle opportunité de projet du fait de ne pas être assez développeur me pousse à vouloir investir sur ce sujet en plus du plaisir que j’ai à développer.

Sur les conférences, j’ai prévu d’aller à Devoxx France et à la prochaine édition des InfluxDays. A voir pour le reste de l’année.

Après un premier chantier de refonte du site suite à la nouvelle identité, je dois encore le faire évoluer pour mieux présenter les offres de service ainsi que d’autres améliorations.

Enfin, comme tous les ans, j’ai prévu de travailler à la pérénité et soutenabilité de CérénIT, d’apprendre plein de nouvelles choses pour rester pertinent et aller de l’avant. A celà s’ajoute le plaisir de contribuer/participer à la communauté BigData Hebo.

Si certains sujets vous interpellent ou si vous avez des contacts à me suggérer, n’hésitez pas à me contacter.

Paris Time Series Meetup - Edition 4 et 3


06/02/2020 timeseries influxdb meetup ptsm telegraf flux tsl redistimeseries redis

L’édition 4 du Paris Time Series Meetup s’est tenue hier soir. J’ai eu le plaisir d’accueillir David McKay, Developer Advocate InfluxData, qui est venu nous présenter la plateforme InfluxDB 2.0, le nouveau langage Flux et l’outil de collecte Telegraf (et les bonnes pratiques associées).

Vous pouvez d’ores et déjà retrouver les vidéos en ligne ; les présentations sont en anglais :

Et pour les ressources complémentaires mentionnées par David McKay :

Concernant l’édition 3 sur TSL et RedisTimeSeries, initiallement prévue en décembre 2019 et replanifiée le 21 janvier, elle aura finalement lieu le mercredi 25 Mars chez OVHCloud. Pour alimenter votre attente et comme indiqué dans le dernier billet de veille mensuelle, OVHCloud a publié erlenmeyer et vient de publier un billet de blog sur le sujet : TSL (or how to query time series databases).

Nous espérons vous y voir nombreux et en attendant, bon visionnage et bonne lecture !

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


30/01/2020 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

URL https://github.com/helm/charts/tree/master/stable/postgresql
Mainteneur Bitnami
Version actuelle 8.2.1
Version testée 7.6 & 8.2.1
Version PG disponible 9.6, 10.11, 11.6, 12.1
Version PG testée 11.6
Replication O
Failover N
Backup N
Gestion Upgrade PG O
Metrics Prometheus

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

URL https://github.com/sorintlab/stolon
Mainteneur Sorint OSS
Version actuelle 0.15.0
Version testée -
Version PG disponible 9.4+, 10, 11, 12
Version PG testée -
Replication O
Failover O
Backup N
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

URL https://kubedb.com/
Mainteneur AppsCode
Version actuelle 0.13.0-rc0
Version testée 0.13.0-rc0
Version PG disponible 9.5/9.6, 10.2/10.6, 11.1
Version PG testée 11.1
Replication O
Failover ?
Backup O
Gestion Upgrade PG ?
Metrics Prometheus

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

URL https://access.crunchydata.com/documentation/postgres-operator/4.1.0/
Mainteneur CruncyData
Version actuelle 4.1
Version testée -
Version PG disponible 9.5/9.6, 10.10, 11.5
Version PG testée -
Replication O
Failover O
Backup O
Gestion Upgrade PG ?
Metrics Prometheus

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

URL https://github.com/zalando/postgres-operator
Mainteneur Zalando
Version actuelle 1.3.1
Version testée -
Version PG disponible 9.6, 10, 11
Version PG testée -
Replication O
Failover ?
Backup O
Gestion Upgrade PG ?
Metrics Prometheus

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 - Janvier 2020


29/01/2020 timeseries cloud ovh s3 object storage delta git diff faas containerd raspberrypi docker influxdb vscode flux warp10 observabilité docker cnab postgresql grafana

Meilleurs voeux à tous pour cette nouvelle année !

Cloud

  • OVHcloud Object Storage clusters support S3 API : pour ceux qui ne voulaient pas aller chez OVH car leur système de stockage objet est basé sur Openstack/Swift et ne voulaient pas modifier leurs appels d’API S3, une bonne nouvelle : le stockage objet d’OVH Cloud supporte l’API S3.

Container & Orchestration

  • Managing the TICK Stack with Docker App : cet article aurait pu être dans la section Time Series mais le focus étant sur Docker et Docker App, il sera dans la section Container. L’article montre comment déployer la stack TICK (Telegraf, InfluxDB, Chronograf et Kapacitor) tout d’abord via un fichier docker-compose.yml et ensuite il montre les apports de Docker App, qui permet d’avoir un niveau de personnalisation supplémentaire. Ainsi, on peut avoir un seul fichier docker-compose.yml de référence et auquel on rajoute un fichier avec des propriétés par environnement ou par client ou par instance par ex. Une combinaison intéressante pour améliorer l’industrialisation de vos containers.
  • Kubernetes 1.17 disponible sur l’offre kubernetes managé d’OVHCloud

DevOps/SRE

  • The 3 Myths of Observability : l’observabilité ne va pas directement baisser votre nombre d’incidents, l’observabilité n’est pas qu’une suite d’outils et elle n’est pas gratuite.

Outillage

  • delta : pour améliorer le rendu de vos diff et certaines commandes git (diff, show, log, stash, reflog). L’outil est réalisé en rust. Cela donne un rendu à la github/gitlab dans votre console. Sympa !

Raspberry Pi

  • faasd - lightweight Serverless for your Raspberry Pi : si vous jugez k3s encore trop gros pour vos raspberry pi pour faire tourner OpenFaaS ou que vous ne voulez pas déployer du kubernetes, vous pourriez trouver la solution du coté de faasd. Une implémentation du projet basée sur containerd (le runtime utilisée par Docker)
  • HypriotOS v1.12.0 : la distribution optimisée pour Raspberry Pi et fournissant Docker arrive en version 1.12. Elle permet d’utiliser Docker sur tous les modèles de Raspberry (0, 1, 2, 3, 4) avec les dernières versions de docker, docker-compose et docker-machine.

SQL

  • Améliorez votre SQL : utilisez des index filtrés : Postgresql permet de définir des index filtrés : plutôt que de créer un index sur toutes les données d’une table, vous pouvez définir un index qui répond à un filtre et ne faire un index que sur ce sous-ensemble de données.

Time Series

  • Grafana v6.6 Released : nouvelle version de Grafana avec comme d’habitude plein d’améliorations à tous les étages (data source, panels, alerting, explore, etc)
  • Release Announcement: Flux VSCode Support : InfluxData a publié une extension VSCode pour le langage flux.
  • InfluxDB 2.0 Open Source Beta Released : InfluxData passe la version OSS d’iInfluxDB 2.0 en béta après une année de versions alpha. On y trouve notamment une approche Configuration As Code avec la possibilité de définir des Tasks, Dashboards, ainsi que de la configuration via des Manifest en YAML et un système de packages. Flux, le nouveau langage de requêtage continue à s’améliorer et enfin le transpiler InfluxQL vers Flux fait son entrée mais demande à s’améliorer au fil du temps. La beta 2 est sortie aussi.
  • telegaf warp10 output : la prochaine version de Telegraf supportera nativement Warp10.
  • Erlenmeyer: Time Series query translator : OVHCloud vient d’opensourcer le code de leur proxy en go qui leur permet de parser des requêtes de différentes bases de données time series (OpenTSDB, PromQL, Prometheus Remote Read, InfluxQL et Graphite) en Warpscript pour requêter les données stockées dans Warp10. Pour rappel, la solution OVHMetrics est basée sur Warp10.
  • Le traitement et l’utilisation de la data dans l’industry 4.0 : SenX, la société éditrice de Warp10, a réalisé une vidéo intéressante sur le traitement et l’utilisation de la data dans l’industrie 4.0. On y voit notamment les 4 niveaux de maturité quant à la donnée et le rôle d’une base de données temporelles dans ce contexte. Un billet de blog (en anglais) est également disponible.

Web, Ops & Data - Décembre 2019


18/12/2019 influxdb docker kubernetes traefik grafana dashboard cassandra reaper warp10 timeseries timescaledb helm machine-learning

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

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

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

Le Blog

Nous partageons ici notre veille et nos réflexions

Nuage de tags

docker kubernetes traefik ansible elasticsearch influxdb kafka postgres grafana timeseries python aws redis sécurité mysql tick cloud ovh cassandra helm terraform warp10 swarm telegraf test timescaledb chronograf docker-compose résilience architecture confluent ksql log machine-learning microservice prometheus rancher serverless spark angularjs api cert-manager cncf container devops git gitlab graphql hashicorp iac java javascript monitoring opensource operator optimisation ptsm raspberrypi service-mesh stream windows arm bilan csp cérénit dns documentation elastic flux gcp hpkp ingress jenkins kafka-streams kapacitor kibana lambda lean licence maintenance microsoft mobile nginx npm orientdb perspective redhat rest rethinkdb reverse-proxy s3 sauvegarde scaleway sql ssh agile apm automatisation azure bash big-data certificat ci/cd cli cluster containerd continous-delivery continous-integration cookie dashboard deployment diff fluxlang framework gdpr grav hsts http/3 https hypriot hébergement influxace influxdata istio json k3s kubedb lets-encrypt linux load-balancer maesh meetup molecule mongodb percona performance php pip pipeline postgresql reaper registry replication rook rpi rsyslog scale secrets société solr sre systemd tls vault virtualenv vscode vue.js wagtail yarn accessibilité akka alerte alibaba amazon-emr anonymisation anthos apache-pulsar ara audit bastion beam beat bigdatahebdo bounded-context branche brigade browser buildkit cahier-des-charges cassandra-reaper cd cdc centralisation-de-logs ceph certificats chart checklist chrome ci cloud-init cloud-native cloud-storage clusterip cnab cockroachdb code codeurs-en-seine confluence conftest consul continous-deployment coreos cors covid19 cqrs crash cron crontab csrf css curl d3.js daemonset data-pipelining data.gouv.fr datacenter dataviz date ddd debezium debian delta deprek8 desktop devoxx distributed-systems dive docker-app docker-hub docker-registry docker-swarm documentdb dokcer draft drop-in déploiement développement-du-site e-commerce ebs ec2 edge elassandra electron elk engineering entreprise ergonomie etcd event-sourcing faas facebook faisabilité falcor feature-policy fedora feed filebeat firebase firefox fish flash flask fleet flink fluentd forecast formation foundation frontend fsync fullstack github gitlab-ci gke glacier glowroot google google-cloud-next gpu grid géospatial hacker hadoop haproxy harbor hdfs header html html5 http hue ia iaac ibm immutable incident index influxcloud influxdays infrastructure-as-code ingénierie inspec jq jquery jwt k3d k8s k9s kotlin kubeadm kubecon kubectl laravel linky liste-de-diffusion loadbalancer logstash logstatsh loi longhorn mailing-list management mariadb message metallb micro-service mot-de-passe multi-cloud médecine métrique newsletter nodeport nomad nosql null object-storage observabilité opa opendata openebs openmetrics openshit openssh openstack openweb over-engineering packaging pandas partiql password persistent-volume-claim pipenv pod portainer prediction prescience publicité pubsub push pyenv quasardb quay queue quic ram rambleed raml react recaptcha recherche redistimeseries reindex reinvent reliability responsive revocation revue-de-code rkt rolespec root rpo rto runc rwd scalabilité scanner schema sdk search select serverless-architecture service-account service-worker sha1 sharding shell shipyard sidecar souveraineté-numérique spinnaker spécifications sri ssh-agent ssl statistique superset sympa syslog-ng test-unitaire tidb tiers timer timezone training travail tsl ubuntu unikernel unit ux vendredi victoria-metrics vie-privée virtualbox virtualisation vitess vm vnc volume voxxeddays vpc web yubikey

Syndication

Restez informé(s) de notre actualité en vous abonnant au flux du blog (Atom)