Comment garder les configurations de site à jour dans Wallabag dans Docker

Voilà plusieurs années que je n’arrive pas à choisir comment gérer mes articles à lire plus tard. J’ai tout d’abord utilisé Instapaper, avant de l’abandonner. Puis Pocket, ou encore la liste de lecture de mon navigateur.

Depuis quelques mois, je bricole un truc avec Obsidian et une extension dédiée. Mais même si cela est assez pratique, je considère Obsidian comme un outil de capture, pas comme un outil de rattrapage de lecture.

J’ai donc sauté le pas et installé Wallabag dans un conteneur Docker. Bilan : j’aurais dû le faire plus tôt. :)

Mais je suis trouvé face à un petit souci, comme expliqué dans la documentation :

Wallabag only updates its config files as part of releases for the wallabag package. However, since these config files originate from another project, they can also be loaded from the original repo into a separate folder and automatically kept up to date there.

Concrètement, Wallabag utilise une collection de fichiers de configuration spécifiques pour une poignée de site, afin d’en récupérer proprement le contenu. Ces fichiers sont stockés dans le conteneur dans /var/www/wallabag/vendor/j0k3r/graby-site-config/ et ne sont mis à jour que lorsque Wallabag est mis à jour.

Pour autant, les configurations sont régulièrement mises à jour dans le dépôt https://github.com/fivefilters/ftr-site-config.

La documentation propose alors une solution adaptée à une instance auto-hébergée de Wallabag… mais sans Docker.

J’ai donc bricolé un moment pour adapter tout ça à ma situation.

1. Créer les dossiers

On commence par créer un dossier dans la machine hôte qui contiendra à la fois les fichiers de configuration par site, mais également un fichier de configuration de Wallabag. On peut créer ses dossiers où on le souhaite, pour ma part c’est ici :

cd ~
mkdir -p data/wallabag/config

2. Cloner le repo des configurations par site

On va ensuite cloner les fichiers. La commande va créer un sous-dossier wallabag/ftr-site-config qui les contiendra :

cd data/wallabag
sudo git clone https://github.com/fivefilters/ftr-site-config

3. Ajouter 2 volumes au conteneur

Ici, nous allons ajouter 2 montages de type bind. Pour ma part, le conteneur existe déjà, donc je l’ai simplement relancé avec les nouvelles options. Depuis un docker-compose.yml, ça donne ceci (attention, ce n’est pas le fichier complet, j’ai uniquement repris le début):

version: '3'
services:
  wallabag:
    image: wallabag/wallabag
    environment:
      - MYSQL_ROOT_PASSWORD=wallaroot
      - SYMFONY__ENV__DATABASE_DRIVER=pdo_mysql
      - SYMFONY__ENV__DATABASE_HOST=db
      - SYMFONY__ENV__DATABASE_PORT=3306
      - SYMFONY__ENV__DATABASE_NAME=wallabag
      - SYMFONY__ENV__DATABASE_USER=wallabag
      - SYMFONY__ENV__DATABASE_PASSWORD=my_password
      - SYMFONY__ENV__DATABASE_CHARSET=utf8mb4
      - SYMFONY__ENV__DATABASE_TABLE_PREFIX="wallabag_"
      - SYMFONY__ENV__MAILER_DSN=smtp://127.0.0.1
      - SYMFONY__ENV__FROM_EMAIL=my@email.fr
      - SYMFONY__ENV__DOMAIN_NAME=https://my.domain.fr
      - SYMFONY__ENV__SERVER_NAME="My Wallabag's Name"
    ports:
      - 80:80
    volumes:
      - wallabag-images:/var/www/wallabag/web/assets/images
      - ./ftr-site-config:/var/www/ftr-site-config # ici
      - ./config/services.yml:/var/www/wallabag/app/config/services.yml # ici
[…]

Le fichier docker-compose est placé dans ~/data/wallabag, donc le premier bind lie le sous-dossier ftr-site-config/ au dossier /var/www/ftr-site-config/.

