db-presets

Тулза для работы с пресетами (дампами) PostgreSQL.

Фичи

• Хранит пресеты на Amazon S3 в заархивироанном и зашифрованном виде.
• Позволяет:
  • забирать нужные пресеты с Amazon S3,
  • заливать обратно отредактированные,
  • смотреть список существующих пресетов,
  • создавать новые пресеты и заливать их на Amazon S3.
• Поддерживает блокировку объектов на запись.
• Хранит историю изменений объекта.
• Логирует действия пользователя.

Требования и пререквизиты

• Linux
• xz, rsync, PostgreSQL.
• Node.js >= 10.15.3
• Установленное приложение, которое будет работать с базой данных.
• Настроенное ведро (bucket) на Amazon S3 (как настраивать).
• Установить AWS CLI
• Перед установкой заполните все переменные окружения
• Если вы не root:
  • добавьте своего юзера в sudoers.
  • и дайте ему беспарольный доступ к chown, chmod, rsync и командам, нужным для запуска и остановки PostgreSQL.
  • пример строки из /etc/sudoers: alexey ALL = (root) NOPASSWD: /bin/chown, /bin/chmod, /usr/sbin/service postgresql start, /usr/sbin/service postgresql stop, /usr/bin/rsync
  • добавьте своего пользователя в группу postgres.

Установка глобально

• npm i -g db-presets (для root используйте npm i --unsafe -g db-presets).
• В системе появится утилита db-p, и создадутся директории для вашей ветки.
• Если вы хотите сменить репозиторй или ветку - меняте переменные окружения, и запускаете db-p init.
• Помощь по командам можно посмотреть так: db-p -h.

Установка, чтобы использовать API в коде

npm i -S db-presets

Детальное описание команд

Сценарии использования

Файлы и папки.

• Папка с sql пресетами и описанием измнений. Рядом с каждым sql файлом лежит одноименный *-clog.txt фал.
• Папка с data директориями, созданными pg_basebackup.
• Папка c зашифрованными архивами пресетов, дубликаты этих архивов заливаются на Amazon S3.
• ~/.aws/config - конфиг aws cli утилиты, выглядит примерно так:

[profile r-vision-r]
region = eu-central-1
output = json
[profile r-vision-rw]
region = eu-central-1
output = json

• ~/.aws/credentials - креденшлзы для aws cli, выглядит примерно так:

[r-vision-r]
aws_access_key_id = bla-bla
aws_secret_access_key = bla-bla
[r-vision-rw]
aws_access_key_id = bla-bla
aws_secret_access_key = bla-bla

• Файл с AES ключом и вектором инициализации. Создается db-p gen-key. Записывается по пути, указанному в DBP_AESKEY_PATH.

• Лог действий пользователя. Записывается по пути, указанному в DBP_LOGFILE.

• Папка с внутренними данными тулзы. Лежит в ~/.db-presets

Рекомендации

• Делать пресеты, нужно по-возможности на релизных ветках, чтобы на них всегда можно было накатить миграции от тестовой ветки, или от фиче - веток. Если пресет нужен для тестирования ещё не влитой в релиз фичи, то никуда не денешься, придется создавать временные пресеты для тестовой (development, stage) ветки. Но для этого в ведре на Amazon S3 нужно создать папку для тестовой ветки.

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

• В пресетах должны быть только необходимые данные, т.к. с большими пресетами снизится скорость работы и увеличится плата за S3. И просто не стоит копить мусор в пресетах, ведь от них наследуются пресеты для следующих релизов, и мусор будет копиться как снежный ком.

• Название пресета должно быть информативным. Чтобы и тестировщики понимали какой пресет использовать для тестов, и какой пресет расширять для того или иного тест кейса.

• Нужны универсальные пресеты, которые будут использоваться для большинства тестов, и специфические пресеты, для тестирования частностей.

• По-возможности, названия и свойства сущностей в БД должно быть на английском языке, чтобы было меньше различий между английской и русской версиями приложения.

• Имена сущностей должно быть информативными. Смысл такой: у каждого писателя тескейсов должно быть понимание какие сущности он может юзать для своих кейсов. Если там device1, user1, host1, то писатель не поймет что это, и сделает свои user2, host2, и т.д., и будет мусорка.

• Если непонятно название сущности, которую кто-то создал, можете улучшить название, и поменять название во всех местах, где оно используется (другие тесткейсы, автотесты, и т.д.). Принцип скаута и рефакторинги работают и здесь.

• Т.е. надо постоянно следить за порядком в пресетах, и не допускать там бардака. Иначе потом бардак будет наследоваться в следующей версии, и разрастаться.

Лицензия (license)

MIT