Flask + mod_wsgi ricarica automatica in caso di modifica del codice sorgente

Question

Qualcuno sa come eseguire automaticamente il mod_wsgi ricarica di un'app Flask quando uno dei moduli cambia? Ho provato WSGIScriptReloading On, ma senza fortuna. Il official documentation è una specie di orso ... Immagino che darò una pugnalata se nessuno lo sa. Grazie in anticipo!

Inoltre, se non fosse possibile bloccarsi in modo permanente in caso di errori di sintassi (come nel caso di Flask reloader), sarebbe fantastico.

Answer 1

Cosa intendi con "la documentazione ufficiale è una specie di orso"? Cosa c'è di sbagliato con la ricetta incluso:

• http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode#Monitoring_For_Code_Changes

Questo documento spiega anche il motivo per WSGIScriptReloading non fa quello che ci si aspetta.

E no non è possibile arrestarsi in modo permanente in caso di errori di sintassi. È incorporato in Apache e l'intero punto di Apache è quello di mantenere la roba in esecuzione.

Sembra che non dovresti usare Apache/mod_wsgi per lo sviluppo. Tutti sanno che non si dovrebbe usare il codice sorgente automatico che si ricarica nella produzione, quindi non si può immaginare che si vorrebbe farlo.

Answer 2

Con mod_wsgi, WSGIScriptReloading cerca le modifiche al file di configurazione .wsgi anziché al codice.

mio flusso di lavoro è quello di caricare le mie modifiche al codice poi basta

$ touch MyWebApp.wsgi 

che fa sì che l'ultimo timestamp di file modificato per cambiare e mod_wsgi per ricaricare il codice.

È possibile eseguire questa operazione "da remoto" salvando il file .wsgi sul computer locale e quindi caricandolo di nuovo, oppure lo faccio semplicemente tramite SSH.

Non molto si può fare per errori di sintassi, il codice è in esecuzione o non lo è, ma una correzione più uno touch lo riavvierà di nuovo.

Una Gotcha di guardare fuori per se si sta lavorando via FTP: assicurarsi di caricare la 'toccata' .wsgi file di ultima altrimenti cercherò di iniziare con il codice errato.

Answer 3

Penso che sia una situazione molto realistica voler ricaricare il codice sorgente automaticamente in produzione. Pensa a un ambiente in cui le fonti vengono distribuite per versione e un collegamento simbolico "produzione" punta a una di quelle versioni. Ogni volta che si desidera rilasciare una versione più recente, basta puntare il collegamento simbolico su un altro percorso. Ma apache e mod_wsgi raccolgono ancora i file dalla directory con collegamenti simbolici e quindi è necessario disporre di un meccanismo di ricarica basato su data/ora, dimensioni o w/e. Certo, un'applicazione potrebbe non essere un problema, ma per quanto riguarda l'hosting di 15-20 applicazioni che sono tutte in fase di sviluppo attivo? Il non ricaricare automaticamente le fonti è una perdita pura in una situazione simile rispetto al riavvio di Apache ogni volta.

Torna alla domanda: se il framework che stai usando (in questo caso una bottiglia) non ha un plugin o uno strumento in posto per ricaricare automaticamente il codice sorgente, allora le due opzioni descritte da Graham e Malphas sono le migliori opzioni . Attivare il processo wsgi per riavviare o implementare un sistema di monitoraggio.

Answer 4

Hai ragione sull'aggiunta della direttiva WSGIScriptReloading. I documenti Flask non lo rendono chiaro al 100%, ma Apache cerca modifiche al tuo file .wsgi. La soluzione consigliata è quella di eseguire un comando touch sul tuo file .wsgi, come parte del processo di rilascio.

Answer 5

Per la produzione preferisco anche apache mod_wsgi, mentre per lo sviluppo utilizzo il server integrato del pallone. Ho separato i file prod e dev config e ho impostato la direttiva debugTrue nella configurazione di dev in modo che Flask possa rilevare e ricaricare automaticamente le modifiche al codice.

Answer 6

La risposta corretta a questa domanda è che WSGIScriptReloading On deve essere aggiunto a 000-default.conf presente nella cartella /etc/apache2/sites-enabled.

Vedere sotto esempio

<VirtualHost *:80> 
     # The ServerName directive sets the request scheme, hostname and port that 
     # the server uses to identify itself. This is used when creating 
     # redirection URLs. In the context of virtual hosts, the ServerName 
     # specifies what hostname must appear in the request's Host: header to 
     # match this virtual host. For the default virtual host (this file) this 
     # value is not decisive as it is used as a last resort host regardless. 
     # However, you must set it for any further virtual host explicitly. 
     #ServerName www.example.com 

     ServerName sentiments.live 
     ServerAdmin admin@sentiments.live 
     DocumentRoot /var/www/html 
     WSGIDaemonProcess flaskapp threads=5 
     WSGIScriptAlias//var/www/html/sentiments/flaskapp.wsgi 

     <Directory sentiments> 
       WSGIScriptReloading On 
       WSGIProcessGroup sentiments 
       WSGIApplicationGroup %{GLOBAL} 
       Order deny,allow 
       Allow from all 
     </Directory>