• 30 heures
  • Facile

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

Ce cours existe en livre papier.

course.header.alt.is_certifying

Vous pouvez être accompagné et mentoré par un professeur particulier par visioconférence sur ce cours.

J'ai tout compris !

Mis à jour le 04/09/2017

Déployer son site Symfony2 en production

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Votre site est fonctionnel ? Il marche parfaitement en local, et vous voulez que le monde entier en profite ? Vous êtes au bon endroit, on va voir dans ce chapitre les points à vérifier pour déployer votre site sur un serveur distant.

L'objectif de ce chapitre n'est pas de vous apprendre comment mettre en production un site de façon générale, mais juste de vous mettre le doigt sur les quelques points particuliers auxquels il faut faire attention lors d'un projet Symfony2.

La méthodologie est la suivante :

  1. Uploader votre code à jour sur le serveur de production ;

  2. Mettre à jour vos dépendances via Composer ;

  3. Mettre à jour votre base de données ;

  4. Vider le cache.

Mais avant de penser à envoyer son application en ligne, il faut s'assurer qu'elle soit parfaite déjà en local !

Préparer son application en local

Bien évidemment, la première chose à faire avant d'envoyer son application sur un serveur, c'est de bien vérifier que tout fonctionne chez soi ! Vous êtes habitués à travailler dans l'environnement de développement et c'est normal, mais pour bien préparer le passage en production, on va maintenant utiliser le mode production.

Vider le cache, tout le cache

Tout d'abord, pour être sûrs de tester ce qui est codé, il faut vider le cache. Faites donc un petit :

php app/console cache:clear

Voici qui vient de vider le cache… de l'environnement de développement ! Eh oui, n'oubliez donc jamais de bien vider le cache de production, via la commande :

php app/console cache:clear --env=prod

Tester l'environnement de production

Pour tester que tout fonctionne correctement en production, il faut utiliser le contrôleur frontalapp.phpcomme vous le savez, et nonapp_dev.php. Mais cet environnement n'est pas très pratique pour détecter et résoudre les erreurs, vu qu'il ne les affiche pas du tout. Pour cela, ouvrez le fichierweb/app.php, on va activer le mode debugger pour cet environnement. Il correspond au deuxième argument du constructeur du Kernel :

<?php
// web/app.php

// …

$kernel = new AppKernel('prod', true); // Définissez ce 2e argument à true

Dans cette configuration, vous êtes toujours dans l'environnement de production, avec tous les paramètres qui vont bien : rappelez-vous, certains fichiers commeconfig.ymlouconfig_dev.ymlsont chargés différemment selon l'environnement. L'activation du mode debugger ne change rien à cela, mais permet d'afficher à l'écran les erreurs.

Soigner ses pages d'erreur

En tant que développeurs, vous avez la chance de pouvoir utiliser l'environnement de développement et d'avoir de très jolies pages d'erreur, grâce à Symfony2. Mais mettez-vous à la place de vos visiteurs : créez volontairement une erreur sur l'une de vos pages (une fonction Twig mal orthographiée par exemple), et regardez le résultat depuis l'environnement de production (et sans le mode debugger bien sûr !), visible à la figure suivante.

Une page d'erreur pas très séduisante
Une page d'erreur pas très séduisante

Pas très joli, n'est-ce pas ? C'est pour cela qu'il faut impérativement que vous personnalisiez les pages d'erreur de l'environnement de production. Un chapitre entier est dédié à ce point important, je vous invite à lire « Personnaliser les pages d'erreur ».

Installer une console sur navigateur

En fonction de l'hébergement que vous avez, vous n'avez pas forcément l'accès SSH nécessaire pour exécuter les commandes Symfony2. Heureusement, les commandes Symfony2 sont de simples scripts PHP, il est alors tout à fait possible de les exécuter depuis un navigateur. Il existe des bundles qui émulent une console dans un navigateur, décrits dans un chapitre dédié : je vous invite à lire le chapitre « Utiliser la console directement depuis le navigateur ».

Vérifier la qualité de votre code

L'importance d'écrire un code de qualité n'est plus à démontrer. En utilisant Symfony2 plutôt que de tout coder vous-mêmes, j'imagine que vous êtes déjà sensible à cela.

