Webrick + Apache + Proxy

Community FR
1

Bonjour,

Je fais tourner mes applications rails avec Webrick, et j’utilise
apache (1.3) comme proxy pour rediriger les requêtes
vers le port 3000.

Pour l’une de mes applis, j’utilise un virtual host et ça fonctionne
très bien :

<VirtualHost *>
ServerName “application.domaine.fr”
ProxyPass / http://serveur.domaine.fr:3000/
ProxyPassReverse / http://serveur.domaine.fr:3000/

L’ennui, c’est que je suis obligée de demander un nouveau nom de
domaine à mon administrateur à chaque nouvelle
application.

Je voudrais donc que mon application rails apparaisse comme un sous-
répertoire de mon serveur, c’est-à-dire que
http://serveur.domaine.fr/application soit redirigé vers
http://serveur.domaine.fr:3000/

J’ai donc essayé ça :

<VirtualHost *>
ServerName “serveur.domaine.fr”
ProxyPass /application/ http://serveur.domaine.fr:3000/
ProxyPassReverse /application/ http://serveur.domaine.fr:3000/

Et ça marche un tout petit peu. Quand je me connecte à
http://serveur.domaine.fr/application, je suis bien redirigée vers
http://serveur.domaine.fr:3000/ mais les liens ne suivent pas : les
feuilles de style sont cherchée sur
http://serveur.domaine.fr/stylesheets et non sur
http://serveur.domaine.fr:3000/stylesheets
par exemple.

Bref, en dehors de la home page de mon application, ça ne fonctionne
pas.

Existe-t-il une solution en dehors de la réécriture d’adresse ? Et
encore, est-ce que la réécriture d’adresse restera transparente
vis-à-vis de l’utilisateur ? Est-ce que la requête :
http://serveur.domaine.fr/application/posts/new
sera bien interprétée comme
http://serveur.domaine.fr:3000/posts/new
et me créera bien un nouveau post ?

Merci de toute aide.

2

Sauf si ton administrateur refuse, tu devrais passer à Passenger. En
plus d’être plus performant, il te permet de placer tes applications
rails en sous-répertoire.

3

Si c’est dans le cadre d’une mise en production pour moi le nom de
domaine
propre a une application me semble logique.
Si c’est pour du dev, rien ne t’empêche de modifier ton fichier host en
locale, ce qui te permettra de faire correctement pointer tes requêtes
vers
tes applications.

IP SERVEUR application.domaine.fr
IP SERVEUR application2.domaine.fr
IP SERVEUR application3.domaine.fr

Mais je ne suis pas certain de bien comprendre ton problème.

2009/4/9 olfhen [email protected]

4

dans config/production.rbessai :
config.action_controller.relative_url_root
= ‘/monapplication’

2009/4/9 ook? ook! [email protected]

5

un peut de doc :

2009/4/9 guillaume belleguic [email protected]

6

2009/4/9 Tony C. [email protected]

Sauf si ton administrateur refuse, tu devrais passer à Passenger. En
plus d’être plus performant, il te permet de placer tes applications
rails en sous-répertoire.

Passenger requière Apache2, or il est en Apache1.3, donc ce n’est pas
utilisable. Solution: utiliser un cluster de mongrels ou un cluster de
thin,
mais SURTOUT PAS webrick, qui n’est fait QUE pour le développement (et
encore, pour le dev, mongrel est plus efficace. Pour preuve: rails le
prend
par défaut à la place de webrick quand il est présent).

My 2cents.

7

Bonjour,

On 9 avr, 15:49, guillaume belleguic [email protected]
wrote:

dans config/production.rbessai : config.action_controller.relative_url_root
= ‘/monapplication’

Nickel.
Il aura fallu que je passe en Rails 2.3.2 (j’étais en 2.1) et que je
renomme mon
application.rb en application_controller.rb.
Par ailleurs, le nom de mon application était le même que celui d’une
de mes classes,
et ça, ça coince complètement. J’ai donc aussi dû renommer le
répertoire de mon application.

En tout cas merci !

8

On 9 avr, 15:51, guillaume belleguic [email protected]
wrote:

un peut de doc :Configuring Rails Applications — Ruby on Rails Guides…

Vu, merci aussi. je cherchais un truc de ce genre, mais dans le
mauvais guide (je cherchais
dans routing from the outside in)

9

2009/4/10 olfhen [email protected]

Question de débutante : en quoi est-il plus efficace ?

{mongrel,thin} vs webrick : ils répondent plus vite même avec plus de
requête concurrentes. webrick est un serveur principalement http fourni
avec
ruby, il est là de base et pour raisons historiques. Mais il n’est pas
le
plus adapté à http + rails.

–
http://fabien.jakimowicz.com

10

olfhen wrote:

Question de d�butante : en quoi est-il plus efficace ?

Une des nombreuses comparaisons que tu peux trouver :
http://www.missiondata.com/blog/ruby/71/mongrel-vs-webrick/

11

{mongrel,thin} vs webrick : ils répondent plus vite même avec plus de
requête concurrentes. webrick est un serveur principalement http fourni
avec
ruby, il est là de base et pour raisons historiques. Mais il n’est pas
le
plus adapté à http + rails.

Under the hood Webrick c’est du Ruby pur, donc fonctionnel sur 100% des
machines où Ruby est installé, mais est forçément très lent.

Mongrel / thin, ont certaines parties du code écrites en C et
nécessitent quelques dépendances, donc ils seront fonctionnels
out-of-the-box sur 99% des machines où Ruby est installé, pour le 1%
restant il y a quelques manips supplémentaires mais rien de méchant.

12

On 9 avr, 15:40, “ook? ook!” [email protected] wrote:

Solution: utiliser un cluster de mongrels ou un cluster de thin,
mais SURTOUT PAS webrick, qui n’est fait QUE pour le développement (et
encore, pour le dev, mongrel est plus efficace. Pour preuve: rails le prend
par défaut à la place de webrick quand il est présent).

Question de débutante : en quoi est-il plus efficace ?