Préparez votre site pour la mise en production
Ça y est : votre site fonctionne en local ! 😎
Mais comment faire pour le déployer sur un serveur distant ? Ce chapitre abordera l'ensemble des points points à vérifier avant le déploiement.
Vous n'apprendrez pas à mettre en ligne un site en production de façon globale mais je mettrai en avant des points particuliers auxquels il faut faire attention lorsque l'on travaille sur un projet Symfony.
Procédons étape par étape.
Préparez votre application en local
Avant d'envoyer une application sur un serveur, il est primordial de s'assurer qu'elle tourne correctement en local. Pour bien préparer le mise en production, il va falloir passer de l'environnement de développement au mode production.
Videz TOUT votre cache
La première étape est de vider le cache. Cela permettra d'être sûr de tester ce que vous avez codé.
Pour cela, utilisez cette commande :
php bin/console cache:clear
Le cache de votre environnement de développement est désormais complètement vide.
La deuxième étape est de vider le cache de production grâce à cette commande :
php bin/console cache:clear --env=prod
Faire des tests dans un environnement de production
Mettez-vous dans la peau de vos utilisateurs en parcourant votre application en environnement de production. Pensez à désactiver le mode de débogage pour être en condition réelle. Pour cela, rendez-vous dans le fichier .env à la racine de votre projet et changez la valeur de APP_ENV à "prod" et de APP_DEBUG à 0 :
# .env
###> symfony/framework-bundle ###
APP_ENV=prod
APP_DEBUG=0
###< symfony/framework-bundle ###
...Soignez vos pages d'erreur
En tant que développeur, vous travaillez dans un environnement de développement et avez droit à de belles pages d'erreur grâce à Symfony. Cependant, vos utilisateurs ne verront pas la même chose en cas d'erreur. Pour vous en rendre compte, créez une erreur sur l'une de vos pages (une fonction Twig mal orthographiée, par exemple). Regardez ensuite le résultat depuis l'environnement de production (avec le mode débogage désactivé). Cela donnera ceci :
Pas très engageant, n'est-ce pas ? Vous devrez donc personnaliser les pages d'erreur de l'environnement de production.
Vérifiez la sécurité de vos dépendances
Il y a beaucoup de dépendances dans un projet Symfony. Vous pouvez le constater avec les nombreuses bibliothèques présentes dans le répertoire vendor. Il est donc pratiquement impossible d'être au courant de toutes les failles de sécurité découvertes dans ces dépendances. Et pourtant, c'est indispensable. En effet, vous ne voulez pas mettre en ligne votre application alors que certaines de vos dépendances contiennent des failles de sécurité n'est-ce pas ?
Pour gérer cela, un outil a été créé par SensioLabs : Security Checker (security.symfony.com). Il existe deux méthodes pour vérifier les dépendances.
La première est d'envoyer manuellement le fichier composer.lock de votre projet sur l'interface en ligne de l'outil. Ce fichier contient les versions des dépendances que vous utilisez. L'outil pourra ainsi vérifier si elles contiennent des failles de sécurité grâce à sa base de données interne.
La seconde méthode consiste à utiliser le même outil mais en utilisant l'invite de commande.
➜ bin/console security:check Symfony Security Check Report ============================= // Checked file: /var/www/html/composer.lock [OK] No packages have known vulnerabilities. ! [NOTE] This checker can only detect vulnerabilities that are referenced in ! the SensioLabs security advisories database. Execute this command ! regularly to check the newly discovered vulnerabilities.
Si votre projet contient une dépendance avec une faille déjà répertoriée, renseignez-vous sur internet. La plupart du temps, la bibliothèque aura corrigé la faille dans une version plus récente : vous n'aurez qu'à mettre la dépendance à jour.
Vérifiez et préparez le serveur de production
Vérifiez que votre serveur est compatible
Pour déployer une application Symfony sur votre serveur, il faut que celui-ci soit compatible avec Symfony.
Pour pouvoir vérifier la compatibilité, nous pouvons distinguer deux cas.
Vous avez déjà un hébergeur
C'est le cas le plus simple car vous avez déjà accès au serveur.
Pour vérifier s'il est compatible avec Symfony, nous allons commencer par installer une extension du projet Symfony dont c'est le rôle : "Requirements Checker".
Cette extension s'installe avec Composer, à l'aide de la commande suivante :
composer require symfony/requirements-checker
Cette extension va ajouter un fichier appelé "check.php" dans le dossier "public" de votre application.
Mais attention, avant de l'envoyer sur le serveur, il va falloir le modifier légèrement. En effet, il contient une restriction sur l'IP qu'il va falloir retirer :
<?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, il faut supprimer ce bloc de code et envoyer le fichier sur votre serveur. En accédant à la page correspondante, par exemple www.votre-serveur.com/check.php , vous devriez obtenir la figure suivante :
Essayez de suivre les recommandations proposées. Même si elles ne sont pas obligatoires pour faire fonctionner votre application, elles auront toujours un impact positif.
Vous n'avez pas encore d'hébergeur.
Dans cette situation, il n'est pas possible d'exécuter le script de test présent dans Symfony. Vous allez devoir effectuer des modifications à la main ! Voici les points que votre serveur va devoir respecter pour que Symfony puisse fonctionner :
la version de PHP doit être supérieure ou égale à PHP 7.2.5 ;
l'extension SQLite 3 doit être activée ;
l'extension JSON doit être activée ;
le paramètre
date.timezonedoit être défini dans la configuration PHP.
Ensuite, pensez à vérifier la compatibilité de votre serveur avec Requirements Checker comme nous l'avons vu précédemment.
Une fois la vérification faite, désinstallez l'extension avec Composer :
composer remove symfony/requirements-checker
Déployez votre application
Il existe deux cas distincts pour déployer votre application sur votre serveur :
soit vous avez accès à votre serveur en SSH (VPS, serveurs dédiés, etc.) ;
soit vous souhaitez déployer votre application dans le Cloud, ce que nous apprendrons à faire dans la suite de ce chapitre.
Pour déployer correctement votre application, 4 étapes sont nécessaires :
uploader (télécharger) le code de votre projet sur votre serveur ;
installer les dépendances (vous pouvez le faire avant le déploiement, à l'aide de Composer) ;
appliquer les migrations de base de données en production, s'il y en a ;
supprimer le cache.
Il existe de nombreux outils open source pour vous aider à déployer vos projets Symfony, comme Deployer ou encore Capistrano.
Déployez Symfony dans le Cloud !
Aujourd'hui, les entreprises ont tendance à ne plus gérer le déploiement et l'infrastructure de leurs applications elles-mêmes. En effet, elles passent de plus en plus par des plateformes capables de gérer cela pour elles. On parle souvent de Plateformes As A Service (PaaS), qui déploient des applications web dans le Cloud
Utilisez le Cloud
Mais pourquoi passer par une PaaS comme Platform.sh, Heroku ou Amazon Web Services plutôt que d'acheter un serveur chez OVH par exemple ? Eh bien la différence est ce que vous achetez. Chez OVH, vous allez acheter un serveur, c'est-à-dire une machine qui se trouve dans un data center qui appartient à OVH. Vous pourrez dans certains cas avoir le droit d'accéder physiquement à la machine.
Avec une PaaS, vous achetez de la puissance de calcul et des services (accès à une base de données, à un système de cache). Dans ce cas, votre site web peut changer de serveur physique mais vous n'avez pas à vous en préoccuper car la plateforme le fait pour vous.
Utiliser une PaaS présente de nombreux avantages :
Ces entreprises sont des spécialistes de l'infrastructure. À moins que vous soyez une très grosse entreprise, vous n'aurez probablement pas la compétence en interne pour gérer des serveurs et tout l'applicatif qui y est lié.
Si une grosse charge arrive sur votre serveur (suite à une publicité télévisée par exemple), vous n'aurez aucun problème ! Ces plateformes sont capables de faire évoluer vos services automatiquement pour supporter l'afflux de nouveaux visiteurs.
En tant que développeur, vous n'aurez plus à vous préoccuper des problèmes de déploiement, des versions de PHP, d'Apache, de GNU/Linux. Vous pourrez vous concentrer sur votre cœur de métier et sur ce qui pourra apporter de la valeur business à vos clients.
Le "Cloud", est donc le fait de déployer son site sur un serveur qui ne nous appartient pas et dont on ne sait rien. Ce serveur peut changer, voire évoluer. Une plateforme en tant que service va vous permettre de déployer votre projet à travers une plateforme qui s'occupera de ce serveur. Une plateforme offre également un accès à d'autres services, comme une base de données, un nom de domaine, un certificat pour le HTTPS, un système de cache, un serveur mail... c'est-à-dire tout ce qui pourrait être nécessaire pour votre application.
Pour bien comprendre comment tout cela fonctionne, nous allons déployer notre application sur Platform.sh.
Création d'un compte Platform.sh et configuration
Pour commencer, créez-vous un compte sur Plateform.sh. Vous aurez accès à une période d'essai gratuite d'un mois pour vous familiariser avec les différent services que Platform.sh propose. Cliquez sur "Free Trial" ("Essai gratuit") pour y accéder.
Dans ce plan d'essau gratuit, vous aurez :
3 environnements de développement ;
5 Gb d'espace disque sur chaque environnement ;
1 licence d'utilisation (vous serez le seul à pouvoir accéder à vos environnements) ;
l'accès à tous les services (MySQL, Redis, Solr, etc.) ;
l'accès au support client ;
la possibilité de faire évoluer l'essai gratuit, les services, les environnements.
Avant toute chose, vous devrez choisir la zone géographique dans laquelle vous souhaitez héberger vos applications. Ce choix est important pour la réactivité des serveurs. Ensuite, la plateforme vous redirigera vers l'interface de création des projets.
Tout d'abord, vous devrez choisir le nom de votre projet. Pour ma part, j'ai choisi "Apprendre Symfony sur OpenClassrooms" :
Deux choix s'offriront à vous pour la création de votre projet :
partir d'une configuration générée automatiquement ;
partir d'un code existant.
Dans notre cas, nous choisirons la première option puisque nous n'avons pas de projet disponible.
Vous devrez ensuite choisir la plateforme que vous souhaitez utiliser parmi Drupal, Symfony, Easy Platform, Typo3 ou WordPress ! Choisissez "Symfony" puis "Symfony 5". Cliquez ensuite sur "Finish"
Votre projet s'ouvre et est actif !
La prochaine étape est d'accéder au code du projet via GIT. Pour cela, nous allons devoir configurer sa clé SSH pour être authentifié correctement par Platform.sh quand nous utilisons Git.
Une fois la clé configurée, nous allons récupérer le projet en local. Pour cela, cliquez sur le bouton "Git" (en haut de la page) et copiez-collez l'instruction dans votre invite de commande.
Voici l'instruction utilisée dans mon cas :
➜ Projects git clone --branch master wbe6iqdgihnqu@git.eu-2.platform.sh:wbe6iqdgihnqu.git apprendre-symfony-sur-openclassrooms Clonage dans 'apprendre-symfony-sur-openclassrooms'... Warning: Permanently added the RSA host key for IP address '52.210.208.94' to the list of known hosts. remote: counting objects: 31, done. Réception d'objets: 100% (31/31), 11.73 KiB | 3.91 MiB/s, fait. Résolution des deltas: 100% (2/2), fait.
Une fois le dépôt cloné, ouvrez votre projet avec n'importe quel éditeur de code.
➜ apprendre-symfony-sur-openclassrooms git:(master) tree -aL 2 . ├── bin │ └── console ├── composer.json ├── composer.lock ├── config │ ├── bundles.php │ ├── packages │ ├── routes.yaml │ └── services.yaml ├── .env.dist ├── .platform │ ├── routes.yaml │ └── services.yaml ├── .platform.app.yaml ├── public │ └── index.php ├── README.md ├── src │ ├── Controller │ └── Kernel.php └── symfony.lock
Dans la suite de ce chapitre, nous allons entrer dans les détail du dossier .platform et du fichier .platform.app.yaml .
Configuration de Platform.sh
La configuration de Platform.sh se fait en deux partie :
d'abord avec un fichier .platform.app.yaml ;
puis avec un dossier .platform
Dans le fichier .platform.app.yaml, vous trouverez toutes les informations requises pour que platform.sh puisse créer un environnement valide pour votre application.
Voici à quoi ressemble la configuration pour un projet Symfony fourni par Platform.sh :
# Le nom de l'application
name: app
# Le type d'application à construire
type: php:7.2
build:
flavor: composer
variables:
env:
# Configuration des variables d'environnement pour Symfony
APP_ENV: 'prod'
APP_DEBUG: 0
# Actions à exécuter à la construction et au déploiement
hooks:
build: |
set -e
bin/console assets:install --no-debug
bin/console cache:clear
deploy: |
set -e
bin/console assets:install --symlink --relative public
bin/console cache:clear
# Les services utilisés
relationships:
database: "mysqldb:mysql"
# L'espace disque configurés
disk: 2048
# Les dossiers qui doivent rester accessibles en écriture
mounts:
"/var/cache": "shared:files/cache"
"/var/log": "shared:files/log"
"/var/sessions": "shared:files/sessions"
# La configuration web
web:
locations:
"/":
# Dossier public
root: "public"
# Le contrôleur frontal (qui doit recevoir toutes les requêtes)
passthru: "/index.php"
Vous trouverez les éléments suivants dans la plupart des services cloud :
La déclaration de l'environnement à créer : dans notre cas, nous avons demandé à avoir un environnement avec PHP 7.2 et Composer installés.
Les variables d'environnement : Nous n'avons pas accès au serveur. Pour configurer notre application au déploiement, la seule solution est d'utiliser des variables d'environnement. Dans notre cas, l'application doit démarrer dans un environnement de production.
Les étapes du cycle de vie de la plateforme : "build" et "deploy" dans lesquelles certaines actions et variables d'environnement sont disponibles.
Les services : dans notre cas, il s'agit d'une base de données. Nous n'avons pas eu à la configurer.
La configuration "HTTP" : cette section permet de définir le dossier public de l'application et du contrôleur frontal. Habituellement, on doit configurer Apache ou Nginx sur un serveur. La plateforme doit connaître ces éléments pour pouvoir le faire.
Pour pouvoir fonctionner correctement, Platform.sh a besoin de deux autres fichiers.
Le fichier routes.yaml définit comment la plateforme doit réagir lorsque un utilisateur atterrit sur l’URL d'un site :
# .platform/routes.yaml
# Si un utilisateur arrive sur le site en HTTPS, appelez l'application "app"
"https://{default}/":
type: upstream
upstream: "app:http"
# Si l'utilisateur arrive sur l'application en www, le rediriger vers https://{default}/
"https://www.{default}/":
type: redirect
to: "https://{default}/"Le fichier services.yaml, lui, permet de déclarer et de configurer les services dont nous allons avoir besoin pour notre application.
# .platform/services.yaml
mysqldb:
type: mysql:10.2 # MariaDB 10.2
disk: 2048Mais comment notre application Symfony est-elle capable de se connecter à la base de données fournie par Platform.sh ? En effet, notre base de données va changer d'IP et de serveur. Alors comment cela fonctionne-t-il ?
Eh bien la réponse est dans le fichier composer.json de l'application :
{
"name": "symfony/skeleton",
"type": "project",
"license": "MIT",
"description": "A minimal Symfony project recommended to create bare bones applications",
"require": {
"php": "^7.2.5",
"ext-ctype": "*",
"ext-iconv": "*",
"platformsh/symfonyflex-bridge": "^2.7",
"symfony/console": "*",
"symfony/flex": "^1.1",
"symfony/framework-bundle": "*",
"symfony/yaml": "*"
},
"require-dev": {
"symfony/dotenv": "*"
}
}
C'est le bridge de Platform.sh qui va configurer automatiquement la base de données dans Symfony.
Il faudra absolument l'installer si vous voulez déployer une application déjà existante.
Création d'une action simple
En l'état actuel, notre application n'a aucun contrôleur ! Elle ne fonctionne donc pas.
Reprenons le code du contrôleur "Hello World" réalisé précédemment :
<?php
// src/Controller/HelloController.php
namespace App\Controller;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\Routing\Annotation\Route;
use Symfony\Component\HttpFoundation\Response;
class HelloController extends AbstractController
{
/**
* @Route("/{name}", name="hello")
*/
public function hello($name = 'World')
{
return new Response("Hello $name");
}
}Dans l'application Symfony de démonstration de Platform.sh, les annotations ne sont pas activées. Il faut donc installer les dépendances adéquates grâce à Composer :
➜ composer require annotations
Cette commande va activer l'utilisation de l'annotation @Route. Il faut ensuite "commiter" et déployer nos modifications sur le projet mis a disposition par Platform.sh :
➜ git commit -am "Ajout d'un contrôleur"
Mise en ligne
Mais comment faire pour déployer nos modifications sur Platform.sh ? Eh bien il suffit de publier nos changements Git sur le serveur :
➜ git push origin master
Décompte des objets: 11, fait.
Delta compression using up to 12 threads.
Compression des objets: 100% (10/10), fait.
Écriture des objets: 100% (11/11), 3.93 KiB | 3.93 MiB/s, fait.
Total 11 (delta 5), reused 0 (delta 0)
Validating submodules
Validating configuration files
Processing activity: Mickaël Andrieu pushed to Master
Found 1 new commit
Building application 'app' (runtime type: php:7.2, tree: fc33c53)
Generating runtime configuration.
Moving the application to the output directory
Prewarming composer cache.
Pre-downloaded 10 packages referenced in `composer.lock`
Found a `composer.json`, installing dependencies.
W: Loading composer repositories with package information
W: Installing dependencies (including require-dev) from lock file
W: Package operations: 31 installs, 0 updates, 0 removals
W: - Installing symfony/flex (v1.1.1): Loading from cache
W: - Installing doctrine/inflector (v1.3.0): Loading from cache
W: - Installing doctrine/lexer (v1.0.1): Loading from cache
W: - Installing doctrine/annotations (v1.6.0): Loading from cache
W: - Installing doctrine/reflection (v1.0.0): Loading from cache
W: - Installing doctrine/event-manager (v1.0.0): Loading from cache
W: - Installing doctrine/collections (v1.5.0): Loading from cache
W: - Installing doctrine/cache (v1.8.0): Loading from cache
W: - Installing doctrine/persistence (v1.0.1): Loading from cache
W: - Installing platformsh/symfonyflex-bridge (1.3.0): Loading from cache
W: - Installing psr/cache (1.0.1): Loading from cache
W: - Installing psr/container (1.0.0): Loading from cache
W: - Installing psr/simple-cache (1.0.1): Loading from cache
W: - Installing symfony/polyfill-mbstring (v1.9.0): Loading from cache
W: - Installing symfony/http-foundation (v5.2.4): Loading from cache
W: - Installing symfony/event-dispatcher (v5.2.4): Loading from cache
W: - Installing psr/log (1.0.2): Loading from cache
W: - Installing symfony/debug (v5.2.4): Loading from cache
W: - Installing symfony/http-kernel (v5.2.4): Loading from cache
W: - Installing symfony/routing (v5.2.4): Loading from cache
W: - Installing symfony/finder (v5.2.4): Loading from cache
W: - Installing symfony/filesystem (v5.2.4): Loading from cache
W: - Installing symfony/dependency-injection (v5.2.4): Loading from cache
W: - Installing symfony/config (v5.2.4): Loading from cache
W: - Installing symfony/cache (v5.2.4): Loading from cache
W: - Installing symfony/framework-bundle (v5.6.1): Loading from cache
W: - Installing doctrine/common (v2.9.0): Loading from cache
W: - Installing sensio/framework-extra-bundle (v5.2.2): Loading from cache
W: - Installing symfony/console (v5.2.4): Loading from cache
W: - Installing symfony/yaml (v5.2.4): Loading from cache
W: - Installing symfony/dotenv (v5.2.4): Loading from cache
W: Generating optimized autoload files
Executing build hook...
Installing assets as hard copies.
[OK] No assets were provided by any bundle.
// Clearing the cache for the prod environment with debug
// false
[OK] Cache for the "prod" environment (debug=false) was successfully cleared.
Executing pre-flight checks...
Compressing application.
Beaming package to its final destination.
Provisioning certificates
Environment certificates
- certificate 0798f9d: expiring on 2019-02-02 13:32:58+00:00, covering {,www}.master-7rqtwti-wbe6iqdgihnqu.eu-2.platformsh.site
Re-deploying environment wbe6iqdgihnqu-master-7rqtwti
Environment configuration
app (type: php:7.2, size: S, disk: 2048)
mysqldb (type: mysql:10.2, size: S, disk: 2048)
Environment routes
http://master-7rqtwti-wbe6iqdgihnqu.eu-2.platformsh.site/ redirects to https://master-7rqtwti-wbe6iqdgihnqu.eu-2.platformsh.site/
http://www.master-7rqtwti-wbe6iqdgihnqu.eu-2.platformsh.site/ redirects to https://www.master-7rqtwti-wbe6iqdgihnqu.eu-2.platformsh.site/
https://master-7rqtwti-wbe6iqdgihnqu.eu-2.platformsh.site/ is served by application `app`
https://www.master-7rqtwti-wbe6iqdgihnqu.eu-2.platformsh.site/ redirects to https://master-7rqtwti-wbe6iqdgihnqu.eu-2.platformsh.site/
To git.eu-2.platform.sh:wbe6iqdgihnqu.git
6c23fcc..3651681 master -> masterLe message "Hello World" devrait s'afficher dans votre navigateur en accédant à la route fournie par Platform.sh (dans mon cas : https://master-7rqtwti-wbe6iqdgihnqu.eu-2.platformsh.site/).
En résumé
Le déploiement d'une application Symfony passe par plusieurs étapes :
les vérifications en local ;
la personnalisation des pages d'erreur utilisateur ;
la vérification de la configuration du serveur ;
etc.
Le Cloud et en particulier les plateformes (PaaS), comme Platform.sh ou Heroku permettent de ne plus se préoccuper du serveur. Tout ce qui relève des opérations serveur sera géré par la plateforme, à partir du moment où la configuration du projet a été faite et les différents services activés (base de données, système de cache, etc.)
Dans ce cours, nous nous sommes concentrés sur Platform.sh car cette plateforme est performante et adaptée aux projets Symfony. Cependant, l'ensemble des PaaS fonctionnement de la même façon.
Pour vous entraîner, je vous conseille d'essayer de déployer votre application à l'aide d'Heroku ou de Microsoft Azure
Ce cours touche à sa fin et vous avez maintenant toutes les clés en main pour :
Expliquer les éléments fondamentaux du framework Symfony
Rédiger un code propre et facilement utilisable par d'autres développeurs
Développer un programme Symfony fonctionnel
Utiliser Doctrine ORM pour la gestion de bases de données
Utiliser le moteur de template Twig pour la gestion des vues
N'oubliez pas de vous exercer pour valider ces compétences en complétant l'activité à la fin de cette partie !
Bienvenue dans la communauté des développeurs Symfony ! Happy Coding. ;)
