Я видел много выдающихся работ высокого уровня в нескольких работах, представленных на . Однако мало кто задумывается о том, как поддерживать актуальность базы данных на общих резервных серверах (разработчиках, сцене, продуктах и т. д.), работая каждый день. Эта статья предназначена для начинающих разработчиков. Я использовал Spring в качестве примера, чтобы продемонстрировать простой метод внедрения системы миграции базы данных в процесс CI/CD. конкурс авторов DevOps Для этого развертывания нам потребуются инструменты 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 (другую ОС вы можете найти здесь): https://docs.gitlab.com/runner/install/?embedable=true # 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 позволяет вам описывать процедуры свертывания и отката с использованием файлов набора изменений. Сами сценарии могут представлять собой обычные команды SQL, а также независимые от базы данных описания изменений, которые будут преобразованы в сценарий, адаптированный к вашей базе данных. Список . Liquibase поддерживаемых баз данных доступен здесь Я покажу вам способ выполнения миграции в приложении Spring. Это необходимо для того, чтобы можно было контролировать выполнение всех наборов изменений как отдельный шаг. Проект Чтобы быстро разработать приложение Spring, . перейдите сюда Давайте теперь быстро создадим Особое внимание следует уделить включенным опциям и опциям журнала изменений. Первый вариант включает и отключает Liquibase на уровне приложения, а второй задает путь к журналу изменений. application.yml. 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 Что делать с переменными? Хорошей практикой является размещение их в GitLab, что поможет гибко настраивать приложение между стендами dev/prod. В нашем проекте мы используем 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 Все возможные команды можно найти в . Теперь нам нужен только , который позволяет нам обновиться до текущей версии из файла Changelog-master.xml. документации Liquibase update Следующим шагом является создание файла .gitlab-ci.yml в корне проекта, содержащего инструкции о том, как продолжить процесс CI/CD. Во-первых, хотелось бы обратить файла , который можно найти в проекте по относительному пути . Прежде чем прошивать конфигурацию, предлагаю воспользоваться ею. Также предполагается, что вы умеете работать с файлами YAML. внимание на встроенный компоновщик gitlab-ci.yml ci/lint Этапы и задания 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 не имеет тестов, он может работать неправильно, например, если введены неправильные пути к файлам. Все слияния не будут разрешены, если флажок не установлен после настройки CI/CD. Последние штрихи Давайте создадим файл миграции и включим его. Для этого нам нужно создать файл в качестве точки ввода. changelog-master.xml Для более гибкого управления рекомендуется иметь несколько файлов Changelog.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. Я надеюсь, что это руководство поможет вам применить это руководство на практике.
