Deploy di un'applicazione Rails

Attenzione dalla versione 2.3 Rails e' Rack compliant pertanto il sistema di deploy consigliato e' tramite il rack-handler di Unbit. Se volete continuare ad utilizzare fastcgi dovrete accertarvi che il file dispatch.fcgi sia presente all'interno di /public

AGGIORNAMENTO: La versione corrente di uRack supporta anche le vecchie versioni di rails tramite il wrapper di Thin, chiedete allo staff se potete avere abilitato uRack nel vostro piano

Unbit Rack Handler Howto

1) fare l'upload della propria applicazione all'interno della directory /rails in cima alla propria home directory

2) sul pannello di controllo nelle impostazioni del dominio configurare i seguenti campi:

docroot nomeapp/public

dove nomeapp e' il nome della directory appena uploadata dentro /rails

rails settare questo checkbox

3) richiamare il dominio sul proprio browser; nel giro di qualche secondo l'applicazione sara' avviata

In caso l'applicazione sia in modalita' "production" si puo' forzare il reload dei controller e dei modelli utilizzando la UnbitConsole (si abilita dal pannello di controllo nelle opzioni dominio) .

4) Se la vostra applicazione fa uso di ActionMailer esiste un servizio smtp locale (localhost:25) sul vostro dominio quindi non dovrete configurarne uno esterno. E' importante usare SMTP e non sendmail, in quanto quest'ultimo occupa almeno 2 processi per ogni invio.

5) Ricordatevi sempre (se possibile) di fare il freeze della vostra applicazione cosi' da evitare che un aggiornamento delle gems possa rendere la vostra applicazione inutilizzabile (altamente probabile)

 rake rails:freeze:gems VERSION=x.x.x

dove x.x.x e' la versione da utilizzare

In generale, cercate sempre di specificare la versione quando includete delle gem, questo vi garantira' un ambiente piu' solido.

ATTENZIONE Da dicembre 2007 la funzione require_gem non e' piu' disponibile quindi le vecchie versioni di rails potrebbero avere dei problemi. Una soluzione e' aggiungere nel file config/boot.rb subito dopo require 'rubygems' la seguente direttiva:

  alias require_gem gem

I segreti del perfetto deploy

Tutti i log pre-spawn di rails sono presenti all'interno del file stderr_log nella home. Verificate sempre questo file i nquanto contiene informazioni utilissime sull'ambiente di deploy.

In caso di problemi verificate che:

1) non si includano classi/moduli/librerie/gems non presenti sul sistema, ricordate che potete utilizzare la directory /vendor della vostra applicazione per includere le vostre gem.

2) l'address space acquistato sia sufficiente a eseguire la vostra applicazione, rails e' un divora-memoria quindi mettete in conto da subito un upgrade o acquistate direttamente processi con almeno 96 mega di address space.

Per riavviare rails o recuperare situazioni di blocco potete usare la sezione "Processi" del pannello di controllo e inviare il segnale di KILL ai processi di rails.

Note su htaccess (solo ambiente FastCGI)

Può capitare di voler effettuare delle operazioni sull'applicazione rails tramite il file htaccess, ad esempio usando mod_rewrite per utilizzare[http://www.feedburner.com/ FeedBurner]con il proprio feed.

Per farlo correttamente dovrete tenere a mente che nel caso di un'applicazione rails su unbit se mettete un file .htaccess in nomeapp/public esso non verrà utilizzato dal web server. Il file viene invece analizzato ed usato correttamente se si trova in una sottodirectory. Quindi se ad esempio volete effettuare un rewrite del tipo

/feed/atom.xml -> http://feeds.feedburner.com/miofeed

non potete mettere la regola corrispondente in public/.htaccess ma potete risolvere mettendo la regola nel file public/feed/.htaccess.

In alternativa potete non utilizzare il deploy semplificato di unbit per rails e utilizzare fastcgi liscio.

Note sulle risorse

Tutte i processi unbit vengono eseguiti in un ambiente protetto con dei limiti di risorse ben definiti in base alla fascia di utenza. Uno degli errori ( o meglio dei comportamenti poco corretti) piu' frequenti di programmazione in ambiente rails e' nella scrittura su disco di file ricevuti da una form.

La tecnica piu' comune (e quella piu' malsana) e':

File.new("pippo.file",'w').write(params[:file].read)

In pratica si legge il contenuto di tutto il file params[:file] in un colpo solo e lo si scrive in pippo.file.

Questo significa che se params[:file] e' grande 100MB ruby allochera' 100MB di ram, superando i limiti assegnati e chiudendo la vostra applicazione !!!

Il modo corretto (e insegnato nelle buone scuole e libri di informatica) e' suddividere il file in chunk:

    f = File.new("pippo.file",'w')

    while !params[:file].eof

      f.write(params[:file].read(4096))

    end

    f.close

...che leggera' il file in blocchi di 4096 bytes fino alla sua fine e li scrivera' mano mano su disco. Di solito si utilizzano chunk di 4k (4096) per motivi di performance, ma potete azzardare con multipli leggermente piu' grandi.

Ricordate sempre di valutare (magari prima di andare in fase di produzione) quanto tempo impiega ogni action a generare la risposta, cosi' da modificare (se e' necessario) il flag fastcgi_socket_timeout con un valore adeguato.

Gems

C'e' una sezione apposita nel wiki per quanto riguarda le gem: RubyGems

rails_nfork (solo ambiente FastCGI)

Questo parametro di configurazione e' il piu' importante per quanto riguarda le performance. Ogni dominio ha una serie di processi assegnati e volendo potete utilizzarli tutti per la vostra applicazione rails (che di default utilizzera' un solo processo). Utilizzare piu' processi significa poter gestire piu' richieste in parallelo e ridurre la latenza. Valutate sempre con attenzione il numero di processi da utilizzare. Ricordate inoltre che in alcuni contesti (pochi a dir la verita') l'utilizzo di piu' processi puo' introdurre delle nuove problematiche come nel caso di ferret per cui si rende necessario l'utilizzo del ferret-server

fastcgi_memory_watchdog (solo ambiente FastCGI)

Sappiamo benissimo che la tentazione di usare questa funzionalita' offerta da UFCGI e' molto forte. Tuttavia vi chiediamo di resistere e limitarne l'uso il piu' possibile. La chiusura forzata di una applicazione puo' potenzialmente provocare dei danni ai vostri dati.

Rails >= 2.3 (sia FastCGI che uRack)

Di default le versioni piu' recenti di Rails tengono in cache anche le views quando sono in modalita' prduction. E' una funzionalita' che puo' incrementare le performance ma che puo' occupare molta memoria.

Valutate se e' il caso di disabilitare questa opzione (nel file config/environments/production.rb):

config.action_view.cache_template_loading            = true

...impostandola a false