Docker sur Olivier DOSSMANN

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 :

La Genèse d'un projet

Wed, 13 Sep 2023 12:13:23 +0200

Il y a quelques temps je lançais un billet sur le projet Gachette qui permet de publier mon blog. Dans la même lancée je souhaite aujourd’hui vous présenter un autre projet sur lequel je travaille de temps en temps : Genèse. Genèse est assez difficile à définir. Cependant je l’imagine comme une commande unique pour permettre à plusieurs développeurs de travailler sur un environnement commun et en lançant une instance par ticket/problème relevé.

Cet outil, bien qu’il soit utile et facile à utiliser, demande un minimum d’explication pour comprendre à la fois le concept et l’utilité réelle.
C’est pourquoi je vais avant tout poser la problématique principale qui a initiée le projet, puis montrer quelques usages intéressants qui sont plus parlants et finalement tenter d’expliquer son fonctionnement en interne.

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

Ce qui a initié le projet

De nombreuses années d’expérience professionnelle dans le domaine informatique m’ont amené à rencontrer plusieurs problèmes et à réfléchir sur énormément de sujets.

L’un d’eux se porte sur l’environnement de travail : je parle de l’environnement système utilisé pour travailler sur un projet. J’ai relevé quelques éléments intéressants, similaires à des postulats :

on essaie souvent de se rapprocher de l’environnement système de la production : ceci pour repérer assez tôt d’éventuels problèmes
plus l’environnement entre collègues est similaire, mieux nous travaillons : si un collaborateur rencontre un problème il peut se tourner vers le reste de l’équipe pour avoir de l’aide
nous en arrivons souvent à faire un fichier docker-compose.yml pour cela : peut-être est-ce initialement plus facile de partager un fichier léger (docker-compose.yml) qu’une machine virtuelle entière ?
quand on nouveau collaborateur arrive dans l’équipe, il a pas mal de choses à apprendre sur le projet. Et il peine souvent - en plus de toutes les choses à apprendre - à devoir installer l’environnement initial
on utilise souvent un fichier docker-compose.yml très proche entre plusieurs projets : ce qui est normal puisqu’on utilise très souvent des technologies similaires qu’on maîtrise pour les vendre à nos clients
on travaille souvent sur plusieurs tickets, c’est à dire plusieurs problèmes émis par le client. Chaque fois que nous démarrons un nouveau ticket, dans l’idéal, nous devrions avoir un environnement sain et propre pour ne pas avoir de fioritures de nos travaux précédents

En discutant avec Richard Dern (qui a d’ailleurs fait une refonte de son site web avec un nouveau moteur de blog), nous avons réfléchi à un outil capable de résoudre plusieurs de ces problématiques. Le fil rouge était :

les environnements doivent rester isolés : utilisation d’un fichier docker-compose.yml pour générer un environnement
création d’un répertoire unique pour chaque nouveau ticket/projet/autre afin de garder quelque chose de sain et propre
éviter de devoir se répéter entre plusieurs projets : mettre en commun les éléments qui le peuvent, comme par exemple le type de base de données
permettre à plusieurs utilisateurs de travailler sur la même machine : nommage des environnements d’une manière particulière (avec le nom de l’utilisateur par exemple)
permettre à chaque développeur de personnaliser son environnement : par exemple s’il souhaite avoir une interface web pour la base de données, qu’il puisse rajouter l’outil qu’il souhaite
si nous travaillons sur 2 tickets d’un même projet, sachant que l’environnement est similaire pour un même projet, ces deux environnements doivent pouvoir exister en même temps : s’ils utilisent les mêmes ports d’adresses, cela va échouer. Il faut donc des ports aléatoires.
si les ports sont aléatoires, alors il faut un accès facile à chacun des environnements, par exemple à l’aide d’une interface Web commune à tous ces environnements

C’est assez difficile à se l’imaginer sans des explications, une démonstration et/ou quelqu’un qui nous guide pour nous montrer le fonctionnement, alors je vais vous présenter un cas d’usage.

Usage et exemple de Genèse

Imaginons un cas d’usage typique : un client détient une application web (faite avec un framework) qui utilise une base de données MySQL. Appelons cette application : memory_game.

