https://www.pfaffmanager.com/ récupère des informations de /admin/dashboard/general.json pour obtenir des informations sur la version. C’est très bien de pouvoir obtenir cela depuis l’UX. Malheureusement, il est mis à jour périodiquement, pas lorsque le serveur démarre, donc si vous effectuez une reconstruction, les informations sont erronées pendant un bon moment (jusqu’à 30 minutes) avant d’être exécutées à nouveau. Mon plan est de faire en sorte que mon outillage Ansible appelle manuellement AdminDashboardGeneralData.refresh_stats après le démarrage d’un nouveau conteneur, mais cela semble un peu idiot.
Serait-il judicieux d’exécuter cette tâche au démarrage plutôt que toutes les 30 minutes ? Y a-t-il un moyen de la mettre à jour sans redémarrage ? Sinon, pourquoi s’exécute-t-elle toutes les 30 minutes ? Du moins, je pense que c’est ce qui se passe. J’ai confirmé que l’exécution de refresh_stats ci-dessus met à jour general.json.
En général, nous n’aimons pas exécuter des choses « au démarrage ». Bien que cela puisse avoir du sens dans un environnement à serveur unique, non multisite, les choses se compliquent à grande échelle.
Par exemple, si vous avez une configuration d’autoscaling qui ajoute/supprime des serveurs en fonction de la charge, chacun de ces événements d’échelle peut entraîner le « démarrage » simultané de plusieurs serveurs. Nous ne voudrions pas que tous ces serveurs retardent le démarrage pendant que certaines statistiques sont mises à jour.
Nous aimons également nous assurer que les serveurs peuvent démarrer avec succès, même si la base de données/redis est en lecture seule.
Pour ce cas particulier de pfaffmanager, utilisez-vous un plugin personnalisé et/ou un modèle discourse_docker sur les sites ? Depuis l’extérieur de Discourse, vous pourriez le déclencher comme suit :
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 :