Reinicié la VM; ahora la página `/admin/upgrade` no carga, las solicitudes JS fallan, algunas imágenes de avatar devuelven 404

Información de fondo: el sitio es lot.almost-dead.net, versión 2.8.0.beta4, alojado en Google Cloud/Compute; seguí la guía oficial basada en Docker para configurarlo. (Tengo experiencia con tecnologías front-end de navegador y entiendo los conceptos generales del alojamiento en la nube, pero estoy familiarizado con AWS y no con Google.)

Causa preliminar: detuve la instancia de VM y luego la reinicié (intentando ajustar las variables de entorno expuestas a Discourse).

Cuando la VM volvió y el sitio se restableció, noté que los activos de JS estaban agotando el tiempo de espera, al igual que algunos avatares de usuario. En el panel de administración, el área de Salud de la Comunidad no carga; el indicador de carga sigue girando y, en las Herramientas de Desarrollador de Chrome, la pestaña de Red muestra que todas las solicitudes /message-bus/.../poll fallan. La página de Actualización (/admin/upgrade) falla casi de inmediato y Chrome muestra el código ERR_FAILED. Al navegar por los temas, veo que las solicitudes POST fallan con ERR_CONNECTION_REFUSED y las solicitudes GET iniciadas por JS fallan con ERR_FAILED. (Esto es desde un navegador que tiene cookies de inicio de sesión configuradas para mi cuenta de administrador.)

Cargar el sitio desde una instancia de navegador nueva muestra el error ERR_CONNECTION_REFUSED de Chrome.

Lo que he intentado:

  • reconstrucción del lado del servidor: sudo ./launcher rebuild app parece tener éxito, pero no hay cambios en el comportamiento del sitio
    • también intenté comentar los complementos y reconstruir, sin cambios
  • modo seguro: solicitar /safe-mode resulta inmediatamente en la página ERR_FAILED de Chrome

¿Alguna sugerencia?

¿Has probado

apt-get update
apt-get upgrade

y luego una reconstrucción?

Lo intenté hace un momento y parece ser lo mismo que antes.

No, tu sitio no está activo; está completamente caído. Estás viendo parcialmente la caché. Para alguien que nunca visitó tu sitio, este no responde en absoluto. Esto probablemente sea algo a nivel de red/firewall, o nginx no está iniciando o se está bloqueando.

Entiendo, tiene sentido.

Una vez que ejecuto sudo ./launcher enter app, parece que nginx se está ejecutando…

root@adn-prod-app:/var/www/discourse# ps aux | grep nginx
root       548  0.0  0.0   2156    64 ?        Ss   07:04   0:00 runsv nginx
root       558  0.0  0.1  55236  2524 ?        S    07:04   0:00 nginx: master process /usr/sbin/nginx
www-data   567  0.0  0.2  55996  5068 ?        S    07:04   0:00 nginx: worker process
www-data   568  0.0  0.0  55996  1628 ?        S    07:04   0:00 nginx: worker process
www-data   569  0.0  0.0  55792  1680 ?        S    07:04   0:00 nginx: cache manager process
root     23179  0.0  0.0   6140   884 pts/1    S+   21:23   0:00 grep nginx

No estoy lo suficientemente familiarizado con Google Cloud como para saber qué buscar en su configuración de red/firewall… Sí noto que la instancia de VM tiene las etiquetas “http-server” y “https-server”, y que su sistema de firewall parece utilizar esas etiquetas para aplicar las reglas integradas “default-allow-http” y “default-allow-https” a las instancias con dichas etiquetas. Esto me parece correcto, y nslookup muestra que el subdominio que estoy usando se está resolviendo a la dirección IP externa que aparece en la interfaz de usuario de Google, sin embargo, el mundo exterior todavía no puede acceder a la instancia.

En /var/discourse/shared/standalone/log/rails/production.log veo errores al conectarse a Redis; ¿hay alguna forma de repararlo?