Il est très probable que nous ayons d’autres clients qui utilisent MySQL. Et il est très probable que notre client fera des tickets de bugs que nous aurons à résoudre. Nous aurons probablement plusieurs collaborateurs (pour lesquels nous allons répartir les tickets).

Il utilise un fichier docker-compose.yml avec le contenu suivant :

version: '3'

services:
  php:
    image: toasterlint/php-apache-mysql
    ports:
      - "8888:80"
    volumes:
      - ./:/var/www/html

  db:
    image: mysql
    command: --default-authentication-plugin=mysql_native_password
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: mot2passe
      MYSQL_DATABASE: maBdd
    volumes:
      - ./base_de_donnees:/docker-entrypoint-initdb.d

On comprend donc qu’il y a :

un service (nommé db) pour une base de données MySQL,
un service (nommé php) pour l’application écrite en PHP sur le port 8888.

Avec Genèse, générer un nouvel environnement de développement reviendrait à faire :

# Génère un docker-compose.yml dans le dossier instances/memory_game à partir du profil nommé memory_game
./genese -p memory_game

instances/memory_game est un répertoire de travail :

avec le dépôt de version du projet memory_game,
un fichier docker-compose.yml prévu pour lancer un environnement complet,
et un fichier .env contenant des variables permettant au projet d’être autonome.

Si l’exécutable ./genese venait à disparaître, le dossier reste fonctionnel pour travailler (avec Docker Compose évidemment).

Si on travaille sur plusieurs problèmes en parallèle, on peut vouloir créer un dossier par problème. Imaginons le ticket 42 et le ticket 16 :

# Génère une instance du projet dans le dossier instances/ticket42
./genese -p memory_game -n ticket42
# Même chose avec le dossier instances/ticket16
./genese -p memory_game -n ticket16

Il faut récupérer une branche spéciale du service memory_game ?

# Récupère dans le dépôt Git fourni dans le service memory_game la branche maBrancheSpeciale
BRANCHE_MEMORY_GAME="maBrancheSpeciale" ./genese -p memory_game -n essaiautrebranche

Vous découvrirez dans un prochain article à quel usage je réserve cela 😉

Quelles sont les instances dont je dispose ?

# Liste l'ensemble des instances
./genese -i

Et j’obtiens une liste des dossiers ayant été créés.

Si je veux supprimer une instance spécifique :

# Supprimer l'instance ticket16
./genese -s ticket16

Et si on veut avoir une visualisation des instances lancées, d’accéder à leur détail, éteindre un conteneur, le rallumer, regarder les fichiers de journalisation (logs) ou encore entrer dans un conteneur avec une invite de commande, on peut utiliser l’interface Web Portainer fournie avec Genèse. Cela ressemble à quelque chose comme :

Seriez-vous curieux de savoir comment cela fonctionne (sans entrer dans le technique évidemment !) ?

Comment ça marche ?

Nous allons voir que Genèse s’appuie sur quelques éléments clés comme :

l’instance : version autonome et isolée, située dans le dossier instance,
le service : la description nécessaire pour générer un service, par exemple MySQL,
le profil : contient une liste de services permettant de démarrer une instance.

Prenons l’exemple précédent, nous aurons :

deux services :
- l’un nommé mysql pour la base de données,
- l’autre nommé memory_game pour notre application,
un profil nommé memory_game qui liste les services mysql et memory_game.

Chaque fois que nous lancerons la commande ./genese avec le profil memory_game nous aurons la possibilité de générer une instance avec un nom spécifique.

Comment cela peut-il fonctionner ? Les services ont une structure permettant de décrire :

la partie du fichier docker-compose.yml qui va être utilisée,
la possibilité de donner le dépôt Git utilisé pour récupérer les sources du projet et la branche par défaut à récupérer,
la possibilité de donner un dossier extras permettant de surcharger les sources du projet récupéré (par exemple pour mettre des fichiers de configuration),
la possibilité d’agir à des moments clés de la génération de l’instance via des déclencheurs qui sont des scripts pour :
- procéder à des changements AVANT le lancement des conteneurs Docker, par exemple modifier des fichiers de configuration,
- agir APRÈS le lancement des conteneurs, par exemple pour lancer des commandes dans les conteneurs Docker lancés,
- afficher des informations à la fin du processus de création de l’instance, par exemple pour afficher les ports utilisés par les différents conteneurs

