CérénIT

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

Git: hook commit-msg pour adopter les conventional commits

git commit conventional commit

Les “conventional commits” apportent une formalisation des messages de commit git. Ils sont de la forme :

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Pour reprendre quelques exemples :

# Commit message with no body
feat: allow provided config object to extend other configs

# Commit message with scope
feat(lang): add polish language

# Commit message with ! to draw attention to breaking change
refactor!: drop support for Node 6

# Commit message with both ! and BREAKING CHANGE footer
refactor!: drop support for Node 6

BREAKING CHANGE: refactor to use JavaScript features not available in Node 6.

En forçant ce formalisme, le développeur est un peu moins tenté d’avoir un historique de commit du style :

fix  button
typo
add some tests
add some tests
...

Au lieu de faire un commit à chaque sauvegarde du fichier ou presque, il va commencer à “raconter une histoire” :

fix: button on home page does not work on IE6
docs: typo in the README file
feat: add some tests for module XXX

Cela a le mérite aussi de générer un changelog plus agréable à lire. Si en plus, on rajoute par ex un identifiant de ticket, on peut alors facilement retracer l’historique d’un changement et sa raison d’être :

fix(123): button on home page does not work on IE6
docs(211): typo in the README file
feat(175): add some tests for module XXX

Un peu à la manière de “Properly managing your .gitignore file”, on peut vouloir que le hook git s’applique à tous nos dépôts présents et à venir et ne pas avoir à contribuer le hook à chaque dépôt git.

# Create ~/.git-templates/hooks
mkdir -p ~/.git-templates/hooks
# Create commit-msg file and make it executable
touch ~/.git-templates/hooks/commit-msg
chmod +x ~/.git-templates/hooks/commit-msg

Ajoutons ensuite notre hooks dans ~/.git-templates/hooks/commit-msg :

#!/usr/bin/env python3
# Original source: https://github.com/prahladyeri/enforce-git-message/
# Extended with BREAKING CHANGE, exclamation mark support (!) and space before " : " for French people

import re, sys, os

examples = """+ 61c8ca9 fix: navbar not responsive on mobile
+ 479c48b test: prepared test cases for user authentication
+ a992020 chore: moved to semantic versioning
+ b818120 fix: button click even handler firing twice
+ c6e9a97 fix: login page css
+ dfdc715 feat(auth): added social login using twitter
+ b235677 BREAKING CHANGE: remove support for XXX
+ a234556 revert!: back to version X.Y.Z for component ZZZ
+ b123456 feat : we support space before : for French people :-)
"""

def main():
    pattern = r'(build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test|BREAKING CHANGE)(\([\w\-\s]+\))?!?\s?:\s.*'
    filename = sys.argv[1]
    ss = open(filename, 'r').read()
    m = re.match(pattern, ss)
    if m == None:
        print("\nCOMMIT FAILED!")
        print("\nPlease enter commit message in the conventional format and try to commit again. Examples:")
        print("\n" + examples)
        sys.exit(1)

if __name__ == "__main__":
    main()

Il faut ensuite indiquer à git que vos templates sont dans ce dossier :

git config --global init.templatedir '~/.git-templates'

Pour les dépots git existants, il faut réinitialiser votre dépôt git :

cd /path/to/git/repo
git init
Dépôt Git existant réinitialisé dans /path/to/git/repo/.git/

Vous pouvez alors commencer à travailler dans votre repo et valider le bon fonctionnement du hook.

Web, Ops & Data - Août 2020

python vscode cassandra nosql mariadb s3 cdk terraform ptyhon setuptools git gitignore rook ceph

Cloud

  • CDK for Terraform: Enabling Python & TypeScript Support : cdk est le Cloud Development Kit édité par AWS, Hashicorp annonce donc son support dans terraform. Si la démo semble fonctionner (faut aimer typescript…), à voir ce que cela peut donner sur des projets de plus grande ampleur et ce que donne l’empilement d’abstractions (Code > CDK > Terraform > Provider) lors des erreurs et bugs.

Code

Container et orchestration

(No)SQL

  • Introducing Apache Cassandra 4.0 Beta: Battle Tested From Day One : Première beta pour la tant attendue Cassandra 4.0 - version GA espérée pour la fin d’année. On notera le passage à Java 11 et le nouveau ZGC, des gains de performance sur les tâches d’opération, un audit logging, et bien d’autres choses encore. A noter que l’écosystème semble prêt déjà à supporter la 4.0 comme avec Repair, Medusa, etc.
  • MariaDB S3 Engine: Implementation and Benchmarking : MariaDB dispose d’un plugin S3 en version alpha. Il permet de déporter des tables dans S3 et de les requêter. Pour des cas en lecture et suivant vos requêtes cela peut avoir du sens apparemment. D’autres billets sur le sujet devraient suivre prochainement.

OS

Web, Ops & Data - Janvier 2020

timeseries cloud ovh s3 object storage delta git diff faas containerd raspberrypi influxdb vscode flux warp10 observabilité docker cnab postgresql grafana

Meilleurs voeux à tous pour cette nouvelle année !

Cloud

  • OVHcloud Object Storage clusters support S3 API : pour ceux qui ne voulaient pas aller chez OVH car leur système de stockage objet est basé sur Openstack/Swift et ne voulaient pas modifier leurs appels d’API S3, une bonne nouvelle : le stockage objet d’OVH Cloud supporte l’API S3.

Container & Orchestration

  • Managing the TICK Stack with Docker App : cet article aurait pu être dans la section Time Series mais le focus étant sur Docker et Docker App, il sera dans la section Container. L’article montre comment déployer la stack TICK (Telegraf, InfluxDB, Chronograf et Kapacitor) tout d’abord via un fichier docker-compose.yml et ensuite il montre les apports de Docker App, qui permet d’avoir un niveau de personnalisation supplémentaire. Ainsi, on peut avoir un seul fichier docker-compose.yml de référence et auquel on rajoute un fichier avec des propriétés par environnement ou par client ou par instance par ex. Une combinaison intéressante pour améliorer l’industrialisation de vos containers.
  • Kubernetes 1.17 disponible sur l’offre kubernetes managé d’OVHCloud

DevOps/SRE

  • The 3 Myths of Observability : l’observabilité ne va pas directement baisser votre nombre d’incidents, l’observabilité n’est pas qu’une suite d’outils et elle n’est pas gratuite.

Outillage

  • delta : pour améliorer le rendu de vos diff et certaines commandes git (diff, show, log, stash, reflog). L’outil est réalisé en rust. Cela donne un rendu à la github/gitlab dans votre console. Sympa !

Raspberry Pi

  • faasd - lightweight Serverless for your Raspberry Pi : si vous jugez k3s encore trop gros pour vos raspberry pi pour faire tourner OpenFaaS ou que vous ne voulez pas déployer du kubernetes, vous pourriez trouver la solution du coté de faasd. Une implémentation du projet basée sur containerd (le runtime utilisée par Docker)
  • HypriotOS v1.12.0 : la distribution optimisée pour Raspberry Pi et fournissant Docker arrive en version 1.12. Elle permet d’utiliser Docker sur tous les modèles de Raspberry (0, 1, 2, 3, 4) avec les dernières versions de docker, docker-compose et docker-machine.

SQL

  • Améliorez votre SQL : utilisez des index filtrés : Postgresql permet de définir des index filtrés : plutôt que de créer un index sur toutes les données d’une table, vous pouvez définir un index qui répond à un filtre et ne faire un index que sur ce sous-ensemble de données.

Time Series

  • Grafana v6.6 Released : nouvelle version de Grafana avec comme d’habitude plein d’améliorations à tous les étages (data source, panels, alerting, explore, etc)
  • Release Announcement: Flux VSCode Support : InfluxData a publié une extension VSCode pour le langage flux.
  • InfluxDB 2.0 Open Source Beta Released : InfluxData passe la version OSS d’iInfluxDB 2.0 en béta après une année de versions alpha. On y trouve notamment une approche Configuration As Code avec la possibilité de définir des Tasks, Dashboards, ainsi que de la configuration via des Manifest en YAML et un système de packages. Flux, le nouveau langage de requêtage continue à s’améliorer et enfin le transpiler InfluxQL vers Flux fait son entrée mais demande à s’améliorer au fil du temps. La beta 2 est sortie aussi.
  • telegaf warp10 output : la prochaine version de Telegraf supportera nativement Warp10.
  • Erlenmeyer: Time Series query translator : OVHCloud vient d’opensourcer le code de leur proxy en go qui leur permet de parser des requêtes de différentes bases de données time series (OpenTSDB, PromQL, Prometheus Remote Read, InfluxQL et Graphite) en Warpscript pour requêter les données stockées dans Warp10. Pour rappel, la solution OVHMetrics est basée sur Warp10.
  • Le traitement et l’utilisation de la data dans l’industry 4.0 : SenX, la société éditrice de Warp10, a réalisé une vidéo intéressante sur le traitement et l’utilisation de la data dans l’industrie 4.0. On y voit notamment les 4 niveaux de maturité quant à la donnée et le rôle d’une base de données temporelles dans ce contexte. Un billet de blog (en anglais) est également disponible.

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 - Février 2018

grafana docker docker-compose kafka graphql swarm git https certificat sécurité inspec

API, Rest, GraphQL

  • GraphQL at the REST-aurant : une introduction à GraphQL et à ses avantages par rapport à un modèle REST en faisant une analogie avec un REST-aurant. J’ai découvert les “persisted queries”.

