lindev.fr

Aller au contenu | Aller au menu | Aller à la recherche

27 août 2014

Django déploiement avec Nginx Gunicorn et Supervisord

Je vois souvent passer des questions sur le forums ou autres fils de discussion concernant la mise en production d'un projet Django.
Ici je vais présenter une façon de faire, utilisant Nginx Gunicorn et Supervisord .

Prérequis

Sur une Débian toute fraiche,

Nginx

sudo apt-get install nginx

Virtualenv

Car nous travaillons toujours avec un environnement virtuel, dans lequel nous allons y installer les dépendances de notre projet.
Ce qui permet de ne pas avoir de conflit de version avec d'autres éventuels projets déjà en prod.

pip install virtualenv virtualenvwrapper

Note : Si vous n'avez pas l'outil pip de disponible, installez-le comme ceci

sudo apt-get install python-setuptools
sudo easy_install pip

Puis dans votre fichier ~/.bashrc , ajoutez les lignes suivantes, pour l'autocompletion

export VIRTUALENVWRAPPER_VIRTUALENV_ARGS='--no-site-package'
export WORKON_HOME=$HOME/.virtualenvs
source /usr/local/bin/virtualenvwrapper.sh

Gunicorn

Pourquoi pas utiliser uWSGI ? humm ... car je préfère Gunicorn qui me donne toute satisfaction sur mes projets en prod. donc ... pourquoi pas !

sudo apt-get install libevent-dev
pip install gunicorn

Supervisor

Installation simple :

sudo pip install supervisor

Récupération du fichier de conf par défaut

echo_supervisord_conf > /etc/supervisord.conf

Dans le fichier de conf, afin de pouvoir manager votre projet via l'interface web, il faut dé-commenter et paramétrer les lignes suivantes

[inet_http_server]         ; inet (TCP) server disabled by default
port=*:9001        ; (ip_address:port specifier, *:port for all iface)
username=user              ; (default is no username (open server))
password=123               ; (default is no password (open server))

Note: Changer le username et password évidemment

L'interface web sera disponible à l'adresse : http://ipduserveur:9001

Pour le lancement automatique au démarrage du système, vous pouvez utiliser ces scripts d'init:

  1. debian init supervisor
  2. debian init supervisor

Installer votre projet

Notre environnement est prêt, nous allons commencer par installer le projet Django dans l’environnement virtuel.

Création du virtualenv

mkvirtualenv monprojet

Si vous utilisez git, cloner votre projet, sinon, copier le à l'endroit que vous souhaitez, ( pour l'exemple ce sera /var/www/monprojet )

Installation des dépendances du projet

si vous utilisez également les environnements virtuels pour développer ( ce que je conseille ) vous pouvez alors enregistrer la liste des libs python installées dans cette environnement, afin de pouvoir également les installer ( avec la même version ) sur un autre serveur.

Pour avoir la liste des libs :

pip freeze > requirements.txt

puis sur votre serveur, pour installer les libs depuis un export freeze :

pip install -r requirements.txt

Configuration de Django

Il vous faudra peut-être toucher un peu à votre fichier settings.py pour le passer du mode debug au mode production.
Personnellement j'utilise une autre subtilité qui me permet de ne pas avoir à toucher au fichier settings.py ( j'expliquerai celà dans un autre billet ) .

N'oubliez pas de vérifier le paramètre STATIC_ROOT

STATIC_ROOT = '/var/www/static_monprojet/'

C'est le répertoire ou seront copiés les fichiers statiques du projet, pour ensuite être servis par Nginx

Ce répertoire DOIT EXISTER

Une fois le répertoire créé, nous allons y "placer/lier" les fichiers statiques du projet

python manage.py collectstatic --link

Perso je préfère y mettre des liens symboliques .. ( les gouts et les couleurs ... )

Liaison du projet avec Gunicorn

Nous allons créer un fichier dans notre projet qui sera utilisé pour le lancement du/des process Gunicorn ( vous devrez adapter les valeurs dans ce script )

vim /var/www/monprojet/monprojet/gunicorn.sh

Et voici le contenu

#!/bin/bash
  set -e
  NUM_WORKERS=2
  USER=www-data
  GROUP=www-data
  ADDRESS=127.0.0.1:5002
  cd /var/www/monprojet
  source /home/monuser/.virtualenvs/monprojet/bin/activate
  exec gunicorn monprojet.wsgi:application -w $NUM_WORKERS --bind=$ADDRESS \
    --user=$USER --group=$GROUP --log-level=debug

