CérénIT

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

Web, Ops & Data - Janvier 2021

timeseriesprometheuspromqlovhcloudiotopenhabvectortimescaledbptsmanomalielabelmachine-learningiacansiblelibsshvectorlogwarp10influxdbopensshgpgpodmandocker-composesudo

Cloud

Code

  • GitLab release feature report : le code qui permet de générer le rapport ce qui a changé entre les versions de Gitlab.
  • SSH is the new GPG : les dernières versions d'OpenSSH permettent de signer un fichier. Une solution intermédiaire entre de la signature de fichiers à base de MD5 & co qui donnent des informations de conformité mais sans indiquer qui a signé le fichier et une solution GPG plus complexe à mettre en oeuvre ?

Container et orchestration

  • Using Podman and Docker Compose : podman, le "daemonless container engine" va permettre d'être utilisé avec docker-compose dans le cadre de la version 3.0. De quoi favoriser l'adoption de podman ?

Infra as code

  • New LibSSH Connection Plugin for Ansible Network Replaces Paramiko, Adds FIPS Mode Enablement : Ansible change de librairie pour les connexions ssh en remplaçant paramiko par libssh. Elle se veut plus performante et peut être requis dans un contexte demandant du FIPS. Pensez à installer le paquet libssh-dev(el) suivant votre distribution pour pouvoir installer ansible-pylibssh. Mes premiers essais ne notent pas une amélioration sensible des performances... à voir sur d'autres machines et dans la durée...

IoT

  • openHAB 3.0 Release et Release Notes : OpenHAB est une plateforme open source de gestion de périphétiques IoT et d'automatisation autour de ces périphériques. Elle est développée en Java, support 2000 "Things" (objets, équipements, protocoles). La version 3.0 apporte une refonte et l'unification de l'UI et des composants, le passage à Java 11 et plein d'autres choses. La migration depuis une version 2.x se fait assez simplement. Avec le nouveau moteur de règle, j'ai pu supprimer mon code spécifique. Reste encore la partie "Pages" à appréhender... J'avais préféré OpenHAB à Jeedom et Home Assistant
  • Meet Raspberry Silicon: Raspberry Pi Pico now on sale at $4 : la fondation Raspberry Pi se lance dans les micro-controlleurs avec le Pico au prix de 4$.
  • Raspberry Pi PICO la carte Microcontrôleur de la Fondation : un article très détaillé sur la prise en main du pico.

Observabilité

Système

Time Series

Bilan 2020 et perspectives 2021

bilanperspectivecérénittimeseriesbigdatahebdoinfluxaceiot

Routine habituelle de début d'année pour la clôture de ce 4ème exercice (déjà !).

Bilan 2020

Au global, une bonne année au regard des conditions - les objectifs sont remplis.

D'un point de vue comptable, cela donne :

2020201920182017Variation n/n-1
Chiffre d'affaires~138 K€~150 K€~132 K€~100 K€-8%
Résultat après impôts~8 K€~13.5 K€~10 K€~20 K€-41%
Jours facturés175197178160-11%
TJM789€761€742€625€+3.6%

Contrairement aux autres années, les jours facturés ne prennent plus en compte des prestatations forfaitaires (comme l'infogérance, etc) pour lesquelles je faisais un équivalent jour. J'ai ajusté les valeurs de ce tableau mais je n'ai pas mis à jour les synthèses 2019, 2018 et 2017. Cela a pour conséquence d'améliorer sensiblement le TJM.

L'épisode COVID n'a pas eu d'impact direct sur mon activité et je fais un chiffre d'affaire conforme à ce que j'avais prévu en début d'année. Clairement, je mesure ma chance d'avoir passé cette année sans encombres professionnels. J'avais dit que je passerai à 4/5 sur l'année. Dès lors je ne pouvais envisager de factuer plus de 80% des jours ouvrés et et je parviens à en factuer 77% (toujours hors prestatations forfaitaires). En faisait un TJM de 700€ et 80% des jours ouvrés, cela me donnait un chiffre d'affaires à atteindre de 128 K€. J'atteins à peu près cet objectif avec les jours facturés et je le dépasse grâce aux prestations forfaitaires. Ces prestations forfaitaires ayant sensiblement augmenté en 2020 (passage de ~10K€ à ~13K€) et même si l'une d'entre elles a généré un investissement matériel important et qui sera compensé sur les prochaines années. Cela explique principalement la chute du résultat (si on prend 2018 comme année de comparaison, pour une chiffre d'affaire et un volume de jours facturés similaire, le résultat est 20% inférieur).

