Discourse mit Docker für die Entwicklung installieren

Dokumentation Entwicklerhandbücher
, ,
168

Vielen Dank für die Anleitung.

Allerdings habe ich Probleme beim Erstellen eines Backups aus dem Admin-Bereich.
Die Fehlermeldung lautet:
pg_dump: error: connection to database "discourse development" failed: FATAL: Peer authentication failed for user "postgres".

Ich habe die pg_hba.conf-Datei überprüft und alle Optionen auf „trust“ gesetzt.

Es wäre toll, wenn ich Unterstützung dabei bekommen könnte, das zum Laufen zu bringen.

Ich habe es sowohl unter Ubuntu als auch unter macOS ausprobiert. Alles funktioniert einwandfrei (Erstellen von Beiträgen, API usw.), außer die Backup-Funktionalität.

169

Vielen Dank für diese fantastische Docker-Lösung.

Für das Ausführen von Plugin-Specs funktioniert dies hervorragend:

d/rake plugin:spec["discourse-follow"]

Gibt es eine Möglichkeit, spezifische Plugin-Tests zu adressieren, wie bei einer nicht-Docker-Entwicklungsumgebung? Zum Beispiel:

LOAD_PLUGINS=1 RAILS_ENV=test rspec plugins/discourse-follow/spec/requests/follow_controller_spec.rb:32

Ich habe beispielsweise Folgendes versucht:

d/rspec plugins/discourse-follow/spec/lib/updater_spec.rb:10 LOAD_PLUGINS=1 RAILS_ENV=test

Dabei erhalte ich jedoch einen Fehler.

170

LOAD_PLUGINS und RAILS_ENV müssen vor dem Befehl stehen, um Umgebungsvariablen zu setzen. Nach dem Befehl werden sie als Argumente an rspec übergeben, das diese nicht versteht.

LOAD_PLUGINS=1 RAILS_ENV=test d/rspec plugins/discourse-follow/spec/lib/updater_spec.rb:10

171

Nein, ich bin nicht überzeugt, dass das funktioniert – hast du es tatsächlich ausprobiert?

Ich erhalte:

NameError:
  uninitialized constant Follow

Ich vermute, das liegt daran, dass die Umgebungsvariablen nicht an den Docker-Prozess übergeben werden?

Deswegen habe ich sie als Argumente definiert.

172

Entschuldigung, ich habe deine beiden Befehle missverstanden als „der erste funktioniert für diese andere Spezifikation, der zweite funktioniert nicht für diese Spezifikation". Ich habe keine Entwicklungsumgebung eingerichtet, um es zu testen.

Wenn ich mir die RSpec-Datei auf GitHub ansehe, hast du recht, dass die Umgebungsvariablen nicht übergeben werden. Es sieht so aus, als könntest du d/shell ausführen, um eine Shell innerhalb des Containers zu erhalten, und dort dann deinen RSpec-Befehl ausführen.

1 „Gefällt mir“
173

Simon, das ist mehr als eine hervorragende praktische Lösung, danke!

Habe es gerade ausprobiert und es funktioniert, also:

my-blah-machine:~/discourse$ d/shell
discourse@discourse:/src$ LOAD_PLUGINS=1 RAILS_ENV=test rspec plugins/discourse-follow/spec/lib/updater_spec.rb:37

Ich habe dies sowie die gesamte Plugin-Version ins Wiki aufgenommen.

1 „Gefällt mir“
174

Ein genauerer Blick auf d/exec, das sowohl d/shell als auch d/rspec verwenden: Ich glaube, es kann auch so verkürzt werden:

RAILS_ENV=test d/exec LOAD_PLUGINS=1 rspec plugins/discourse-follow/spec/lib/updater_spec.rb:37

d/exec übergibt zwar RAILS_ENV, aber nicht LOAD_PLUGINS, weshalb diese auf beiden Seiten von d/exec stehen.

1 „Gefällt mir“
175

Das führt zu einem Fehler:

OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: "LOAD_PLUGINS=1": executable file not found in $PATH: unknown
176

Ah, ich vermute, Umgebungsvariablen können nicht so mit docker exec verwendet werden. Nun gut, zumindest funktioniert das Öffnen der Shell zuerst.

1 „Gefällt mir“
177

Ich habe exakt das gleiche Problem wie Max. Immer wenn ich versuche, auf meiner lokalen Docker-Entwicklungsumgebung ein Backup zu erstellen oder eine Wiederherstellung durchzuführen, erhalte ich denselben Fehler: Peer authentication failed for user "postgres".

Nach etwas Recherche habe ich festgestellt, dass in der Entwicklungsumgebung die Datenbankkonfiguration so aussieht:

BackupRestore.database_configuration
=> #<struct BackupRestore::DatabaseConfiguration host=nil, port=nil, username="postgres", password=nil, database="discourse_development">

Offensichtlich werden in der Entwicklungsumgebung die Benutzernamen nicht in den Umgebungsvariablen gesetzt, und das Modul BackupRestore setzt den Benutzernamen dann standardmäßig auf postgres.

# lib/backup_restore.rb:122

    DatabaseConfiguration.new(
      config["backup_host"] || config["host"],
      config["backup_port"] || config["port"],
      config["username"] || username || ENV["USER"] || "postgres",
      config["password"] || password,
      config["database"]
    )

Wo können wir den richtigen Datenbankbenutzernamen festlegen?

1 „Gefällt mir“
178

Wie verwenden wir hier Install the Discourse Theme CLI console app to help you build themes?

Wir haben das Gem erfolgreich installiert: d/exec sudo gem install discourse_theme … nun besteht die Herausforderung darin, eine Symlink-Verbindung zum lokalen Theme herzustellen …

@Simon_Manning Hinweis zur Verwendung von sudo, um Berechtigungsprobleme zu umgehen (danke für die Erinnerung an @fzngagan).

179

Ich versuche, ein Plugin mit dem Docker-Setup zu testen. Zufällig lädt die App nicht mehr und ich sehe nur eine leere Seite, bis ich den Datenordner lösche und alles neu aufbaue. Hast du Tipps, wie man das Problem debuggen kann?

180

Gibt es dazu schon Erkenntnisse? Es scheint immer noch ein Problem zu sein.

181

Mein „schmutziger" Workaround bestand darin, den Benutzernamen von postgres zu discourse im folgenden Codeblock zu ändern:

# lib/backup_restore.rb:122

    DatabaseConfiguration.new(
      config["backup_host"] || config["host"],
      config["backup_port"] || config["port"],
      config["username"] || username || ENV["USER"] || "postgres",
      config["password"] || password,
      config["database"]
    )
182

Ich bin von meinem lokalen Mac auf eine Ubuntu-VM umgestiegen, in der Hoffnung, dass das den Start erleichtert. Leider ist das bisher nicht der Fall.

Bereits in den frühen Phasen kämpfe ich mit seltsamen Berechtigungsproblemen. d/bundle install meldet, dass es sudo-Rechte benötigt, um einige Pakete zu installieren, und auch d/rails s wirft Berechtigungsfehler.

Traceback (most recent call last):
        8: from /src/bin/unicorn:70:in `<main>'
        7: from /src/bin/unicorn:38:in `ensure_cache_clean!'
        6: from /usr/local/lib/ruby/2.7.0/fileutils.rb:211:in `mkdir_p'
        5: from /usr/local/lib/ruby/2.7.0/fileutils.rb:211:in `each'
        4: from /usr/local/lib/ruby/2.7.0/fileutils.rb:226:in `block in mkdir_p'
        3: from /usr/local/lib/ruby/2.7.0/fileutils.rb:226:in `reverse_each'
        2: from /usr/local/lib/ruby/2.7.0/fileutils.rb:228:in `block (2 levels) in mkdir_p'
        1: from /usr/local/lib/ruby/2.7.0/fileutils.rb:250:in `fu_mkdir'