Excepción de trabajo: Error al conectarse a Redis en localhost:6379 (Errno::EADDRNOTAVAIL)
Excepción de trabajo: Error al conectarse a Redis en localhost:6379 (Errno::EADDRNOTAVAIL)
Excepción de trabajo: Error al conectarse a Redis en localhost:6379 (Errno::EADDRNOTAVAIL)
Excepción de trabajo: Error al conectarse a Redis en localhost:6379 (Errno::EADDRNOTAVAIL)
Excepción de trabajo: Error al conectarse a Redis en localhost:6379 (Errno::EADDRNOTAVAIL)
Excepción de trabajo: Error al conectarse a Redis en localhost:6379 (Errno::EADDRNOTAVAIL)
Error al conectarse a Redis en localhost:6379 (Errno::EADDRNOTAVAIL) suscripción fallida, reconectando en 1 segundo. Pila de llamadas /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:384:in `rescue in establish_connection'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:365:in `establish_connection'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:117:in `block in connect'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:330:in `with_reconnect'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:116:in `connect'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:403:in `ensure_connected'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:255:in `block in process'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:342:in `logging'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:254:in `process'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:148:in `call'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/rack-mini-profiler-2.3.3/lib/mini_profiler/profiling_methods.rb:85 :in `block in profile_method'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis.rb:959:in `block in get'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis.rb:70:in `block in synchronize'
/usr/local/lib/ruby/2.7.0/monitor.rb:202:in `synchronize'
/usr/local/lib/ruby/2.7.0/monitor.rb:202:in `mon_synchronize'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis.rb:70:in `synchronize'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis.rb:958:in `get'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/message_bus-3.3.6/lib/message_bus/backends/redis.rb:361:in `process_global_backlog'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/message_bus-3.3.6/lib/message_bus/backends/redis.rb:269:in `block in global_subscribe'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/message_bus-3.3.6/lib/message_bus/backends/redis.rb:282:in `global_subscribe'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/message_bus-3.3.6/lib/message_bus.rb:781:in `global_subscribe_thread'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/message_bus-3.3.6/lib/message_bus.rb:729:in `block in new_subscriber_thread'
Excepción de trabajo: Error al conectarse a Redis en localhost:6379 (Errno::EADDRNOTAVAIL)
Creando ámbito :open. Sobrescribiendo el método existente Poll.open.

Hola,
es un intento poco probable, pero la última vez que vi un error de Redis estaba relacionado de alguna manera con (bueno, digamos que en el mismo tema que) los certificados SSL (¿faltantes?).
¿Quizás ./launcher logs app podría ayudar?

Ah, hay algunas advertencias de nginx aquí, seguidas de este mensaje que parece que le falta un identificador: Reload error for :

