GitLab CI/CD: automatización de pruebas y despliegue de aplicaciones

Hace tiempo que la gente me pide que prepare un tutorial sobre cómo usar CI/CD en GitLab. Así que he preparado un proyecto básico de ejemplo y aquí tienes un tutorial sobre GitLab y su CI/CD.

Cómo conseguir que CI/CD funcione en GitLab

Este tutorial enumera los pasos que debes completar para poner en marcha el desarrollo y despliegue automático de tu proyecto de software. Esta demo está centrada en GitLab, pero puedes implementar de forma similar en otras soluciones como GitHub action.

Qué necesitas tener, proporcionar y configurar:

• Utilizar GitLab.
.
• Tener runnners.
• Configurar un proceso de desarrollo para que se utilicen contenedores. Por ejemplo, Docker.
.
• Dividir las aplicaciones para que cada servicio se ejecute en un contenedor independiente.
• Haz pruebas. A continuación, configure el inicio automático.
.
• Tener un VPS para ejecutar la aplicación.
.
• Configurar nginx en el VPS. Crear un usuario y configurar el acceso ssh al servidor.
• Diseñar una imagen build.
• Diseñar un proceso de creación de imágenes para producción y configurar la automatización de la creación de imágenes en gitlab.
.
• Establezca permisos para el despliegue.
• Ejecutar la compilación y enviar la imagen al registro.
• Ejecutar el despliegue en gitlab.
• Ejecutar deploy en gitlab - la acción se ejecutará al fusionar a la rama master/principal.

Plazos

Para usar algo hay que entenderlo. Por eso con cualquier tecnología nueva hay que explicar los términos.

¿Qué es un corredor?

Un runner es una instancia de GitLab Runner que te permite ejecutar diferentes tipos de tareas como construir, probar y desplegar un proyecto. GitLab Runner forma parte de GitLab y te permite automatizar operaciones comunes de desarrollo de software.

Si usas gitlab.com por defecto tienes runners disponibles. Si está ejecutando GitLab en su propia infraestructura, tendrá que proporcionar los ejecutores de Gitlab usted mismo. Es decir, aprovisionar los servidores, instalar el runner y configurar la conexión a GitLab.

Detalles cómo instalar el runner de GitLab.

A continuación, el runner lanza contenedores, según la imagen que elijas, y ejecuta el trabajo específico: el trabajo que quieres ejecutar.

Pipeline, Job

Un Pipeline es un conjunto de pasos que se ejecutan para conseguir un objetivo concreto, como desplegar una aplicación en producción. Un pipeline suele contener varias fases (etapas) que incluyen diferentes pasos como build, test y deploy. Cada etapa puede contener uno o más trabajos. Los pipelines pueden activarse automáticamente cada vez que se produce un cambio en el código o en función de una programación específica.

Un Job es una tarea específica que se ejecuta dentro de un pipeline. Cada trabajo es una unidad de trabajo que se puede ejecutar y supervisar de forma independiente. Los trabajos pueden dividirse en diferentes fases del pipeline. Cada trabajo puede contener scripts o comandos que necesitan ser ejecutados, como ejecutar pruebas, construir código o desplegar una aplicación.

Un pipeline consta de una o más etapas. Una etapa puede consistir en uno o más trabajos.
Las etapas se ejecutan en secuencia. Múltiples trabajos en una etapa se ejecutan paralelamente.

¿Qué son los registros de contenedores docker?

Docker Container Registry (también conocido como Docker Registry) es un servicio para almacenar y gestionar imágenes Docker. Es un repositorio central donde puedes almacenar tus propias imágenes Docker y compartirlas con otras personas de tu organización o públicamente en Internet.

GitLab incluye registros de Contenedores. Cuando haces una build en GitLab, no es una solución fácil usar GitLab como repositorio para tus imágenes docker.

También puedes utilizar DockerHub. También escribí un artículo Cómo subir una imagen docker al Docker Registry en Docker Hub.

