Una organización sin fines de lucro con la que trabajo tiene una instalación de Discourse 2.9.0.beta1, cuyo mantenimiento recayó en mí cuando el administrador original se fue. Cuando intenté actualizar las credenciales SMTP, me enteré de que la instalación no puede reconstruirse ni actualizarse de forma segura, ni a través de la web ni de la línea de comandos. (Si no hubiera tenido una copia de seguridad activa de la instancia realizada antes de comenzar el trabajo, este habría sido un mal momento). El problema parece ocurrir bastante profundo en Ruby, y puedo capturar registros si parecen útiles.
Pensé que tal vez era demasiado antigua para actualizarse correctamente, así que intenté un proceso de recuperación en su lugar, creando una nueva instancia de Discourse y luego cargando la copia de seguridad más reciente del foro en ella, pero este proceso también falló de manera inconclusa, con lo que creo que fueron errores de columnas de la base de datos antes de que el proceso de actualización dejara de responder.
¿Cuál sería la mejor manera de proceder desde donde estamos? El foro está actualmente funcional en este momento, pero no puedo actualizarlo ni, aparentemente, emplear una copia de seguridad. ¿Debería continuar intentando la recuperación, debería redoblar mis esfuerzos para actualizar y capturar registros para comenzar, o hay una tercera opción que no veo?
Necesitas moverte a una nueva máquina virtual. Es probable que tu sistema operativo sea demasiado antiguo para actualizar Docker a una versión compatible.
Es mejor moverse a una nueva VM que estará en hardware más nuevo, que es más rápido y más barato.
El versionado de Docker no pareció influir en el colapso de las compilaciones de Ruby, pero supongo que es posible. Las descargas de Docker que formaron parte de la reconstrucción no parecieron tener ningún estado de fallo excepcional. Sin embargo, esto parece algo que puedo intentar. ¡Gracias por la respuesta!
Tu mudanza se complicó un poco más porque tenías copias de seguridad en S3 configuradas en la base de datos en lugar de en variables de entorno, como se describe en Configurar un proveedor de almacenamiento de objetos compatible con S3 para cargas (aunque eso es para cargas, por lo que no deberías usar la configuración use_s3, solo el bucket y la ubicación de copia de seguridad. EDITAR: Y luego la restauración falló porque tu EC2 no tiene acceso de escritura al bucket.
Tener un balanceador de carga delante de tu sitio también cambia las cosas con respecto a la mayoría de las personas.
Y dado que tus credenciales son para el EC2 en lugar de tenerlas en la base de datos o en el archivo YML, la restauración no se puede completar.