Raccourcis : Contenu - rubriques - sous rubriques
EN FR
Guide du développeur
Jelix 1.8.1

Chapitre: Configurer un serveur de production

^ Déployer une application jelix Installation d'une application »
Changer de langue : EN

− 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.

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 système (ou celui de votre compte, chez certains hébergeurs) qui exécute apache ou php-fpm et qu'il ait les droits en écriture et personne d'autres. 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 si il est activé dans la configuration principale.

configuration du logger

À moins que vous ne vouliez avoir toute la liste des requêtes SQL et SOAP, mettez en commentaire la ligne sql=... et soap=... Idem pour les autres types de log qui ne vous semblent pas pertinent. Supprimez également "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. Vous devriez aussi activer l'option sourceFileResolutionInCache.


[compilation]
sourceFileResolutionInCache = on
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.

L'option sourceFileResolutionInCache évite de rechercher à chaque requête ou se trouve le fichier source à compiler. En effet, pour certains types de fichiers, comme les templates, ils peuvent se trouver dans plusieurs répertoires différents, et la recherche dans tous ces répertoires peut être lente.

Bien sûr, en configurant ces options comme indiqué, 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 donc 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, il reçoit les requêtes en HTTP alors que le frontal reçoit les requêtes en HTTPS 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, il faut indiquer le basePath "public" et le basePath "backend". Par exemple, le proxy redirige les urls http://example.com/index.php vers http://backend.example.com/foo/bar/index.php, vous indiquerez alors :


[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
^ Déployer une application jelix Installation d'une application »
Changer de langue : EN
Ce manuel est distribué selon les termes de la licence Creative Commons by-nc-sa 3.0. Vous pouvez donc reproduire, modifier, distribuer et communiquer ce manuel au public en respectant les conditions suivantes : Paternité, Pas d'Utilisation Commerciale, Partage des Conditions Initiales à l'Identique.