Discourse mit Docker für die Entwicklung installieren

[Vin]

Hallo,

ich erhalte diesen Fehler, wenn ich versuche, d/boot_dev --init auszuführen:

Errno::EACCES: Permission denied @ dir_s_mkdir - tmp
/src/config/boot.rb:23:in `<top (required)>'
/src/config/application.rb:16:in `require'
/src/config/application.rb:16:in `<top (required)>'
/src/Rakefile:7:in `require'
/src/Rakefile:7:in `<top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
(Siehe vollständigen Trace, indem Sie die Aufgabe mit --trace ausführen)

Haben Sie eine Idee, wie ich das beheben kann? Ich habe überall danach gesucht, aber keine Lösungen gefunden.

Edit: Ich habe es behoben, indem ich chmod -R 777 ~/discourse ausgeführt habe. Jetzt erhalte ich jedoch diesen Fehler:

gifsicle worker: gifsicle not found; please provide proper binary or disable this worker (--no-gifsicle argument or :gifsicle => false through options)

[sam (Sam Saffron)]

@Vin

gifsicle-Worker: gifsicle nicht gefunden; bitte stellen Sie das korrekte Binärprogramm bereit oder deaktivieren Sie diesen Worker (–no-gifsicle-Argument oder :gifsicle => false über Optionen)

Das ist kein Problem, wir haben unsere Nutzung vor kurzem entfernt, die Warnung ist kein Anlass zur Sorge. Arbeiten Sie mit veraltetem Discourse-Code?

[Vin]

Nein, es war das kürzlich veröffentlichte Update. Aber ich habe dieses DigitalOcean-Tutorial befolgt, und jetzt funktioniert es einwandfrei.

[Marcin_J]

Wie verwendet man Plugins in einer solchen Einrichtung?
Ich versuche, Install plugins on a self-hosted site zu befolgen, aber dort wird die Datei /var/discourse/containers/app.yml erwähnt, die in meinem discourse-Verzeichnis nicht existiert.

[jessicah (Jessica Hamilton)]

Ich habe eine Discourse-Entwicklungsumgebung erfolgreich aufgebaut und kann meinen Patch testen, aber wie bekomme ich meinen Patch in meine Produktionsinstanz? Ich habe versucht, base zu bauen und dann ./launcher rebuild app --run-image discourse/base:build auszuführen, aber es scheint nicht zu einer laufenden Discourse-Instanz zu führen.

Normalerweise erhalte ich einen Fehler über die fehlende syslog-Gruppe, aber ich habe diesen Kommentar entfernt, und es kam trotzdem keine laufende Website zustande. In den Docker-Logs ist ebenfalls nichts Bemerkenswertes zu finden.

[sam (Sam Saffron)]

Wir dokumentieren solche Dinge eigentlich nicht, aber Sie würden eine „Diff“-Datei generieren und diese nach dem Klonen des Repositories in einem Hook mit git apply anwenden. app.yml unterstützt Hooks.

Eine schnelle und einfache Lösung für selbst gehostete Einzel-Container-Umgebungen besteht darin, den Code direkt zu bearbeiten und sv restart unicorn auszuführen.

[juli (Julian Muñoz)]

Ich bin mir nicht sicher, ob dies der beste Ort ist, um nach diesem Problem zu fragen, aber ich konnte die Discourse-Installation mit Docker auf einem Apple M1-Computer nicht abschließen.

Nachdem ich d/boot_dev --init ausgeführt habe, werden alle Abhängigkeiten ohne ersichtliche Probleme installiert. Sobald ich jedoch den Schritt „Migrating database

[sam (Sam Saffron)]

Ich denke, die Virtualisierungsunterstützung ist wirklich brandneu, daher überrascht es nicht, dass es ein kleines Abenteuer ist.

@pmusaraj / @david: Hattet ihr Erfolg damit, docker-dev auf M1 zum Laufen zu bringen?

[pmusaraj (Penar Musaraj)]

Ich habe es noch nicht ausprobiert.

[juli (Julian Muñoz)]

Falls jemand Discourse mit Docker auf einem M1-Mac ausführen kann, lass es mich bitte wissen. In der Zwischenzeit werde ich versuchen, die andere Anleitung zu befolgen! Danke!

[pmusaraj (Penar Musaraj)]

Ich habe es heute kurz versucht und bin an derselben Stelle wie du hängen geblieben, allerdings mit einem Fehler:

Invalid gemspec in [/usr/local/lib/ruby/gems/2.7.0/specifications/default/zlib-1.1.0.gemspec]: Malformed version number string specification_version
bundler: failed to load command: rake (/usr/local/bin/rake)

@juli

folge der anderen Anleitung

Ja, bitte tu das. Es gibt mehrere Teammitglieder, die täglich Discourse auf M1 verwenden (ich eingeschlossen), also funktioniert es ziemlich gut!

Lass uns wissen, falls du auf Probleme stößt.

[juli (Julian Muñoz)]

Vielen Dank für Ihre Zeit und Hilfe! Zumindest bin ich nicht der Einzige, der damit feststeckt.

[hawm]

Hallo, ich denke, wir sollten hier eine Beschreibung für Ember-CLI hinzufügen und eine Abkürzung für den folgenden Befehl erstellen, ohne dass man in den Docker-Container eintauchen muss.

Außerdem bekomme ich es nicht hin, die oben genannten Befehle im Container auszuführen; es scheint, als ob der Container den Port 4200 nicht freigegeben hat.

Manuelles Freigeben von Port 4200 durch Bearbeiten von d/boot_dev:

Nach dem Neustart des Containers habe ich auf localhost:4200 zugegriffen und folgendes erhalten:

discourse@discourse:/tmp$ cat error.dump.cab4cc444229d44fc0fce2deb8695880.log 
=================================================================================

ENV Summary:

  TIME: Sun May 02 2021 08:01:12 GMT+0000 (Coordinated Universal Time)
  TITLE: ember
  ARGV:
  - /usr/bin/node
  - /src/app/assets/javascripts/node_modules/.bin/ember
  - server
  - --proxy
  - http://localhost:3000
  EXEC_PATH: /usr/bin/node
  TMPDIR: /tmp
  SHELL: /bin/bash
  PATH:
  - /tmp/yarn--1619942449179-0.1910991449592403
  - /src/app/assets/javascripts/discourse/node_modules/.bin
  - /home/discourse/.config/yarn/link/node_modules/.bin
  - /src/app/assets/javascripts/node_modules/.bin
  - /home/discourse/.yarn/bin
  - /usr/libexec/lib/node_modules/npm/bin/node-gyp-bin
  - /usr/lib/node_modules/npm/bin/node-gyp-bin
  - /usr/bin/node_modules/npm/bin/node-gyp-bin
  - /usr/local/sbin
  - /usr/local/bin
  - /usr/sbin
  - /usr/bin
  - /sbin
  - /bin
  PLATFORM: linux x64
  FREEMEM: 8603062272
  TOTALMEM: 41962496000
  UPTIME: 612639
  LOADAVG: 3.32177734375,2.19580078125,1.47900390625
  CPUS:
  - Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz - 3301
  - Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz - 3300
  - Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz - 3300
  - Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz - 3301
  ENDIANNESS: LE
  VERSIONS:
  - ares: 1.15.0
  - brotli: 1.0.7
  - cldr: 35.1
  - http_parser: 2.9.3
  - icu: 64.2
  - modules: 64
  - napi: 7
  - nghttp2: 1.41.0
  - node: 10.23.0
  - openssl: 1.1.1g
  - tz: 2019c
  - unicode: 12.1
  - uv: 1.34.2
  - v8: 6.8.275.32-node.59
  - zlib: 1.2.11

ERROR Summary:

  - broccoliBuilderErrorStack: [undefined]
  - code: ECONNREFUSED
  - codeFrame: [undefined]
  - errorMessage: connect ECONNREFUSED 127.0.0.1:3000
  - errorType: [undefined]
  - location:
    - column: [undefined]
    - file: [undefined]
    - line: [undefined]
  - message: connect ECONNREFUSED 127.0.0.1:3000
  - name: Error
  - nodeAnnotation: [undefined]
  - nodeName: [undefined]
  - originalErrorMessage: [undefined]
  - stack: Error: connect ECONNREFUSED 127.0.0.1:3000
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1107:14)

=================================================================================

Nachdem ich in bin/ember-cli den PORT von 3000 auf 9292 geändert habe, funktioniert alles.

Es scheint, als ob das ember-cli-Skript nicht mit ENV["UNICORN_PORT"] funktioniert.

[codinghorror (Jeff Atwood)]

Der Ember CLI ist eine neue (und hart erkämpfte) Entwicklung; @eviltrout sollte dazu in Kürze etwas sagen können.

[eviltrout (Robin Ward)]

Ja, das muss aktualisiert werden. Bis dahin können Sie dies deaktivieren, indem Sie die Umgebungsvariable NO_EMBER_CLI auf 1 setzen.

[Daniel_McQuillen]

Wahrscheinlich offensichtlich, aber könntest du bitte klären, wo du die Umgebungsvariable setzt, @eviltrout?

Ich habe es in der Datei d/unicorn so versucht:

docker exec -it -u discourse:discourse discourse_dev /bin/bash -c "$CMD" -e NO_EMBER_CLI=1

…aber das hat nicht funktioniert (immer noch die Meldung “Ember CLI ist im Entwicklungsmodus erforderlich” auf localhost:9292).

[Alex_P]

d/boot_dev -e NO_EMBER_CLI=1

[david (David Taylor)]

@juli

Wenn jemand Discourse mit Docker auf einem M1-Mac ausführen kann

Ich habe es heute ebenfalls versucht und bin dabei auf Probleme gestoßen. Der Fehler trat auf, weil die Architektur-Emulation von Docker inotify nicht unterstützt (was wir in der Discourse-Entwicklung häufig verwenden). Derzeit habe ich eine Warnung in d/boot_dev hinzugefügt, die ausgegeben wird, wenn eine nicht-x86_64-Architektur erkannt wird:

❯ d/boot_dev 
WARNUNG: Die Docker-Architektur ist nicht x86_64.
Die Discourse-Entwicklung wird unter der Architektur-Emulation von Docker wahrscheinlich nicht funktionieren.
Bitte versuchen Sie eine native Entwicklungsumgebung.

@hawm

Hallo, ich denke, wir sollten hier eine Beschreibung zu Ember-CLI hinzufügen.

Ich habe nun einen d/ember-cli-Helper hinzugefügt und standardmäßig den Port 4200 weitergeleitet. Die Informationen oben in diesem Thema wurden ebenfalls aktualisiert. Nach dem Update führen Sie in einem Terminal d/rails s und in einem anderen d/ember-cli aus. Außerdem habe ich NO_EMBER_CLI als eine der Variablen festgelegt, die an Docker übergeben werden, sodass sie bei Bedarf verfügbar ist.

[Daniel_McQuillen]

@david Wahrscheinlich unbedeutend, aber nur zur Info: Das boot_dev-Skript gibt einen falschen Fehler bei der x86_64-Prüfung aus, wenn ich es versehentlich ohne Docker ausgeführt habe (aber der Teil „Ist der Docker-Daemon aktiv?

[mint_saxon]

Danke für dieses Bild und die superklaren Anweisungen!

Beim Ausführen von d/boot_dev --init erhielt ich die Fehlermeldung psql: error: FATAL: Peer authentication failed for user "postgres".

Obwohl in der pg_hba.conf unter data/postgres/ alle Authentifizierungsmethoden auf “trust” eingestellt waren, gab es eine weitere unter /etc/postgresql/13/main/, die die Standardeinstellungen (“peer” / “md5”) enthielt.

Ich habe /etc/postgresql/13/main/pg_hba.conf bearbeitet, alle Methoden auf trust geändert, d/shell ausgeführt und sv restart postgres gestartet, um die Änderungen zu übernehmen. Anschließend konnte ich fortfahren, indem ich d/bundle install; d/rake db:migrate RAILS_ENV=development; d/rake admin:create manuell ausführte.

Ich hinterlasse dies hier, falls es für andere hilfreich sein sollte!