Migrar Discourse de una droplet de DigitalOcean a otra sin tiempo de inactividad

Estamos migrando a un nuevo droplet de DigitalOcean y hemos intentado usar la imagen del mercado. Al ejecutar el script de configuración, falla rápidamente porque nuestro nombre de dominio aún apunta a nuestra instancia actual en producción.

Necesito tener esta nueva instalación operativa para poder restaurar su copia de seguridad y, posteriormente, actualizar los registros DNS.

El error es:

Verificando tu nombre de dominio . . .
ADVERTENCIA: El puerto 443 del equipo no parece ser accesible usando el nombre de host: x
ADVERTENCIA: La conexión a x (puerto 80) también falla.

Esto sugiere que x se resuelve a una dirección IP que no llega a esta
máquina donde estás instalando Discourse.

Lo primero que debes hacer es confirmar que x se resuelve a la dirección IP de este servidor.
Por lo general, esto se hace en el mismo lugar donde compraste el dominio.

Si estás seguro de que la dirección IP se resuelve correctamente, podría ser un problema de firewall.
Una búsqueda en la web sobre "abrir puertos TU_SERVICIO_EN_LA_NUBE" podría ayudar.

El nombre de dominio en realidad responde en los puertos 80 y 443, por lo que este mensaje de error también parece ser incorrecto.

Hola Matt,

Nosotros (el equipo de Discourse) no gestionamos la imagen del marketplace de DO, así que temo que no podamos ayudarte mucho a resolver ese problema en particular.

Pero tú gestionas esto, ¿verdad?

Incluso las instrucciones de instalación manual incluyen este paso.

Seguro que no puedo ser la primera persona en hacer esto. ¿Cómo lo hace la gente?

Sí, nosotros gestionamos eso. No revisé el código, asumí que la verificación provenía de la imagen del marketplace.

./discourse-setup está diseñado como una forma sencilla de configurar Discourse, evitando la necesidad de editar manualmente un archivo de texto al crear un nuevo sitio de Discourse. Tu caso de uso no es “típico” para lo que maneja el script de configuración.

En tu caso, lo más recomendable sería copiar el archivo containers/app.yml desde tu servidor actual al nuevo. Alternativamente, puedes editar el archivo manualmente como se sugiere en las líneas 75/76:

1 me gusta

¿Dónde puedo encontrar el archivo app.yml predeterminado? Quiero comenzar con una instalación predeterminada limpia.

Además, ¿cómo puedo iniciar el servidor sin el script de configuración? El acceso a la dirección IP sigue sin responder, ya que no puedo ejecutar el script de configuración.

El valor predeterminado se encuentra en samples/standalone.yml. También en GitHub.

Si estás siguiendo la guía de instalación oficial, después de los comandos en “Instalar Discourse”, deberás hacer lo siguiente:

Copia el archivo YAML predeterminado de samples a containers:

cp samples/standalone.yml containers/app.yml

Edita el archivo manualmente:

nano containers/app.yml

Inicializa e inicia Discourse:

./launcher rebuild app

Gracias, eso me acerca un poco más.

Pero ahora no puedo importar la copia de seguridad porque no puedo activar mi cuenta de administrador temporal:

(6) Se ha denegado la carga del script ‘’ porque viola la siguiente directiva de la Política de Seguridad de Contenido: “script-src ”. Tenga en cuenta que ‘script-src-elem’ no se estableció explícitamente, por lo que se utiliza ‘script-src’ como alternativa.

¿Existe una forma directa de restaurar desde una copia de seguridad o desactivar la CSP hasta entonces?

Conéctate por SSH a tu servidor, luego:

cd /var/discourse
sudo ./launcher enter app
rails c
SiteSetting.content_security_policy = false
exit
exit

Ten en cuenta que te sugiero intentar primero la restauración de la copia de seguridad desde la CLI; esto resuelve el problema real que tienes (restaurar una copia de seguridad) en lugar del obstáculo actual (CSP).

1 me gusta

Gracias por las indicaciones.

Al ejecutar la restauración, obtengo:

ERROR:  no se pudo crear el índice único "index_incoming_referers_on_path_and_incoming_domain_id"
DETALLE:  La clave (path, incoming_domain_id)=(/s/free+proxy+hideip.me, 1009) está duplicada.
EXCEPCIÓN: psql falló: DETALLE:  La clave (path, incoming_domain_id)=(/s/free+proxy+hideip.me, 1009) está duplicada.
/var/www/discourse/lib/backup_restore/database_restorer.rb:87:in `restore_dump'
/var/www/discourse/lib/backup_restore/database_restorer.rb:26:in `restore'
/var/www/discourse/lib/backup_restore/restorer.rb:51:in `run'
script/discourse:143:in `restore'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.0.1/lib/thor/command.rb:27:in `run'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.0.1/lib/thor/invocation.rb:127:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.0.1/lib/thor.rb:392:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.0.1/lib/thor/base.rb:485:in `start'
script/discourse:284:in `<top (required)>'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/lib/bundler/cli/exec.rb:63:in `load'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/lib/bundler/cli/exec.rb:63:in `kernel_load'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/lib/bundler/cli/exec.rb:28:in `run'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/lib/bundler/cli.rb:497:in `exec'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/lib/bundler/vendor/thor/lib/thor.rb:392:in `dispatch'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/lib/bundler/cli.rb:30:in `dispatch'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/lib/bundler/vendor/thor/lib/thor/base.rb:485:in `start'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/lib/bundler/cli.rb:24:in `start'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/exe/bundle:49:in `block in <top (required)>'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/lib/bundler/friendly_errors.rb:130:in `with_friendly_errors'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/exe/bundle:37:in `<top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
Intentando revertir...
Revertiendo...
Limpieza de elementos...
Eliminando funciones del esquema discourse_functions...
Eliminando el directorio temporal '/var/www/discourse/tmp/restores/default/2020-12-29-214249'...
Reanudando sidekiq...
Marcando la restauración como finalizada...
Notificando al 'sistema' sobre el fin de la restauración...
¡Finalizado!
[FALLÓ]
Restauración completada.

Parece que tienes un índice corrupto. ¿Has ejecutado una actualización en la instancia existente? Es posible que eso ayude.

Hay un tema en algún lugar con instrucciones para copiar los archivos de la base de datos sin procesar (y de Let’s Encrypt) desde la instancia antigua. Eso es probablemente lo que yo haría.

1 me gusta

¿Qué es “rub run”?

Las actualizaciones en la instancia existente siguen dando errores (errores diferentes a este), por eso estoy migrando a una nueva instancia.

¿Tienes un enlace a esto?

Transferencia de copias de seguridad mediante rsync y cronquizás

1 me gusta