¿Cómo desplegar una aplicación?

Normalmente hay dos formas de desplegar una aplicación:

• Ayudar al contenedor y realizar un build, push y pull del panel con la nueva versión de la aplicación.
.
• Clásicamente, ejecutar algún script de despliegue que realice un git pull y otras acciones.
.

Operar sin contenedores

Despliega tu aplicación dependiendo de cómo hayas configurado tu entorno para ejecutar la aplicación.
No es necesario tener la aplicación en contenedores para ejecutar la aplicación en absoluto. Incluso es posible ejecutar múltiples aplicaciones PHP en un único servidor, incluyendo diferentes versiones de PHP, y mantener las aplicaciones separadas entre sí, garantizando así la seguridad básica. Por supuesto, es necesario saber cómo servidor web Linux para instalar.

Para desplegarlo, puedes utilizar, por ejemplo, la herramienta Deployer. O puedes escribir tu propio script.

Despliegue de aplicaciones en docker

Si va a ejecutar la aplicación en un contenedor, el despliegue sólo consiste en descargar y nueva imagen y soltar el contenedor de la misma. Normalmente también hay que ejecutar algunos scripts de migración. Recuerda mantener tus datos en volumen para que tus datos sean persistentes.

Ejemplo sencillo de GitLab CI

Un ejemplo de un simple archivo .gitlab-ci.yml para verificar que CI funciona en Gitlab podría tener este aspecto:

etapas:
  - build
  - test
  - desplegar

construir_proyecto:
  stage: build
  script:
    - echo "Construyendo el proyecto..."

run_tests:
  stage: test
  script:
    - echo "Ejecutando pruebas..."

deploy_to_production:
  stage: deploy
  script:
    - echo "Desplegando a producción..."
  entorno:
    nombre: producción
    url: https://your-production-url.com

Confirmar el archivo en el proyecto y luego la tubería debe ejecutar.

GitLab CI y variables

Para funcionar, necesitarás pasar variables a los trabajos del pipeline. En GitLab CI/CD, puedes pasar variables de varias maneras diferentes.

Recuerda tener en cuenta la seguridad de la información sensible y las variables. En el caso de datos sensibles, es una buena idea utilizar las características de GitLab para proteger esos datos. Por ejemplo, sólo permitir su uso en situaciones privilegiadas.

Definición de variables en la configuración del repositorio

Para almacenar variables de entorno (ENVs) y claves de acceso de forma segura en GitLab, existen "variables" y "variables de entorno CI/CD", que se pueden configurar en la propia interfaz de GitLab y no forman parte del código fuente de tu aplicación. Esto ayuda a proteger la información sensible y permite su uso dentro de la tubería CI/CD.

En la propia interfaz de GitLab (en la configuración del repositorio), puedes definir variables de entorno que serán accesibles en tu .gitlab-ci.yml. Estos ajustes pueden ser genéricos para todo el proyecto o pueden ser específicos para cada rama, etiqueta.

Para añadir variables a tu repositorio de GitLab, ve a configuración del proyecto -> "Configuración" -> "CI/CD" -> "Variables". Aquí puedes definir variables de diferentes tipos (como variables de entorno, variables de tipo de archivo, y más).
Estas variables se pueden utilizar dentro de su tubería CI/CD utilizando la sintaxis clásica bash por ejemplo $VARIABLE_NAME.

Por ejemplo, puede pasar una clave ssh de esta manera para que luego pueda conectarse a través de ssh al servidor al desplegar su aplicación.

Definiendo variables directamente en .gitlab-ci.yml

Puedes pasar variables directamente en el archivo de configuración .gitlab-ci.yml.

Definición de variables directamente en el archivo de configuración.gitlab-ci.yml.

yaml

etapas:
  - build

variables:
  MI_VARIABLE: "valor"

construir_proyecto:
  stage: build
  script:
    - echo $MY_VARIABLE

En este caso, la variable MY_VARIABLE se define directamente en el archivo .gitlab-ci.yml y se utiliza en la tarea build_project.

