despliegue fluido de Django para un solo servidor

Question

que tiene un nuevo sitio web construido en Django y Python 2.6, que He desplegado a la nube (palabra de moda el estándar y la instancia EC2 de Amazon micro es gratis!).
Aquí están mis notas detalladas: https://docs.google.com/document/d/1qcZ_SqxNcFlGKNyp-CXqcFxXXsKs26Avv3mytXGCedA/edit?hl=en_US

Como este es un nuevo sitio (y con ganas de jugar con la última y más grande) Solía ​​Nginx y Gunicorn en la parte superior del supervisor.
Todo el software instalado desde el tronco utilizando YUM/easy_install.
Mi base de datos es Sqlite (por ahora, no estoy seguro de dónde ir después, pero esa no es la pregunta). También en la lista de tareas pendientes: virtualenv + pip.
Hasta ahora todo bien.
Mi código está en SVN. Escribí un fabfile simple para implementar: verifica el código más reciente y reinicio Gunicorn a través de Supervisor. Conecté mi nombre DNS a una IP elástica.
Funciona.

Mi pregunta es, ¿cómo puedo actualizar el sitio sin una interrupción del servicio? Los usuarios del sitio obtienen 404s/500s cuando ejecuto mi pequeño script de actualización.

¿Hay una manera de hacer esto sin añadir otro servidor (el precio es clave)?

Me encantaría tener un sistema de estadificación (en un puerto diferente?) Y un interruptor sin fisuras entre ensayo y producción. En el mismo servidor (gratuito). A través de Fabric.
¿Cómo hago eso? ¿Es el mismo Nginx ejecutando ambos sitios? ¿Puedo actualizar la puesta en escena sin dañar la producción? ¿Cómo se vería el archivo fabfile? ¿Cómo se vería el árbol de directorios?

Gracias!

Tal.

relacionadas:

• Seamless deployment in Rails
-

Answer 1

Nginx que permite la conmutación por error de configuración para sus servidores proxy inversos se puede poner un ejemplo gunicorn como el primario y el tiempo que esa versión se está ejecutando nunca se verá en la conmutación por error.

Si configura su sitio para que su nueva versión esté en la instancia de conmutación por error, solo necesita escribir su archivo fab para actualizar la instancia de falla con la nueva versión del sitio y luego cuando esté listo, desactivar la instancia principal. Nginx realizará failover sin problemas a segunda instancia y bam se está ejecutando en una nueva versión sin tiempo de inactividad.

A continuación, puede actualizar la versión primaria y luego volver a encenderla y su principal está ahora en vivo. En este punto, puede mantener la instancia de conmutación por error en funcionamiento por si acaso, o desactivarla.

Algunas cosas a considerar. Debe tener cuidado con las bases de datos, si está utilizando sqllite asegúrese de que ambas instancias de gunicornio puedan acceder al archivo sqllite.

Si tiene una base de datos normal, esto no representa un problema, solo necesita asegurarse de aplicar las migraciones de bases de datos que la nueva versión necesita antes de cambiar a ella.

Si son cambios hacia atrás compatibles entonces no es un gran problema. Si no son compatibles con versiones anteriores, tenga cuidado, podría romper la versión anterior del sitio antes de cambiar a una nueva versión.

Para facilitar las cosas, ejecutaría las versiones en diferentes entornos virtuales.

Si usa supervisord para controlar gunicorn, puede usar los comandos supervisorctl para volver a cargar/reiniciar cualquier instancia que desee implementar sin afectar a la otra.

Espero que ayude

Aquí está un ejemplo de y configuración de nginx (no un archivo de configuración completo, eliminado las partes sin importancia)

Esto supone la instancia gunicorn primario se ejecuta en el puerto 9005 y el otro es ejecutándose en el puerto 9006

upstream service-backend { 
    server localhost:9005;  # primary 
    server localhost:9006 backup; # only used when primary is down 
} 

server { 
    listen 80; 
    root /opt/htdocs; 
    server_name localhost; 

    access_log /var/logs/nginx/access.log; 
    error_log /var/logs/nginx/error.log; 

    location/{ 
     proxy_pass http://service-backend; 
    } 
} 

Answer 2

Suena como que necesita para encontrar la manera de decirle a gunicorn gracefully restart. Parece que todo lo que tienes que hacer es emitir un HUP al proceso de gunicornio cuando notificar para volver a cargar la aplicación. Como se describe en el enlace, el gunicorn docs explica cómo hacerlo.