ruby deployment capistrano heroku uptime

ruby - Implementación en caliente en Heroku sin tiempo de inactividad



deployment capistrano (7)

De hecho, tendrá un tiempo de inactividad cuando Heroku reinicie su aplicación. Tienen una nueva característica llamada Preboot que inicia nuevos dynos antes de eliminar los viejos: https://devcenter.heroku.com/articles/labs-preboot/

En cuanto a las migraciones de bases de datos, ese artículo enlaza a este sobre cómo lidiar con ese problema: http://pedro.herokuapp.com/past/2011/7/13/rails_migrations_with_no_downtime/

Un lado malo de presionar a Heroku es que debo presionar el código (y el servidor se reinicia automáticamente) antes de ejecutar mis migraciones de db.

Obviamente, esto puede causar unos 500 errores en los usuarios que navegan por el sitio web con el nuevo código sin las nuevas tablas / atributos: la solución propuesta por Heroku es usar el modo de mantenimiento, ¡pero quiero una manera sin inconvenientes de que mi aplicación web funcione siempre!

¿Hay alguna manera? Por ejemplo, con Capistrano:

  • Preparo el código para implementar en un nuevo directorio
  • Ejecuto migraciones (hacia atrás) y el código anterior continúa funcionando a la perfección
  • Con swith mongrel instancia al nuevo directorio y reiniciar el servidor

... y no tengo tiempo de inactividad!

El único método para mejorar el proceso es lo que sugiere este tipo. Sin embargo, este no es un escenario de implementación en caliente:

http://casperfabricius.com/site/2009/09/20/manage-and-rollback-heroku-deployments-capistrano-style/

Una cosa que sugeriría es presionar solo sus migraciones hacia Heroku primero y ejecutarlas antes de empujar su base de código. Esto implicaría comprometer las migraciones como asignaciones independientes y empujarlas manualmente cada vez (lo que no es ideal). Estoy muy sorprendido de que no haya una mejor solución para este problema con todas las aplicaciones grandes alojadas en Heroku ahora.

En este momento no veo ninguna posibilidad de hacer esto sin tiempo de inactividad. Yo también lo odio

Este comando de consola lo hace en la menor cantidad de tiempo que se me ocurra

git push heroku master && heroku maintenance:on && sleep 5 && heroku run rails db:migrate && sleep 3 && heroku ps:restart && heroku maintenance:off

  1. git push heroku master para impulsar la rama principal a heroku
  2. heroku maintenance:on para poner el mantenimiento así que no 500s
  3. sleep 5 para permitir que los dynos inicien el nuevo código (sin él, la migración podría fallar)
  4. heroku run rails db:migrate para hacer la migración real
  5. heroku ps:restart la experiencia, el reinicio asegura que las nuevas dynos tengan el último esquema
  6. heroku maintenance:off turno de mantenimiento

Es posible que deba agregar -a <app name> detrás de todos los comandos de heroku si tiene varias aplicaciones.

Solo un comando los ejecutará en serie en la terminal de Mac OSX.

Heroku no puede desplegar por capistrano. Estás bloqueado por herramienta lanzada por heroku.

El sistema sin tiempo de inactividad es imposible en todos los casos. Cómo cambiar su esquema con grandes cambios sin detener su servidor. Si no lo detiene, puede evitar algunos cambios y su base de datos puede ser inconsistente. ASÍ QUE el uso de la página de mantenimiento es una solución normal.

Si desea una pequeña solución para evitar el problema, es un equilibrio en dos servidores. Uno con solo la base de datos leída durante su migración. Puede cambiar a esta instancia durante su migración evitando la página de mantenimiento. Después de su migración, vuelve a su maestro.

Primero cometo las migraciones, las ejecuto y luego presiono el resto del código. Agregue un solo archivo como así:

git commit -m ''added migration'' -- db/migrate/2012-your-migration.rb

Puede configurar una segunda aplicación Heroku que apunte a la misma base de datos que su aplicación de producción primaria y usar la aplicación secundaria para ejecutar sus migraciones de bases de datos sin interrumpir la producción (suponiendo que las migraciones no interrumpan la versión anterior de su aplicación).

Llamemos a las aplicaciones de Heroku PRODUCCIÓN y ESCENOGRAFÍA .

Su secuencia de implementación se convertiría en algo así como:

  1. Implementar código nuevo para ESCENAR
    git push heroku staging
  2. Ejecute migraciones de bases de datos en STAGING (para actualizar PROD db)
    heroku run -a staging-app rake db:migrate
  3. Implementar código nuevo para PRODUCTION
    git push heroku production

La aplicación de montaje no te costará nada, ya que no necesitarás superar el nivel libre de Heroku y sería muy trivial configurar un script de despliegue de rake para que lo haga automáticamente.

¡Buena suerte!