Le Rayon UX

La radiographie du Web en temps presque réel / thème en chantier (je m'appelle Teuse)

Installer Passenger mod_rails sous Debian

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 modrails comme il existe un modphp y était certainement pour beaucoup, jusqu’à la sortie hier de Passenger, aussi appelé modrails. Enfin terminés les atermoiements entre mongrel + modproxy, 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.

<VirtualHost 91.121.17.203:80>
    ServerName t37.net
    DocumentRoot /some/path/t37.net/public
</VirtualHost>

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

  • Par Sunny 12/04/2008 at 13h09

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

  • Par Eric 12/04/2008 at 20h14

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

  • Par Olivier BONHOMME 13/04/2008 at 13h58

    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 modphp, modperl et tout autre mod_ 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.

  • Par Eric 13/04/2008 at 14h20

    Oui mais non Olivier, justement.

    Contrairement à modphp ou modperl, 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 modrails, justement parce qu’on a une structure à la fastcgi. Le processus Rails prend automatiquement l’utilisateur du fichier d’environement de l’appli Rails.

  • Par Olivier BONHOMME 13/04/2008 at 14h55

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

  • Par Eric 14/04/2008 at 10h46

    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.

  • Par Morgan FITUSSI 03/09/2008 at 13h58

    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.

  • Par Morgan FITUSSI 03/09/2008 at 14h06

    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.

  • Par Claude 24/12/2008 at 14h44

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

Commentaire Installer Passenger mod_rails sous Debian