Pasar variables a través de scripts

Si necesitas cambiar dinámicamente el valor de las variables dependiendo de las condiciones, puedes pasarlas a través de scripts en el pipeline CI/CD

.
yaml

Etapas:
  - build

construir_proyecto:
  stage: build
  script:
    - export MY_VARIABLE="valor"
    - echo $MY_VARIABLE

Este ejemplo muestra el uso de export dentro de un script para establecer la variable MY_VARIABLE.

Elegir otra imagen en GitLab CI

Se puede definir globalmente qué imagen docker usar. Pero en diferentes trabajos estarás haciendo diferentes salidas, por lo que querrás usar diferentes imágenes.
Por ejemplo, si necesitas un cliente ssh para conectarte a un servidor usando ssh, necesitarás una imagen donde esté el cliente ssh. Para una imagen build docker necesitarás una imagen donde estén las utilidades para la imagen build docker.

La definición de que se va a utilizar la imagen docker:19.03.13.

build_image:
  before_script:
    - ''
  only:
    - main
  stage: build
  imagen: docker:19.03.13
  servicios:

También define que este trabajo sólo se ejecutará cuando commit to main.

Conexión vía ssh

Al desplegar la aplicación, probablemente necesitará conectarse al servidor, idealmente usando ssh. Cómo hacerlo? En primer lugar, la mejor opción es utilizar claves SSH. Añade el contenido de tu clave privada SSH como variable secreta a GitLab. Esto asegurará que la clave no sea visible públicamente.

Para tener una aplicación que nos permita loguearnos con ssh, utilizamos la imagen kroniak/ssh-client, que contiene el cliente ssh. A continuación, preparamos el entorno para que la configuración para ssh sea la que necesitamos, incluyendo la clave ssh. Esto permite conectarse al servidor de forma segura y cómoda. Y luego sólo hay que ejecutar los comandos en el servidor....

Configura la conexión usando la clave SSH en .gitlab-ci.yml:

deploy:
  before_script:
    - ''
  servicios: []
  stage: deploy
  imagen: kroniak/ssh-client
  sólo
    - main
  script:
    - mkdir ~/.ssh/
    - echo "$SSH_KEY" | tr -d '\r' > ~/.ssh/id_rsa
    - echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config
    - chmod 600 ~/.ssh/id_rsa
    - export SSH_AUTH_SOCK && export SSH_ASKPASS=ssh-askpass && eval `ssh-agent -s` && ssh-add ~/.ssh/id_rsa
    - "scp docker-compose.prod.yml user@test3.xeres.cz:app"

En este caso, el archivo docker-compose.prod.yml se copia en el servidor a través de ssh.

Ten en cuenta que almacenar una clave privada en la tubería CI/CD puede ser arriesgado y debe utilizarse con precaución. Se recomienda utilizar claves especiales con permisos limitados y crear una cuenta de usuario con privilegios limitados. Dicha cuenta sólo se utilizará para fines de CI/CD.

Desplegar un contenedor Docker

Los pasos para desplegar un contenedor Docker a través de GitLab CI/CD en un servidor son:

1. Crear una imagen Docker: Asegúrate de tener un Dockerfile que describa tu aplicación y su entorno. Crea una imagen Docker usando el comando docker build. Por ejemplo: docker build -t tu-nombre-de-imagen:etiqueta.
2. Docker build -t tu-nombre-de-imagen:etiqueta.
3. Pulsar la imagen en el registro: Si está utilizando registros Docker externos (por ejemplo, Docker Hub), inicie sesión utilizando el comando docker login.
4. .
5. En el servidor, descargue una nueva versión de la imagen, apague el contenedor antiguo e inicie el contenedor desde la nueva imagen.
.

El siguiente ejemplo muestra los pasos de construir, iniciar sesión en el registro y empujar la imagen.

