Creo que sí 
Espera a que se fusione este PR y luego sigue los pasos indicados:
Alrededor de 100 GB 
lo haré
Así que, mientras pienso en automatizar esta actualización, se me ocurre que saber cuándo realizar este salto de post-despliegue es bastante complicado.
Para instalaciones de un solo contenedor, a menos que haya alguna migración extraña (esta es la primera de la que tengo conocimiento en mis 4 años), no hay ninguna ventaja en hacerlo de esta manera. La mayoría de las actualizaciones tendrán pocas migraciones y, probablemente, ninguna que sea intensiva en recursos computacionales.
Para instalaciones de dos contenedores, siempre es una buena idea usar SKIP_POST_DEPLOYMENT_MIGRATIONS, ya que puedes desactivar tu sitio si las migraciones rompen el contenedor en ejecución, lo que elimina parte de la ventaja de poder iniciar el nuevo contenedor mientras el antiguo sigue funcionando. PERO, aun así, no todas las actualizaciones incluyen migraciones que rompan cosas, por lo que la solución de dos reinicios proporcionada por este commit (muy bienvenido) probablemente resulte en más tiempo de inactividad (dos ciclos de reinicio) que simplemente vivir al límite.
Mi pensamiento actual es que una mejor solución sería que el bootstrap siempre realice las migraciones con SKIP_POST_DEPLOYMENT_MIGRATIONS=1 y luego ejecute una migración en el primer arranque. Sin embargo, no tengo una solución elegante para cómo lograr exactamente eso. ¿Existe una forma rápida de saber si hay migraciones pendientes? Supongo que el script de arranque podría tener algo como if hay migraciones pendientes, ejecutar una migración justo después de iniciar unicorn. Eso es bastante engorroso, sin embargo, y probablemente no valga la pena para la mayoría de las instalaciones la mayor parte del tiempo.
Definitivamente no vale la pena la mayoría de las veces, pero si las actualizaciones de tu software rara vez (pero a veces) tardan 10 veces más de lo normal, eso es un problema real para muchos usuarios.
A partir de ahora, no ejecutaré actualizaciones de Discourse hasta al menos una semana después del lanzamiento. Por supuesto, podrías argumentar que soy un idiota por no haber esperado desde el principio, que me lo busqué, que debería saberlo mejor, y todo eso es completamente correcto. Aun así, hacer que los tiempos de actualización sean más consistentes y predecibles sería un gran servicio para todos los otros idiotas que hay por ahí.
Alternativamente, la actualización a través de la interfaz de usuario mediante docker_manager se encarga de esto automáticamente.
¡Eso es increíble! Casi nunca actualizo de esa manera, así que nunca se me habría ocurrido. Gracias.
Perdona, para aclarar, si añadimos esta variable de entorno a nuestro contenedor de la aplicación:
O bien:
SKIP_POST_DEPLOYMENT_MIGRATIONS: true
o
SKIP_POST_DEPLOYMENT_MIGRATIONS: 1
¿Al ejecutar el lanzador se omitirán todas las migraciones de la base de datos cuando volvamos a compilar?
¿Es esta la comprensión correcta?
No exactamente. Consulta Introducing Post Deployment Migration
Hola, he logrado actualizar todo usando este método (es decir, a través de la interfaz de usuario), pero después comienza a realizar este proceso de implementación con instrucciones de migración (las que se habían omitido desde el principio) y así sucesivamente, y falla después de un tiempo, indicando que la actualización no se completó con éxito. Sin embargo, el foro funciona correctamente y el panel de administración muestra todo como actualizado.
Mi pregunta es: ¿tengo que hacer algo más? Específicamente sobre este proceso de implementación, ¿necesito ejecutarlo a través de la línea de comandos (para evitar fallos)? ¿Hay comandos específicos para ello y el foro dejará de funcionar mientras se ejecuta?
¿Aún tienes los registros relevantes? Necesitas ejecutar las migraciones, de lo contrario la búsqueda se romperá en el sitio.
./launcher enter app
bundle exec rails db:migrate
Sin registros, pero fueron las mismas consultas mencionadas anteriormente en este tema.
Antes de iniciar este proceso y dejarlo ejecutándose, ¿esto romperá temporalmente el sitio web (como una reconstrucción) o es “seguro”? Disculpe que insista en este asunto específico, pero se trata de un sitio web en producción y una interrupción de 10 a 15 minutos es aceptable; sin embargo, uno o dos días no lo son y debe considerarse cuidadosamente si no hay otras opciones disponibles.
Si ya has actualizado a la última versión, ejecutar las migraciones no causará ningún tiempo de inactividad en tu sitio. Con ‘actualizado’, me refiero a que la nueva versión fue implementada, pero la migración posterior a la implementación mencionada en este tema falló.
Gracias. Al final volví a las actualizaciones a través de la interfaz, lo intenté una vez más y las migraciones de la base de datos posteriores al despliegue finalmente se completaron. Tardó varias horas (y mucho uso de CPU 
), pero se terminaron y ¡todo está ahora completamente actualizado! 