Symfony 4: Variables de entorno

En el libro Las Buenas Prácticas Oficiales de Symfony se explica con detalle cómo gestionar la configuración de las aplicaciones Symfony. Por ejemplo, cómo usar app/config/parameters.yml para las opciones de configuración relacionadas con la infraestructura (por ejemplo, tu base de datos) y cómo usar app/config/config.yml para las opciones de configuración relacionadas con la aplicación.

Nuestra primera recomendación es que no utilices opciones de configuración de las que se guardan en app/config/config.yml a menos que sea imprescindible. De hecho, en nuestra opinión, se pueden contar con los dedos de una mano los casos en los que es necesario definir una opción de ese tipo.

Por otra parte, en Symfony 4 también desaparece el archivo app/config/parameters.yml. En su lugar se utilizan variables de entorno, tal y como hacen la mayoría de frameworks en otros lenguajes de programación. Además, esta es una de las recomendaciones recogidas en el 12-Factor Application Manifesto que siguen la mayoría de plataformas de hosting modernas.

Aunque las variables de entorno no son perfectas, tienen varias ventajas respecto a usar el archivo parameters.yml. Para empezar, las variables de entorno son el mecanismo estandar en la industria para gestionar la configuración que depende del entorno de ejecución (son mucho más cómodas por ejemplo que tener que lidiar con el archivo parameters.yml.dist).

Además, las variables de entorno se pueden leer desde distintas herramientas, ya que son independientes del código, del framework y del lenguaje de programación. Las variables de entorno también son útiles en los sistemas de archivos de solo lectura, ya que están desacopladas de tu código y su valor se puede cambiar dinámicamente sin tener que desplegar de nuevo la aplicación (y sin tener que borrar la caché de la aplicación Symfony).

Su única pega es que, a diferencia de lo que algunos programadores creen, las variables de entorno son igual de inseguras que los archivos de configuración a la hora de guardar valores secretos como contraseñas y tokens de APIs.

Utilizar variables de entorno mientras se desarrolla la aplicación es un poco pesado, así que vamos a recomendar el uso de un archivo estándar llamado .env. Symfony 3.3 incluye un nuevo componente llamado Dotenv que se utilizará por defecto en las aplicaciones Symfony 4. Así que el cambio entre un archivo .env y las variables de entorno “de verdad” será automática y transparente para ti.

Si lo prefieres, puedes seguir definiendo las variables de entorno en un archivo llamado parameters.yaml, aunque esta ya no será la forma estándar de trabajar. Por cierto, el nombre parameters.yaml no es un error al escribir parameters.yml. De hecho, este será otro cambio de Symfony 4 que discutiremos más adelante.

Una ventaja añadida de usar variables de entorno es que simplifica la forma en la que se gestiona el entorno de ejecución (dev, prod, etc.) y el valor de la opción debug tanto en la consola como en los controladores frontales.

Actualmente, se pueden definir el entorno y el debug que utiliza ./bin/console tanto con las opciones --env y --no-debug como con las variables de entorno SYMFONY_ENV y SYMFONY_DEBUG. En Symfony 4 esto ya no es necesario, ya que se utilizarán las variables de entorno APP_ENV y APP_DEBUG tanto en la consola como en los controladores frontales.

Así que ta te puedes ir olvidando de ./bin/console foo:bar --env=prod --no-debug o SYMFONY_ENV=prod SYMFONY_DEBUG=0 ./bin/console foo:bar. Simplemente utiliza ./bin/console foo:bar y todo funcionará como esperas. Tanto en desarrollo como en producción. Por cierto, Symfony 4 está lleno de simplificaciones de este tipo.

 

Fuente: https://symfony.es/noticias/2017/04/07/symfony-4-buenas-practicas/

Sobre Ruben 12 Artículos
Graduado en la UCI, amante de las tecnológicas y de la programación.

Dejar una contestacion

Tu dirección de correo electrónico no será publicada.


*