Scripts simples de migración de bases de datos en su paso CI/CD

He visto muchos trabajos sobresalientes y de alto nivel en varias de las presentaciones al Concurso de redacción de DevOps . Sin embargo, pocas personas consideran cómo mantener actualizada la base de datos en los recursos comunes (desarrollo, etapa, producción, etc.) mientras trabajan todos los días. Este artículo está destinado a desarrolladores novatos. Utilicé Spring como ejemplo para demostrar una técnica sencilla para introducir un sistema de migración de bases de datos en el proceso CI/CD.

Necesitaremos las herramientas Liquibase y GitLab CI/CD para esta implementación. Supongamos por el momento que una base de datos está en funcionamiento. Usaré PostgreSQL.

CI/CD de GitLab

Si ya tienes implementado GitLab, puedes omitir este paso por completo.

Para implementar Gitlab, usaremos el método Docker. Es importante tener en cuenta que necesitamos crear la variable $GITLAB_HOME .

 sudo docker run --detach \ --hostname gitlab.devopscontest.com \ --publish 443:443 --publish 80:80 --publish 22:22 \ --name gitlab \ --restart always \ --volume $GITLAB_HOME/config:/etc/gitlab \ --volume $GITLAB_HOME/logs:/var/log/gitlab \ --volume $GITLAB_HOME/data:/var/opt/gitlab \ --shm-size 256m \ gitlab/gitlab-ee:16.4.1-ee.0

El siguiente paso es instalar y configurar los corredores.

Si ya tiene un proyecto de larga duración y todo ha estado configurado durante mucho tiempo, puede omitir la creación de un nuevo ejecutor.

Mostraré la creación de un corredor usando la versión 16.4.1 como ejemplo. Todo lo posterior a 17.0 se registra mediante RUNNER_AUTHENTICATION_TOKEN , pero el enfoque es cercano al actual.

Primero, necesitas instalar la fuente del corredor. Para instalarlo a través de bash en su GitLab implementado, este ejemplo le ayuda a instalar runner para sistemas basados en Apple Silicon (puede encontrar otros sistemas operativos aquí):

 # Download the binary for your system sudo curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64 # Give it permission to execute sudo chmod +x /usr/local/bin/gitlab-runner # Create a GitLab Runner user sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash # Install and run as a service sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner sudo gitlab-runner start

Ahora podemos crear el corredor a través de la interfaz de usuario haciendo clic en el botón New project runner .

Cada corredor puede tener una plataforma, etiquetas que aparecen en azul y otras configuraciones de tiempo de ejecución. Cuando necesitamos configurar la posibilidad de ejecutar comandos desde el programa, las etiquetas son útiles. Por el momento, todo lo demás no nos interesa.

Después de hacer clic en Create runner , lo único que queda por hacer es registrar a tu corredor.

 # Command to register runner gitlab-runner register --url https://gitlab.devopscontest.com/ --registration-token glrt-bjyfCR5pM5wypQDdfSqU

Liquibase

Liquibase es una plataforma gratuita y de código abierto para gestionar migraciones de bases de datos. En resumen, Liquibase le permite describir procedimientos de consolidación y reversión utilizando archivos changset. Los scripts en sí pueden ser comandos SQL convencionales, así como descripciones de modificaciones independientes de la base de datos que se convertirán en un script adaptado a su base de datos. La lista de bases de datos compatibles está disponible aquí .

Le mostraré una forma de realizar migraciones en una aplicación Spring. Esto es necesario para poder controlar la ejecución de todos los conjuntos de cambios como un paso independiente.

Proyecto

Para desarrollar rápidamente una aplicación Spring, vaya aquí .

Ahora creemos rápidamente application.yml. Se debe prestar especial atención a las opciones habilitadas y de registro de cambios. La primera opción habilita y deshabilita Liquibase a nivel de aplicación, mientras que la segunda establece la ruta al registro de cambios.

 server: port: 80 spring: datasource: username: ${DB_USERNAME} password: ${DB_PASSWORD} url: ${DB_HOST} liquibase: enabled: true change-log: classpath:db/changelog/db.changelog-master.xml

¿Qué hacer con las variables?

Usamos Kubernetes en nuestro proyecto, y estos parámetros deben ser establecidos por los propios equipos al construir la aplicación utilizando archivos de valores que están preconfigurados para varios esquemas.

 env: - name: SPRING_PROFILES_ACTIVE value: "dev" - name: DB_HOST value: "jdbc:postgresql://127.0.0.1:5436/your_db" - name: DB_USERNAME value: "user" - name: DB_PASSWORD value: "pass"

Volvamos a la personalización. Crear aplicaciones completamente autosuficientes que estén preparadas para su implementación inmediata es, en mi opinión, una práctica inteligente. Para seguir construyendo una etapa distinta en CI/CD, construyamos un archivo de migración. Podemos usar diferentes herramientas para diferentes equipos y no estamos restringidos al sistema de migración con este archivo.

 #!/bin/sh cd /opt/app /opt/app/liquibase \ --changeLogFile=./db/changelog/changelog-master.xml \ --url="$DB_HOST" \ --username="$DB_USERNAME" \ --password="$DB_PASSWORD" \ --logLevel=info \ --headless=true \ update

Todos los comandos posibles se pueden encontrar en la documentación de Liquibase . Ahora sólo nos falta update , lo que nos permite actualizar a la versión actual desde el archivo changelog-master.xml.

El siguiente paso es crear un archivo.gitlab-ci.yml en la raíz del proyecto que contenga instrucciones sobre cómo proceder con el proceso de CI/CD.

En primer lugar, me gustaría llamar la atención sobre el vinculador integrado para el archivo gitlab-ci.yml , que se puede encontrar en el proyecto en la ruta relativa ci/lint . Antes de cambiar la configuración, sugiero usarla. También se supone que sabes cómo trabajar con archivos YAML.

Etapas y trabajos

 stages: - publish - dev .migrate: stage: publish allow_failure: true script: - ./migrate.sh Migrate: tags: - migration extends: .migrate environment: name: dev

La etiqueta migration le indica a nuestro ejecutor generado previamente que reaccione a esta tarea y ejecute scripts en la sección script . La cadena stage identifica la etapa a la que pertenece este trabajo. Si es necesario, el mismo corredor puede trabajar en varios proyectos a la vez. El bloque de entorno se refiere al medio ambiente . Este es un tipo de panel donde puede ver el estado de sus stands (desarrollo, preproducción, producción, etc.) y realizar acciones como implementaciones manuales. Además, se pueden configurar variables vinculadas al entorno; sin embargo, no he tenido la oportunidad de probar esta función premium.

Rechazo de medidas con errores

Puede detener la fusión correspondiente en caso de que algo salga mal con el procedimiento de implementación. En particular, esto es útil si las pruebas se integran en CI/CD como una fase independiente. Aunque Liquibase no tiene pruebas en nuestro ejemplo, puede funcionar mal si, por ejemplo, se ingresan rutas de archivos incorrectas.

Toques finales

Creemos un archivo de migración y habilítelo. Para hacer esto necesitamos crear el archivo changelog-master.xml como punto de entrada.

 <?xml version="1.1" encoding="UTF-8" standalone="no"?> <databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog" xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext" xmlns:pro="http://www.liquibase.org/xml/ns/pro" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog-ext http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd http://www.liquibase.org/xml/ns/pro http://www.liquibase.org/xml/ns/pro/liquibase-pro-4.1.xsd http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-4.1.xsd"> <include file="db/changelog/changeset-202310151300-create-table.sql"/> </databaseChangeLog>

 --liquibase formatted sql --changeset a.tyryshkin:create-table create table if not exists table ( id bigserial primary key, name varchar(255) ); create sequence if not exists table_id_seq;

Puede utilizar diferentes formatos XML, YAML o JSON para describir las migraciones, pero SQL es el más fácil de leer para mi gusto.

Intentamos ejecutar y todo es exitoso. Consulte nuestra base de datos y vea la entrada en el registro de cambios de la base de datos.

Conclusión

En este artículo, analizamos cómo implementar GitLab usted mismo, descargar y configurar ejecutores y, lo más importante, integrar un sistema de migración de bases de datos en su proceso de CI/CD. Espero que esta guía le ayude a ponerla en práctica.