Cool good to know, thanks for your feedback
The first post says this
Is this the only way to do it? We don’t have nginx running outside docker
Yes, that’s the only way. The idea is to install a webserver (nginx recommended) to serve the request, if Discourse is up it routes it there. If not it does something else. All the installation process is explained step by step.
2 Me gusta
Hola,
Introducción
Gracias por esa solución, @fefrei! La hemos implementado en https://community.hiveeyes.org/ y funciona de maravilla.
Reflexiones adicionales
Sin embargo, nos gustaría hacer referencia a la pregunta relacionada de @mlinksva en Site maintenance mode during rebuilds?, ya que esto también nos resuena y aún no se resuelve con la solución de /errorpages. Se trata de mejorar el texto genérico: “Lo sentimos, no pudimos cargar ese tema, posiblemente debido a un problema de conexión.”. Intentaremos detallarlo más.
Servir discourse_offline.html
Esto es perfecto cuando los usuarios llegan por primera vez al sitio.
Mostrar un mensaje diferente de “Lo sentimos”
Sin embargo, al navegar dentro de Discourse, te gritará algo como
sin revelar nada sobre la razón.
Como ya te conocemos, probablemente habrá una función de personalización para poder cambiar ese texto, ¿verdad? Quizás simplemente nos lo hayamos perdido. Tampoco hemos investigado si la función Administración » Copia de seguridad » Habilitar modo solo lectura ya resolvería esto, tal como se describe en Maintenance Mode?.
No obstante, nos pareció lógico retomar este tema aquí nuevamente y esperamos que no te importe si fue una tontería.
Atentamente,
Andreas.
P.D.: @staff: Como esta discusión de alguna manera se salió de control en cuanto a los detalles adecuados de configuración de Nginx o del servidor web, me gustaría sugerir una reestructuración completa dividiendo estos mensajes en un tema con un nombre apropiado, como “Configuración del servidor web para la página sin conexión”. Estoy seguro de que encontrarás un buen título. Gracias de antemano si te gusta esta sugerencia y consideras que vale la pena seguirla.
Ahora, en realidad nos sentimos tontos al encontrarlo de inmediato como un bloque de texto de sitio personalizable:
– https://community.hiveeyes.org/admin/customize/site_texts/js.topic.server_error.description
Hemos cambiado el texto predeterminado js.topic.server_error.description para que diga:
Gracias por escucharnos ;].
3 Me gusta
Hm. No estamos seguros de si cambiar ese texto realmente funciona para nosotros. ¿Hay algo especial que debamos considerar al modificar esto?
Además, nos gustaría mencionar que, durante un período específico en el que el sitio estaba fuera de línea, mostraba un mensaje diferente, como este:
¿Tienes alguna idea de cómo podríamos cambiar eso también?
1 me gusta
Lo uso, pero quiero una página web offline personalizada y no puedo hacerlo.
¡Guía maravillosa!
Pero sería perfecto si también incluyeras algunos comandos para renovar automáticamente este certificado. Así sería una guía completa.
He visto el enlace mencionado aquí, pero solo explica cómo instalar el certificado desde cero o renovarlo manualmente.
No logré encontrar instrucciones sobre cómo configurarlo para que se renueve automáticamente.
Gracias.
1 me gusta
¡Buen punto! He actualizado esta sección arriba en la publicación original 
1 me gusta
¿Alguien más ha notado que se muestra un error 500 más genérico cuando se produce la actualización? ¿Quizás lo vi en un momento inadecuado?
1 me gusta
Cuando el contenedor se detiene durante una reconstrucción, no hay ningún proceso en ejecución que proporcione un error 500.
4 Me gusta
¿Alguien ha intentado usar otro contenedor de Docker para eso, evitando todos estos pasos manuales, como se sugirió al principio?
Sí, muchos lo han hecho. Consulta Move from standalone container to separate web and data containers. Ten en cuenta que usar contenedores separados es una instalación más compleja, y muchas de las guías aquí en Meta asumen una instalación de un solo contenedor (autónomo). Antes de pasar a contenedores separados, asegúrate de entender qué hace cada uno de los dos contenedores y cómo interactuarás con ellos en el futuro. El punto más importante a considerar: app ya no será un destino válido para el comando ./launcher.
5 Me gusta
hm, por alguna razón este tema todavía menciona “nginx al frente” en dos publicaciones…
por cierto, lo que realmente quiero es
- tener la página sin conexión discutida aquí
- redirigir http → https y el dominio raíz → www en mi servidor web. No quiero usar Cloudflare para eso porque algunas de sus IPs están bloqueadas en Rusia.
Así que, según entiendo, solo necesito averiguar cómo hacerlo en el contenedor solo web 
Ahora estoy confundido.
Ninguno de estos objetivos requiere una configuración de contenedor separada. ¿Buscas configurar ambos pasos anteriores y, de forma independiente, buscas contenedores separados? ¿O estabas pensando en contenedores separados creyendo que eran necesarios para completar lo anterior?
Según mi entendimiento, la gestión de la página sin conexión (reconstrucción) no puede estar en el mismo contenedor, ya que no se estará ejecutando. Por lo tanto, la solución propuesta en el tema actual es agregar nginx al frente. Pero, como se discutió en este tema, requiere muchos pasos manuales y es específico del sistema operativo, así que pensé que usar otro contenedor Docker para este nginx frontal sería más confiable y más fácil de mantener.
Ah, ahora te entiendo. En ese caso, ignora el tema que enlacé anteriormente. Ese tema trata sobre separar el servidor web de Discourse de la base de datos, lo cual no es necesario en este caso.
Instalar Nginx en un contenedor Docker, en lugar de hacerlo directamente en el sistema operativo, es definitivamente posible, pero no conozco ninguna guía específica de Discourse para hacerlo. Si decides seguir este camino, asegúrate de entender el OP de este tema (los cambios necesarios para crear la página offline e instalar un proxy nginx delante) y de que tienes conocimientos sólidos sobre cómo funciona Docker, especialmente en la configuración de la red entre dos contenedores Docker. Ten en cuenta también que es probable que tengamos limitaciones para brindarte ayuda, ya que no es algo con lo que tengamos experiencia.
También me he dado cuenta de que esto ya no funciona.
Había implementado el enfoque de @fefrei a principios de noviembre y definitivamente funcionaba entonces. Quizás sea porque estaba deteniendo el contenedor manualmente y haciendo un git pull en lugar de usar /admin/upgrade.
1 me gusta
4 publicaciones se dividieron en un nuevo tema: Agregar soporte para una página sin conexión nativa al reconstruir
Hicimos exactamente eso recientemente y la página offline se activó correctamente.
Ahora mismo, acabamos de realizar la actualización en línea a través de /admin/upgrade y descubrimos que Discourse no se puso offline en absoluto. Independientemente de si esto ha mejorado recientemente o no, o si simplemente hemos tenido suerte esta vez, es genial ver una actualización en línea sin experimentar ningún comportamiento significativo de tiempo de inactividad.
Discourse nunca debería ponerse en modo offline al ejecutar actualizaciones a través de Docker Manager (/admin/upgrade). ¿Suele ponerse en modo offline para ti? Si es así, deberíamos crear un tema de #soporte sobre eso.