/usr/local/lib/ruby/2.7.0/fileutils.rb:250:in `mkdir': Permission denied @ dir_s_mkdir - /src/tmp (Errno::EACCES)

Habt ihr eine Idee, was schiefläuft? Auf dieser Maschine lief zuvor ein produktives Discourse ohne Probleme. Ich habe diese Container gestoppt und entfernt und das Dev-Git-Repository in ein anderes Verzeichnis geklont. Ich führe alles über tmux aus, um die verschiedenen Shell-Instanzen zu verwalten.

183

Ich bin noch nicht auf M1, werde aber sehr bald wechseln, und ich bevorzuge wirklich die Bequemlichkeit des Docker-Setups.

Der Link zu diesem PR führt zu https://github.com/docker/for-mac/issues/5321, wo es heißt:

Die einzige Lösung besteht darin, auf arm64-fähige Multi-Arch-Images umzusteigen. Diese werden auch deutlich schneller und generell zuverlässiger sein. Ich empfehle zu prüfen, welche Basis-Images ihr verwendet, und wo möglich auf Multi-Arch-Images umzusteigen. Auf Docker Hub lässt sich ablesen, welche Architekturen von jedem Image unterstützt werden: […]

Um ein Multi-Arch-Image selbst zu bauen, empfehle ich docker buildx. Schaut euch diesen Blogbeitrag an: https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/

Ist das Discourse-Team offen für die Unterstützung eines Multi-Arch-Images? Es sieht so aus, als ob das Discourse-Basisimage auf debian:buster-slim basiert, das bereits Multi-Arch-fähig ist. Daher sollte es nicht übermäßig schwierig sein, das Discourse-Basisimage ebenfalls multi-arch-fähig zu machen. Das könnte euch jedoch in die Lage versetzen, ARM (in der Produktion!) unterstützen zu müssen. Jemand (das Discourse-Team?) müsste die Discourse-Tests sowohl auf x86_64 als auch auf ARM ausführen, Fehler beheben, wenn sie scheitern, usw.

Wäre ein PR hier überhaupt willkommen?

(IMO scheint ARM die Architektur der Zukunft zu sein, selbst in cloud-gewirteten Umgebungen.)

2 „Gefällt mir“
Install Discourse on Arm-Based Compute
184

Ich versuche, dies unter WSL2 einzurichten.

Ich bin bis zum Start von ember_cli gekommen, aber Chrome zeigt mir folgenden Fehler:

Sowohl im Terminal als auch im Entwicklungsprotokoll sind keine Fehler sichtbar. Jegliche Vorschläge sind willkommen, bitte?

1 „Gefällt mir“
Trouble setting up dev Discourse on WSL2 with Docker - solved
185

das ist wirklich hilfreich

186

Hallo zusammen,

Ich stoße auf dieselben Probleme und dachte daher, ich melde es als Fehler. Bitte siehe unten.

Backup-Wiederherstellung schlägt in sauberer Dev-Docker-Umgebung fehl: FATAL: Peer-Authentifizierung fehlgeschlagen für Benutzer „postgres“

Lassen Sie mich wissen, wenn ich weitere Informationen bereitstellen oder behilflich sein kann.

Koen

187

Ich bekomme das unter openSUSE Leap 15 nicht zum Laufen. Ich nehme an, das ist kein unterstütztes Betriebssystem, obwohl es, da wir Docker verwenden, eigentlich keine Rolle spielen sollte…

Migrating database...
rake aborted!
Errno::EACCES: Permission denied @ dir_s_mkdir - /src/app/assets/javascripts/plugins
/src/lib/plugin/instance.rb:441:in `ensure_directory'
/src/lib/plugin/instance.rb:713:in `activate!'
lib/discourse.rb:283:in `block in activate_plugins!'
lib/discourse.rb:280:in `each'
lib/discourse.rb:280:in `activate_plugins!'
/src/config/application.rb:318:in `block in <class:Application>'
/src/lib/plugin_initialization_guard.rb:5:in `plugin_initialization_guard'
/src/config/application.rb:317:in `<class:Application>'
/src/config/application.rb:73:in `<module:Discourse>'
/src/config/application.rb:72:in `<main>'
/src/Rakefile:7:in `<main>'
(See full trace by running task with --trace)

Ich habe versucht, “app/assets/javascripts/plugins” manuell zu erstellen, und das hat mich zu Folgendem geführt:

Migrating database...
rake aborted!
Errno::EACCES: Permission denied @ dir_s_mkdir - /src/tmp
lib/discourse.rb:94:in `atomic_write_file'
/src/lib/plugin/instance.rb:726:in `activate!'
lib/discourse.rb:283:in `block in activate_plugins!'
lib/discourse.rb:280:in `each'
lib/discourse.rb:280:in `activate_plugins!'
/src/config/application.rb:318:in `block in <class:Application>'
/src/lib/plugin_initialization_guard.rb:5:in `plugin_initialization_guard'
/src/config/application.rb:317:in `<class:Application>'
/src/config/application.rb:73:in `<module:Discourse>'
/src/config/application.rb:72:in `<main>'
/src/Rakefile:7:in `<main>'
(See full trace by running task with --trace)

Ich werde also tmp im Quellordner erstellen…

Aber dann komme ich hierher:

Migrating database...
rake aborted!
Errno::EACCES: Permission denied @ rb_sysopen - /src/tmp/5ad4443faf817dc922116f8df65ae5c3
lib/discourse.rb:97:in `initialize'
lib/discourse.rb:97:in `open'
lib/discourse.rb:97:in `atomic_write_file'
/src/lib/plugin/instance.rb:726:in `activate!'
lib/discourse.rb:283:in `block in activate_plugins!'
lib/discourse.rb:280:in `each'
lib/discourse.rb:280:in `activate_plugins!'
/src/config/application.rb:318:in `block in <class:Application>'
/src/lib/plugin_initialization_guard.rb:5:in `plugin_initialization_guard'
/src/config/application.rb:317:in `<class:Application>'
/src/config/application.rb:73:in `<module:Discourse>'
/src/config/application.rb:72:in `<main>'
/src/Rakefile:7:in `<main>'
(See full trace by running task with --trace)

Es sieht so aus, als ob boot_dev docker exec als discourse-Benutzer ausführt… aber die Verzeichnisse gehören einem Benutzer 1016 (der uid meines Host-Benutzers).

Ich stelle mir vor, dass viele Entwickler dieses Problem auf ihren persönlichen Laptops nicht haben, wo ihr Benutzer eine uid von 1000 hat und es zufällig übereinstimmt…

1 „Gefällt mir“