À cela s’ajoute une interface Web (Portainer) permettant de contrôler les instances lancées et accéder à des fonctionnalités particulières de Docker.

La documentation de Genèse devrait se charger bien mieux que moi pour les détails techniques et les possibilités de cet outil.

Conclusion

Malgré l’exemple d’utilisation et quelques détails sur son fonctionnement, Genèse mérite qu’on s’y attarde : nous n’avons gratté que la surface.

Cela ressemble à un framework pour des profils de personnes de type devops afin de leur fournir un outil unique ; à la fois déployer des instances pour les développeurs ; et des instances de type test pour les personnes fonctionnelles.

Je ne sais pas comment suggérer de passer un peu de temps sur l’outil pour comprendre que c’est un bon investissement de temps. Surtout pour des personnes d’un profil DevOps et qui connaissent le scripting Bash. J’espère que la curiosité vous piquera au vif !

Nous nous retrouverons très probablement pour en reparler dans un cadre différent encore.

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 !

Cron sous Docker avec Alpine

Wed, 12 Oct 2022 21:41:39 +0200

Introduction

Chose promie, chose due ! J’écris un article sur mes pérégrinations en informatique.

Cette fois, je fais suite à l’état des lieux 2022 de mon espace numérique. Certains de mes services/sites nécessitent régulièrement d’être mis à jour. Pour cela je souhaite utiliser Cron, un service sous GNU/Linux qui permet de planifier le lancement de script(s) à des fréquences définies.

Comme je souhaite utiliser Docker, je me suis demandé s’il était possible de créer un service dédié avec Cron, Docker et Alpine.

Cet article explique quelques règles que j’ai dû suivre pour y parvenir. Il vous faudra a minima connaître Docker, voire Docker Compose pour comprendre quelque chose. À la rigueur vous connaissez déjà Cron et souhaitez l’utiliser sous Docker.

Nous allons d’abord réflechir sur le sujet. Puis nous utiliserons l’exemple d’un site pour expliquer la solution choisie avant de conclure sur cette histoire.

Pour les pressés, j’ai fais un chapitre « En bref » à la fin de cet article.

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

Réflexion sur le sujet

Ce que nous souhaitons faire, c’est lancer un service, par exemple almanax, et le mettre à jour régulièrement avec une tâche dans le service cron. Je vais expliquer un peu ma réflexion, si vous voulez entrer plus rapidement dans le vif du sujet, rendez-vous au chapitre suivant.

Tout d’abord il faut savoir que l’environnement choisi est Docker. Un système qui permet, à partir d’une image de générer plusieurs conteneurs ayant des points de montage différents pour changer les données qui s’y trouvent.

Docker propose plusieurs bonnes pratiques, parmi lesquelles :

ne lancer qu’un seul processus/service dans chaque conteneur
réutiliser les images ou les parties d’images au maximum pour réduire à la fois la maintenance des images/conteneurs, le travail effectué et la place système utilisée pour les images de base

Sachant que nous ne lançons qu’un seul processus par conteneur Docker, et que je souhaite utiliser Cron, je vais devoir lancer cron dans un autre service. Concrètement, Docker propose Docker Compose qui est un outil permettant de lancer plusieurs services à la fois, avec des dépendances entre eux (si besoin), une description des points de montage, des commandes à lancer sur chaque service, les ports ouverts, etc.

On peut également choisir l’image qu’on souhaite utiliser pour chaque service.

Certes nous allons lancer Cron dans un service à part, pour lancer les scripts que notre autre service a besoin pour mettre à jour ce dernier - je pense notamment à un script qui recompile et reconstitue mes pages webs statiques -, mais nous allons devoir avoir accès à notre service almanax qui contient la logique principale du site.

Pour cela, l’idée est de modifier l’image de almanax pour qu’elle contienne elle aussi cron. Ainsi on pourra lancer la même image sous Docker Compose, avec une commande de lancement différente.

