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
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.
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?
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!