He exportado una versión un poco antigua del contenedor de Discourse y los archivos de Docker de Discourse de una instancia en ejecución y los he importado en un servidor diferente.
Necesito cambiar el nombre de host de Discourse para que coincida con el nuevo servidor.
¿Hay alguna forma de hacer que el nuevo DISCOURSE_HOSTNAME: sea efectivo sin una reconstrucción?
Si debo reconstruir, ¿buscará la última versión de la rama main y anulará la versión actual que tengo? porque necesito ejecutar exactamente la versión actual.
Tendrías que cambiar cosas en la configuración de Let’s Encrypt, que es (al menos en parte) la razón por la que necesitas reconstruir.
¿Por qué no actualizar? Eso es lo que realmente necesitas hacer. ¿Qué tan viejo es?
Pero podrías intentar fijar discourse_docker (también conocido como /var/discourse y la versión de Discourse en la que te encuentras. También podrías necesitar fijar todos los plugins.
Necesito tener la misma versión en esa instancia para probar la actualización a la última versión, así que si tiene éxito, realizaré la actualización en producción.
Si tienes otra cosa haciendo la resolución https, entonces podrías evitar la reconstrucción y simplemente hacer las otras cosas en Cambiar el nombre de dominio o renombrar tu Discourse.
HTTPS se maneja en un balanceador de carga, pero ese enlace dice que tengo que reconstruir después de modificar app.yml.
Entonces, si fijo las versiones, para discourse_docker, ¿debería extraer el hash de commit actual?
Y para la aplicación Discourse dentro del contenedor, ¿también debería establecer su hash de commit actual usando version: <hash_de_commit> en app.yml?
Es muy probable que si instalas la versión actual en el servidor de pruebas y restauras la base de datos en él, puedas actualizar el servidor de producción.
Lo que propones probablemente sea varias horas de trabajo, tiene un montón de pequeños detalles confusos que serán muy difíciles de describir en un foro, y no demostrará nada que la restauración de la base de datos de producción al nuevo servidor no vaya a hacer.
Simplemente apunta el servidor de staging y el servidor de producción al mismo bucket de copias de seguridad de S3, haz una copia de seguridad de producción y restáurala en el servidor de staging. En el futuro, estarán en paridad y podrás actualizar staging y producción en rápida sucesión.
Desencadené una reconstrucción pero esto es lo que obtuve:
I, [2023-04-07T19:17:58.707365 #1] INFO -- : cd /var/www/discourse & gem install bundler --conservative -v $(awk '/BUNDLED WITH/ { getline; gsub(/ /,""); print $0 }' Gemfile.lock)
ERROR: Could not find a valid gem 'bundler' (= 2.3.4), here is why:
Unable to download data from https://rubygems.org/ - Net::OpenTimeout: execution expired (https://rubygems.org/specs.4.8.gz)
Sin embargo, puedo hacer curl a rubygems.org desde el host.
Sí, el comando de reconstrucción y también la actualización iniciada desde la GUI dieron el mismo error.
Reintentando el fetcher debido a un error (4/4): Bundler::HTTPError No se pudieron obtener las especificaciones de https://rubygems.org/ debido a un error subyacente <Net::OpenTimeout: execution expired (https://rubygems.org/specs.4.8.gz)>
Hubo un error al instalar la versión bloqueada de bundler (2.4.4), vuelve a ejecutar con la bandera `--verbose` para más detalles. Continuando usando bundler 2.3.6.
Obteniendo el índice de origen de https://rubygems.org/
No se pudieron obtener las especificaciones de https://rubygems.org/ debido a un error subyacente
<Net::OpenTimeout: execution expired (https://rubygems.org/specs.4.8.gz)>
Docker Manager: FALLÓ LA ACTUALIZACIÓN