Puis on le rend exécutable

chmod 777 /var/www/monprojet/monprojet/gunicorn.sh

Configuration Supervisord

Notre projet est prêt, afin de lancer Gunicorn automatiquement, nous allons utiliser supervisord, qui en plus de s'occuper de démarrer le projet automatiquement au démarrage du système, va aussi le relancer en cas de crash, gérer les logs et vous donner la main pour arrêter ré-demarrer les process, via l'interface web ou en mode console.

supervisord.png

Ajoutez à la fin du fichier de configuration /etc/supervisord.conf les lignes suivantes ( paramètres à adapter selon votre cas )

[program:guni_monprojet]
directory=/var/www/monprojet/monprojet
user = www-data
autostart=true
autorestart=true
stdout_logfile=/var/log/monprojet.log
redirect_stderr=true
stopsignal=QUIT
command = /var/www/monprojet/monprojet/monprojet.sh

Ne reste plus qu'à redémarrer supervisor pour prendre en compte la nouvelle config.

Pour le lancer manuellement

supervisord -c /etc/supervisord.conf

Vhost Nginx

Dernier point, la création du vhost de Nginx, pour diriger les requêtes vers Gunicorn qui écoute sur le port 5002 ( il est aussi possible d'utiliser un fichier socket à la place )

vim /etc/nginx/sites-enabled/monprojet

Et voilà le contenu ( fonctionnel, mais vous pouvez l'adapter )

upstream us_monprojet {
        server 127.0.0.1:5002;
}


server {
        listen 80;

        root /var/www/monprojet;

        gzip             on;
        gzip_min_length  1000;
        gzip_proxied     expired no-cache no-store private auth;
        gzip_types       text/plain application/xml text/css text/javascript application/x-javascript application/x-shockwave-flash video/x-flv;
        gzip_disable     "MSIE [1-6]\.";


        server_name monprojet.com;
        charset utf-8;

        client_max_body_size 75M;


        location ~ /\.ht {
            deny  all;
        }

        location /favicon.ico {
                alias /var/www/monprojet/monprojet/static/favicon.ico;

                if (-f $request_filename) {
                        access_log off;
                        expires max;
                }

        }


        location /media {
                alias /var/www/monprojet/monprojet/media;

                if (-f $request_filename) {
                        access_log off;
                        expires max;
                }

        }

        location /static {
                alias /var/www/static_monprojet/;

                if (-f $request_filename) {
                        access_log off;
                        expires max;
                }

        }
location / {

                if (-f $request_filename) {
                        access_log off;
                        expires max;
                }       

                #gunicornParams
                if (!-f $request_filename) {
                        proxy_pass         http://us_monprojet;
                        break;
                }       
                proxy_redirect     off;
                proxy_set_header   Host             $host;
                proxy_set_header   X-Real-IP        $remote_addr;
                proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;

        }       
}       

Ne reste plus qu'à activer le vhost, et relancer nginx

ln -s /etc/nginx/sites-available/monprojet /etc/nginx/sites-enabled/
service nginx reload

24 août 2010

PHP 5.3.3 et php-fpm

php-fpm

php-fpm-logo.gif

Voilà quelques semaines que la version 5.3.3 de php est sortie avec comme belle nouveauté php-fpm .
Au risque de répéter la doc officielle , php-fpm est :

  • FPM permet notamment de faire tourner plusieurs VHosts avec un UID/GID différent et des PHP.ini différents.
  • Support de l'upload accéléré
  • Statistiques de base (similaire au module mod_status d'Apache)
  • Redémarrage de secours en cas de destruction accidentelle du cache opcode, lors de l'utilisation d'un accélérateur de code PHP
  • Amélioration de la gestion des processus en cas de graceful stop/start
  • Journalisation des scripts lents
  • Journalisation de stdout et stderr
  • fastcgi_finish_request() une fonction spéciale pour clôturer la connection avec le client, mais continuer un traitement php/

Installation

A partir de php 5.3.3 , les sources de php-fpm sont intégrés au core , il vous suffit dont d'ajouter le paramètre --enable-fpm à la compilation , voici donc un exemple de fichier de configuration à la compilation :

#!/bin/sh

export OPTIM=-02
./configure --prefix=/usr/local \
        --enable-fpm
        --with-xsl \
        --enable-soap \
        --with-gettext \
        --enable-mbstring --with-mbstring=all \
        --disable-debug \
        --enable-memory-limit \
        --enable-ftp \
        --with-mcrypt \
        --enable-zip \
        --enable-calendar \
        --enable-exif \
        --enable-pdo \
        --with-pdo-mysql \
        --with-mysql \
        --with-pdo-sqlite \
        --with-sqlite \
        --with-zlib \
        --with-jpeg-dir \
        --with-gd \
        --with-freetype-dir=DIR \
        --with-imap-ssl \
        --with-kerberos \
        --with-imap \
        --with-curl \
        --enable-bcmath \

Le seul impératif , est d'avoir le paquet libevent en version 1.4.11 minimum .
En cas de besoin voici les sources de cette lib : http://packages.debian.org/source/sid/libevent

Un simple

./configure
make
make install

fera l'affaire.

Configuration

Une fois l'installation de php terminée il vous faudra faire quelques petits réglages de base pour le bon fonctionnement .
nous allons commencer par editer le fichier de configuration par defaut de php-pfm

cp /usr/local/etc/php-fpm.conf.default /usr/local/etc/php-fpm.conf
vim /usr/local/etc/php-fpm.conf

J'ai pour habitude de tester avec les paramètres par défauts , puis d'adapter en fonction de mes besoins , voici donc la liste des paramètres à décommenter ( si ce n'est déjà fait ) , chez moi le groupe et l'utilisateur qui lance les process php sont www-data , à adapter dans votre cas , il est conseillé de mettre un utilisateur sans pouvoir .


  • pid = /usr/local/var/run/php-fpm.pid
  • error_log = /usr/local/var/log/php-fpm.log
  • listen.allowed_clients = 127.0.0.1
  • user = www-data
  • group = www-data
  • pm = dynamic
  • pm.max_children = 50
  • pm.start_servers = 20
  • pm.min_spare_servers = 5
  • pm.max_spare_servers = 35
  • pm.max_requests = 500

Voilà pour le fichier de configuration .

Démarrage automatique

Nous allons mettre l'exécutable dans le répertoire init.d afin qu'il lance automatiquement php-fpm au démarrage du serveur .

cd /etc/init.d
vim php-fpm

Voici le contenu .. très ... basique mais fonctionnel :)

#!/bin/bash

start() {
      echo -n "Starting PHP-FPM: "
            /usr/local/sbin/php-fpm
}
stop() {
      echo -n "Stopping PHP-FPM: "
      killall -9 php-fpm
}

case "$1" in
    start)
          start
    ;;
    stop)
          stop
    ;;
    restart)
          stop
          start
    ;;
    *)
          echo "Usage: php-fpm {start|stop|restart}"
          exit 1
    ;;
esac
exit 0

Enfin , la commande pour le lancement au démarrage du serveur

chmod 777 /etc/init.d/php-fpm
update-rc.d php-fpm defaults

On peu maintenant lancer la bête , par un simple appel à : php-fpm

/etc/init.d/php-fpm start

Si tout se passe correctement vous ne devriez avoir aucun message d'erreur , et une série de process se mettent à l'écoute sur le port 9000 par défaut .
Je vous laisse explorer la doc pour affiner vos réglages et aller plus loin quand à la virtualisation d'hôtes .
Utiliser php-fpm avec Nginx semble donc maintenant évident .. voilà qui va nous simplifier la vie , plus particulièrement à cette étape : liaison php - nginx

Avec apache:

Merci à Stealth35

pour ceux qui voudraient tester sur apache voilà le code à ajouter dans votre configuration httpd.conf ou dans vos vhost si vous en utilisez:

<Location "/php-fpm">

Order Deny,Allow Deny from All Allow from ENV=REDIRECT_STATUS
</Location>

FastCgiExternalServer /php-fpm-handler -host 127.0.0.1:9000
AddType application/x-httpd-php .php
Action application/x-httpd-php /php-fpm
ScriptAlias /php-fpm /php-fpm-handler

07 avr. 2010

Nginx - Vhost - php - perl - ssl

banniere-nginx.png
Bon , le billet qui sert de pont de départ ... pas toujours évident sur un blog de s'y retrouver .. sans sommaire ...
Voici donc le sommaire concernant les billets de Nginx

Installation , et utilisation de base

Installer Nginx manuellement , options de compilation , découvrez les emplacements des différents fichiers de configuration , démarrage automatique , options de base ect ...

Gérer les pages PHP et PERL

Nginx seul c'est bien , mais pouvoir l'utiliser avec php perl et .. tant d'autres , c'est mieux , dans ce billet , est éxpliqué la mise en place de php et perl en fast-cgi , et la liaison avec nginx .

SSL , vhost , et autres petites options

Mise en place de pages sécurisées par ssl , création de certificats , redirection automatique , mod_rewrite , compatibilité avec certains framework qui ont besoin du mod rewrite commezend framework , symphony , etc ...

06 avr. 2010

Nginx , SSL et plus encore ..

logo_openssl.gifVoici le troisième volet sur Nginx et son utilisation .
Nous allons voir aujourd'hui la mise en place d'un certificat pour une connexion sécurisé SSL via OpenSSL , mais aussi un passage sur les réécritures d'url , en fonction d'une classe d'adresse IP ,ou la mise en place de réécritures pour l'utilisation d'un framework tel que le ZF , Sympho ou Autres ...
La mise en cache des données statiques ...
Etc etc ..

Open SSL

Il faut dans un premier temps générer les certificats auto-signés , pour celà il vous faudra installer openssl

apt-get install openssl

Certificats

Ensuite , nous allons générer un certificat , plaçons nous dans un le répertoire de conf de Nginx .

mkdir /etc/nginx/certificats
cd /etc/nginx/certificats
openssl req -new -x509 -nodes -out mon-site.fr.crt -keyout mon-site.fr.key

Vhosts

Nous voilà avec de magnifiques certificats auto-signés , nous allons maintenant modifier notre vhost pour qu'il soit dorénavant en https .
Nous allons donc changer le
listen 80;
par
listen 443;
Et enfin , voici les quelques lignes à ajouter pour utiliser nos certificats fraichement crées .

ssl on;
ssl_certificate /etc/nginx/certificats/mon-site.fr.crt;
ssl_certificate_key /etc/nginx/certificats/mon-site.fr.key;
ssl_session_timeout 5m;

Restart Nginx

Et comme d'habitude , il faut recharger les fichiers de conf de nginx

/usr/local/nginx/sbin/nginx -s reload

info.pngsources de la doc

Redirection 301

Il est parfois ( souvent ) utile de faire des redirection 301 pour une histoire de référencement ou autres , voici la conf du vhost à rediriger :

server {
  listen 80;
  server_name example.com;
  rewrite ^/(.*) http://www.example.com/$1 permanent;
}

Pour mettre un code 302 , il faut juste changer permanent par redirect

info.pngDocumentation du module

Redirection interne / externe

Prenons l'exemple d'un site qui de l'extérieur est accessible en ssl , et de façon standard en local , voilà comment faire une redirection automatique :

    if ($remote_addr !~  "^(10\.0\.0\.\d+)"){
            rewrite ^/(.*)$ https://siteA.mon-site.fr permanent;
    }

Chaque client dont l'adresse IP n'est pas 10.0.0.0-255 se verra obligé de passer par une connexion sécurisée .

Redirection pour framework

Beaucoup de framework tel que le zend-framework , symphony et bien d'autres utilisent des règles de redirections ( via par exemple le mod_rewrite d'apache ) pour rediriger toutes URL différentes de média statiques vers le bootstrap ( index.php ) , qui lui s'occupe de lancer le chef d'orchestre .

Voilà le code à ajouter dans votre vhost pour effectuer cette redirection .

location /  {
    index index.php;

    if (-f $request_filename) {
        access_log off;
        expires max;
    }

    if ($request_filename !~ "\.(js|ico|gif|jpg|jpeg|png|css|txt|pdf|doc|odt|xls|swf|mp3)$") {
        rewrite ^(.*) /index.php last;
    }    

Cache

Nginx peut aussi gérer du cache , pour servir plus rapidement , les données dites statiques , voilà une façon de l'activer :

location ~* ^.+.(jpg|jpeg|gif|css|png|js|ico)$ {
            access_log        off;
            expires           30d;
        }

Une autre méthode , ( qui est présente ci-dessus )

if (-f $request_filename) {
    access_log        off;
    expires max;
    }

warning.pngMais attention , cette deuxiéme méthode , n'est valable que si vous utilisez un framework , qui joue avec les réécritures d'url , car le script ci-dessus se traduit comme ceci :

Si le fichier de la requête existe , alors on le met/ utilise en cache .

Etant donne que l'utilisation de réécriture d'url , implique que toutes les requêtes utilisateurs , sont "factices" , elles ne représentent pas réellement la structure de fichiers/répertoires de votre site , sauf , le fichiers statiques tels que les images , css , js etc ... mais les chargements sont fait automatiquement .
Voilà pourquoi cette deuxième méthode ne fonctionne qu'avec un FW qui utilise la réécriture d'url .

Conclusion

Et bien cette fois nous y voilà , un serveur http complet , prêt à servir de nombreuses pages , à héberger n'importe quel framework , et tout ça avec de trés bonnes performances .
De nombreuses autres options / modules existes , je vous invite à les parcourir :
modules nginx

En espèrent que cette petite série de tuto vous a intéressé , n'hésitez pas à laisser un commentaire , ça fait toujours plaisir ,

Christophe.

05 avr. 2010

Nginx + php fastcgi + perl

nginx-logo2.pngCa y est , voici la deuxième partie certainement attendu .. non !! ha .. bon .. spa grave ..
Je disais donc , nginx est maintenant en place , mais il faudrait peut être penser à le rendre compatible avec les 90% des sites sur le net aujourd'hui , c'est à dire php .. et pourquoi pas python tant que l'on y est .
Pour mettre en place cette liaison , nous allons utiliser php en fast-cgi .
Nginx ne possédant pas de mod_php comme apache , les requêtes php seronts donc transmises aux process php que nous aurons lancés en tâche de fond .
Je ne vais pas débattre des avantages et des inconvénients d'utiliser php en fastcgi , ce n'est pas le but de ce topic , mais sachez juste qu'aujourd'hui php en fastcgi est très apprécié , pour sa stabilité et sa sécurité , c'est pourquoi l'on retrouve souvent ce mode de fonctionnement chez les hébergeurs aujourd'hui ...
Vous n'étiez pas au courant ? ..

Note du 24/08/10 : Depuis php 5.3.3 il est bien plus simple et performant d'utiliser php-fpm , voir le tuto à ce sujet

PHP compilation

Et oui encore , il nous faut compiler php spécialement pour le mod fast-cgi ( ne vous inquiétez pas , il est maintenant impossible de repasser en mode cgi simple , vous aurez forcement du Fastcgi ).
Comme d'hab voici les étapes ,

  1. Récupération des source
  2. décompactage
  3. création du fichier de config à la compilation
  4. trio : ./configure make / make / install

Récupération de php

Voilà les lignes de commande correspondantes ( PHP 5.3.2 )

wget http://fr2.php.net/get/php-5.3.2.tar.gz/from/this/mirror
tar xzf php-5.3.2.tar.gz
cd /usr/local/src/php-5.3.2/
vim my_configure

Config de compilation

Voici un exemple , de config de php ( celui de ma machine de dev ) je vous laisse ajuster selon vos besoins ..

#!/bin/sh

export OPTIM=-02
./configure --prefix=/usr/local \
        --with-xsl \
        --enable-soap \
        --with-gettext \
        --enable-mbstring --with-mbstring=all \
        --disable-debug \
        --enable-memory-limit \
        --enable-ftp \
        --with-mcrypt \
        --enable-zip \
        --enable-calendar \
        --enable-exif \
        --enable-pdo \
        --with-pdo-mysql \
        --with-mysql \
        --with-pdo-sqlite \
        --with-sqlite \
        --with-zlib \
        --with-jpeg-dir \
        --with-gd \
        --enable-bcmath \
        --with-curl \

Compilation , go go go

make 
make install 

Vérification

Nous voilà avec normalement un exécutable nommé php-cgi dans /usr/local/bin_

Process FastCgi

Nous allons donc maintenant créer un script qui sera chargé de lancer X process , qui ont pour mission de répondre aux requêtes php envoyées par nginx.

Création

cd /etc/init.d/
vim php-fastcgi

Le script peut exister sous des formes plus ou moins différentes , voici celui que j'utilise :

download.pngphp-fastcgiwrapper php-fastcgi

warning.pngLà encore les script est adapté , si vous avez suivi à la lettre mon tutoriel , si vous avez effectué des modification vérifiez les paramètres , notamment:

  • USER
  • PHP_CGI

Ajout au RC

Il faut lui aussi le rendre exécutable , et le mettre dans le RC , afin que les process soient lancés au démarrage de la machine .

chmod 777 php-fastcgi
update-rc.d php-fastcgi defaults

warning.pngConcernant le nombre de process fils lancés , il faudra adapter selon la charge de votre site ... en production , la commande

netstat -atup

Vous donnera des indications sur l'état de vos process , n'en ajoutez pas trop ! travaillez de façon logique .

Vous pouvez démarrer les process :

/etc/init.d/php-fastcgi start

Liaison avec Nginx

Et bien voilà , il ne nous reste plus qu'à lui indiquer de transmettre les requêtes php aux process que nous avons lancés .

fastcgi_params

Dans un premier temps il faudra éditer le fichier de configuration fastcgi_params de nginx .

cd /etc/nginx/
vim fastcgi_params

A la fin de ce fichier , ajouter les lignes suivantes :

fastcgi_split_path_info ^(.+\.php)(.*)$;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

Ces lignes permettent entre autre d'indiquer aux process quel script executer , ainsi que son chemin .

Vhost ou Nginx.conf

Selon l'utilisation ou non de vhost , il vous faut ajouter ( en fait elles y sont déjà dans le conf principale si vous avez utilisé mon fichier de config nginx.conf ) les lignes suivantes dans les accolades de server .

location ~ \.php$ {

          include /etc/nginx/fastcgi_params; #or whatever you named it
          fastcgi_pass  127.0.0.1:9000;
	  index index.php;
        }


Exemple d'un vhost:

server{

        listen 8282;

        server_name lindev.fr;

        root /home/apache2/lindev.fr;

        
        location /  {

                index index.php;

        }

        location ~ \.php$ {

          include /etc/nginx/fastcgi_params; #or whatever you named it
          fastcgi_pass  127.0.0.1:9000;
	  index index.php;
        }

}

Et voilà votre serveur peut maintenant gérer les fichiers .php

Restart Nginx

Pour que les modifications prennent effet, il vous faut demander à Nginx de relire sont/ses fichiers de conf .

/usr/local/nginx/sbin -s reload

Et bien voilà pour php .. On fait la même chose avec perl ? aller .. go !

Perl CPAN

Certains sites demandent la gestion de perl , principalement pour des site de graph , tel qu'eluna , je vais donc faire en sorte que notre serveur puisse gérer ce genre de site .. même pas peur !

FCGI

Il nous faut dans un premier temps installer le paquet FCGI par cpan :

perl -MCPAN -e 'install FCGI'

Wrapper perl fastcgi

Il faut ensuite , créer le script qui ( comme pour php ) lance des process en fastcgi en attente de script à traiter .

vim /usr/bin/fastcgi-wrapper.pl

download.pngVoilà le contenu de ce script : fastcgi-wrapper.zip

Il faut maintenant le rendre exécutable

chmod 755 /usr/bin/fastcgi-wrapper.pl



Ok maintenant , nous allons créer le script qui se situe dans le RC , pour lancer les process :

vim /etc/init.d/perl-fastcgi

download.pngVoici le fichier perl-fastcgiperl-fastcgi

On le rend exécutable , et on l'ajoute au RC

chmod 755 /etc/init.d/perl-fastcgi
update-rc.d perl-fastcgi defaults
/etc/init.d/perl-fastcgi start

Liaison perl - Nginx

Nous y voilà , les process perl sont lancés , il écoutent sur le port 8999 , il ne nous reste plus qu'à ajouter dans les Vhost qui en ont besoin , les lignes suivantes :

location ~ \.pl$ {
        gzip off;
        include /etc/nginx/fastcgi_params;
        fastcgi_pass  127.0.0.1:8999;
        fastcgi_index index.pl;
    }

warning.pngCette fois , pas besoin de modifier les fichier fcgi_params car les modifications à apporter sont les même que précédemment avec php .

Nginx restart

Et bien oui comme pour php , on relance la lecture des fichiers de conf de nginx , afin de prendre en compte les modifications .

/usr/local/nginx/sbin/nginx -s reload

Good job

Ca y est , Nginx est maintenant capable de gérer les script php et perl en plus des fichiers statiques ...

Il reste encore quelques petites choses utiles à voir , comme la gestion du SSL , les redirections automatique , les réécritures d'url, pour du 301 ou l'utilisation de framework tel que symphony , Zend ou autre basé sur la réécriture d'url et un peut de sécurité en plus ...

Voilà le programme de la troisième partie sur nginx ..

- page 1 de 2