Maybe we just implemented the offline page because we started using the upgrade procedure »stop container, git pull, launcher rebuild« after being hit by things like [1,2,3] for a few times actually.
Maybe something changed on the robustness of killing PostgreSQL if it wouldn’t shutdown in time to run through the upgrade process smoothly.
Either way, the online upgrade (again) worked well for us when giving it another shot right now. So, nevermind and sorry for the noise.
Eso es un poco confuso, ya que lo que sigue es una guía para instalar y configurar nginx fuera del contenedor.
En cualquier caso, hoy me di cuenta de un beneficio adicional de esta configuración externa de nginx: si estás acostumbrado a ver direcciones IP como 127.0.0.1 o tu dirección Docker (probablemente comenzando con 172.) como dirección IP de registro o inicio de sesión, podría haber sido porque el tráfico IPv6 que se reenvía al contenedor no transportaba su dirección IPv6 junto con él, a diferencia de IPv4. Con esta configuración, ahora verás direcciones IPv6 correctas en lugar de direcciones locales.
En otras palabras, esta configuración es esencialmente necesaria para el funcionamiento correcto de una herramienta administrativa útil en el internet cada vez más IPv6. (En EE. UU., esto incluye mucho tráfico móvil.)
¡Gracias por esta guía tan útil! Un par de comentarios:
Creo que sudo apt-get install letsencrypt ha sido reemplazado por sudo apt-get install certbot. Al ejecutar el primero, aparece el aviso Note, selecting 'certbot' instead of 'letsencrypt'.
Un amigo notó que al compartir el sitio en Facebook aparecía una vista previa de “301 moved permanently”.
Edición: Originalmente había reemplazado la sección location / del bloque de servidor del puerto 80 con la sección location / del bloque de servidor del puerto 443. Pero creo que eso es redundante. En su lugar, simplemente eliminé el bloque de servidor del puerto 80, que servía como bloque de redirección, y agregué:
listen [::]:80;
listen 80;
en la sección correspondiente del bloque de servidor principal.
También habilité la redirección a HTTPS (no estoy seguro si es necesario) desde la configuración de Discourse.
Eso solucionó el problema con la compartición en Facebook, y parece que las solicitudes HTTP normales se están redirigiendo a HTTPS. Si existe otro método o uno mejor, por favor házmelo saber.
Gracias por el tutorial, es excelente. Ahora mi página 502 se ve mucho mejor.
En mi caso práctico, tengo que agregar la configuración de nginx al archivo /etc/nginx/sites-enabled/discourse.conf.
He instalado Discourse correctamente después de que nginx estuviera ejecutando WordPress.
Me encontré con el problema de que nginx no conocía el certificado renovado porque no se reinició tras la instalación siguiendo esta guía. Para mí, la solución fue:
Gracias por el tutorial, que funciona bastante bien para mí.
Solo me preguntaba: si, por ejemplo, Googlebot ve esa página de error, ¿sabe que se trata de una página temporal? ¿O necesitamos enviar algún tipo de código de error para que sea consciente del carácter temporal del cambio?
Preferiría no ver que Google elimine toda la indexación de mi foro debido a una página de error más elaborada…
Google debería interpretar los errores 500/502 como una señal para “volver más tarde”. Mientras tu sitio no esté en reconstrucción con demasiada frecuencia, no deberías tener problemas.
He estado ejecutando mi foro detrás de nginx durante mucho tiempo y esto no ha tenido un efecto adverso en el posicionamiento.
Esto significa: "Al encontrar (o generar) un código de respuesta 502 Bad Gateway, envía el contenido del archivo /errorpages/discourse_offline.html con un código de respuesta 502 Bad Gateway. El = es lo que le indica qué código de respuesta HTTP enviar.
¡Todo está bien!
Y coincido con @ashs; un minuto o menos de errores 502 una o dos veces al mes no ha dañado la búsqueda. A menudo veo publicaciones recientes en los resultados de Google.
Un error 502 probablemente indica que Nginx no se está iniciando, posiblemente debido a un error de configuración. Ejecutar nginx -t te indica si el archivo de configuración parece correcto. Si no hay errores, ejecuta systemctl status nginx.service para verificar el estado del servicio Nginx.
Mi pregunta está directamente relacionada con el título del tema, pero no con el método utilizado en este tema, así que espero que esté bien mantenerla en esta discusión.
Configuré algo muy sencillo para resolver este problema y tengo una pregunta específica.
Creé un droplet separado en DigitalOcean e instalé un servidor LAMP a través del mercado. Luego subí una página HTML básica con algunas imágenes para indicar que el servidor estaba en mantenimiento. Después, asignaría una IP flotante entre mi servidor Discourse habitual y este servidor de mantenimiento según fuera necesario.
Aquí está la pregunta: para que el servidor de “mantenimiento” cargue correctamente, finalmente necesité obtener un certificado a través de Certbot para ese servidor (además del que ya tenía para la instancia principal de Discourse). En otras palabras, dos certificados para el mismo dominio en servidores diferentes. Funcionó, pero siempre me ha preocupado si eso podría causar problemas en el futuro. La información que he leído en línea sugiere que está bien tener esto, pero quería ver si alguien ha tenido experiencia directa con esto.
Esto es perfectamente válido. Sin embargo, dependiendo de cómo realices la validación, las renovaciones de certificados podrían no funcionar: por ejemplo, si tu servidor de “mantenimiento” utiliza validación basada en HTTP, esto fallará mientras el dominio no apunte a él, lo que probablemente anula el propósito. Podría tener sentido que el servidor de mantenimiento copie ocasionalmente el certificado más reciente desde el servidor principal en lugar de solicitar uno a Let’s Encrypt.
Admito que no tengo ni idea de si mi servidor está utilizando validación basada en HTTP (simplemente lo hice todo a través de ese increíble certbot), pero tu preocupación es totalmente lógica. Busqué un poco, pero no encontré ningún recurso sobre cómo copiar certificados como sugieres. Además, asumo que necesitaría configurar algún tipo de tarea programada (cron job). Si tienes más sugerencias, sería genial. De lo contrario, gracias de nuevo por tu ayuda.
Para copiar archivos directamente de servidor a servidor, scp o rsync son buenas herramientas para usar – este puede ser un buen lugar para empezar.
Mi sugerencia sería, de hecho, configurar un trabajo cron para copiar el certificado del servidor principal al servidor de mantenimiento de forma regular.
Ah, y para explicar el contexto de la validación basada en HTTP: para verificar que el dominio realmente te pertenece, Let’s Encrypt solicitará un archivo específico de tu servidor y esperará una respuesta concreta. Certbot puede manejar esto automáticamente (configurando temporalmente tu servidor para devolver este archivo ante la solicitud de validación), pero, por supuesto, esto solo funciona si la solicitud realmente llega a tu servidor. Si tu DNS no apunta a tu servidor, o has movido la IP a otro lugar, la solicitud irá al servidor equivocado, Let’s Encrypt no recibirá la respuesta esperada y se negará a firmar el certificado.
Si desea una página de “en construcción” mientras el sitio se reconstruye, deberá realizar los tediosos pasos anteriores. Recomendaría cambiar a una instalación de 2 contenedores, que es algo más problemática de mantener (hay que saber cuándo reconstruir el contenedor de datos), pero solo tiene unos 30 segundos de inactividad cuando se inicia el nuevo contenedor, aunque actualmente requiere una cantidad considerable de RAM (2 GB podría no ser suficiente, pero no estoy del todo seguro).