Cependant, Symfony2 étant un framework très puissant, le code que vous faites  se doit d'être à la hauteur, et il n'est pas évident de le passer entièrement en revue pour s'en assurer. Heureusement, il existe un outil qui permet de vérifier automatiquement un grand nombre de points particuliers dans votre code. Il s'agit d'un outil en ligne,  SensioLabs Insight : insight.sensiolabs.com.

Je vous invite à aller voir, à l'adresse précédente, les points que cet outil vérifie. Ils sont tous intéressants à prendre en compte si vous voulez avoir une application Symfony2 de grande qualité. La figure suivante montre par exemple ce que donne l'analyse sur le code source de notre plateforme d'annonce créée dans ce cours.

Notre code source obtient la médaille de Bronze
Notre code source obtient la médaille de Bronze

Comme la figure le montre, il reste quelques points à corriger : 2 points majeurs, 10 mineurs et 12 recommandations. Il reste encore un peu de travail avant d'obtenir la médaille Platinium !

Vous pouvez utiliser gratuitement l'outil sur vos projets publics, c'est-à-dire que votre projet doit avoir un Git publiquement accessible. Si vous avez votre code sur Github, c'est parfait.

Vérifier la sécurité de vos dépendances

Un projet Symfony2 contient beaucoup de dépendances : cela se voit très bien en constatant le nombre de bibliothèques dans le répertoire vendor. Il est impossible de se tenir au courant des failles de sécurité découverte dans toutes ces dépendances... mais pourtant cela serait indispensable ! Vous n'imaginez pas envoyer en ligne votre application alors qu'une de vos dépendances contient une faille de sécurité.

Pour cela, il existe un outil également créé par SensioLabs : Security Checker (security.sensiolabs.org). Vous avez deux solutions pour vérifier vos dépendances.

La première est d'envoyer manuellement votre fichiercomposer.lock sur l'interface en ligne de l'outil. C'est lui qui contient les versions exactes des dépendances que vous utilisez, cela permet donc à l'outil de vérifier avec sa base de données internes des failles de sécurité.

Mes dépendances n'ont pas de faille connues
Mes dépendances n'ont pas de faille connues

La deuxième solution est d'utiliser l'outil fourni en ligne de commande. Il est déjà inclu dans la version standard de Symfony, vous l'avez donc déjà. Il s'agit de la commandesecurity:check, que vous pouvez exécuter comme n'importe quelle commande Symfony :

C:\wamp\www\Symfony>php app/console security:check
Security Check Report
~~~~~~~~~~~~~~~~~~~~~
Checked file: C:\wamp\www\Symfony\composer.lock

 [OK]
 0 packages have known vulnerabilities

 This checker can only detect vulnerabilities that are referenced
 Disclaimer in the SensioLabs security advisories database. Execute this
 command regularly to check the newly discovered vulnerabilities.

Si vous avez une dépendance avec une faille connue, renseignez-vous dessus sur Internet. La plupart du temps, la bibliothèque aura corrigé la faille dans une version plus récente : vous devez alors la mettre à jour dans votre projet.

Vérifier et préparer le serveur de production

Vérifier la compatibilité du serveur

Évidemment, pour déployer une application Symfony2 sur votre serveur, encore faut-il que celui-ci soit compatible avec les besoins de Symfony2 ! Pour vérifier cela, on peut distinguer deux cas.

Vous avez déjà un hébergeur

Ce cas est le plus simple, car vous avez accès au serveur. Symfony2 intègre un petit fichier PHP qui fait toutes les vérifications de compatibilité nécessaires, utilisons-le ! Il s'agit du fichierweb/config.php, mais avant de l'envoyer sur le serveur il nous faut le modifier un petit peu. En effet, ouvrez-le, vous pouvez voir qu'il y a une condition sur l'IP qui appelle le fichier :

<?php
// web/config.php

// …

if (!in_array(@$_SERVER['REMOTE_ADDR'], array(
  '127.0.0.1',
  '::1',
))) {
  header('HTTP/1.0 403 Forbidden');
  exit('This script is only accessible from localhost.');
}

Comme ce fichier n'est pas destiné à rester sur votre serveur, supprimez simplement ce bloc et envoyez le fichier sur votre serveur. Ouvrez la page web qui lui correspond, par exemplewww.votre-serveur.com/config.php. Vous devriez obtenir la figure suivante.

Le fichier de configuration s'affiche
Le fichier de configuration s'affiche

Comme vous le voyez, mon serveur est compatible avec Symfony2, car il n'y a pas de partie « Major Problems », juste des « Recommendations ». Bien évidemment, essayez de respecter les recommandations avec votre hébergeur/administrateur si cela est possible. Notamment, comme Symfony2 l'indique, installer un accélérateur PHP comme APC est très important, cela augmentera très sensiblement les performances. Si celles-ci n'étaient pas importantes en local, elles le seront en ligne !

Vous n'avez pas encore d'hébergeur et en cherchez un compatible.

Dans ce cas, vous ne pouvez pas exécuter le petit script de test inclus dans Symfony2. Ce n'est pas bien grave, vous allez le faire à la main ! Voici les points obligatoires qu'il faut que votre serveur respecte pour pouvoir faire tourner Symfony2 :

  • La version de PHP doit être supérieure ou égale à PHP 5.3.3 ;

  • L'extension SQLite 3 doit être activée ;

  • L'extension JSON doit être activée ;

  • L'extension Ctype doit être activée ;

  • Le paramètredate.timezonedoit être défini dans lephp.ini.

Il y a bien entendu d'autres points qu'il vaut mieux vérifier, bien qu'ils ne soient pas obligatoires. La liste complète est disponible dans la documentation officielle.

Modifier les paramètres OVH pour être compatible

Certains hébergeurs permettent la modification de certains paramètres via les.htaccessou l'interface d'administration. Il m'est bien sûr impossible de lister toutes les solutions pour chaque hébergement. C'est pourquoi ce paragraphe est uniquement à destination des personnes hébergées chez OVH, il y en a beaucoup et c'est un cas un peu particulier.

Vous savez sans doute que le PHP par défaut d'OVH est une branche de la version 4, or Symfony2 a besoin de la version 5.3.2 minimum. Pour cela, créez un fichier.htaccessà la racine de votre hébergement, dans le répertoirewww:

SetEnv SHORT_OPEN_TAGS 0
SetEnv REGISTER_GLOBALS 0
SetEnv MAGIC_QUOTES 0
SetEnv SESSION_AUTOSTART 0
SetEnv ZEND_OPTIMIZER 1
SetEnv PHP_VER 5_3

Ceci permettra notamment d'activer la version 5.3 de PHP, mais également de définir quelques autres valeurs utiles au bon fonctionnement de Symfony2.

Déployer votre application

Il y a deux cas pour déployer votre application sur votre serveur :

  1. Soit vous n'avez pas accès en SSH à votre serveur (la plupart des hébergements mutualisés, etc.) : dans ce cas vous devez envoyer vos fichiers à la main ;

  2. Soit vous avez accès en SSH à votre serveur (VPS, serveur dédiés, etc.) : dans ce cas il vous faut utiliser Capifony, un outil fait pour automatiser le déploiement.

Méthode 1 : Envoyer les fichiers sur le serveur par FTP

Dans un premier temps, il faut bien évidemment envoyer les fichiers sur le serveur. Pour éviter d'envoyer des fichiers inutiles et lourds, videz d'abord le cache de votre application : celui-ci est de l'ordre de 1 à 10 Mo. Attention, pour cette fois il faut le vider à la main, en supprimant tout son contenu, car la commandecache:clearne fait pas que supprimer le cache, elle le reconstruit en partie, il restera donc des fichiers qu'on ne veut pas. Ensuite, envoyez tous vos fichiers et dossiers à la racine de votre hébergement, danswww/sur OVH par exemple.

Que faire des vendors ?

Si vous avez accès à Composer sur votre serveur, c'est le mieux. N'envoyez pas vos vendors à la main, ils sont assez lourds, mais envoyez bien les deux fichierscomposer.jsonetcomposer.lock. Ensuite, sur votre serveur, exécutez la commandephp composer.phar install. Je parle bien de la commandeinstallet nonupdate, qui va installer les mêmes versions des dépendances que vous avez en local. Cela se fait grâce au fichiercomposer.lockqui contient tous les numéros des versions installées justement.

Si vous n'avez pas accès à Composer sur votre serveur, alors contentez-vous d'envoyer le dossiervendoren même temps que le reste de votre application.

Régler les droits sur les dossiersapp/cacheetapp/logs

Vous le savez, Symfony2 a besoin de pouvoir écrire dans deux répertoires :app/cachepour y mettre le cache de l'application et ainsi améliorer les performances, etapp/logspour y mettre l'historiques des informations et erreurs rencontrées lors de l'exécution des pages.

