Mostrar página de error estática mientras el sitio está caído

Lo que quiero hacer es mostrar una página que diga “este sitio está en mantenimiento” cuando se desconecte durante, por ejemplo, el proceso de reconstrucción.

Este tema es básicamente lo que me gustaría hacer, pero parece requerir una configuración no estándar. ¿Hay una forma más fácil de hacer esto para una instalación estándar? ¡Gracias!

No, no hay nada parecido en este momento.

3 Me gusta

En realidad, este procedimiento utiliza lo que se considera una “instalación estándar” (es decir, utilizando la guía oficial de Docker de Discourse), a la que Nginx se redespliega fuera del contenedor.
El procedimiento parece aterrador al principio, pero en realidad no lo es, puedo ayudarte si quieres.

No es la respuesta que quería oír, pero aprecio la respuesta inequívoca de todos modos.

No me preocupa demasiado el proceso, sino si esta configuración requerirá alguna consideración adicional al hacer cosas sencillas en el futuro, como instalar un nuevo plugin. ¿O es algo que una vez configurado no tengo que volver a pensar en ello?

Desde que agregué NGINX para esto en 2020, he tenido que editar la configuración dos veces. Ambas veces fue para ajustar la configuración relacionada con la carga de archivos grandes después de actualizar el límite en Discourse.

Usar NGINX externo para proporcionar la página estática y actuar como un proxy inverso para Discourse normalmente no requiere cambios una vez que lo configuras correctamente.

3 Me gusta

Tenga en cuenta que el nginx externo aporta algo más valioso además de la página de error estática: la atribución correcta de las direcciones IP de origen para los usuarios de IPv6. Si su foro es accesible a través de IPv6 y no utiliza la configuración externa de nginx, todos los que accedan a su sitio a través de IPv6 aparecerán como si provinieran de una dirección local 172.x.y.z. ¡Esto no ayuda cuando intenta lidiar con usuarios maliciosos del sitio como los spammers!

Es exactamente lo mismo para añadir nuevos plugins.

Creo que facilita la actualización porque sabe que sus usuarios serán informados del mantenimiento y simplemente esperarán a que termine.

Lo único que se me ocurre que querrá asegurarse es que tiene certbot renovando correctamente sus certificados. Eso está integrado en la configuración predeterminada que no utiliza nginx externo, pero si utiliza nginx externo, también debe utilizar certbot externo y asegurarse de que está configurado para renovar su certificado. Y no todas las formas de instalar certbot manejan esto.

Tenga en cuenta que la documentación que preguntó dice:

:alarm_clock: Si instaló certbot desde su repositorio de paquetes, las renovaciones suelen ocurrir automáticamente. De lo contrario, ¡establezca un recordatorio para ejecutar letsencrypt renew && systemctl reload nginx.service antes de que expire su certificado!

Sin embargo, establecer un recordatorio no es una buena manera de hacerlo. Inevitablemente lo olvidará, y si se pierde un correo electrónico de letsencrypt advirtiéndole sobre la expiración del certificado, su sitio dejará de funcionar. Afortunadamente, esto es fácil de solucionar.

Si las renovaciones automáticas no están configuradas, aquí le mostramos cómo hacerlo.

Cree el archivo /etc/systemd/system/certbot.service con este contenido:

[Unit]
Description=Certbot
Documentation=file:///usr/share/doc/python-certbot-doc/html/index.html
Documentation=https://letsencrypt.readthedocs.io/en/latest/
[Service]
Type=oneshot
ExecStart=/usr/bin/certbot -q renew
PrivateTmp=true

Cree el archivo /etc/systemd/system/certbot.timer con este contenido:

[Unit]
Description=Run certbot twice daily

[Timer]
OnCalendar=*-*-* 00,12:00:00
RandomizedDelaySec=43200
Persistent=true

[Install]
WantedBy=timers.target

Luego, informe a systemd sobre los nuevos archivos.

# systemctl daemon-reload
# systemctl enable --now certbot.timer
1 me gusta

Si usa una configuración de dos contenedores, el tiempo de inactividad es inferior a un minuto y realmente no necesita una página de este tipo.

1 me gusta

Después de algunas búsquedas aquí, está bastante claro que el mantenimiento de dos contenedores es un trabajo mucho más exigente que Nginx. Al menos con mi nivel de habilidades.

2 Me gusta

Ah. Ya veo. Desde mi perspectiva es casi lo mismo, excepto que tienes que prestar atención a cuándo se debe actualizar el contenedor de fechas, lo cual es infrecuente, pero tienes que prestar atención. Y cuando eso sucede, el sitio está caído por un tiempo.

Eso también es cierto. Siempre es un compromiso: el tiempo que un foro estará inactivo debido a actualizaciones/mejoras frente al tiempo que requiere el mantenimiento de contenedores separados (y especialmente cuando tú (léase: yo) lo estropeas todo y empiezas a intentar encontrar algunas soluciones y el foro está inactivo al mismo tiempo :rofl: )

2 Me gusta

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.