Déploiement parallèle de RSSHub en production

Ce que cette phase prouve

RSSHub est la première vraie charge applicative du VPS. Il possède un nom HTTPS public, une route réelle fonctionnelle, un contrôle d’accès et une supervision, mais reste un déploiement parallèle car aucun consommateur de production n’a migré :

Canari public
    `-- HTTPS -> Caddy -> infra-edge -> RSSHub du VPS

consommateur de flux existant
    `-- RSSHub local -> production actuelle et solution de repli

Le chemin serveur est donc prouvé avant que la phase 4 ne change le consommateur. Une instance parallèle défaillante peut quitter l’entrée publique sans interrompre le consommateur existant.

Carte des responsabilités

Composant	Responsabilité	Ce qu’il ne fait pas
DNS faisant autorité	Résoudre le sous-domaine RSS vers le VPS	Ne relaie pas le trafic applicatif et ne gère pas les conteneurs
Caddy	Gérer les ports publics 80/443, TLS, les redirections et le proxy	Ne stocke pas l’ACCESS_KEY brute de RSSHub
infra-edge	Fournir un chemin interne entre Caddy et RSSHub et la découverte de service	Ne publie pas le port 1200 sur l’hôte ou Internet
RSSHub	Récupérer les sources, produire RSS et protéger les vraies routes	Ne stocke pas les données du consommateur
Uptime Kuma	Vérifier /healthz publiquement sans clé	Ne contient pas l’ACCESS_KEY et n’expose aucune interface de gestion publique
RSSHub local	Continuer à servir le consommateur actuel	N’est ni arrêté ni supprimé en phase 3

Le chemin public est :

rss.example.com
        |
        v
  Caddy :80/:443
        |
        v
  infra-edge
        |
        v
rsshub-prod:1200

Seul Caddy publie des ports sur les adresses publiques de l’hôte ; Uptime Kuma ne publie TCP 3001 que sur 127.0.0.1, et RSSHub ne publie aucun port sur l’hôte. Le 1200/tcp de RSSHub reste dans Docker ; ni l’adresse publique ni l’adresse Tailscale de l’hôte ne l’accepte directement.

Pourquoi l’architecture reste minimale

La route Bilibili représentative produisait déjà un flux RSS valide contenant au moins un élément sur l’instance locale sans Redis, Browserless ni Chromium. Le VPS démarre donc avec le même minimum :

• image RSSHub officielle épinglée par digest immuable ;
• CACHE_TYPE=memory ;
• aucun Redis ;
• aucun Browserless ou Chromium ;
• aucune base ni volume de données applicatives.

La présence d’un service facultatif dans un exemple amont ne prouve pas qu’un nœud personnel en a besoin. On ne l’ajoute qu’après qu’une route requise a démontré cette dépendance.

Fichiers et frontière des secrets

Le répertoire /srv/rsshub/ n’a besoin que des fichiers suivants :

• compose.yaml pour l’image, le contrôle de santé, le réseau et la politique de redémarrage vérifiables ;
• .env en mode 600, jamais commité ni développé dans les rapports.

Le fichier d’environnement ne contient que les variables nécessaires : une ACCESS_KEY nouvellement générée et la paire UID/cookie exigée par la route Bilibili représentative. Les noms peuvent être documentés ; les valeurs ne doivent jamais entrer dans le chat, Git, le site ou une sortie Compose partagée.

Cet extrait présente l’image, les variables d’environnement, la politique de redémarrage et le raccordement réseau ; il ne constitue pas la configuration complète du déploiement. Le contrôle de santé du conteneur et la configuration Caddy discutés plus bas n’y figurent pas. Ils doivent être configurés avant les vérifications qui attendent running healthy et une réponse publique de /healthz :

services:
  rsshub:
    image: diygod/rsshub@sha256:<immutable-digest>
    restart: unless-stopped
    env_file: [.env]
    environment:
      NODE_ENV: production
      CACHE_TYPE: memory
      DISALLOW_ROBOT: "1"
    networks:
      infra-edge:
        aliases: [rsshub-prod]

