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 SubscribeNo quiero adentrarme demasiado en el despliegue, pero vamos a hacer un curso rápido de "Cómo desplegar tu aplicación Symfony 101". Esta es la idea.
Paso 1: Tienes que llevar de alguna manera todo tu código comprometido a tu máquina de producción y luego ejecutar
composer install
para rellenar el directorio vendor/
.
Paso 2: crea de algún modo un archivo .env.local
con todas tus variables de entorno de producción, que incluirá APP_ENV=prod
, para que estés en el entorno de producción.
Y Paso 3: ejecuta
php bin/console cache:clear
que borrará la caché en el entorno de producción, y luego
php bin/console cache:warmup
para "calentar" la caché. Puede haber algunos otros comandos, como ejecutar las migraciones de tu base de datos... pero esta es la idea general. Y los documentos de Symfony tienen más detalles.
Por cierto, en caso de que te lo preguntes, desplegamos a través de https://platform.sh, utilizando la integración en la nube de Symfony... que se encarga de muchas cosas por nosotros. Puedes comprobarlo entrando en https://symfony.com/cloud. También ayuda a apoyar el proyecto Symfony, así que todos salimos ganando.
De todos modos, la parte más complicada del proceso es el paso 2: crear el archivo .env.local
con todos tus valores de producción, que incluirán cosas como las claves de la API, los detalles de la conexión a la base de datos y más.
Ahora bien, si tu plataforma de alojamiento te permite almacenar variables de entorno reales directamente dentro de ella, ¡problema resuelto! Si estableces variables de entorno reales, entonces no hay necesidad de gestionar un archivo .env.local
en absoluto. En cuanto despliegues, Symfony verá y utilizará instantáneamente las variables de entorno reales. Eso es lo que hacemos para Symfonycasts.
Pero si eso no es una opción para ti, tendrás que dar de alguna manera a tu sistema de despliegue acceso a tus valores sensibles para que pueda crear el archivo.env.local
. Pero... como no vamos a consignar ninguno de estos valores en nuestro repositorio, ¿dónde debemos almacenarlos?
Una opción para manejar los valores sensibles es la bóveda de secretos de Symfony. Es un conjunto de archivos que contienen variables de entorno de forma encriptada. Estos archivos son seguros para enviarlos a tu repositorio... ¡porque están encriptados!
Si quieres almacenar secretos en una bóveda, necesitarás dos: una para el entornodev
y otra para el entorno prod
. Primero vamos a crear estas dos bóvedas... y luego te explicaré cómo leer valores de ellas.
Empieza creando una para el entorno dev
. Ejecuta:
php bin/console secrets:set
Pasa este GITHUB_TOKEN
, que es el secreto que queremos establecer. A continuación, nos pide nuestro "valor secreto". Como se trata de la bóveda del entorno dev
, queremos poner algo que sea seguro para que todos lo vean. En un momento explicaré por qué. Diré CHANGEME
. No puedes verme escribir eso... sólo porque Symfony lo oculta por razones de seguridad.
Como este es el primer secreto que hemos creado, Symfony creó automáticamente la bóveda de secretos entre bastidores... que es literalmente un conjunto de archivos que viven en config/secrets/dev/
. Para la bóveda dev, vamos a confirmar todos estos archivos en el repositorio. Vamos a hacerlo. Añade todo el directorio de secretos:
git add config/secrets/dev
Luego haz el commit con:
git commit -m "adding dev secrets vault"
He aquí una explicación rápida de los archivos. dev.list.php
almacena una lista de los valores que viven dentro de la bóveda, dev.GITHUB_TOKEN.28bd2f.php
almacena el valor cifrado real, y dev.encrypt.public.php
es la clave criptográfica que permite a los desarrolladores de tu equipo añadir más secretos. De modo que si otro desarrollador se baja del proyecto, tendrá este archivo... para poder añadir más secretos. Por último, dev.decrypt.private.php
es la clave secreta que nos permite desencriptar y leer los valores de la bóveda.
En cuanto los archivos de la bóveda estén presentes, Symfony los abrirá automáticamente, descifrará los secretos y los expondrá como variables de entorno Pero, más sobre esto en unos minutos.
Pero espera: ¿realmente acabamos de confirmar la clave decrypt
en el repositorio? Sí, ¡eso normalmente sería un no-no! ¿Por qué te tomarías la molestia de encriptar valores... sólo para almacenar la clave de desencriptación junto a ellos?
La razón por la que hacemos esto es que se trata de nuestra bóveda de desarrollo, lo que significa que sólo vamos a almacenar valores que sean seguros para que los vean todos los desarrolladores. La bóveda de dev
sólo se utilizará para el desarrollo local... y queremos que nuestros compañeros de equipo puedan bajar el código y leerlo sin problemas.
Bien, en este punto tenemos una bóveda dev
que Symfony utilizará automáticamente en el entorno dev
. Siguiente: vamos a crear la bóveda prod, que contendrá los valores verdaderamente secretos. Luego aprenderemos la relación entre los secretos de la bóveda y las variables de entorno... así como una forma fácil de visualizar todo esto.
Hey Rufnex,
We do have a tutorial about deployment already! :) Take a look at Ansistrano tool: https://symfonycasts.com/screencast/ansistrano - it's based on Ansible automation language, but you're not required to know it to start this deployment course as its syntax is pretty descriptive. Moreover we explain it during the course well I think. But in case you're interested in Ansible to learn its syntax deeper - we also have a separate tutorial about it here: https://symfonycasts.com/screencast/ansible
Cheers!
Hey Rufnex,
You're welcome! If you have any use cases that are not covered with that Ansistrano deploy tutorial - please, let us know in the comments! It would definitely help us to plan a new deploy tutorial in the future :)
Cheers!
// composer.json
{
"require": {
"php": ">=8.1",
"ext-ctype": "*",
"ext-iconv": "*",
"knplabs/knp-time-bundle": "^1.18", // v1.19.0
"symfony/asset": "6.1.*", // v6.1.0-RC1
"symfony/console": "6.1.*", // v6.1.0-RC1
"symfony/dotenv": "6.1.*", // v6.1.0-RC1
"symfony/flex": "^2", // v2.1.8
"symfony/framework-bundle": "6.1.*", // v6.1.0-RC1
"symfony/http-client": "6.1.*", // v6.1.0-RC1
"symfony/monolog-bundle": "^3.0", // v3.8.0
"symfony/runtime": "6.1.*", // v6.1.0-RC1
"symfony/twig-bundle": "6.1.*", // v6.1.0-RC1
"symfony/ux-turbo": "^2.0", // v2.1.1
"symfony/webpack-encore-bundle": "^1.13", // v1.14.1
"symfony/yaml": "6.1.*", // v6.1.0-RC1
"twig/extra-bundle": "^2.12|^3.0", // v3.4.0
"twig/twig": "^2.12|^3.0" // v3.4.0
},
"require-dev": {
"symfony/debug-bundle": "6.1.*", // v6.1.0-RC1
"symfony/maker-bundle": "^1.41", // v1.42.0
"symfony/stopwatch": "6.1.*", // v6.1.0-RC1
"symfony/web-profiler-bundle": "6.1.*" // v6.1.0-RC1
}
}
A tutorial on deployment might be an interesting idea :)