divERsions Parce qu'il faut un blog (Erlang mode)…

Installation et démarrage de Mochiweb

Afin de réaliser une application web, il est nécessaire d’obtenir et utiliser un serveur applicatif qui sera capable de fournir les services dynamiques.

Au niveau Erlang, le choix est vite cerné, et ce rôle sera dévolu à l’application Mochiweb.

Mochiweb est une application OTP, et respecte donc tous les principes décrits précédemment.

Installation

L’installation se fait en récupérant les sources du système directement. En effet, il s’agit d’une application Erlang, et donc de scripts .erl qui doivent être compilés par la machine virtuelle Erlang.

Ce n’est pas la peine de chercher de « package » Mochiweb pour votre environnement particulier car cela n’a pas de sens.

Les sources sont stockés au niveau de google code, et doivent être récupérés par Subversion :

$ yaourt -S subversion
$ cd /d/apps
$ svn co http://mochiweb.googlecode.com/svn/trunk/ mochiweb
$ cd mochiweb
$ make

Ce répertoire sera noté $mochiweb pour la suite du document.

La commande make lance la compilation de tous les sources de tous les répertoires via l’outil de ligne de commande erlc. Au final, on obtient une application OTP au niveau du répertoire mochiweb/ebin.

Le makefile est très simple :

all:
    (cd src;$(MAKE) all)
edoc:
    (cd src;$(MAKE) edoc)
test:
    (cd src;$(MAKE) test)
clean:
    (cd src;$(MAKE) clean)

En fait, le vrai fichier se trouve dans le répertoire src.

De la même façon, on peut donc générer la documentation de l’application en lançant la commande suivante :

make edoc

La documentation est alors disponible dans le répertoire mochiweb/docs/index.html.

Création de l’application

Le script doit être modifié car il n’est pas exécutable par défaut :

chmod +x scripts/new_mochiweb.erl

Il s’agit de code source rattaché à l’environnement erlang, voici les premières lignes du script :

#!/usr/bin/env escript
%% -*- mode: erlang -*-
-export([main/1]).

Une application Mochiweb correspond à la création d’un squelette applicatif, dont les sources / dépendances sont recopiées à partir du répertoire racine $mochiweb récupéré depuis Subversion.

Les sources du squelette de la future application se trouvent dans le répertoire $mochiweb/priv/skel. Ces sources seront recopiés au niveau de l’emplacement de la nouvelle application.

La création d’une application consiste donc à copier les squelettes dans un nouvel environnement, compiler les sources puis démarrer l’application OTP ainsi créée.

Les étapes se résument ainsi :

cd $mochiweb
scripts/new_mochiweb.erl ann /d/apps
cd /d/apps/ann
make
./start-dev.sh

Les codes retour affichés sur la console devrait afficher quelque chose d’approchant :

supervisor: {local,ann_sup}
   started: [{pid,},
             {name,ann_web},
             {mfa,{ann_web,start,
                           [[{ip,"0.0.0.0"},
                             {port,8000},
                             {docroot,"/d/apps/ann/priv/www"}]]}},
             {restart_type,permanent},
             {shutdown,5000},
             {child_type,worker}]

Le site est accessible à l’adresse http://localhost:8000 et la page affiche alors « MochiWeb running. ».

Oui, mais comment ?

La page affichée est stockée dans le répertoire des fichiers du site web, comme indiqué précédemment, dans priv/www. La page index.html est le contenu affiché par défaut.

Le code de réaction aux requêtes est stocké dans src/ann_web.erl

Le fonctionnement est le suivant, l’application (src/ann_app.erl) démarre le superviseur (ann_sup:start_link().) dans sa méthode start. ann_sup est un superviseur au sens OTP, il s’agit d’un comportement :

-behaviour(supervisor).

sa méthode init est responsable de créer les processus enfants à surveiller. Le processus créé ici est correspond bien à ann_web :

init([]) ->
    ...,
    Web = {ann_web,
           {ann_web, start, [WebConfig]},
           permanent, 5000, worker, dynamic},
 
    Processes = [Web],
    {ok, {{one_for_one, 10, 10}, Processes}}.

one_for_one correspond à la stratégie de redémarrage : si un processus de réponse aux requêtes est tué, le superviseur en recrée un pour le remplacer.

La méthode start de ann_web démarre mochiweb_http:start en lui passant comme boucle de traitements la méthode ann_web:loop.

La méthode loop/0 renvoie le fichier correspondant à l’url pour toute requête get :

case Req:get(method) of
    Method when Method =:= 'GET'; Method =:= 'HEAD' ->
        case Path of
            _ ->
                Req:serve_file(Path, DocRoot)
        end;

Modification à chaud

L’intérêt d’Erlang est le remplacement des modules à chaud, c’est à dire sans arrêt du serveur applicatif. Cela est absolument essentiel pour les applications télécomms pour lesquelles le langage fut inventé et pour justifier d’un taux de haute disponibilité ahurissant.

Nous allons reproduire le code montré en exemple sur le site de beebole en ajoutant ce code dans le fichier src/ann_web.erl :

case Req:get(method) of
      Method when Method =:= 'GET'; Method =:= 'HEAD' ->
        case Path of
          "about" ->
            Req:ok({"text/html", [],["<h1>A propos...</h1>"]});
          _ ->
            Req:serve_file(Path, DocRoot)
        end;

Il faut recompiler le source par la commande make à la racine du projet. Si tout s’est bien passé, la console erlang affiche alors l’information suivante :

=PROGRESS REPORT=
         application: ann
          started_at: nonode@nohost
    Reloading ann_web ... ok.

eh oui, le module compilé a été chargé et sera utilisé à la place de l’ancien lors des requêtes suivantes.

Accès simple à la documentation

La documentation Mochiweb peut être ajoutée très simplement à l’application en cours de développement (si un navigateur n’a pas été installé localement comme dans mon cas) en créant un lien symbolique dans le répertoire www :

cd $app
cd priv/www
ln -s /d/apps/mochiweb/doc

On peut alors y accéder depuis l’url http://localhost:8000/doc/index.html.

Référencez cet article