Fehlerbehebung bei S3-Uploads: Seite hängt nach dem Neubau, JS-Assets werden mit net::ERR_... auf R2 und GCS nicht geladen

[Ryze_Chen]

Hallo Discourse Team und Community,

Ich versuche, meine selbst gehostete Discourse-Instanz so zu konfigurieren, dass sie externen S3-kompatiblen Objektspeicher verwendet, bin aber auf ein sehr hartnäckiges und ungewöhnliches Problem gestoßen. Ich wäre für jede Hilfe sehr dankbar.

Meine Umgebung:

• Discourse-Version: Standard-Docker-Installation, neueste tests-passed.

• Host: [IHR VPS-ANBIETER und Betriebssystem] (Bitte geben Sie hier Ihren Anbieter und Ihr System ein)

• Reverse Proxy: Caddy

Ziel: Mein Ziel ist es, alle Uploads (Benutzer-Uploads und Website-Assets) vom lokalen Speicher auf einen externen Anbieter zu verschieben.

Problemzusammenfassung: Nach der Konfiguration von app.yml für S3 (entweder Cloudflare R2 oder Google Cloud Storage) und dem Ausführen von ./launcher rebuild app hängt sich die Website beim anfänglichen Ladebildschirm (dem blauen Spinner) auf. Die Entwicklertools des Browsers zeigen, dass die meisten Kern-JavaScript-Assets nicht von der externen CDN-URL geladen werden können und einen generischen Netzwerkfehler (net::ERR_...) verursachen.

Ergriffene Debugging-Schritte:

1. Versuch mit Cloudflare R2:

   • Ich habe einen Cloudflare R2-Bucket konfiguriert, ein API-Token (Object Read & Write) erstellt und eine benutzerdefinierte Domain (s3.ryzelan.sbs) über Cloudflare DNS verbunden.
   • Ich habe app.yml mit den R2-Anmeldeinformationen, der benutzerdefinierten Domain als Endpunkt/CDN-URL konfiguriert und DISCOURSE_FORCE_HTTPS: true sowie DISCOURSE_S3_FORCE_PATH_STYLE: true gesetzt.

2. Entscheidender Test – Wechsel zu Google Cloud Storage:

   • Um ein Cloudflare-spezifisches Problem auszuschließen, habe ich alle Änderungen rückgängig gemacht und eine neue Einrichtung mit Google Cloud Storage unter Verwendung von S3-Interoperabilitätsschlüsseln vorgenommen.
   • Nach dem Wiederaufbau mit der GCS-Konfiguration trat das exakt gleiche JavaScript-Ladefehler-Muster wie bei R2 auf.

Aktueller Status:

• Der Prozess ./launcher rebuild app wird ohne angezeigte Fehler im Terminal abgeschlossen.
• Der app-Container läuft nach dem Wiederaufbau korrekt (verifiziert mit docker ps).
• Der Befehl ./launcher logs app zeigt keine Fehler an; alle internen Dienste (Unicorn, Redis, PostgreSQL) scheinen normal zu laufen.
• Das Problem scheint ein Netzwerkfehler auf Netzwerkebene zu sein, wenn der Browser versucht, JS-Assets von der konfigurierten externen CDN-URL abzurufen, und dies geschieht unabhängig davon, welcher Anbieter (R2 oder GCS) verwendet wird.

Hier ist der finale app.yml-Konfigurationsblock, den wir für R2 verwendet haben (der für GCS war ähnlich):

— Cloudflare R2 S3 Konfiguration START (Endgültige Version) —

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

— Cloudflare R2 S3 Konfiguration ENDE —

Meine Frage: Was könnte dazu führen, dass ein frischer Discourse-Wiederaufbau seine eigenen Assets von zwei verschiedenen, großen Cloud-Anbietern mit einem Netzwerkfehler konsistent nicht laden kann? Gibt es bekannte Probleme mit bestimmten VPS-Netzwerkumgebungen, Docker-Netzwerken oder Caddy, die dies verursachen könnten?

Vielen Dank für Ihre Zeit und alle Einblicke, die Sie geben können.

[pfaffman (Jay Pfaffman)]

@Ryze_Chen

Die Seite hängt beim anfänglichen Ladebildschirm (der blaue Spinner).

Haben Sie den Teil zum Hochladen dieser Assets nach S3 einbezogen?

@Discourse

Um Discourse-Statik-Assets in Ihrem Objektspeicher zu speichern, fügen Sie diese Konfiguration in Ihrer app.yml unter dem Abschnitt hooks hinzu:

  after_assets_precompile:
    - exec:
        cd: $home
        cmd:
          - sudo -E -u discourse bundle exec rake s3:upload_assets
          - sudo -E -u discourse bundle exec rake s3:expire_missing_assets

Wenn Sie das nicht tun, sind keine der Assets auf S3 und die Seite wird nicht geladen.

[tobiaseigen]

@Ryze_Chen konnten Sie Ihr Problem lösen?