Discourse-Rebuild während des Bootstraps fehlgeschlagen: Git-HTTPS-Timeout, Suche nach einer sauberen SSH-basierten Lösung

Unterstützung
1

Hallo,

ich betreibe eine Standard-Installation von Discourse auf Ubuntu im Self-Hosted-Modus mit dem offiziellen discourse_docker-Setup.

Umgebung

  • Ubuntu Server
  • Docker
  • Offizielles discourse_docker
  • Installation mit einem einzigen Container (app.yml)
  • Neuaufbau durchgeführt mit:
cd /var/discourse
./launcher rebuild app

Problem

Der Neuaufbau schlägt während der Bootstrap-Phase fehl, wenn Discourse versucht, die Anwendungsquelle von GitHub zu aktualisieren.

Der Fehler tritt auf bei:

git fetch --tags --prune-tags --prune --force origin

und führt zu:

fatal: unable to access 'https://github.com/discourse/discourse.git/': SSL connection timeout

gefolgt von:

FAILED
bootstrap failed with exit code 128

Wichtige Erkenntnisse

GitHub ist über HTTPS erreichbar

Auf dem Host:

curl -I https://github.com

funktioniert einwandfrei.

Ebenso:

curl -I https://raw.githubusercontent.com

funktioniert ebenfalls.

Git über HTTPS ist in meiner Umgebung unzuverlässig

Innerhalb der Discourse-Umgebung:

git ls-remote https://github.com/discourse/discourse.git

schlägt fehl mit:

SSL connection timeout

Meinen Untersuchungen zufolge liegt dies an Verbindungsproblemen meines Internetanbieters zu GitHub über HTTPS. Derzeit versuche ich nicht, dieses Netzwerkproblem selbst zu lösen. Stattdessen suche ich nach einer Möglichkeit, Discourse-Neuaufbauten über SSH durchzuführen, da die SSH-Verbindung zu GitHub in meiner Umgebung einwandfrei funktioniert.

GitHub-SSH-Authentifizierung funktioniert

Ich habe einen neuen SSH-Schlüssel generiert, zu GitHub hinzugefügt und die Authentifizierung überprüft:

ssh -T git@github.com

liefert:

Hi <username>! You've successfully authenticated, but GitHub does not provide shell access.

Ebenso:

git ls-remote git@github.com:discourse/discourse.git

funktioniert vom Host aus erfolgreich.

Repository-URLs

Auf dem Host habe ich /var/discourse so geändert, dass es SSH verwendet:

origin git@github.com:discourse/discourse_docker.git

und Git-Operationen funktionieren.

Innerhalb des Discourse-Anwendungscontainers zeigt jedoch:

cd /var/www/discourse
git remote -v

folgendes an:

origin https://github.com/discourse/discourse.git

Während des Bootstraps versucht Discourse daher weiterhin, HTTPS zu verwenden.

Was ich erreichen möchte

Mein Hauptziel ist es, Discourse-Neuaufbauten in einer Umgebung zuverlässig durchzuführen, in der HTTPS-Verbindungen zu GitHub instabil sind oder häufig timeouten.

Ich möchte Folgendes wissen:

  1. Gibt es eine offiziell unterstützte Möglichkeit, dass Discourse-Bootstrap und -Neuaufbau GitHub über SSH statt über HTTPS verwenden?
  2. Wenn nein, was ist der empfohlene Ansatz für Umgebungen, in denen Git über HTTPS unzuverlässig ist, SSH aber einwandfrei funktioniert?
  3. Gibt es eine unterstützte Methode, SSH-Anmeldedaten in die Bootstrap-/Build-Phase einzuspeisen?
  4. Hat jemand discourse_docker erfolgreich so konfiguriert, dass Discourse-Quellaktualisierungen über SSH abgerufen werden?

Ich bevorzuge eine Lösung, die auch bei zukünftigen Upgrades bestehen bleibt, interessiere mich aber auch dafür, ob das Abrufen über SSH während des Bootstraps technisch unterstützt wird.

Jeder Hinweis wäre sehr willkommen.

Vielen Dank.

2

Wird ausgehende HTTPS-Verbindung irgendwie blockiert?

Es wird nicht einfach sein, alle Teile, die HTTPS erwarten, umzuschreiben. Ich befürchte, dass Sie zuverlässige Netzwerkverbindungen herstellen müssen, um das Problem zu lösen.

3

Danke für die Klarstellung, Jay.

Nach weiteren Diagnosemaßnahmen scheint der ausgehende HTTPS-Verkehr auf dem Host selbst nicht blockiert zu werden — direkte curl-Anfragen an GitHub und raw.githubusercontent.com funktionieren konsistent. Das Problem tritt nur innerhalb des Bootstrap-Containers auf, wo git ls-remote über HTTPS intermittierend SSL-Timeouts auslöst. Der SSH-basierte Zugriff auf GitHub bleibt vollständig zuverlässig, weshalb ich anfangs geprüft habe, ob ein sauberer SSH-Pfad während des Bootstrap-Vorgangs praktikabel wäre.

Dein Einwand, dass es schwierig ist, alle Komponenten umzuschreiben, die HTTPS voraussetzen, ist gut nachvollziehbar. Da die HTTPS-Ausfälle mit Instabilitäten in der Route meines ISPs zu GitHub zusammenhängen und nicht mit einer lokalen Firewall oder Docker-Netzwerkproblemen, werde ich mich darauf konzentrieren, den Upstream-Netzwerkpfad zu stabilisieren, anstatt den Bootstrap-Prozess zu ändern.

Nochmals vielen Dank für die Anleitung und die Klärung der Einschränkungen bezüglich der HTTPS-Nutzung in der Build-Pipeline.

4

Ich glaube, es gibt eine Möglichkeit, einen Proxy anzugeben, sodass du vielleicht einen Proxy nutzen kannst, der deinen ISP-Netzwerkverkehr umgeht. Es scheint einfacher, einen anderen ISP zu finden, aber das Leben ist oft nicht so einfach, wie wir es uns wünschen.