Excellent. Nope that will be perfect. Thanks again! Very much appreciated.
1 „Gefällt mir“
The command is now ./discourse-setup --two-container
worked as expected just now 
2 „Gefällt mir“
Good catch! Did it print a message that made it easy to figure that out?
I’ve been meaning to clean up this topic since they change.
1 „Gefällt mir“
Yes, very helpful thanks.
2 „Gefällt mir“
Are there any plans to migrate from the old “container links” thing to proper setup with a custom network with two containers being connected to it?
“Links” are legacy and may be removed in the future according to Docker docs
1 „Gefällt mir“
That sounds like a good idea.
Unless someone beats me to it, I’ll see about subunits /creating a PR to switch to networks and /or sockets (which some prefer anyway) and creating a howto to convert an existing setup to the new configuration.
5 „Gefällt mir“
@pfaffman Ich weiß nicht, ob Sie sich darum gekümmert haben, aber wenn ja, möchten Sie hier darauf verlinken? 
3 „Gefällt mir“
Sollten wir am Ende dieser Befehle noch && ./launcher cleanup hinzufügen?
Ich habe festgestellt, dass sich nach dem Wechsel zu einer Zwei-Container-Installation der verfügbare Speicherplatz schnell mit alten Images füllt.
1 „Gefällt mir“
Das empfehle ich in meiner Anleitung auf jeden Fall… Viele Leute setzen auf kleineren Systemen wie DO-Droplets ein und ich weiß, dass ich anderen geholfen habe, die nicht ganz verstanden haben, wohin ihr Speicherplatz verschwand.
2 „Gefällt mir“
@pfaffman, Hallo,
Vor ein paar Tagen habe ich AWS EC2 mit einem einzelnen Container installiert und alles funktionierte gut. Aber ich brauche genau die Konfiguration mit zwei Containern, web_only auf EC2 und data auf AWS RDS (PostgreSQL 15.3 auf Port 5432 => Ich kann keine andere Version wählen, und die Datenbank hat keinen DB_NAME-Parameter). Als Redis-Cluster habe ich versucht, AWS ElastiCache zu verwenden, aber dann einen Link in der data.yml zu der vorhandenen Vorlage hinterlassen:
#- "templates/postgres.template.yml"
- "templates/redis.template.yml"
Nachdem ich data und web_only erfolgreich gebootstrappt habe, kann ich die Webseite nicht öffnen. “Diese Website ist nicht erreichbar”
Ich habe keine Änderungen an DNS-Einträgen vorgenommen oder die Zugriffseinstellungen in den AWS-Sicherheitsgruppen (Firewall für Web und Datenbank) geändert.
Erfolgreich gebootstrappt, zum Starten ./launcher start data verwenden
root@ip-172-31-3-68:/var/discourse# ./launcher start data
x86_64 arch detected.
+ /usr/bin/docker run --shm-size=512m -d --restart=always -e LANG=en_US.UTF-8 -e LC_ALL=en_US.UTF-8 -e LANGUAGE=en_US.UTF-8 -h ip-172-31-3-68-data -e DOCKER_HOST_IP=172.17.0.1 --name data -t -v /var/discourse/shared/data:/shared -v /var/discourse/shared/data/log/var-log:/var/log --mac-address <...> local_discourse/data /sbin/boot
27b66e577d250e4178f5e145c9962be7b5f2d905cfacd233d3d2278e7b83aa93
Erfolgreich gebootstrappt, zum Starten ./launcher start web_only verwenden
root@ip-172-31-3-68:/var/discourse# ./launcher start web_only
x86_64 arch detected.
+ /usr/bin/docker run --shm-size=512m --link data:data -d --restart=always -e LANG=en_US.UTF-8 -e RAILS_ENV=production -e UNICORN_WORKERS=2 -e UNICORN_SIDEKIQS=1 -e RUBY_GC_HEAP_GROWTH_MAX_SLOTS=40000 -e RUBY_GC_HEAP_INIT_SLOTS=400000 -e RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=1.5 -e DISCOURSE_DB_SOCKET= -e DISCOURSE_DB_HOST=database-discourse.<...>.rds.amazonaws.com -e DISCOURSE_DB_PORT= -e LETSENCRYPT_DIR=/shared/letsencrypt -e DISCOURSE_FORCE_HTTPS=true -e LC_ALL=en_US.UTF-8 -e LANGUAGE=en_US.UTF-8 -e DISCOURSE_HOSTNAME=talk.furtherium.com -e DISCOURSE_DEVELOPER_EMAILS=hello@furtherium.com -e DISCOURSE_SMTP_ADDRESS=email-smtp.us-east-2.amazonaws.com -e DISCOURSE_SMTP_PORT=587 -e DISCOURSE_SMTP_USER_NAME=A<...>S -e DISCOURSE_SMTP_PASSWORD=B<...>M -e DISCOURSE_NOTIFICATION_EMAIL=noreply@talk.furtherium.com -e LETSENCRYPT_ACCOUNT_EMAIL=me@example.com -e DISCOURSE_DB_NAME= -e DISCOURSE_DB_USERNAME=postgres -e DISCOURSE_DB_PASSWORD=7<...>1 -e DISCOURSE_REDIS_HOST=data -h ip-172-31-3-68-web-only -e DOCKER_HOST_IP=172.17.0.1 --name web_only -t -p 80:80 -p 443:443 -v /var/discourse/shared/web-only:/shared -v /var/discourse/shared/web-only/log/var-log:/var/log --mac-address <...> local_discourse/web_only /sbin/boot
1233f1c660eb7cecc48d2a840aae037b46ecfd7afe029ef89b2e686b136b9886
- Ich habe die Verbindung zur Datenbank von SSH mit Telnet überprüft - OK
- Ich kann die Datenbankverbindungen im AWS RDS Dashboard sehen
- Ich habe die Instanzen 3 Mal neu gestartet
- Ich habe das Rebuild 3-4 Mal ohne Fehler ausgeführt
- Ich habe die Liste der aktiven Container und Images überprüft und unnötige bereinigt
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
1233f1c660eb local_discourse/web_only "/sbin/boot" 18 minutes ago Up 18 minutes 0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp web_only
27b66e577d25 local_discourse/data "/sbin/boot" 47 minutes ago Up 47 minutes data
Was kann ich sonst noch tun? Vielen Dank für Ihre Bemühungen und Ihre Zeit!
Das brauchst du nicht. Du brauchst nur den Web-Container und musst die Postgres- und Redis-Vorlagen löschen. Elasticache ist meiner Meinung nach absurd teuer, daher könntest du es auf deinem EC2 laufen lassen, wenn du einen einzelnen Host verwendest.
Füge einfach die ENV-Variablen zu deiner bestehenden app.yml hinzu und lösche die unnötigen Vorlagen. Ich habe kürzlich gehört, dass diese Seite auf PG15 läuft, das sollte also in Ordnung sein.
Danke für die Antwort, Jay (@pfaffman). Ich möchte nur klarstellen:
- Soll ich die Installation mit einem einzigen Container in der app.yml verwenden und die Zeilen für die Datenbank und Redis auskommentieren? Und auch im ENV-Feld der app.yml dann Zeilen für die Remote-Datenbank in AWS (DB_USER usw. - wie jetzt aus web_only) hinzufügen?
- Oder lasse ich es, wie es ist, aber stoppe den Daten-Container und lasse nur web-only übrig?
- Wenn ich ElastiCache nicht verwende, muss ich dann die Zeile “templates/redis.template.yml” belassen?
Der Wechsel von Standard auf zwei Container verlief fast reibungslos. Ich habe ziemlich viel Zeit mit fehlenden Leerzeichen in der YML-Datei verschwendet, die mich davon überzeugen wollten, dass ich Lokalisierungsprobleme hatte (nicht einmal annähernd), aber das war ein Benutzerfehler.
Aber als ich das Forum hochgefahren hatte, hatte ich ein reines, jungfräuliches Forum. Das war ziemlich einfach zu beheben, da ich ein aktuelles Backup in S3 hatte, aber ich frage mich jetzt, warum es überhaupt passiert ist – irgendwelche Vermutungen?
Ich meine, wenn ich den Weg wähle, eine komplett neue Zwei-Container-Einrichtung zu installieren und sie dann aus Backups wiederherzustellen, könnte das etwas Zeit sparen. Oder auch nicht, denn ich würde immer noch die YML bearbeiten, zumindest Plugins hinzufügen, E-Mail-Einstellungen, Maxmind usw. beheben.
1 „Gefällt mir“
[Nicht im Zusammenhang mit dem obigen Beitrag]
Ich frage mich, was der Vorteil der Verwendung eines Zwei-Container-Setups ist? Warum nicht der normale einzelne Container?
Ich denke, es ist dazu da, Ihr Forum bei einem Rebuild für Upgrades/die Installation eines Plugins nicht offline zu nehmen.
2 „Gefällt mir“
Für mich ist bereits eine kurze Ausfallzeit erwähnt. Außerdem aktualisiere ich oft, mindestens einmal pro Woche, sodass mein Setup anfällig für Fehler ist – nicht sehr oft, muss ich sagen, aber immer wieder doch.
Wenn der Grund ein Plugin ist – nicht oft, meistens ist es eine Komponente – brauche ich drei bis vier Runden, um die problematische zu lösen. Und wenn jede Runde etwa 30 Minuten dauert, ist mein Forum etwas zu lange offline, auch wenn es klein und hobbybasiert ist.
Und der dritte Grund ist, weil ich es könnte.
2 „Gefällt mir“
Ich finde es extrem stressig, wenn ein Neuaufbau fehlschlägt und meine Website ausfällt. Grundsätzlich erfordert es meine sofortige (und manchmal auch anhaltende) Aufmerksamkeit, um eine Lösung zu finden oder einen Workaround zu finden. Überhaupt nicht lustig!!!
Die Zwei-Container-Installation wandelt dies in eine bloße Unannehmlichkeit um, und das zugrunde liegende Problem kann normalerweise zu einem für mich passenden Zeitpunkt behoben werden. Außerdem wurde das Problem, das das Problem verursacht hat, zu diesem Zeitpunkt oft bereits behoben.
Wenn ich stable verwenden würde, würde ich es wahrscheinlich nicht tun. Aber wenn ich näher am Rand mit tests-passed lebe, ist es für die Widerstandsfähigkeit, die es bei Neuaufbauten / Updates bietet, von unschätzbarem Wert.
2 „Gefällt mir“
Ah, ich verstehe. Danke für die Erklärung!
Ich hatte komplett vergessen, dass ich das überhaupt gepostet habe!
1 „Gefällt mir“
Schönes Tutorial. Ich brauche 5 Minuten, mit einem neuen Server, um das Backup zu erstellen und wiederherzustellen, dann ./discourse-setup --two-container.
Danke
2 „Gefällt mir“
Kann mir jemand erklären, warum dieser Schritt notwendig ist, wenn Sie einen bestehenden Server mit einer funktionierenden Datenbank konvertieren?
Ich verstehe, dass es gute Praxis ist, kurz vor der Migration eine sichere externe Sicherung zu erstellen, aber warum der Download?
2 „Gefällt mir“