Cuando se desarrolla una aplicación, es habitual disponer de varias configuraciones distintas pero relacionadas. Por ejemplo durante el desarrollo se tiene un archivo de configuración con los datos de conexión a la base de datos de pruebas, mientras que en el servidor de producción los datos de conexión necesarios son los de la base de datos de producción. Symfony permite definir diferentes entornos de ejecución para poder manejar de forma sencilla las diferentes configuraciones.
5.3.1. ¿Qué es un entorno?
Las aplicaciones de Symfony se pueden ejecutar en diferentes entornos. Todos los entornos comparten el mismo código PHP (salvo el código del controlador frontal) pero pueden tener configuraciones completamente diferentes. Cuando se crea una aplicación, Symfony crea por defecto 3 entornos: producción (prod), pruebas (test) y desarrollo (dev). También es posible añadir cualquier nuevo entorno que se considere necesario.
En cierta forma, un entorno y una configuración son sinónimos. Por ejemplo el entorno de pruebas registra las alertas y los errores en el archivo de log, mientras que el entorno de producción solamente registra los errores. En el entorno de desarrollo se suele desactivar la cache, pero está activa en los entornos de pruebas y de producción. Los entornos de pruebas y desarrollo normalmente trabajan con una base de datos que contiene datos de prueba, mientras que el servidor de producción trabaja con la base de datos buena. En este caso, la configuración de la base de datos varía en los diferentes entornos. Todos los entornos pueden ejecutarse en una misma máquina, aunque en los servidores de producción normalmente solo se instala el entorno de producción.
El entorno de desarrollo tiene activadas las opciones de log y de depuración de aplicaciones, ya que es más importante el mantenimiento de la aplicación que su rendimiento. Sin embargo, en el entorno de producción se ajustan las opciones de configuración para obtener el máximo rendimiento, por lo que muchas características están desactivadas por defecto. Una buena regla general suele ser la de utilizar el entorno de desarrollo hasta que consideres que la funcionalidad de la aplicación en la que estás trabajando se encuentra terminada y después pasarse al entorno de producción para comprobar su rendimiento.
El entorno de pruebas varía respecto del de desarrollo y el de producción. La única forma de interactuar con este entorno es mediante la línea de comandos para realizar pruebas funcionales y ejecutar scripts. De esta forma, el entorno de pruebas es parecido al de producción, pero no se accede a través de un navegador. De todas formas, simula el uso de cookies y otros componentes específicos de HTTP.
Para ejecutar la aplicación en otro entorno, solamente es necesario cambiar de controlador frontal. Hasta ahora, en todos los ejemplos se accedía al entorno de desarrollo, ya que las URL utilizadas llamaban al controlador frontal de desarrollo:
http://localhost/frontend_dev.php/mimodulo/index
Sin embargo, si se quiere acceder a la aplicación en el entorno de producción, es necesario modificar la URL para llamar al controlador frontal de producción:
http://localhost/index.php/mimodulo/index
Si el servidor web tiene habilitado el mod_rewrite, es posible utilizar las reglas de reescritura de URL de Symfony, que se encuentran en web/.htaccess. Estas reglas definen que el controlador frontal de producción es el script que se ejecuta por defecto en las peticiones, por lo que se pueden utilizar URL como la siguiente:
http://localhost/mimodulo/index
5.3.2. Configuration en cascada
Una misma opción de configuración puede estar definida más de una vez en archivos diferentes. De esta forma es posible por ejemplo definir que el tipo MIME de las páginas de la aplicación sea text/html, pero que las páginas creadas con el módulo que se encarga del RSS tengan un tipo MIME igual a text/xml. Symfony permite establecer el primer valor en frontend/config/view.yml y el segundo en frontend/modules/rss/config/view.yml. El sistema de configuración se encarga de que una opción establecida a nivel de módulo tenga más prioridad que la opción definida a nivel de aplicación.
De hecho, Symfony define varios niveles de configuración:
- Niveles de granularidad:
- Configuración por defecto establecida por el framework
- Configuración global del proyecto (en
miproyecto/config/) - Configuración local de cada aplicación (en
miproyecto/apps/frontend/config/) - Configuración local de cada módulo (en
miproyecto/apps/frontend/modules/mimodulo/config/)
- Niveles de entornos de ejecución:
- Específico para un solo entorno
- Para todos los entornos
Muchas de las opciones que se pueden establecer dependen del entorno de ejecución. Por este motivo, los archivos de configuración YAML están divididos por entornos, además de incluir una sección que se aplica a todos los entornos. De esta forma, un archivo de configuración típico de Symfony se parece al que se muestra en el listado 5-12.
Listado 5-12 - La estructura típica de los archivos de configuración de Symfony
# Opciones para el entorno de producción
prod:
...
# Opciones para el entorno de desarrollo
dev:
...
# Opciones para el entorno de pruebas
test:
...
# Opciones para un entorno creado a medida
mientorno:
...
# Opciones para todos los entornos
all:
...Además de estas opciones, el propio framework define otros valores por defecto en archivos que no se encuentran en la estructura de directorios del proyecto, sino que se encuentran en el directorio sfConfig::get('sf_symfony_lib_dir')/config/config/ de la instalación de Symfony. El listado 5-13 muestra la configuración por defecto de estos archivos. Todas las aplicaciones heredan estas opciones.
Listado 5-13 - La configuración por defecto, en sfConfig::get('sf_symfony_lib_dir')/config/config/settings.yml
# Opciones por defecto:
default:
.actions:
default_module: default
default_action: index
...Las opciones de estos archivos se incluyen como opciones comentadas en los archivos de configuración del proyecto, la aplicación y los módulos, como se muestra en el listado 5-14. De esta forma, se puede conocer el valor por defecto de algunas opciones y modificarlo si es necesario.
Listado 5-14 - La configuración por defecto, repetida en varios archivos para conocer fácilmente su valor, en frontend/config/settings.yml
#all:
# .actions:
# default_module: default
# default_action: index
# ...El resultado final es que una misma opción puede ser definida varias veces y el valor que se considera en cada momento se genera mediante la configuración en cascada. Una opción definida en un entorno de ejecución específico tiene más prioridad sobre la misma opción definida para todos los entornos, que también tiene preferencia sobre las opciones definidas por defecto. Las opciones definidas a nivel de módulo tienen preferencia sobre las mismas opciones definidas a nivel de aplicación, que a su vez tienen preferencia sobre las definidas a nivel de proyecto. Todas estas prioridades se resumen en la siguiente lista de prioridades, en el que el primer valor es el más prioritario de todos:
- Módulo
- Aplicación
- Proyecto
- Entorno específico
- Todos los entornos
- Opciones por defecto