Comment maîtriser et créer de nouveaux environnements

Table des matières

Référence
Introduction
Environnements différents, différents fichiers de configuration
L'exécution d'une application dans différents environnements
Mode de débogage
Création d'un nouvel environnement
Environnements et le répertoire du cache

Référence

Introduction

Chaque application est la combinaison de code et un ensemble de configuration qui dicte la façon dont ce code devrait fonctionner. La configuration peut définir la base de données utilisée, si oui ou non quelque chose doit être mis en cache, ou comment la journalisation détaillée devrait être. En Symfony2, l'idée de «environnements» est l'idée que le même code source peut être exécuté à l'aide de multiples configurations différentes. Par exemple, l'environnement de dev devrait utiliser la configuration qui rend le développement facile et conviviale, alors que l'environnement prod doit utiliser un ensemble de configuration optimisée pour la vitesse.

Environnements différents, différents fichiers de configuration

Un typique Symfony2 application commence avec trois environnements: dev, prod, et le test. Comme nous l'avons, chaque «environnement» représente tout simplement une façon d'exécuter le même code source avec la configuration différente. Il ne faut pas s'étonner alors que chaque environnement charge son propre fichier de configuration individuelle. Si vous utilisez le format de configuration YAML, les fichiers suivants sont utilisés:

Cela fonctionne par l'intermédiaire d'une norme simple qui est utilisé par défaut dans la classe AppKernel:

// app/AppKernel.php
// ...

class AppKernel extends Kernel
{
    // ...

    public function registerContainerConfiguration(LoaderInterface $loader)
    {
        $loader->load(__DIR__.'/config/config_'.$this->getEnvironment().'.yml');
    }
}

Comme vous pouvez le voir, quand Symfony2 est chargé, il utilise l'environnement donné afin de déterminer quel fichier de configuration pour charger. Ceci accomplit le but de plusieurs environnements de façon élégante, puissante et transparente.

Bien sûr, en réalité, chaque environnement ne diffère que peu des autres. En règle générale, tous les environnements se partageront une grande base de la configuration commune. Ouverture du fichier de configuration "dev", vous pouvez voir comment cela se fait facilement et de manière transparente:

Version Yaml

imports:
    - { resource: config.yml }

# ...

Version Xml

<imports>
    <import resource="config.xml" />
</imports>

<!-- ... -->

Version Php

$loader->import('config.php');

// ...

Pour partager la configuration commune, les importations de chaque fichier de configuration de l'environnement tout simplement à partir d'un premier fichier de configuration central (config.yml). Le reste du fichier peut alors s'écarter de la configuration par défaut en remplaçant les paramètres individuels. Par exemple, par défaut, la barre d'outils web_profiler est désactivé. Toutefois, dans l'environnement de dev, la barre d'outils est activé en modifiant la valeur par défaut dans le fichier de configuration dev:

Version Yaml

# app/config/config_dev.yml
imports:
    - { resource: config.yml }

web_profiler:
    toolbar: true
    # ...

Version Xml

<!-- app/config/config_dev.xml -->
<imports>
    <import resource="config.xml" />
</imports>

<webprofiler:config
    toolbar="true"
    # ...
/>

Version Php

// app/config/config_dev.php
$loader->import('config.php');

$container->loadFromExtension('web_profiler', array(
    'toolbar' => true,
    // ..
));

L'exécution d'une application dans différents environnements

Pour exécuter l'application dans chaque environnement, de charger l'application en utilisant soit la app.php (pour l'environnement de prod) ou le app_dev.php (pour l'environnement de dev) contrôleur frontal:

Les URL donnée supposent que votre serveur web est configuré pour utiliser le répertoire web/ de l'application en tant que racine. Lire la suite dans Installation et configuration de Symfony.

Si vous ouvrez un de ces fichiers, vous verrez rapidement que l'environnement utilisé par chacun d'eux est explicitement définie:

1   <?php
2
3    require_once __DIR__.'/../app/bootstrap_cache.php';
4    require_once __DIR__.'/../app/AppCache.php';
5
6    use Symfony\Component\HttpFoundation\Request;
7
8    $kernel = new AppCache(new AppKernel('prod', false));
9    $kernel->handle(Request::createFromGlobals())->send();

Comme vous pouvez le voir, la clé de produits précise que cet environnement se déroulera dans l'environnement de prod. Une application Symfony2 peut être exécuté dans un environnement en utilisant ce code et en changeant la chaîne d'environnement.

L'environnement de test est utilisé lors de l'écriture des tests fonctionnels et n'est pas accessible dans le navigateur directement via un contrôleur frontal. En d'autres termes, contrairement aux autres environnements, il n'ya pas de fichier avant app_test.php contrôleur.

Mode de débogage

