Jruby, i files statici

Mi riferisco ad una applicazione sviluppata con jruby e quindi
deployata in un servlet container quale tomcat.
E’ in uso collegare tomcat ad apache attraversp mod_jk o, meglio
proxy_ajp.
So che i files statici quali i css, le immagini e i javascript di
solito e’ meglio farli gestire direttamente da apache anziche’ da
tomcat per questioni di performance.
Essendo tali file sotto la directory Pubblic pensavo di copiare tutto
il contenuto di tale directory sotto una directory nella document root
di apache, ovviamente dovrei modificare tutti i path all’interno dei
css, ecc.
Una volta fatto questo posso cancellare il contenuto di Public?

Msan M. wrote:

Mi riferisco ad una applicazione sviluppata con jruby e quindi
deployata in un servlet container quale tomcat.
E’ in uso collegare tomcat ad apache attraversp mod_jk o, meglio
proxy_ajp.
So che i files statici quali i css, le immagini e i javascript di
solito e’ meglio farli gestire direttamente da apache anziche’ da
tomcat per questioni di performance.
Essendo tali file sotto la directory Pubblic pensavo di copiare tutto
il contenuto di tale directory sotto una directory nella document root
di apache, ovviamente dovrei modificare tutti i path all’interno dei
css, ecc.
Una volta fatto questo posso cancellare il contenuto di Public?

Probabilmente sì, ma l’approccio che seguo normalmente è diverso.
Imposto la document root di apache alla directory public di rails e
configuro apache in modo che non faccia proxy a rails di tutte le url
che fanno riferimento a file in quella dir. Così facendo non devo
copiare nulla e gestisco gli aggiornamenti del server più facilmente con
un solo svn update o un git pull.
Lo stesso approccio funziona anche con nginx.

Paolo

2009/9/1 Paolo M. [email protected]:

di apache, ovviamente dovrei modificare tutti i path all’interno dei
css, ecc.
Una volta fatto questo posso cancellare il contenuto di Public?

Probabilmente sì, ma l’approccio che seguo normalmente è diverso.
Imposto la document root di apache alla directory public di rails e
configuro apache in modo che non faccia proxy a rails di tutte le url
che fanno riferimento a file in quella dir. Così facendo non devo
copiare nulla e gestisco gli aggiornamenti del server più facilmente con
un solo svn update o un git pull.
Lo stesso approccio funziona anche con nginx.

Tu sviluppi in jruby no?
Potresti spiegarmi piu’ nei dettagli la tua configurazione?

Msan M. wrote:

2009/9/1 Paolo M. [email protected]:
Tu sviluppi in jruby no?
Potresti spiegarmi piu’ nei dettagli la tua configurazione?

No, jruby non l’ho mai usato ma la configurazione di apache è in larga
parte indipendente dal tipo di application server che si usa.

Qui riporto una configurazione molto semplice, senza load balancing tra
istanze dell’application server. L’ho adattata da una delle mie senza
testarla, ma ad occhio dovrebbe funzionare.

Con ProxyPass /url/ ! definisci ciò che vuoi sia servito direttamente da
apache mentre tutto il resto finirà a rails. E’ importante usare
ProxyPassReverse per mandare al cliente gli header corretti.

<VirtualHost *:80>
DocumentRoot /dir/di/rails/public
ServerName www.ilserver.com
ServerAdmin [email protected]

FileETag INode MTime Size

CustomLog /dir/dei/log/www.ilserver.com-access.log combined
ErrorLog /dir/dei/log/www.ilserver.com-error.log

ProxyPass /javascript/ !
ProxyPass /images/ !
ProxyPass /stylesheets/ !
ProxyPass /favicon.ico !
ProxyPass /robots.txt !
ProxyPass /404.html !
ProxyPass /maintenance.html !

ProxyPass / http://127.0.0.1:3000/
ProxyPassReverse / http://127.0.0.1:3000/
ProxyPreserveHost on

ErrorDocument 404 /public/404.html
ErrorDocument 502 /public/maintenance.html

Per usare un load balancer apache con jruby googlando ho trovato
http://weblogs.java.net/blog/arungupta/archive/2009/06/totd_84_using_a.html

Spero ti sia d’aiuto

Paolo

Marco M. wrote:

Dalla mia personalissima esperienza, per fare lavorare correttamente
l’applicazione sotto il proxy di apache serve il plugin
reverse_proxy_fix GitHub - napcs/reverse_proxy_fix: Rewrites Rails base urls proxied behind IIS and other frontends altrimenti
alcuni url non vengono trovati.

Questo plugin non l’avevo mai sentito. Da quel che ho capito, quando
Apache mappa
http://www.mydomain.com/app1/ in http://backend.mydomain.com:3000/ poi
lui va a (cito) “to prepend http://www.mydomain.com/app1 to all URLs
generated by the application.”

Penso che sia quanto già fa la coppia

ProxyPass / http://127.0.0.1:3000/
ProxyPassReverse / http://127.0.0.1:3000/

ma non ho mai provato a fare reverse proxy di URL come

ProxyPass /app1 http://127.0.0.1:3000/
ProxyPassReverse /app1 http://127.0.0.1:3000/

anche se la documentazione di Apache usa proprio un esempio simile
http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxypassreverse
e quindi mi aspetterei che debba funzionare anche su di loro.

Paolo, sai come collocare diverse applicazioni rails sulla porta 80 di
apache? Io non ci sono riuscito, solo tramite virtualhost con porta
dedicata.

Ne ho un po’ sia in produzione che in sviluppo. Ogni applicazione ha il
suo server name e dominio (in sviluppo li associo a 127.0.0.1 in
/etc/hosts) e poi uso <VirtualHost *:80> con i ProxyPass di cui
scrivevo. Trattandosi però della configurazione che avevo presentato mi
sa che mi stai chiedendo qualcosa di diverso. Se mi dai le URL con cui
vuoi accedere alla applicazioni Rails tramite Apache e le porte su cui
girano effettivamente i mongrel (o quel che usi), potrò aiutarti meglio.

Paolo

Scusa Msan, che versione di rails stai usando sotto tomcat? Io sto
provando la 2.3.4 con tomcat 6 ma sto avendo problemi con rack 1.0

2009/10/8 Marco M. [email protected]:

Scusa Msan, che versione di rails stai usando sotto tomcat? Io sto
provando la 2.3.4 con tomcat 6 ma sto avendo problemi con rack 1.0

Anche io ho la 2.3.4 con tomcat6.
Nessun problema, sto usando jruby 1.3.1 e warbler per i war.

Dalla mia personalissima esperienza, per fare lavorare correttamente
l’applicazione sotto il proxy di apache serve il plugin
reverse_proxy_fix GitHub - napcs/reverse_proxy_fix: Rewrites Rails base urls proxied behind IIS and other frontends altrimenti
alcuni url non vengono trovati.
Paolo, sai come collocare diverse applicazioni rails sulla porta 80 di
apache? Io non ci sono riuscito, solo tramite virtualhost con porta
dedicata.

Grazie per la risposta, non avevo aggiornato warbler.
Comunque anche aggiornandolo c’è un baco con jruby-rack 0.9.5 se usi
l’applicazione in sviluppo:

http://www.ruby-forum.com/topic/196906#new

per risolvere bisogna passare alla 0.9.6, i sorgenti su github:

Ora provo mod_jk.

Comunque su windows, il deploy di applicazioni jruby è tutta un altra
cosa ed anche la gestione delle applicazioni tramite tomcat è molto più
comodo rispetto i servizi mongrel ed anche la gestione della memoria mi
sembra migliore (anche se non ho abbastanza applicazioni per dirlo con
certezza). Insomma mi sto convertendo a jruby.

Msan M. wrote:

In che senso se uso l’applicazione in sviluppo, cioe’ se creo il war
del development anziche’ del production?

Nel senso che funziona solo se usi l’applicazione rails in production
(cache attiva ecc.) mentre in development c’è un bel bug e per risolvere
bisogna usare jruby-rack 0.9.6, trovi il link nell’altra discussione,
l’autore ha anche aggiunto il pacchetto.
Riguardo il war, credo sia lo stesso tra produzione e sviluppo, credo
cambia solo un impostazione nel file web.xml che determina l’am.biente
di
esecuzione di rails ma non sono sicurissimo

Io sto usando proxy_ajp, non c’e’ paragone come difficolta’ di
configurazione.

Allora provo prima questo, grazie per l’informazione

Io usavo ruby ma da quando ho provato la facilita’ del deploy con
jruby non credo tornero’ indietro.

Purtroppo su windows il deploy è laborioso e comunque non mi soddisfa
usare mongrel in produzione, preferirei avere un application server che
faccia anche da contenitore. Glassfish l’ho usato solo in test, in
produzione sto valutando Tomcat perchè ho letto si integra meglio sotto
apache. Devo dire che ora va bene, non è leggero ma consuma meno memoria
rispetto i vari servizi mongrel, se riesco farò dei test per verificare
più nel dettaglio.
Un altro vantaggio di tomcat è la flessibilità nella gestione del
carico. Se per esempio un applicazione attraversa una fase concitata,
basta aumentare il numero dei thread nel file web.xml e riavviare
l’istanza. Con mongrel invece dovrei creare un nuovo servizio ed
inserirlo nel bilanciamento del carico sotto apache, si può fare ma
costa un pò di più.

2009/10/8 Marco M. [email protected]:

Grazie per la risposta, non avevo aggiornato warbler.
Comunque anche aggiornandolo c’è un baco con jruby-rack 0.9.5 se usi
l’applicazione in sviluppo:

In che senso se uso l’applicazione in sviluppo, cioe’ se creo il war
del development anziche’ del production?

Error Deploying 2.3.4 to Tomcat 6, due to Rack 1.0 - JRuby - Ruby-Forum

per risolvere bisogna passare alla 0.9.6, i sorgenti su github:
GitHub - nicksieger/jruby-rack: Rack for JRuby and Java appservers

Ora provo mod_jk.

Io sto usando proxy_ajp, non c’e’ paragone come difficolta’ di
configurazione.

Comunque su windows, il deploy di applicazioni jruby è tutta un altra
cosa ed anche la gestione delle applicazioni tramite tomcat è molto più
comodo rispetto i servizi mongrel ed anche la gestione della memoria mi
sembra migliore (anche se non ho abbastanza applicazioni per dirlo con
certezza). Insomma mi sto convertendo a jruby.

Io usavo ruby ma da quando ho provato la facilita’ del deploy con
jruby non credo tornero’ indietro.

2009/10/26 Marco M. [email protected]:

Purtroppo ci sono anche i lati negativi: non mi piace il fatto che con
il deploy su un app server java si debba avere una struttura di
directory semplificata rispetto a una classica applicazione rails: la
public viene spostata nella root, crea la cartella WEB-INF dove piazza i
sorgenti ecc. …non so se c’è un rimedio ma così non si riesce più ad
usare rake in produzione e non vorrei avere problemi con applicazioni
più complesse che usano/creano files sotto public

Prova a postare il problema nella mailing list di jruby, sono molto
gentili e rispondono sempre.

Purtroppo ci sono anche i lati negativi: non mi piace il fatto che con
il deploy su un app server java si debba avere una struttura di
directory semplificata rispetto a una classica applicazione rails: la
public viene spostata nella root, crea la cartella WEB-INF dove piazza i
sorgenti ecc. …non so se c’è un rimedio ma così non si riesce più ad
usare rake in produzione e non vorrei avere problemi con applicazioni
più complesse che usano/creano files sotto public