Hallo zusammen, ich bin neu hier 
Ich betreibe eine Docker-Version von Bitnami Discourse (die neueste) in einem Kubernetes-Cluster, es scheint wirklich ein großartiges Projekt zu sein. Allerdings habe ich ein Problem bei der Automatisierung der Installation eines Themes. Im Wesentlichen muss ich dieses Docker-Image über CI/CD erstellen, bereitstellen, ausführen und konfigurieren, damit beim allerersten Login alles bereit ist. Was die Konfiguration betrifft, so gibt es die Installation eines benutzerdefinierten Themes. Soweit ich das aus verschiedenen Foren und Dokumentationen verstehen konnte, gibt es keine native Möglichkeit, dies programmatisch zu installieren. Ich habe nur eine Schritt-für-Schritt-Anleitung gefunden (korrigieren Sie mich, wenn ich falsch liege).
Meine erste Idee war, die Theme-Dateien über k8s “manuell” in das Discourse-Dateisystem einzufügen, aber wie ich sehe, verwaltet Discourse seine Dateien auf eine seltsame Weise, benennt sie nach seiner eigenen internen Logik um und macht es unmöglich, sie vorherzusagen.
Bei genauerer Betrachtung habe ich dieses großartige CLI namens discourse_theme gefunden. Das Problem hier ist, dass ich trotzdem zuerst einen API-Schlüssel von Discourse generieren müsste, sonst funktioniert es nicht (nochmal… korrigieren Sie mich, wenn ich falsch liege).
Am Ende habe ich ein paar Fragen:
Erstens, gibt es eine andere/native Möglichkeit, ein Theme programmatisch in Discourse zu installieren, die ich übersehen habe?
Und andererseits, gibt es eine Möglichkeit, einen API-Schlüssel von Discourse aus einem Skript zu erhalten?
Und schließlich, kennt jemand einen Kubernetes-Trick, um diese Art von Problem zu umgehen?
Vielen Dank im Voraus
Mit freundlichen Grüßen
Das wird unterstützt, wenn Sie unsere offizielle Installationsmethode verwenden: Install a Theme programatically
Ich denke, die einzige Lösung ist, ein Image zu erstellen, das die gewünschten Plugins enthält, es in ein Docker-Repository zu pushen, es mit den entsprechenden Umgebungsvariablen zu starten und irgendwann festzustellen, dass die Datenbank migriert und die Assets kompiliert und auf S3 hochgeladen wurden (zumindest) beim ersten Ausführen des Images. Möglicherweise möchten Sie einmal mit SKIP_POST_DEPLOYMENT_MIGRATIONS migrieren, während das alte Image ausgeführt wird, und dann erneut, nachdem das neue Image gestartet wurde und die alten heruntergefahren wurden, mit SKIP_POST_DEPLOYMENT_MIGRATIONS deaktiviert oder die db:ensure_post_migrations Rake-Aufgabe ausführen.
Sie können eine Rake-Aufgabe in einem Ihrer laufenden Images ausführen, etwas wie
rake api_key:create_master[‘Beschreibung des Schlüssels’]
Das Obige könnte ausreichen, um Sie ein wenig weiter zu bringen. Ich habe in der Vergangenheit Kubernetes-Instanzen für Kunden auf GCP und AWS betrieben. Ich war nie zu 100 % zufrieden damit, wie es funktionierte (es funktionierte perfekt aus der Sicht des Kunden, es war nur aus meiner Sicht nicht sehr elegant, aber es war auch nicht so unansehnlich, dass es sich gelohnt hätte, es zu beheben!). Ich habe hier nicht viel mehr anzubieten, aber Sie können mich gerne direkt kontaktieren, wenn Sie weitere Hilfe benötigen.