CérénIT

Surveillez le Time Series Paris Meetup, car la première édition du Meetup sera annoncée mardi avec une présentation des usages avancées des séries temporelles avec Warp10 (comprendre au-delà du monitoring classique) et une présentation par les équipes OVH sur du monitoring de datacenter aidé par du machine learning et leur offre Préscience.

CI/CD

  • How to trigger multiple pipelines using GitLab CI/CD : depuis une pipeline d’un dépôt gitlab, il va être possible d’appeler les pipelines des autres projets gitlab. Une fonctionnalité intéressante et qui pourrait lever la dépendance à Jenkins lorsque l’on a des pipelines un peu complexes et inter-projets.
  • New up and coming GitLab CI/CD Features : bilan et perspectives par le responsable produit de gitlab sur les fonctionnalités CI/CD qui ont été rajoutées cette année et celles à venir.

Code

Conteneurs & orchestration

SQL

time series

Souveraineté numérique

SQL

  • Fastest Way to Load Data Into PostgreSQL Using Python : le billet revoit différentes façons de faire ingérer des données dans Postgres via du code python. Cela va de 2 minutes à une demi seconde. De quoi piocher des idées pour la mise en place de votre prochaine ingestion de données.
  • Quel avenir pour Postgresql? : Le mérite de l’article n’est pas tant de savoir si Postgres est une alternative crédible (spoiler: oui) mais de remettre en perspective l’histoire de Postgres jusqu’à nos jours.
  • Retour d’utilisation de Mongodb et pourquoi nous migrons vers Postgresql : Retour d’expérience de l’équipe de développement de Malt.io sur leur utilisation de MongoDB, les limites et leur récente migration à Postgres pour un certain nombre de cas d’usages. Pour autant, ils n’abandonnent pas MongoDB.

Time Series

  • Warp 10™ version 2.1 : Sortie de la version 2.1 de Warp10 avec son lot de nouveautés.
  • Warp 10™ Raspberry Pi 4 bench for industrial IoT : Warp10 2.1 parvient à ingérer jusqu’à 300.000 points par secondes sur un Raspberry Pi 4 (contre une valeur recommandée il y a 2 ans d’une à quelques dizaines de milliers de points par secondes). Preuve s’il en est de l’amélioration tant du Raspberry Pi que de la performance de Warp10.

Deux petites annonces pour démarrer cette édition :

  • Je serai à KubeCon EU du 20 au 23 Mai à Barcelone. Si vous y allez aussi, dites le moi, ce sera une occasion de se rencontrer.
  • Le BigData Hebdo a ouvert son slack - Vous pouvez nous rejoindre par vous même via ce lien

APM

  • Glowroot : Pour ceux qui s’intéressent au sujet de l’APM et qui ne veulent pas aller chez AppDynamics, Dynatrace ou Elastic, j’ai assisté à une démo intéressante sur Glowroot - il est forcément moins riche que ces concurrents mais il a l’air de faire l’essentiel de ce que l’on peut attendre d’un APM. Il ne marche qu’avec la JVM.

Cloud

Container et Orchestration

DevOps

  • JSON as configuration files: please don’t : Si certains pensaient utiliser JSON pour décrire des fichiers de configurations, l’article rappelle que JSON n’est qu’un format d’échange de données et surtout pas de fichiers de configuration. On peut comprendre la tentation mais on a déjà bien assez à faire avec YAML, INI voire XML. Aucun n’est parfait certes mais pas la peine d’en rajouter.
  • In Defense of YAML : L’auteur critique l’abus autour de YAML pour l’utiliser pour tout et n’importe quoi. Comme format de données, il est utilisable mais nous voyons des détournements où du yaml devient du pseudo code. L’auteur cite la CI Gitlab ou encore Tekton. On ne peut que lui donner raison. Il serait plus simpe d’avoir un vrai langage de programmation plutôt que de tout “YAMLiser”.

Licences

  • Deprecation Notice: MIT and BSD (via Les Cast Codeurs) : Intéressant, les licences BSD/MIT serait à considérer comme dépréciée. L’auteur travaille pour le Blue Oak Council qui publie la licence du même nom. On peut éventuellement lui reprocher un certain biais mais il indique quand même que des licences modernes (comme ASL 2.0) seraient plus judicieuses que de rester sur du MIT/BSD.

Sécurité

SQL

Timeseries

Astuce du mois : gestion de la rotation des logs d’un container docker

Dans les bonnes pratiques Docker, il est dit d’utliser stdout/stderr pour avoir les logs de votre conteneur via docker logs. Toutefois, cette pratique va alimenter un fichier de log /var/lib/docker/containers/<container id>/<conteiner id>-json.log. Ce fichier peut donc saturer votre disque et aller jusqu’à corrompre vos conteneurs. L’autre bonne pratique étant que tout fichier de log doit avoir une politique de rotation du fichier associée pour éviter toute saturation de disque ou d’avoir des trop gros fichiers de logs.

Docker permet de configurer le driver de logs au niveau du démon (via /etc/docker/daemon.json), en argument lors d’un docker run ou dans docker-compose.yml.

Si l’on reste sur le driver json-file et que l’on veut piloter la rotation des logs au niveau de docker-compose.yml, cela donne par ex (version simplifiée) :

version: '3'
services:
  service_xxx:
    image: docker_image_xxx
    [...]
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "10"

Vous pouvez alors définir une stratégie de rotation des logs par container si vous le souhaitez. Ainsi, vous gérer la taille maximale de logs qui vont être générés et êtes ainsi assurés de ne pas avoir de mauvaises surprises à ce niveau là.

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.

Cloud

Container et orchestration

  • APIServer dry-run and kubectl diff : Un des soucis majeurs avec Kubernetes est l’écriture de fichiers YAML où la moindre faute peut s’insérer très rapidement et à l’insu de son auteur. Le billet présente les efforts fait pour ajouter un mode “dry run” qui simule les modifications et retourne l’objet qui aurait du être créé. Dans la même veine, un kubectl diff montrera les différences entre la ressource existante et celle décrite dans la nouvelle version du fichier yaml.
  • 9 Kubernetes Security Best Practices Everyone Must Follow : rien de transcendental mais une petite piqure de rappel après la faille majeure découverte en fin d’année.
  • Kubernetes NodePort vs LoadBalancer vs Ingress? When should I use what? : billet synthétique sur les avantages et inconvénients d’utiliser un service de type ClusterIP, NodePort, LoadBalancer ou Ingress. Sachant que l’on peut combiner LoadBalancer & Ingress !.
  • Why Is Storage On Kubernetes So Hard? : Les données, c’est tout sauf stateless et le stockage distribué c’est pas facile non plus. Le billet revient sur les logiques de stockages sous Kubernetes (PV, PVC), la couche d’interface de stockage CSI et sur des solutions comme Ceph ou Rook.
  • Stateful Kubernetes with Saad Ali - Software Engineering Daily : une présentation globale des Volumes, Persistent Volume, Persistent Volume Claims et des StorageClass sous Kubernetes et de l’évolution de la gestion du stockage sous k8s
  • Kubernetes Podcast - #36 Rook : une présentation de Rook, un opérateur k8s de gestion de stockage (Ceph, NFS, etc).

Data

IDE

Infrastructure (as Code)

  • Tester son code d’infrastructure avec Terratest : le billet présente terratest, un outil en go qui permet de tester du code Terraform, des templates Packer ou encore des images Docker. La conclusion montre qu’il n’est pas parfait certes mais peut être intéressant.
  • Infrastructure as (real) code : Faire de l’IaC, ce n’est pas que rédiger des fichiers YAML. Le billet montre comment on pourrait avoir de l’IaC avec du vrai code (du go en l’occurence). Avoir un vrai langage et un moteur de template semble en effet plus complet que juste du YAML pour lequel les validateurs sont assez faibles et la probabilité d’écrire une faute assez importante.
  • Reactive planning is a cloud native pattern : Le reactive planning tiendrait dans l’idée que pour une action donnée, il va y avoir un plan et que ce plan est constitué d’une multitude de petites étapes. Chaque étape informant la/les précédentes et voire globalement sur l’état de l’étape en cours et peut décider des étapes suivantes.

Langages

  • Why you should use pyenv + Pipenv for your Python projects : Une solution propre pour mieux gérer ses versions de python installées sur son poste / sur un serveur avec pyenv et pipenv (mix de pip et virtualenv) pour gérer les dépendances. A tester !
  • Pipenv: promises a lot, delivers very little : le billet nuance les propos autour de pipenv comme le nouveau gestionnaire officiel (autopromu) et fait le point sur l’outil.
  • shiv : Shiv permet de packager des applications python en une seule archive zip avec toutes les dépendances incluses. Disponible pour Windows / Linux / OSX, il faut néanmoins builder sur l’OS Cible pour que cela fonctionne - pas de “build one, run everywhere”.

Logs

(No)SQL

J’ai eu le plaisir et l’opportunité de participer à la réalisation de l’épisode 10 de Dev’Obs, le magazine du DevOps, pendant lequel nous avons parlé de formation, d’innovation et des tests dans la mouvance Infrastructure As Code.

Acquisition

Automatisation

  • Mitogen for Ansible : extension pour Ansible qui permettrait d’accélérer Ansible via une optimisation de la connexion à l’hôte distant. “Expect a 1.25x - 7x speedup and a CPU usage reduction of at least 2x, depending on network conditions, modules executed, and time already spent by targets on useful work. Mitogen cannot improve a module once it is executing, it can only ensure the module executes as quickly as possible.”
  • Molecule : molelcule est un framework pour Ansible permettant de tester les rôles/playbooks au travers de linter (syntaxe yaml, python, etc), mais aussi de réaliser des tests unitaires, de valider l’omnipotence d’une tâche, etc. A tester, mais vous ne devriez plus avoir de mauvaises surprises à l’exécution d’un playbook et ainsi mettre fin au cycle “run, break, fix” que l’on a trop souvent avec Ansible.
  • Ansible to adopt molecule and ansible-lint projects : les projets molecule et ansible-lint vont passer sous l’organisation Ansible sur Github et ont pour objectif d’accroitre la qualité des playbooks ansible. Cela fait apparamment partie aussi d’un objectif RedHat de péréniser les ressources liées au projet tout en étendant l’écosystème.
  • The release of Red Hat Ansible Engine 2.7 : Pas de révolution dans cette version, essentiellement des améliorations de perfomances/stabilité/connectivité. Il faudra une version python 2.7+ ou 3.5+ pour qu’Ansible fonctionne correctement.
  • Reboot Plugin for Linux in Ansible 2.7 : Avec l’arrivée de cette version 2.7 arrive également officiellement le module reboot. Il permet ainsi de piloter des playbooks pour lesquels un reboot est nécessaire (mise à jour de noyau, etc).
  • 12 Factor CLI Apps : le principe des 12 factors apps appliqué aux outils en ligne de commande. Il y a pas mal de bonnes idées (et donc de travail à faire) pour améliorer ses scripts.

(No)SQL

  • [RELEASE] Redis 5 is out! : l’annonce de la version 5.0 de la base Redis vient de sortir avec pas moins de 19 nouveautés listées. Si les Streams sont la principale nouveauté de cette version, de nombreuses améliorations ont été apportées à la base. La montée de version se veut compatilbe à 99%, il y a néanmoins quelques incompatibilités.
  • PostgreSQL 11 Released! : la version 11 de la base Postgres vient de sortir - ce que j’ai retenu de cette version majeure, c’est le support du catch-all dans le partitionning (si une donnée ne correspond à aucune clé de partitionnement, alors le catch-all récupère cette donnée) et la capacité à mettre à jour ces clés de partitionnement. D’autres nouveautés sont également intéressantes, je vous laisse le soin de les lire. Une traduction française de l’annonce est disponible sur le blog de Loxodata.

Sécurité

  • Around 62% of all Internet sites will run an unsupported PHP version in 10 weeks : Pour les sites développés en PHP, à compter de janvier 2019, il faudra être minimum en version de PHP 7.1 pour avoir les mises à jour de sécurité - le support de PHP 5.6 et 7.0 se finit à la fin de l’année.
  • Extended Validation Certificates are Dead : le bandeau avec l’intitulé de l’organisme propriétaire du certificat est en train de disaparaitre des navigateurs. Il ne sert donc plus à rien d’en acheter un.
  • Removing Old Versions of TLS : TLS 1.0 et 1.1 ne seront plus supportés en mars 2020 dans les navigateurs. Dès aujourd’hui, ces deux versions ne représentant que ~1% du traffic observé par les navigateurs, il peut être judicieux de n’utiliser que du TLS 1.2+ et voir s’il n’y a pas quelques vieux programmes à mettre à jour d’ici là…
  • Announcing the HashiCorp Learn Platform for HashiCorp Vault : pour ceux qui veulent se faire la main sur Vault et mieux gérer leurs secrets applicatifs, Hashicorp vient de lancer une plateforme gratuite et avec des contenus sous licence libre (un dépot sera prochainement mis à disposition) pour se former à leur outil Vault.
  • Firefox 63 Lets Users Block Tracking Cookies - Firefox va incorporer un mécanisme expérimental de gestion des cookies pour limiter le pistage inter sites. A activer selon vos préférences.

Le Blog

Nous partageons ici notre veille et nos réflexions

Nuage de tags

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

Syndication

Atom