Discourse auf einem isolierten CentOS 7-Server installieren

Die meisten Plugins enthalten den gesamten benötigten Code und lassen sich einfach installieren. Die beiden, die du versucht hast zu verwenden, müssen jedoch Bibliotheken (Gems) aus dem Internet herunterladen, um funktionieren zu können.

3 „Gefällt mir“

Weißt du, wo im Code die Ruby-Gem-Downloads für Plugins stattfinden? Ich habe versucht, sie zu finden, habe aber den richtigen Ort noch nicht entdeckt.

Ich überlege, ob es eleganter wäre, anstelle von gecachten Gems einen RubyGems-Spiegel auf dem isolierten Host zu betreiben. Ich habe hier ein Tutorial gefunden, und es scheint, als könnte man zusätzliche systemweite Gem-Quellen konfigurieren.

1 „Gefällt mir“

Unser interner Discourse läuft schon seit geraumer Zeit erfreulicherweise mit derselben alten Version, aber wir werden endlich IE9 abgeschafft, sodass ein Upgrade längst überfällig ist.
Ich kann bestätigen, dass dieser Leitfaden auch mit den neuesten Versionen von Discourse funktioniert. Selbst mit RHEL8 statt 7 :slight_smile:

Beim Experimentieren habe ich einen Weg gefunden, die Plugins discourse-prometheus und discourse-calendar auch offline zum Laufen zu bringen, selbst mit den zusätzlichen Abhängigkeiten. Der Trick bestand darin, die Ruby-Gems aus dem Plugin-Verzeichnis des Build-Servers sowie die in /var/www/discourse/vendor/bundle/ruby zu extrahieren.

docker run -it -v ~/local/rubygems.org:/local-rubygems local_discourse/app /bin/bash -c "cp -rv /var/www/discourse/vendor/bundle/ruby /local-rubygems"
docker run -it -v ~/local/rubygems.org/plugin-gems/discourse-calendar:/local-rubygems local_discourse/app /bin/bash -c "cp -rv /var/www/discourse/plugins/discourse-calendar/gems /local-rubygems"
docker run -it -v ~/local/rubygems.org/plugin-gems/discourse-prometheus:/local-rubygems local_discourse/app /bin/bash -c "cp -rv /var/www/discourse/plugins/discourse-prometheus/gems /local-rubygems"

Und dann in /templates/web.template.yml:

  - exec:
      cd: $home
      hook: bundle_exec
      cmd:
        # Lokales Ruby-Cache kopieren
        - cp -rv /local-rubygems.org/ruby/* $home/vendor/bundle/ruby/
        - cp -rv /local-rubygems.org/plugin-gems/* $home/plugins/
        - su discourse -c 'bundle install --local --deployment --retry 3 --jobs 4 --verbose --without test development'

Übrigens scheint das Thema zu Active Directory IIS SSO irgendwann verloren gegangen zu sein, aber der Code ist immer noch unter GitHub - laktak/discourse-sso: Single Sign On for Discourse with Active Directory · GitHub verfügbar und funktioniert auch mit dem nun umbenannten DiscourseConnect SSO.

Ich habe ein weiteres Upgrade ausprobiert und es sieht so aus, als ob an einer Stelle ein neuer Abschnitt “yarn install” zu web.template.yml hinzugefügt wurde, der in der isolierten Umgebung fehlschlägt.

- exec:
      cd: $home
      cmd:
        - "[ ! -d 'node_modules' ] || su discourse -c 'yarn install --production && yarn cache list'"

Beim Vergleich der Inhalte des alten und neuen Containers sieht es so aus, als ob im neuen eine Menge gecachte Yarn-Pakete in /usr/local/share/.cache/yarn/v6 vorhanden sind, im alten jedoch nichts. Ich vermute, dass alle benötigten Node.js-Pakete früher im Basis-Image enthalten waren, jetzt aber während eines Rebuilds aktualisiert werden?

Ich werde experimentieren, indem ich den Yarn-Cache genauso auskopiere wie den Ruby-Cache und sehen, ob ich Yarn dazu bringen kann, die gecachten Pakete von der Build-Box zu verwenden.