Entornos Symfony
Keep on Learning!
If you liked what you've learned so far, dive in! Subscribe to get access to this tutorial plus video, code and script downloads.
With a Subscription, click any sentence in the script to jump to that part of the video!
Login SubscribeA veces, nos vendría muy bien un conjunto de configuraciones que nos ayuden a desarrollar en diferentes escenarios. Por suerte, Symfony tiene justo lo que necesitamos: entornos.
En el archivo .env (situado en la raíz del directorio de nuestro proyecto), tenemos algunas variables de entorno.
| // ... lines 1 - 17 | |
| APP_ENV=dev | |
| APP_SECRET=930f26d714e6fa9188943d7e037a63fa |
Son conjuntos de configuraciones para nuestra aplicación que podemos cambiar en función del escenario -o entorno- en el que estemos desarrollando. Symfony lee este archivo para ver qué variables estamos utilizando y crea ese entorno.
Por el momento, sólo tenemos unas pocas variables de entorno aquí, como esta variable APP_ENV establecida en dev. Esto le dice a Symfony que nuestra aplicación debe cargarse en modo desarrollo. Después de desplegar nuestra aplicación en producción, querremos cambiar esto a prod, que está optimizado para el rendimiento y evita la fuga de datos sensibles. ¿Dónde se utiliza exactamente?
Abre /public/index.php. Este es nuestro controlador frontal, que se ejecuta en cada petición y arranca nuestra aplicación.
| // ... lines 1 - 2 | |
| use App\Kernel; | |
| require_once dirname(__DIR__).'/vendor/autoload_runtime.php'; | |
| return function (array $context) { | |
| return new Kernel($context['APP_ENV'], (bool) $context['APP_DEBUG']); | |
| }; |
Crea una instancia de App\Kernel, y ésta tiene algunos métodos. Mantén pulsado "comando" y haz clic en Kernel() para abrirlo. Esta clase está bastante vacía, aparte de esta línea use MicroKernelTrait;, y de ese trait procede la mayor parte del código.
| // ... lines 1 - 4 | |
| use Symfony\Bundle\FrameworkBundle\Kernel\MicroKernelTrait; | |
| use Symfony\Component\HttpKernel\Kernel as BaseKernel; | |
| class Kernel extends BaseKernel | |
| { | |
| use MicroKernelTrait; | |
| } |
Si abrimos esto... ¡ah! ¡Ya está! Contiene un montón de métodos como, por ejemplo, configureContainer(), que importa nuestros archivos de configuración. Dentro de él, abajo, tenemos $this->environment que, si escarbas un poco, es el valor de nuestra variable APP_ENV. Así que si queremos añadir una configuración específica del entorno, podemos poner esto en config/packages/, seguido de tu entorno, como dev o prod, y luego el nombre del archivo de configuración - framework.yaml por ejemplo.
Eso funcionará, pero recientemente, Symfony ha introducido una forma mucho más genial de hacer esto, utilizando la sintaxis when@. Puedes ver esto en toda la nueva configuración. Si abrimos framework.yaml por ejemplo, aquí abajo al final... ¡aquí está - when@test! Este código sólo se cargará para el entorno test.
| // ... lines 1 - 18 | |
| when@test: | |
| framework: | |
| test: true | |
| session: | |
| storage_factory_id: session.storage.factory.mock_file |
En nuestro archivo monolog.yaml, vemos más de esta configuración específica del entorno bajo when@dev. Esto le dice a Symfony que sólo cargue esta configuración en el entorno dev. Si nos desplazamos hacia abajo, podemos ver también configuraciones ligeramente diferentes para los entornos test y prod.
| // ... lines 1 - 4 | |
| when@dev: | |
| monolog: | |
| handlers: | |
| main: | |
| type: stream | |
| path: "%kernel.logs_dir%/%kernel.environment%.log" | |
| level: debug | |
| channels: ["!event"] | |
| // ... lines 13 - 62 |
Si volvemos a MicroKernelTrait, aquí abajo, podemos ver lo mismo para este método configureRoutes(). Y en config/routes/framework.yaml, vemos when@dev, lo que significa que sólo estamos importando este conjunto de rutas para el entorno dev. En web_profiler.yaml, tenemos lo mismo. Así que Symfony, por defecto, tiene tres entornos (o "modos") que podemos utilizar en nuestra app: dev prod y test. También puedes crear tu propio entorno personalizado si es necesario, pero normalmente, esos tres son más que suficientes para hacer el trabajo.
Bien, abramos un archivo con el que ya estamos familiarizados: config/bundles.php.
| // ... lines 1 - 2 | |
| return [ | |
| // ... lines 4 - 6 | |
| Symfony\Bundle\WebProfilerBundle\WebProfilerBundle::class => ['dev' => true, 'test' => true], | |
| Symfony\Bundle\MonologBundle\MonologBundle::class => ['all' => true], | |
| Symfony\Bundle\DebugBundle\DebugBundle::class => ['dev' => true], | |
| // ... lines 10 - 12 | |
| Symfony\Bundle\MakerBundle\MakerBundle::class => ['dev' => true], | |
| // ... line 14 | |
| ]; |
Tiene una matriz de bundles habilitados en nuestra aplicación, donde la clave es la clase de bundle y el valor es una matriz de entornos disponibles para ese bundle. Por ejemplo, este WebProfilerBundle sólo está disponible para los entornos devy test. Mientras tanto, DebugBundle y MakerBundle sólo están disponibles para el entorno dev. Son súper útiles mientras desarrollamos, pero definitivamente no queremos utilizarlos en producción y arriesgarnos a filtrar información sensible.
A continuación: Cambiemos e intentemos cargar nuestra aplicación utilizando el entorno prod.
