Usando Laravel con canalizaciones de GitLab
jigadmin

Como se menciona en un artículo anterior, Laravel is a popular PHP development platform that is well known for its clean design and the active user community. Gitlab is one of the most popular source code repository and collaborative software development platforms.   This article outlines how to use Gitlab’s pipelines with Laravel projects.

Primero deberá declarar las etapas principales del proceso de canalización, como: compilación, prueba e implementación.

Construir (preparación y configuración)

The instructions below assume that you have docker installed and understand how it works with Gitlab.  If you are unsure, take a look at our blog on configurando la ventana acoplable.

Los pasos para la preparación y configuración son:

Configurar una imagen de contenedor Docker

GitLab CI/CD (https://docs.gitlab.com/ee/ci/) permite utilizar Docker (https://www.docker.com/) para manejar el proceso de prueba e implementación de una aplicación, por lo que tendrás que seleccionar una imagen base de Docker para usar o crear una.Hay muchas imágenes de Docker disponibles para aplicaciones PHP/Laravel.Por ejemplo, la imagen oficial de PHP Docker (https://hub.docker.com/_/php).

Una vez que se crea un contenedor y se coloca un Dockerfile en el directorio raíz de su aplicación, deberá configurar GitLab Container Registry, crear una imagen y colocarla allí para su uso posterior.

Para configurar el Registro de contenedores en el repositorio de su proyecto GitLab, navegue hasta la pestaña Registro o, si no puede encontrarlo, es posible que deba habilitarlo para su proyecto en Configuración >Generales>Visibilidad, características del proyecto, permisos.

 

Primero deberá iniciar sesión en el registro de GitLab con su nombre de usuario y contraseña de GitLab.Dado que Docker está instalado en nuestra máquina, deberá ejecutar los siguientes comandos:

registro de inicio de sesión de Docker.gitlab.com

Luego puedes crear y enviar tu imagen a GitLab:

docker build -t registro.gitlab.com/<USERNAME>/<IMAGE_NAME>.

docker push registro.gitlab.com/<USERNAME>/<IMAGE_NAME>

Now you can use this image in order to build and test your application with GitLab CI/CD which requires a file called .gitlab-ci.yml created in the  repository’s root starting with the following commands to use the image previously registered:

image: registry.gitlab.com/<USERNAME>/<IMAGE_NAME>:latest

Agregue servicios adicionales a su canal de GitLab.

El enfoque de agregar múltiples servicios a su proceso de GitLab depende de las necesidades específicas de su proyecto y tanto de la palabra clave de servicios como de Docker Compose (https://docs.docker.com/compose/) tienen sus propias ventajas.

La palabra clave servicios es un enfoque más simple que le permite agregar fácilmente una cantidad limitada de servicios a su canal de GitLab.Es adecuado cuando sólo necesita unos pocos servicios simples, como una base de datos o un servidor de caché, y no necesita administrarlos de una manera más compleja.La palabra clave servicios también es una característica incorporada de GitLab y no requiere que instale ninguna herramienta adicional ni escriba ningún archivo de configuración adicional.

Por otro lado, docker-compose proporciona más flexibilidad y funcionalidad en la gestión de múltiples servicios.Le permite definir configuraciones de servicios complejas, como múltiples versiones de un servicio, redes, volúmenes y dependencias.Además, puede administrar fácilmente sus servicios mediante comandos docker-compose, que pueden simplificar la configuración de su canalización.

En general, si tiene una arquitectura de aplicación más compleja y necesita administrar múltiples servicios, usar docker-compose sería un mejor enfoque.Sin embargo, si sólo necesita utilizar unos pocos servicios simples y desea una solución rápida y sencilla, la palabra clave servicios es una opción adecuada.Es importante elegir el enfoque que mejor se adapte a las necesidades de su proyecto.

A continuación se muestra un ejemplo de cómo agregar un servicio MySQL a una canalización de CI/CD de GitLab para una aplicación Laravel usando la palabra clave servicios:

servicios:

  - mysql:latest

variables:

  MYSQL_DATABASE: my_app_db

  MYSQL_ROOT_PASSWORD: ejemplo

  DB_HOST: mysql

  DB_USERNAME: raíz

  DB_PASSWORD: ejemplo

En este ejemplo, utilizamos la palabra clave servicios para especificar la imagen de MySQL Docker que se iniciará junto con la imagen principal.

A continuación, definimos algunas variables de entorno que se utilizan para configurar nuestra aplicación Laravel para conectarse al servicio MySQL.Establecemos la variable MYSQL_DATABASE con el nombre de la base de datos que queremos crear y MYSQL_ROOT_PASSWORD con la contraseña que queremos establecer para el usuario root.También configuramos las variables DB_HOST, DB_USERNAME y DB_PASSWORD para configurar la conexión de la base de datos de Laravel.

Instale las dependencias de la aplicación (paquetes requeridos por Laravel Framework):

Para instalar las dependencias requeridas por el marco Laravel en la canalización de GitLab, puede usar el administrador de paquetes del compositor.He aquí un ejemplo:

guion:

- apt-get update &&apt-get install -y git descomprimir

- curl -sS https://getcomposer.org/installer |php --install-dir=/usr/local/bin --filename=composer

- instalación del compositor --prefer-dist --no-ansi --no-interaction --no-progress

En este ejemplo, primero instalamos algunas dependencias necesarias para ejecutar Composer.Luego descargamos e instalamos el propio compositor.Finalmente, ejecutamos Composer install para instalar las dependencias requeridas por Laravel, usando algunas opciones adicionales para mejorar el rendimiento de la instalación.

Configure el entorno de la aplicación Laravel y genere una clave de entorno:

Para pasar las credenciales de la base de datos al archivo .env de una aplicación Laravel en una canalización de GitLab, puede usar las variables CI/CD de GitLab mencionadas anteriormente para almacenar la información confidencial y luego usarlas en el script de la canalización para actualizar el archivo .env con las credenciales correctas.

Aquí tienes un ejemplo de cómo puedes hacer esto:

En la configuración de su proyecto GitLab, navegue hasta “CI/CD”y “Variables”.Aquí puede agregar variables para las credenciales de su base de datos, como DB_HOST, DB_DATABASE, DB_USERNAME y DB_PASSWORD.

En su archivo .gitlab-ci.yml, agregue un trabajo para actualizar el archivo .env con las credenciales de la base de datos.He aquí un ejemplo:

construir:

etapa: construir

guion:

    - cp .env.ejemplo .env

    - clave artesanal de php: generar

    - sed -i "s/DB_HOST=.*/DB_HOST=${DB_HOST}/" .env

    - sed -i "s/DB_DATABASE=.*/DB_DATABASE=${DB_DATABASE}/" .env

    - sed -i "s/DB_USERNAME=.*/DB_USERNAME=${DB_USERNAME}/" .env

- sed -i "s/DB_PASSWORD=.*/DB_PASSWORD=${DB_PASSWORD}/" .env

En este ejemplo, definimos las credenciales de nuestra base de datos como variables CI/CD.En el trabajo de compilación, copiamos el archivo .env.example para crear un nuevo archivo .env, generamos una nueva clave de aplicación y luego usamos sed para actualizar las credenciales de la base de datos en el archivo .env.

Tenga en cuenta que los comandos sed en el ejemplo reemplazan la línea completa que comienza con DB_HOST=, DB_DATABASE=, DB_USERNAME= o DB_PASSWORD= con el valor correspondiente de las variables CI/CD.Si su archivo .env tiene un formato diferente, es posible que deba ajustar los comandos sed en consecuencia.

Configure la base de datos y ejecute las migraciones:

En una canalización de GitLab, se recomienda crear la base de datos y ejecutar migraciones antes de ejecutar las pruebas e implementar la aplicación.Esto garantiza que el esquema de la base de datos esté actualizado con el código base y que las pruebas se ejecuten con el esquema de la base de datos más reciente.

Los pasos necesarios para crear la base de datos y ejecutar las migraciones pueden variar según los requisitos específicos de su aplicación y las herramientas que esté utilizando.Sin embargo, normalmente, esto implicaría ejecutar los siguientes comandos en su canalización:

  1. Cree la base de datos (si aún no existe):

mysql -u<DB_USERNAME>-p<DB_PASSWORD>-e "CREAR BASE DE DATOS <DB_NAME>"

Nota: Reemplace <DB_USERNAME>, <DB_PASSWORD> y <DB_NAME>con los valores apropiados para su base de datos.

2) Ejecute las migraciones:

php artesanal migrar --force

Puede agregar estos comandos a la sección before_script de su canalización, para que se ejecuten antes que cualquier otro comando en la canalización.

Configurar la caché y los artefactos de GitLab (https://docs.gitlab.com/ee/ci/caching/#cache-vs-artifacts).

GitLab proporciona un mecanismo de almacenamiento en caché que se puede utilizar para acelerar su canalización almacenando en caché archivos y dependencias entre ejecuciones de canalización.También puede utilizar artefactos para pasar datos entre trabajos en la canalización.Por ejemplo:

cache:

caminos:

    - proveedor

En este ejemplo, agregamos el directorio del proveedor a la sección de rutas de la configuración de la caché.Esto almacenará en caché el directorio de proveedores entre ejecuciones de canalización.

En el trabajo de compilación, ejecutamos los mismos pasos de compilación que antes, pero no instalamos dependencias usando Composer porque podemos usar el directorio de proveedores en caché.

Al almacenar en caché el directorio de proveedores, puede acelerar significativamente su canalización y evitar la necesidad de reinstalar dependencias en cada ejecución de canalización.

Una canalización de GitLab ejecuta varios trabajos, etapa por etapa, con la ayuda de código automatizado.Un proceso de integración continua implica construir algo desde cero y probarlo en un entorno de desarrollo.

Prueba (sintaxis y controles de seguridad)

One of the advantages of using a pipeline is the ability to run a series of tests before code is deployed to the main codeline.  Examples include tests for things like unit code functionality, syntax and security.

Existen muchos verificadores de sintaxis, algunos de los que nos gustan son:

Puedes instalarlo usando Composer y tiene un archivo de configuración .php_cs que puedes enviar a tu repositorio.Ejecute php-cs-fixer fix para verificar y solucionar todos los problemas en su repositorio.

Laravel Framework usa StyleCI para verificar automáticamente si hay problemas de estilo de código en nuevas confirmaciones y solicitudes de extracción.Puede notificarle cuando encuentre problemas, enviar correcciones automáticamente a través de solicitudes de extracción y confirmar correcciones automáticamente.Sin embargo, es gratuito sólo para proyectos de código abierto.

Rastreador de código PHP (phpcs) es un verificador de estilo que viene con varios estilos PHP populares como PEAR, PSR2, etc. Puede verificar sangrías, comentarios faltantes, convenciones de nomenclatura, etc. y también incluye phpcbf, un programa que puede solucionar automáticamente algunos problemas.

Detector de desorden PHP (phpmd) comprueba los olores del código: código incómodo, demasiado complicado o no utilizado y se entrega con varias reglas integradas que se pueden habilitar o deshabilitar.

Para ilustrar un ejemplo de cómo configurar un verificador de sintaxis en proceso, usaremos PHP-CS-Fixer:

php-cs-:

etapa: prueba

dependencias:

- composer

guion:

    - ./vendor/bin/php-cs-fixer corrección --config=.php_cs.php --verbose --diff --dry-run

There are also many examples of security checkers available.  Some of the ones we like are:

Es una herramienta de línea de comandos basada en Go que verifica si su aplicación PHP depende de paquetes PHP con vulnerabilidades de seguridad conocidas.Publicado por Fabien Potencier (fabpot), fundador del proyecto Symfony.Utiliza la base de datos de avisos de seguridad detrás de escena (https://github.com/FriendsOfPHP/security-advisories).Este directorio se actualiza diariamente con los CVE más recientes y es un excelente lugar para comenzar a verificar.

Este analizador es un contenedor de phpcs-security-audit, un conjunto de reglas PHP CodeSniffer que encuentra vulnerabilidades y debilidades relacionadas con la seguridad en el código PHP.

To illustrate an example of how to setup a security checker in the pipeline we will use Fabpot’s local-php-security-checker.  This can be integrated into your container and run within your CI environment using the following steps:

# Lanzamientos https://github.com/fabpot/local-php-security-checker/releases

ARG URL="https://github.com/fabpot/local-php-security-checker/releases/download/v2.0.6/local-php-security-checker_2.0.6_linux_amd64"

EJECUTAR apk agregar --no-cache wget

EJECUTAR wget -O local-php-security-checker $URL

EJECUTAR chmod +x ./local-php-security-checker

EJECUTE mv ./local-php-security-checker /usr/local/bin/

guion:

    - verificador-de-seguridad-php-local

Prueba (pruebas unitarias)

Unit Testing is the process of checking small pieces of code to speed your testing strategies.  These unit tests are automated to reduce time for overall testing and improve the reliability of the system.  As code is added to new systems it’s possible to break previously created tasks.  Adding these unit tests to the build process allows programmers to catch errors before they make it into the main codeline.

Ejemplos de marcos de pruebas unitarias son:

PHPStan es una herramienta de análisis estático de PHP que se centra en encontrar errores en su código sin ejecutarlo.Detecta clases enteras de errores incluso antes de escribir pruebas para el código.

PHPUnit es un marco de pruebas unitarias para el lenguaje de programación PHP.Laravel usa PHPUnit para las pruebas de forma predeterminada.

Usaremos tanto Larastan (un contenedor PHPStan para Laravel – https://github.com/nunomaduro/larastan) para realizar análisis estático en los proyectos y PHPUnit para ejecutar las pruebas unitarias:

unidad php:

etapa: prueba

guion:

- phpunit --coverage-text –colors=nunca

- proveedor/bin/phpstan

Implementar (implementación)

La implementación es cuando el código se inserta en la codeína principal y se envía a un servidor de prueba o de producción.Por conveniencia, por ahora solo trabajaremos con el trabajo de puesta en escena, ya que será muy similar al trabajo de producción.

Primero, necesitaremos inicializar una conexión SSH haciendo lo siguiente:

  • Cree un nuevo par de claves SSH localmente en nuestra máquina.
  • Give the public key to our server.
  • Proporcione la clave privada a GitLab usando variables secretas.
  • Utilice esa clave privada en nuestras tuberías.

Una vez hecho esto, podemos implementar la aplicación en el host de prueba.

Hay algunas herramientas de implementación disponibles para gestionar el proceso:

Laravel Envoy es una herramienta para ejecutar tareas comunes que ejecuta en sus servidores remotos.Con la sintaxis estilo Blade, puede configurar fácilmente tareas para implementación, comandos Artisan y más.

Deployer es un paquete PHP que proporciona aprovisionamiento automático de servidores, implementaciones sin tiempo de inactividad, reversión a una versión anterior y recetas listas para usar para los principales marcos y algunas aplicaciones PHP.

Usaremos Deployer:

Primero, necesitamos instalar Deployer:

composer require deployer/deployer:^7.0

A continuación, inicializaremos Deployer y elegiremos la receta del proyecto Laravel que generará automáticamente un archivo de configuración implementar.yaml o implementar.php:

inicio de depósito

Ahora puede revisar el archivo de implementación y cambiar todos los parámetros necesarios para la configuración de su aplicación.

Ya instalamos Deployer, instalamos certificados SSL en el servidor de prueba y creamos el script de implementación, así que finalmente es hora de reunirlo todo y realizar la primera implementación en prueba:

implementación de departamento

Deberías ver una nueva estructura de carpetas en tu host, donde tiene la carpeta de lanzamientos.El implementador sincroniza su código con su servidor, ejecuta sus tareas y luego crea un enlace simbólico que vincula la versión actual con la habilitada.

Si algo sale mal, siempre puedes volver a la versión implementada anteriormente:

reversión de depósito