Despliegue

Despliegue

¡Muy bien! ¡Ha llegado el momento de la verdad! La aplicación está lista y el cliente ansioso por cortar la cinta roja.

Es claro que, para que eso suceda el código debe, de alguna forma, llegar al servidor de Producción.

Si bien en teoría puede tratarse de cualquier combinación de hardware/sistema operativo, lo más conveniente es que sea lo más parecido posible a tu máquina virtual.

Ahora, antes de abrir el cliente de FTP, hay algunas consideraciones a tener en cuenta.

Los entornos

Symfony, como cualquier otro framework profesional, tiene muy incorporada la noción de entorno.

Hasta ahora, siempre trabajamos en un ambiente controlado, el entorno de desarrollo (dev).

En este contexto es perfectamente razonable (¡y útil!) ver cada tanto alguna pantalla similar a:

Con un precioso volcado de la pila de llamadas y demás.

Claro que, si esto llegara a los ojos de un usuario final sería… incómodo por decirlo de algún modo.

Y si llegara a los ojos de un atacante sería realmente problemático.

De ahí que ciertos comportamientos de la aplicación deben variar según el ambiente donde el código esté ejecutándose.

Una forma de lograr esto sería llenar el código de sentencias if… claramente algo que NO haremos (Entre otros, si hiciéramos eso sería muy difícil confiar en las pruebas que realizamos localmente).

Es aquí donde empiezan a jugar los archivos de configuración.

Los archivos de configuración

Desde los inicios de Symfony esta fue una preocupación: ¿cómo usar un mismo código en diferentes ambientes?

Las versiones iniciales lo resolvían usando un punto de entrada diferente según el ambiente: había un archivo index.phpy un app_dev.php (El primero para el ambiente productivo y el segundo para el de desarrollo).

Si bien esto funcionaba, traía una serie de problemas aparejados que complicaban la subida a producción (Había que usar diferentes configuraciones para el webserver y ser cuidadoso con no llevar a producción el archivo app_dev entre otras).

Actualmente se utiliza un esquema bastante mejor: la configuración de entorno.

Todo el modelo se basa en que las diferencias entre lo que sucede en producción y cualquier otro ambiente deberían ser mínimas: sólo algunas configuraciones.

Por ejemplo, es esperable que el servidor donde está la base de datos productiva y el de desarrollo no sean el mismo, lo mismo sucede con el usuario y contraseña.

El sistema de configuración de Symfony es ciertamente complejo (aunque ha ido simplificándose a lo largo del tiempo).

Por un lado tenemos la configuración específica de los paquetes que instalamos: todo lo que está dentro del directorio config/packages.

En este directorio encontrarás un archivo .yaml por cada paquete.

La modificación de estos archivos tiene un impacto directo en cómo estos paquetes realizan su tarea.

Si miras dentro de este directorio encontrarás, al menos, tres más: dev, prod y test.

En estos directorios puedes encontrar archivos con el mismo nombre que alguno que encuentres en el directorio padre.

Cuando esto sucede lo que hace el framework es sobre-escribir la configuración padre con la que figura en el archivo hijo (solo en aquellas claves que están definidas).

También puede ocurrir que sólo existan los archivos hijo. Esto puede deberse a que cada entorno requiere su propia configuración para un determinado paquete o bien a que cierto paquete sólo está disponible en un entorno determinado (Ejemplo: web_profiler.yaml).

Si miras el archivo config/packages/dev/monolog.yaml y lo comparas con config/packages/prod/monolog.yamlnotarás que existen muchas diferencias.

En este caso, lo que ocurre es que el tratamiento de errores en producción será bastante diferente a aquel de desarrollo.

Hasta aquí hemos visto las configuraciones que hacen al comportamiento.

Luego están las configuraciones que tienen información específica del entorno.

El principal archivo de configuración es .env.

La configuración que no puede faltar es aquella que indique en qué entorno está ejecutando la aplicación.

Al comienzo Symfony creará un archivo .env para nosotros y colocará allí la siguiente definición:

APP_ENV=dev

De este modo estamos indicando que las configuraciones que deben utilizarse son aquellas que estén en el directorioconfig/packages/dev

Y luego tenemos algunas otras definiciones propias del entorno, como por ejemplo:

DATABASE_URL=mysql://homestead:[email protected]:3396/homestead?serverVersion=5.7

¿Te suena familiar?

En la clase 5 editaste este archivo… ahora entiendes por qué 😃

En cada computadora en que debe correr tu aplicación debe existir un archivo .envque defina, al menos, a qué entorno de trabajo pertenece.

Luego existen escenarios algo más complejos donde, por ejemplo, dos servidores productivos podrían apuntar a bases de datos diferentes.

En tal caso podrías crear un nuevo archivo .env.local donde definir únicamente la clave DATABASE_URL (Todo lo demás sería heredado de .env).

Para nuestro ejemplo será suficiente con tener un archivo .env en nuestra computadora y uno similar pero diferente en el servidor de producción.

El despliegue

Antes de realizar el despliegue de nuestra aplicación será necesario:

1. Contar con un servidor dónde realizar dicho despliegue
2. Definir una estrategia para realizar dicho despliegue

El punto 1 es bastante simple: se trata de contratar algún servicio de hosting que soporte PHP.

Mi recomendación en este punto es usar algún VPS.

Como hemos visto, trabajar con Symfony implica usar bastante la terminal y los hosting compartidos no suelen ser muy amigos de esta práctica, además de tener que luchar con versiones incompatibles de php… pero bueno, si no queda otra, será cuestión de adaptar nuestro Homestead a las posibilidades.

Respecto del punto 2, las opciones son realmente muchas.

La que yo suelo utilizar es la de apoyarme en Git.

De modo que mi típico primer deployment es algo como:

1. Realizar un push al servidor remoto (GitHub o BitBucket suelen ser mis elegidos).
2. Realizar un pull desde mi servidor de producción.
3. Instalar las dependencias via composer.
4. Crear el archivo.env.
5. Cambiar la configuración APP_ENV=dev por APP_ENV=prod.
6. Correr las migraciones de la base de datos.
7. Limpiar la cache.
8. Apuntar el webserver al directorio publicde mi aplicación.

Respecto del punto de la caché, Symfony se apoya mucho en el uso de este mecanismo para acelerar la ejecución de las aplicaciones.

Especialmente cuando se trata del entorno de producción y, más aún, si la cantidad de usuarios es grande, la diferencia entre servir contenido pre-generado o generado en el momento puede ser importante.

Para limpiar la caché se utiliza el comando php bin/console cache:clear

Claro que los siguientes despliegues son algo más sencillos:

1. Realizar un push al servidor remoto.
2. Realizar un pull desde mi servidor de producción.
3. Instalar las dependencias vía composer.
4. Correr las migraciones de la base de datos.
5. Limpiar la cache.

Cuando el proyecto esté desplegado en el servidor podrás ver esto al ingresar al sitio:

Nota como ha desaparecido la barra inferior:

Eso es natural: esa barra contiene información muy útil para tí cuando estás desarrollando, pero definitivamente no quieres que esté disponible para cualquier visitante!

Este es uno de los efectos de cambiar la definición de APP_ENV de devaprod.

Otra diferencia que notarás es que, si se produce un error, la pantalla que verás será bastante más escueta, algo como:

Nuevamente, esto tiene que ver con hacer tu aplicación algo más segura.

Despliegues más complejos

Dependiendo de las características particulares de nuestra aplicación y el hosting que tengamos puede que necesitemos alguna estrategia de deploy algo más compleja.

En esos casos recomiendo utilizar alguna herramienta de automatización como puede ser scripts de bash o algún paquete propio de Symfony como EasyDeployBundle

Bien, con esto tienes lo necesario para crear tus aplicaciones Symfony y desplegarlas en un servidor de producción. ¡¡Viva!!

Ahora quiero invitarte a conversar sobre algunos otros frameworks que existen aparte de Symfony. ¡Acompáñame!