Advertisement
  1. Code
  2. PHP

Implementar su aplicación PHP con Rocketeer

by
Read Time:18 minsLanguages:

Spanish (Español) translation by Elías Nicolás (you can also view the original English article)

Hubo un tiempo en que los desarrolladores de PHP tenían que usar herramientas de despliegue que estaban dirigidas a aplicaciones web generales. Esto se puede ver en el tutorial de Johannes Schickling sobre el despliegue de aplicaciones Laravel con Capistrano, por ejemplo. Es una herramienta Ruby, y necesitas escribir código Ruby. Estas herramientas realizan el trabajo pero tienen una integración limitada con las aplicaciones PHP. Esto puede resultar en soluciones hacky para ciertos escenarios.

Pero hoy en día, tenemos la bendición de unas pocas herramientas de despliegue escritas en nuestro idioma que permiten una integración más profunda. Una de estas herramientas es Rocketeer, una herramienta que se inspira en Capistrano y el framework Laravel.

Rocketeer es una herramienta moderna que aporta un gran enfoque para sus necesidades de implementación. Esto es para ejecutar tareas y administrar su aplicación en diferentes entornos y servidores. Además, también tiene algo de magia, como instalar las dependencias de Composer si detecta un archivo composer.json. Usted obtiene los valores predeterminados sanos y la automatización de tareas comunes para una aplicación moderna de PHP. Y usted tiene la capacidad de personalizar y extender todo.

Usted podría describirlo como un corredor de la tarea de SSH que funciona en lado del cliente. Los comandos se ejecutan en servidores a través de una conexión SSH. Si utiliza un proveedor de alojamiento compartido con sólo acceso FTP, por desgracia no tendra suerte. Lo que también necesita es un repositorio remoto donde la herramienta pueda obtener su código. Hay soporte para Git y SVN de forma predeterminada. ¿Necesita soporte para otro sistema de control de versiones? Escriba su propia implementación con las interfaces proporcionadas.

Instalación

Puede instalar Rocketeer de dos formas diferentes. O bien descarga el archivo phar y lo hace ejecutable o lo instala a través de Composer. Soy un partidario de este último. Tenerlo como una dependencia permite una fácil instalación al clonar el repositorio. Esto puede beneficiar a cualquier persona clonando el repositorio para ponerlos en funcionamiento.

Instalación con Composer:

No recomiendo que lo instales globalmente. Mantenerlo en el nivel del repositorio garantizará que cada persona que esté implementando ejecute la misma versión. Lo que sí recomiendo es que agregue vendor/bin a su PATH. A continuación, puede utilizar el binario escribiendo rocketeer en la raíz del proyecto.

Encendido

¡Empecemos! Primero arranque los directorios y archivos para la configuración. Haces esto ejecutando rocketeer ignite en la raíz de tu proyecto.

Cuando su aplicación se enciende, la herramienta crea una carpeta .rocketeer en su proyecto. El contenido del directorio se verá así:

Estos son todos los archivos de configuración que necesita para comenzar a configurar sus implementaciones. Siempre que me refiero a un archivo de configuración de aquí en adelante, existe en el .rocketeer/ directorio.

Estructura de carpetas remotas

Es importante entender cómo Rocketeer gestiona su estructura de carpetas en el lado del servidor, ya que es un poco diferente a una configuración regular. Utiliza algunos directorios para administrar ciertos aspectos del despliegue, por lo que puede ser eficaz en lo que hace. Especifique una ruta de acceso donde desee implementar la aplicación en su servidor y la herramienta se encargará del resto. Esa carpeta se verá así, si tiene /var/www/app como su directorio de aplicación.

La carpeta más importante es la actual, que apunta a su última versión. Es ahí donde debe establecerse la raíz del documento de su servidor web. Entonces, ¿qué sucede cuando se implementa?

  1. La herramienta crea una carpeta con hora marcada en el directorio de releases.
  2. Completa todas las tareas para hacer un lanzamiento listo.
  3. Actualiza el enlace simbólico current a la nueva versión.

Este proceso hace que su implementación sea transparente para el usuario. El cambio entre versiones es casi instantáneo, usualmente denominado despliegues atómicos.

Algunos datos deben ser persistentes entre las implementaciones. Esto puede ser archivos subidos, sesiones de usuario y registros, por ejemplo. Esos archivos o carpetas entran en el directorio compartido. La herramienta crea enlaces simbólicos dentro de cada versión para los que haya configurado.

Eventos

Los eventos dirigen la herramienta y todas las estrategias y tareas disparan un evento antes y después cuando se ejecutan. También proporcionan un evento de parada especial cuando una tarea falla. Esto podría ser, por ejemplo, dependencies.halt o deploy.halt para un error general. Esto nos permite enganchar en el proceso donde necesitamos.

Los eventos predeterminados que ocurren durante una implementación son:

  • deploy.before: antes de que suceda algo.
  • create-release.before: antes de crear un nuevo directorio de lanzamiento.
  • create-release.after: después de crear un nuevo directorio de lanzamiento.
  • dependencies.before: antes de instalar o actualizar dependencias.
  • dependencies.after: después de instalar o actualizar dependencias. Tal vez asegúrese de que los archivos binarios en su carpeta de proveedores son ejecutables.
  • test.before: antes de ejecutar pruebas.
  • test.after: Después de ejecutar pruebas.
  • migrate.before: Antes de ejecutar las migraciones de la base de datos. Tal vez usted quiere hacer una copia de seguridad de su base de datos?
  • migrate.after: Después de ejecutar las migraciones de la base de datos.
  • deploy.before-symlink: antes de enlazar el lanzamiento como nuestro lanzamiento actual.
  • deploy.after: terminado. Usted podría notificar a la gente que todo estaba navegando sin problemas o de otra manera.

También podemos crear nuestros propios eventos que podemos disparar y escuchar. Por ahora, nos quedaremos con estos eventos proporcionados para nosotros. Serán suficientes para nosotros en este momento.

Tareas

En el corazón de Rocketeer, encontramos un concepto llamado tareas. La mayoría de lo que está sucediendo detras de escena son tareas básicas. La definición de una tarea podría ser un conjunto de instrucciones para realizar como un paso en una implementación. Si observamos algunas de las clases que proporciona la herramienta, podemos obtener una idea general de las tareas: clases como Deploy, Setup, Migrate, Rollback y Dependencies. Cuando se implementa, el comando deploy es una tarea con subtareas.

Tipos de tareas

Aquí es donde empezarás a ver cómo está integrada la herramienta con PHP, ya que escribirás tareas en el idioma. Puede crear sus propias tareas de tres maneras diferentes:

Comandos de terminal arbitrarios. Éstos son los trazadores de líneas que usted desea hacer funcionar en su servidor. Puede ser útil para muchas cosas, como ejecutar gulp build ---production por ejemplo.

Cierres. Si necesita un poco más de flexibilidad o complejidad, puede escribir una tarea como un cierre (función anónima). Digamos que desea generar documentación para una API durante la implementación.

Clases. Para tareas más complejas, debe utilizar la opción para crear clases para tareas. Crea una clase y extiende Rocketeer\Abstracts\AbstractTask. A continuación, debe proporcionar al menos una descripción y un método execute(). He aquí un ejemplo completamente inútil sólo para mostrar la estructura de una clase de tarea:

Tenga en cuenta que tiene que registrar las clases de tarea usted mismo. O lo hace a través del archivo hooks.php y lo agrega a la array custom ...

... o puedes hacerlo a través de la facade:

Una vez registrado, puede ejecutarlo:

Definición de tareas

Hablamos primero de los acontecimientos porque enganchamos las tareas en el lugar donde las necesitamos en el proceso. Usted puede hacer esto de algunas maneras. Ir con el que te gusta y que cumple con los requisitos para su nivel de complejidad.

La forma más fácil de definir sus tareas se encuentra en el archivo hooks.php. Proporciona dos matrices para esto, especificando la ejecución de la tarea antes o después de ciertos eventos.

Estrategias

Usted podría ser capaz de decir ya que las tareas proporcionadas son bastante genéricos. Tome Dependencies, por ejemplo. ¿De qué tipo de dependencias estamos hablando y qué gestor de paquetes?

Aquí es donde las estrategias entran en juego. Una estrategia es una implementación específica de una tarea, como ejecutar pruebas con Behat o usar Gulp para construir su front-end. Las tareas tienen una estrategia predeterminada con la opción de ejecutar las otras estrategias a través de la CLI. Podemos enumerar las estrategias disponibles como esto:

Creando sus propias estrategias

Digamos que usted está haciendo BDD con Behat para su aplicación en lugar de TDD. A continuación, desea ejecutar sus pruebas con Behat en lugar de PHPUnit. Ya que es un corredor de pruebas, ya hay un espacio de nombres de estrategia para eso, pero sin implementación. Cree el directorio .rocketeer/strategies/ Y coloque su nuevo BehatStrategy.php allí.

Ahora puede cambiar su estrategia de prueba a la nueva implementación en strategies.php.

Conexiones y etapas

No importa si usted tiene una infraestructura en su lugar o tener uno en mente. No importa si su aplicación se despliega en muchos entornos en muchos servidores. Rocketeer estará allí para ti. Incluso puede tener muchas ubicaciones diferentes en el mismo servidor. Aquí es donde entran los términos conexiones y etapas.

Una conexión es un servidor en el que despliega su aplicación. Esto se llama a menudo un environment, y la producción y puesta en escena son ejemplos de esto. Configurar estas conexiones es una brisa en la herramienta. O lo hace a través de una matriz anidada o manteniendo archivos separados para cada conexión. Cada conexión también puede tener varios servidores en él.

Las etapas son como conexiones dentro de las conexiones, una especie de "connectionception". Usted podría configurar un escenario y un entorno de producción en un solo servidor con el uso de etapas. Así que en lugar de tener dos conexiones separadas, usted tiene una conexión con dos etapas en ella.

Plugins

Una gran característica es que podemos extender nuestro proceso usando plugins. Hay algunos oficiales para la integración con Laravel, Slack, HipChat y Campfire. Luego hay algunos, pero no muchos, en Packagist. La instalación de complementos es una tarea fácil a través de la CLI:

Aunque hay un número limitado de complementos, deja espacio para desarrollar plugins en el futuro. Cuenta de una buena filosofía. ¿Y por qué no desarrollar uno propio?

Configuración de la implementación

Para obtener su aplicación funcionando, necesita una configuración básica. Debes decirle a Rocketeer dónde encontrar tu aplicación y dónde debe desplegarla. Comencemos configurando un nombre de aplicación y configurando un servidor de producción en config.php.

Ahora tiene un nombre de aplicación y un servidor para implementar su aplicación. Esta configuración utiliza la autenticación de clave SSH, pero también puede conectarse con un nombre de usuario y una contraseña. Para obtener una solicitud de nombre de usuario y contraseña, defina 'key' => ''. La herramienta almacenará las credenciales en su máquina local y las utilizará cada vez más adelante. No recomiendo establecer un nombre de usuario y una contraseña en el archivo de configuración, porque nunca desea que las credenciales se comprometan con su repositorio.

Lo que debe hacer ahora es cambiar la conexión predeterminada a la que despliega. Tener el conjunto predeterminado de producción no es ideal. Usted no desea desplegar a la producción por accidente. Por lo tanto, en el mismo archivo, busque la clave default y cambie el valor a staging en su lugar.

El nombre de la aplicación en sí no es tan importante. Pero si no especifica una carpeta para implementar, utilizará esto como el nombre de la carpeta en el directorio raíz. De forma predeterminada, la raíz se establece en /home/www. Con este nombre de aplicación, se desplegará en /home/www/my-deployable-app Si desea cambiar su directorio raíz, puede cambiarlo en remote.php.

En el mismo archivo, tiene la capacidad de anular el nombre de la aplicación y especificar un directorio para su aplicación.

Ahora tiene un extremo de recepción del despliegue, pero también debe configurar la ubicación de su código para que pueda ser recuperado. Para ello, configure su repositorio remoto en scm.php. Por defecto usa Git, pero también tiene soporte para SVN. Dígale la dirección de nuestro repositorio y suministre las credenciales si es necesario. Le sugiero que use la autenticación de clave SSH aquí también, y deje el nombre de usuario y la contraseña vacía.

Puesto que ha agregado una conexión al servidor de producción, desea implementar la rama principal.

Configuración específica de conexión y etapas

En la mayoría de los casos, no desea la misma opción de configuración para todas sus conexiones o etapas. Digamos, por ejemplo, que desee implementar otra sucursal en el entorno de ensayo. Rocketeer le permite anular valores de configuración para conexiones y etapas usando config.php. Para implementar una sucursal llamada puesta en escena en la conexión de prueba, realice lo siguiente:

Utiliza una array anidada para anular los valores de configuración. Bajo la clave de clasificación temporal, busque la clave correspondiente en el archivo que desea cambiar. En este caso es la branch en scm.php.

¡Despliegue, levante!

Ahora tiene todo configurado para hacer un despliegue exitoso. No ha cumplido sus requisitos para una implementación completa, pero es suficiente para que su aplicación se clone en su servidor y se distribuya a los usuarios finales. Primero puede ejecutar la estrategia check para ver si su servidor cumple con los requisitos.

Si todo está bien, puedes implementarlo ejecutando:

Dado que este fue su primer despliegue, Rocketeer se asegurará de que todo esté a la altura. La herramienta crea los directorios que necesita y en los que vivirá nuestra aplicación. Si todo está navegando sin problemas, debería tener una compilación completa de su aplicación en el servidor.

Si ha cambiado la conexión predeterminada a la etapa en la sección anterior, siempre se desplegará en el almacenamiento intermedio. Eso es, por supuesto, a menos que usted le diga que se despliegue a otro lugar. Cuando desee implementar en una conexión diferente o más de uno, utilice el modificador --on.

¿Quieres echar un vistazo a lo que va a pasar en su servidor una vez que pulse el botón? Utilice el indicador --pretend para que la herramienta le diga lo que ejecutará en el servidor.

Houston, tenemos un problema. Necesitamos una reversión.

Desafortunadamente necesitamos cuidar despliegues que rompan la funcionalidad o causen estragos en la infraestructura. Entonces usted necesita hacer una vuelta rápida a su último lanzamiento. Afortunadamente, es una operación sencilla—simplemente ejecuta el comando:

Dado que almacena una serie de compilaciones, realizar una retrotracción es rápido. Cambia el enlace simbólico de current a la versión anterior.

Directorios compartidos

La configuración de directorios compartidos es sencilla—sólo tiene que añadirlos a la array shared que se encuentra en remote.php. Rocketeer creará y vinculará estas carpetas para usted en las implementaciones después. Las rutas especificadas deben ser relativas a su carpeta raíz.

Directorios con permisos de escritura

La mayoría de los directorios compartidos también necesitarán el servidor web para poder escribirles. La escritura de registros, sesiones o subidas de archivos es a menudo una tarea realizada por cualquier aplicación. Estos se agregan a la array permissions.files en remote.php.

Instalar o actualizar dependencias

Instalar o actualizar dependencias es algo que necesita si la aplicación depende de cualquier tipo de dependencias. La herramienta viene con soporte para los gestores de paquetes más populares. No es necesario configurar nada si tiene la configuración predeterminada para ellos. Se detectará e instalar o dependencias de actualización para el Composer, Npm, Bower y Bündler. La estrategia predeterminada para las dependencies se establece en Polyglot. Esta es la forma de la herramienta de detectar e instalar dependencias para los diferentes gestores de paquetes.

Pero digamos que desea instalar todas las dependencias en staging, y la herramienta utiliza el indicador --no-dev por defecto. Tal vez desee instalar PHPUnit para ejecutar pruebas, que es una dependencia de desarrollo. En strategies.php, puede encontrar la clave de composer, que le indica a la herramienta cómo ejecutar Composer. A continuación, puede anular esto en config.php:

Migraciones de bases de datos

Migrar bases de datos es a menudo algo que usted quiere hacer cuando tiene una versión completa, justo antes de que los enlaces simbólicos a la corriente. Sea cual sea la herramienta que utilice, puede decirle que se ejecute antes del enlace deploy.before-symlink. Este gancho no es regular, sino un gancho interno. A continuación, debe registrarlo en otro lugar que hooks.php. Puede hacer esto en events.php, que puede crear si no existe ya.

Ejecutando Pruebas

La ejecución de pruebas en un proceso de despliegue es una excelente forma de garantizar que no se rompan códigos ni pruebas en las grietas. De forma predeterminada, la herramienta utiliza PHPUnit y puede conectar el corredor de prueba para que se ejecute después de instalar o actualizar las dependencias.

Ahora debemos ver que está ejecutando PHPUnit en cada implementación, y en caso de cualquier prueba que falla se abortará. Asegúrese de ver la salida, de lo contrario podría tener un problema con la búsqueda de un binario PHPUnit o su suite de prueba.

Herramientas de compilación front-end

A menudo, nuestras aplicaciones no son sólo un back-end, a menos que sean un REST API por ejemplo. Ejecutar herramientas de compilación para nuestro front-end es una tarea común con herramientas como Grunt, Gulp o Webpack. Hacer esta parte de nuestro proceso de implementación no es nada más sofisticado que usar un gancho para ejecutar los comandos como:

Un front-end a menudo depende de dependencias, así que ejecute las herramientas después de instalarlas o actualizarlas.

Consejos y trucos

Ejecutando Actualizaciones

Si no desea crear una nueva versión al implementar, tiene la opción de ejecutar una actualización. Tenga cuidado al hacer esto ya que no podrá volver a la versión anterior, sólo el release anterior. Pero es una forma rápida y sencilla de actualizar su aplicación con los últimos cambios con:

Tareas locales

A veces puede ser bueno ejecutar tareas en su entorno local. Digamos que desea ejecutar una comprobación PHPCS o crear sus activos estáticos y subirlos al servidor, eliminando la necesidad de ciertos binarios en el servidor. Si crea una clase de tarea, puede establecer la variable protegida $local como true.

Conclusion

El proceso de implementación es una parte importante del ciclo de vida de una aplicación. Herramientas como Rocketeer le permiten con facilidad hacer de este un asunto sin complicaciones. Esto es especialmente cierto cuando se utiliza para una aplicación PHP, ya que se integra muy bien con él.

Escribir un tutorial introductorio a Rocketeer resultó ser una tarea difícil. La herramienta es tan flexible que dibujar las líneas sobre dónde parar no es fácil. Espero tener todas las posibilidades en el uso de esta herramienta y cómo puede beneficiarse usted y su aplicación. Si desea profundizar, sugiero leer la documentación completa. Hay mucho más en la herramienta de lo que podría cubrir en este artículo.

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.