Web sur Olivier DOSSMANN

Publier son blog Hugo sur Gitlab Pages

Tue, 28 Apr 2026 18:18:10 +0200

Introduction

Il y a plus d’un an je travaillais en équipe dans le cadre du passage d’un titre professionnel d’Administrateur Système DevOps. Pour étayer nos travaux nous avions choisi, entre autre, de publier un site à l’aide du très célèbre moteur de blog statique Hugo. Nous utilisions la plateforme Gitlab CI dont je vous parlais déjà pour automatiser le déploiement du site sur Gitlab Pages. C’est une plateforme pour publier gratuitement ses sites webs statiques.

Aujourd’hui nous allons voir comment publier son blog/site fabriqué avec Hugo sur Gitlab Pages, ce qui ressemblera beaucoup au tutoriel officiel de Gitlab pour construire et déployer un site Hugo. Le présent tutoriel s’appuie sur l’article précédent concernant les premiers pas avec Hugo, moteur de blog statique, je vous invite à en prendre connaissance - excepté si vous savez déjà utiliser Hugo.

Dans un premier temps nous listerons les pré-requis à l’usage de ce tutoriel, puis nous aborderons le nommage du dépôt Gitlab lors de sa création. Après quoi nous agrémenterons ce dernier avec un site Hugo (avec une configuration minime). Et nous attaquerons l’automatisation de la compilation du site sur Gitlab CI pour finalement terminer sur la publication du blog/site.

Photo trouvée sur Wikimedia Commons concernant le Tanuki du Japon sous Licence CC BY-SA 4.0.

Pré-requis

savoir utiliser Git,
avoir un compte Gitlab et avoir déposé une clé SSH sur son profil Gitlab pour y accéder,
installer Hugo sur sa machine et savoir l’utiliser (cas échéant je vous invite à lire mon article nommé « Premiers pas avec Hugo, moteur de blog statique »).

Ce « tutoriel » peut sembler long la première fois, mais il vaut la peine d’être accompli jusqu’au bout. Les fois d’après sont plus rapides, plus faciles et ne durent que quelques minutes seulement ! Je l’ai déjà fait en moins de 10 minutes - si je devais être une référence 🤣.

Création du dépôt et règles de nommage

Dans le principe, c’est très simple :

vous créez un nouveau dépôt à l’aide de « Nouveau projet/dépôt » puis « Créer un projet vide »,
vous renseignez les champs demandés, par exemple pour l’URL de projet on choisit son pseudo dans le menu déroulant,
puis il s’agit de donner un nom spécifique au dépôt et un slug correspondant.

Parlons du nom du dépôt (et du champ « identifiant slug » hérité de ce nom).

Imaginons que vous ayez comme pseudo blankoworld, pour ne viser personne 🤣 . À défaut dans Gitlab Pages votre accès est : blankoworld.gitlab.io. Essayez : il n’y a rien pour l’instant à cette URL.

Pour faciliter les choses et bénéfier d’une adresse URL permettant d’accéder à votre blog/site statique, je vous suggère fortement de créer un dépôt nommé blankoworld.gitlab.io (oui oui, avec le domaine dans le titre du dépôt). C’est la méthode la plus simple. Bien évidemment, changez blankoworld par votre pseudo choisi sur Gitlab.

Si au contraire vous créez un dépôt nommé veille par exemple, il sera finalement disponible à l’adresse blankoworld.gitlab.io/veille. C’est ce qui permet de bénéficier de plusieurs blog/sites statiques sans être limité par Gitlab.

Il est aussi possible d’utiliser un groupe Gitlab, en ce cas cela fonctionne avec le nom du groupe, par exemple odtre.gitlab.io pour le groupe nommé odtre.

Et si vous êtes intéressés par l’usage d’un nom de domaine en lieu et place de celui fourni par Gitlab pour votre blog/site statique généré ; je vous invite à lire la documentation Gitlab au sujet des noms de domaines personnalisés.

Autre point important : le niveau de visibilité de votre dépôt Git. Si le dépôt est public, ça facilitera possiblement les actions pour afficher le site final au reste du monde. Nous verrons cela en détail plus tard.

Laissez « Initialiser le dépôt avec un README » coché, comme ça nous aurons déjà un dépôt Git prêt à être récupéré.

Récupération initiale du dépôt et préparation

En bref, ça pourrait faire quelque chose comme les lignes suivantes dans une invite de commande :

PSEUDO_GITLAB=VOTRE_PSEUDO # par exemple blankoworld
DEPOT=VOTRE_DEPOT          # par exemple blankoworld.gitlab.io
git clone git@gitlab.com:${PSEUDO_GITLAB}/${DEPOT}
cd "${DEPOT}"
hugo new site . --force    # le point définit le dossier courant
git submodule add https://github.com/zhaohuabing/hugo-theme-cleanwhite themes/cleanwhite
echo "theme = 'cleanwhite'" >> hugo.toml
echo "public/" >> .gitignore
sed -i "s#baseURL = \(.*\)#baseURL = 'https://${DEPOT}/'#" hugo.toml
git add . # on ajoute les fichiers au prochain commit git
git commit -m "chore: Hugo initialized" # création du prochain commit
git push

Procédons étape par étape avec des explications.

On va récupérer notre dépôt Gitlab à l’aide de la commande suivante :

git clone git@gitlab.com:blankoworld/blankoworld.gitlab.io

blankoworld (le premier qui apparaît) est notre pseudo sur Gitlab, mais ça peut aussi être le “groupe” Gitlab sur lequel nous avons créé le dépôt (rappelez-vous le menu déroulant qui demandait l’URL du projet),
blankoworld.gitlab.io est le mot clé que je vous avais demandé de fabriquer en fonction de votre pseudo/groupe pour faciliter l’accès. Je dis mot-clé car il sera repéré par Gitlab pour mettre à disposition le site contenu dans le dépôt directement à la racine de l’adresse URL blankoworld.gitlab.io.

Ensuite on se rend dans ce répertoire pour préparer un site Hugo. D’après mon tutoriel sur la fabrication initiale d’un site Hugo, en choisissant le thème CleanWhite pour Hugo, cela ressemblerait à quelque chose comme :

cd blankoworld.gitlab.io  # pour se rendre dans le répertoire qu'on vient de récupérer avec Git
hugo new site . --force   # `--force` prend en compte les fichiers existant du dépôt Git
git submodule add https://github.com/zhaohuabing/hugo-theme-cleanwhite themes/cleanwhite
echo "theme = 'cleanwhite'" >> hugo.toml

Pour éviter d’augmenter la taille du dépôt Gitlab distant, on va ignorer - seulement sous Git - les fichiers contenus dans le répertoire public/. Ce qui revient à le rajouter dans le fichier .gitignore comme ceci :

echo "public/" >> .gitignore

Nous devons également adapter l’URL du site dans la configuration afin qu’il corresponde à l’URL fournie par Gitlab Pages pour servir votre - futur - site statique. Dans le cas où vous auriez suivi mes conseils et utilisé quelque chose comme mon_pseudo.gitlab.io, alors l’URL sera https://mon_pseudo.gitlab.io/. Dans mon cas c’est https://blankoworld.gitlab.io/ .

Éditons le fichier hugo.toml pour adapter l’URL du site comme il se doit :

baseURL = 'https://blankoworld.gitlab.io/'
locale = 'en-us'
title = 'My New Hugo Project'
theme = 'cleanwhite'

Il ne reste plus qu’à enregistrer les changements dans le dépôt Git et l’envoyer sur Gitlab :

git add .                               # on ajoute les fichiers au prochain commit git
git commit -m "chore: Hugo initialized" # création du prochain commit
git push                                # on pousse le résultat sur Gitlab

À ce stade, nous avons un site Hugo - très sommaire - avec un thème et l’URL de Gitlab enregistrée dans la configuration. Ce sont les seuls besoins vitaux pour compiler et publier le site. Rédiger un article est une étape qui peut attendre.

Voyons désormais comment permettre la publication de notre travail.

Automatisation avec compilation d’Hugo

La documentation de Gitlab sur l’intégration continue parle d’un fichier .gitlab-ci.yml à fournir à la base du répertoire principal.

Ce fichier .gitlab-ci.yml - oui, oui, avec un point devant le nom du fichier - va décrire les actions à effectuer pour construire, ou plutôt compiler, votre site Hugo et le publier sur Gitlab Pages.

Créons donc le fichier .gitlab-ci.yml à la base de notre répertoire principal - dans mon cas dans le dossier blankoworld.gitlab.io - avec le contenu suivant :

 1default:
 2  image: "hugomods/hugo:exts"
 3
 4variables:
 5  GIT_SUBMODULE_STRATEGY: recursive
 6  HUGO_ENV: production
 7
 8create-pages:
 9  script:
10    - hugo
11  pages: true
12  artifacts:
13    paths:
14      - public
15  rules:
16    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

C’est une version allégée de celle trouvée sur la documentation Gitlab à propos de la publication d’un site Hugo en utilisant Gitlab CI.

Inutile d’être un as de l’écriture de fichiers .gitlab-ci.yml pour en comprendre le détail :

Les lignes 1 à 2 renseignent l’image Docker à utiliser pour compiler votre site. Ici nous utilisons les excellentes images Docker fournies par Hugomods. Attention cependant à trouver une image qui contient aussi l’outil Git pour récupérer le thème du site,
ligne 4 à 6, nous avons respectivement une variable GIT_SUBMODULE_STRATEGY pour définir la statégie de récupération Git (utile pour récupérer notre thème) et HUGO_ENV pour définir l’environnement cible pour la compilation Hugo,
ligne 8 à 17 sont les lignes où tout va se jouer. C’est là qu’on décrit la commande à lancer - ici c’est juste hugo. Le fait qu’on souhaite utiliser Gitlab Pages et qu’on va utiliser le contenu résultant du dossier public pour l’envoyer sur Gitlab Pages.
ligne 15 et 16 définissent dans quel cas exécuter cette étape nommée create-pages. En l’occurrence cela ne sera que si la branche attachée au commit est la branche par défaut dans Gitlab. Si vous m’avez suivi dès le départ, nous n’avons qu’une seule branche dans Gitlab nommée master.

Une fois le fichier dûment complété, n’oubliez pas de l’ajouter au dépôt Git et de pousser le tout sur Gitlab :

git add .gitlab-ci.yml
git commit -m "feat(CI): Add .gitlab-ci.yml file to compile Hugo"
git push

Vous devriez retrouver rapidement les détails de la compilation dans le menu Gitlab (à gauche) nommé “Compilation > Pipelines”. Les pipelines de Gitlab CI représentent une suite automatisée d’étapes justement fournies dans le fichier .gitlab-ci.yml. Donc chaque fois que vous ferez un commit sur votre dépôt et que vous poussez le résultat sur Gitlab, une pipeline s’exécutera si et seulement si le fichier .gitlab-ci.yml est présent dans votre dépôt (et qu’il soit bien bien formé comme Gitlab CI l’attend).

Mais ne crions pas victoire trop tôt, nous avons encore quelques détails à régler.

Publication de son blog

Bien entendu, suite à notre dernier commit Git, une pipeline s’est exécutée. Elle est sûrement arrivée au bout de son exécution et le site est envoyé vers Gitlab Pages.

Cependant même en ayant l’URL il se pourrait que vos visiteurs n’accèdent pas au site : nous devons vérifier la « visibilité du site ». Et où cela se trouve ? Dans les paramètres de votre dépôt.

Sur Gitlab, une fois sur votre dépôt :

allez dans le menu latéral gauche et choisissez cette fois “Paramètres > Général”,
puis cliquez sur le titre “Visibilité, fonctionnalités du projet, autorisations”. Vous devriez avoir une loooooongue liste de boutons à cocher/décocher,
parmi eux, sous un titre “Pages”, doit se trouver un bouton activé. Et un menu déroulant pour choisir qui peut voir le site,
si vous souhaitez que tout le monde puisse accéder au site, choisissez “Toute personne ayant accès”,
ET n’oubliez pas d’aller plus bas de la page pour cliquer sur le bouton “Enregistrer les modifications”. Cas échéant vos modifications n’auront aucun effet.

Le menu “Paramètres > Général” en image :

et son petit copain l’encart “Pages” également en image :

C’est tout bon ! Vous devriez avoir un site accessible sur mon_depot.gitlab.io, dans mon cas c’est blankoworld.gitlab.io. Allez vérifier tout de même 😉.

Conclusion

À travers quelques étapes comme la création du dépôt, celle du site Hugo, la configuration de ce dernier, l’ajout d’un fichier .gitlab-ci.yml et finalement une configuration Gitlab, nous avons vu que quelques minutes suffisent à démarrer un nouveau blog/site statique, ce qui est très pratique !

Loin d’être un modèle de beauté, nous avons pourtant un site prêt à l’usage sur Gitlab Pages, à l’adresse blankoworld.gitlab.io. Chaque nouvelle modification enregistrée par Git (via un commit) puis poussée sur Gitlab génèrera une pipeline Gitlab CI qui publiera le site Hugo sur l’adresse fournie ci-avant.

Si d’aventures vous voudriez voir ce qui a été fait, je vous invite à lire le dépôt Gitlab utilisé pour ce tutoriel sur la publication d’un site Hugo sur Gitlab Pages.

Vous pourriez aller plus loin en ajoutant un domaine personnalisé sur votre dépôt Gitlab en lisant la documentation Gitlab. Vous allez devoir cependant apprendre comment avoir un nom de domaine et comment en modifier ce qu’on appelle la zone DNS. Mais ceci est une autre histoire que nous n’aborderons pas aujourd’hui.

Amusez-vous bien et n’hésitez pas à tester votre site Hugo en local avant de pousser le résultat sur le dépôt Gitlab 😉 .

Liens utiles

Voici les liens de l’article par ordre d’apparition :

Premiers pas avec Hugo, moteur de blog statique

Tue, 07 Apr 2026 17:19:03 +0200

Introduction

Hugo est un moteur de blog statique célèbre pour sa rapidité et sa souplesse d’utilisation. Il permet de générer un site web contenant des milliers d’articles en quelques secondes.

Qu’entends-tu par générer un site web ?

Dire que c’est un moteur de site statique signifie que l’outil va prendre un répertoire d’origine comme base pour compulser les données et générer des pages webs comme par exemple des pages HTML, CSS, XML ou encore du JS (mais d’autres formats sont possibles).

Quel(s) avantage(s) à ce qu’il soit statique ? Une fois vos fichiers générés dans un dossier cible (par exemple un dossier nommé « public »), vous pouvez le déposer chez n’importe quel hébergeur web.

Imaginez votre blog, votre site vitrine ou un site professionnel : aucune dépendance, pas de faille de sécurité liée au langage ou au framework choisi pour publier le site, pas de surcoût de serveur pour des environnements particuliers, pas de lenteurs sur votre site pour calculer tous les éléments avant de les servir à chaque visiteur, etc.

En somme fournir un site web statique est très pratique, économique et facile. D’autant qu’il existe des hébergeurs gratuits pour fournir vos fichiers HTML, CSS, XML, JS. Pourquoi ne pas en profiter ?

En 2016, j’ai fait le choix de migrer mon blog sur Hugo, j’ai donc un peu de bouteille dans son utilisation. J’ai d’ailleurs proposé un thème nommé Adam & Eve pour Hugo que j’utilise pour l’espace Recueil de ce blog.

Aujourd’hui nous allons faire nos premiers pas dans la création d’un blog statique à l’aide d’Hugo. Nous parlerons de l’installation de l’outil, puis de la création du squelette principal, le choix d’un thème, la configuration du blog et la rédaction d’un article avant de générer notre premier blog Hugo 😎.

Photo trouvée sur le profil de Stephen Bowler sur Flickr sous licence CC BY 2.0.

Installation

Étant donné qu’Hugo est un outil qui s’utilise en ligne de commande, il faut installer le binaire sur notre machine. En fonction de votre système d’exploitation la méthode diffère.

La documentation officielle sur l’installation d’Hugo est bien faite. Je vous invite à la consulter promptement.

Si vous avez une distribution GNU/Linux, il existe sûrement un paquet spécifique d’Hugo pour votre distribution.

Par exemple sous ArchLinux il me suffit de faire :

sudo pacman -S hugo

Et le tour est joué !

Une fois installée, vous pouvez taper la commande suivante dans une console pour vérifier que tout soit en ordre :

hugo version

Cela affiche la version d’Hugo que vous venez d’installer.

Plusieurs méthodes permettent d’avoir des infos sur la commande hugo :

man hugo
hugo help

Ou tout simplement se rendre sur la documentation officielle d’Hugo.

Créer un nouveau site

Pour générer un nouveau site nommé superblog :

hugo new site superblog

Hugo lui-même vous informe des étapes à suivre pour terminer votre projet de site, parmi :

se rendre dans le nouveau répertoire,
choisir et ajouter un thème,
configurer le site à l’aide du fichier hugo.toml,
créer du contenu,
vérifier le résultat avec un serveur local dédié (rien que ça !).

Agissons de suite : rendez-vous dans le répertoire superblog et passons au chapitre suivant.

cd superblog

Choisir un thème

L’avantage d’avoir un outil très connu c’est de bénéficier d’innombrables thèmes proposés par la communauté. Vous les retrouverez sur un site officiel dédié aux thèmes prévus pour Hugo.

Étant donné que le travail est fourni par la communauté, leur qualité ou la couverture de fonctionnalités intégrées est dépendante du temps passé sur ces thèmes et le temps accordé à leur maintenance. Autrement dit : il y a à boire et à manger là dedans !

Parcourez l’annuaire de thèmes Hugo, choisissez un thème, par exemple le thème Clean White pour Hugo et cliquez de droit sur le bouton « Download » pour copier l’adresse où se trouve le thème.

Pour l’installer il suffira de taper la commande suivante dans le répertoire superblog (exemple avec le thème Clean White) :

# Nécessite d'avoir la commande `git` installée sur sa machine
git init && git submodule add https://github.com/zhaohuabing/hugo-theme-cleanwhite themes/cleanwhite

On enregistre ensuite le thème dans la configuration de ce site - dont nous parlerons dans le chapitre suivant :

echo "theme = 'cleanwhite'" >> hugo.toml

Si vous êtes curieux du résultat, vous pouvez directement lancer la commande suivante :

hugo serve -D

qui aura pour effet de lancer un serveur web en arrière plan et de vous fournir une adresse URL où consulter votre nouveau site. Par exemple sur http://localhost:1313/. Pour arrêter le serveur, pressez simultanément les touches [Ctrl]+[c].

Regardons de plus près la configuration du site.

Configuration du site, le fichier hugo.toml

La configuration principale de votre site se trouve dans le fichier hugo.toml (anciennement config.toml). La documentation officielle sur le fichier hugo.toml vous donnera une idée de l’ampleur des possibilités qu’offre la configuration d’un site Hugo.

Cantonnons-nous ici de quelques éléments seulement. Le contenu actuel du fichier hugo.toml est :

baseURL = 'https://example.org/'
locale = 'en-us'
title = 'My New Hugo Project'
theme = 'cleanwhite'

Les éléments sont plutôt parlants :

