Raccourcis : Contenu - rubriques - sous rubriques
EN FR

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

  1. Tous les répertoires autre que le www de votre application devraient être en dehors du "document root" du site web. Voir le chapitre sur la configuration d'un serveur pour des exemples.
  2. 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épertoire temp/ ;-)
  3. 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