Important, mais rien à voir avec le sujet des environnements est la fausse clef sur la ligne 8 du contrôleur avant au-dessus. Ceci spécifie si oui ou non l'application doit s'exécuter en mode "debug". Indépendamment de l'environnement, une application Symfony2 peut être exécuté avec le mode de débogage a la valeur true ou false. Cela affecte beaucoup de choses dans l'application, comme si oui ou non les erreurs doivent être affichées ou si les fichiers du cache sont dynamiquement reconstruit à chaque demande. Bien que n'étant pas une exigence, le mode debug est généralement la valeur true pour le dev et des environnements de test et de faux pour l'environnement de prod.

Interne, la valeur du mode de débogage devient le paramètre kernel.debug utilisé à l'intérieur du Service Container . Si vous regardez dans le fichier de configuration d'application, vous verrez le paramètre utilisé, par exemple, pour activer la journalisation ou lorsque vous utilisez l'DBAL Doctrine:

Version Yaml

doctrine:
   dbal:
       logging:  %kernel.debug%
       # ...

Version Xml

<doctrine:dbal logging="%kernel.debug%" ... />

Version Php

$container->loadFromExtension('doctrine', array(
    'dbal' => array(
        'logging'  => '%kernel.debug%',
        // ...
    ),
    // ...
));

Création d'un nouvel environnement

Par défaut, une application Symfony2 a trois environnements qui gèrent la plupart des cas. Bien sûr, depuis un environnement n'est rien de plus qu'une chaîne de caractères qui correspond à un ensemble de configuration, la création d'un nouvel environnement est assez facile.

Supposons, par exemple, que, avant le déploiement, vous devez comparer votre demande. Une façon de comparer l'application est d'utiliser à court de production réglages, mais avec web_profiler Symfony2 a permis. Cela permet Symfony2 à enregistrer des informations sur votre application tout en benchmarking.

La meilleure façon d'y parvenir est par l'intermédiaire d'un nouvel environnement appelé, par exemple, de référence. Commencez par créer un nouveau fichier de configuration:

Version Yaml

# app/config/config_benchmark.yml

imports:
    - { resource: config_prod.yml }

framework:
    profiler: { only_exceptions: false }

Version Xml

<!-- app/config/config_benchmark.xml -->

<imports>
    <import resource="config_prod.xml" />
</imports>

<framework:config>
    <framework:profiler only-exceptions="false" />
</framework:config>

Version Php

// app/config/config_benchmark.php

$loader->import('config_prod.php')

$container->loadFromExtension('framework', array(
    'profiler' => array('only-exceptions' => false),
));

Et avec cette simple addition, l'application prend désormais en charge un nouvel environnement appelé indice de référence.

Ce nouveau fichier de configuration importe la configuration de l'environnement de prod et le modifie. Cela garantit que le nouvel environnement est identique à l'environnement de prod, sauf pour les modifications faites ici explicitement.

Parce que vous voudrez de cet environnement pour être accessible via un navigateur, vous devez également créer un contrôleur frontal pour elle. Copiez le fichier web/app.php à web/app_benchmark.php et modifier l'environnement pour être référence

<?php

require_once __DIR__.'/../app/bootstrap.php';
require_once __DIR__.'/../app/AppKernel.php';

use Symfony\Component\HttpFoundation\Request;

$kernel = new AppKernel('benchmark', false);
$kernel->handle(Request::createFromGlobals())->send();

Le nouvel environnement est désormais accessible via:

http://localhost/app_benchmark.php

Certains environnements, comme l'environnement de dev, ne sont jamais destinées à être consulté sur n'importe quel serveur déployé par le grand public. C'est parce que certains milieux, à des fins de débogage, peut donner trop d'informations sur l'application ou de l'infrastructure sous-jacente. Pour être sûr que ces environnements ne sont pas accessibles, le contrôleur frontal est généralement protégé contre les adresses IP externes via le code suivant en haut du contrôleur:

if (!in_array(@$_SERVER['REMOTE_ADDR'], array('127.0.0.1', '::1'))) {
    die('You are not allowed to access this file. Check '.basename(__FILE__).' for more information.');
}

Environnements et le répertoire du cache

Symfony2 tire profit de la mise en cache de plusieurs façons: la configuration de l'application, configuration de routage, Twig modèles et plus sont mis en cache des objets stockés dans des fichiers PHP sur le système de fichiers.

Par défaut, ces fichiers mis en cache sont en grande partie stocké dans le répertoire app/cache. Toutefois, chaque environnement met en cache son propre ensemble de fichiers:

Parfois, lors du débogage, il peut être utile d'inspecter un fichier mis en cache pour comprendre comment quelque chose fonctionne. Ce faisant, n'oubliez pas de regarder dans le répertoire de l'environnement que vous utilisez (le plus souvent dev tout développement et le débogage). Alors il peut varier, le répertoire app/cache/dev comprend les éléments suivants: