CérénIT

Le blog tech de Nicolas Steinmetz (Time Series, IoT, Web, Ops, Data)

Web, Ops, IoT et Time Series - Janvier 2024

reverse-proxy caddy traefik docker cron lora lorawan duckdb mysql postgres sqlite

Après presque 2 ans de silence et le remplacement de Hugo et Bootstrap par Zola et Tailwind/daisyUI l’été dernier pour générer le site, je vous souhaite une bonne année à tous et la résolution de publier plus régulièrement mes trouvailles…

Data

TL;DR: DuckDB can attach MySQL, Postgres, and SQLite databases in addition to databases stored in its own format. This allows data to be read into DuckDB and moved between these systems in a convenient manner.

IoT

Ops

  • DKron via Dkron pilote vos crontab : un gestionnaire de cron distribué, avec une jolie interface et uen API - que demander de plus ? Sur un modèle agent/serveur, le serveur dRkon distribue les tâches aux agents dKron concernés. les agents dKron étant déployés sur les serveurs sur lesquels les jobs doivent s’exécuter.

Reverse Proxy

  • Caddy : si vous avez besoin d’un reverse-proxy avec gestion automatique des certificats et redirection HTTP > HTTPS et plein d’autres choses encore mais sans nécessité d’intégration avec Docker comme Traefik, alors jetez un coup d’oeil à Caddy. Il permet également d’avoir un certificat sur localhost. Comme Traefik, il est écrit en Go.

J’avoue que la concision de Caddy vs Traefik et le provider file est bien appréciable:

# Caddyfile
xxx.cerenit.fr {
	reverse_proxy 127.0.0.1:3000
}

# Traefik
http:
  middlewares:
    redirectToHttps:
      redirectScheme:
        permanent: true
        scheme: https
  routers:
    grafana:
      entryPoints:
        - websecure
        - web
      middlewares:
        - redirectToHttps
      rule: Host(`xxx.cerenit.fr`)
      service: grafana@file
      tls:
        certResolver: le
  services:
    grafana:
      loadBalancer:
        servers:
        - url: http://127.0.0.1:3000/

Pour un serveur, la migration de Traefik vers Caddy fait passer le fichier de configuration de 172 lignes à 27 - soit presque 6 fois moins ! 😏

  • Caddy-Docker-Proxy via Caddy Docker Proxy, Like Traefik But Better? : si vous souhaitez aller plus loin dans l’intégration Caddy/Docker dans l’objectif de remplacer Traefik, cela semble être une bonne piste. C’est une version modifiée de Caddy pour s’interfacer avec Docker. L’intégration se fait notamment via les labels, comme pour Traefik. A voir si on peut déployer la version standalone en dehors d’un conteneur comme on peut le faire avec Traefik. Cela éviterit ainsi que chaque container à exposer via Caddy-Docker-Proxy rejoigne le réseau ad-hoc.

Exemple:

services:
  whoami:
    image: traefik/whoami
    networks:
      - caddy
    labels:
      caddy: whoami.example.com
      caddy.reverse_proxy: "{{upstreams 80}}"

networks:
  caddy:
    external: true

Web, Ops & Data - Février 2021

java repository artefact timescale postgres kapacitor grafana nomad hashicorp podman docker-compose registry docker golang vscode warp10 dataviz transformation vector linter

Container et orchrestration

  • Running Nomad for home server : pour avoir mené une expérience très similaire sur le mois de janvier, je me retrouve complètement dans ce retour d’expérience sur nomad (vs kubernetes dans une certaine mesure). Le trio nomad/consul/vault permet de faire des choses assez proches de ce que l’on peut faire avec kubernetes et parfois même de façon plus simple. Et ce, avec moins de couches intermédiaires (CSI, CNI, etc) mais aussi quelques fonctionnalités en moins. Un compromis assez réussi je trouve entre un docker nu et/ou avec docker-compose et un kubernetes.
  • Podman 3.0 has been released! : support de docker-compose, support des noms courts d’image, amélioration sur le réseau, apport de la dernière version de buildah, correction d’une CVE, etc.
  • Donating Docker Distribution to the CNCF : Docker Inc donne sa registry à la fondation CNCF pour fédérer les initiatives autour d’un même standard et élargir le champ des contributeurs/mainteneurs.
  • Panorama des outils de sécurité autour des conteneurs : comparaison des outils de bonnes pratiques et d’analyses de vulnérabilités des containers docker pour améliorer la sécurité de vos conteneurs.

Code

Monitoring & observabilité

Time Series

Si vous êtes en manque de news, vous pouvez aller consulter (et vous abonner) aux brèves du BigData Hebdo

Web, Ops & Data - Aout 2019

gitlab ci cd continous integration continous deployment git diff docker rpi traefik kubernetes ovh helm postgres percona aws partiql redis timeseries influxdb kafka prometheus

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

Web, Ops & Data - Juillet 2019

warp10 timeseries souveraineté numérique python postgres mongodb

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.

Web, Ops & Data - Avril 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à.

1 2 3 4 5