• 15 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 11/05/2020

Déploiement

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

Une application se développe et se teste en local mais arrive un moment où il faut la mettre sur un serveur pour qu'elle devienne visible et accessible. Ce déploiement n'est pas forcément une tâche aisée selon le contexte. Dans ce chapitre nous allons faire un petit tour d'horizon de ce qu'il convient de faire sans pouvoir être exhaustif étant donné la multiplicité des configurations existantes.

L'environnement

Créer des environnements

La version 5 de Laravel a un peu révolutionné les habitudes pour l'environnement par rapport à la version 4. Elle fait usage maintenant d'un package tiers : DotEnv. On y a gagné en clarté mais pas forcément en ergonomie. Voyons comment cela se présente. Quand vous installez Laravel avec Composer vous trouvez à la racine le fichier .env avec ce contenu :

APP_ENV=local
APP_DEBUG=true
APP_KEY=oJiCzJoPu9FvTjmTz1jpsNHVSBL7i1nl
APP_URL=http://localhost

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_DATABASE=homestead
DB_USERNAME=homestead
DB_PASSWORD=secret

CACHE_DRIVER=file
SESSION_DRIVER=file
QUEUE_DRIVER=sync

REDIS_HOST=127.0.0.1
REDIS_PASSWORD=null
REDIS_PORT=6379

MAIL_DRIVER=smtp
MAIL_HOST=mailtrap.io
MAIL_PORT=2525
MAIL_USERNAME=null
MAIL_PASSWORD=null
MAIL_ENCRYPTION=null

Ça se présente sous la forme clé/valeur. Par exemple on a déjà vu cela en oeuvre dans config/app.php :

<?php
'debug' => env('APP_DEBUG', false),

L'helper env permet d'aller lire la valeur de APP_DEBUG dans le fichier .env et d'affecter la valeur de la clé debug de la configuration de l'application.

On trouve aussi par exemple le réglage de MySql :

<?php
'host'      => env('DB_HOST', 'localhost'),
'database'  => env('DB_DATABASE', 'forge'),
'username'  => env('DB_USERNAME', 'forge'),
'password'  => env('DB_PASSWORD', ''),

Remarquez que l'helper accepte une valeur par défaut comme deuxième paramètre. Que fait cet helper ? Tout simplement il stocke les valeurs dans la super globale d'environnement $_ENV du serveur.

Moralité : pour avoir plusieurs environnements il faut créer plusieurs fichiers .env. Le cas le plus classique sera d'avoir un environnement local de développement et un autre de déploiement. Il faut juste ne pas se mélanger les pinceaux, en particulier ne pas enlever le fichier .gitignore de la racine qui prévoit de ne pas envoyer le fichier .env qui peut contenir des données sensibles (si vous utilisez git).

La variable APP_ENV dans le fichier .env est justement destinée à connaître l'environnement actuel :

APP_ENV=local

Lorsque je crée une application je fais une copie du fichier d'environnement pour régler mes variables en situation production. Pour ne pas qu'il y ait de confusion je le nomme de façon explicite :

Le fichier d'environnement
Le fichier d'environnement "production"

Dans ce fichier je fixe toutes les valeurs nécessaires :

APP_ENV=production
APP_DEBUG=false
APP_KEY=5avz0M3IGPu4GFxBBLPhQs00MNJREzoL
...

Il me suffit ensuite d'envoyer ce fichier là sur le serveur et de le renommer.

Le déploiement

Nous allons envisager plusieurs situations pour le déploiement selon votre hébergement.

Les besoins de Laravel

Laravel n'a pas besoin de grand chose mais quand même :

  • PHP >= 5.5.9

  • Extension PHP PDO

  • Extension PHP OpenSSL

  • Extension PHP Mbstring

  • Extension PHP Tokenizer

D'autres part le dossier storage doit avoir les droits d'écriture sur le serveur.

La solution royale

Commençons par la situation idéale : vous disposez de SSH et vous avez un dossier disponible avec possibilité d'avoir des dossiers non accessibles. 

Si vous disposez de git sur le serveur vous pouvez évidement l'utiliser et vous n'aurez aucun souci.

Si vous avez Composer installé globalement sur le serveur c'est aussi parfait. Vous pouvez alors installer l'installeur de Laravel :

composer global require "laravel/installer"

Il ne vous reste plus alors qu'à utiliser cet installeur :

laravel new application

Mais il est probable que vous de disposiez pas de Composer installé. Dans ce cas vous commencez par envoyer l'archive phar  de composer. Vous accédez à votre dossier avec SSH :

login as: mon_login
login@login.org's password:*****

Ensuite vous lancez la creation avec composer :

php composer create-project --prefer-dist laravel/laravel

Vous attendez quelques minutes que toutes les dépendances s'installent. 

Ca devrait fonctionner mais avec un Laravel anonyme qui n'est pas encore une application :

Laravel installé

Il va falloir ensuite envoyer le dossier app, le composer.json, le fichier .env, créer une base de données... tout ce qui spécifie une application.

La solution intermédiaire

Supposons maintenant que vous disposez de SSH mais que vous êtes obligé de mettre votre application complètement accessible. Dans ce cas vous devez supprimer le dossier public et effectuer quelques manipulations pour que ça fonctionne. Voici la procédure :

Commencez par installer normalement Laravel. Vous devez avoir cette architecture :

L'architecture de Laravel

On va commencer par transférer tout ce qui se trouve dans le dossier public à la racine et supprimer ce dossier. Vous devez avoir maintenant cette situation :

Le dossier public a été supprimé et son contenu transféré

Evidemment maintenant plus rien ne fonctionne !

Ouvrez le fichier index.php et trouvez cette ligne :

<?php
require __DIR__.'/../bootstrap/autoload.php';

Remplacez-la par celle-ci :

<?php
require __DIR__.'/bootstrap/autoload.php';

Dans le même fichier trouvez cette ligne :

<?php
$app = require_once __DIR__.'/../bootstrap/app.php';

Remplacez-la par celle-ci :

<?php
$app = require_once __DIR__.'/bootstrap/app.php';

Ces modifications sont nécessaires à cause du déplacement de ce fichier et de la modification de son emplacement relatif.

Maintenant la page d'accueil de Laravel va s'afficher correctement.

Le souci c'est que maintenant tout devient accessible et il faut prendre des précautions, par exemple en prévoyant dans les dossiers que vous voulez inaccessibles (app, bootstrap...) un .htaccess avec :

Deny from all

Les seuls fichiers accessibles restent ceux qui sont présents à la racine.

La solution laborieuse

Si vous ne disposez pas de SSH l'affaire devient plus laborieuse parce que la seule solution qui vous reste est le FTP. Comme il y a beaucoup de fichiers l'affaire peux être longue selon la vitesse de votre transmission.

D'autre part les mises à jour doivent être soigneusement gérées parce qu'elles vont aussi forcément passer par le FTP.

Le mode maintenance

Quand vous mettez à jour votre application il peut y avoir des moments où il vaut mieux que personne ne se connecte. Laravel propose un mode maintenance facile à mettre en oeuvre avec Artisan :

php artisan down

Et bien sûr il y a la commande inverse :

php artisan up

Évidemment encore faut-il que vous ayez accès à Artisan sur votre serveur...

En résumé

  • Il faut créer des environnements pour répondre aux différentes situations : local, distant...

  • Le déploiement est facile et rapide si on dispose de git ou du SSH.

  • On peut supprimer le dossier public tout en ayant un Laravel fonctionnel, il faut juste prendre des mesures pour assurer la sécurité.

  • Il est possible de déployer une application avec le FTP mais c'est un peu laborieux et les mises à jour doivent être soigneusement gérées.

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