Comme chaque année, j'en profite pour remercier Fabrice pour son accompagnement en tant qu'expert-comptable. Je le dis et le répête, 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 - surtout en cette période. Même si je n'en ai pas bénéficié directement, les informations transmises pendant cette période sur les aides et autres mécanismes mis en place ont été très utiles.

D'un point de vue activité, c'est une bonne année en termes de contenus de missions :

Pour le reste, j'ai le plaisir de :

Petite déception toutefois sur la partie développement, où je n'ai pas pu me mettre sérieusement à Go ou Rust.

Enfin, je m'étais posé la question du rôle social d'une entreprise dans notre société en temps de COVID. Ma contribution a certes été modeste dans la limite de ce qui était autorisé par la loi d'une part et ne sachant pas trop comment se finirait l'année d'autre part. Je pense que je vais continuer dans cette voie et voir quel(s) projet(s) je pourrai soutenir en 2021. Content d'avoir contribué au projet Makair et de voir comment il évolue en tous cas.

Perspectives 2021

L'année commence bien avec la suite de la mission Warp 10/InfluxDB dans le monde nautique mentionnée précédemment. A celà s'ajoute une autre mission de conseil autour des usages de séries temporelles pour un autre acteur de l'énergie. J'ai du décliner un troisième appel d'offre sur un sujet similaire du fait de mes engagements actuels, mais j'espère qu'il y aura d'autres projets similaires.

Ayant aussi découvert le monde de l'impression 3D durant le premier confinement et plus récemment à jouer avec des cartes micro:bit (et peut être bientôt des ESP32), j'irais bien voir du coté de l'IoT et donner une dimension "plus industrielle" à mes usages de séries temporelles. Sortir des usages de monitoring serveur pour les séries temporelles et aller vers des usages plus industriels ou métiers est clairement intéressant. Osons le terme: direction l'industrie 4.0 !

Pour rebondir sur cette dimension usage, j'ambitionne pour le Paris Time Series Meetup d'avoir un focus usage plus important et avoir des retours d'expérience (et moins de présentation produit par des éditeurs).

Sur BigData Hebo, nous venons de lancer les brèves afin de mettre en avant les contributions des membres de la communauté. A suivre !

Pour le développement en Go et Rust, le premier devrait voir le jour dans l'année de façon assez certaine, c'est plus incertain pour le second.

Et enfin, pour le projet commencé en septembre et dont je ne peux pas encore parler, j'espère pouvoir lever le voile prochainement !

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

Stabilité vs immobilisme

stabilitéproductionservicequalitéperformancerésiliencepérénnitésérénité

Un client m’a dit récemment : “Nicolas, tu es pénible - jusqu’à présent, je pensais que la solution X était bien, mais quand je vois les mises à jour à faire ici et là, ça devient pénible” et un de ces développeurs de me dire “Mais pourquoi mettre à jour, ça marche !”. Effectivement, ça marche jusqu’au jour où cela ne marche plus.

Souvent, on dépeint les développeurs comme voulant toujours des nouveautés et les ops comme voulant la stabilité et idéalement ne rien changer. Sauf que ne rien changer, ce n’est pas apporter de la stabilité mais juste de l’immobilisme. Darwin sait comment cela se finit, à la fin, le serveur ou l’application, ils meurent. Par ricochet, le projet et l’équipe projet peuvent aussi y passer.

Par ailleurs, nous sommes dans un monde qui évolue. Des nouveautés sont apportées, ainsi que des améliorations de performance mais aussi ne les oublions pas des failles. Dès lors, lorsque l’on fournit un service quelconque, la stabilité prend un autre sens à mon avis : il ne s’agit plus de figer le service dans un état donné mais plutôt de fournir un environnement qui permet au service de s’exécuter avec la même stabilité. Votre service vit dans un écosystème et celui-ci évolue. Dès lors, la stabilité de votre service implique d’être toujours en phase avec votre écosystème. Si votre service s’interface avec le fournisseur Y, vous devez toujours être en mesure de vous interfacer avec plutôt que de dire à votre client : “Le fournisseur Y a changé son API ou je ne sais quoi, vous ne pouvez plus utiliser le service”. Dans ce cas, ce n’est pas de la stabilité que vous apporter à votre client mais une régression. D’ailleurs, la littérature informatique a un terme pour cela “Le Maintien en Conditions Opérationnelles (MCO)” (à ne pas confondre avec “Le Maintien à bout de bras” ou “Le Maintien à flot”).

Et sinon, les projets d’upgrade tous les X ans qui prennent Y mois pendant lesquels on n’apporte aucune valeur au client le temps de faire cette fichue mise à jour, c’est d’un pénible et d’un frustrant. Et faut-il encore que ce budget d’upgrade - qui ne cesse de grossir par nombre de fois où il est reporté - soit un jour accordé.

Donc tout comme il est plus facile de ranger sa chambre chaque jour un petit peu plutôt qu’une fois par mois ou trimestre, la stabilité de votre plateforme, vous l’assurez en mettant à jour régulièrement vos composants. Il y a certes un petit effort régulier à faire. Certains pourront trouver ça pénible - mais vaut mieux ça que le “plus jamais ça” après un chantier d’un an de mise à jour. Les premiers rangements, vous allez les sentir passer car ils sont encore un peu gros. Mais au fur et à mesure, ils vont diminuer et être tout à fait acceptables. En faisant aussi des petites mises à jour incrémentales et pour les bugs que vous allez découvrir, il est aussi plus facile de voir ce qui a pu créer un bug dans le cadre de la mise à jour du fait de sa taille. Dans les grosses mises à jour, il y a tellement de coupables possibles que c’est une véritable partie de Cluedo que vous allez devoir mener pendant des semaines.

De plus, avoir des composants à jour vous permet d’être supporté par les éditeurs ou les communautés d’utilisateurs. Vous éviterez la réponse “Mettez à jour - passer à la version X pour être supporté - Je ferme le ticket”.

Donc oui, je vais fortement encourager mes clients à maintenir leur système à jour car je veux leur apporter la stabilité dont ils ont besoin. Au delà du fait aussi que je ne veux pas me retrouver dans une situation dantesque en cas de pépin majeur, c’est tout autant ma tranquillité que la leur dont je m’assure de façon régulière. Cerise sur le gâteau, ils bénéficient aussi des avancées des composants et peuvent à leur tour fournir un meilleur service à leurs clients et contribuer ainsi à la pérennité de leur entreprise.

Web, Ops & Data - Décembre 2020

podmandockerruncrootlessswarmcgroupskubernetescridockershimvectorawstimestreamwarp10dashboardptsmtimescalecentosrhelpodmaninfluxdbtimeseries

