Dépannage des téléchargements S3 : le site se bloque après la reconstruction, les actifs JS ne se chargent pas avec net::ERR_... sur R2 et GCS

Bonjour à l’équipe et à la communauté Discourse,

J’essaie de configurer mon instance Discourse auto-hébergée pour utiliser un stockage d’objets externe compatible S3, mais j’ai rencontré un problème très persistant et inhabituel. Je serais très reconnaissant pour toute aide.

Mon environnement :

  • Version de Discourse : Installation Docker standard, dernière version tests-passed.

  • Hôte : [VOTRE FOURNISSEUR VPS et OS] (Veuillez remplir ici votre fournisseur et votre système)

  • Proxy inverse : Caddy

Objectif : Mon objectif est de déplacer tous les téléchargements (téléchargements d’utilisateurs et actifs du site) du stockage local vers un fournisseur externe.

Résumé du problème : Après avoir configuré app.yml pour S3 (soit Cloudflare R2, soit Google Cloud Storage) et exécuté ./launcher rebuild app, le site reste bloqué sur l’écran de chargement initial (le spinner bleu). Les outils de développement du navigateur montrent que la plupart des actifs JavaScript principaux ne parviennent pas à se charger depuis l’URL CDN externe avec une erreur réseau générique (net::ERR_...).

Étapes de débogage effectuées :

  1. Tentative avec Cloudflare R2 :

    • J’ai configuré un bucket Cloudflare R2, créé un jeton API (Lecture et Écriture d’objets) et connecté un domaine personnalisé (s3.ryzelan.sbs) via Cloudflare DNS.
    • J’ai configuré app.yml avec les identifiants R2, le domaine personnalisé comme point de terminaison/URL CDN, et j’ai défini DISCOURSE_FORCE_HTTPS: true et DISCOURSE_S3_FORCE_PATH_STYLE: true.
  2. Test crucial - Passage à Google Cloud Storage :

    • Pour écarter un problème spécifique à Cloudflare, j’ai annulé toutes les modifications et effectué une nouvelle configuration avec Google Cloud Storage en utilisant des clés d’interopérabilité S3.
    • Après la reconstruction avec la configuration GCS, j’ai rencontré le même schéma d’échec de chargement JavaScript qu’avec R2.

État actuel :

  • Le processus ./launcher rebuild app se termine sans aucune erreur affichée dans le terminal.
  • Le conteneur app s’exécute correctement après la reconstruction (vérifié avec docker ps).
  • La commande ./launcher logs app ne montre aucune erreur ; tous les services internes (unicorn, redis, postgres) semblent fonctionner normalement.
  • Le problème semble être un échec au niveau réseau lorsque le navigateur tente de récupérer les actifs JS depuis l’URL CDN externe configurée, et cela se produit quel que soit le fournisseur (R2 ou GCS) utilisé.

Voici le bloc de configuration final app.yml que nous avons utilisé pour R2 (celui de GCS était similaire) :

# — Configuration S3 Cloudflare R2 DÉBUT (Version finale) —

DISCOURSE_FORCE_HTTPS: true
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: “us-east-1”
DISCOURSE_S3_ENDPOINT: “https://s3.ryzelan.sbs
DISCOURSE_S3_CDN_URL: “https://s3.ryzelan.sbs
DISCOURSE_S3_ACCESS_KEY_ID: “REDACTED”
DISCOURSE_S3_SECRET_ACCESS_KEY: “REDACTED”
DISCOURSE_S3_BUCKET: “ryzelan-discourse”
DISCOURSE_S3_FORCE_PATH_STYLE: true

# — Configuration S3 Cloudflare R2 FIN —

Ma question : Qu’est-ce qui pourrait causer une reconstruction Discourse fraîche à échouer systématiquement à charger ses propres actifs à partir de deux fournisseurs cloud majeurs et différents avec une erreur réseau ? Existe-t-il un problème connu avec certains environnements réseau VPS, le réseau Docker ou Caddy qui pourrait en être la cause ?

Merci de votre temps et de vos éclaircissements.

Avez-vous inclus le code pour téléverser ces ressources sur S3 ?

Si vous ne le faites pas, aucune des ressources ne sera sur S3 et le site ne se chargera pas.

@Ryze_Chen avez-vous pu résoudre votre problème ?

Ce sujet a été automatiquement fermé 7 jours après la dernière réponse. De nouvelles réponses ne sont plus autorisées.