Mise en production

Les environnements Symfony

Dans le .env, on a une variable qui détermine l’environnement dans lequel on se trouve : APP_ENV=DEV. Il existe aussi PROD et TEST.

Le code est le même mais les configurations diffèrent entre environnements de travail. On voit dans le index.php quel Kernel est instancié.

Par exemple, les erreurs entre PROD et DEV s’affichent différement (en PROD on enlève les informations utiles aux développeurs mais sensibles).

Souvent on a une base de données par environnement : on garde la même structure mais on recrée la base de données en PROD (souvent celle que fournit l’hébergeur).

Le cache aussi diffère, en DEV il recharge à chaque refresh alors qu’en PROD il garde le cache (gain de rapidité).

Les paquets disponibles peuvent aussi différer, notamment la barre de déboguage qui n’est pas accessible en PROD.

Grossièrement, pour passer en PROD, on prend le code source, on le met dans le serveur OVH, on remplace la valeur de APP_ENV=PROD.

On personnalise les pages d’erreur

On est donc en PROD sur le projet, on lance le serveur, on check la page d’erreur (on va sur une url qui existe pas) et c’est moche.

Si on crée le bon twig qu’on met au bon endroit, alors c’est lui qui sera affiché : templates/bundles/TwigBundle/Exception (que l’on crée à la main).

On peut faire une page générale pour toutes les erreurs : error.html.twig

On peut ajouter des fichiers selon les erreurs : error404.html.twig

{% extends base.html.twig %}

{% block body %}
	<p> Erreur 404 - La page demandée n'a pas été trouvée.
{% endblock %}

On doit parler de SQL

En environnement de DEV, on faisait des symfony console doctrine:schema:update --force, sauf qu’il n’est pas possible de revenir en arrière.

C’est fini tout ça en PROD. On fait des migrations : symfony console make:migration.

Le déploiement

Etapes listées sur Symfony :

1. on transfère le code source sur le serveur web

2. on le passe en PROD, on gère les variables d’environnement

3. on installe les dépendances avec composer

4. on vide le cache

Il faut faire du SSH pour se connecter au serveur OVH.

Dans un terminal, on se connecte au serveur avec login@adresse : ssh ovh@10.22.200.32 > le mot de passe : ovh.

OVH c’est linux, on doit copier le projet en choisissant une méthode :

1. FTP (non) / SFTP (mouais) / SCP (pour copier d’un ordi à un autre via le protocole SSH) (rare)

2. git (le + utilisé) : git clone URL et on récupère le projet

3. Docker, { Jenkins, Travis CI } (forge logicielle d’intégration continue : à chaque commit, il compacte dans un docker qu’il met dans OVH et démarre et plein d’autres trucs…), GitHub, GitLab

Se connecter à la base de données :

• dev : onglet Database à droite

• prod : pareil mais on met le serveur OVH (10.22.200.32) en host (l’hébergeur nous donne les identifiants)

  dans le .env, on met la DATABSE_URL avec le 127.0.0.1 (car quand on le mettra sur le serveur, ce sera aussi le local) et les bons identifiants

Cloner le repository git :

• c’est l’hébergeur qui démarre le service : /etc/init.d/apache2 restart

• pour que l’application soit en PROD, on la met dans /var/www/html (souvent on a accès qu’à ce répertoire) parce que c’est le dossier root

• on clone le projet : git clone https://github.com/LSarribouette/hello-symfony

  (je vérifie avec ls que j’ai bien la liste des documents)

Passer le projet en PROD :

• on utilise vi pour changer la valeur de APP_ENV

Installer les dépendances : /usr/local/bin/composer install

Si on va sur l’adresse IP du serveur, on voit la page par défaut. Si on rajoute ‘/nom-du-projet’, on accède bien au projet.

En vrac

• Utilisation d’un VPS (serveur privé virtuel) : accessible dans la salle, en public avec l’adresse iPv4. C’est comme un ordinateur dans le nuage d’internet (on peut faire ce qu’on veut : installer des trucs, mettre des fichiers, créer un site web… On peut acheter un nom de domaine qui mène à cette iPv4…).

• Choix d’hébergement : selon le nombre de sites (un domaine peut avoir plein de sous-domaines)

  BP : o2switch (avec nom de domaine offert)

• git workflow : ce qui se passe dans la vraie vie

  Les développeurs commitent ; le lead développeur se connecte en SSH sur le serveur web, il pull la branche main (taguée) —> en vérité, on automatise ce processus avec de l’intégration continue.

  on touche quasi jamais à la branche main (sauf lead dev)

  on a une branche dev

  chaque développeur a sa branche à lui et merge dans dev

  on a autant de merge sur la branche main que de tags (version V.0.2….)

  Exemple d’intégration continue avec GitHub Action : un symfony.yaml qui lance des jobs qui crée des dockers, fait un github checkout, installe des machins,…. —> principe = on dit qu’est ce qu’on lance et quand.

  Le changement de base de données aussi est géré par l’intégration continue.

  Le reste à voir en Symfony

  Symfony : mais encore ? • Webpack Encore • Symfony UX • Fixtures • Commandes de console • Traduction • EventDispatcher • BrowserKit • Tests • API REST, APIPlatform • Cache • Logs • Workflow • Voters • Les bundles de la communauté • Et encore plein d'autres merveilles