Installer Passenger mod_rails sous Debian

Le 12 avril 2008 à 10h50 | Publié sous | 9 commentaires

S’il existe un grand nombre de manières de déployer et de faire tourner des applications développées avec Ruby on Rail, comme, au hasard, ce blog, l’hébergement de masse reste encore un vrai problème, principalement pour des raisons de complexité de configuration côté serveur. L’absence sous Apache d’un mod_rails comme il existe un mod_php y était certainement pour beaucoup, jusqu’à la sortie hier de Passenger, aussi appelé mod_rails. Enfin terminés les atermoiements entre mongrel + mod_proxy, ou fastcgi, avec tous les inconvénients inhérents à ces deux solutions. Il existe certes d’autres solutions logicielles, parmi lesquelles ma préférée va à Nginx + Thin, cependant quand on héberge des sites faisant très massivement appel à mod_rewrite, ces dernières sont malheureusement exclues (à moins que quelqu’un ne me porte les quelques 500 rewrite rules qui restent encore ici et là).

Mais sans plus attendre, rentrons immédiatement dans le vif du sujet, l’installation de mod_rails pour Apache 2 sous Debian.

Installation d’Apache 2 et MySQL 5

Dans un premier temps, installez le serveur web Apache 2.2, et la version 5.0 de la base de données MySQL.

7el.net:~$ sudo aptitude update
7el.net:~$ sudo aptitude install mysql-client-5.0 mysql-server-5.0 apache2-mpm-prefork apache2.2-common apache2-utils libmysqlclient-dev libfcgi-dev apache2-dev libapr1-dev 
[...]
7el.net:~$ sudo a2enmod rewrite    

Dans le cas où Aptitude ne vous demanderait pas de mot de passe root, n’oubliez-pas de taper :

7el.net:~$ mysqladmin -u root -h localhost -p 'toto'

Il est évidemment fort peu recommandé de choisir “toto” comme mot de passe root, mais après tout, chacun fait comme il veut.

Ruby et… Rails

Installez maintenant Ruby, rdoc et irb depuis les paquetages Debian, puis Ruby Gem à l’aide des sources afin de bénéficier de la toute dernière version. Gem est le gestionnaire de paquetages de Ruby, un outil absolument indispensable.

7el.net:~$ sudo aptitude install ruby1.8 ruby1.8-dev rdoc irb build-essential
[...]
7el.net:~$ cd /usr/bin
7el.net:/usr/bin$ sudo ln -s ruby1.8 ruby

Ne soyez surtout pas impressionné par la quantité de paquetages à récupérer, nous aurons besoin de compiler un certain nombre de choses, et sans les build-essential, nous n’arriverons à rien.

Récupérez maintenant les sources de la dernière version de Gem, actuellement la 1.0.1, et installez la.

7el.net:/usr/bin$ cd /tmp
7el.net:/tmp$ wget http://rubyforge.org/frs/download.php/35283/rubygems-1.1.1.tgz
[...]
7el.net:/tmp$ tar xvzf rubygems-1.1.1.tgz
7el.net:/tmp$ cd rubygems-1.1.1
7el.net:/tmp/rubygems-1.1.1$ sudo ruby setup.rb    

Installons maintenant notre framework favori, ainsi que le driver MySQL.

7el.net:~$ sudo gem install rails
7el.net:~$ sudo gem install mysql

Et voilà, ce n’est pas tellement plus difficile que ça. Passons maintenant aux choses sérieuses : Passenger.

Installer Passenger mod_rails

Si vous avez suivi toutes les étapes de ce didacticiel, l’installation de Passenger ne devrait pas poser de problèmes.

7el.net:~$ sudo gem install passenger
7el.net:~$ sudo passenger-install-apache2-module

Voilà, c’est terminé. Ajoutez maintenant les lignes suivantes à votre fichier de configuration Apache :

7el.net:~$ sudo echo "LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-1.0.1/ext/apache2/mod_passenger.so" >> /etc/apache2/apache2.conf
7el.net:~$ sudo echo "RailsSpawnServer /usr/lib/ruby/gems/1.8/gems/passenger-1.0.1/bin/passenger-spawn-server" >> /etc/apache2/apache2.conf
7el.net:~$ sudo echo RailsRuby /usr/bin/ruby1.8 >> /etc/apache2/apache2.conf
7el.net:~$ sudo /etc/init.d/apache2 restart

Ajouter une application Rails

Ajouter une application Rails devient aussi simple (plus simple ?) qu’ajouter un site en PHP : il vous suffit de rajouter un vhost basique à votre Apache.


    ServerName t37.net
    DocumentRoot /some/path/t37.net/public

Redémarrer une application sans redémarrer Apache

La cerise sur le gâteau, sans laquelle ce mod_rails n’aurait jamais été utilisable, c’est évidemment la possibilité de redémarrer votre application sans redémarrer le serveur : il vous suffit de créer un fichier nommé restart.txt dans le répertoire tmp de votre application.

touch /some/path/t37.net/tmp/restart.txt

Et voilà, c’est terminé. Quant à moi, je vous laisse, il faut que j’aille supprimer mod_fcgid de mon serveur.

surfer dans la baie des sables d'olonne

  1. Sunny about 2 hours plus tard :

    Merci pour ces étapes, ce genre d’outils qui simplifient au maximum le déploiement sont un régal.

  2. Eric about 9 hours plus tard :

    ””“cependant quand on héberge des sites faisant très massivement appel à mod_rewrite, ces dernières sont malheureusement exclues”“”

    Sauf que c’est vrai aussi par défaut sous Passenger

  3. Olivier BONHOMME 1 day plus tard :

    Voici un module très intéressant permettant de simplifier le déploiement d’applications WEB basées sur rails. On peut espérer qu’avec ce genre d’évolution les applications rails puissent rattraper leur retard sur les applications PHP ou PERL qui disposaient de leur propre module d’accès intégré à Apache.

    La complexité de déploiement par rapport à une application PHP était je pense le gros point noir pour les applications rails qui nécessitaient la mise en place d’un wrapper CGI dont la mise en place n’est pas forcément triviale en particulier pour les administrateurs systèmes occasionnels qui représentent à mon avis un nombre important. (Suffit de voir le nombre de Dedibox louées pour comprendre mais ceci est un autre débat)

    Avec l’apparition de ce module, on peut donc espérer une augmentation de l’utilisation des applications rails.

    Cependant, ce module présente les mêmes défauts que ses “concurrents” que sont mod_php, mod_perl et tout autre mod_<language_quelconque> lorsque l’on cherche à mettre en place une architecture robuste :

    • Pas de possibilité d’utiliser un mode threadé d’apache => Surconsommation de mémoire.
    • Pas de possibilité d’utiliser SuExec pour faire une gestion plus fine des droits.

    Un administrateur pointilleux préférera donc rester sur une solution basée sur FastCGI ou fcgid.

    Malgré celà, l’apparition de ce module va permettre aux applications ruby d’être plus accessibles car plus facilement déployables ce qui permettraient donc à celles-ci de n’être plus utilisées que par un public averti.

  4. Eric 1 day plus tard :

    Oui mais non Olivier, justement.

    Contrairement à mod_php ou mod_perl, l’interpréteur n’est pas embarqué dans le processus Apache. En fait on a une architecture beaucoup plus proche de celle de fast_cgi. Les processus Ruby/Rails sont externes et persistants, Apache ne faisant que renvoyer la requête. On reste effectivement avec un processus Apache par requête mais ce processus Apache peut être très léger quand il n’embarque pas de PHP ou d’interpréteur. Je doute fortement que ces processus Apache soient le goulot d’étranglement quand on a une forte charge sur du Rails. Le problème sera soit sur la mémoire des processus Rails eux même, soit sur le cpu et la db.

    Quant aux équivalents suexec, ils sont justement prévus et intégrés dans ce mod_rails, justement parce qu’on a une structure à la fast_cgi. Le processus Rails prend automatiquement l’utilisateur du fichier d’environement de l’appli Rails.

  5. Olivier BONHOMME 1 day plus tard :

    Au temps pour moi. J’avais compris pour ma part que l’interpréteur était embarqué dans le mod d’ou cette analyse. Cependant, n’ayant pas pu tester encore, est ce que le mod ne contient-il pas du code empéchant de faire fonctionner apache en mode Worker qui est vraiment plus interessant que le prefork.

    A priori non mais bon on ne sait jamais.

    Si effectivement, le mod ne présente pas les désavantages dont j’ai parlé précédemment, ca peut devenir très intéressant y compris pour les administrateurs tatillons ne supportant pas l’utilisateur www (Ce qui est mon cas j’avoue :))

    Une phase de tests s’impose donc :)

  6. Eric 1 day plus tard :

    J’ai cru lire qu’il imposait le prefork par contre, oui. Pas sur que ce soit un si grand problème ceci dit. Un prefork bien configuré au niveau des minimum/maximum est un bon système.

  7. Morgan FITUSSI 4 months plus tard :

    Très bon article, juste une petite correction : Vu qu’on a wget http://rubyforge.org/frs/download.php/35283/rubygems-1.1.1.tgz

    Remplacer ces lignes : 7el.net:/tmp$ tar xvzf rubygems-1.0.1.tgz 7el.net:/tmp$ cd rubygems-1.0.1

    Par : 7el.net:/tmp$ tar xvzf rubygems-1.1.1.tgz 7el.net:/tmp$ cd rubygems-1.1.1

    Merci encore pour l’article.

  8. Morgan FITUSSI 4 months plus tard :

    Autre correction, après le setup, les binaires ne sont pas placés dans /usr/bin/ automatiquement. Il doit y avoir des options pour arranger ca. En attendant un simple : cp bin/gem /usr/bin/ et cp bin/update_rubygems /usr/bin/ permet d’utiliser la commande gem.

  9. Claude 8 months plus tard :

    Dommage que les corrections de Morgan n’ont pas été ajoutés à ton article Fred, je me tirai les cheveux…

Merci de vous exprimer dans un français correct. Les commentaires déplacés, injurieux et le spam seront supprimés.

Les trackbacks sont fermés pour cause de spam.