baseURL : va définir l’adresse URL finale de votre site (par exemple pour mon blog ça sera https://olivier.dossmann.net/),
locale : définit le langage du site au regard de la RFC5646,
title : est le titre affiché sur le site,
et theme est l’adresse vers les fichiers du thème utilisé pour notre site.

Modifions le fichier hugo.toml pour ressembler à ceci :

baseURL = 'https://example.org/'
locale = 'fr'
title = 'Mon Super Blog'
theme = 'cleanwhite'
enableEmoji = true

On relance le serveur local intégré à Hugo pour voir le résultat :

# Faites Ctrl + c pour arrêter le serveur
hugo serve -D

On a rajouté une ligne enableEmoji pour activer l’utilisation des emojis dans les articles. Cf. la page de la documentation officielle consacrée à la liste des émojis disponibles sous Hugo.

Mon premier article

Commençons par créer ledit article :

# Très souvent les thèmes proposés n'utilisent que les articles situés dans le dossier "post"
hugo new content -k post post/mon_premier_post.md

L’extension .md est ici nécessaire. L’option -k va suggérer d’utiliser un template post.md s’il existe. C’est ce qu’on appelle un archétype : un fichier au format Markdown situé dans le dossier themes/monTheme/archetypes/ (par exemple themes/cleanwhite/archetypes/post.md) qui sera copié en lieu et place de l’article demandé ; ici dans post/mon_premier_post.md. Les fichiers sont toujours placés dans le dossier content.

Le fichier est placé dans le dossier content/post/mon_premier_post.md dont voici le contenu :

---
title:       "An Example Post"
subtitle:    ""
description: ""
date:        2018-06-04
author:      ""
image:       ""
tags:        ["tag1", "tag2"]
categories:  ["Tech" ]
---

Les articles auront toujours la même forme :

Une entête délimitée par une chaîne de caractère de début et de fin (ici --- en début et fin),
Le contenu de l’article, écrit au format Markdown (par défaut).

Dans le cas présent, nous n’avons aucun contenu.

L’article propose seulement une entête contenant des informations qui seront utilisées comme méta-données de l’article (par exemple son titre, une description, un sous-titre, l’auteur de l’article, éventuellement une image, des balises (tags) et des catégories). L’exemple utilise les tags nommés tag1 et tag2 ; et une catégorie Tech.

Notez également la date fournie : on peut déterminer la date de publication d’un article. Si c’est une date dans le futur, alors l’article ne sera pas publié - ce qui est très pratique !

Pour empêcher également qu’un article soit publié, on peut rajouter une information comme :

draft: true

Ce qui aura pour effet, excepté si l’option -D est ajoutée, de ne pas rendre disponible cet article - très pratique aussi !

Ajoutez quelques lignes à la fin du fichier (après les méta-données et la chaîne de caractère ---) pour regarder le résultat :

# Titre 1

Quelques lignes avec du texte en **gras**, ou *italique*, c'est comme vous voulez.

# Titre 2

## Sous-titre

Avec un lien vers [mon blog](https://olivier.dossmann.net/).

On vérifie à l’aide de la commande hugo serve -D.

Compilation du site

Maintenant que nous avons un site, un thème configuré dans le fichier hugo.toml et un article, voyons l’étape de compilation.

La compilation, avec Hugo, c’est le fait de prendre l’ensemble des fichiers et informations du site et de les transformer en un dossier complet qui fournit les pages Web - et tout autre fichier nécessaire à l’élaboration du site. Hugo stocke le résultat dans un dossier nommé public.

Pour lancer la compilation complète, on peut, à la racine du site, taper la commande suivante :

hugo

Cette commande seule suffit à compiler l’ensemble du site et le rendre disponible dans le dossier public. C’est le contenu de ce dernier que vous devez déposer dans l’espace fourni par votre hébergeur de site web.

On peut agrémenter la commande de plusieurs options, par exemple :

hugo -D --minify

L’option -D va aussi compiler les articles dits « brouillons » (ayant draft: true dans la section des méta-données).

L’option –minify va réduire la taille des fichiers en enlevant le plus possible les espaces, retour à la ligne et assimilés.

Il y a énormément d’options et là encore la documentation officielle d’Hugo sur la commande hugo permet d’en savoir plus.

Conclusion

À travers quelques étapes simples, nous avons vu comment installer la commande hugo, créer un nouveau site, ajouter un thème, configurer le site, rédiger un article et compiler l’ensemble pour générer les fichiers suffisants pour créer un nouveau site web statique.

Hugo est un moteur de site statique très riche et bourré de fonctionnalités en tous genres comme la gestion de contenu multilingue, l’usage de « bouts de code » réemployables, le redimensionnement des images, les commentaires, la génération d’un ou plusieurs flux RSS, la personnalisation des thèmes, une page 404 personnalisée, l’usage de coloration syntaxique pour les balises HTML code, le serveur web embarqué, une commande de déploiement et bien plus encore…

C’est mon outil favori depuis 2016. Je prévois cette année encore de concocter un article supplémentaire à son sujet qui dépendra du présent article qui, je l’espère, vous plaira.

Qui sait, peut-être vous lancerez-vous, vous aussi, dans la création et la publication d’un blog - et cela gratuitement 😉.

Liens utiles

Voici les liens de l’article par ordre d’apparition :

Encore un autre lecteur de flux RSS, Yarr

Sun, 22 Mar 2026 11:42:00 +0100

Introduction

Il y a fort fort longtemps (en 2009), je testais TinyTinyRSS, un lecteur de flux RSS avec une interface Web. J’en parlais d’ailleurs dans un article pour signaler la venue de deux nouveaux tutoriels (dont TinyTinyRSS) dans mon Recueil d’astuces. Ce lecteur était agréable à l’usage, rapide et utilisait une base de données postgreSQL. Bref, tout ce que je voulais à l’époque. Le temps a passé ; je dépensais moins de temps sur les flux RSS. Puis j’ai arrêté - qu’importe les raisons. Ça fait bientôt 10 ans que j’ai laissé cela derrière moi.

Bouh la honte Olivier !

Certes.

Récemment, une mouche m’a piquée - ou une lubie - et je me suis renseigné sur les outils de lecture de flux RSS façon auto-hébergés et minimalistes. Je ne vais pas détailler la liste dans cet article puisque, vous l’aurez compris, on parle déjà dans le titre de Yarr !

Ainsi nous commencerons par présenter l’outil, pour ensuite décrire comment l’utiliser avec docker-compose pour finalement terminer par mon retour d’expérience après quelques jours d’utilisation (démarrage au 25 février 2026) et via un tour complet de l’outil - ça va être long mais il y a des images 😉 .

Photo trouvée sur le profil de Kevin Dooley sur Flickr sous licence CC BY 2.0.

Découverte de Yarr

Avant de découvrir : on cherche ! J’ai donc établi une petite liste de critères pour la recherche d’un lecteur de flux RSS :

simple, voire basique,
avec une interface Web,
auto-hébergeable,
Open Source,
rapide,
léger,
sans forcément une base de données de type MySQL ou PostgreSQL. SQLite acceptable,
écrit, éventuellement, en Go (j’envisage d’apprendre prochainement le Go).

J’ai donc cherché. J’ai trouvé quelques outils comme :

Miniflux (en Go),
FreshRSS (en PHP),
LeedRSS (en PHP),
feedpushr (en Go),
et Yarr (en Go).

Je l’ai déjà annoncé : nous n’irons pas plus loin avec cette liste.

Nul besoin de faire la promotion de Yarr, je pense qu’Internet fait déjà de belles suggestions d’utilisation de Yarr comme remplaçant de TinyTinyRSS. Petite histoire marrante : le nom est l’acronyme de Yet Another Rss Reader, littéralement « Encore un autre lecteur RSS » ou « L’énième lecteur de flux RSS ».

Une fois cette lecture de blog effectuée, j’ai voulu tester Yarr. Je me suis donc lancé dans l’écriture d’un fichier docker-compose.yml.

Mon fichier docker-compose.yaml pour Yarr

Il aura fallu moins de 20 minutes pour trouver l’image Docker de Yarr sur le dépôt officiel de Yarr sur Github. Cependant l’image étant sur Github Actions - que je connais peu - j’ai eu plus de mal à trouver le nom donné à l’image pour la récupérer depuis Docker. Je vous le donne de suite : ghcr.io/nkanaev/yarr:v2.5.

Une fois le nom de l’image obtenu, il reste à en connaître son usage. Heureusement j’ai trouvé un article sur la création d’un fichier docker-compose.yaml pour Yarr (Cf. https://awesome-docker-compose.com/apps/rss/yarr) dont je me suis, forcément, grandement inspiré. Et oui je le dis quand j’utilise quelque chose qui n’est pas de moi 😉 .

Ainsi j’ai pu construire le fichier docker-compose.yaml suivant :

services:
  yarr:
    image: ghcr.io/nkanaev/yarr:v2.5
    container_name: yarr
    restart: always
    ports:
      - 7070
    volumes:
      - ${DATA_DIR:-./data}:/data
    command:
      - --addr=0.0.0.0:7070
      - --db=/data/yarr.db
      - --auth=${Y_USER}:${PASSWORD}
    environment:
      - TZ=Europe/Paris
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.${SERVICE}.rule=Host(`$DOMAIN_URL`)"
      - "traefik.http.routers.${SERVICE}.entrypoints=websecure"

où :

DATA_DIR, Y_USER, PASSWORD, SERVICE et DOMAIN_URL sont à renseigner dans un fichier .env (avec une valeur),
DATA_DIR est le chemin vers le point de montage où seront stockées les données de Yarr,
Y_USER est le nom d’utilisateur que vous souhaitez utiliser comme login pour s’identifier sur votre Yarr,
PASSWORD… bah le mot de passe pour s’identifier au service Yarr,
SERVICE est un nom (en minuscule, sans espace et sans point) pour le routeur dans Træfik (si vous n’utilisez pas Træfik, supprimez la section “labels” de ce docker-compose.yaml),
DOMAIN_URL est l’adresse web pour accéder au service, mais seulement si vous utilisez Træfik en frontal. Sinon supprimez la section “labels” de ce fichier docker-compose.yaml.

Exemple de fichier .env :

SERVICE=monService
DOMAIN_URL=domain.tld
DATA_DIR=/srv/http/yarr_data
Y_USER=olivier
PASSWORD=mot2passe

Vous noterez qu’on autorise volontairement toutes les IP pour accéder au service (0.0.0.0). Ce dernier s’ouvrira sur le port 7070 dans le conteneur, mais Docker choisira un port aléatoire sur ce service (pour éviter de demander un port déjà utilisé). Nous en parlerons ci-après avec la commande docker compose port.

Une fois le fichier .env configuré, on lance et accède rapidement au service (pour tester par exemple) :

# Lance le service en arrière plan - récupération de la main sur l'invite de commande
docker compose up -d
# Affiche les conteneurs lancés
docker compose ps
# Affiche l'adresse pour accéder au service en local
docker compose port yarr 7070

On lance un navigateur, on tape l’adresse retournée par la dernière commande (chez moi 0.0.0.0:32768) et le lecteur de flux RSS apparaît. C’est parti pour une période d’essai de plusieurs jours (tests commencés à partir du 25 février 2026).

Mon expérience avec Yarr - on fait le tour !

L’authentification

Dans le fichier docker-compose.yml précédent nous avons ajouté l’option --auth afin d’activer l’authentification de Yarr. La première page sur laquelle nous tombons est donc celle pour s’identifier :

Simple, efficace.

L’interface générale

L’accueil est plutôt austère - chouette c’est ce que je voulais ! - et propose une disposition en 3 colonnes :

Chaque colonne sert un objectif précis, de gauche à droite :

la liste des flux RSS,
puis la liste des articles/éléments d’un flux en particulier,
puis l’article choisi parmi la liste précédente.

Donc plus on se dirige à droite, plus la lecture se précise.

Sur téléphone mobile il n’y aura plus qu’une seule colonne : celle tout à gauche. On choisira ainsi un flux, ce qui affichera la liste des articles et si on choisit un article, on verra son contenu. Toujours sur une colonne. Astucieux, logique et presque intuitif.

J’avoue que sur ce dernier point, sur téléphone mobile, j’ai été totalement perdu : je ne savais pas où j’étais et ce que je faisais. Ce n’est qu’en comparant l’usage entre un grand écran et un petit écran que j’ai saisi ce qu’il en était. Sur ce coup-là, je suis le couteau le moins aiguisé du tiroir…

La configuration de l’interface

Je continue ma découverte avec l’icône représentant 3 petits points en haut à droite de la première colonne (ou en haut à droite sur un petit écran ne présentant donc qu’une seule colonne). Les options de l’outil apparaissent :

C’est ici que va se jouer les seules options disponibles dans Yarr :

New Feed : Permet d’ajouter un nouveau flux. Il faut 2 infos : l’adresse URL du flux, et le dossier dans lequel le ranger,
Refresh Feeds : Actualisation des flux,
Theme : Pour changer l’apparence de Yarr. Nous en parlerons tout à l’heure,
Auto Refresh : Permet de choisir le laps de temps entre plusieurs rafraîchissements automatiques. Comprendre : on récupère les flux tous les X temps (de 0mn à 4h),
Show first : Permet de choisir si on préfère afficher les articles parus récemment en premier (New) ou ceux les plus anciens en premier (Old),
Subscriptions :
- Import : Donne la possibilité d’importer une liste de flux (au format OPML),
- Export : Permet d’exporter sa liste de flux (au format OPML) pour la partager par exemple,
- Shortcuts : Affiche un rappel des raccourcis claviers possibles pour naviguer et lire les flux. Et ils sont très utiles,
- Log out : Apparaîtra seulement si l’option --auth a été utilisée. C’est pour se déconnecter.

J’avais peur de tomber sur un lecteur avec des milliers de configurations. Finalement Yarr va à l’essentiel. Cela me plaît - encore une fois.

Choix d’un thème

Vous aurez remarqué que mes impressions écrans présentent les pages d’une couleur simili jaune (qui fait penser à Solarized Light d’Ethan Shoonover). C’est parce que j’ai choisi un thème. On peut choisir entre 3 thèmes :

blanc,
jaune,
noir.

Je suis content du thème jaune car ma vue pose problème avec les thèmes noirs (l’astigmathie a une forme d’opposition rebelle au “dark theme” et peut rendre les textes “flous”). Certes, la performance de lecture est plus importante en mode “light”, mais ça reste trop lumineux pour moi. Je n’aime pas le jaune en tant que tel, mais pour mon efficacité de lecture c’est le “moins pire” 🤣 . Évidemment les tendances s’inversent la nuit (mais pas pour moi), dans la pénombre et/ou dans un environnement peu lumineux. Mais nous ne sommes pas ici pour lancer le troll « Dark Mode vs. Light Mode », ou bien ? Combat !

Les trois icônes principales

Vous avez découvert l’usage en 3 colonnes, cette fois nous allons découvrir l’usage des 3 icônes tout en haut qui sont, en quelque sorte, le menu principal de Yarr :

un rond rempli de noir,
une étoile,
3 traits horizontaux parallèles de longueurs différentes.

La première (le rond noir) permet d’afficher la liste des flux sur lesquels nous avons encore des articles/éléments à lire.

La seconde (étoile noire) affiche une liste des flux sur lequels vous avez marqués des articles/éléments comme favoris.

Et la dernière (les 3 traits horizontaux) affiche la liste complète des flux, qu’importe qu’il vous reste ou non des articles/éléments à lire.

Exemple d’affichage en 3 colonnes sur le rond noir avec le choix d’un article et son affichage :

Simple, basique, sans fioritures. Utilisable avec des raccourcis clavier. Parfait !

Les derniers petits détails - et après j’arrête promis !

Dernière liste d’icônes dans l’interface :

deuxième colonne :
- icône de loupe : Fait une recherche dans la liste d’article de CE flux choisi,
- icône de validation : Marque tous les articles de ce flux comme lus,
- icône de 3 petits points l’un à côté de l’autre verticalement : c’est ici qu’on a les détails du flux. On peut le renommer, le changer de place, le supprimer, aller sur le site Web, etc.,
troisième colonne :
- icône d’étoile (vide/remplie) : Marque l’article en favori ou au contraire l’enlève des favoris,
- icône d’un rond (vide/rempli) : Marque l’article comme lu ou non-lu (suivant de quel état on commence),
- icône de traits verticaux entrecoupés comme de petits pistons : Permet de changer la police d’écriture (parmi sans-serif, serif et monospace) ainsi que la taille de police (petit, ou grand, plus on appuie plus ça réduit/aggrandit),
- icône d’un livre ouvert : Choisi de lire l’article dans Yarr ou bien seulement les informations du flux RSS,
- icône d’un carré avec une flèche qui en sort) : Va directement sur le site Web de l’article en question.

J’utilise souvent l’icône de validation de la seconde colonne pour marquer tous les articles comme lus une fois que j’ai parcouru la liste des titres et que rien ne m’intéressait.

Les raccourcis claviers sont là pour faciliter le traitement des articles (lu, non-lu, favori, lire à l’extérieur, etc.). Parfois j’utilise le raccourci “o” pour lire l’article sur le site Web.

Du reste, je n’utilise quasiment rien. Après tout je ne viens que pour lire des titres, trier et lire un article de temps en temps 🤷 . Je ne suis pas là pour bosser.

Conclusion

Au début un peu perdu par l’interface afin de comprendre à quoi sert chaque élément - surtout entre interface petit écran et grand écran - j’ai finalement apprécié Yarr à l’usage.

C’est un outil “menu” (maigre, léger), simple, basique, sans fioritures. Configurable un minimum. Utilisable avec des raccourcis clavier. Très efficace d’ailleurs avec un clavier quand on s’y fait. C’est même redoutable de rapidité quand on a le coup de main !

À vrai dire, je ne sais même pas de quoi j’aurais besoin en plus pour lire des flux. J’ajoute rapidement des flux, j’importe et exporte facilement pour partager avec d’autres, je vois de nouveaux articles, je clique sur ce qui m’intéresse, je lis, je note le reste des articles comme lus pour ce flux et voilà.

Ni plus. Ni moins. Parfait 😄 .

Liens utiles

Voici les liens de l’article par ordre d’apparition :

RustFS, alternative au service de stockage objet MinIO

Sun, 15 Feb 2026 17:27:26 +0100

Quand on étudie Kubernetes, on arrive tôt ou tard sur la question de la gestion des sauvegardes. Et avec elles le sujet du stockage de ces dernières. La référence en matière de sauvegarde - dont je parlerais sûrement dans un prochain article - est Velero. Cet outil supporte plusieurs fournisseurs de stockage pour ses opérations de sauvegarde comme Amazon Web Services, Google Cloud, Microsoft Azure ou VMware Sphere. Principalement des fournisseurs liés à une entreprise. Que faire dans la situation où nous souhaitons auto-héberger une solution de stockage chez soi ?

C’est ce dont je voudrais parler aujourd’hui : une solution spécifique que j’ai - presque - choisie. Surtout pourquoi cette solution ? Je décrirais son installation sous Docker Compose derrière un proxy nommé Traefik, dont je vous ai déjà parlé. Et j’ajouterais quelques mots sur les ports réseau à ouvrir, l’initialisation des premiers « buckets » (nous y reviendrons) et l’usage de noms de domaines.

Pourquoi cette solution ?

Si vous n’êtes pas fan de l’histoire de « pourquoi choisir cette solution », vous pouvez passer au chapitre suivant, je ne vous en voudrais pas 😉.

En étudiant la documentation de Velero on découvre parmi les fournisseurs de solutions de stockage le célèbre Amazon Web Services. Et avec lui le service Amazon S3. Ce service est une solution de stockage objet qui a développé un protocole ouvert du même nom : S3. Grâce à cela, de nombreux outils compatibles avec ce protocole ont vu le jour ; que ce soit des clients comme des serveurs. Top, c’est ce que je recherche !

Ayant beaucoup entendu parler de MinIO, je m’enquiers de l’installer fin novembre 2025. En Docker Compose, derrière Traefik comme je l’explique dans un précédent article sur le sujet. Mais quelques problèmes se posent successivement :

en août 2025 les dépôts de Bitnami, qui fournissaient jusqu’alors d’excellentes images, chartes Helm et outils en tous genres sont chamboulés par une décision drastique prise par Bitnami. L’impact est énorme sur la communauté,
faute de cette image pratique, je me tourne vers l’image officielle qui demande des ajustements pour avoir des « buckets » à l’initialisation,
finalement le 13 février 2026, l’entreprise qui gérait MinIO décide d’abandonner la maintenance de la version communautaire.

Coup dur. Je recherche des alternatives. Je tombe sur le message de loverustfs qui compare les solutions alternatives à RustFS, dont MinIO, Garage, Ceph, Seaweeedfs, etc..

Edit (24 fév. 2026) : Un fork de MinIO est apparu il y a quelques jours. Si le cœur vous en dit 🤷.

RustFS n’est probablement pas la solution la plus performante (Seaweedfs semble plus performant), mais il se défend bien. Et il semble proche de MinIO en terme d’interface et d’utilisation. Allons donc, ne le faisons pas attendre, installons-le !

RustFS sous Docker Compose

L’idée est d’installer/utiliser RustFS avec Docker Compose. Derrière Træfik. Avec des domaines.

Installation minimale

On commence par une installation de base. On a besoin de :

une image Docker. Ça tombe bien, il y a des images officielles de RustFS sur le Hub Docker,
ouvrir 2 ports :
- 9000,
- 9001,
un volume local pour stocker les données et pouvoir les réutiliser entre 2 redémarrages de conteneurs,
un identifiant et un mot de passe initial.

ATTENTION : le projet RustFS est encore jeune, il est en développement actif et les versions ne sont pas toutes utilisables telles quelles. Par exemple dans ma situation, la version 1.0.0-alpha.83 était inutilisable. Ceci dû à un bug sur l’architecture de ma machine comme le montre ce ticket Github.

Une première ébauche d’un fichier docker-compose.yaml pourrait s’écrire de la manière suivante :

services:
  rustfs:
    image: rustfs/rustfs:1.0.0-alpha.82
    restart: always
    ports:
      - 9000
      - 9001
    volumes:
      - ./storage_data:/data
      - /etc/localtime:/etc/localtime:ro
      - /etc/timezone:/etc/timezone:ro
    environment:
      - RUSTFS_VOLUMES=/data
      - RUSTFS_ADDRESS=0.0.0.0:9000
      - RUSTFS_CONSOLE_ADDRESS=0.0.0.0:9001
      - RUSTFS_CONSOLE_ENABLE=true
      - RUSTFS_ACCESS_KEY=olivier
      - RUSTFS_SECRET_KEY=mot2passe
      - RUSTFS_OBS_LOGGER_LEVEL=info
    healthcheck:
      test:
        [
          "CMD",
          "sh", "-c",
          "curl -f http://127.0.0.1:9000/health && curl -f http://127.0.0.1:9001/rustfs/console/health"
        ]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s

Veillez à changer les éléments suivants - au minimum :

./storage_data dans la section volumes. Renseigner par un dossier dans lequel vous voulez stocker les données,
RUSTFS_ACCESS_KEY dans la section environment. Changez olivier par un identifiant que vous souhaitez utiliser,
RUSTFS_SECRET_KEY dans la section environment. Changez la valeur mot2passe par quelque chose de bien plus long et bien plus compliqué que cela (une clé secrète en somme).

De cette façon, le service va se lancer avec des ports choisis par Docker Compose. Vous pouvez les connaître en tapant les commandes suivantes :

docker compose port rustfs 9000
docker compose port rustfs 9001

On constate sur l’interface (port initial 9001), après s’être authentifié avec l’identifiant et la clé secrète, qu’il n’y aucun bucket.

Initialisation des buckets

Qu’est un bucket ?

C’est un espace qui regroupe plusieurs objets qu’on aurait déposé à cet endroit. Cela permet de se repérer plus facilement dans un espace de stockage objet.

Afin de créer un bucket, soit on utilise l’interface (méthode manuelle), soit on créé un conteneur d’initialisation qui fera le job à notre place (automatique).

J’opte pour le conteneur d’initialisation pour créer 3 buckets. Dans notre fichier docker-compose.yaml on ajoute les lignes suivantes :

  init_buckets:
    image: minio/mc:RELEASE.2025-08-13T08-35-41Z
    depends_on:
      - rustfs
    restart: on-failure
    entrypoint: >
      /bin/sh -c "
      sleep 5;
      /usr/bin/mc alias set s3server http://rustfs:9000 \"olivier\" \"mot2passe\";
      /usr/bin/mc mb s3server/default;
      /usr/bin/mc mb s3server/bucket1;
      /usr/bin/mc mb s3server/bucket2;
      exit 0;
      "

Pensez à changer olivier et mot2passe par les mêmes identifiants/mot de passe que renseignés dans le service rustfs du docker-compose.yaml précédent.

L’astuce est donc d’utiliser le client mc de MinIO pour ajouter les buckets qu’on souhaiterait. Dans l’exemple présenté ci-avant, le conteneur d’initialisation permet de créer 3 buckets :

default,
bucket1,
bucket2.

Libre à vous d’adapter ce conteneur pour répondre à vos besoins en matière de création initiale de bucket.

Il ne reste alors plus que la mise à disposition sur Internet via l’usage de sous-domaines et de Træfik.

Configurer les labels pour Træfik

Træfik est un proxy souvent utilisé avec Docker Compose pour se charger des routes. L’idée de Træfik est d’utiliser le champ labels pour récupérer des instructions utiles à la création des routes en lien avec les domaines.

Pour RustFS sous Docker Compose, et avec Træfik en frontal, je suggère les labels suivants :

    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.api-rustfs.rule=Host(`api.mondomaine.tld`)"
      - "traefik.http.routers.api-rustfs.entrypoints=websecure"
      - "traefik.http.routers.api-rustfs.service=api-rustfs"
      - "traefik.http.services.api-rustfs.loadbalancer.server.port=9000"
      - "traefik.http.routers.rustfs.rule=Host(`mondomaine.tld`)"
      - "traefik.http.routers.rustfs.entrypoints=websecure"
      - "traefik.http.routers.rustfs.service=rustfs"
      - "traefik.http.services.rustfs.loadbalancer.server.port=9001"

Prenez soin de changer les éléments suivants :

websecure par le nom de votre routeur permettant d’avoir du HTTPS,
api.mondomaine.tld par le domaine de votre choix pour accéder à l’API de RustFS,
mondomaine.tld par le domaine utilisé pour accéder à l’interface Web de RustFS.

Évidemment tout un tas d’autres options sont possibles, il suffit de lire la documentation de Træfik pour cela.

Résultat final complet

Ce qui nous donne :

services:
  rustfs:
    image: rustfs/rustfs:1.0.0-alpha.82
    restart: always
    ports:
      - 9000
      - 9001
    volumes:
      - ./storage_data:/data
      - /etc/localtime:/etc/localtime:ro
      - /etc/timezone:/etc/timezone:ro
    environment:
      - RUSTFS_VOLUMES=/data
      - RUSTFS_ADDRESS=0.0.0.0:9000
      - RUSTFS_CONSOLE_ADDRESS=0.0.0.0:9001
      - RUSTFS_CONSOLE_ENABLE=true
      - RUSTFS_ACCESS_KEY=olivier
      - RUSTFS_SECRET_KEY=mot2passe
      - RUSTFS_OBS_LOGGER_LEVEL=info
    healthcheck:
      test:
        [
          "CMD",
          "sh", "-c",
          "curl -f http://127.0.0.1:9000/health && curl -f http://127.0.0.1:9001/rustfs/console/health"
        ]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.api-rustfs.rule=Host(`api.mondomaine.tld`)"
      - "traefik.http.routers.api-rustfs.entrypoints=websecure"
      - "traefik.http.routers.api-rustfs.service=api-rustfs"
      - "traefik.http.services.api-rustfs.loadbalancer.server.port=9000"
      - "traefik.http.routers.rustfs.rule=Host(`mondomaine.tld`)"
      - "traefik.http.routers.rustfs.entrypoints=websecure"
      - "traefik.http.routers.rustfs.service=rustfs"
      - "traefik.http.services.rustfs.loadbalancer.server.port=9001"

  init_buckets:
    image: minio/mc:RELEASE.2025-08-13T08-35-41Z
    depends_on:
      - rustfs
    restart: on-failure
    entrypoint: >
      /bin/sh -c "
      sleep 5;
      /usr/bin/mc alias set s3server http://rustfs:9000 \"olivier\" \"mot2passe\";
      /usr/bin/mc mb s3server/default;
      /usr/bin/mc mb s3server/bucket1;
      /usr/bin/mc mb s3server/bucket2;
      exit 0;
      "

Avec ce contenu vous devriez pouvoir démarrer une instance RustFS sans problème 😉.

Quelle aventure !

Au bout du compte, avoir cherché à lancer un service de stockage objet a été une sacrée odyssée pour moi. Beaucoup d’aléas liés au changement de politique de Bitnami (pour les images MinIO), à l’arrêt de maintenance du code du serveur MinIO par AIStor et aux effets de bord de RustFS en plein développement.

Mes besoins spécifiques en terme d’infrastructure (Docker Compose et Træfik) m’ont amené à devoir retravailler plusieurs fois le fichier docker-compose.yaml. Et j’ai essuyé quelques plâtres avant d’avoir une instance fonctionnelle.

Je suis ainsi content de partager ce fichier docker-compose.yaml. Bien qu’il y a matière à faire évoluer ce fichier. On peut imaginer améliorer ce fichier en utilisant des variables pour le dossier où seront stockées les données, le nom du service, le domaine et bien évidemment l’identifiant et le mot de passe du service RustFS. Et déposer les valeurs dans un fichier .env.

On pourrait également trouver un autre client que mc pour initialiser les buckets au départ. Voire trouver un autre outil permettant de créer les buckets plus facilement. Imaginons une nouvelle image Docker ayant un script d’initialisation avec des variables d’environnement le permettant.

Je laisse votre imagination faire le reste 😊.

Sources utilisées pour la mise en place de RustFS

Liens utiles

Mon Labo K8S pour essayer des applications

Sun, 09 Nov 2025 06:25:39 +0100

Introduction

Quand on commence à étudier Kubernetes (k8s), on a besoin d’un environnement où tester ce qu’on apprend. Les environnements possibles sont nombreux : Minikube, Kubernetes (k8s) officiel, k0s, k3s, etc. Cela ne s’arrête plus !

Entre les difficultés à installer l’environnement et celles à appliquer ce qu’on apprend, on ne s’en sort plus. Cela devient vite compliqué au point de vouloir tout arrêter ; c’était mon cas.

De plus je souhaitais avoir un environnement reproductible et spécifique à chacun de mes projets, de quoi travailler unitairement sur un service particulier.

Avant de décrocher complètement, j’ai fait une pause, pris du recul et étudié la question. Je vous relate ici le résultat de cette petite aventure dans le monde de Kubernetes et des outils envisagés pour créer un labo de développement d’applications tournant sous Kubernetes.

Dans un premier temps nous poserons le problème, après quoi nous étudierons quelques solutions pour finalement détailler le produit de cette pérégrination.

Photo trouvée sur publicdomainpictures.net sous Licence CC0 Public Domain.

Le contexte

Venant du monde de Docker et Docker Compose, il me semblait aller de soi d’étudier ensuite le monde de Kubernetes - qui utilise la conteneurisation. Seulement je ne pensais pas que l’installation même de Kubernetes était un cap à franchir.

Je souhaite en profiter pour migrer petit à petit mes services sur Kubernetes. Chacun d’eux devient donc un projet en soi. Et comme souvent, j’aime avoir un environnement spécifique de développement pour créer les fichiers nécessaires à Kubernetes et permettre a posteriori d’améliorer le service. Je cherche donc à avoir un simili de docker-compose.yml pour chaque service et permettant de développer l’application dans un environnement Kubernetes propre.

Au début on découvre Minikube. Du moins c’est un outil très souvent conseillé. Pratique sur une machine bureautique pour triturer rapidement quelques fichiers Kubernetes (des fichiers au format YAML). Il est bien documenté et possède plusieurs plugins pour faciliter l’étude du Kubernetes en place ; par exemple un plugin Dashboard permet de visualiser les métriques du serveur et les objets instanciés. J’ai la sensation que cet outil reste « trop spécifique ». Il ne représente pas totalement un « vrai » Kubernetes. Ça peut parfois causer des torts au moment de déployer sur un autre serveur Kubernetes. L’outil est également lourd et relativement lent pour instancier un nouvel environnement.

Pourquoi ne pas tester un Kubernetes connu pour sa légèreté ? Par exemple k3s. D’autant qu’il s’installe rapidement à l’aide de k3sup (qui fonctionne à merveille). Sur le papier c’est une bonne idée : léger, facile à installer. En revanche il ne permet pas d’instancier un nouvel environnement ; il faut donc jouer avec les namespaces Kubernetes. Rebelote : ce n’est pas un outil adapté à l’apprentissage de Kubernetes. Au départ on fait forcément des erreurs dues à l’incompréhension ou l’ignorance ; ce qui peut rendre l’environnement rapidement inutilisable.

Après ces deux premières tentatives, je sais désormais ce que je veux :

possibilité de créer un environnement « propre »,
encore mieux s’il peut créer plusieurs environnements,
si possible léger (petit) - ce qui exclue les machines virtuelles,
facile à installer,
et rapide.

Nous avons nos critères, il ne reste plus qu’à chercher le(s) outil(s) permettant de créer rapidement un environnement de développement autour de Kubernetes.

Solutions étudiées

À la recherche des mots clés « lightweight » (similaire au mot léger) et « kubernetes » dans un moteur de recherche, on trouve plusieurs outils comme :

MicroK8S,
k0s,
k3s,
et kind.

k3s a déjà été cité dans cet article. Il ne me convient pas pour un environnement de développement/d’étude concernant k8s. Il est sûrement très redoutable à l’installation rapide sur une quantité importante de machines à l’aide de k3sup. Mais ce n’est pas le sujet de cet article.

La liste mentionne également MicroK8S, le petit rejeton de la famille Ubuntu, qui semble être une alternative à Minikube avec des plugins (Dashboard, DNS, registry, istio, etc.). Je pense qu’il est effectivement intéressant pour un usage complet entre des développeurs, une intégration continue (CI) / déploiement continue (CD) et plusieurs environnements allant jusqu’à des environnements dit « de production ». Je sens cependant que la similitude avec Minikube ne puisse me convenir. Je le laisse de côté pour l’instant.

k0s, quant à lui, semble être la solution idéale pour une installation sur une machine physique. À usage privé. Bien qu’il semble léger, facile à installer et utiliser, je comprends rapidement qu’il est fait pour avoir une installation unique sur une machine physique précise. Il ne répond pas à mon critère de création multiple d’environnements.

Et un de plus en moins !

Il reste le dernier de cette liste : kind. A priori il semble léger, prévu pour un usage spécifique au développement ou de l’intégration continue (CI) et utilise Docker pour créer un cluster complet à chaque fois. Waouh, rien que ça ! Sur le papier, cet outil est très prometteur car il répond aux critères précédemment listés :

créer des environnements « propres » grâce à l’usage de Docker,
ainsi il permet l’usage de plusieurs environnements,
il est léger, petit,
facile à installer puisque kind est disponible dans les dépôts AUR d’ArchLinux,
et pour la rapidité nous verrons.

À l’usage, kind (qui veut dire Kubernetes IN Docker) semble facile à prendre en main :

# Créer un cluster nommé olivier
kind create cluster --name olivier
# Supprime le cluster nommé olivier
kind delete cluster --name olivier

Une fois le cluster créé, il s’agit simplement de jouer avec la commande kubectl habituelle pour contacter le cluster. Et la commande étant à taper, je peux tout à fait scripter la création du cluster et sa destruction.

Il serait plus pratique de l’utiliser avec d’autres outils pour en faciliter l’usage. J’ai donc cherché au fur et à mesure de nouveaux outils dont voici la liste :

kubectx va permettre de commuter d’un contexte Kubernetes à un autre. Autrement dit passer d’un cluster à un autre facilement,
kubeconform pour valider nos fichiers YAML,
kube-linter pour pousser à l’usage des bonnes pratiques en matière de rédaction de fichiers YAML,
skaffold pour surveiller la moindre modification (équivalent d’un « watcher ») sur nos fichiers YAML et les déployer directement sur le cluster,
et make (avec un fichier Makefile) pour mélanger tout ça.

Mon idée est d’utiliser un fichier Makefile pour fournir plusieurs commandes permettant de créer le cluster, le détruire, vérifier les fichiers YAML ou encore lancer un déploiement automatique s’il y a des changements dans les fichiers en cours de développement.

J’imagine quelque chose comme :

make cluster pour créer un cluster,
make dev pour lancer skaffold et écouter le moindre changement sur le dossier de développement de l’application,
make kubeconform pour vérifier les fichiers une fois écrits,
make lint pour vérifier les bonnes pratiques avec kube-linter,
et make clean pour détruire le cluster.

Tentons l’aventure et voyons le résultat !

Ce que j’ai finalement produit

En bref

Le fichier Makefile :

CLUSTER_NAME := k8s-dev-example
KUBECTL := kubectl
SKAFFOLD := skaffold
KIND := kind
KUBECONFORM := kubeconform
KUSTOMIZE := kustomize

NAMESPACES := dev

.PHONY: help
help:
	@echo "Commandes disponibles :"
	@echo "  make cluster       - Crée un cluster Kind"
	@echo "  make namespaces    - Crée les namespaces Kubernetes (dev/staging/prod)"
	@echo "  make dev           - Lance Skaffold pour l'env dev"
	@echo "  make kubeconform   - Lance kubeconform sur l'env de DEV"
	@echo "  make clean         - Supprime le cluster Kind"

cluster:
	$(KIND) create cluster --name $(CLUSTER_NAME) ||:

namespaces:
	@for ns in $(NAMESPACES); do \
		$(KUBECTL) get ns $$ns >/dev/null 2>&1 || $(KUBECTL) create ns $$ns; \
	done

dev: cluster namespaces
	$(SKAFFOLD) dev

kubeconform: kubeconform-dev

kubeconform-dev:
	$(KUSTOMIZE) build overlays/dev | $(KUBECONFORM) -strict -summary -ignore-missing-schemas

clean:
	$(KIND) delete cluster --name $(CLUSTER_NAME)

Ce fichier Makefile est disponible sur le dépôt Gitlab d’ODTRE.

Il va utiliser deux dossiers principaux :

base qui contient les fichiers YAML de l’application qu’on souhaite implémenter sur Kubernetes,
overlays/dev qui contient un fichier kustomization.yaml pour surcharger le dossier base.

Et 2 fichiers de configuration :

kube-linter.yaml avec votre configuration de l’outil,
skaffold.yaml avec le contenu suivant :

apiVersion: skaffold/v4beta13
kind: Config
metadata:
  name: k8s-demo-app
manifests:
  kustomize:
    paths:
      - ./overlays/dev
# Exemple de redirection de port sur le service nommé dev-nginx (car l'overlay ajoute dev- devant tout)
portForward:
  - resourceType: service
    resourceName: dev-nginx
    namespace: dev
    port: 80
    localPort: 4000

Cela permet de surveiller le dossier ./overlays/dev avec kustomize pour interpréter les fichiers. Et il va ouvrir le port 4000 sur la machine locale pour rediriger sur le port 80 du service Nginx d’exemple (fourni dans le dépôt Gitlab mentionné précédemment).

À l’usage

Tout n’est pas parfait. Cependant ce fichier Makefile permet de lancer quelques commandes make utiles :

# Lance l'environnement de DEV. Si le cluster n'existe pas : il le créé. Sinon il ignore.
make dev
# Vérifie la conformité des fichiers YAML en utilisant le dossier overlays/dev
make kubeconform
# Détruit le cluster de DEV
make clean
# Pousse à l'usage des bonnes pratiques sur les fichiers contenus dans le dossier ./base
kube-linter lint --config kube-linter.yaml ./base

Pour toute aide supplémentaire, faites : make help.

Ainsi il devient facile de travailler sur un nouvel environnement :

je copie les fichiers disponible sur un dépôt template sur Gitlab,
j’ouvre le fichier Makefile en écriture,
j’édite la ligne suivante pour adapter le nom du cluster de travail :

CLUSTER_NAME := k8s-dev-example

Et le tour est joué !

Je suis assez satisfait de cet environnement. Il répond aux critères édictés plusieurs fois dans cet article. Et je me sens plus à l’aise de pouvoir modifier comme bon me semble cet environnement de développement/travail.

Les outils utilisés me font penser à une boîte à outil de base pour le travail sur Kubernetes. Même sans utiliser le fichier Makefile je suis amené à pratiquer les outils comme kubeconform, kubectl, kube-linter et kustomize.

C’est donc une très bonne chose d’avoir regroupé ces outils autour de Makefile et de les utiliser régulièrement sur mes projets Kubernetes.

Conclusion

Nous avons posé le contexte d’une recherche d’outil simple, rapide et léger pour créer de nombreux environnements Kubernetes afin de travailler sur ces environnements dans le cadre d’un développement de fichiers YAML.

Après quelques essais sur Minikube et k3s, mes recherches se sont portées sur l’utilisation de kind. Puis j’ai utilisé make pour le manipuler et regrouper aussi les différents outils utiles.

La boîte à outil se compose de :

kind,
skaffold,
kubectl,
kubeconform,
kube-linter,
et make.

J’aborde désormais de manière plus sereine le développement d’une application qui sera hébergée par un Kubernetes. J’ai un template à ma disposition pour ces fichiers. Template que je peux faire évoluer au gré des obstacles rencontrés. Il utilise tous les outils que j’ai appréciés. J’en suis pleinement satisfait 😎 .

Et vous, quel environnement Kubernetes utilisez-vous pour vos développements de fichiers YAML ?

Liens utiles

Ce que j'aurais voulu savoir sur Gitlab CI

Sun, 18 May 2025 13:55:39 +0200

Introduction

Il y a quelques mois je parlais de ma formation Bootcamp pour devenir Ingénieur DevOps. J’y ai utilisé - à nouveau - Gitlab CI (Continuous Integration). Vous savez, cet outil permettant d’exécuter des actions après avoir envoyé votre code/dépôt sur la plateforme Gitlab ?

C’est très utile, par exemple pour lancer les tests sur votre code, vérifier que le code s’exécute dans un environnement précis ou tout simplement vérifier que le code compile. Et si votre dépôt n’est pas du code, par exemple un site web, vous pouvez tester les liens morts ; voire publier votre site ! Les possibilités sont - finalement - nombreuses !

En revanche, un tel outil est parfois déstabilisant. Et des cheveux, j’en ai arrachés ! J’aurais apprécié tomber sur un article explicatif. Avec des astuces. Peut-être que le présent article m’aurait convenu, qui sait !

J’aurai par exemple aimé savoir comment publier facilement un site web, tester localement le fichier .gitlab-ci.yml avant de l’envoyer sur Gitlab, connaître plus d’astuces pour les mots clés Gitlab, savoir utiliser Docker dans Gitlab CI et ce que sont les composants réutilisables.

Ce sont ainsi tous les sujets que nous allons aborder aujourd’hui.

Photo trouvée sur le profil de didier.camus sur Flickr sous Licence Œuvre du domaine public.

Publier rapidement un site statique

Gitlab met à disposition des utilisateurs un espace permettant d’héberger des sites webs statiques. Incroyable n’est-ce pas ? Cet espace est Gitlab Pages.

Comment cela fonctionne ? Il suffit de créer un dépôt Gitlab, d’ajouter un fichier .gitlab-ci.yml contenant la section suivante :

image: busybox

pages:
  stage: deploy
  script:
    - echo "The site will be deployed to $CI_PAGES_URL"
  artifacts:
    paths:
      - public
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Code récupéré du projet https://gitlab.com/pages/plain-html.

Cela signifie qu’au terme de la CI/CD (dans l’étape nommée deploy), le contenu du dossier public sera publié sur Gitlab Pages. À quelle adresse ? Imaginons que vous partez d’un dépôt dont l’adresse est : https://gitlab.com/blankoworld/monprojet/, l’adresse URL d’accès à votre site publié sera : https://blankoworld.gitlab.io/monprojet/. Pratique non ?

Astuce : Si votre dépôt est privé, vous pouvez quand même rendre votre site public. Il suffit d’aller dans Settings > General, Section « Visibility, project features, permissions » et dans le sous-titre « Pages », activez la fonctionnalité. Et dans le menu déroulant à côté, choisissez « Everyone ». N’oubliez pas de sauvegarder cette configuration. Le code sera privé, le site web statique public !

Pour plus d’exemple, veuillez vous rendre sur la page Gitlab présentant la liste de projets utilisant Gitlab Pages.

Tester avant d’envoyer sur le dépôt ?

Le truc vraiment embêtant avec les fichiers .gitlab-ci.yml, c’est qu’on ne peut pas les tester sur notre machine (localement). Pour avancer il faut :

modifier le fichier .gitlab-ci.yml,
le valider (faire un commit),
l’envoyer sur Gitlab,
patienter que la pipeline se lance (et parfois se termine),
bénéficier du résultat ou, dans la plupart des cas, recommencer à l’étape 1…

À une époque on pouvait utiliser une commande gitlab-runner exec en local. Mais celle-ci a été supprimée : https://gitlab.com/gitlab-org/gitlab-runner/-/commit/f8508c924f80b104ec7353353e6ad0edb5daae66 .

Suivant ce que nous faisons dans la CI/CD de Gitlab, il est possible d’utiliser un outil bien pratique nommé gitlab-ci-local : gitlab-ci-local.

Vous trouverez quelques détails de gitlab-ci-local sur mon recueil d’astuces.

Généralités

Voici quelques pistes intéressantes sur le sujet Gitlab :

Une documentation de départ est : https://docs.gitlab.com/topics/build_your_application/. Elle permet d’en savoir plus sur la syntaxe de gitlab-ci.yaml, les variables pré-définies ou encore le fonctionnement d’un pipeline dans Gitlab CI,
Toujours utiles : les actions que je nomme comme « globales ». Par exemple les mots clés image, variables ou before_script peuvent être utilisés en début du fichier pour définir des actions ou des valeurs qui seront utilisées dans toutes les étapes du pipeline. Ce qui peut être un avantage, ou un inconvénient. Exemple : image: ubuntu:latest va définir que toutes les étapes se lanceront dans un docker partant de l’image Ubuntu,
Entrées/sorties : un artefact = une sortie. C’est à dire des fichiers utilisables/disponibles pour les étapes suivantes (donc en entrée pour les autres étapes) en utilisant le mot clé dependencies (Cf. https://docs.gitlab.com/ci/jobs/job_artifacts/#fetching-artifacts). Sauf si dependencies = [] est utilisé.
Utiliser des variables globales en début du fichier (par exemple pour les numéros de versions) fait gagner du temps sur le long terme. Exemple :

variables:
  DOCKER_VERSION: "27.3.1"
  UBUNTU_VERSION: "24.04"

Concernant le mot clé script :
- si on veut écrire plusieurs lignes, utiliser la syntaxe suivante :
```
script:
  - echo "première étape des scripts"
  - |
    echo "première ligne"
    echo "seconde ligne"
    echo "etc."
```
- limiter à 10 lignes maximum,
- si on utilise la syntaxe pour écrire plusieurs lignes, le debug est plus difficile
Pour organiser les étapes, on peut donner à chacune d’elle une étape pré-requise en utilisant le mot clé « needs », cela permet de chaîner les étapes dans un certain ordre. Exemple : si on veut que l’étape « deploy » se fasse après « compile », alors à la fin de l’étape « deploy » on met needs: [compile].

Le Cas Docker

Création d’une image Docker… dans un conteneur Docker

Dans la situation où vous voudriez fabriquer des images Docker, vous allez être confrontés à plusieurs problématiques :

il faut utiliser des commandes docker pour créer des images,
mais la plupart des Gitlab Runner exécutent les étapes de Gitlab CI dans un Docker,
donc on se retrouve à vouloir exécuter des commandes docker dans un environnement Docker.

Vous voyez le problème ?

Pour contourner cette situation il suffit d’utiliser Docker-in-Docker.

En somme le début du fichier .gitlab-ci.yml ressemblera à :

variables:
  DOCKER_VERSION: "27.4.1"

image: docker:$DOCKER_VERSION

services:
  - docker:$DOCKER_VERSION-dind

S’identifier

Pour utiliser les dépôts de conteneurs de Gitlab, rien de plus simple il suffit d’écrire le code suivant dans le fichier .gitlab-ci.yml :

before_script:
  - docker info
  - echo "$CI_REGISTRY_PASSWORD" | docker login $CI_REGISTRY -u $CI_REGISTRY_USER --password-stdin

Nul besoin de renseigner les variables. Elles sont renseignées par Gitlab CI.

Construire l’image

Pour construire l’image cela va ressembler à :

variables:
  CONTAINER_TEST_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG

build-image:
  stage: build
  script:
    - docker pull "$CONTAINER_TEST_IMAGE" || true
    - docker build --build-arg BUILDKIT_INLINE_CACHE=1 -t $CONTAINER_TEST_IMAGE .
    - docker push $CONTAINER_TEST_IMAGE

On part du principe que le fichier Dockerfile est situé à la racine de votre projet Gitlab.

CONTAINER_TEST_IMAGE est une variable globale construite à partir des variables pré-définies de Gitlab CI.

Pousser l’image sur le dépôt

Dans cette situation nous sommes contents d’avoir déjà ajouté l’authentification aux dépôts de conteneurs Gitlab.

Cette fois on fait une étape pour récupérer l’image précédente et lui donner un nouveau nom :

push-image:
  stage: push
  script:
    - export IMAGE_TAG="$(date +'%Y%m%d')-${CI_COMMIT_SHORT_SHA}"
    - docker pull $CONTAINER_TEST_IMAGE
    - docker tag $CONTAINER_TEST_IMAGE $CI_REGISTRY_IMAGE:$IMAGE_TAG
    - docker push $CI_REGISTRY_IMAGE:$IMAGE_TAG
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

L’idée est :

de créer un nom de tag pour l’image (variable IMAGE_TAG),
récupérer l’image précédente - puisque les étapes d’un fichier .gitlab-ci.yml s’exécutent dans des conteneurs isolés les uns des autres,
apposer un nouveau tag sur l’image récupérée,
publier le résultat en poussant l’image ainsi étiquetée.

Ceci ne s’exécute que si la branche est nommée main. Donc chaque commit sur cette branche générera une image Docker et un tag.

Ordre d’exécution des étapes

Afin que les deux étapes précédentes s’exécutent dans un certain ordre, ne pas oublier les lignes suivantes dans le fichier .gitlab-ci.yml :

stages:
  - build
  - push

Comme si ça ne suffisait pas…

En outre, voici d’autres éléments à rajouter dans son fichier .gitlab-ci.yml :

variables:
  # Use TLS https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#tls-enabled
  DOCKER_HOST: tcp://docker:2376
  DOCKER_TLS_CERTDIR: "/certs"

Ces lignes permettent de renseigner un autre accès à l’API Docker pour lancer les commandes docker.

Les composants réutilisables

Gitlab CI offre la possibilité d’utiliser des composants réutilisables pour agrémenter les étapes de son fichier .gitlab-ci.yml. Ceci évite de réinventer la roue (en codant soi-même).

Plusieurs composants sont disponibles sur la page Gitlab components.

Exemple d’utilisation d’un composant :

include:
  - component: gitlab.com/components/container-scanning/container-scanning@5.1.0

C’est très utile dans certaines situations comme pour tester des fichiers Terraform (avec le composant OpenTofu), le composant Go, le composant Rust ou même utiliser les fonctionnalités Autodevops de Gitlab.

Conclusion

Au premier abord Gitlab CI paraît complexe et maigre en fonctionnalités. Cependant la lecture de la documentation (très fournie !) donne rapidement un aperçu bien plus avantageux de cet outil. On y découvre les composants réutilisables, les mots clés image, variables, before_script, les artefacts (sorties), les variables globales, le déploiement de sites statiques et j’en passe !

Certaines difficultés telles que Docker viennent s’immiscer dans nos essais. Mais une fois les obstacles franchis c’est un outil très satisfaisant. Je l’apprécie.

Je serais ravi de tomber plus souvent sur des articles décrivant ses fonctionnalités. J’espère participer à une diffusion plus grande de la connaissance Gitlab CI et, qui sait, peut-être partagerais-je prochainement d’autres astuces ?

Bye Bye Gandi Mail, Bonjour Mailo

Fri, 25 Aug 2023 21:26:05 +0200

Ça fait quelques mois qu’on nous rabache que Gandi Mail va devenir payant. NextInpact affirme aussi que Gandi passe les mails en payant. Quel problème cela pose ? Où en suis-je ? Y a-t-il d’autres alternatives à cela ?

Photo trouvée sur le profil d’irio sur Flickr sous licence BY 2.0.

Problèmes posés

Gandi annonce la mise du service Gandi Mail payant à partir de fin septembre/début octobre. Le prix des boîtes mail passe de gratuit à 4.79€ par mois. C’est à dire 57.48€/an. Et cela pour chaque boîte courriel !

Le souci ? Quand on utilise plusieurs boîtes courriel, ça douille tout de suite plus ! Exemple : j’ai 4 boîtes courriel utilisées chez Gandi, ce qui me ferait passer de 0€/an à… 229.92€ !!

Avouez que la facture est plutôt corsée quand on a été habitué plus de 10 ans à ne rien débourser pour cela. Et encore, j’abuse un peu car il faut savoir que les domaines sous Gandi sont généralement plus chers que d’autres fournisseurs de domaines. Les adresses courriel gratuites et de bonne qualité amenait des clients chez Gandi.

J’utilise Gandi pour l’ensemble de mes domaines car j’apprécie le service, les possibilités (comme le « Live DNS ») et - antérieurement - la possibilité de créer des adresses courriels avec 1 000 alias de redirection courriels (vous choisissez des adresses courriels qui vont rediriger vers 1 à plusieurs adresses courriels, même si les adresses cibles ne vous appartiennent pas).

Et dans tout cela, où me situe-je ?

Où j’en suis

Si j’écris cet article, c’est parce que j’aimerais partager à la fois le fait qu’il y a du changement chez Gandi Mail, mais aussi mes pérégrinations en matière de recherche d’un fournisseur de mail prenant en compte les noms de domaine sans forcément les gérer.

On le dit souvent, en informatique il est intéressant de pouvoir changer un service sans avoir d’impact sur un autre : choisir un fournisseur d’adresses courriels sans changer de fournisseur de domaine par exemple. Et c’est ce que je visais.

Quelles alternatives ?

Si SebSauvage propose Infomaniak en migrant ses domaines là bas, d’autres proposent différents services comme FastMail, Ikoula.

La plupart du temps, il faut migrer ses domaines avec : ce que je ne recherche pas du tout. C’est le cas pour OVH qui propose des offres quand on gère les domaines chez eux.

Je suis alors tombé sur un article intéressant sur le passage à Mailo.com, service que je ne connaissais pas. Mailo.com est Français, garantit aux utilisateurs d’être respectueux de leurs données, ne pas les vendre à des tiers et visant une utilisation éthique et responsable du Web. Le service Mailo est gratuit, mais une option à 2€/mois existe, ce qui permet de gérer 5 adresses mails. Ça tombe bien, j’ai 4 adresses à créer !

Quelques détails sur ma migration

Ce qui est intéressant dans ce dernier article sur Mailo.com, c’est que l’auteur suggère l’utilisation d’imapsync comme outil pour synchroniser son ancienne boîte aux lettres avec la nouvelle. Et il donne les détails sur comment configurer tout cela.

À noter une petite subtilité que je n’avais pas prise en compte : si sous Gandi Mail vous avez droit à 1 000 redirections courriel, sous Mailo c’est limité à 100 redirection par boîte courriel. Quand on a 390+ redirections… il faut faire du tri ! Fort heuresement, Mailo propose un fonctionnement intéressant : ajouter ++ dans l’adresse courriel. Par exemple si vous faites une boîte prenom.nom@domaine.tld, vous pouvez créer dynamiquement prenom.nom++quelquechose@domaine.tld. Autant que vous voulez. Sans utiliser d’ordinateur. À la volée je vous disais !

Autre chose à viser aussi : le catch-all. C’est le fait que n’importe quelle adresse mal écrite, ou différente de votre boîte courriel entraînera quand même la redirection vers votre boîte courriel. Exemple : au lieu d’écrire prenom.nom@domaine.tld, si je me trompe en écrivant prenmo.nmo@domaine.tld, je recevrais quand même l’adresse courriel.

Conclusion

Je joue les montagnes russes avec les prix : je suis passé de 4 boîtes Gandi Mail gratuites à potentiellement 230€/an pour finalement payer 24€/an. Le coût numérique augmente légèrement. Je pense être en droit de me demander jusqu’où cela ira pour bénéficier d’un pseudo contrôle de mes données et le choix de mes fournisseurs sur Internet ?

Quoiqu’il en soit le passage de Gandi Mail à Mailo, même si rocambolesque et pas de tout repos, a été plus serein avec l’aide de l’article de Jonathan Tremesaygues sur le passage de Gandi Mail à Mailo à l’aide d’imapsync.

Je trie encore mes 390+ redirections Gandi Mail vers Mailo au fur et à mesure, mais c’était nécessaire et je suis bien content de l’avoir fait, malgré le côté payant de la chose !

Liens utiles

La Gachette qui publie mon blog

Fri, 20 Jan 2023 17:46:32 +0200

Introduction

Peut-être serez-vous surpris d’apprendre que la publication d’un article sur ce blog revient simplement à écrire du texte dans un fichier et envoyer un commit sur un dépôt Git. Ni plus, ni moins.

C’est là que commence toute une chaîne de publication afin de mettre à disposition le fameux article sur le Web ! Pour cela j’ai utilisé très peu d’outils et un peu d’imagination.

Le but du présent article est de vous présenter l’outil de la chaîne que j’ai dû développer pour mener à bien ce projet : Gachette. Puis de vous décrire comment le mettre en place.

Mais avant tout commençons à planter le décor !

Photo trouvée sur le profil de Nikk sur Flickr sous licence CC BY 2.0.

Plantons le décor avec l’Histoire logicielle de ce blog

(je comprendrais que ce chapitre ne soit pas très enthousiasmant pour vous, si c’est le cas, passez au suivant 😉)

En 2016 je vous parlais d’Hugo, le moteur de blog statique que j’utilise pour « confectionner » ce blog. Outil très intéressant qui utilise de simples fichiers pour générer un site web entier, statique ; c’est à dire en pur HTML et ne demandant aucune autre ressource finale qu’un serveur Web tel qu’Apache2, nginx, lighttpd, Caddy Server et j’en passe… Dans ma situation, le serveur Web en question est Nginx depuis 2013 environ - mais qu’importe.

Afin de garder en mémoire les travaux effectués, je vous partageais en 2017 l’outil Gitea, service Git sans prise de tête issu de Gogs.

À cette époque (entre 2016 et 2019/2020), pour publier mon blog il me faut :

(manuel) écrire l’article dans un fichier texte
(manuel) (facultatif) l’enregistrer sous Git avec un commit
(manuel) (facultatif) envoyer l’article sur Gitea
(manuel) compiler le site à l’aide de la commande hugo
(manuel) synchroniser les fichiers résultants sur mon serveur doté de Nginx, par exemple avec une commande rsync simple

À force de traîner à FOSDEM en 2016 et en 2017, j’ai non seulement appris que l’informatique sert à automatiser des tâches mais qu’il est aussi possible de le faire de manière « simple ».

Je me renseigne et j’apprends que sous Gitlab, Github et Gitea (plateformes que j’utilise à l’époque), il existe un système de webhooks. Qu’est-ce à dire ? Grossomodo je peux configurer ces plateformes pour qu’à chaque envoi de mon travail peut résulter un appel à une adresse Web.

Il suffit ensuite, à l’adresse appelée, de pouvoir étudier la requête envoyée et d’agir en conséquence (par exemple déployer un site).

Sur le papier ça a l’air fun :

(manuel) j’écris mon article dans un fichier texte
(manuel) je commite et pousse sur Gitea/Github/Gitlab
(automatique) la plateforme de réception envoie un appel à un de mes serveurs
(automatique) un de mes serveurs reçevant l’appel lance un script ou une action pour publier les dernières nouveautés

Parfait on se lance là dedans !

La naissance de Gachette

En 2019 où j’étudiais la question, je ne trouvais pas de serveur simple et léger qui puisse supporter les appels envoyés par Github, Gitlab et Gitea. Hors de question d’avoir 3 serveurs de webhooks différents sur mes machines.

Comme j’ai cru comprendre être ingénieur logiciel au travail 🤣, je me suis dit pouvoir l’être aussi à la maison sur mon temps personnel. À l’époque je m’amusais un peu avec le langage Crystal avec des amis, c’était l’occasion.

C’est ainsi qu’est né Gachette, un serveur de webhooks sous Licence MIT en Crystal (une syntaxe comme Ruby, mais compilé) qui supporte les plateformes Github, Gitlab et Gitea.

Sous ce langage, il existe quelques frameworks, dont Kemal, un framework web minimaliste qui permet d’ouvrir quelques routes très facilement. C’est ce que j’ai utilisé pour créer la première version 0.1 de Gachette en 2019.

À tout casser on doit être à 100 lignes de code. Bref. À aujourd’hui, plutôt 200+ lignes de code Crystal.

Voyons les particularités de mise en place de Gachette.

Mise en place de Gachette sur un serveur

Je ne vais pas reproduire ce que le fichier README de Gachette énonce si bien pour l’installation, cependant je peux vous faire un résumé rapide de l’installation/configuration :

# On récupère le projet
git clone https://github.com/blankoworld/gachette.git
cd gachette
# Pré-requis : Crystal, Shards et make doivent être installés
shards install
# On compile le logiciel
make

À l’issue de ces commandes devrait apparaître un fichier bin/gachette qui est un exécutable utilisable tel quel.

On le place où on veut, par exemple dans /srv/www/gachette/gachette puis on édite le fichier /etc/systemd/system/gachette.service dont le contenu est le suivant :

[Unit]
Description=Gachette webhooks service
After=network.target

[Service]
Type=simple
User=http
WorkingDirectory=/srv/www/gachette
ExecStart=/srv/www/gachette/gachette -c /etc/gachette.ini -b 0.0.0.0 -p 3000
Environment="KEMAL_ENV=production"
Restart=always

[Install]
WantedBy=multi-user.target

À noter qu’il faut adapter User=http par l’utilisateur de votre système d’exploitation, par exemple sous Debian c’est User=www-data. Mais également le port utilisé, ici c’est le port 3000.

Ensuite créez le fichier /etc/gachette.ini avec un contenu qui va décrire les dépôts/projets qui vont contacter le serveur webhooks et déclencher une action. Imaginons que le projet Gachette, sur Github, à l’adresse https://github.com/blankoworld/gachette veuille qu’à chaque commit nous exécutions le contenu du script /srv/www/gachette/deploiement.sh, nous allons écrire :

# contenu du fichier /etc/gachette.ini
[Un_nom_au_hasard]
service = github
namespace = blankoworld/gachette
key = monMot2Passe
scriptfile = /srv/www/gachette/deploiement.sh

Une fois la configuration faite, le service installé, vous pouvez faire en tant qu’utilisateur root :

# pour lancer le service
systemctl start gachette.service
# pour voir l'état du service
systemctl status gachette.service
# pour lancer le service à chaque redémarrage : 
systemctl enable gachette.service
# pour suivre ce qu'il se passe dans Gachette : 
journalctl -xe -f -u gachette.service

Tout résidera ensuite dans votre capacité à créer des scripts qui feront le travail de déploiement.

Dans ma situation, pour le présent blog, j’ai un script qui :

récupère la dernière version du dépôt Git du blog
compile le site pour générer les fichiers statiques
synchronise le résultat - si réussi - vers un dossier particulier
relance le serveur Web avec les nouveaux fichiers

Suite à mon dernier article sur Træfik pour publier ses conteneurs Docker, je me suis même essayé à l’utilisation de conteneurs Docker pour isoler les environnements, voire même à avoir des images Docker communes pour l’ensemble des sites Web statiques : très pratique !

On s’amuse bien par ici en somme 😉.

Conclusion

Bien que certains jugerons ma chaîne de publication assez alambiquée, utilisant des outils peu communs, voire pas du tout utilisés (Gachette notamment), ce système a déjà fait ses preuves et tourne bien : moins d’une minute après avoir enregistré un article, il est publié sur le web sans action humaine.

Il n’y a pour cela que 3 outils simples :

Gitea comme dépôt Git ; qui déclenche une demande auprès d’un serveur distant (ici Gachette)
Gachette qui reçoit la demande et lance un script de compilation/déploiement/traitement (bref, une action est menée)
Nginx comme serveur Web pour diffuser les pages statiques ainsi générées

L’utilisation de Docker en sus améliore le côté réutilisable des outils : pour plusieurs sites statiques j’utilise la même image qui va compiler les fichiers puis les mettre à disposition sur le net.

La difficulté réside cependant à notre capacité à créer des scripts pour lancer les différentes actions sur le serveur. La ligne de commande et Bash sont de fidèles alliés !

Liens utiles

Utilisation de træfik pour publier ses conteneurs Docker

Wed, 07 Dec 2022 07:16:11 +0100

Introduction

Il y a 8 ans je vous faisais découvrir Docker. À l’époque je ne savais pas encore à quel point cet outil très controversé serait utilisé !

Docker est quasiment devenu un standard. Qu’on le veuille ou non il arrive souvent qu’on ait un conteneur Docker à lancer. On finit toujours par devoir lire la documentation de Docker.

Avant de continuer sur la problématique du présent article, je tiens à vous signaler qu’il est important de savoir un minimum jouer avec les fichiers docker-compose.yml. Cas échéant je crains que cet article ne vous soit d’aucune autre utilité que nourrir votre curiosité.

Ainsi, un problème qui survient fréquemment quand on a crée nos images, nos conteneurs puis que nous lançons ces derniers : comment publier nos conteneurs afin qu’ils soient disponibles sur Internet ? En général la solution est d’utiliser un proxy (par exemple Nginx) qui va étudier les requêtes HTTP demandées sur le serveur puis rediriger vers le port choisi d’un conteneur Docker qu’on a lancé.

Dans cet article je vais rapidement expliquer pourquoi le choix de Træfik plutôt que Nginx que j’utilisais avant ça. Ensuite j’expliquerai les configurations utilisées pour mettre à disposition nos conteneurs. Nous aborderons rapidement quelques points pour aller plus loin et finirons par une conclusion.

Choix du proxy

Habituellement, pour mettre en place l’accès à des sites web que j’héberge, j’utilisais Apache, Nginx ou encore Caddy.

Cependant il y avait pas mal de contraintes :

chaque nouveau domaine demandait une configuration spécifique avec un fichier spécifique, des dossiers spécifiques,
pour avoir un certificat SSL par Let’s Encrypt, il fallait parfois user d’intelligence, même une fois qu’on utilise Certbot, notamment pour redémarrer le serveur Web une fois les certificats renouvelés,
quand on lançait un conteneur Docker, il valait mieux choisir un port spécifique, par exemple 8081, puis recopier ce nombre en dur dans la configuration du serveur Web (Nginx dans mon cas) et je ne suis pas le plus imaginatif pour les numéros de ports qui se cumulaient…

Ce qui est assez pénible. Très consommateur de temps.

Étant donné que nous utilisons déjà les possibilités de Docker et Docker Compose, autant continuer en utilisant un outil ayant un backend avec Docker, non ?

C’est là que Træfik entre en jeu :

il permet avec quelques lignes dans vos fichiers docker-compose.yml de définir le domaine à utiliser pour tel ou tel conteneur Docker
il s’occupe de faire la demande de certificat Let’s Encrypt et le renouvellement de ces derniers
le lancement d’un conteneur Docker ne demande pas de relancer Træfik, il y a une détection automatique des configurations
on laisse les ports choisis par Docker pour nos conteneurs, ce qui nous évite d’en faire une gestion
étant codé en Go (tout comme Docker et Docker Compose), Træfik fait partie du même monde, il est donc aussi rapide et compatible avec les outils utilisés
pas besoin d’installer Træfik : il sera un conteneur Docker comme le reste des services de la machine 😃

Au final ce sont les contraintes des serveurs Web dont j’ai eu l’usage qui m’ont convaincu d’essayer Træfik. Voyons donc à quoi cela ressemble !

ATTENTION : Træfik ne résoud pas tous les problèmes du monde. Il va falloir expérimenter, recommencer plusieurs fois, plier son cerveau pour saisir de quoi il retourne. Parfois demander de l’aide. C’est un processus d’apprentissage qui en vaut la peine cependant !

Configuration de træfik

Pour mettre en place Træfik nous allons procéder comme la documentation de Træfik Proxy le propose :

faire un docker-compose.yml pour décrire notre service Træfik
utiliser un fichier de configuration externe pour configurer le service : le fichier traefik.yml
demander à exposer les ports 80 et 443

Pour cela, voici le fichier docker-compose.yml pour lancer le service Træfik :

version: '3'

services:
    proxy:
      image: traefik:v2.8
      restart: always
      ports:
      	- 80:80
        - 443:443
      volumes:
        # pour que Træfik écoute les événements Docker : à adapter chez vous
        - /var/run/docker.sock:/var/run/docker.sock
        # Utilisation d'un fichier de configuration
        - ${PWD}/traefik.yml:/etc/traefik/traefik.yml
        # Mémorisation des certificats TLS (par Let's Encrypt)
        - ${PWD}/acme.json:/acme.json
      labels:
        # Activation du tls
        - "traefik.http.routers.api.tls"
        # nawak, pour que les logs la boucle sur service error: port is missing
        - "traefik.http.services.nawak.loadbalancer.server.port=8484"

Ce qui va monter le fichier local /var/run/docker.sock pour discuter avec Docker : adaptez-le au fichier Socket de votre service Docker.

Cela va utiliser le fichier traefik.yml local qui contient notre configuration pour notre service Træfik.

On stocke les données des certificats dans le fichier local acme.json : pensez à faire touch acme.json pour créer le fichier avant de lancer.

Et voici le contenu de notre fichier traefik.yml :

api:
  dashboard: true # pour activer un tableau de bord

providers:
  docker:
    network: traefik # réseau de discussion entre les conteneurs et traefik
    exposedByDefault: false # n'active pas les conteneurs par défaut sur le web

entryPoints:
  web:
    address: ":80"
    http:
      redirections:
        entryPoint:
          to: websecure # pointe sur websecure plus bas (port 443 en somme)
          scheme: https

  websecure:
    address: ":443"
    http:
      tls: # configuration par défaut
        certResolver: letsencrypt # pointe sur la config. letsencrypt plus bas

  traefik: # adresse pour le dashboard ;-)
    address: ":8080"

certificatesResolvers:
  letsencrypt:
    acme:
      email: "mon-courriel@domaine.tld"
      storage: "/acme.json"
      httpChallenge: # le type utilisé pour valider les certificats Let's Encrypt
        entryPoint: web

Je me suis permis de commenter un peu partout pour savoir de quoi il retourne.

Sachez qu’il existe aussi une méthode pour créer un fichier sur lequel Traefik va lire régulièrement pour mettre à jour sa configuration. Peut-être ferais-je un autre article sur ce sujet un jour. Petite piste : c’est le Provider nommé file qui permet de faire ça.

Une fois configuré, les autres conteneurs Docker que nous lançons n’ont plus besoin que des lignes suivantes dans leur fichier docker-compose.yml :

labels:
  - "traefik.enable=true"
  - "traefik.http.routers.un-nom-de-service.rule=Host(`mon.domaine.com`)"
  - "traefik.http.routers.un-nom-de-service.entrypoints=websecure"

Au lancement de vos conteneurs via un fichier docker-compose.yml, Træfik lira les informations contenues dans labels et tentera de les analyser puis utiliser à bon essien.

Dans l’exemple donné ci-avant, on comprend que :

trafik.enable : le service doit être publié par Traefik (car dans la configuration nous avions mis exposedByDefault: false, donc pas de publication par défaut)
traefik.http.routers.un-nom-de-service.rule=Host(`mon.domaine.com`) : pour votre service remplacez un-nom-de-service par ce que vous voulez. Et mon.domaine.com par le domaine que vous détenez
la dernière ligne ne sert qu’à indiquer quel entrée par défaut accepter/utiliser. En l’occurence celle nommée websecure qui, dans notre configuration du fichier traefik.yml est configurée pour être disponible sur le port 443 avec un résolveur de certificat Let’s Encrypt

Exemple de docker-compose.yml pour lancer un service :

version: '3'

services:
    whoami:
      image: traefik/whoami
      labels:
        - "traefik.enable=true"
        - "traefik.http.routers.whoami.rule=Host(`whoami.domaine.com`)"
        - "traefik.http.routers.whoami.entrypoints=websecure"

Y aurait-il encore d’autres fonctionnalités sympas ?

Pour aller plus loin

Dans ce que j’ai pratiqué, voici quelques points à étudier pour aller plus loin :

utilisation de Let’s Encrypt par challenge DNS qui permet de gérer les DNS de son fournisseur de domaine en direct. Par exemple pour Gandi il suffit de fournir la variable d’environnement GANDIV5_API_KEY
utilisation d’un fichier externe avec watch: true pour appliquer les changements dès modification du fichier
utilisation de middleware pour une authentification basique
activer un port, par exemple 8080 pour l’accès au tableau de bord
dans certains cas où les services ne sont pas forcément dans des Docker, il peut être intéressant de fournir une IP et un port spécifique par un loadBalancer, Cf. https://doc.traefik.io/traefik/routing/services/#servers

Il y a beaucoup plus à découvrir avec Træfik. Je vous invite à lire la documentation qui est très riche et bien expliquée.

Conclusion

Utiliser Træfik a permis de réduire considérablement le temps de maintenance de mes services, que ce soit en terme de mises à jour, de renouvellement de certificats et d’organisation des dossiers/fichiers.

Cependant qu’on se le dise, ce n’est pas exempt de quelques difficultés :

il n’y a pas toujours des images Docker de vos services, il faut donc parfois fabriquer soi-même les conteneurs,
la courbe d’apprentissage de Træfik est assez difficile,
on se casse les méninges jusqu’à comprendre comment fournir un service sur Træfik

Si on fait l’effort d’apprendre Træfik et d’investir du temps, c’est surtout pour assurer la possibilité de connecter tout cela à un système de métriques, pouvoir faire de la journalisation, vérifier l’état de santé des serveurs, etc.

Il y a de quoi faire !

État des lieux 2022

Wed, 21 Sep 2022 18:54:18 +0200

Intro

Il fait bien longtemps, chers lecteurs, que ce blog n’avait pas été mis à jour. Qu’en est-il aujourd’hui ? Qu’adviendra-t-il à celui-ci dans l’avenir ?

Nous allons faire l’état des lieux du blog, de ma présence sur le net et des choses à venir, mais avant tout peut-être voudriez-vous savoir ce qui fait qu’on laisse un blog en déperdition aussi longtemps.

Image dans le domaine public trouvée sur une galerie photo de aeroman3.

État des lieux

IRL (In Real Life) nous rattrape bien plus souvent qu’il n’y paraît. Et cela a un impact sur l’espace numérique que l’on se fait.

En effet que ce soit financier, familial, moral ou technique, toutes ces choses s’ammoncèlent pour faire une montagne qui nous écrase au sol.

Long est le chemin pour s’en sortir et avoir à nouveau un peu de souffle pour conter des histoires et/ou rassembler nos pérégrinations quelque part.

En sommes j’ai cumulé pas mal de choses qui m’ont empêché de tenir ce blog, mais surtout les serveurs sur lesquels mon espace numérique tournait.

Fort heureusement, récemment, un généreux donateur (via Liberapay) fourni de quoi payer une partie de l’hébergement à l’année.

Le bilan, après ces 3 années n’est pour autant pas folichon.

Sur le blog :

quelques liens cassés (que je résoudrais petit à petit)
je n’ai plus de Microblog car le service herds.eu a été fermé (j’étais le seul résident de cette instance)
mon CV ne fonctionne plus sur la version actuelle d’Hugo

Sur le reste de mon espace numérique :

les sauvegardes c’est fini
je n’ai plus de service de contact/agenda auto-hébergé
sur la trentaine de sites que j’avais, seulement 7 restent
mes automatisations ne sont plus
je suis passé de 2 serveurs dédiés à un seul, très petit
plus aucun serveur Jabber/XMPP

Le bilan est lourd. Le temps me manque. Mes priorités sont toutes autres.

Mais alors que viser pour les prochains temps ?

L’avenir proche

Bien que mes objectifs aient changé ces dernières années, l’informatique et le numérique plus généralement me tient à cœur. J’en reviens toujours à ce domaine, quoiqu’il arrive.

L’idée pour les prochains temps sera donc :

de partager mes pérégrinations sur les différentes technologies que j’aborde de mon côté
remettre petit à petit les services
corriger quelques liens morts
apporter de l’automatisation pour remettre ma chaîne de publication en ordre
réouvrir des services tels que les salons Jabber/XMPP
en profiter 😃

De la sorte, le blog tournera forcément un peu plus et quelques articles sortiront !

Quelques articles potentiels

Dans les prochaines idées d’article :

Utilisation de Traefik et Docker pour les services
Mise en place de Gachette, serveur de webhooks personnel pour créer une chaîne de publication
Quelques lignes sur DreamLight Valley, le nouveau RPG Disney

Conclusion

Si vous lisez ces lignes, je vous remercie de m’avoir gardé dans vos lecteurs de flux RSS. Je m’excuse également d’avoir cassé vos flux si c’est le cas, et j’espère que vous serez contents de lire les prochains articles à venir !

Au plaisir de vous faire de la lecture,

Olivier D.

Mise à jour des DNS Gandi (v5) avec la bbox de Bougues

Mon, 06 May 2019 20:18:29 +0200

Figurez-vous qu’après mes pérégrinations dans le monde de l’Internet nomade, j’ai eu l’occasion de passer à la Fibre. Et avec elle son lot de « malheurs » : une IP dynamique.

En quoi est-ce problématique ?

Une IP fixe permet de bénéficier d’une adresse constante, c’est à dire qu’elle permet, par exemple, d’avoir un nom de domaine qui redirige vers une à plusieurs machines de la maison. Par exemple avec bogossdu69.fr je pourrais éventuellement arriver sur mon partage de fichiers.

Photo trouvée sur le profil de sattygalle sur Flickr sous licence CC BY-SA 2.0.

La situation

Mon but est donc de mettre à jour régulièrement mes noms de domaine lorsque mon IP change.

Je dispose de :

une box Bouygues nommée bbox
une ip dynamique
un nom de domaine chez Gandi.net
une machine allumée en permanence sur la box

L’objectif

Mettre à jour régulièrement le nom de domaine pour qu’il pointe vers ma box en permanence.

Ma solution en 1 commande

En une commande :

curl -s https://mabbox.bytel.fr/api/v1/wan/ip |jq '.[0].wan.ip.address'| xargs -I{} curl -X PUT -H "X-Api-key: LaSuperCleAPIdeGandiV5" -H "Content-Type: application/json" -d '{"rrset_ttl":"1800","rrset_values":["{}"]}' https://dns.api.gandi.net/api/v5/domains/domain.tld/records/bogossdu69/A

En remplaçant :

LaSuperCleAPIdeGandiV5 par la clé de sécurité dans votre interface Gandi sur Tableau de Bord > Paramètres > Sécurité > (Re)Générer la clé d’API
domain.tld par votre domaine, par exemple dossmann.net
bogossdu69 par votre sous-domaine, par exemple olivier (ce qui donnera olivier.dossmann.net)

Le détail

L’idée est de lancer un script régulièrement (par exemple toutes les 5 minutes) sur la machine branchée à la Box.

Pour cela on va utiliser les outils suivants :

l’IP donnée par l’API de votre bbox et dont la documentation est sur le site officiel de l’API de Bouygues
curl fourni dans la plupart des distributions GNU/Linux (et plus encore !)
jq
l’outil timerctl fourni dans le système pour planifier l’exécution de tâches régulières
et la commande précédente aménagée dans un script

L’API de notre box va fournir l’IP publique dynamique de notre connexion internet. jq va permettre la récupération de la bonne information parmi l’ensemble fourni par notre box. Après quoi curl mettra à jour les DNS dynamiques de Gandi (notre fournisseur de nom de domaine).

Il ne nous reste plus qu’à taper la commande entière dans le fichier /etc/systemd/system/maj_domaine.service sous la forme suivante :

[Unit]
Description=Mise a jour du domaine Gandi

[Service]
Environment="API_KEY=oefijzoifjzeoifjzeoifjeo"
ExecStart=/usr/bin/bash /home/user/maj_domaine.sh
Type=simple

N’oubliez pas d’adapter API_KEY avec votre clé d’API et /home/user/ par l’adresse où se trouve le script !

Puis de renseigner le fichier /etc/systemd/system/maj_domaine.timer avec :

[Unit]
Description=Lance maj du domaine toutes les 8 min

[Timer]
OnBootSec=8min
OnUnitActiveSec=8min
Persistent=True
Unit=maj_domaine.service

[Install]
WantedBy=multi-user.target

Il ne nous reste plus qu’à prévenir systemd via les commandes suivantes :

sudo systemctl daemon-reload
sudo systemctl enable maj_domaine.timer
sudo systemctl start maj_domaine.timer
sudo systemctl start maj_domaine.service

Et le tour est joué !

Conclusion

À l’aide des outils listés dans ce billet on peut sans problème survivre à une IP dynamique à la maison chez Bouygues Telecom. Je n’ai eu jusqu’à ce jour aucun problème et espère que cela continuera ainsi.

Déploiement d'une application Crystal en production

Sun, 07 Oct 2018 15:29:39 +0200

Introduction

Le mois dernier je parlais de l’installation de PixelFed, un outil récent avec peu de documentation. Aujourd’hui je voudrais installer en production un site web développé avec Amber, un framework du langage Crystal pour développer rapidement des sites webs.

Force est de constater que souvent les tutoriels proposés ne correspondent pas à mes attentes. J’ai décidé de vous livrer aujourd’hui le résultat de mes enquêtes sur le sujet !

Après une présentation du framework Amber, je listerai rapidement les étapes à suivre pour déployer son application sur un serveur.

Un tutoriel plus détaillé pour Amber est disponible sur mon wiki.

Au sujet d’Amber

C’est un framework web. C’est à dire un outil pour simplifier la création de sites Web. Il peut aussi bien faire des sites vitrines que des applications webs ou des API web. Il est donc multifonctions.

Amber est écrit en Crystal, un langage dont la syntaxe est similaire à Ruby, mais dont l’application résultante est plus rapide. Ça dépotte !

Pourquoi je parle de Ruby aussi ? Parce qu’il possède un outil formidable très connu pour créer des sites webs : Ruby On Rails. Déjà très intéressant pour créer des sites webs, il était normal que les développeurs Crystal s’attardent à la création d’un outil similaire : Amber !

J’ai déjà utilisé Ruby On Rails, alors je me suis dis pourquoi pas tenter Amber ? Allons-y !

Déploiement, en bref

Je rappelle qu’un tutoriel plus détaillé pour Amber est disponible sur mon wiki. Et le “Quick Start” d’Amber explique très bien comment créer un projet.

Pour déployer Amber, il faut suivre quelques étapes clés :

créer une base de données sur le serveur et garder en tête l’identifiant, le mot de passe et la base de donnée associée
configurer le mode production sur notre machine et garder quelque part la clé située dans le fichier .encryption_key
compiler sur notre machine l’application en mode --release, mais aussi amber lui même. Si votre machine et le serveur sont d’architectures différentes, pensez à la compilation croisée d’application Crystal (en)
copie de certains dossiers de votre application vers le serveur
migration du schéma de la base de données sur le serveur
création d’un fichier systemd sur le serveur pour le lancement/arrêt du service (votre site web)
lancement de votre service sur le serveur
configuration et relance de Nginx en association avec votre site web sur le serveur

Je vous donne ce qui est généralement important ci-dessous.

La configuration de la connexion dans le fichier de production :

database_url: postgres://amber_user:mot2passe@localhost:5432/amber_production

Savoir quels fichiers copier :

bin/
config/environments/.production.enc et QUE celui-là (les autres sont inutiles pour la production)
db/
public/
src/locales/

On oublie souvent de déployer la base (en mettant la clé située dans le fichier .encryption_key) :

AMBER_ENV=production AMBER_ENCRYPTION_KEY="oliBK0J9-HrSK1K8VPTtsMERyj2as1mUZqvPqfKGGeQ" ./bin/amber db migrate

Avec un fichier systemd bien rempli, notamment les variables d’environnement :

[Unit]
Description=Lance le framework web Amber pour le site monsite.tld
After=network.target

[Service]
Type=simple
User=http
WorkingDirectory=/srv/www/monsite
Environment="AMBER_ENV=production"
Environment="PORT=3002"
Environment="AMBER_ENCRYPTION_KEY=oliBK0J9-HrSK1K8VPTtsMERyj2as1mUZqvPqfKGGeQ"
ExecStart=/home/www/monsite/bin/tutamber
Restart=always

[Install]
WantedBy=multi-user.target

Et finalement on se mange souvent sur une configuration Nginx pourrie, mais on commence simple :

server {
  listen      *:80;
  listen      [::]:80;
  server_name monsite.domaine.tld;
  root        /srv/www/monsite;
  index       index.html;

  proxy_set_header X-Real-IP  $remote_addr;

  location / {
    proxy_set_header Host $host;
    proxy_pass http://127.0.0.1:3002;
  }
}

Et voilà !

Conclusion

Le déploiement d’une application Amber n’est pas plus compliquée qu’un autre service. Mais il faut avouer qu’elle n’est pas si bien détaillée sur le site même d’Amber. Le projet est encore jeune, tout autant que le langage Crystal lui-même. Avec mon tutoriel vous savez quoi faire : installer des sites Amber partout 😂.

Cependant je vous conseille vivement de tester Crystal, Amber et d’autres éléments de la communauté : c’est facile à écrire, c’est réactif, bien pensé, avec une communauté active, des personnes gentilles qui répondent aux questions, c’est top !

Installation de PixelFed, une alternative à Instagram

Fri, 14 Sep 2018 23:34:55 +0200

Introduction

Peut-être le saviez-vous, ma curiosité m’a amenée à parcourir les réseaux sociaux. Ainsi je réside sur GNU Social, un réseau alternatif. Àla Twitter. Mais décentralisé. Depuis début 2018, ce réseau évolue rapidement. De nouvelles applications basées sur celui-ci fleurissent :

Mastodon : encore meilleur que Twitter !
PeerTube : YouTube sans la censure
Funkwhale : Groovshark chez soi, à partager en famille
PixelFed : alternative à Instagram
etc.

Nous allons nous intéresser au dernier de la liste : PixelFed, un outil pour publier et partager des photos. Un tutoriel plus accessible sur son installation manque cruellement sur le web, alors pourquoi ne pas se lancer ici ?

Je vous expliquerai en plusieurs étapes ma procédure d’installation. Le logiciel n’est pas encore stable, je préfère donc en parler ici plutôt que sur mon recueil d’astuces.

Avant-propos

Ce « tutoriel » est très probablement réservé à des personnes ayant un minimum d’assurance avec la ligne de commande ; les serveurs et probablement d’autres compétences dont je ne me rends pas compte. La lecture sera probablement longue, prenez votre temps et achevez les tâches progressivement.

PixelFed est un outil récent qui n’a pas été testé ni longtemps ni sur énormément d’instances. Je crois qu’il est sage de dire qu’il est réservé aux têtes brûlées. Ces personnes qui souhaitent être à la fois « hype » mais se casser les dents sur des soucis. Cela m’est arrivé : j’ai mis plusieurs heures à trouver ce qui n’allait pas.

Je ne serais en aucun cas tenu pour responsable de toute perte de données, de problèmes ou de catastrophe résultant de l’application des commandes de ce tutoriel. Vous êtes assez intelligents pour vous renseigner si le besoin s’en fait sentir. D’ailleurs un canal IRC pour PixelFed existe pour vous aider. Vous n’êtes pas seul, l’univers que nous connaissons est rempli d’aliens comme vous et moi :)

Prérequis

Sur la page du dépôt du projet on lit que l’application requièrt PHP supérieur ou égal à 7.1. Pour Debian c’est mort, à moins que vous soyez le roi du pinning. Pour Ubuntu, c’est déjà mieux : PHP 7.1 (sous bionic).

Dans le présent tutoriel j’ai travaillé sur une machine possédant ArchLinux et PHP 7.2. J’ai donc utilisé les éléments suivants :

php, Cf. https://wiki.archlinux.org/index.php/PHP
php-fpm, Cf. https://wiki.archlinux.org/index.php/nginx#PHP_implementation
postgreSQL, Cf. https://olivier.dossmann.net/wiki/services/postgres/ et https://wiki.archlinux.org/index.php/PostgreSQL
redis, https://wiki.archlinux.org/index.php/redis
git
nginx, Cf. https://wiki.archlinux.org/index.php/nginx

J’ai installé les paquets suivants :

sudo pacman -S php php-fpm php-gd php-pgsql git postgresql redis

Puis à la lecture du fichier README sur le dépôt git officiel de PixelFed, j’ai du installer plusieurs autres logiciels, y compris sur les dépôts AUR d’ArchLinux en utilisant l’outil trizen - que je recommande.

Voici les logiciels supplémentaires :

trizen -S optipng jpegoptim pngquant gifsicle svgo composer

Éditez également le fichier /etc/php/php.ini et décommentez (enlever le “;”) devant les lignes suivantes :

extension=bcmath.so
extension=gd.so
extension=iconv.so
extension=pdo_pgsql.so
extension=pgsql.so
extension=zip.so

Nous lancerons les différents services plus tard, passons déjà à l’installation de PixelFed.

Installation

Nous vérifions que le dossier /srv/http/ existe :

sudo mkdir -p /srv/http

puis nous créeons le dossier pixelfed et lançons l’installation des dépendances :

cd /srv/http
sudo git clone https://github.com/dansup/pixelfed.git
cd pixelfed
composer install

Le plus gros de l’installation est faite ! Faisons de la configuration avant le grand lancement !

Configuration

La configuration va se passer en quelques étapes :

configuration d’un fichier pour php-fpm, spécifique à PixelFed
configuration du fichier .env de PixelFed
lancement de postgreSQL
configuration d’une base de données pour postgreSQL
ajout d’un fichier de service pour systemd afin de lancer horizon pour PixelFed
configuration de Nginx
création d’une clé pour PixelFed
création du lien sur les storage de PixelFed
modification des permissions du dossier /srv/http/pixelfed

On crée le fichier /etc/php/php-fpm.d/pixelfed.conf avec le contenu suivant :

[pixelfed]
user = http
group = http
listen = /run/php-fpm/php-fpm-pixelfed.sock
listen.owner = http
listen.group = http
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3

Au cas où, on crée nous même le fichier /run/php-fpm/php-fpm-pixelfed.sock :

sudo mkdir -p /run/php-fpm
sudo touch /run/php-fpm/php-fpm-pixelfed.sock && sudo chown http:http /run/php-fpm/php-fpm-pixelfed.sock

Rendons-nous dans le dossier PixelFed pour créer le fichier de configuration et l’éditer :

cd /srv/http/pixelfed
sudo cp .env.example .env

avec le contenu suivant :

APP_NAME="Le plus terrible des noms d'instance que tu peux trouver"
APP_ENV=production
APP_DEBUG=false
APP_URL=http://tondomaine.tld

# Language configuration
#APP_LOCALE=fr
#APP_FALLBACK_LOCALE=fr

ADMIN_DOMAIN="tondomaine.tld"
APP_DOMAIN="tondomaine.tld"

LOG_CHANNEL=stack

DB_CONNECTION=pgsql
DB_HOST=127.0.0.1
DB_PORT=5432
DB_DATABASE="pixelfed"
DB_USERNAME="roidumonde"
DB_PASSWORD="ilestdesnôootres,ilabusonverrecommeuxlesôÔtres"

BROADCAST_DRIVER=log
CACHE_DRIVER=redis
SESSION_DRIVER=redis
SESSION_LIFETIME=120
QUEUE_DRIVER=redis

REDIS_HOST=127.0.0.1
REDIS_PASSWORD=null
REDIS_PORT=6379

MAIL_DRIVER=smtp
MAIL_HOST=smtp.tondomaine.tld
MAIL_PORT=587
MAIL_USERNAME=tonpseudo@tondomaine.tld
MAIL_PASSWORD=mot2passe
MAIL_ENCRYPTION=tls
MAIL_FROM_ADDRESS="contact@tondomaine.tld"
MAIL_FROM_NAME="Le nom d'expéditeur que tu veux que les personnes voient"

SESSION_DOMAIN=".tondomaine.tld"
SESSION_SECURE_COOKIE=true
API_BASE="/api/1/"
API_SEARCH="/api/search"

OPEN_REGISTRATION=true
RECAPTCHA_ENABLED=false
ENFORCE_EMAIL_VERIFICATION=false

MAX_PHOTO_SIZE=15000
MAX_CAPTION_LENGTH=150
MAX_ALBUM_LENGTH=4

MIX_PUSHER_APP_KEY="${PUSHER_APP_KEY}"
MIX_PUSHER_APP_CLUSTER="${PUSHER_APP_CLUSTER}"
MIX_APP_URL="${APP_URL}"
MIX_API_BASE="${API_BASE}"
MIX_API_SEARCH="${API_SEARCH}"

Pour certaines variables vous trouverez des informations dans la documentation de Laravel, outil utilisé pour crée PixelFed.

Puis on lance postgreSQL et on crée une base de données suivant les informations ajoutées dans le fichier de configuration précédent :

sudo systemctl start postgresql.service
sudo systemctl enable postgresql.service
sudo su - postgres
createuser roidumonde
createdb -O roidumonde -E UTF-8 pixelfed
psql pixelfed
ALTER USER roidumonde WITH PASSWORD 'ilestdesnôootres,ilabusonverrecommeuxlesôÔtres';
\q
exit

Maintenant on va créer le fichier de service systemd pour lancer horizon. Éditez /etc/systemd/system/horizon.service et mettez y ceci :

[Unit]
Description=Service horizon pour PixelFed
After=network.target

[Service]
Type=simple
User=http
WorkingDirectory=/srv/http/pixelfed
ExecStart=php artisan horizon
Restart=on-failure

[Install]
WantedBy=multi-user.target

suivi de :

sudo systemctl daemon-reload

Edit : À la lecture d’un ticket sur Github qui m’a été signalé par raphgilles, le fichier /etc/systemd/system/horizon.service peut ressembler à ceci :

[Unit]
Description=Service horizon pour PixelFed
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/php7.2 /srv/http/pixelfed/artisan horizon
Restart=on-failure

[Install]
WantedBy=multi-user.target

De là on édite le fichier /etc/nginx/nginx.conf et on rajoute la section suivante sous la ligne :

# HTTPS Server

avec :

server {
  listen         *:80;
  listen         [::]:80;
  server_name    tondomaine.tld;

  root /srv/http/pixelfed/public;
  index index.php index.html;

  location / {
    try_files $uri $uri/ /$is_args$args;
  }

  location ~ \.php$ {
    try_files $uri =404;
    fastcgi_split_path_info  ^(.+\.php)(.*)$;
    fastcgi_pass unix:/run/php-fpm/php-fpm-pixelfed.sock;
    fastcgi_index index.php;
    include fastcgi.conf;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_param PATH_INFO $fastcgi_path_info;
  }

}

Il n’y a plus qu’à lancer redis, générer une clé pour PixelFed, générer le lien vers le dossier storage, migrer la base de données et changer les permissions du dossier :

sudo systemctl start redis.service
sudo systemctl enable redis.service
cd /srv/http/pixelfed
php artisan key:generate
php artisan storage:link
php artisan migrate
cd /srv/http
sudo chown http:http pixelfed -R

Chaud bouillant pour tester si tout va bien ? C’est parti !

Ça passe ou ça casse !

Tout est prêt, il ne reste plus qu’à :

lancer horizon
lancer php-fpm
lancer Nginx
tout casser 😭

Faites :

sudo systemctl start horizon.service
sudo systemctl enable horizon.service
sudo systemctl start php-fpm.service
sudo systemctl enable php-fpm.service
sudo systemctl start nginx.service
sudo systemctl enable nginx.service

Alors, si vous allez sur tondomaine.tld, tout fonctionne ?

Accéder au Dashboard admin

Au moment où j’ai écris ce tutoriel, le bug 327 avait encore cours. Pour pallier à ce problème, j’ai lancé la commande suivante :

sudo mkdir -p /srv/http/pixelfed/storage/app/public/m && sudo chown http:http /srv/http/pixelfed/storage/app/public/m

Et pour devenir administrateur, sachant que nous sommes le premier utilisateur (id : 1) à s’être enregistré :

sudo su - postgres
psql pixelfed
UPDATE users SET is_admin = 't' WHERE id = 1;
\q
exit

Et vous voilà administrateur !

Conclusion

Je dois avouer que l’installation est non seulement longue, mais compliquée. Le nombre de problèmes à régler est plus important que pour l’installation d’une autre application PHP que j’ai eu l’occasion d’utiliser.

J’ai par exemple encore quelques soucis pour comprendre comment personnaliser les pages d’à propos, de licence, la page d’accueil, etc. sans casser mon installation et ses mises à jours. J’aimerais également savoir si le lien entre PixelFed et Redis fonctionne réellement, parce que d’après le Dashboard admin, Redis est inactif…

Je suis pressé d’être à l’année prochaine pour voir ce que ce projet donnera ! Et peut-être aurons-nous une application mobile pour faciliter l’envoi de données ? Voire la possibilité d’utiliser AndStatus, Twidere ou Tusky pour envoyer nos belles images et nos têtes curieuses 👽 .

Mon wiki en tenue d'Adam & Eve

Tue, 24 Jul 2018 11:53:08 +0200

Introduction

Rappelez-vous l’année dernière je parlais de migrer de Dokuwiki à Hugo. Au bout d’un an je suis fier de vous annoncer la sortie effective de mon Wiki sous Hugo en tenue d’Adam & Eve.

Après avoir listé rapidement les changements effectués, je vous montrerais quelques images de l’avant/après. Je dois avouer être satisfait de ce recueil d’astuces qui se présente dans son plus simple apparât grâce à ce thème.

Photo trouvée sur le profil de Waiting For The Word sur flickr sous licence CC BY 2.0.

Le travail accompli

Si j’ai pris autant de temps c’est essentiellement pour le remaniement du contenu. J’ai également profité pour construire progressivement le thème Adam & Eve pour les sites Hugo.

J’ai donc :

supprimé des pages inutiles
mis aux archives les pages obsolètes
corrigé quelques fautes
remanié du contenu pour qu’il soit plus lisible
corrigé des liens, supprimé d’autres
réordonné la page d’accueil et crée différentes rubriques plus adaptées
crée un endroit d’archives
déplacé - dans un endroit secrètement secret du mystère mystérieux - mes pages personnelles
adapté le contenu de Dokuwiki à Hugo
crée un thème Adam & Eve pour Hugo avec des encarts, façon Note Plugin de Dokuwiki et des « shortcodes » Hugo afin d’afficher différemment les liens externes

J’ai traité 367 pages Dokuwiki. Le résultat contient pas loin de 200 pages désormais. Le nettoyage fait donc du bien !

Le changement visuel

Le wiki utilisait le thème de base de Dokuwiki avant le passage à Hugo. Il ressemblait donc à ceci :

L’équivalent à ce jour de la page correspondante est :

Naviguez sur mon wiki pour découvrir les différentes pages 😉.

Conclusion

Grâce à cette formidable aventure j’ai pu à la fois ranger et réduire mon wiki et créer un nouveau thème pour les futures personnes souhaitant se lancer dans la création d’un wiki à l’aide d’Hugo.

J’ai aussi parfait ma compréhension et mes connaissances de l’outil Hugo. Je vous partagerai sûrement tout cela dans un billet voire ajouterai une page wiki concernant Hugo.

Edit du 15 août 2018 : J’ai publié mon thème sur le dépôt officiel d’Hugo. Il est en attente de validation. Croisons les doigts !

Wekan, mon alternative à MyTinyTodo

Wed, 21 Feb 2018 19:07:46 +0100

Introduction

Pour encore beaucoup de personnes, s’organiser n’est pas une tâche facile. On commence par faire des pense-bête sur de petits papiers. Puis les notes s’accumulent et le bureau se retrouve complètement recouvert !

Pour pallier à ce genre de problèmes, j’utilise MyTinyTodo. Cependant c’est un outil mono-utilisateur et la dernière version date de 2014.

Je commence donc à tester plusieurs alternatives. Aujourd’hui je vais vous parler de l’une d’entre elles : Wekan, un kanban Libre façon “Trello” (service de pense-bête en ligne).

Photo trouvée sur le profil de Michael Arrighi sur Flickr

Présentation de Wekan

Wekan se base sur les kanban, un système de colonne et de lignes (appelées couloirs) pour trier ses tâches.

Par exemple on pourrait imaginer des colonnes “À faire”, “En cours”, “En attente” et “Terminées” pour trier ses tâches suivant leur état d’avancement. C’est vous qui choisissez !

Ce logiciel utilise des technologies Web assez modernes, ce qui permet une utilisation agréable de l’interface. C’est assez intuitif de manière générale, bien plus que MyTinyTodo ne l’est !

Je pense d’ailleurs que ça vaut le coup de comparer un peu MyTinyTodo et Wekan pour comprendre ce que Wekan peut apporter.

Comparaison succinte des deux outils

MyTinyTodo utilise GTD, une technique qui « trie » les tâches par un degré d’importance (4 niveaux). Pour agir sur l’interface et changer rapidement quelques tâches de degré d’importance, c’est une torture parce qu’il faut les sélectionner une à une. Là où Wekan propose simplement de déplacer la tâche dans la colonne appropriée.

En revanche, la méthode de Kanban énnoncée auparavant sous Wekan implique que vous sachiez comment organiser vos tickets. Alors que MyTinyTodo propose plutôt des catégories de tâches. Mais dont le déplacement n’est pas aussi simple qu’un glisser/déposer.

MyTinyTodo est mono-utilisateur. Wekan multi-utilisateur, avec un partage des tâches/tableaux et des sections privées/publiques.

MyTinyTodo consomme peu : 20Mo de mémoire vive à tout péter, avec une base SQLITE3 facile à sauvegarder. Tandis que Wekan utilise 120Mo de mémoire vive, utilise MongoDB qui utilise 20 Mo de mémoire vive et est embêtant à sauvegarder car il faut un script pour lancer la sauvegarde de la base (si on l’utilise dans un Docker c’est légèrement plus complexe).

C’était, dans les grandes lignes, ce qui diffère des deux outils. J’ai tout de même mon opinion sur l’outil Wekan, dont nous allons tout de suite parler.

Mon expérience de Wekan

Wekan, est une brise fraîche pour la gestion des tâches car le glisser/déposer d’une colonne ou d’une ligne (ils appellent ça des couloirs) à l’autre est aisé. Ce qui implique moins de temps à trier et plus de temps pour réellement faire les tâches. C’est agréable.

Seulement cet outil est de la folie furieuse pour tout le reste :

il consomme pas mal en mémoire vive (120Mo) et en processeur (CPU)
supprimer une tâche n’est pas intuitif : il faut aller dans “plus” puis trouver un petit lien souligné nommé « Supprimer »
supprimer un tableau ? Pas possible ! On peut l’archiver oui. Et plus tard, si vous êtes un guerrier, vous pouvez utiliser wekan-cleanup (un script) pour nettoyer votre base MongoDB
l’outil n’est pas disponible sur ARM en 32 bits. Notamment à cause de meteorJS qui est le framework utilisé pour développer l’outil
pas encore de possibilité d’utiliser autre chose que la base de données MongoDB
il utilise NodeJS. Sérieux, c’est assez galère de faire une installation propre sans exploser son propre système qui contient lui aussi du Javascript en pagaille

Le produit final est certes agréable pour l’utilisateur, mais côté serveur il faut pallier aux problèmes cités.

Conclusion

Vous l’aurez compris, je suis mitigé sur Wekan. Je souhaite trouver un outil plus léger, disponible sur ARM, avec une interface web et une méthode simple et « raffinée » pour déplacer rapidement les tâches d’une priorité ou d’une catégorie à une autre. Peut-être que je cherche le mouton à 5 pattes, mais mon petit doigt me dit que je trouverai une solution pour « créer » un outil capable de saisir et organiser rapidement mes tâches et les accomplir plutôt qu’à perdre du temps à les gérer !