Простые сценарии миграции базы данных на этапе CI/CD

Я видел много выдающихся работ высокого уровня в нескольких работах, представленных на конкурс авторов DevOps . Однако мало кто задумывается о том, как поддерживать актуальность базы данных на общих резервных серверах (разработчиках, сцене, продуктах и т. д.), работая каждый день. Эта статья предназначена для начинающих разработчиков. Я использовал Spring в качестве примера, чтобы продемонстрировать простой метод внедрения системы миграции базы данных в процесс CI/CD.

Для этого развертывания нам потребуются инструменты Liquibase и GitLab CI/CD. Предположим на мгновение, что база данных запущена и работает. Я буду использовать PostgreSQL.

GitLab CI/CD

Если у вас уже развернут GitLab, вы можете полностью пропустить этот шаг.

Для развертывания Gitlab мы будем использовать метод Docker. Важно отметить, что нам нужно создать переменную $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

Следующий шаг — установка и настройка бегунков.

Если у вас уже есть давно работающий проект и все давно настроено, то создание нового раннера можно пропустить.

Создание раннера я покажу на примере версии 16.4.1. Все, что после 17.0 идет на регистрацию с использованием RUNNER_AUTHENTICATION_TOKEN , но подход близок к текущему.

Во-первых, вам нужно установить исходный код бегуна. Чтобы установить его через bash на развернутый GitLab, этот пример поможет вам установить runner для систем на базе Apple Silicon (другую ОС вы можете найти здесь):

 # 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

Теперь мы можем создать сам бегун через пользовательский интерфейс, нажав кнопку New project runner .

У каждого бегуна может быть платформа, теги, отображаемые синим цветом, и другие конфигурации среды выполнения. Когда нам нужно задать возможность запуска команд из программы, пригодятся теги. Все остальное нас пока не интересует.

После нажатия кнопки Create runner остается только зарегистрировать своего бегуна.

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

Ликвибаза

Liquibase — бесплатная платформа с открытым исходным кодом для управления миграцией баз данных. Таким образом, Liquibase позволяет вам описывать процедуры свертывания и отката с использованием файлов набора изменений. Сами сценарии могут представлять собой обычные команды SQL, а также независимые от базы данных описания изменений, которые будут преобразованы в сценарий, адаптированный к вашей базе данных. Список поддерживаемых баз данных доступен здесь .

Я покажу вам способ выполнения миграции в приложении Spring. Это необходимо для того, чтобы можно было контролировать выполнение всех наборов изменений как отдельный шаг.

Проект

Чтобы быстро разработать приложение Spring, перейдите сюда .

Давайте теперь быстро создадим application.yml. Особое внимание следует уделить включенным опциям и опциям журнала изменений. Первый вариант включает и отключает Liquibase на уровне приложения, а второй задает путь к журналу изменений.

 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

Что делать с переменными?

В нашем проекте мы используем Kubernetes, и эти параметры должны задаваться самими командами при построении приложения с использованием файлов значений, предварительно настроенных для различных схем.

 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"

Вернемся к настройке. На мой взгляд, создание полностью самодостаточных приложений, готовых к немедленному развертыванию, является разумной практикой. Чтобы продолжить создание отдельного этапа в CI/CD, давайте создадим файл миграции. Мы можем использовать разные инструменты для разных команд, и с этим файлом мы не ограничены системой миграции.

 #!/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

Все возможные команды можно найти в документации Liquibase . Теперь нам нужен только update , который позволяет нам обновиться до текущей версии из файла Changelog-master.xml.

Следующим шагом является создание файла .gitlab-ci.yml в корне проекта, содержащего инструкции о том, как продолжить процесс CI/CD.

Во-первых, хотелось бы обратить внимание на встроенный компоновщик файла gitlab-ci.yml , который можно найти в проекте по относительному пути ci/lint . Прежде чем прошивать конфигурацию, предлагаю воспользоваться ею. Также предполагается, что вы умеете работать с файлами YAML.

Этапы и задания

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

Тег migration указывает нашему ранее созданному бегуну отреагировать на эту задачу и запустить сценарии в разделе script . Строка stage определяет этап, к которому принадлежит это задание. При необходимости один и тот же бегун может работать сразу над несколькими проектами. Блок окружающей среды относится к окружающей среде . Это тип информационной панели, на которой вы можете просматривать состояние ваших стендов (разработка, предварительная разработка, разработка и т. д.) и предпринимать такие действия, как развертывание вручную. Кроме того, можно настроить переменные, привязанные к среде; однако у меня не было возможности протестировать эту премиум-функцию.

Отклонение мер с ошибками

Вы можете остановить соответствующее объединение, если что-то пойдет не так с процедурой развертывания. В частности, это полезно, если тесты интегрированы в CI/CD как самостоятельный этап. Хотя в нашем примере Liquibase не имеет тестов, он может работать неправильно, например, если введены неправильные пути к файлам.

Последние штрихи

Давайте создадим файл миграции и включим его. Для этого нам нужно создать файл changelog-master.xml в качестве точки ввода.

 <?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;

Для описания миграции вы можете использовать различные форматы XML, YAML или JSON, но, на мой вкус, проще всего читать SQL.

Пробуем выполнить и все успешно. Проверьте нашу базу данных и посмотрите запись в журнале datachangelog.

Заключение

В этой статье мы обсудили, как самостоятельно развернуть GitLab, загрузить и настроить раннеры и, что самое важное, интегрировать систему миграции баз данных в ваш процесс CI/CD. Я надеюсь, что это руководство поможет вам применить это руководство на практике.