Cómo hacer un reinicio continuo de un grupo de mongres

Question

Cualquiera sabe una buena manera de reiniciar un clúster mongrel a través de capistrano en un estilo "rodante", por ejemplo, un mongrel a la vez. Sería genial tener un poco de tiempo de espera allí también para cada uno, para que el mestizo también cargue la aplicación de rieles.

He hecho algunas búsquedas, y no he encontrado demasiado, así que busco ayuda antes de sumergirme en la gema mongrel_cluster.

Gracias!

Answer 1

El balancín es una gema que se encuentra en el Rails Oceania Rubyforge Project que proporciona este tipo de funcionalidad a los grupos de mestizos. Sin embargo, el proyecto puede estar sufriendo de algún fragmento de podredumbre no había havain un comunicado desde 2007. Aún así vale un vistazo aunque sólo sea para pellizcar las ideas :)

Answer 2

#!/bin/bash 
for PIDFILE in /tmp/mongrel.*; do 
    PID=$(cat ${PIDFILE}) 
    kill ${PID} 
    ${RUN_MONGREL_CMD} ${PID} 
    sleep 2 
done 

Answer 3

Estoy de acuerdo con el enfoque de sube y baja más que el enfoque de rodadura estas buscando. El problema es que terminas en situaciones en las que el equilibrio de carga puede enviar y recibir usuarios entre las diferentes versiones de la aplicación mientras haces la transición.

Las soluciones que se nos ocurrieron (antes de encontrar SeeSaw, que no usamos) fueron quitar la mitad de los mestizos de la línea del equilibrador de carga. Ciérrenlos. Actualízalos. Ponlos en marcha. Vuelva a poner en línea a esos mestizos en el equilibrador de carga y quite la otra mitad. Cierra la segunda mitad. Actualiza la segunda mitad. Ponlos en marcha. Esto minimiza en gran medida el tiempo en el que tiene dos versiones diferentes de la aplicación ejecutándose simultáneamente. Escribí un archivo de Windows Bat para hacer esto. (No se recomienda la implementación en Windows, por cierto)

Es muy importante tener en cuenta que tener migraciones de bases de datos puede hacer que todo el enfoque sea un poco peligroso. Si solo tiene migraciones aditivas, puede ejecutarlas en cualquier momento antes de la implementación. Si está eliminando columnas, debe hacerlo después de la implementación. Si va a cambiar el nombre de las columnas, es mejor dividirlo en una nueva columna y copiar datos en la migración para que se ejecute antes de la implementación y un script separado para eliminar la columna anterior después de la implementación. De hecho, puede ser peligroso usar sus migraciones regulares en una base de datos de producción en general si no hace un esfuerzo específico para organizarlas. Todo esto apunta a hacer entregas más frecuentes, por lo que cada actualización es de menor riesgo y menos compleja, pero ese es un tema para otra respuesta.