Despliegue en caliente en Heroku sin tiempo de inactividad

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. Esto obviamente puede causar unos 500 errores en los usuarios que navegan por el nuevo código sin las nuevas tablas/atributos: la solución propuesta por Heroku es usar el modo de mantenimiento, pero quiero una forma sin inconvenientes para que mi webapp corriendo todo el tiempo!Despliegue en caliente en Heroku sin tiempo de inactividad

¿Hay alguna manera? Por ejemplo, con Capistrano:

preparo el código para desplegar en una nueva dir
corro migraciones (hacia atrás) y el código antiguo seguir trabajando perfectamente
I SWITH ejemplo mestizo al nuevo directorio y reinicie el servidor

... ¡y no tengo tiempo de inactividad!

Fuente

2010-04-01 zetarun

Heroku no puede implementar 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 servidor de equilibrio en dos. 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.

Fuente

2010-04-01 14:19:33 shingara

Hola Shingara, Lo siento, pero no estoy de acuerdo con usted. no quiero utilizar el equilibrio de carga para esto: una de las grandes características de Heroku es el "trasparente" poder de nubes por la necesidad y deseo utilizar esta función ... Para equilibrar la carga en Heroku He MANTENER a dos diferentes aplicaciones y una base de datos de solo lectura pueden causar problemas a mis usuarios. Y un sistema sin tiempo de inactividad no es imposible. Estoy acostumbrado explicado el sistema sin tiempo de inactividad. En caso de un cambio grande y sin la posibilidad de un esquema de db-compatible retro Puedo utilizar una página de mantenimiento: pero esto es el 5% de todos mis casos ... – zetarun

Puede evitar el problema descrito en esta respuesta mediante el uso de CouchDB, por ejemplo. – iconoclast

El único método para mejorar el proceso es lo que sugiere este tipo. Esto todavía no es un escenario de despliegue en caliente sin embargo:

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

Una cosa que sugeriría es solamente empujando sus migraciones hasta Heroku primero y ejecutarlos antes de empujar su código base. 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.

Fuente

2011-05-03 13:47:56 iwasrobbed

Puede configurar una segunda aplicación Heroku que apunte al mismo DB que su aplicación de producción primaria y use la aplicación secundaria para ejecutar sus migraciones de base de datos sin interrumpir la producción (suponiendo que las migraciones no rompen la versión anterior de su aplicación) .

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

Su secuencia de despliegue se convertiría en algo como:

Implementar nuevo código a ESTADIFICACIÓN
git push heroku staging
migraciones de bases de datos en Ejecutar en ESTADIFICACIÓN (para actualizar db PROD)
heroku run -a staging-app rake db:migrate
implementar nuevo código para PRODUCCIÓN
git push heroku production

La aplicación puesta en escena no le cuesta nada, ya que no tendrá que exceder de capa gratuita de Heroku y sería bastante trivial para configurar un script de despliegue rastrillo para hacer esto de forma automática.

¡Buena suerte!

Fuente

2012-04-10 00:26:11 jshkol

Todavía tendría un poco de tiempo de inactividad con el paso 3 ¿verdad? – andrewrk

Creo que Heroku mantendrá sus dinas antiguas hasta que se complete la compilación del nuevo slug para que su sitio permanezca disponible mientras se ejecuta el paso 3. Supongo que podría haber algún tiempo de inactividad momentáneo, mientras que Heroku corta la ruta de los viejos dynos a los nuevos, pero debería ser bastante mínimo. – jshkol

No estoy seguro de que sea una buena idea tener su entorno de ensayo vinculado a su base de datos de producción si realmente lo está utilizando como entorno de ensayo. – Daniel

Si usted es capaz de vivir con dos versiones de la misma aplicación en vivo al mismo tiempo, Heroku ahora tiene una característica de prearranque.

https://devcenter.heroku.com/articles/preboot

Fuente

2012-09-04 20:54:58

El enlace correcto es ahora: https://devcenter.heroku.com/articles/preboot –

Que se va a tener un poco de tiempo de inactividad cuando Heroku se reinicia la aplicación. Tienen una nueva característica llamada de prearranque que se pone en marcha nuevos dinamómetros antes de sacar los viejos: https://devcenter.heroku.com/articles/labs-preboot/

En cuanto a las migraciones de bases de datos, que vincula artículo a éste sobre cómo hacer frente a esta cuestión: http://pedro.herokuapp.com/past/2011/7/13/rails_migrations_with_no_downtime/

Fuente

2012-09-25 17:31:00 michael

por primera vez cometer las migraciones, ejecutarlas, luego presionar el resto del código. Añadir un único archivo, así:

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

Fuente

2012-11-07 18:35:36 bevanb

Despliegue en caliente en Heroku sin tiempo de inactividad

Respuesta

Cuestiones relacionadas