Merci. Tout cela est logique.
Non ! L’un des principes clés est que tout est tel qu’il serait dans une installation standard. Il n’y a absolument aucune dépendance spécifique à pfaffmanager. Si quelqu’un voit ici qu’il doit faire quelque chose comme une reconstruction, ajouter un plugin ou ajouter une variable d’environnement à app.yml, pfaffmanager le fera exactement comme s’il savait ce qu’est ssh et pouvait taper des commandes. Les installations utilisent discourse-setup, les mises à niveau exécutent ./launcher rebuild (ou bootstrap, destroy, start pour les configurations à 2 conteneurs). Si Postgres est obsolète, les procédures décrites dans Mise à jour PostgreSQL 13 sont suivies, et ainsi de suite. Quelques éléments m’ont tenté de créer un plugin de support optionnel, mais je préfère l’éviter. Je jongle déjà avec Ansible, Rails et Ember ; avoir une autre pièce en jeu n’est pas très attrayant.
Mais ce bout de runner a été d’une grande aide. Je vais simplement exécuter ceci après le redémarrage d’un conteneur nouvellement construit :
docker exec web_only bash -c 'rails runner AdminDashboardGeneralData.refresh_stats'
Merci infiniment. C’était exactement ce dont j’avais besoin.