On utilise des services Docker. Chacun ayant déjà leur propre image sous Alpine. Ainsi, chaque image possède déjà Cron inclut dans Alpine.

J’allais dire qu’une image vaut mieux que 1 000 mots, mais là nous allons donner un exemple avec Docker Compose pour comprendre de quoi il s’agit.

Mise en place, exemple avec l’Almanax

Peut-être le savez-vous déjà : j’ai crée une page statique qui liste une quinzaine de quêtes de l’Almanax dans un jeu nommé Dofus.

Cet outil est un de mes services fourni aux utilisateurs, mais également un projet Open Source, dofus-almanax que je fournis via Github. C’est dans ce dépôt Github que vous trouverez la plupart des fichiers nécessaires au bon lancement d’un service Cron que nous allons décrire.

On va étudier le fichier docker-compose.yml suivant :

version: '3'
services:
  generator:
    build: .
    image: dofus-almanax:0.2
    volumes:
      - almanax_public:/opt/almanax/public:rw
      - almanax_data:/opt/almanax/dl:rw
  web:
    image: caddy:2-alpine
    restart: always
    depends_on:
      - generator
    volumes:
      - almanax_public:/usr/share/caddy:ro
      - ${PWD}/Caddyfile:/etc/caddy/Caddyfile
    ports:
      - 8888:80
  cron:
    image: dofus-almanax:0.2
    restart: always
    entrypoint: /usr/sbin/crond
    command: ["-f", "-l", "2", "-L", "/dev/stdout"]
    volumes:
      - almanax_public:/opt/almanax/public:rw
      - almanax_data:/opt/almanax/dl:rw

volumes:
  almanax_public:
  almanax_data:

Nous avons 3 services :

generator : qui génère le site web au lancement, suite à quoi il s’éteint,
web : un service pour mettre à disposition les fichiers statiques générés par generator,
cron : un service pour mettre à jour régulièrement les fichiers statiques.

La particularité de la solution :

generator et cron utilisent la même image : dofus-almanax:0.2
ces deux services n’ont cependant pas la même commande au lancement : l’un prend la commande par défaut de l’image dofus-almanax:0.2, l’autre lance spécifiquement cron
pour le service cron, il spécifie avec le mot clé entrypoint d’utiliser /usr/sbin/crond (chemin absolu du binaire sous Alpine) et donne les paramètres -f -l 2 -L /dev/stdout

Que font les paramètres ?