$ sudo ./launcher logs app
run-parts: ejecutando /etc/runit/1.d/00-ensure-links
run-parts: ejecutando /etc/runit/1.d/00-fix-var-logs
run-parts: ejecutando /etc/runit/1.d/01-cleanup-web-pids
run-parts: ejecutando /etc/runit/1.d/anacron
run-parts: ejecutando /etc/runit/1.d/cleanup-pids
Limpieza de archivos PID obsoletos
run-parts: ejecutando /etc/runit/1.d/copy-env
run-parts: ejecutando /etc/runit/1.d/letsencrypt
[Mar 14 Sep 2021 10:44:41 PM UTC] Los dominios no han cambiado.
[Mar 14 Sep 2021 10:44:41 PM UTC] Omitido, la próxima fecha de renovación es: Mar 5 Oct 00:05:09 UTC 2021
[Mar 14 Sep 2021 10:44:41 PM UTC] Agregue '--force' para forzar la renovación.
[Mar 14 Sep 2021 10:44:42 PM UTC] Instalando clave en:/shared/ssl/lot.almost-dead.net.key
[Mar 14 Sep 2021 10:44:42 PM UTC] Instalando cadena completa en:/shared/ssl/lot.almost-dead.net.cer
[Mar 14 Sep 2021 10:44:42 PM UTC] Ejecutando comando de recarga: sv reload nginx
advertencia: nginx: no se pudo abrir supervise/ok: el archivo no existe
[Mar 14 Sep 2021 10:44:42 PM UTC] Error de recarga para :
[Mar 14 Sep 2021 10:44:42 PM UTC] Los dominios no han cambiado.
[Mar 14 Sep 2021 10:44:42 PM UTC] Omitido, la próxima fecha de renovación es: Lun 4 Oct 00:06:04 UTC 2021
[Mar 14 Sep 2021 10:44:42 PM UTC] Agregue '--force' para forzar la renovación.
[Mar 14 Sep 2021 10:44:43 PM UTC] Instalando clave en:/shared/ssl/lot.almost-dead.net_ecc.key
[Mar 14 Sep 2021 10:44:43 PM UTC] Instalando cadena completa en:/shared/ssl/lot.almost-dead.net_ecc.cer
[Mar 14 Sep 2021 10:44:43 PM UTC] Ejecutando comando de recarga: sv reload nginx
advertencia: nginx: no se pudo abrir supervise/ok: el archivo no existe
[Mar 14 Sep 2021 10:44:43 PM UTC] Error de recarga para :
Iniciado runsvdir, PID es 546
ok: run: redis: (pid 554) 0s
ok: run: postgres: (pid 560) 0s
chgrp: grupo inválido: 'syslog'
pid del supervisor: 558 pid de unicorn: 579
Apagando
run-parts: ejecutando /etc/runit/3.d/01-nginx
ok: down: nginx: 1s, normalmente up
run-parts: ejecutando /etc/runit/3.d/02-unicorn
(558) saliendo
ok: down: unicorn: 0s, normalmente up
run-parts: ejecutando /etc/runit/3.d/10-redis
ok: down: redis: 0s, normalmente up
run-parts: ejecutando /etc/runit/3.d/99-postgres
ok: down: postgres: 0s, normalmente up
ok: down: nginx: 3s, normalmente up
ok: down: postgres: 1s, normalmente up
ok: down: redis: 2s, normalmente up
ok: down: cron: 0s, normalmente up
ok: down: unicorn: 2s, normalmente up
ok: down: rsyslog: 0s, normalmente up
run-parts: ejecutando /etc/runit/1.d/00-ensure-links
run-parts: ejecutando /etc/runit/1.d/00-fix-var-logs
run-parts: ejecutando /etc/runit/1.d/01-cleanup-web-pids
run-parts: ejecutando /etc/runit/1.d/anacron
run-parts: ejecutando /etc/runit/1.d/cleanup-pids
Limpieza de archivos PID obsoletos
run-parts: ejecutando /etc/runit/1.d/copy-env
run-parts: ejecutando /etc/runit/1.d/letsencrypt
[Mar 14 Sep 2021 10:54:00 PM UTC] Los dominios no han cambiado.
[Mar 14 Sep 2021 10:54:00 PM UTC] Omitido, la próxima fecha de renovación es: Mar 5 Oct 00:05:09 UTC 2021
[Mar 14 Sep 2021 10:54:00 PM UTC] Agregue '--force' para forzar la renovación.
[Mar 14 Sep 2021 10:54:00 PM UTC] Instalando clave en:/shared/ssl/lot.almost-dead.net.key
[Mar 14 Sep 2021 10:54:01 PM UTC] Instalando cadena completa en:/shared/ssl/lot.almost-dead.net.cer
[Mar 14 Sep 2021 10:54:01 PM UTC] Ejecutando comando de recarga: sv reload nginx
fail: nginx: runsv no se está ejecutando
[Mar 14 Sep 2021 10:54:01 PM UTC] Error de recarga para :
[Mar 14 Sep 2021 10:54:01 PM UTC] Los dominios no han cambiado.
[Mar 14 Sep 2021 10:54:01 PM UTC] Omitido, la próxima fecha de renovación es: Lun 4 Oct 00:06:04 UTC 2021
[Mar 14 Sep 2021 10:54:01 PM UTC] Agregue '--force' para forzar la renovación.
[Mar 14 Sep 2021 10:54:01 PM UTC] Instalando clave en:/shared/ssl/lot.almost-dead.net_ecc.key
[Mar 14 Sep 2021 10:54:01 PM UTC] Instalando cadena completa en:/shared/ssl/lot.almost-dead.net_ecc.cer
[Mar 14 Sep 2021 10:54:01 PM UTC] Ejecutando comando de recarga: sv reload nginx
fail: nginx: runsv no se está ejecutando
[Mar 14 Sep 2021 10:54:01 PM UTC] Error de recarga para :
Iniciado runsvdir, PID es 539
ok: run: redis: (pid 549) 0s
ok: run: postgres: (pid 555) 0s
chgrp: grupo inválido: 'syslog'
pid del supervisor: 551 pid de unicorn: 579
$

No estoy seguro de por qué, pero ¿podrían faltar?

Los veo dentro de la aplicación…

root@adn-prod-app:/var/www/discourse# ls -l /shared/ssl/
total 24
-rw-r--r-- 1 root root 5950 Sep 14 22:54 lot.almost-dead.net.cer
-rw-r--r-- 1 root root 5329 Sep 14 22:54 lot.almost-dead.net_ecc.cer
-rw------- 1 root root  302 Sep 14 22:54 lot.almost-dead.net_ecc.key
-rw------- 1 root root 3243 Sep 14 22:54 lot.almost-dead.net.key

:facepalm: Parece que mi problema era que la VM se reinició con una dirección IP diferente y necesitaba modificar mi registro A para que apuntara a la nueva dirección.

El sitio está de nuevo en línea, ¡gracias por escucharme!