24/04/2019
influxdb timescaledb traefik kubernetes ssh-agent postgres recherche docker log google cloud next serverless apm glowroot docker registry
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à.