Come eseguire un'applicazione Web Haskell distribuita

Question

Ho letto tutti i thread di distribuzione Haskell che ho trovato qui e diversi sul Web più ampio, ma non riesco ancora a ottenere una cosa. Se ho compilato un'app per il mio server e posso ssh ed eseguirlo, come faccio a far girare la cosa? Supponiamo che io stia usando un'interfaccia HTTP (non FastCGI).

Ad esempio, con node.js, utilizziamo il cluster per avviare l'app su diversi core del processore, quindi creare uno script init.d per centOS per ottenere l'esecuzione, il demone, il pid file ecc.

Come si esegue questa operazione per un'app Haskell?

Answer 1

Dato che non si menziona quale framework si sta utilizzando, ho intenzione di rispondere a questa domanda in generale.

Con Haskell, non è necessario avviare più istanze (in un cluster) dell'applicazione Web, poiché se l'applicazione supporta la concorrenza, in genere utilizza più thread internamente. Quello che invece si vuole fare è assicurarsi che l'applicazione sia compilata con i flag -threaded e -rtsopts. Quindi, quando si esegue l'applicazione, si superano le bandiere +RTS -N<number of simultaneous threads>. Se si utilizza un'applicazione Web Snap in esecuzione sulla porta 1234 su un computer 8-core con Intel® Hyper-Threading, ad esempio, è necessario avviarla con my-server -p 1234 +RTS -N16 per ottenere la parallellizzazione fino a 16 thread del sistema operativo.

Per eseguire il daemonize dell'applicazione Web, utilizzare la stessa procedura di node.js. Si crea uno script di init che avvia l'eseguibile in varie modalità di esecuzione UNIX e Bob è tuo zio.

Come con qualsiasi altra applicazione Web, è possibile che si desideri utilizzare un server front-end che reindirizza il traffico all'applicazione Web (motivo per cui non si potrebbe desiderare di utilizzare la porta 80 per le applicazioni Web). Per i dettagli su come eseguire questa operazione, visitare the Web/Deploy page on HaskellWiki.

Answer 2

I tre grandi framework web Haskell (Snap, Yesod e Happstack) hanno tutti la possibilità di essere forniti con un server Web integrato. L'approccio tradizionale alla distribuzione di produzione è probabilmente quello di utilizzare il meccanismo del sistema operativo per eseguire un processo come daemon in uno script di init o simile. Una soluzione più leggera che ho usato è una sceneggiatura simile alla seguente:

Ho eseguito questo script in background. È semplice, quindi il processo dello script di shell non si blocca mai. Se il server si arresta in modo anomalo per qualsiasi motivo, questo script garantisce automaticamente il riavvio immediato. Se desideri implementare una nuova versione, copialo sul file eseguibile my_app e invia un SIGHUP al processo my_app.

Gli amministratori di sistema induriti là fuori potrebbero rabbrividire in qualcosa del genere. Non dirò che questo è il modo migliore per farlo, ma ho gestito un'app di produzione per diversi anni con questo approccio e ha funzionato alla grande. Come altri hanno menzionato, puoi anche configurarlo con un server proxy front-end in modo che la tua app non debba essere eseguita come root.