Scripts simples de migração de banco de dados na etapa CI/CD

Tenho visto muitos trabalhos excelentes e de alto nível em vários envios para o DevOps Writing Contest . No entanto, poucas pessoas consideram como manter o banco de dados atualizado em standbys comuns (dev, stage, prod, etc.) enquanto trabalham todos os dias. Este artigo é destinado a desenvolvedores iniciantes. Usei Spring como exemplo para demonstrar uma técnica simples para introduzir um sistema de migração de banco de dados no processo de CI/CD.

Exigiremos ferramentas Liquibase e GitLab CI/CD para esta implantação. Suponha por enquanto que um banco de dados está instalado e funcionando. Usarei PostgreSQL.

CI/CD do GitLab

Se você já tem o GitLab implantado, pode pular totalmente esta etapa.

Para implantar o Gitlab, usaremos o método Docker. É importante observar que precisamos criar a variável $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

A próxima etapa é instalar e configurar os executores.

Se você já tem um projeto de longa duração e tudo está configurado há muito tempo, você pode pular a criação de um novo executor.

Mostrarei a criação de um runner usando a versão 16.4.1 como exemplo. Qualquer coisa após 17.0 vai para registro usando RUNNER_AUTHENTICATION_TOKEN , mas a abordagem é próxima da atual.

Primeiro, você precisa instalar a fonte do executor. Para instalá-lo via bash em seu GitLab implantado, este exemplo ajuda como você pode instalar o runner para sistemas baseados em Apple Silicon (outro sistema operacional você pode encontrar aqui):

 # 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

Agora podemos criar o próprio executor por meio da IU clicando no botão New project runner .

Cada executor pode ter uma plataforma, tags que aparecem em azul e outras configurações de tempo de execução. Quando precisamos definir a possibilidade de executar comandos do programa, as tags são úteis. Por enquanto, não estamos interessados em todo o resto.

Depois de clicar em Create runner , a única coisa que falta fazer é cadastrar seu corredor.

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

Liquibase

Liquibase é uma plataforma gratuita e de código aberto para gerenciamento de migrações de banco de dados. Em resumo, o Liquibase permite descrever procedimentos de rollup e rollback usando arquivos changset. Os próprios scripts podem ser comandos SQL convencionais, bem como descrições de modificações independentes do banco de dados que serão transformadas em um script adaptado ao seu banco de dados. A lista de bancos de dados suportados está disponível aqui .

Mostrarei uma maneira de realizar migrações em uma aplicação Spring. Isso é necessário para que você possa controlar a execução de todos os conjuntos de alterações como uma etapa separada.

Projeto

Para desenvolver rapidamente um aplicativo Spring, clique aqui .

Vamos agora criar rapidamente application.yml. Atenção especial deve ser dada às opções ativadas e de registro de alterações. A primeira opção ativa e desativa o Liquibase no nível do aplicativo, enquanto a segunda define o caminho para o changelog.

 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

O que fazer com as variáveis?

Utilizamos Kubernetes em nosso projeto, e esses parâmetros devem ser definidos pelas próprias equipes na construção da aplicação usando arquivos de valor pré-configurados para diversos 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"

Voltemos à personalização. Criar aplicativos totalmente autossuficientes e preparados para implantação imediata é, na minha opinião, uma prática inteligente. Para construir ainda mais um estágio distinto em CI/CD, vamos construir um arquivo de migração. Podemos utilizar ferramentas diferentes para equipes diferentes e não estamos restritos ao sistema de migração com este arquivo.

 #!/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 os comandos possíveis podem ser encontrados na documentação do Liquibase . Agora só precisamos update , que nos permite atualizar para a versão atual a partir do arquivo changelog-master.xml.

A próxima etapa é criar um arquivo.gitlab-ci.yml na raiz do projeto que contém instruções sobre como prosseguir com o processo de CI/CD.

Em primeiro lugar, gostaria de chamar a atenção para o vinculador integrado para o arquivo gitlab-ci.yml , que pode ser encontrado no projeto no caminho relativo ci/lint . Antes de alterar a configuração, sugiro usá-la. Também pressupõe-se que você saiba trabalhar com arquivos YAML.

Etapas e trabalhos

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

A tag migration instrui nosso executor gerado anteriormente a reagir a esta tarefa e executar scripts na seção script . A sequência stage identifica o estágio ao qual este trabalho pertence. Se necessário, o mesmo executor pode trabalhar em vários projetos ao mesmo tempo. O bloco de ambiente refere-se ao ambiente . Este é um tipo de painel onde você pode visualizar o status de seus estandes (desenvolvimento, pré-produção, produção, etc.) e realizar ações como implantações manuais. Além disso, variáveis vinculadas ao ambiente podem ser configuradas; no entanto, não tive a oportunidade de testar esse recurso premium.

Rejeição de medidas com erros

Você pode interromper a mesclagem correspondente caso algo dê errado com o procedimento de implantação. Em particular, isto é útil se os testes forem integrados no CI/CD como uma fase independente. Embora o Liquibase não tenha testes em nosso exemplo, ele pode funcionar mal se forem inseridos caminhos de arquivo incorretos, por exemplo.

Últimos retoques

Vamos criar um arquivo de migração e habilitá-lo. Para fazer isso, precisamos criar o arquivo changelog-master.xml como ponto 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;

Você pode usar diferentes formatos XML, YAML ou JSON para descrever migrações, mas SQL é o mais fácil de ler para meu gosto.

Tentamos executar e tudo dá certo. Verifique nosso banco de dados e veja a entrada no databasechangelog.

Conclusão

Neste artigo, discutimos como implantar o GitLab você mesmo, baixar e configurar executores e, o mais importante, integrar um sistema de migração de banco de dados ao seu processo de CI/CD. Espero que este guia o ajude a colocá-lo em ação.