-f définit de lancer le service en foreground, nécessaire sous Docker, sinon cela ne fonctionne pas
-l 2 définit un niveau de journalisation, habituellement c’est 8 (Cf. une explication des niveaux crond sous Stackoverflow
-L /dev/stdout permet d’avoir une sortie à l’écran dans Docker Compose

Ça, c’est les éléments de base. Cependant comment fonctionne la mise à jour, la configuration de cette dernière, etc.?

Fonctionnement de Cron dans l’image dofus-almanax:0.2

Nous l’avions dit, l’idée est de tout mettre dans l’image dofus-almanax:0.2 (à la fois nos scripts, nos fichiers et crond). Mais comment configurer le service Cron pour lui indiquer la fréquence à laquelle mettre à jour et comment mettre à jour nos fichiers ?

Regardons l’image Docker, écrite sous le fichier Dockerfile suivant :

FROM alpine:3.16

RUN apk update && \
    apk add --no-cache \
        py3-lxml \
	py3-mechanize \
	tzdata && \
    rm -rf /var/cache/apk/*

ENV TZ=Europe/Paris

WORKDIR /opt/almanax

VOLUME /opt/almanax/public
VOLUME /opt/almanax/dl

ENTRYPOINT ["python3", "almanax_next_week.py"]
CMD ["/opt/almanax/public/index.html"]

COPY ./src /opt/almanax
COPY ./crontabs /etc/crontabs/root

RUN chown root:root /etc/crontabs/root && \
    chmod 600 /etc/crontabs/root

COPY ./cron_scripts/generate.sh /opt/generate

Étudions ce fichier dans les grandes lignes concernant le service Cron notamment.

Nous partons d’une image Alpine 3.16 qui contient déjà crond (le service Cron)
Nous installons tzdata qui nous permettra de choisir correctement un fuseau horaire
ENV TZ=Europe/Paris définit notre fuseau horaire, histoire de lancer le script au moment où nous nous y attendons
Le fichier le plus important, cronbtabs est copié vers /etc/crontabs/root, la ligne COPY ./crontabs /etc/crontabs/root est déterminante pour remplacer le fichier du service crond d’Alpine Linux
On copie aussi un script generate.sh dont nous parlerons après
Ce même fichier nécessite des permissions spécifiques, notifiée vers la fin du fichier Dockerfile :

RUN chown root:root /etc/crontabs/root && \
    chmod 600 /etc/crontabs/root

Que contient le fichier crontabs et generate.sh ?

La configuration du service crond

Sous Alpine, le fichier utilisé pour configurer les éléments à lancer par crond est /etc/crontabs/root. Dans le chapitre précédent nous parlions de comment le remplacer, voici désormais son contenu :

5       0       *       *       *       /bin/sh /opt/generate

Nous voyons que nous utilisons effectivement le script generate.sh - qui a d’ailleurs été renommé generate.
Nous utilisons /bin/sh devant notre script :
- c’est un chemin absolu vers le binaire sh
- et nous utilisons sh, pas bash (car bash n’est, à défaut, pas délivré sous Alpine Linux)
Nous utilisons des caractères spécifique, formatés spécifiquement pour dire que nous lançons le service à 00h05 du matin

Pour générer un fichier compatible avec crond, je vous suggère Crontab Generator.

Il va falloir appliquer quelques règles pour être sûr que tout cela fonctionne évidemment.

En bref, les règles à appliquer pour crond

Voici les règles à retenir pour rédiger le fichier que le service crond va étudier :

7 espaces entre chaque élément défini dans le crontab (le fichier se nomme ainsi)
utiliser /bin/sh sous Alpine pour lancer un script, puis le nom de votre script
ne pas mettre de point dans le script qu’on lance (mettre par exemple generate au lieu de generate.sh)
le fichier /etc/crontabs/root doit appartenir à root (root:root) et avoir les permissions 600 (chmod 600)
utilisez -L /dev/stdout sous votre Docker Compose pour avoir une sortie lisible et -l 2 pour plus de logs, mais -l 8 suffit

Ce qui fait déjà pas mal de choses à savoir !

Conclusion

Bien que la réflexion ait été longue (et croyez moi j’ai pris plusieurs jours pour tester au fur et à mesure ce que je souhaitais), nous avons réuni les seules règles à appliquer pour que cela fonctionne, tout en trouvant une solution sympathique qui a plusieurs avantages :

le service Cron accède à tous les fichiers communs de notre service initial
le service Cron accède également à tous les scripts utiles de notre service initial
il suffit de changer le script d’entrée de l’image initiale pour lancer Cron
on a peu de changement à faire pour utiliser Cron finalement !

L’inconvénient reste cependant qu’il faut pouvoir modifier l’image initiale. Si nous n’avions pas la possibilité de faire ça, j’imagine qu’on devrait créer un point de montage commun entre le service initial et le service cron pour accéder à la fois aux fichiers mais aussi aux binaires… ce qui est bien plus complexe/casse-tête !

Liens utiles

Je me suis grandement inspiré, pour mes pérégrinations sur Cron dans Alpine sous Docker par :

Voici Docker, plus léger et plus simple qu'une machine virtuelle

Thu, 03 Apr 2014 13:20:30 +0100

Introduction

Nous parlions précédemment de VirtualBox pour créer des machines virtuelles sur sa machine. C’est une solution pratique qui permet de tester un environnement sans avoir à installer quoique ce soit de plus que VirtualBox sur sa machine et sans perdre de données. Un environnement fermé.

Mais quand il s’agit de lancer plusieurs services sur une machine (un serveur web, un serveur de base de données, une application web, etc.) cela devient tout de suite lourd et consommateur de mémoire vive + espace disque.

Des solutions alternatives existent, comme l’utilisation de LXC qui sont des conteneurs qui utilisent communément le noyau Linux mais fonctionnent à peu de choses prêts comme ce que nous appelons des chroots. Cependant cette solution n’est pas si simple car il faut gérer les conteneurs, leur lancement, etc.

Une solution plus simple, se basant sur les LXC existe : Docker.

Présentation de Docker

Pour en savoir plus sur Docker, il faut se rendre sur la page prévue à cet effet sur le site officiel.

Mais pour vous résumer un peu ce que j’en ai compris :

Docker permet de créer des applications dans un conteneur
Un conteneur est plus léger en terme de taille et en terme de consommation mémoire qu’une machine virtuelle entière
Les conteneurs peuvent être construits à partir d’un simple fichier nommé le Dockerfile
Les conteneurs peuvent être partagés via un dépôt public (Index Docker)
La création d’un conteneur peut se faire via l’utilisation de commit, ce qui permet de versionner les conteneurs
La création d’un conteneur peut se faire via l’héritage d’un autre conteneur

Ainsi :

faire tourner plusieurs conteneurs est plus léger que créer plusieurs machines virtuelles
le versionnement de ses conteneurs permet de redémarrer depuis un précédent commit, de rejouer certaines choses ou améliorer des conteneurs précédents
le Dockerfile est un simple fichier, ce qui permet de partager/déplacer une application contenue dans un conteneur de manière très rapide
plus de soucis avec les collègues au sujet d’un environnement différent d’un développeur à l’autre : tout le monde utilise la même version du conteneur

Vous l’aurez compris, cela n’a que des avantages - quasiment.

Installation et utilisation

Le site de Docker nous apprend comment installer et utiliser Docker en quelques points, mais aussi la page Docker de mon Recueil d’astuces.

Ce que je pense qu’il faut au minimum retenir ce sont les commandes suivantes :

# Créer un nouveau conteneur basé sur Ubuntu
docker run -i -t ubuntu /bin/bash
# Voir les conteneurs lancés
docker ps
# Voir tout les conteneurs crées
docker ps -a
# Voir les images disponibles sur notre machine (à partir desquelles créer de nouveaux conteneurs)
docker images
# Supprimer un conteneur (ID est l'identifiant donné par la commande docker ps -a)
docker rm ID
# Donner un nom à son conteneur (--name). Utile à la place d'utiliser un ID
docker run -i -t --name SuperNom ubuntu /bin/bash

Et évidemment, le plus intéressant est de regarder l’index des fichiers Docker disponibles.

Quelques regrets

En faisant quelques conteneurs Docker, on peut regretter :

le fait qu’il faille utiliser supervisord de manière systématique pour lancer plusieurs services dans un conteneurs.
l’utilisation d’espace partagés ne nous prévient pas qu’on risque d’écraser nos propres données sur la machine hôte
ne fonctionne que sur architecture am64
ne fonctionne que pour Linux (puisque basé sur LXC), donc sous windows il faut utiliser une machine virtuelle avec Ubuntu

Si on se soustrait de ses inconvénients, cela reste un outil intéressant !

Conclusion

Docker est un outil intéressant comparé à la gestion, la création et l’utilisation de conteneurs LXC, c’est une surcouche très attrayante.

J’apprécie qu’on puisse générer un environnement commun à l’ensemble d’une équipe de développeurs afin qu’ils aient toujours les mêmes bibliothèques et outils. En revanche, pour de la production je ne trouve pas cela encore assez au point car réussir à lancer plusieurs services sur un conteneur est vite décourageant et demande pas mal de connaissances !

Mon utilisation de Docker resterait donc du côté développement, afin d’utiliser un fichier simple qui génère un environnement complet de développement et de déploiement local d’un ou plusieurs services. Par exemple pour avoir un serveur OpenERP ou bien un serveur postgreSQL.

Je pense que ça peut-être déployé sur un serveur distant (machine virtuelle ou non) avec plusieurs conteneurs, un par service afin de permettre de déployé/déplacer un service rapidement, sans effort et sans pertes.

Je verrais cela à l’utilisation, et je vous invite à en faire autant !