Mi sono sempre un po’ arrangiato, ma mettendo su un server nuovo, mi
viene voglia di cercare di migliorare il setup…
I dubbi vengono principalmente da rvm e i permessi da dare a tutto.
Passenger non riesce a gestire piu di un Ruby, ma per il momento non e un grande problema. Ho deciso di utilizzare un utente creato
specificamente per quest’applicazione, invece di www-data o peggio,
davidw, ma a quel punto, per fare bundle install, dovrei sistemare
questo utente in modo che possa installare le gemme. Neanche questo
mi piace molto. Poi c’e da pensare a come sistemare git, anche se la vedo piu` chiaramente le cose: read only access per il deploy.
Pensieri a proposito? Il sistema ideale sarebbe in grado di gestire
piu` applicazioni con gemset/bundle/whatever diversi fra di loro, ma
per il momento va bene gestire anche una sola applicazione in
sicurezza.
Il giorno 10/lug/2012, alle ore 11:56, David W. [email protected] ha scritto:
questo utente in modo che possa installare le gemme. Neanche questo
mi piace molto. Poi c’e da pensare a come sistemare git, anche se la vedo piu` chiaramente le cose: read only access per il deploy.
Pensieri a proposito? Il sistema ideale sarebbe in grado di gestire
piu` applicazioni con gemset/bundle/whatever diversi fra di loro, ma
per il momento va bene gestire anche una sola applicazione in
sicurezza.
Ciao David,
La tua domanda è molto interessante e una risposta esaustiva sarebbe
lunghissima.
Mi unisco al consiglio che ti hanno già dato su server fault, abbandona
passenger e volendo anche apache. Nginx + unicorn o nginx + thin sono
una buona combinazione.
Io sto considerando di abbandonare anche capistrano, sul lungo periodo,
in favore di una soluzione private cloud basata su cloud foundry. C’è un
gruppo devops-italia su google groups con tante persone che ne sanno più
di me a riguardo.
Riguardo git e le gemme, la prossima release di bundler (1.2) permette
di fare package delle dipendenze in vendor/cache anche di quelle che
sono prese direttamente da git.
L’architettura che delinei non funziona sul lungo periodo se devi
gestire
pi di un paio d’app: te lo dico perch la mia situazione.
Ad oggi sui server di produzione che gestisco io un delirio, perch
sopra
ho parecchie applicazioni e non riesco ad aggiornare le versioni di ruby
per via della compatibilit.
So che dovrei fare manutenzione, ecc, ma i budget e sopratutto i tempi
per
fare queste modifiche non ci sono, quindi i requisiti tecnologici per le
nuove app sono dettate dal server su cui andranno a girare e non dai
reali
requisiti. Insomma, un delirio da cui spero di uscirne a breve con
l’architettura che ti descrivo sotto :).
Il mio consiglio questo: elimina Passenger. Usa Apache o NGINX come
reverse proxy, e esegui le tue app via unicorn, avendo cura di abilitare
la
cache http nginx/apache.
In questo modo puoi:
installare un interprete ruby per app, visto che RVM “locale”.
aggiornare i tuoi interpreti ruby quando ti pare
usare i Procfile per generare gli script di Upstart per le tue app,
cos sei sicuro che i vari processi Unicorn, Deleyed Jobs,
Vattelapesca
vengono riavviati se crashano.
gestire il setup delle tue applicazioni con Puppet, ne vale la
pena.
reverse proxy, e esegui le tue app via unicorn, avendo cura di abilitare la
cache http nginx/apache.
In questo modo puoi:
installare un interprete ruby per app, visto che RVM “locale”.
aggiornare i tuoi interpreti ruby quando ti pare
Sono sicuramente dei vantaggi non indifferenti. Quello che mi ha
sempre fatto evitare Mongrel e altri sistemi simili e stata la necessita di progettare esattamente quante istanze volevo. Io ho un
computer per calcolare cose del genere:-)
E non e solo un punto teorico: se ho N app, mi piace che il sistema limiti quelli non in uso, e da piu risorse a quelli piu richiesti.
La configurazione a cui aspira Matteo quella che attualmente usiamo in
produzione. E’ un setup che da molte soddisfazioni, abbiamo diverse
applicazioni Rails con versioni di Ruby differenti e RVM + bundler
risolvono tutti i problemi. Con unicorn e il preload delle applicazioni
poi i deploy sono allo stato dell’arte.
Tutto questo a scapito di una gestione delle risorse da parte del
sistema. Cosa che cominci a sentire man mano che il numero delle diverse
applicazioni cresce, principalmente per via della memoria che tieni
occupata anche quando l’app idle.
Tanto che mi era venuta la tentazione di valutare quali progressi si
erano fatti con soluzioni tipo Passenger. Ma gi non poter gestire
diverse versioni di Ruby un bel problema.
Tutto questo a scapito di una gestione delle risorse da parte del sistema. Cosa
che cominci a sentire man mano che il numero delle diverse applicazioni cresce,
principalmente per via della memoria che tieni occupata anche quando l’app idle.
Infatti! Se hai molte app che non vedono un uso costante, non e` un
problema indifferente.
Tanto che mi era venuta la tentazione di valutare quali progressi si erano fatti
con soluzioni tipo Passenger. Ma gi non poter gestire diverse versioni di Ruby un
bel problema.
Ho trovato questo, ma non ho minimamente idea di com’e` in pratica:
Che palle:-(
Un’altra soluzione sarebbe un VPS per app, ma… e` un grande spreco a
modo suo.
Tutto questo a scapito di una gestione delle risorse da parte del
sistema. Cosa che cominci a sentire man mano che il numero delle diverse
applicazioni cresce, principalmente per via della memoria che tieni
occupata anche quando l’app idle.
Infatti! Se hai molte app che non vedono un uso costante, non e` un
problema indifferente.
Tanto che mi era venuta la tentazione di valutare quali progressi si
erano fatti con soluzioni tipo Passenger. Ma gi non poter gestire
diverse
versioni di Ruby un bel problema.
Ho trovato questo, ma non ho minimamente idea di com’e` in pratica:
Per funzionare funziona, ma 1 po macchinoso da mantenere. Ne ho
dismesse
2 istanze un paio
Che palle:-(
Un’altra soluzione sarebbe un VPS per app, ma… e` un grande spreco a
modo suo.
Tutto questo a scapito di una gestione delle risorse da parte del
sistema. Cosa che cominci a sentire man mano che il numero delle diverse
applicazioni cresce, principalmente per via della memoria che tieni
occupata anche quando l’app idle.
Infatti! Se hai molte app che non vedono un uso costante, non e` un
problema indifferente.
Tanto che mi era venuta la tentazione di valutare quali progressi si
erano fatti con soluzioni tipo Passenger. Ma gi non poter gestire
diverse
versioni di Ruby un bel problema.
Ho trovato questo, ma non ho minimamente idea di com’e` in pratica:
Sorry mi partito il messaggio in anticipo.
Per funzionare funziona, ma 1 po macchinoso da mantenere. Ne ho
dismesse
2 istanze un paio di mesi fa ed hanno fatto il loro dovere per quasi 2
anni.
Che palle:-(
Un’altra soluzione sarebbe un VPS per app, ma… e` un grande spreco a
modo suo.
Ma, una private cloud single tenant con possibilit di auto scaling, non
fa gola proprio a nessuno?
Sante, David non ha quel tipo di esigenze, n la maggior parte di chi fa
app sartoriali per i propri clienti.
Tipicamente hanno “basso” traffico, o comunque pattern molto
prevedibili.
L’auto scaling ottimo per le startup
vedilo come uno unicorn piu’ versatile e con tutte le belle
funzionalita’
aggiuntive che ti da’ passenger (monitoraggio, check…)
In ambiente python, perl e lua e’ uno degli standard de-facto, ma per
ruby
non abbiamo mai spinto troppo sull’acceleratore, ma ora i tempi
cominciano
a essere maturi.
Se vuoi avere una idea delle potenzialita’ che offre dai una occhiata
qui:
oppure se vuoi proprio andare sul ‘massive’ (e puoi sopportare l’inglese
parlato in antico romano) guarda qui (e’ riferito a python ma i concetti
sono generici):
Ovviamente ha una curva d’apprendimento piu’ ripida delle soluzioni
cut&paste, ma posso dirti che tutti i clienti che lo usano non
tornerebbero piu’ indietro
Se invece preferisci andare sul ‘classico’, anche io do’ un +1 a
nginx+unicorn
Il giorno 10 luglio 2012 22:19, Fabrizio R. [email protected] ha
scritto:
Dipende molto dal carico che hai sulle tue app.
Se per gestire il tuo traffico hai bisogno al massimo di un’istanza,
devi
tenerla sempre allocata perch i tempi di “spawn” sono lenti, e un
browser
non pu aspettare tutto quel tempo.
Se per gestire il tuo traffico hai bisogno di pi di un’istanza per
gestire
il tuo traffico, probabilmente non dovresti porti il problema, e andare
verso una soluzione pi “dedicata”.
…
Io sto considerando di abbandonare anche capistrano, sul lungo periodo,
in favore di una soluzione private cloud basata su cloud foundry. C’è un
gruppo devops-italia su google groups con tante persone che ne sanno più
di me a riguardo.
…
La via private cloud open source mi sembra quella più pulita e
promettente, ho provato a cercare qualcosa su Cloud Foundry e Rails e mi
sembra un’approccio tutt’altro che pulito, perché vengono usate delle
gem non mainstream:
For Ruby 1.9 Cloud Foundry requires a tweak to the jquery-rails
gem.
gem ‘jquery-rails’
gem ‘cloudfoundry-jquery-rails’
For Ruby 1.9 Cloud Foundry requires a tweak to devise.
Un’alternativa, che è una specie di heroku open source, sarebbe
openshift di RedHat che utilizza come base fedora 16 e 18 Red Hat OpenShift enterprise Kubernetes container platform, ma
non funziona ancora ufficialmente con ruby 1.9.x
Per funzionare funziona, ma 1 po macchinoso da mantenere. Ne ho
dismesse
2 istanze un paio di mesi fa ed hanno fatto il loro dovere per quasi 2
anni.
Macchinoso in che senso? A me inizia a sembrare la soluzione che mi
fa girare meno le palle, ma non l’ho mai usato…
Nel mio caso erano 2 eccezioni alla regola: 1 passenger = 1 interprete;
due
app avevano necessit dell’interprete 1.8.7 e 1.9.2 mentre il resto (una
dozzina) la 1.9.3. Macchinoso perch contrariamente e tutto il resto ti
servono deploy lievemente differenti, script di startup e shutdown
ad-hoc,
etc…
Niente di esoterico, ma si allontana dal 1-click deployment.
Se sono poche eccezioni sostenibile, altrimenti IMHO anneghi.
Se vuoi delucidazioni maggiori condivido volentieri setup/esperienza
davanti ad una birra
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
