Me pregunto si puedo resolver este problema vaciando Redis o actualizándolo; no ha sido modificado en los últimos 8+ meses. No he trabajado personalmente con Redis antes, pero nuestra instancia de Discourse Tests-Pass se configuró usando local_discourse en lugar del Discourse Docker que ahora se recomienda en este foro. Los problemas que estoy experimentando están relacionados con que los correos electrónicos no se envían a los usuarios. ¡Agradeceré cualquier ayuda y sugerencia!
Sidekiq no se está ejecutando. Muchas tareas, como el envío de correos electrónicos, se ejecutan de forma asíncrona mediante Sidekiq. Asegúrate de que al menos un proceso de Sidekiq se esté ejecutando.
¿Sería útil que usara el launcher para reconstruir o reiniciar el contenedor de Redis?
Uso: launcher COMANDO CONFIG [–skip-prereqs] [–docker-args CADENA]
Comandos:
start: Iniciar/inicializar un contenedor
stop: Detener un contenedor en ejecución
restart: Reiniciar un contenedor
destroy: Detener y eliminar un contenedor
enter: Abrir una shell para ejecutar comandos dentro del contenedor
logs: Ver los registros de Docker de un contenedor
bootstrap: Inicializar un contenedor para la configuración basada en una plantilla
run: Ejecutar el comando dado con la configuración en el contexto de la última imagen inicializada
rebuild: Reconstruir un contenedor (destruir el antiguo, inicializar, iniciar uno nuevo)
cleanup: Eliminar todos los contenedores que han estado detenidos por más de 24 horas
start-cmd: Generar el comando de Docker utilizado para iniciar el contenedor
Opciones:
–skip-prereqs No verificar los requisitos previos del launcher
–docker-args Argumentos adicionales para pasar al ejecutar Docker
–skip-mac-address No asignar una dirección MAC
–run-image Anular la imagen utilizada para ejecutar el contenedor
¿Lo instalaste siguiendo la Guía oficial de instalación estándar de Discourse o de alguna otra manera? Si tienes una instalación estándar, entonces sí, ejecutar ./launcher rebuild app probablemente solucionará tu problema.
Aún no, pero estamos fijando una fecha para la migración. Nuestro Discourse ha estado funcionando durante casi tres años y simplemente no quiero añadir tiempo de inactividad innecesario. Nuestra instancia es mantenida enteramente por voluntarios, así que en el último mes me he estado enseñando a mí mismo cómo mantenerla. Si una corrección rápida de Redis ayuda (ese contenedor ha estado funcionando durante un año sin tocarlo), me gustaría aplicarla.
Si no realizaste una instalación estándar desde el principio, es imposible adivinar qué podría solucionar tu problema actual.
Te sugiero configurar una nueva máquina virtual (VM) y realizar una instalación de prueba allí para asegurarte de que funcione. Al hacer la transferencia, puedes poner el foro antiguo en modo solo lectura, crear una copia de seguridad, restaurarla en la nueva VM y cambiar los registros DNS con casi ningún tiempo de inactividad. (De hecho, habrá un breve lapso, ya que necesitarás reconstruir después de cambiar los DNS para instalar un certificado de Let’s Encrypt).
Gracias, Let’s Encrypt debería ser bastante sencillo, ya que está configurado para ser una simple edición de proxy inverso en nginx. Es bueno saberlo y es de esperar que haya algún tiempo de inactividad. Solo hay que programarlo en un horario de menor actividad.
Estoy a punto de migrar y restaurar la copia de seguridad en las imágenes oficiales. ¿Hay algo que deba saber sobre la limpieza de correos electrónicos respaldados, etc., que podrían generar spam para los usuarios una vez que Sidekiq y otros servicios estén funcionando correctamente. ¡Gracias!
La cola de trabajos de Sidekiq no se migrará, por lo que se perderán muchos correos electrónicos, mientras que los resúmenes volverán a enviarse con normalidad.
Así que, al intentar seguir la documentación para instalar las imágenes oficiales de Docker de Discourse, nos hemos encontrado con problemas. Hemos concluido que nos faltan los contenedores de Redis, de recepción de correo y de datos que teníamos previamente en Docker.
Parece que nuestra instalación anterior incluía: app.yml data.yml mail-receiver.yml redis.yml
Esta configuración de múltiples contenedores difiere de las instrucciones de instalación básica. Tengo una copia de seguridad de nuestro antiguo /var/discourse para referencia.
FAILED │················································································································
-------------------- │················································································································
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 645 exit 1> │················································································································
Location of failure: /pups/lib/pups/exec_command.rb:112:in `spawn' │················································································································
exec failed with the params {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]} │················································································································
bbf0e57ac69f1febe2a5f149aa7e6e12541c3c23aaf199188fdf19d507254b58 │················································································································
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one. │················································································································
./discourse-doctor may help diagnose the problem.
Parece que nos saltamos el paso ./launcher bootstrap data ./launcher start redis
[Mon 11 May 2020 12:53:20 AM UTC] Ejecutando comando de recarga: sv reload nginx │················································································································
fail: nginx: runsv no está en ejecución │················································································································
[Mon 11 May 2020 12:53:20 AM UTC] Error de recarga para : │················································································································
[Mon 11 May 2020 12:53:21 AM UTC] Los dominios no han cambiado. │················································································································
[Mon 11 May 2020 12:53:21 AM UTC] Omitido, la próxima fecha de renovación es: Thu 09 Jul 2020 11:33:04 PM UTC │················································································································
[Mon 11 May 2020 12:53:21 AM UTC] Agrega '--force' para forzar la renovación. │················································································································
[Mon 11 May 2020 12:53:21 AM UTC] Instalando clave en: /shared/ssl/discuss.noisebridge.info_ecc.key │················································································································
[Mon 11 May 2020 12:53:21 AM UTC] Instalando cadena completa en: /shared/ssl/discuss.noisebridge.info_ecc.cer │················································································································
[Mon 11 May 2020 12:53:21 AM UTC] Ejecutando comando de recarga: sv reload nginx │················································································································
fail: nginx: runsv no está en ejecución │················································································································
[Mon 11 May 2020 12:53:21 AM UTC] Error de recarga para : │················································································································
run-parts: ejecutando /etc/runit/1.d/remove-old-socket │················································································································
runsvdir iniciado, PID es 626 │················································································································
ok: run: redis: (pid 636) 0s │················································································································
chgrp: grupo inválido: 'syslog' │················································································································
ok: run: postgres: (pid 639) 0s │················································································································
rsyslogd: imklog: no se puede abrir el registro del kernel (/proc/kmsg): Operación no permitida. │················································································································
rsyslogd: falló la activación del módulo imklog [v8.1901.0 intenta en https://www.rsyslog.com/e/2145 ] │················································································································
pid del supervisor: 640 pid de unicorn: 667
Eso es correcto, los importadores lo configuraron para que no envíes 50,000 correos electrónicos después de una migración. Activa los correos electrónicos con cuidado en la configuración de tu sitio.
Nuestra instancia es mantenida enteramente por voluntarios, así que en el último mes me he estado enseñando a mí mismo cómo mantenerla. Si una corrección rápida de Redis ayuda (ese contenedor ha estado funcionando durante un año sin tocarlo), me gustaría aplicarla.