build_image:
  before_script:
    - ''
  only:
    - main
  stage: build
  imagen: docker:19.03.13
  servicios:
    - docker:19.03.13-dind
  script:
    - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN registry.gitlab.com
    - docker build ./ -t registry.gitlab.com/$CI_PROJECT_NAMESPACE/$CI_PROJECT_NAME:app
    - docker push registry.gitlab.com/josef.jebavy/example-symfony-devstack-cicd:app

	

Después de añadir y empujar los cambios de la aplicación al repositorio, la tubería CI/CD se ejecutará y construirá automáticamente una imagen docker con la nueva versión de la aplicación y la empujará al registro.
Este trabajo utiliza docker:19.03.13 para la imagen de construcción, que contiene herramientas para construir imágenes docker.

El siguiente ejemplo muestra los pasos de iniciar sesión en el servidor mediante ssh, copiar la nueva configuración docker-compose.prod.yml, descargar la nueva imagen con la nueva aplicación. Apagar el contenedor antiguo, arrancar el contenedor desde la nueva imagen y ejecutar los scripts de migración.

Desplegar:
  before_script:
    - ''
  servicios: []
  stage: deploy
  imagen: kroniak/ssh-client
  sólo
    - main
  script:
    - mkdir ~/.ssh/
    - echo "$SSH_KEY" | tr -d '\r' > ~/.ssh/id_rsa
    - echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config
    - chmod 600 ~/.ssh/id_rsa
    - export SSH_AUTH_SOCK && export SSH_ASKPASS=ssh-askpass && eval `ssh-agent -s` && ssh-add ~/.ssh/id_rsa
    - "scp docker-compose.prod.yml user@test3.xeres.cz:app"
    - ssh user@test3.xeres.cz "docker login -u gitlab-ci-token -p $CI_JOB_TOKEN registry.gitlab.com && docker pull registry.gitlab.com/josef.jebavy/example-symfony-devstack-cicd:app"
    - ssh user@test3.xeres.cz "cd app && docker compose -f docker-compose.prod.yml stop web && docker compose -f docker-compose.prod.yml rm web -f && docker compose -f docker-compose.prod.yml up -d "
    - ssh user@test3.xeres.cz "cd app && docker exec -d test-app-web bin/console doctrine:database:create --if-not-exists && docker exec -d test-app-web php bin/console doctrine:migrations:migrate --no-interaction"

Ejemplo de CI de GitLab

Para ver un ejemplo completo de una configuración de GitLab CI donde se automatizan pruebas, se construye la aplicación y se despliega a producción, haz clic aquí https://gitlab.com/josef.jebavy/example-symfony-devstack-cicd/. La demo también incluye la configuración del servidor, que puedes hacer automáticamente usando Ansible. Si haces un fork de mi proyecto, también puedes probarlo tú mismo y desplegar en tu servidor.

Video tutorial

Aquí tienes un videotutorial de ejemplo detallado paso a paso sobre cómo hacer funcionar GitLab CI:

Funcionamiento de un proyecto en un contenedor docker

Cómo ejecutar un proyecto en contenedores docker:

Pruebas automáticas

GitLab CI/CD y pruebas automáticas:

Línea de producción

Configuración de Gitlab CI/CD y pipeline en gitlab-ci.yml:

Desplegar la aplicación en el servidor

Configuración de GitLab CI/CD para desplegar la aplicación en el servidor:
.

Configuración del servidor

Configuración del servidor GitLab CI/CD para ejecutar la aplicación en un contenedor y configuración para el despliegue automático mediante GitLab CI:

Automatización

La automatización hará gran parte del trabajo por ti, ahorrándote tiempo valioso. También reducirás el error humano. Como mínimo, te recomiendo tener pruebas y ejecutarlas automáticamente cuando hagas commit en un repositorio git. De esta forma con cada modificación del código fuente te asegurarás de probar tu aplicación.

Enlaces

• https://bogomolov.tech/gitlab-ci-cd-symfony/
• https://medium.com/@zakariae/setting-up-symfony-continuous-deployment-using-rancher-274838fcf632