https://www.pfaffmanager.com/ extrae información de /admin/dashboard/general.json para obtener información de la versión. Es muy bueno poder obtener esto de la UX. Desafortunadamente, se actualiza periódicamente, no cuando el servidor arranca, por lo que si realizas una reconstrucción, la información es incorrecta durante un buen tiempo (hasta 30 minutos) antes de que se ejecute de nuevo. Mi plan es que mis herramientas Ansible llamen manualmente a AdminDashboardGeneralData.refresh_stats después de que arranque un nuevo contenedor, pero eso parece un poco tonto.
¿Tendría sentido ejecutar esa tarea al arrancar en lugar de cada 30 minutos? ¿Hay alguna forma de que se actualice sin reiniciar? Si no, ¿por qué se ejecuta cada 30 minutos? Al menos creo que eso es lo que está sucediendo. He confirmado que ejecutar el refresh_stats anterior hará que general.json se actualice.
En general, no nos gusta ejecutar cosas ‘al arrancar’. Si bien puede tener sentido en un entorno de un solo servidor que no sea multisitio, las cosas se complican a gran escala.
Por ejemplo, si tiene una configuración de escalado automático que agrega/elimina servidores según la carga, cada uno de esos eventos de escalado puede hacer que varios servidores “arranquen” simultáneamente. No querríamos que todos retrasaran el inicio mientras se actualizan algunas estadísticas.
También nos gusta asegurarnos de que los servidores puedan arrancar correctamente, incluso si la base de datos/redis están en un estado de solo lectura.
Para este caso particular de pfaffmanager, ¿tiene un plugin personalizado y/o una plantilla de discourse_docker ejecutándose en los sitios? Desde fuera de Discourse, podría activarlo así:
¡No! Uno de los principios clave es que todo es tal como estaría en una instalación estándar. No hay CERO dependencias específicas de pfaffmanager. Si alguien ve aquí que debe hacer algo como una reconstrucción, agregar un plugin o agregar una variable de entorno a app.yml, pfaffmanager lo hará exactamente como si supiera qué es ssh y pudiera escribir comandos. Las instalaciones usan discourse-setup, las actualizaciones ejecutan ./launcher rebuild (o bootstrap, destroy, start para configuraciones de 2 contenedores). Si Postgres está desactualizado, se siguen los procedimientos en Actualización de PostgreSQL 13, y así sucesivamente. Un par de cosas me han tentado a crear un plugin de soporte opcional, pero principalmente quiero evitarlo. Ya estoy haciendo malabares con Ansible, Rails y Ember; tener otra pieza en juego no es muy atractivo.
Pero ese fragmento de runner fue de gran ayuda. Simplemente ejecutaré esto después de que se reinicie un contenedor recién construido: