Chapitre: Configurer un serveur de production
| ^ Déployer une application jelix | Installation d'une application » |
− Table des matières
On appelle serveur de production, le serveur sur lequel sera installé votre application une fois terminée, donc accessible aux utilisateurs finaux. Par opposition, il y a le serveur de développement, celui sur lequel vous développez votre application.
Il y a certaines choses différentes à prendre compte dans le cas du serveur de production, afin d'optimiser l'exécution de votre application basée sur Jelix.
Choisir la bonne édition de Jelix ¶
Pour développer, vous utilisez bien sûr l'édition "developer" de Jelix. Le code source de cette édition contient des instructions aidant au déboggage, pour la debugbar par exemple.
Cependant, pour l'installation sur un serveur de production, il est préférable d'installer l'édition "optimized" de Jelix. Comme son nom l'indique, elle est optimisée, et débarrassée des choses inutiles en production. Notez toutefois que votre application fonctionnera à l'identique avec l'une ou l'autre des éditions de Jelix, à un détail près : on pourra observer de légères améliorations de performance avec l'édition "Optimized" ;-).
Si vous choisissez de rester avec l'édition "developer" sur le serveur de production, cela ne posera aucun problème.
Configuration ¶
Au niveau du serveur ¶
- Tous les répertoires autre que le
wwwde votre application devraient être en dehors du "document root" du site web. Voir le chapitre sur la configuration d'un serveur pour des exemples. - Bien spécifier les droits sur le répertoire
temp/, en particulier, que le propriétaire soit l'utilisateur qui exécute apache (ou celui de votre compte, chez certains hébergeurs) et qu'il ait les droits en écriture. Par exemple, sur linux, il n'est pas recommandé de mettre les droits 0777 sur le répertoiretemp/;-) - Idem pour les répertoires
var/log/,var/mails/etc de votre application
Au niveau de l'application ¶
Voici quelques conseils au niveau de la configuration de l'application, donc les
modifications à faire au niveau du fichier
var/config/localconfig.ini.php .
section jResponseHtml ¶
Désactivez le plugin debugbar.
configuration du logger ¶
Si vous gardez l'édition "dev" en production, mettez en commentaire la ligne
sql=... et peut être aussi soap=.. et autre type de log qui ne vous
semble pas pertinent. Et supprimez "memory" pour chaque type de log, cela
économisera de la mémoire (n'est utile que pour la debugbar).
Section compilation ¶
Dans la section [compilation], vous pouvez désactiver l'option checkCacheFiletime, et encore plus recommandé, l'option force si vous l'avez activé pour le développement.
[compilation]
checkCacheFiletime = off
force = off
L'option checkCacheFiletime évite à Jelix de vérifier tout le temps que le
cache (les fichiers générés par Jelix pour les fichiers de configurations, les
DAO, templates etc) est bien à jour par rapport aux fichiers de l'application. À
priori, cette vérification est inutile en production, puisque l'application est
rarement modifiée. Bien sûr, si vous la désactivez, il faudra impérativement
vider le répertoire de cache (temp/votre_appli/)
à chaque mise à jour de votre application ,
pour que vos modifications soient bien prises en compte !
(surtout quand il s'agit de modifications dans la configuration, des daos,
locales, templates..)
Section mailer ¶
N'oubliez pas de mettre à jour les paramètres de la section [mailer]. En effet, les paramètres pour envoyer des mails ne sont pas toujours identiques entre le serveur de développement et le serveur de production.
Si votre serveur web est derrière un reverse proxy ¶
Il arrive que sur des infrastructures conséquentes, le serveur web qui execute Jelix se trouve derrière un reverse proxy (un load-balancer, Nginx, haproxxy etc..). Et ainsi le serveur web n'est pas configuré comme un serveur frontal : il n'a pas le nom de domaine du site, il n'écoute pas forcément sur les même port etc.. Du coup Jelix n'a pas forcément toutes les infos qui permettent de générer les urls correctement entre autres (car pour le moment il ne prend pas en charge les entêtes 'Forwarded' ou 'X-Forwarded-Proto' que peuvent communiquer les reverses proxy aux serveurs web).
Si le serveur web n'écoute pas sur les ports standards (80 ou 443), il va falloir indiquer de forcer les ports aux valeurs standards (sur lesquels écoute le reverse proxy), quand Jelix gènère des urls. Cela se passe dans la section générale :
forceHTTPPort = true
forceHTTPSPort = true
Il faut aussi indiquer le vrai nom de domaine du site (celui donc du reverse proxy), sinon jelix prend le nom de domaine du serveur derrière le proxy
domainName = www.example.com
Si le "basePath" du serveur derrière le proxy n'est pas le même que le basePath public (ex: le proxy redirige les urls http://example.com/index.php vers http://backend.example.com/foo/bar/index.php), il faut indiquer le basePath public et le basePath "backend" :
[urlengine]
basePath = /
backendBasePath = /foo/bar
Et si le proxy transforme les requêtes HTTPS en HTTP vers votre serveur web, il faut désactiver la vérification HTTPS de jelix :
[urlengine]
checkHttpsOnParsing = off
Depuis Jelix 1.6.16, vous pouvez aussi indiquer de forcer les URLS générées en HTTPS car Jelix ne sait pas détecter le protocol utilisé par les requêtes arrivant sur le reverse proxy.
[urlengine]
forceProxyProtocol = https
