Unbit Rack handler (URack)

Rack e' l'equivalente di WSGI per il mondo Ruby.

Tutti i framework per Ruby dovrebbero gradualmente appoggiarsi su questo nuovo ambiente, per questo motivo si e' reso necessario implementare un handler Rack che utilizzi il protocollo su cui si basa uWSGI per poter avere un sistema di comunicazione con apache altamente efficiente e con un consumo minimo di risorse.

I parametri di configurazione sono i seguenti:

rack associa al dominio all'applicazione rack

rack_app tipo di applicazione rack (attualmente supportate rails-development, rails-production, sinatra e config.ru)

rack_off uri per cui disabilitare l'interpete rack

rack_fileserve modalita' di serving per i file statici (gestita da apache, gestita da middleware, gestita dall'applicazione rack)

rack_debug visualizza nello stderr_log informazioni utili per debuggare i problemi di risorse, introduce un overhead sensibile, pertanto e' opportuno abilitarlo solo in fase di pre-produzione. Il consumo di address space viene sempre loggato indipendentemente da questo flag.

rack_path di default viene effettuato un chdir() alla docroot. Se l'applicazione rack e' in una directory differente si puo' specificare il path (relativo alla home) in questo campo.

rack_stderr file alternativo allo stderr_log in cui reindirizzare i log di uRack

rack_nfork numero di processi da avviare

rack_timeout massimo numero di secondi che apache deve attendere una risposta dall'applicazione rack prima che dichiari la richiesta fallita (max 30 secondi)

rack_input_buf_size massima quantita' (in Kbyte) del content body che puo' essere mantenuta in un oggetto StringIO. Richieste superiori vengono scritte in un file all'interno della directory temporanea.

Il ciclo di vita di una applicazione uRack

Ad ogni richiesta apache si collega al socket (UNIX) di uRack per passargli le informazioni; se il socket non e' disponibile verifica che uRack sia in esecuzione per il dominio, in caso negativo lo avvia.

Nel file di log impostato troverete le seguenti informazioni (date e pid sono ovviamente fittizi):

[Wed Nov 11 18:15:06 +0100 2009] starting uRack
[uRack/Unbit] process address space limit is 96.0 MB
[uRack/Unbit] need 124 bytes to store uidsec_struct...
[uRack/Unbit] uidsec_struct allocated.
[Wed Nov 11 18:15:06 +0100 2009] uRack: loading app [/accounts/unbit/www/XXXXXXXX]...
[uRack/Unbit] now you have 45.68 MB of address space available (used 50.32MB after app startup)
[Wed Nov 11 18:15:10 +0100 2009] uRack: ready to serve requests after 4 secs (pid: 12903)
[Wed Nov 11 18:15:10 +0100 2009] uRack: spawned rack worker 1 (pid: 12911)
[Wed Nov 11 18:15:11 +0100 2009] uRack: spawned rack worker 2 (pid: 12912)
[Wed Nov 11 18:15:11 +0100 2009] uRack: spawned rack worker 3 (pid: 12913)
[Wed Nov 11 18:15:11 +0100 2009] uRack: spawned rack worker 4 (pid: 12914)
[Wed Nov 11 18:15:11 +0100 2009] uRack: the master process manager is alive.

l'applicazione in questione risiede nella directory /accounts/unbit/www/XXXXXXXX, deve avviare 4 processi piu' il master (che si occupa del riavvio automatico).

Al momento dell'avvio uRack verifica quanto address space e' a disposizione dell'applicazione e quanti bytes sono necessari per ottenere le informazioni aggiuntivi del processo (contenute nella struttura uidsec_struct) tramite il kernel Unbit.

E' importante ricordare che tutte le linee di log che iniziano con "[uRack/Unbit]" sono relative alla piattaforma Unbit. Se usate uRack su altri sistemi non saranno presenti.

Caricata l'applicazione in memoria, uRack riporta l'address space occupato da quest'ultima dopo l'avvio e quanto ne e' ancora disponibile.

Successivamente (in base al valore di rack_nfork) vengono avviati i processi aggiuntivi e , se richiesto, il process manager.

Da questo momento l'applicazione e' pronta a ricevere richieste.

Per ogni richiesta verra' scritta la seguente linea nello stderr_log (o il file che si e' scelto dal pannello):

[Thu Nov 12 09:02:46 +0100 2009] uRack: [/accounts/unbit/www/XXXXXXXX] req: 2 pid: 12911 as: 52.51 MB => GET / in 0.060878 secs

il parametro req indica quante richieste ha gestito il processo, as e' l'address space occupato e alla fine viene riportato il tempo (in secondi) impiegato a generare la risposta.

I segnali del master process

Il master process di uRack risponde a 2 segnali POSIX: QUIT e TERM.

QUIT termina tutta l'applicazione e i worker. Sara' riavviata alla successiva richiesta.

TERM esegue il 'graceful kill' ai worker, e' molto comodo per aggiornare una applicazione in produzione. I worker vengono uccisi tenendo conto di eventuali richieste in corso. L'applicazione sara' riavviata alla successiva richiesta.

Questi 2 segnali sono gestiti da uRack, ma in caso di bug nell'applicazione potrebbero non funzionare a dovere.

In tal caso la soluzione migliore e' inviare il segnale di KILL a tutti i processi dell'applicazione.