Distribuzione del codice Tornado

Question

Esiste una strategia di distribuzione del codice canonico per la distribuzione di applicazioni Web basate su tornado. La nostra attuale configurazione è di 4 processi di tornado in esecuzione dietro NginX? (Il nostro caso d'uso specifico è dietro EC2.)

Attualmente abbiamo una soluzione che funziona abbastanza bene, per cui lanciamo i quattro processi di tornado e salviamo i PID in un file in/tmp /. Dopo aver distribuito il nuovo codice, eseguiamo la seguente sequenza via fabric:

1. Fai un tiro di git dal ramo prod.
2. Rimuovere la macchina dal servizio di bilanciamento del carico.
3. Attendere che tutte le connessioni in volo terminino con una sospensione.
4. Elimina tutti i tornado nel file pid e rimuovi tutti i file * .pyc.
5. Riavvia i tornado.
6. Collegare la macchina alla bilancia di carico.

Abbiamo preso qualche ispirazione da questo: http://agiletesting.blogspot.com/2009/12/deploying-tornado-in-production.html

Esistono altre soluzioni complete là fuori?

Answer 1

Non ho distribuito Tornado in produzione, ma ho giocato con Gevent + Nginx e ho utilizzato Supervisord per la gestione dei processi - avvio/arresto/riavvio, registrazione, monitoraggio - supervorctl è molto utile per questo. Come ho detto, non una soluzione di distribuzione, ma forse uno strumento che vale la pena utilizzare.

Answer 2

Corriamo Tornado + Nginx con supervisord come supervisore.

configurazione di esempio (nomi cambiati)

[program:server] 
process_name = server-%(process_num)s 
command=/opt/current/vrun.sh /opt/current/app.py --port=%(process_num)s 
stdout_logfile=/var/log/server/server.log 
stderr_logfile=/var/log/server/server.err 
numprocs = 6 
numprocs_start = 7000 

devo ancora trovare il modo "migliore" per riavviare le cose, quello che io probabilmente finalmente fare è avere Nginx ha un file "attiva", che è aggiornato lasciando che HAProxy sappia che abbiamo problemi con la configurazione, quindi aspettiamo un po ', scambiamo le cose, quindi riabilitiamo tutto.

Usiamo Capistrano (abbiamo un compito di backlog per passare a Fabric), ma invece di trattare con la rimozione di file * .pyc abbiamo symlink/opt/current all'identificatore di release.