Forum: Italian Ruby user group 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...

http://serverfault.com/questions/405994/state-of-t...

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.

--
David N. Welton

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

http://www.dedasys.com/

Il giorno 10/lug/2012, alle ore 11:56, David Welton 
<davidnwelton@gmail.com> 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.


Inviato da Ipad

Sante Gennaro Rotondi
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 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.

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

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 Welton" <davidnwelton@gmail.com> 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-passenge...
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.

On Jul 10, 2012 10:37 PM, "David Welton" <davidnwelton@gmail.com> 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-passenge...

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?

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

2012/7/11 Sante Rotondi <saten.r@gmail.com>

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

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%20guid...

Maurizio
--
My profile <https://plus.google.com/100973969013103507046/about>




2012/7/11 Matteo Collina <matteo.collina@gmail.com>

[ 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/

Il giorno 10 luglio 2012 22:19, Fabrizio Regini <freegenie@gmail.com> 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

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

-f

Il giorno 11 luglio 2012 16:09, Fabrizio Regini <freegenie@gmail.com> ha
scritto:

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

https://github.com/ddollar/foreman

Sante Rotondi 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/archit..., 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-m...

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 Collina <matteo.collina@gmail.com>

On Jul 11, 2012 10:30 AM, "David Welton" <davidnwelton@gmail.com> 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 ;)