Containers et orchestration

  • Electro Monkeys #37 – Podman, l’alternative de Redhat à Docker avec Benjamin Vouillaume : je me demandais si podman permettait un management de containers à distance et l'étendue de son écosystème. Le podcast permet de compléter le tour du propriétaire et de se faire une bonne idée de son positionnement.
  • How to deploy on remote Docker hosts with docker-compose : dans la même quête, je me demandais s'il était possible de piloter un noeud docker à distance quand je me suis rappelé qu'il était possible de le faire au travers d'une connexion ssh. En creusant un peu plus, j'ai découvert la notion de contexte qui permet ainsi de cibler un noeud docker, docker swarm ou kubernetes.
  • Don't Panic: Kubernetes and Docker et Dockershim Deprecation FAQ : A partir de kubernetes 1.20 (fin 2020) et définitivement à partir de la version 1.23 (fin 2021), le retrait du binaire docker comme CRI de Kubernetes est annoncé. Cela ne devrait pas changer grand chose et c'est essentiellement de la plomberie interne. Plutôt que de passer par Dockershim qui implémentait l'interface CRI et qui discutait ensuite avec Docker pour lancer les conteneurs via containerd, l'appel sera directement fait à containerd. Il n'y a que ceux qui montent la socket docker dans les pods qui vont avoir un souci. Si c'est pour builder des images, il y a des alternatives comme img, kaniko, etc. Pour les autres cas, il faudra peut être passer par l'API kubernetes ou trouver les alternatives qui vont bien.
  • What developers need to know about Docker, Docker Engine, and Kubernetes v1.20 et Mirantis to take over support of Kubernetes dockershim : Mirantis et Docker Inc vont assurer le support de cette interface dockershim pour permettre à ceux qui ont en besoin de pouvoir continuer à l'utliiser. La limite étant que si vous êtes sur du service managé et que votre provider ne le fournit pas, vous ne pourrez pas l'utiliser...
  • Kubernetes 1.20: The Raddest Release : voilà, la version 1.20 est sortie et apporte son lot de nouveautés et de stabilisation.
  • Announcing General Availability of HashiCorp Nomad 1.0 : Nomad 1.0 est également disponible.
  • Introducing Docker Engine 20.10 - Docker Blog : Docker 20.10 arrive avec des profondes nouveautés comme le support des cgroupsv2 et un mode rootless, docker logs fonctionne avec tous les drivers de log et non unqiement json & journald et plein d'autres améliorations/harmonisations au niveau de la CLI. Pour ceux sous Fedora qui avaient bidouillé avec firewalld précédemment pour faire fonctionner docker et qui ont un problème lié à l'interface docker0 au démarrage du service docker, allez voir par ici.
  • Docker Engine Release Notes - Version 20.10 : En plus des points précédents, il y a l'arrivée des jobs dans swarm - depuis le temps que je l'attendais 🤩 (même si on peut se toujours se poser la question de la pérénnité de swarm depuis qu'il a été racheté par Mirantis)
  • New features in Docker 20.10 (Yes, it’s alive) : un billet décrivant plus en détail certaines feautres de docker 20.10 comme support Fedora/CentOS, le rootless mode, l'option -mount, les jpbs swarm et une synthèse de l'actualité de l'écosystème docker.
  • Podman Release 2.2.0 : ajout des commandes network (dis)connect, support des alias avec des noms courts, amélioration des commandes play|generate kube et capacité de monter une image OCI dans un container.

Observabilité

  • Vector - Collect, transform, & route all observability data with one simple tool. (via) : vector est un outil en rust qui permet de collecter et manipuler des métriques/logs/événements et de les envoyer vers différentes destinations. De quoi remplacer filebeat/journalbeat voire même telegraf ? ;-)
  • Our new partnership with AWS gives Grafana users more options : AWS vient d'annoncer un service managé pour Prometheus basé sur Cortex et pour Grafana (version Entrepsise). Grafana et Cortex étant des projets édités par Grafana Labs sous licence OSS (et des déclinaisons Cloud et Entreprise). AWS changerait-il sa façon de travailler avec les projets OSS lorsqu'il souhaite en faire des services managés et prendre ainsi une attitude plus positive vis à vis de la communauté OSS ?

OSS

  • Death of an Open Source Business Model : Analyse du passage de Mapbox GL JS v2 sous licence propriétaire, le modèle de l'open core et les menaces des top cloud providers sur le reste de l'économie du logiciel. On peut étendre cela aussi "VC funded OSS company".

Système

  • CentOS Project shifts focus to CentOS Stream, CentOS Stream: Building an innovative future for enterprise Linux et la FAQ associée : Historiquement CentOS Linux était batie sur les sources de Red Hat Entreprise Linux un fois celle-ci disponible. CentOS Stream renverse un peu la tendance avec un cycle d'intégration plutôt Fedora -> CentOS Stream -> RHEL. L'initiative CentOS Stream avait été annoncée en septembre 2019 et ce changement permet donc aux équipes CentOS de se focoaliser sur une seule version (CentOS Stream) et non plus deux versions (CentOS Stream et CentOS Linux). CentOS Linux 7 sera maintenue jusqu'à la fin du support de RHEL 7 et et CentOS 8 jusqu'à fin 2021 (et non pas 2029 comme prévu). Il n'y aura pas de version 9 de CentOS Linux. A tester pour voir si CentOS Stream est plus stable que Fedora mais moins conservateur que RHEL et pourrait alors s'avérer être un bon compromis.
  • Before You Get Mad About The CentOS Stream Change, Think About… : un billet assez long d'un employé de Red Hat qui exprime son opinion et cherche à remettre les choses en perspective en dépassionnant le débat.

Time Series

  • PTSM Edition #8 - Amazon TimeStream 101 : Edition du Paris time Series Meetup sur AWS Timestream
  • TimescaleDB vs. Amazon Timestream: 6000x higher inserts, 5-175x faster queries, 150x-220x cheaper : avec toutes les réserves habitudelles sur les benchmarks, Timescale a comparé son produit avec AWS Timestream et la conclusion semble clairement en faveur de Timescaledb. A noter que l'update des données est arrivé dans AWS Timestream entre temps.
  • Truly Dynamic Dashboards as Code : les équipes de SenX ont implémenté leur vision du "Dashboards as Code" sous le nom Discovery. Discovery veut aller plus loin que la simple description d'un dashboard comme on peut le voir dans Grafana ou InfluxDB 2.0 en apportant une touche de dynamisme et de génération dynamique des dashboards en fonction des élements obtenus (ex si valeur X > Y alors afficher la procédure AAA de résolution d'incident). J'ai commencé à jouer avec, un billet de blog sur ce sujet devrait bientôt arriver.
  • NeuralProphet : un modèle neuronal orienté série temporelles, inspiré de Facebook Prophet et développé avce PyTorch.
  • Release Notes InfluxDB 2.0.3 et Release Announcement: InfluxDB OSS 2.0.3 : build arm64 en preview, un petit conflit de packaging entre influxdb et influxdb2 à passer pour ceux qui étaient déjà en 2.0 et ceci afin d'éviter que des gens en 1.x passent involontairement en 2.x, le "delete with predicate" a été réactivé, améliorations sur le process d'upgrade, des commandes autour des actions en mode V1, mise à jour de flux, et plein d'autres corrections/améliorations.

Web

  • Web Almanac 2020 - Rapport annuel de HTTP Archive sur l’état du Web : une synthèse de l'état du web d'après HTTP Archive sur une base de 7.5 millions de sites testés, soit 31.3 To de données traitées. De quoi relativisez un peu les biais de notre bulle technologique : non tout le monde ne fait pas du React/Angular/Vue.js par ex mais plutôt du JQuery ! Suivant vos usages, plein d'enseignements et de choses intéressantes à tirer de cette synthèse.

Il ne me reste plus qu'à vous souhaiter de bonnes fêtes de fin d'année et on se retrouve l'année prochaine !

Docker et déploiement distant : tout est histoire de contexte

dockercontextsshgitlabgitlab-ci

Kubernetes, c'est bien mais parfois on veut faire des choses plus simples et on n'a pas forcément besoin d'avoir un système distribué ou d'une forte disponibilité. Pour autant, il est agréable avec kubernetes de pouvoir interagit à distance avec l'API au travers de kubectl. Je me suis donc mis en quête d'une alternative. Partir sur k3s avec un déploiement mono-node ? Partir sur docker/docker-compose/docker-swarm ?

Je me souvenais que l'on pouvait exposer la socket docker sur le réseau en TCP et authentification par certificat mais cela ne me plaisait pas beaucoup. Je me suis alors rappelé que l'on pouvait interagir avec un hote docker via une connection ssh. En continuant à creuser, je suis tomber sur les contextes dans Docker et ce billet How to deploy on remote Docker hosts with docker-compose. Et là : 🤩

