Cuando has terminado tu primera aplicación Laravel, comienza una nueva tarea, la de desplegarla en un servidor web. Ya sea porque es un encargo de un cliente o porque es un proyecto personal que quieres publicar, es necesario que funcione en algún servidor. Porque eso de enseñarla solamente en tu entorno de desarrollo es poco útil.
Como siempre que llegamos a estos puntos de desplegar aplicaciones, tenemos múltiples posibles destinos, ya sea un servidor on premise al que podemos tener incluso acceso físico hasta una máquina virtual. Desplegar Laravel en servidores a los que tenemos un nivel de acceso alto es una tarea relativamente sencilla siguiendo los pasos que el propio producto nos indica en su documentación oficial.
No siempre es posible disponer de un acceso alto al servidor, ya que los clientes de tamaño medio o pequeño suelen tener limitados los costes. En este caso nos debemos desplegar nuestra aplicación en un servidor compartido. Tienen unos costes más ajustados, pero también más limitados los accesos.
Uno de los primeros límites que tienen los servidores compartidos está en el acceso a la consola o terminal. Esta limitación provocará que no podamos ejecuta de forma directa ninguno de los comandos de Artisan. Y aquí empiezan las complicaciones, porque debemos buscar una forma alternativa para realizar esos mismos pasos.
Laravel es un framework de desarrollo que tiene muchas ventajas y ofrece asistencias para un desarrollo más ágil, pero su despliegue en hosting compartidos no es tan sencillo, puesto que gran parte de las herramientas que nos ofrece se utilizan desde el terminal de comandos.
Artículo recomendado: Por qué es un buen momento para aprender Laravel
Pasos previos
Un entorno de desarrollo es ligeramente diferente a un entorno de producción. Especialmente en lo relativo a seguridad. Por este motivo, debemos verificar que hacemos las adaptaciones necesarias en cuanto a configuración.
Por despiste o desconocimiento, son muchas las aplicaciones web que tienen el modo de depuración activo.
La depuración es muy útil en desarrollo para detectar el origen de los errores y corregirlo, pero es un gran agujero de seguridad si esta información la exponemos en internet.
En estos volcados a pantalla se muestran rutas e incluso valores que pueden dar pistas a los usuarios maliciosos para atacar nuestra aplicación y acceder a nuestros datos.
Vamos al fichero config/app.php y verificamos los valores de las claves env, debug y url se obtiene del fichero de configuración de entorno. Esto lo vemos claramente porque utilizan la función env para obtener el valor de las claves asociadas
'env' => env('APP_ENV', 'production'),
'debug' => (bool) env('APP_DEBUG', false),
'url' => env('APP_URL', 'http://localhost'),Lenguaje del código: PHP (php)El segundo parámetro es un valor por defecto, por si no se encontrase la clase en el fichero, así que tampoco le prestaremos demasiada atención.
A continuación revisaremos el fichero .env. Si has mantenido el orden inicial, algo altamente recomendable, deberías tener las siguientes líneas al inicio:
APP_NAME=Laravel
APP_ENV=local
APP_KEY=base64:X0hgHxJ8c88yUwq2LxHRRrUQOaDeIqKsvjmZAP9dsIo=
APP_DEBUG=true
APP_TIMEZONE=UTC
APP_URL=http://localhostLenguaje del código: JavaScript (javascript)Nos centraremos en APP_ENV y en APP_DEBUG. La primera nos indica el entorno, que inicialmente tendrá el valor local, pero que a la hora de pasar a producción cambiaremos por production. Más importante es APP_DEBUG, que en desarrollo nos conviene que tenga valor true, pero al pasar a producción debe tener valor false. De lo contrario, si alguna vez se produce un error no controlado en nuestra aplicación, me mostrará todo nuestro código fuente por pantalla.
Por último, y muy importante, antes de desplegar en producción, hay que cambiar la clave de cifrado de datos. Laravel utiliza la función de cifrado AES (Advanced Encription Standard) y para encriptar datos cifrados de base datos o cookies va a utilizar el valor de la clave APP_KEY. Además, se utiliza para generación te token o firmas, por lo que antes de desplegar la aplicación, regeneramos esta clave ejecutando desde un terminal la siguiente instrucción
php artisan key:generateLenguaje del código: CSS (css)Además, debemos revisar los distintos parámetros de configuración por si hay cambios respecto a nuestro entorno local. Dentro de estos parámetros a modificar, estarán los bloques correspondientes al envío de correo, base de datos, Redis o AWS
Ahora sí, podemos pasar a copiar nuestros ficheros desde FTP.
Copiando los ficheros
Es posiblemente la parte más sencilla del despliegue de una aplicación Laravel, puesto que no hay que hacer prácticamente nada distinto a cuando subimos imágenes para una web estática.
Accedemos al servidor remoto por FTP con nuestro cliente favorito y copiamos los ficheros de nuestro proyecto Laravel.
Podemos copiar todos con tranquilidad porque estarán protegidos por la seguridad de Laravel, pero algunos no nos serán necesarios.
Como veremos un poco más adelante, la carpeta database, no es necesaria, puesto que la base de datos no la crearemos mediante migraciones y seeders.
Tampoco necesitaremos la carpeta test, puesto que no es habitual que ejecutemos pruebas en producción después del despliegue. Si dentro de tu aplicación has creado tests automatizados, debes copiar la carpeta y ejecutar los test antes de eliminar la carpeta.
Por último, revisa la carpeta storage y borra todo el contenido de logs y revisa los ficheros que haya subido tu aplicación, porque la mayoría (por no decir todos) corresponderán a pruebas en desarrollo.
La base de datos
Las migraciones en este caso nos van a servir de poco, porque al no poder utilizar Artisan, no podremos ejecutarlas y tampoco cargar los Seeder de apoyo para esos datos iniciales
En una aplicación con un modelo de datos grande y con varias tablas auxiliares, podemos tener varias tablas que alimentamos con Seeder. Tanto esta carga de datos, como la propia creación de la base de datos, es algo que no podremos hacer sin ejecutar comandos.
En este caso, lo vamos a hacer exportando la base de datos. Pero antes, debemos asegurar que no contiene datos procedentes de pruebas. Desde un terminal ejecutamos
php artisan migrate:refreshLenguaje del código: CSS (css)Con esta instrucción regeneramos todo el modelo y a continuación podemos ejecutar todos los seeder con
php artisan db:seedLenguaje del código: CSS (css)Y la base datos ya está “limpia”. Ahora vamos a nuestro cliente de base de datos y exportamos nuestra base de datos a un fichero SQL
Que luego importaremos desde el cliente que nos ofrezca nuestro hosting compartido, normalmente será phpMyAdmin. Para ello, creamos la base de datos y le asignamos el mismo nombre que habíamos definido en el fichero .env además nos aseguraremos de haber creado el usuario y contraseña del mismo fichero con los permisos más altos sobre la base de datos.
Una vez creada la nueva base de datos, la seleccionamos desde phpMyAdmin e importamos tanto el esquema como los datos:
A probar y primeros errores
Lo normal, es acabar el despliegue de nuestra aplicación en este punto, por lo que llega el momento de probar y verificar que todo está funcionando conforme a lo que debería.
En muchos casos comprobaremos que no hay ningún error adicional o según vayan surgiendo los corregimos, pero nos encontraremos con un último obstáculo, la ruta simbólica para los ficheros subidos desde la propia aplicación.
Enlaces simbólicos
Por el modelo de seguridad de Laravel, cuando subimos un fichero lo dejamos en una ruta protegida y ofrecemos un enlace simbólico que tiene que estar correctamente mapeado para poder recuperar estos ficheros desde la aplicación.
Desde nuestro entorno de desarrollo lo solucionábamos ejecutando el comando
php artisan storage:linkLenguaje del código: CSS (css)Pero al no poder ejecutar comandos en nuestro hosting compartido, debemos simularlos. Volvemos a nuestro entorno de desarrollo y abrimos el fichero web.php. En un punto del mismo en el que no estén protegidas las rutas por ningún middleware incorporamos una nueva ruta que va a realizar una llamada a Artisan:
Route::get('/symlink', function () {
Artisan::call('storage:link');
});Lenguaje del código: PHP (php)Subimos el fichero web.php por ftp a nuestro hosting y abrimos la ruta /symlink tras ejecutarse no debe dar una pantalla en blanco, puesto que no le hemos añadido ninguna información y con esto ya lo tendríamos
Solamente quedaría eliminar esa ruta y volver a subir el fichero.
Esta acción para llamar a Artisan, nos sirve con cualquier comando, solamente debemos incorporarle como parámetro a call el comando y como segundo parámetro la lista de argumentos en forma de array asociativo
Artisan::call('comando:nombre', [ 'argumento1' => valor1, 'argumento2' => valor2]);Lenguaje del código: PHP (php)Esto lo necesitaremos, por ejemplo si queremos optimizar nuestro proyecto con caché de eventos, rutas o vistas, o si hacemos una actualización que requiere borrar cache.
De esta forma podemos tener una ruta adicional
Route::get('/clearcache’, function () {
Artisan::call('optimize:clear');
Artisan::call('optimize');
});Lenguaje del código: JavaScript (javascript)Que nos borrará la cache y la regenerá.
Conclusión
El despliegue de una aplicación suele ser tedioso y para ello, siempre podemos generar nuestros propios scripts o utilizar herramientas de automatización, como es el caso de Laravel Forge.
Pero si no podemos utilizarlas o no consideramos incorporar su coste de licenciamiento a nuestro proyecto, podemos hacerlo de forma totalmente artesana siguiendo estos pasos.
Únete a nuestra comunidad
Ser parte de la comunidad tech de Codemotion te permitirá potenciar tu experiencia y enfrentar nuevos desafíos que impulsarán tu carrera. Aprenderás nuevas habilidades técnicas y crecerás junto a otros miembros mediante el intercambio de opiniones y la creación conjunta.
Nuestra comunidad de Telegram es para ti. Allí encontrarás el mejor networking, artículos high-tech, debates de tendencias tech y beneficios exclusivos. Súmate aquí.
¡Nos vemos en Codemotion!
