Ich versuche, Discourse für meine Organisation auf Kubernetes einzurichten. Allerdings habe ich einige Probleme.
Wenn ich das gebootete Image auf Kubernetes bereitstelle, versucht es Dinge wie git pull pups und git pull discourse auszuführen, was nicht funktioniert, da ich in einem privaten Netzwerk ohne Internetzugang bin. Als Ergebnis startet der Container nicht. Gibt es eine Möglichkeit, diese Teile zu überspringen, damit ich bereitstellen kann?
Bist du sicher, dass du ein bereits gebootetes Image bereitstellst? Es klingt so, als hättest du das falsche Image in deine Registry gepusht.
Ach ja, ich verwende das Bild, das mit ./launcher bootstrap app erstellt wurde.
Meinen Sie also, dass das final gebootete Bild keine derartigen Abhängigkeiten haben sollte?
Nein, das wird es nicht. Nach dem Bootstrapping gibt es ein Image namens local_discourse/app. Das ist das Image, das du in die Registry hochladen und andernorts verwenden musst.
Eine letzte Frage: Es scheint, als hätte ich das falsche Image gepusht – mein Fehler. Kann ich also nach dem Pushen des tatsächlichen Images die Umgebungsvariablen während der K8s-Bereitstellung ändern? Zum Beispiel DISCOURSE_DB_HOST usw.? Denn ich habe einen separaten PostgreSQL-Cluster und einen separaten Redis-Cluster!
Das kennen wir alle. Keine Sorge, das ist ein sehr häufiger Fehler. Deshalb habe ich nachgefragt 
Nun, das ist kompliziert.
Zwar kannst du diese Werte leicht überschreiben, indem du die entsprechenden ENV-Variablen beim Start des Containers hinzufügst, aber während des Bootstrapping-Prozesses führen wir Migrationen durch. Wenn du versuchst, das Image nach dem Bootstrapping auf eine andere Datenbank zu verweisen, wird das Datenbankschema völlig falsch sein. Damit würdest du dich eindeutig in das Gebiet der unsupported-install begeben.
Ich habe bereits eine Discourse-Instanz, die auf Bare Metal läuft. Ich möchte sie nach Kubernetes migrieren und dabei dieselbe Datenbank verwenden, die die Bare-Metal-Instanz genutzt hat.
Oder kann ich, falls möglich, den Bootstrap-Vorgang erneut ausführen, wobei DISCOURSE_DB_HOST und DISCOURSE_DB_NAME auf dieselbe Datenbank zeigen, die die Bare-Metal-Instanz verwendet?
Das sollte funktionieren!
Du solltest den aktuellen Discourse-Container, der mit der Datenbank verbunden ist, währenddessen stoppen, da Migrationen dazu führen können, dass er sich fehlerhaft verhält.
Wenn ich eine frische, leere Datenbank erstelle und damit starte, ist es dann möglich, die Daten über die Benutzeroberfläche zu migrieren (mithilfe der UI der alten Discourse-Instanz und der neuen Discourse-Instanz), z. B. über /admin/backups? Ich möchte vermeiden, die alte Datenbank zu beschädigen, da sie von vielen Nutzern verwendet wird.
Sie können nicht von der UX migrieren.
Siehe Einführung der Migration nach dem Deployment. Dies ermöglicht es Ihnen, die Datenbank so zu migrieren, dass sie sowohl für den alten als auch für den neuen Container funktioniert, und dann nach dem Deployment die endgültigen Migrationen durchzuführen.
Nun, ich habe versucht, was du gesagt hast (das gebootete Image gepusht), aber es scheint, als würde ich immer noch denselben Fehler erhalten.
fatal: unable to access 'https://github.com/discourse/pups.git/': Failed to connect to github.com port 443: Connection timed out
Ich befinde mich in einem privaten Netzwerk und kann daher nicht auf github.com zugreifen.
@pfaffman @Falco Ist das zu erwarten? Ich führe dies in k8s aus.
Das bedeutet, du hast wieder das falsche Image gepusht.
Ich würde die interne Datei /etc/hosts so anpassen, dass sie die gewünschten Ressourcen nachahmt … und dann das Erforderliche hinzufügen.
Noch einfacher: Schließen Sie ein Modem/Router mit 4G-/SIM-Karten-Verbindung an. Lassen Sie das Netzwerk dieses Gerät als Standardrouter für Ihr internes Netzwerk erkennen … verbinden … arbeiten … trennen.
Es ist ziemlich einfach.
Viele Grüße
Keith John Hutchison - Ceiteach Seán Mac Úistin
Bringing Data to Life Pty. Ltd. (BD2L)
Dieses Mal bin ich mir ziemlich sicher 
Gibt es eine Möglichkeit, dass während ./launcher bootstrap app ein Fehler auftritt?
Außerdem habe ich sogar das aktuelle Discourse-Image ausprobiert, das auf Bare Metal läuft und unsere aktuelle Discourse-Website hostet, und dieses auf Kubernetes verwendet. Auch das schlägt mit demselben Fehler wie oben fehl.
Selbst auf meinem lokalen Rechner erhalte ich den oben genannten Fehler, wenn ich
docker run local_discourse/app
ohne Internetverbindung ausführe.