Deploy con passenger, rvm, git e magari un po' di sicurezza

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 piudi 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’eda 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.


David N. Welton

http://www.welton.it/davidw/

http://www.dedasys.com/

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’eda 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.

Inviato da Ipad

Sante Gennaro R.
Responsabile ICT ─ CIO

dSmart srl
Via per Cernusco 1
20060 Bussero (Mi)

Ciao David,

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.

Ciao,

Matteo

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 estata la necessita di progettare esattamente quante istanze volevo. Io ho un
computer per calcolare cose del genere:-)

E non esolo un punto teorico: se ho N app, mi piace che il sistema limiti quelli non in uso, e da piurisorse a quelli piu richiesti.


David N. Welton

http://www.welton.it/davidw/

http://www.dedasys.com/

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.

-f

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:

http://blog.phusion.nl/2010/09/21/phusion-passenger-running-multiple-ruby-versions/

Che palle:-(

Un’altra soluzione sarebbe un VPS per app, ma… e` un grande spreco a
modo suo.


David N. Welton

http://www.welton.it/davidw/

http://www.dedasys.com/

On Jul 10, 2012 10:37 PM, “David W.” [email protected] wrote:

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:

http://blog.phusion.nl/2010/09/21/phusion-passenger-running-multiple-ruby-versions/
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.

Ma, una private cloud single tenant con possibilit di auto scaling, non
fa gola proprio a nessuno?

On Jul 10, 2012 10:37 PM, “David W.” [email protected] wrote:

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:

http://blog.phusion.nl/2010/09/21/phusion-passenger-running-multiple-ruby-versions/

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.

2012/7/11 Sante R. [email protected]

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 :slight_smile:

Matteo

Qualcuno ha gia’ provato Passenger Standalone [1] ?

Automatically spawns and shuts down application processes. One Phusion

Passenger Standalone instance can therefore handle multiple simultaneous
connections and handles resource management for you. Crashing application
processes are automatically restarted.

[1]
http://www.modrails.com/documentation/Users%20guide%20Standalone.html

Maurizio

My profile https://plus.google.com/100973969013103507046/about

2012/7/11 Matteo C. [email protected]

[ parlando di Passenger Standalone ]

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…


David N. Welton

http://www.welton.it/davidw/

http://www.dedasys.com/

diverse versioni di Ruby un bel problema.

Io invece mi permetto di tirare acqua al mio mulino e ti consiglio di
dare
una occhiata a:

http://projects.unbit.it/uwsgi/wiki/QuickstartRack

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:

http://projects.unbit.it/uwsgi/wiki/rubyDSL

Se ti interessa l’hosting di piu’ istanze questo puo’ fare al caso tuo:

http://projects.unbit.it/uwsgi/wiki/Emperor

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):

http://www.youtube.com/watch?v=jfkKOaNsE00

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

Mai fatto, vorrei iniziare oggi, qualche link da condividere
sull’argomento Procflie + Upstart?

-f

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”.

Ciao,

Matteo

Il giorno 11 luglio 2012 16:09, Fabrizio R. [email protected] ha
scritto:

Mai fatto, vorrei iniziare oggi, qualche link da condividere
sull’argomento Procflie + Upstart?

https://github.com/ddollar/foreman

Sante R. wrote in post #1068100:


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.

Uncomment next line if you plan to use devise.

gem ‘cloudfoundry-devise’, :require => ‘devise’

cit: http://docs.cloudfoundry.com/frameworks/ruby/rails-3-1.html

Un’alternativa, che è una specie di heroku open source, sarebbe
openshift di RedHat che utilizza come base fedora 16 e 18
https://openshift.redhat.com/community/wiki/architecture-overview, ma
non funziona ancora ufficialmente con ruby 1.9.x

Nel frattempo, un approccio Heroku-style, non completamente isolato, è
utilizzare un file Procfile con altri tool noti per il deploy
http://michaelvanrooijen.com/articles/2011/06/08-managing-and-monitoring-your-ruby-application-with-foreman-and-upstart/

Ciao
Luigi

Se usate foreman, consiglio anche l’uso di pry [1] e pry-remote [2] per
il
debug delle app.

[1] http://pryrepl.org/
[2] https://github.com/Mon-Ouie/pry-remote

Maurizio

My profile https://plus.google.com/100973969013103507046/about

2012/7/11 Matteo C. [email protected]

On Jul 11, 2012 10:30 AM, “David W.” [email protected] wrote:

[ parlando di Passenger Standalone ]

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 :wink: