Ir al contenido principal

Instalación de Laravel Homestead y (IV)

 

En esta entrada, la última de la serie dedicada al Homestead, veremos como llevar a la práctica lo que hemos aprendido hasta ahora. Lo haremos desde dos puntos de vista. Con el Homestead instalado de forma global y con una instalación por proyecto. De este modo, podrás usar el Homestead de la forma en que más prefieras.

Ejecución del entorno Homestead con una instalación global

Llegados a este punto, supongo que ya tienen instalado el Homestead en modo global y configurado el fichero Homestead.yaml. En él pondremos nuestra carpeta compartida ~/code mapeada a /home/vagrant/code. Pues ahora lo primero que hay que hacer es crear la máquina virtual. En el directorio donde instalamos nuestro Homestead:

cd /Homestead

vagrant up 

Durante un buen rato se estará creando la máquina virtual, automáticamente se irá descargando e instalando el software definido en Homestead.yaml. Esto sólo ocurrirá la primera vez que se cree la máquina virtual. Las siguientes veces que utilicemos el comando vagrant up para arrancar la máquina virtual no se descargará software.

Una vez arrancada la máquina virtual y comprobado que en el fichero /etc/hosts está especificada la dirección para el acceso a la página de inicio del sitio de prueba especificado en el fichero Homestead.yaml, nos conectamos a la máquina virtual con el comando:

vagrant ssh

Dentro de la máquina virtual estaremos en el home del usuario vagrant. Nos movemos a la carpeta compartida para crear nuestro proyecto de Laravel.

 cd code

laravel new proyecto1 

El instalador de laravel comenzará a crear nuestro proyecto en la carpeta /home/vagrant/code/proyecto1. Una vez terminado, tendremos el esqueleto un proyecto Laravel a cuya página por defecto accederíamos desde el navegador de la máquina anfitriona con la dirección http://proyecto1.test (siendo proyecto1 el nombre de nuestro proyecto). La página por defecto mostrada es como esta:

Ejecución del entorno Homestead con una instalación por proyecto

La ejecución desde una instalación por proyecto es similar a la de la instalación global, pero tiene unas pequeñas diferencias. Pongamos por caso que nuestro proyecto se llamará proyecto2 y estará en nuestra máquina en la ruta ~/code/proyecto2. Por lo tanto el mapeo de las carpetas en el Homestead.yaml quedaría:

folders:

    -

        map: ~/code/proyecto2

        to: /home/vagrant/code/proyecto2

Y el del sitio:

sites:

    -

        map: proyecto2.test

        to: /home/vagrant/code/proyecto2/public

Levantamos la máquina, que al igual que en el caso anterior tardará un buen rato en descargar el software necesario. Para hacerlo, esta vez, nos movemos hasta el directorio de nuestro proyecto y ejecutamos Vagrant:

cd ~/code/proyecto2

vagrant up

Después de arrancar la máquina virtual, accedemos a ella del mismo modo que hicimos anteriormente:

vagrant ssh

Lo que nos deja en el home de vagrant. Como antes nos desplazamos a la carpeta compartida e intentamos crear el proyecto Laravel.

cd code

Y es ahora cuando se nota la diferencia a la hora de crear el proyecto. Si simplemente ejecutamos el instalador de Laravel (laravel new proyecto2), éste nos devolverá un mensaje de error diciéndonos que el proyecto ya existe:

Por lo tanto tendremos que recurrir a una solución alternativa, lo que en ingles se dice work around, para poder generar nuestro proyecto en la carpeta compartida. Lo primero es crear una carpeta temporal en el directorio home del usuario vagrant y movernos a ella:

mkdir ~/tmp && cd ~/tmp

Y en esta carpeta temporal creamos el proyecto Laravel:

laravel new proyecto2

Una vez creado el proyecto, lo que se debe hacer es copiarlo a la carpeta compartida del mismo:

cp -rf proyecto2 ~/code

Y por fin, si comprobamos con el navegador en la máquina anfitriona, vemos que ya nos aparece la página por defecto de Laravel.

No olvidemos eliminar la carpeta temporal que ya no nos sirve para nada: 

cd && rm -rf tmp

Algunos comandos vagrant útiles

En esta sección mostraré algunos comandos de Vagrant que tendrás que utilizar cuando trabajas con cajas Vagrant. Son sólo una muestra y los más comunes, para tareas más complejas deberás consultar la documentación, cuyo enlace puse en el primer artículo de esta serie.
  • vagrant up: este comando sirve tanto para crear la máquina virtual a partir de las definiciones del fichero Vagrantfile como para ejecutar la máquina virtual ya creada. En el caso del Homestead, el Vagrantfile se nutre de lo especificado en el fichero Homestead.yaml, por lo que no hay que editar el Vagrantfile para nada. Cuando se crea la máquina virtual, es decir, la primera vez que se ejecuta este comando, se descargará el software definido en la Vagrant Box. Por lo que el arranque de la máquina virtual tardará más la primera vez.
  • vagrant ssh: con este comando establecemos una conexión por SSH a la máquina virtual desde la máquina anfitriona. 
  • vagrant halt: ejecutado desde la máquina anfitriona, este comando parará la máquina virtual.
  • vagrant reload --provision: hay casos en que habremos cambiado la configuración definida en el fichero Homestead.yaml. Para que esos cambios se apliquen sin tener que volver a crear la máquina virtual, utilizamos este comando.
  • vagrant destroy: con este comando destruimos la máquina virtual.

Conclusiones

Hemos llegado al final de la serie que explica la instalación y configuración de un nuevo proyecto usando Laravel Homestead

Una vez en marcha nuestro proyecto, trabajaremos en la máquina virtual anfitriona usando nuestro IDE PHP preferido para trabajar en él. La carpeta compartida en la máquina anfitriona (~/code o la que sea) se mantiene en todo momento sincronizada con su homóloga en la máquina virtual. Por lo que para ir viendo el avance en nuestro proyecto podremos utilizar el navegador de la máquina anfitriona usando la dirección del sitio definido en el fichero Homestead.yaml. Como se puede ver, para el trabajo diario casi no es necesario acceder a la máquina virtual. Sólo hace falta levantarla al principio y pararla al final.

El blog lo he tenido un poco abandonado por circunstancias personales. Ahora he decidido revivirlo con esta serie y continuar compartiendo mis conocimientos de Ubuntu con el resto de ustedes de una forma que entiendo es clara e intuitiva. Si están interesados en el blog, los animo a suscribirse. 

Espero que les haya gustado esta serie de artículos. Si tienen alguna opinión o sugerencia no duden en dejarla en la sección de comentarios. 

Comentarios

Entradas populares de este blog

Atom ha muerto, viva Zed

El día 8 de junio de 2022, Microsoft anunció que a partir del día 31 de diciembre de este mismo año dejaría de dar soporte para el editor de código Atom .  ¿En qué nos afecta esto a nosotros? Bueno, pues si me han seguido en artículos anteriores saben que tras una comparativa de varios IDEs había decidido utilizar Atom para los ejemplos que tuviera que hacer en este blog. Sobre todo los artículos que prepararé para ilustrar el uso de Laravel . Amén de los miles de programadores que actualmente usan Atom  en sus proyectos, claro. Pero, ¿qué editor de código abierto podremos utilizar para sustituir a Atom ? En el mismo comunicado, Microsoft explicaba que el abandono del proyecto Atom  se debía a que querían volcar todos sus esfuerzos en el Visual Studio Code y, por supuesto, recomendó a los usuarios de Atom la utilización del mismo como alternativa natural. No quiero entrar en las bondades o defectos del Visual Studio Code  si quieres elegirlo como tu IDE para d...

Gestión de la red usando la línea de comandos (III): gestión DNS

  Introducción En este nuevo artículo de la serie vamos a hablar de la gestión del DNS, Domain Name System. El sistema de resolución de nombres nos permite traducir los nombres de los dominios de Internet en direcciones IP númericas. Más difíciles de recordar para los humanos.  El DNS fue concebido a mediados de los años 80. Hasta esa época, los ordenadores conectados a una red disponían de una dirección numérica, la dirección IP. Pero con el tiempo, cada vez había más ordenadores conectados a las redes. Esto hacía que cada vez fuera más difícil recordar las direcciones IP. Sobre el año 1983, Paul Mockapetris , un informático estadounidense, desarrolló un sistema jerárquico de nombres para identificar a los ordenadores conectados a una red. Y, a mediados de la década, ya se convirtió en un estándar. Pueden consultar más información sobre el sistema DNS consultando el artículo de la Wikipedia: Sistema de nombres de dominio . En este artículo, no vamos a explicar como montar un ...

Gestión de la red usando la línea de comandos (IV): monitorización de conexiones

  Introducción En este artículo de la serie de gestión de la red usando la línea de comandos nos vamos a centrar en la monitorización de las conexiones. Para ello vamos a utilizar el comando netstat , que es el decano de los comandos de monitorización de la red. También mostraremos el comando ss , que viene a sustituir a netstat  en las funciones de monitorización de conexiones de red. Asimismo mostraré una breve explicación de los conceptos que se van a trabajar en el artículo. S ockets, puertos, protocolos y procesos En primer lugar vamos a empezar con un poco de teoría para alumbrar lo que luego se explicará en el artículo. Si ya sabes de lo que estamos hablando, sáltate esta sección y ve al meollo del asunto [1] . Nos referiremos al contexto de la conexiones TCP/IP. Dentro de este contexto, cada conexión queda definida por dos endpoints , puntos finales, uno en el host , equipo, que establece la conexión y otro en el host con el que se comunica. Generalmente este último es...