Le second bind permet de monter le fichier de configuration /var/www/wallabag/app/config/services.yml dans config/services.yml sur l’hôte

4. Modifier les droits

Lorsqu’on a cloné le repo dans ftr-site-config/, le dossier et les fichiers ont pour propriétaire root:root, ce qui ne nous arrange pas. Dans le conteneur Wallabag, tous les fichiers et dossiers appartiennent à nobody:nobody.

Nous allons donc modifier les droits dans le host pour qu’ils soient identiques, en lançant cette commande depuis wallabag/ : sudo chown -R 65534:65534 ftr-site-config/

5. Gérer un avertissement de git

Si j’ouvre le dossier ftr-site-config/ et que je lance git pull (ou même sudo git pull), j’obtiens une erreur. Le changement de propriétaire ne plait pas à git et il faut déclarer le dossier comme sûr. Cette configuration sera inscrite dans les paramètres généraux de git pour l’utilisateur. Nous allons le faire pour root, cela nous servira à l’étape 6. Il suffit de lancer : sudo git config --global --add safe.directory /home/user/data/wallabag/ftr-site-config

La commande va ajouter le contenu ci-dessous dans le fichier /root/.gitconfig:

[safe]
        directory = /home/user/data/wallabag/ftr-site-config

6. Gérer la synchronisation du repo

Nous allons mettre en place une commande via cron, qui sera exécutée par root (bien remplacer /user dans le chemin ici aussi) :

# Éditer la cron de root
sudo crontab -e

# Ajouter cette ligne
0 22 * * * cd /home/user/data/wallabag/ftr-site-config && git pull && chown -R 65534:65534 .

Explication :

• 0 22 * * * : les commandes seront exécutées chaque jour à 22h. Vous pouvez modifier à votre convenance pour un autre horaire, ou une mise à jour plus fréquente
• cd /home/user/data/wallabag/ftr-site-config : ouvre le dossier du repo
• git pull : récupère les mises à jour du repo dans le dossier local. Les dossiers et fichiers appartiennent alors à nouveau à root:root
• chown -R 65534:65534 . : change le propriétaire de tous les fichiers dans le dossier courant pour les attribuer à nouveau à nobody

Comme c’est root qui va exécuter la commande, c’est la configuration /root/.gitconfig créée à l’étape 5 qui va servir.

7. Lancer le conteneur

Que ce soit via docker-compose, ou depuis un outil comme portainer, il faut relancer le conteneur avec la nouvelle configuration des volumes.

8. Éditer la configuration

Il faut maintenant indiquer à Wallabag qu’il doit charger les fichiers de configuration des sites depuis /var/www/ftr-site-config au lieu du dossier par défaut. Pour cela, il faut éditer le fichier avec sudo nano wallabag/config/services.yml et le modifier ainsi :

# Trouver cette section
Graby\SiteConfig\ConfigBuilder:
arguments:
   $config: {}
   
 # Remplacer par ceci
 Graby\SiteConfig\ConfigBuilder:
arguments:
   $config: { site_config: ['/var/www/ftr-site-config']}

9. Purger le cache

Wallabag ne prendra pas immédiatement en compte la modification. Pour forcer, nous allons purger le cache depuis l’hôte : sudo docker exec --user nobody <conteneur> php bin/console --env=prod cache:clear

Bonus

Lors de mes essais, j’ai commencé par récupérer le contenu du services.yml du conteneur pour recréer manuellement le même fichier dans l’hôte, avant de faire le bind dessus.

Je ne suis pas certain que ce soit nécessaire, mais, si besoin, voilà la commande à utiliser depuis l’hôte. Cela va créer un fichier identique dans le répertoire courant : sudo docker exec <nom du conteneur> cat /var/www/wallabag/app/config/services.yml > ./services.yml

Ce n’est pas très propre, mais ça fonctionne :

• Les configurations des sites sont mises à jour toutes les 24h depuis le repo et disponibles dans le conteneur
• La modification dans le fichier services.yml est gérée de façon à survivre à une mise à jour de Wallabag.