Container & orchestration

  • Going Production with Docker and Swarm : une présentation repassant les bonnes et mauvaises pratiques de Docker et Docker Swarm, les outils disponibles, des éléments de sizing de cluster swarm, etc. Globalement en phase avec ce que je pratique chez un client actuellement. Prochaine étape, ne plus utiliser “latest” comme référence d’images !

Dataviz

  • What’s New in Grafana v5.0 : Grosse refonte de Grafana pour l’arrivée de cette version 5.0 : nouveau système de dashboard, gestion des permissions, gestion de groupes, gestion de dossiers, nouvelle UX, etc.

Git

  • –force considered harmful; understanding git’s –force-with-lease : Si l’usage de git --force est déconseillée si ce n’est proscrite, sa variante git --force-with-lease est plus intéressante et permet d’éviter d’écraser le travail de vos camarades alors que vous pensiez juste faire un push en force sur une branche distante suite à un rebase local.
  • Advantages of monolithic version control : le débat mono-dépot vs multi-dépots est récurrent - celui- ci donne des raisons pro mono dépôt. Au delà du mono/multi dépôt, c’est surtout l’architecture d’une application et sa modularité qui sont prépondérants.

Kafka

Sécurité & Compliance

  • La fin d’une époque… : si vous utilisez des certificats issues de chez Thawte, GeoTrust et RapidSSL ayant été générés avant le 1er juin 2016 pour la 1er vague ou avant le 1er décembre 2017 (date de rachat de l’autorité de Symantec par Digicert), alors vos sites risquent d’être bloqués par les version de printemps et d’automne de Firefox et Chrome. Il vous faut renouveller vos certificats. Si votre certificat a été généré après le 1er Décembre 2017, vous n’avez rien à faire.
  • Chef InSpec 2.0 Puts the Security into DevSecOps : la spécification InSpec permet de définir/tester/valider l’état d’une machine au regard de règles de conformité et de sécurité. Cette spécification a été initiée par l’entreprise Chef (éditrice du logiciel du même nom et d’Habitat entre autres). La version 2.0 vient de sortir et apporte une intégration AWS/Azure, de nouvelles ressources de validation (docker, configuration serveurs web, clés & certificats, etc) et une amélioration des performances.

Astuce(s) du mois

Lorsque l’on déploie une même application dans plusieurs contextes via docker-compose, il est intéressant d’utiliser le COMPOSE_PROJECT_NAME qui permet de donner un préfixe à vos réseaux et containers docker a minima.

L’inconvénient est qu’il faut ajouter à vos commandes un -p <project_name> :

docker-compose -p instancea build --pull
docker-compose -p instancea up -d
docker-compose -p instancea logs -f
docker-compose -p instancea stop <service>
docker-compose -p instancea down
...

Ainsi, vos conteneurs seront nommés instancea_<service name>_<occurence> et votre réseau instancea_<network name>.

Mais il est possible d’aller plus loin avec les fichiers d’environnement .env.

Dans votre fichier .env à la racine de votre dossier où se trouve votre fichier docker-compose.yml, définissez la/les variable(s) dont vous avez besoin. Ici, nous allons nous limiter à COMPOSE_PROJET_NAME mais ne vous privez pas.

COMPOSE_PROJECT_NAME=instancea

A partir de ce moment-là, plus besoin de précier l’argument -p <project name>, vos commandes redeviennent :

docker-compose build --pull
docker-compose up -d
docker-compose logs -f
docker-compose stop <service>
docker-compose down
...

… et pour autant, vos réseaux et containers ont le bon préfix car le fichier .env est lu à l’exécution de la commande docker-compose avant de parser docker-compose.yml.

On peut aller encore plus loin en utilisant ce COMPOSE_PROJECT_NAME dans le taggage des images d’un container par ex ou

version: '3'
services:
  nginx:
    build:
      context: ./nginx/
    image: "registry.mycompany.com/nginx:${COMPOSE_PROJECT_NAME}"

Lors de la phase de build, l’image sera tagguée avec le nom passé au projet compose. Ensuite, vous pouvez poussez sur la registry de votre entreprise puis déployer cette version sur votre cluster Swarm par ex.

A noter justement une limitation actuelle de docker stack deploy <stack name> -c docker-compose.yml qui ne lit pas le fichier .env en amont et donc COMPOSE_PROJECT_NAME reste vide lors de la lecture du fichier docker-compose.yml.

Une solution possible est par ex dans le script (simplifié) de déploiement :

cd $BUILDDIR/compose/
source .env

# Remplace la variable COMPOSE_PROJECT_NAME par sa valeur
sed -i -e "s/\${COMPOSE_PROJECT_NAME}/${COMPOSE_PROJECT_NAME}/g" docker-compose.yml

docker stack deploy ${COMPOSE_PROJECT_NAME} -c docker-compose.yml

Et voilà !

1 2 3