Hallo Team,
ich führe Discourse auf AWS ECS aus. Beim Versuch, die Anwendung auszuführen, schlägt der Konsolen-Tab im Browser mit den unten aufgeführten URLs fehl. Habe ich eine Konfigurationsänderung übersehen?
Gemischte Inhalte: Die Seite unter „https://discuss-stage.tllms.com/finish-installation/register
Es sieht nach einer Fehlkonfiguration Ihres S3-Buckets aus.
Wie haben Sie Discourse installiert? Haben Sie die offizielle Standardinstallation von Discourse verwendet oder vielleicht Fehlerbehebung bei Bitnami-Installationen?
Ich setze mein Geld auf eine falsch konfigurierte CDN.
Kannst du deine config/discourse.conf teilen?
Und suche in deinen Site-Einstellungen nach c0fbtc und schaue, ob Treffer dabei herauskommen.
Hallo Jay,
ich habe es als normale Rails-Anwendung installiert. Hier sind die Schritte, die ich befolgt habe:
Ich habe das vorgefertigte Docker-Image nicht verwendet. Ich habe das Docker-Image selbst erstellt.
Konfigurationsdatei löschen
Das scheint nicht richtig zu sein. An deiner Stelle würde ich prüfen, ob meine Datenbank tatsächlich lokal ist und einen seltsamen Namen hat.
Ich denke, es sollte so aussehen:
# Host-Adresse für den DB-Server
# Dies ist leer gesetzt, damit zuerst Sockets verwendet werden
db_host = discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com
# Datenbankname, auf dem Discourse läuft
db_name = default
Wofür wird S3 verwendet? Und muss ich zusätzlich eine separate discourse.conf-Datei erstellen, ohne etwas in der discourse_defaults.conf-Datei zu ändern?
Das hat nichts mit S3 zu tun.
Die Datei discourse.conf wird aus deiner app.yml generiert. Du solltest Änderungen dort vornehmen und das System neu aufbauen.
Richard
Ich habe Discourse von GitHub - discourse/discourse: A platform for community discussion. Free, open, simple. · GitHub geklont. Ich konnte die app.yml-Datei nirgendwo im Repository finden.
Die gesamte Diskurs-Konfiguration verweist auf discourse_docker, das ich nicht verwenden möchte. Ich möchte meinen eigenen Container erstellen.
(Ich muss dich davor warnen, ein bereits perfekt funktionierendes Rad neu zu erfinden. Außerdem werden einige Leute hier nicht sehr begeistert davon sein, dich zu unterstützen, da dies der Community keinen Nutzen bringt).
Was auch immer du tust, du solltest sicherstellen, dass diese Werte am Ende korrekt in deiner discourse.conf landen. Wenn du sie manuell bearbeitet hast, solltest du zumindest den AWS-Hostnamen in db_host eintragen und db_name auf default belassen.
Hallo Richard,
ich arbeite im selben Team wie Vijay. Der konkrete Anwendungsfall, den wir hier adressieren möchten, besteht darin, Discourse zu forken und in unserem GitHub-Repository der Firma unterzubringen. Von dort aus bauen und deployen wir dann auf AWS. Der Grund, warum wir es in unserem GitHub haben möchten, ist, die Flexibilität zu behalten, Änderungen entsprechend unseren Anforderungen vorzunehmen. Wir würden gerne, wo immer möglich, Beiträge zurückgeben. Da wir in dem öffentlichen Discourse-Repository keine Dockerfile finden konnten, haben wir am Ende eine eigene erstellt, um das Docker-Image zu bauen. Außerdem nutzen wir GitHub Actions, um das Docker-Image auf den AWS ECS-Service zu deployen.
Angesichts unserer Anforderungen: Glaubst du, wir hätten einen anderen Ansatz wählen können?
Vielen Dank.
Ja. Meine Empfehlung ist, die offiziellen Repositories discourse und discourse_docker zu verwenden und alle Änderungen als Plugins umzusetzen.
Die Nutzung des offiziellen discourse_docker spart dir Probleme wie das in diesem Thema beschriebene. Außerdem vermeidest du es, Discourse zu forken, und bewahrst alle deine Änderungen in separaten Plugins. So bleibst du nah am Hauptzweig und musst nicht unzählige Aufwände betreiben, um alle Upstream-Änderungen in deinen Fork zurückzuführen.
Die Lernkurve beim Entwickeln von Plugins gleicht sich innerhalb weniger Wochen durch den Aufwand für das Zusammenführen von Upstream-Änderungen aus, und ab dann ist es nur noch effizienter.
Wenn du das offizielle Discourse-Repository verwendest, kannst du auch verwaltetes Hosting in Betracht ziehen. In diesem Fall sind andere Personen meist enthusiastischer (und/oder günstiger), wenn sie dir helfen müssen.
Vielen Dank für Ihre Inputs. Ich habe noch ein paar Folgefragen:
Gibt es bei dem Plug-in-Ansatz die Möglichkeit, dass wir bei bestimmten Anforderungen an eine Grenze stoßen, die sich nicht über Plug-ins umsetzen lassen? Zum Beispiel bei der Verwaltung von Benutzerrollen auf sehr individuelle Weise?
Wie würde die End-to-End-Pipeline aussehen, wenn wir das discourse_docker-Image nehmen und in unserem AWS-Konto auf ECS bereitstellen? Wie erwähnt, nutzen wir derzeit GitHub Actions, um in unserem AWS-Konto auf ECS zu deployen. Welche Bereitstellungsstrategie können wir aus dem öffentlichen Repository verwenden, während wir gleichzeitig unsere AWS-Anmeldedaten schützen?
Plugins unterstützen das Ruby-Monkey-Patching und die Erweiterung von Ember-Objekten, sodass am Ende alles möglich ist.
Das liegt nicht in meinem Fachgebiet, daher überlasse ich dies einer anderen Person.
Beginne immer mit einer Kopie des discourse_docker-Repositories. Erstelle darin eine app.yml.
Verwende den Bootstrap-Unterbefehl des launcher-Skripts in deiner lokalen Kopie von discourse_docker, um ein Docker-Image zu erstellen. Lade das Docker-Image in ein Docker-Repository hoch. Stelle dieses Docker-Image überall bereit, wo du möchtest.
Schreibe Plugins, falls du welche benötigst. Führe deine benutzerdefinierten Plugins in der app.yml wie die anderen Plugins auf.
@ashish_rawat @Vijay_Vantipalli Wie habt ihr Discourse Docker in ECS eingerichtet? Wenn ich es auf einem EC2-Server versuche, lädt Discourse einwandfrei. Sobald ich jedoch das Discourse-Docker-Image in die ECR-Registry hochlade und eine Task daraus erstelle, läuft der Container nicht – ich erhalte lediglich Exit Code 1. Ich stecke seit über einer Woche fest. Ich würde mich sehr über euren Rat freuen. Vielen Dank!
Für dieses Setup habe ich eine separate RDS-Instanz und einen ElastiCache-Redis-Cluster erstellt.
Versuchen Sie, die Argumente in ./launcher start-cmd app zu prüfen – vielleicht haben Sie etwas übersehen, das Sie nicht in ECS übernommen haben.
Vielen Dank für die schnelle Antwort! Ich glaube, mir fehlt nur etwas Einfaches. Ich werde es versuchen.
Entschuldigung, falls das außerhalb Ihres Zuständigkeitsbereichs liegt. Ich habe versucht, das “-e” aus der start-cmd-App hinzuzufügen, aber es gibt weitere Argumente wie die folgenden:
+ /usr/bin/docker run --shm-size=512m -d --restart=always
-h <server ip>
-e DOCKER_HOST_IP=172.17.0.1
--name app -t -p 80:80
-v /var/discourse/shared/web-only:/shared
-v /var/discourse/shared/web-only/log/var-log:/var/log
--mac-address <address> local_discourse/app /sbin/boot
Ist -v wirklich erforderlich?
Ja, das sind Volume-Mounts. Es ist für Discourse zwingend erforderlich, dass im Container unter /shared Speicherplatz verfügbar ist.