https://www.pfaffmanager.com/ sta recuperando informazioni da /admin/dashboard/general.json per ottenere informazioni sulla versione. È molto bello poterle ottenere dall’UX. Sfortunatamente, viene aggiornato periodicamente, non quando il server si avvia, quindi se esegui una ricostruzione, le informazioni sono errate per un bel po’ (fino a 30 minuti) prima che vengano eseguite di nuovo. Il mio piano è di far sì che il mio strumento Ansible chiami manualmente AdminDashboardGeneralData.refresh_stats dopo che un nuovo container si è avviato, ma ciò sembra un po’ sciocco.
Avrebbe senso eseguire quel task all’avvio anziché ogni 30 minuti? C’è un modo per aggiornarlo senza un riavvio? In caso contrario, perché viene eseguito ogni 30 minuti? Almeno credo che sia quello che sta succedendo. Ho confermato che l’esecuzione del refresh_stats sopra indicato farà aggiornare general.json.
In generale, non ci piace eseguire cose “all’avvio”. Sebbene possa avere senso in un ambiente a server singolo e non multisito, le cose si complicano su larga scala.
Ad esempio, se si dispone di una configurazione di autoscaling che aggiunge/rimuove server in base al carico, ognuno di questi eventi di scalabilità può causare l’“avvio” simultaneo di più server. Non vorremmo che tutti ritardassero l’avvio mentre alcune statistiche vengono aggiornate.
Ci piace anche assicurarci che i server possano avviarsi correttamente, anche se il database/redis si trova in uno stato di sola lettura.
Per questo particolare caso di pfaffmanager, si utilizza un plugin personalizzato e/o un template discourse_docker in esecuzione sui siti? Dall’esterno di Discourse, è possibile attivarlo come:
No! Uno dei principi chiave è che tutto è esattamente come sarebbe in un’installazione standard. Non ci sono dipendenze specifiche di pfaffmanager. Se qualcuno vede qui che dovrebbe fare qualcosa come una ricostruzione, aggiungere un plugin o aggiungere una variabile d’ambiente a app.yml, pfaffmanager lo farà esattamente come se sapesse cos’è ssh e potesse digitare comandi. Le installazioni utilizzano discourse-setup, gli aggiornamenti eseguono ./launcher rebuild (o bootstrap, destroy, start per configurazioni a 2 container). Se Postgres è obsoleto, vengono seguite le procedure in Aggiornamento PostgreSQL 13, e così via. Un paio di cose mi hanno tentato a creare un plugin di supporto opzionale, ma per lo più voglio evitarlo. Sto già destreggiandomi tra Ansible, Rails ed Ember; avere un altro pezzo in gioco non è molto attraente.
Ma quel pezzo runner è stato di grande aiuto. Eseguirò questo dopo che un container appena ricostruito è stato riavviato: