Danke. Das ergibt alles Sinn.
Nein! Eines der Schlüsselprinzipien ist, dass alles so ist, wie es bei einer Standardinstallation wäre. Es gibt null pfaffmanager-spezifische Abhängigkeiten. Wenn jemand hier sieht, dass er etwas wie einen Rebuild, ein Plugin oder eine Umgebungsvariable zu app.yml hinzufügen soll, wird pfaffmanager dies genau so tun, als ob er wüsste, was SSH ist und Befehle tippen könnte. Installationen verwenden discourse-setup, Upgrades führen ./launcher rebuild aus (oder bootstrap, destroy, start für 2-Container-Setups). Wenn Postgres veraltet ist, werden die Prozeduren in PostgreSQL 13 Update befolgt und so weiter. Ein paar Dinge haben mich versucht, ein optionales Support-Plugin zu erstellen, aber das möchte ich meistens vermeiden. Ich jongliere bereits mit Ansible, Rails und Ember – ein weiteres Teil im Spiel ist nicht sehr attraktiv.
Aber dieser runner-Teil war eine große Hilfe. Ich werde dies einfach ausführen, nachdem ein neu erstellter Container neu gestartet wurde:
docker exec web_only bash -c 'rails runner AdminDashboardGeneralData.refresh_stats'
Vielen Dank. Das war genau das, was ich brauchte.