networks:
  infra-edge:
    external: true

Il n’y a volontairement aucun ports:, réseau hôte, mode privilégié, socket Docker, base de données ou volume applicatif persistant.

Santé et contrôle d’accès ont des rôles distincts

Les vraies routes RSS exigent une ACCESS_KEY valide et répondent 403 sans elle. La supervision doit rester sans clé pour que Kuma ne conserve aucun identifiant de grande valeur.

Dans l’implémentation du contrôle d’accès de RSSHub citée ici, définir ACCESS_KEY protège aussi /healthz. Le code lié à une route est le condensat MD5 du pathname de la requête suivi de la clé d’accès. Ce déploiement calcule le code de /healthz dans le contrôle de santé du conteneur et transmet ce code dérivé à Caddy plutôt que la clé brute.

GET /healthz                         -> 200, aucune clé fournie par l’appelant
GET /real/rss/route                  -> 403
GET /real/rss/route?key=<valid-key>  -> 200

La santé publique traverse toujours Caddy, infra-edge et RSSHub ; Caddy ne fabrique pas une réponse statique. La valeur du code dérivé n’est pas publiée non plus.

Contrôles courants

Sur le VPS :

[REMOTE: VPS]

cd /srv/rsshub
docker compose ps
docker compose logs --tail 100 rsshub

RSSHUB_ID=$(docker compose ps -q rsshub)
docker inspect "$RSSHUB_ID" \
  --format '{{.State.Status}} {{.State.Health.Status}} {{json .HostConfig.PortBindings}}'

docker network inspect infra-edge

Le résultat accepté est running healthy, une table de liaisons {}, et Caddy avec RSSHub sur infra-edge.

Depuis WSL2 :

[LOCAL: WSL2]

curl --fail https://rss.example.com/healthz
curl -I http://rss.example.com/healthz

# Les deux requêtes doivent expirer ou être refusées ; aucune ne doit renvoyer de contenu RSSHub.
curl --connect-timeout 5 --max-time 7 \
  "http://$VPS_PUBLIC_IPV4:1200/"
curl --connect-timeout 5 --max-time 7 \
  "http://$TAILSCALE_IPV4:1200/"

Une vérification de route réelle ne doit rapporter que le statut, le format du flux, la correspondance d’identité du canal et le nombre d’éléments. Ne collez jamais une URL complète contenant clé, UID privé ou cookie dans un journal ou une note.

Redémarrage contrôlé

La phase 3 ne redémarre pas tout le VPS. Redémarrez uniquement la nouvelle application :

[REMOTE: VPS]

cd /srv/rsshub
docker compose restart rsshub
docker compose ps

Après le retour de la santé, revérifiez la santé publique, le 403 sans authentification, le flux authentifié, Caddy, Kuma, SSH via Tailscale et le blocage du SSH public. Les identifiants et heures de démarrage des conteneurs Caddy et Kuma ne doivent pas changer pendant un redémarrage limité à RSSHub.

Retour arrière

Un déploiement sain n’a pas besoin d’une démonstration destructive. La séquence mécanique est :

1. Restaurer Caddyfile depuis /srv/caddy/Caddyfile.pre-rsshub-p3.
2. Valider toute la configuration Caddy restaurée.
3. Recharger Caddy sans redémarrer son conteneur.
4. Exécuter docker compose -f /srv/rsshub/compose.yaml down.
5. Conserver /srv/rsshub/compose.yaml et le .env protégé.
6. Laisser tourner le RSSHub local ; retirer le DNS plus tard seulement si souhaité.

N’utilisez jamais docker system prune -a, volume prune ou network prune pour ce retour arrière.

Ce qui n’a pas eu lieu

La phase 3 n’a modifié ni l’endpoint du consommateur, ni ses données persistantes, son planificateur ou sa configuration des sources, et n’a pas arrêté RSSHub local. La phase 4 doit traiter ensemble la bascule du consommateur, la sauvegarde et restauration des données persistantes, la migration du planificateur et le retrait du repli.

Mes lectures · Les notes ouvertes sont mémorisées dans ce navigateur.