Chapitre: Installation sur un serveur de production
| « Installation d'une application | ^ Installation | Migration d'une application jelix 1.0 vers jelix 1.1 » |
− 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. Cette édition comprend les outils de scripts en ligne de commande et d'autres choses pour le développement.
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. Il est toutefois recommandé de supprimer les scripts en ligne de commande de Jelix.
Une édition "Gold" est disponible en téléchargement, pour les développeurs qui peuvent modifier la configuration de php, en particulier, installer des extensions PHP. En effet, cette édition repose sur certaines extensions PHP qui ne sont pas disponibles chez tous les hébergeurs, mais aussi sur une extension PHP spécialement dédiée à Jelix, qui prend en charge certains traitements du framework. L'utilisation de l'édition GOLD améliore ainsi sensiblement les performances de votre application.
Configuration ¶
L'installation se passe à l'identique que sur le serveur de développement, y compris pour l'application. Quand vous migrez les fichiers de votre application du serveur de développement vers le serveur de production, il ne faut pas copier les fichiers du répertoire temp.
Pour avoir de meilleures performances et plus de sécurité, voici toutefois quelques conseils supplémentaires.
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/;-)
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/defaultconfig.ini.php .
section error_handling ¶
Dans la section error_handling, la configuration suivante est vivement conseillée :
[error_handling]
messageLogFormat = "%date%\t[%code%]\t%msg%\t%file%\t%line%\n"
logFile = error.log
email = root@localhost
emailHeaders = "From: webmaster@yoursite.com\nX-Mailer: Jelix\nX-Priority: 1 (Highest)\n"
quietMessage="A technical error has occured. Sorry for this trouble."
showInFirebug = off
; mots clés que vous pouvez utiliser : ECHO, ECHOQUIET, EXIT, LOGFILE, SYSLOG, MAIL, TRACE
default = ECHOQUIET EXIT LOGFILE
error = ECHOQUIET EXIT LOGFILE
warning = ECHOQUIET LOGFILE
notice =
strict =
; pour les exceptions, il y a implicitement un EXIT
exception = ECHOQUIET LOGFILE
En clair, il est déconseillé d'utiliser le mot clé ECHO, qui affiche tous les détails des erreurs dans les pages web (informations qui pourraient être utiles pour des pirates), mais plutôt ECHOQUIET, qui affiche simplement le message indiqué dans le paramètre quietMessage.
Toutefois, il est utile d'être informé des erreurs et de leurs détails. Aussi, parallèlement à ECHOQUIET, il est recommandé d'ajouter l'un de ces mots clés
LOGFILE: les erreurs sont insérées dans le fichier indiqué dans logFileSYSLOG: les erreurs sont enregistrées au niveau du systèmeMAIL: les erreurs sont envoyées par Mail.
Attention à l'usage de EMAIL : ne l'utiliser qu'une fois que vous savez que votre application fonctionne bien sur le serveur de production. Sinon vous risquez d'être inondé de mails (voire même que votre hébergeur n'apprécie pas l'usage intensif du mail, pouvant vous prendre pour un spammeur).
Attention aussi à l'usage de SYSLOG : ne mettre cette option que s'il s'agit de votre serveur (c'est à dire que vous êtes administrateur de la machine). Sinon le propriétaire de la machine risque de ne pas apprécier.
En conclusion : LOGFILE est plutôt conseillé par rapport à EMAIL et à SYSLOG ;-)
Section compilation ¶
Dans la section [compilation], vous pouvez désactiver l'option checkCacheFiletime, et encore plus recommandé, l'option forces 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.