Alors, certes, pas de secrets, configmaps ou cronjobs mais un déploiement remote que je peux automatiser dans gitlab et/ou avec lequel je peux interagir à distance 😍

Création d'un contexte puis utilisation d'un contexte :

# Création du contexte docker
docker context create mon-serveur ‐‐docker “host=ssh://user@monserveur”

# Lister les contextes docker existant
docker context ls

# Utiliser un contexte
docker context use mon-serveur

# Vérifier le bon fonctionnement de la cli docker
docker ps
[liste de conteneurs tournant sur la machine "mon-serveur"]

# Vérifier le bon fonctionnement de la cli docker-compose
cd /path/to/docker/compose/project
docker-compose ps

Pour que cela fonctionne, en plus des versions récentes de docker et docker-compose coté client et serveur. Il vous faut aussi une version récent de paramiko coté client. Celle présente dans Debian 10 n'est pas assez à jour par ex, il a fallu passer par pip3 install paramiko. Il faut aussi avoir une authentification par clé pour se simplifier la vie.

Pour docker-compose, vous avez deux solutions pour utiliser un contexte distant :

# En deux commandes
docker context use <remote context>
docker-compose <command>

# En une commande
docker-compose --context <remote context> <command>

Dans gitlab, dans le fichier .gitlab-ci.yml, on peut alors profiter de cette intégration de la façon suivante ; je prends l'exemple du déploiement du site du Paris Time Series Meetup.

Tout d'abord, dans mon fichier docker-compose.yml, j'ai mis un place holder IMAGE qui sera remplacé par la référence de mon image docker fabriquée par gitlab-ci :

version: '3.8'
services:
  web:
    image: IMAGE
    labels:
        [...]
    restart: always

Ensuite, dans gitlab-ci :

  • le job "publish" génère la version html du site et le stock dans un artefact gitlab.
  • le job "kaniko" va générer l'image docker contenant la version html du site. Pour passer la version de l'image, je stocke l'information dans un fichier docker.env. Ce fichier sera sauvegardé en fin de job sous la forme d'un artefact disponible pour le job "docker".
  • le job "docker" recupère ce qui était dans le docker.env sous la forme de variable d'environnement. Il remplace ensuite IMAGE par sa vraie valeur. On initialise le contexte docker pour se connecter au serveur cible et on peut alors réaliser les actions habituelles avec docker-compose.
---
stages:
  - publish
  - image
  - deploy

publish:
  image:  $CI_REGISTRY/nsteinmetz/hugo:latest
  artifacts:
    paths:
      - public
    expire_in: 1 day
  only:
    - master
    - web
  script:
    - hugo
  stage: publish
  tags:
    - hugo

kaniko:
  stage: image
  image:
    name: gcr.io/kaniko-project/executor:debug
    entrypoint: [""]
  variables:
    RELEASE_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA-$CI_PIPELINE_ID-$CI_JOB_ID
  script:
    - echo "IMAGE=${RELEASE_IMAGE}" >> docker.env
    - mkdir -p /kaniko/.docker
    - echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json
    - /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --destination $RELEASE_IMAGE
  only:
    - master
    - web
  when: on_success
  tags:
    - kaniko
  artifacts:
    reports:
      dotenv: docker.env

docker:
  stage: deploy
  before_script:
    - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
  script:
    - sed -i -e "s|IMAGE|${IMAGE}|g" docker-compose.yml
    - docker context use mon-serveur
    - docker-compose pull
    - docker-compose up -d
  needs:
    - job: kaniko
      artifacts: true
  when: on_success
  only:
    - master
    - web
  tags:
    - shell
  environment:
    name: production
    url: https://www.ptsm.io/

Et voilà ! 😎

Avec ces contextes (que l'on peut utiliser aussi avec swarm et kubernetes), on a donc un moyen simple et efficace pour déployer des conteneurs à distance et de façon automatisée.

← Précédent 7 / 27 Suivant →