Le blog tech de Nicolas Steinmetz (Time Series, IoT, Web, Ops, Data)
Deux petites annonces pour démarrer cette édition :
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à.
Nous en avons beaucoup parlé dans l’épisode 69 de BigData Hebdo - je mets juste les liens et vous renvoie à notre discussion sur le sujet.
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).Rien de tel que la finalisation du bilan de cette seconde année d’activité pour faire un petit bilan sur l’année écoulée et les perspectives pour 2019.
Au global, tout va bien, tant d’un point de vue comptable que d’activité. L’année a été moins morcelée et compliquée que 2017.
D’un point de vue comptable, cela donne :
2018 | 2017 | Variation | |
---|---|---|---|
Chiffre d’affaires | ~130 K€ | ~100 K€ | +30% |
Résultat après impôts | ~10 K€ | ~20 K€ | -50% |
Jours facturés | ~190 | ~160 | +20% |
TJM | ~685€ | 625€ | +10% |
La baisse du résultat au regard de l’augmentation du chiffre s’explique surtout par une meilleure rémunération.
Comptablement, c’est donc une bonne année, les objectifs de soutenabilité de l’entreprise sont atteints.
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 :
D’un point de vue contribution à la communauté :
Dans le cadre du partage de connaissance, ce fut aussi l’occasion de tester un partage de connaissance chez LesFurets.com sous la forme d’un meetup hebdomadaire autour de Docker, Docker-Compose et Swarm auprès des équipes de développement et d’infrastructure en vue d’un passage de relais. L’occasion de prendre le temps de présenter les concepts et leurs applications sur une longue période.
D’un point de vue formation et veille, je me suis rendu aux conférences suivantes :
Coté formation, j’ai pu suivre la formation Kubernetes Fundamentals et la formation Déployer ses applications avec Kubernetes. Pour la certification Certified Kubernetes Administrator, j’ai jusqu’à Novembre 2019 pour la passer…
L’activité jusqu’à fin juin est assurée - n’hésitez pas à me contacter si vous avez des sujets à me proposer pour le second semestre.
Sur les conférences, j’ai décidé de me limiter en terme de nombre de conférences mais d’aller à des conférences où je n’étais pas allé comme KubeCon & CloudNativeCon à Barcelone et la SRECon à Dublin. Peut-être irais-je également à la prochaine DockerCon Euope ?
Voici quelques objectifs que je me suis fixé :
Si certains sujets vous interpellent ou si vous avez des contacts à me suggérer, n’hésitez pas à me contacter.
kubectl diff
montrera les différences entre la ressource existante et celle décrite dans la nouvelle version du fichier yaml.