Как стать автором
Обновить
890.82
OTUS
Цифровые навыки от ведущих экспертов

Автоматизация миграций баз данных с помощью контейнеров и Git

Время на прочтение4 мин
Количество просмотров4.1K
Автор оригинала: Paul Stanton

В преддверии старта курса "Инфраструктурная платформа на основе Kubernetes" приглашаем всех желающих на бесплатный демо-урок, в рамках которого одним глазком посмотрим на устройство kubernetes, немного поговорим о том, как взаимодействуют компоненты, разберем основные подходы к обеспечению безопасности кластера, поговорим об ограничениях ресурсов, сетевых политиках, привилегиях запуска и т. д.


Реализуем доставку кастомных миграций баз данных с помощью файлов манифестов сценариев

Управление миграциями баз данных для нескольких сред и команд может быть достаточно сложной задачей. В этой статье описывается, как сочетание Git, контейнеров и клонов баз данных используется для реализации доставки в среды разработки, тестирования и стейджинга за считанные секунды.

Хотя Git и так часто используется в сочетании с контейнерами баз данных, описанный здесь подход все же вводит два новых элемента. Вместо того, чтобы воспроизводить базы данных из бекапов или создавать из источника данных, мы клонируем идентичные безопасные среды производственных баз данных и доставляем их в течении секунд. Клоны баз данных доступны для записи и позволяют легко внедрять маскирование данных и синтетические тестовые данные. Второй элемент - это файл манифеста сценариев, используемый при создании и применении персонализированных сценариев миграции.

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

Эта статья берет за основу SQL Server, но эти методы также поддерживаются Postgres и MySQL.

Компоненты

Можно использовать любой публичный или приватный репозиторий Git, включая GitHub, GitLab или Git на частной виртуальной машине.

Образ базы данных - это набор производственных баз данных, воссозданных из бекапов или файлов баз данных с применением сценариев маскирования данных. Для поддержки конкретных сред разработки, тестирования и стейджинга пользователи могут указывать сценарии из веток и репозиториев Git. Когда у вас есть резервные копии лога транзакций, образ можно обновлять инкрементно.

Файл манифеста сценариев - это текстовый файл со списком запускаемых сценариев.

Контейнер базы данных - это инстанс базы данных, предоставляющий сервисы для работы с базой данных.

Клон баз данных - это база данных с возможностью записи, создаваемая из образа, которая доставляется за секунды и требует для этого всего 40 МБ дискового пространства.

 

Создание образа базы данных

Dockerfile включает еще один путь к бэкапам производственных баз данных и сценариям маскирования данных. Во время выполнения репозиторий Git клонируется в файловую систему контейнера со специальным чекаутом ветки. Также во время выполнения пользователи или конвейер предоставляют две переменные среды, выделенные красным, указывая ветку Git и файл манифеста сценариев (подробнее об этом ниже). Последний шаг включает команду PowerShell, которая создает объединенный сценарий «all.sql», отражающий порядок сценариев в файле манифеста, который затем и запускается.

Образ создается с помощью стандартной docker-команды:

>docker build -t microservice1 c:\path\to\dockerfile

Манифестные файлы

Манифест - это текстовый файл, в котором перечислены пути к сценариям относительно корня репозитория Git в том порядке, в котором они должны выполняться. Можно использовать несколько манифестных файлов. Один манифест может перечислять сценарии обновления, а второй включать сценарии обновления, за которыми следуют сценарии отката. Файл manifest.txt может включать:

Среды разработки и тестирования

Разработка начинается с доставки контейнера SQL Server с клоном производственной базы данных, но без применения гитовых сценариев. По мере выполнения работы сценарии фиксируются в репозитории, создается манифестный файл и фиксируется список сценариев в том порядке, в котором они должны выполняться.

Пользователи и конвейеры предоставляют среды с помощью docker-команд или restful API. Вывод лога сценариев доступен с помощью Rest API. Среды используются для модульного тестирования SQL скриптов и приложений с определенными файлами манифеста и ветками Git. Доставка включает вводимые пользователем данные, выделенные красным.

Тестирование релизных веток

По мере выполнения задач рабочие ветки мержатся в релизную ветку с обновленными манифестными файлами. Теперь тестировщики и DevOps конвейеры могут доставлять среды тестирования релизов с использованием одного и того же образа базы данных, ссылаясь на релизную ветку и обновленный файл манифеста. Миграция базы данных с помощью Git поддерживает полный жизненный цикл разработки/тестирования с согласованной средой баз данных.

Управление данными и безопасность

Этот подход не только упрощает и автоматизирует разработку и тестирование баз данных, он также создает безопасное централизованное хранилище данных. Там, где организации встряют в борьбу с разрастанием виртуальных машин и инстансов, контейнеры позволяют консолидироваться на контейнерном хосте. Один образ базы данных легко поддерживает одновременно от 20 до 50 сред, что потенциально снижает объем хранилища до 95%.


Записаться на бесплатный демо-урок.

Теги:
Хабы:
Всего голосов 10: ↑5 и ↓50
Комментарии2

Публикации

Информация

Сайт
otus.ru
Дата регистрации
Дата основания
Численность
101–200 человек
Местоположение
Россия
Представитель
OTUS