Normalement, votre client FTP devrait vous permettre de régler les droits sur les dossiers. Avec FileZilla par exemple, un clic droit sur les dossierscacheetlogsvous permet de définir les droits, comme à la figure suivante.

Modifiez les droits des dossiers
Modifiez les droits des dossiers

Assurez-vous d'accorder tous les droits (777) pour que Symfony2 puisse écrire à souhait dans ces dossiers.

Méthode 2 : Utiliser l'outil Capifony pour envoyer votre application

La méthode précédente est très sommaire. Cela permet juste de vous expliquer quels sont les points particuliers du déploiement d'un projet Symfony2. Mais si votre projet est assez grand, vous devez penser à utiliser des outils adaptés pour le déployer sur votre serveur. Je vous invite notamment à jeter un œil à Capifony : capifony.org, un outil Ruby qui permet d'automatiser pas mal de choses que nous venons de voir.

Je n'irai pas plus loin sur ce point, car c'est un outil à part entière qui mériterait un cours dédié. Cependant, sachez que c'est outil qui a été conçu pour justement déployer une application Symfony2. Il fait donc toutes les tâches nécessaires et ce de façon automatique : envoyer le code source, installer les dépendances avec Composer, vider le cache, etc. Cerise sur le gâteau : si l'une de vos mises en production échoue (vous vous rendez compte d'une erreur une fois en ligne), vous pouvez facilement revenir à la version antérieure !

Bref, à vous d'investiguer cet outil indispensable !

Les derniers préparatifs

Maintenant que votre application est sur votre serveur, il reste quelques points à ne pas oublier avant de donner l'adresse à tout le monde.

S'autoriser l'environnement de développement

Pour exécuter les commandes Symfony2, notamment celles pour créer la base de données, il nous faut avoir accès à l'environnement de développement. Or, essayez d'accéder à votreapp_dev.php… accès interdit ! En effet, si vous l'ouvrez, vous remarquez qu'il y a le même test sur l'IP qu'on avait rencontré dansconfig.php. Cette fois-ci, ne supprimez pas la condition, car vous aurez besoin d'accéder à l'environnement de développement dans le futur. Il faut donc que vous complétiez la condition avec votre adresse IP. Obtenez votre IP surwww.whatismyip.com, et rajoutez-la :

<?php
// web/app_dev.php

// …

if (!in_array(@$_SERVER['REMOTE_ADDR'], array(
  '127.0.0.1',
  '::1',
  '123.456.789.1'
))) {
  header('HTTP/1.0 403 Forbidden');
  exit('You are not allowed to access this file. Check '.basename(__FILE__).' for more information.');
}

Voilà, vous avez maintenant accès à l'environnement de développement et, surtout, à la console. ;)

Mettre en place la base de données

Il ne manque pas grand-chose avant que votre site ne soit opérationnel. Il faut notamment s'attaquer à la base de données. Pour cela, modifiez le fichierapp/config/parameters.ymlde votre serveur afin d'adapter les valeurs des paramètresdatabase_*.

Généralement sur un hébergement mutualisé vous n'avez pas le choix dans la base de données, et vous n'avez pas les droits pour en créer. Mais si ce n'est pas le cas, alors il faut créer la base de données que vous avez renseignée dans le fichierparameters.yml, en exécutant cette commande :

php app/console doctrine:database:create

Puis, dans tous les cas, remplissez la base de données avec les tables correspondant à vos entités :

php app/console doctrine:schema:update --force

S'assurer que tout fonctionne

Ça y est, votre site devrait être opérationnel dès maintenant ! Vérifiez que tout fonctionne bien dans l'environnement de production.

Avoir de belles URL

Si votre site fonctionne bien, vous devez sûrement avoir ce genre d'URL pour l'instant :www.votre-site.com/web/app.php. On est d'accord, on ne va pas rester avec ces horribles URL !

Pour cela, il faut utiliser l'URL Rewriting, une fonctionnalité du serveur web Apache (rien à voir avec Symfony2). L'objectif est que les requêtes/platform et/css/style.cssarrivent respectivement sur/web/platform et/web/css/style.css.

Méthode.htaccess

Pour faire cela avec un.htaccess, rajoutez donc ces lignes dans un.htaccessà la racine de votre serveur :

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^(.*)$ web/$1 [QSA,L]
</IfModule>

C'est tout ! En effet, c'est déjà bon pour les fichiers CSS, mais pour l'URL/platform il faut qu'au final elle arrive sur/web/app.php/platform. En fait il y a déjà un.htaccessdans le répertoire/web. Ouvrez-le, il contient ce qu'il faut. Pour résumer, l'URL/platform va être réécrite en/web/platform par notre.htaccessà la racine, puis être à nouveau réécrite en/web/app.php/platform par le.htaccessde Symfony2 situé dans le répertoire/web.

Méthode VirtualHost

Si vous avez accès à la configuration du serveur HTTP Apache sur votre serveur, cette solution est à préférer. Vous pouvez l'essayer sur votre serveur local, où vous avez évidemment tous les droits.

Pour cela il faut créer un VirtualHost, c'est-à-dire un domaine virtuel sur lequel Apache va créer un raccourci. Autrement dit, au lieu d'accéder àhttp://localhost/Symfony/web, vous allez accéder àhttp://symfony.local. On va dire à Apache que le domainesymfony.localdoit pointer directement vers le répertoireSymfony/webqui se trouve à la racine de votre serveur web.

Voici la configuration à rajouter dans le fichier de configuration d'Apache,httpd.conf:

# Sous wamp : C:\wamp\bin\apache\apache2.2.22\conf\httpd.conf

<VirtualHost *:80>
    ServerName symfony.local
    DocumentRoot "C:/wamp/www/Symfony"

    <Directory "C:/wamp/www/Symfony">
        DirectoryIndex app.php
        Options -Indexes
        AllowOverride All
        Allow from All
    </Directory>
</VirtualHost>

Et profitez !

Et voilà, votre site est pleinement opérationnel, profitez-en !

 

Les mises à jour de la base de données

Un dernier mot pour vous parler de la mise à jour de votre base de données. En effet, mettre à jour le code est très simple, ce sont des fichiers textes, on peut les mettre à jour facilement, revenir en arrière, etc. En ce qui concerne la base de données c'est un peu plus compliqué : il faut faire très attention aux données que vous avez déjà. Vous ne pouvez pas vous permettre de perdre des données lors d'une mise à jour !

C'est pour cela que la commande doctrine:schema:update est à bannir. Par contre, il existe une bibliothèque pour Doctrine appelée DoctrineMigration et bien sûr son bundle correspondant. Je ne détaillerai pas son utilisation ici, mais l'idée est la suivante :

  • Lorsque vous modifiez ou ajoutez une entité, vous créez en même temps un fichier de migration ;

  • Le fichier de migration reflète les changements que vous avez effectués : il contient les requêtes SQL (du SQL pur, pas du DQL !) permettant de mettre à jour la base de données pour coller à vos changements. Il contient les deux sens : pour mettre à jour (ajout d'une colonne par exemple), et pour annuler la mise à jour (suppression de la nouvelle colonne) ;

  • Lorsque vous envoyez vos fichiers sur votre serveur de production, vous exécutez alors tous les fichiers de migrations depuis la dernière mise en production : votre base de données sur le serveur est alors bien synchronisée avec votre code !

Les fichiers de migrations sont automatiquement exécutés par Capifony lors des mises en production, une raison de plus pour utiliser ces deux outils !

Une checklist pour vos déploiements

Vous n'êtes pas sûr d'avoir pensé à tout avant de lancer définitivement votre site en ligne ? Pour cela, j'ai créé un site (avec Symfony !) contenant une liste de points à vérifier impérativement avant de vous lancer, il s'agit de symfony2-checklist.com. Servez vous en pour être serein lors de vos mises en ligne !

Vous pensez qu'il manque un point ? Le contenu de la liste est hébergé sur Github, c'est-à-dire que tout le monde peut participer et ajouter les points qu'il pense important ! N'hésitez pas si vous avez des idées ;)

En résumé

  • Avant tout déploiement, préparez bien votre application en local.

  • N'oubliez pas de personnaliser les pages d'erreur, d'installer une console via navigateur si vous êtes en hébergement mutualisé, et de vider le cache.

  • Vérifiez la configuration de votre serveur, et adaptez-la si nécessaire.

  • Envoyez tous vos fichiers sur le serveur, et assurez-vous d'avoir de belles URL grâce aux.htaccessou à un VirtualHost.

  • C'est tout bon ! ;)

Exemple de certificat de réussite
Exemple de certificat de réussite