FreshRSS — rss.opytex.org
Agrégateur RSS, PostgreSQL dédié, authentification SSO via Authentik.
Déploiement
Depuis ce dossier, sur chioggia :
sops exec-env secrets.env.yaml 'docker compose up -d'
Le nom du dossier (rss.opytex.org) donne le nom de projet Compose
rssopytexorg, dont dérivent les noms de volumes
(rssopytexorg_freshrss_data, …) et le nom du dump de base
(rssopytexorg.sql.gz). Renommer ce dossier ferait repartir la stack sur
des volumes vides.
Après une rotation de secret, docker compose up -d répond « up to date » et
garde l'ancienne valeur :
sops exec-env secrets.env.yaml 'docker compose up -d --force-recreate'
Volumes
| Volume | Contenu | Sauvegarde |
|---|---|---|
rssopytexorg_pgsql_data |
base PostgreSQL | dump SQL (backup.type=postgres sur le conteneur) |
rssopytexorg_freshrss_data |
config, comptes, articles locaux | label backup.enable=true sur le volume |
rssopytexorg_freshrss_extensions |
extensions installées | label backup.enable=true sur le volume |
Les deux volumes FreshRSS portent backup.enable=true depuis leur
création : le label est donc conservé dans le compose. Le retirer, comme
l'ajouter à un volume qui ne l'a pas, ferait diverger la déclaration du volume
réel — Compose proposerait alors de le recréer, donc de vider FreshRSS.
Ils figurent en plus dans MANUAL_VOLUMES (backup.conf), ce qui les fait
sauvegarder deux fois : le script empile les chemins de MANUAL_VOLUMES puis
ceux des volumes labellisés, sans dédoublonner. Redondance héritée de l'ancien
dépôt, sans conséquence (restic déduplique) — à nettoyer quand backup.conf
sera migré dans ops/backup/.
pgsql_data n'a délibérément aucun label : sauvegarder les fichiers d'un
PostgreSQL en cours d'écriture ne donne pas une base restaurable, c'est le dump
SQL qui le couvre.
Références :