Actualización fallando con FAILED TO BOOTSTRAP

Al intentar actualizar nuestra instancia de Discourse, hoy requirió un git pull, pero el ./launcher rebuild está fallando con FAILED TO BOOTSTRAP y aún no veo de dónde proviene la falla.

Estamos ejecutando Discourse en Ubuntu 18.04. Todo ha ido bien hasta la actualización de hoy.

Nuestro app.yml se llama web.yml, así que ejecuté:

# git pull
# ./launcher rebuild web

La cola de la salida se ve así:

I, [2022-02-18T19:25:46.155360 #1]  INFO -- : > cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate'
Discourse requires Redis 6.2.0 or up
I, [2022-02-18T19:25:55.644442 #1]  INFO -- : gem install sawyer -v 0.8.2 -i /var/www/discourse/plugins/discourse-github/gems/2.7.5 --no-document --ignore-dependencies --no-user-install
Successfully installed sawyer-0.8.2
1 gem installed
gem install octokit -v 4.21.0 -i /var/www/discourse/plugins/discourse-github/gems/2.7.5 --no-document --ignore-dependencies --no-user-install
Successfully installed octokit-4.21.0
1 gem installed
 
 
 
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 1121 exit 1>
Location of failure: /usr/local/lib/ruby/gems/2.7.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
85459e34ac2c6275dd1700de2c469124a9fded84800b8c6b4686c1c6b66824e2
** 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.

Salida completa aquí

Estos son nuestros plugins actuales:

discourse/docker_manager.git
discourse/discourse-github.git
discourse/discourse-solved.git
discourse/discourse-data-explorer.git
discourse/discourse-akismet.git
discourse/discourse-spoiler-alert.git
cpradio/discourse-plugin-replygif.git
discourse/discourse-push-notifications.git
discourse/discourse-chat-integration

Cuando escaneo la salida del lanzador, no veo el error que está causando la falla. ¿Alguna sugerencia sobre qué podría estar causando la falla?

Intenté revertir el commit anterior para ver si podía reconstruir con éxito nuestro contenedor web sin el último cambio, pero todavía falla con un error de arranque. :confused:

Actualización:

Estábamos usando una configuración de contenedores separada, que aparentemente no es una buena idea, y nuestro contenedor de datos estaba obsoleto, ejecutando Redis v5.0.5 (Discourse actualmente requiere 6.2.0+). Por lo tanto, reconstruimos nuestro contenedor de datos y luego los contenedores web con éxito. Después de esta experiencia, probablemente abandonaremos el enfoque de múltiples contenedores en el futuro.

¡Gracias a @pfaffman por los enlaces increíblemente útiles!

¿Qué Redis estás usando?

Ver también Skip Redis Version Check

Ah. Ya veo. Estamos ejecutando discourse_docker con contenedores web y de datos enlazados, por lo que Redis se está ejecutando dentro de nuestro contenedor de datos.

Dentro de nuestro contenedor de datos:

# redis-server --version
Redis server v=5.0.5

Así que eso lo explica. Parece que necesitamos actualizar también nuestro contenedor de datos. Eso me pone más nervioso. ¿Cuándo se añadió ese requisito? Quizás podría volver a una versión anterior del contenedor web hasta que mis refuerzos (en Australia) estén despiertos y disponibles. :wink:

Vaya. Si reviso el historial de git, parece que la versión de Redis no ha estado en el rango de 5.x en dos años. Pero sé que hemos realizado algunas actualizaciones exitosas en el camino (incluyendo git pulls).

Basado en Omitir la verificación de la versión de Redis, parece que recientemente comenzaron a aplicarse. Ya he cavado un hoyo lo suficientemente grande para un viernes y no quiero intentar actualizar nuestro contenedor de datos sin ayuda… así que intentaré revertir a una versión anterior de docker_discourse para ver si puedo volver a un estado donde el requisito de Redis no se aplique por ahora (hasta que podamos actualizar nuestro contenedor de datos).

1 me gusta

Eso no funcionará, ya que la verificación proviene del repositorio principal. Dejar los contenedores de datos sin actualizaciones durante varios años no es bueno, ya que hemos enviado correcciones de rendimiento y seguridad muchas veces en ese período.

Aún otra razón por la que no recomiendo la configuración de contenedores separados.

3 Me gusta

Necesitas reconstruir el contenedor de datos. Consulta también Actualización de PostgreSQL 13

2 Me gusta

Gracias. Estamos esperando la actualización de Postgres mientras hablamos. :slight_smile:

Y gracias por el enlace a los consejos de actualización de Postgres 13. ¡Muy útil!

2 Me gusta

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.