Py-dockerdb: упрощение обработки программной базы данных

Если вы когда-либо работали над бэкэнд или проектом, ориентированным на данные в небольшой команде, скорее всего, вы достигли той же стены, которую я сделал: настройка локальных баз данных последовательно, надежно и без трения.

Это обманчиво простая задача. И все же, это то, где многие проекты начинают чувствовать себя хрупкими.

Проблема: локальная настройка базы данных спираль

Представьте себе это: вы создаете архитектуру микросервиса, которая общается с базой данных PostgreSQL. Вы работаете с двумя другими разработчиками.

Вы пишете быстроREADME:

«Убедитесь, что у вас установлен Postgres. Создайте пользователя, пароль, базу данных. Импортировать этот скрипт SQL. Используйте порт 5432, если он не будет взят».

Вы думаете, что это нормально. Затем запросы на тягу начинают кататься с ошибками, которые не имеют смысла. Кто -то БД неправильно настроен. Кто -то еще забыл запустить сценарий схемы. Другой человек установил неправильную версию Postgres в Windows, и он даже не запустится.

А когда вы пытаетесь встать на борту нового товарища по команде? Если прошло много времени с тех пор, как кто -либо выполнил настройку, она может быстро превратиться в полный день устранения неполадок.

Локальная настройка базы данных обманчиво дорого. Он вводит дисперсию в ваши среды Dev и выпекает скрытые предположения в вашу кодовую базу.

Даже с Docker это редко элегантно. Вы можете получить беспорядокdocker-composeФайлы, переменные среды, сценарии наполовину разбитых оболочек и монтаж ручного тома, которые никто не осмеливается.

Реальный пример: автоматизация уведомлений WG-Gesucht

В моем случае это поразило дом во время разработки бота, который сосказывает списки изWG-Gesucht(Немецкий сайт обмена квартирой) и автоматически предупреждает пользователей на основе их предпочтений. Он построен как коллекция микросервисов:

• Сервис скребки (получает данные и хранит их в Postgres),
• Модуль поиска вектора с использованием PGVector (для рекомендаций списков),
• Диспетчер уведомлений (интегрируется с электронной почтой/телеграммой).

Каждая служба использует локальный БД во время разработки и тестирования. Мне нужно было:

• Быстро раскручивайте экземпляры Postgres и MySQL с помощью тестовых данных,
• Запустить сценарии init и контент семян от Python,
• Поделиться конфигурациями с сотрудниками, используя Jupyter и ноутбуки,
• Избегайте любой боли настройки, специфичной для ОС.

Docker - очевидный выбор, но я не хотел, чтобы мой поток Dev зависел от команд Docker CLI, похороненных в сценариях. Я хотел, чтобы все было заполнено в Python, так что он мог жить бок о бок с моей логикой и быть проверенной, перезагружаемым и явным.

Как должно выглядеть правильное решение

На данный момент у меня были четкие цели для лучшего подхода к местным базам данных:

• Python-Pirst Interface: Нет сценариев оболочки, нетdocker-compose.yml, без макияжных файлов.
• Минимальные зависимости: Нет установки клиентских инструментов или сценариев внешней настройки.
• Кроссплатформенный: работает на MacOS, Linux и Windows (даже WSL).
• Поддерживает сценарии и тома инициировать: Я хочу заселить данные или сохранить их.
• Четкий контроль жизненного цикла: Я хочу.start_db()В.stop_db()В.delete_db()как любой объект Python.

Это инструмент, который я хотел бы, чтобы существовал с самого начала. Итак, я построил это.

Предприятиеpy-dockerdb

py-dockerdbэто библиотека Python, которая позволяет вам управлять настоящими заставленными базами данных, такими как нативные объекты Python. Посетите проект наGitHubДля получения дополнительной информации и примеров использования!

Имея всего несколько строк кода, вы можете развернуться Postgres, MongoDB, MySQL или SQL Server, внедрить скрипты, подключаться к знакомым драйверам Python и разорвать их, когда закончите.

Нет оболочки, нет ямля, нет догадок.

from docker_db.postgres_db import PostgresConfig, PostgresDB

config = PostgresConfig(
    user="botuser",
    password="botpass",
    database="wggesucht_db",
    container_name="local-postgres"
)

db = PostgresDB(config)
db.create_db()

conn = db.connection
cursor = conn.cursor()
cursor.execute("SELECT COUNT(*) FROM listings;")
print(cursor.fetchone())

Он запускает фактический экземпляр PostgreSQL в Docker, разбитый сценарием init, готов к взаимодействию и полностью контролируется с Python.

Как это работает

Каждый тип базы данных имеет два класса:

• АConfigКласс, который определяет настройки соединения и поведение инициирования.
• АDBкласс, который управляет жизненным циклом:create_db()Вstop_db()Вdelete_db()Вrestart_db()Полем

Он поддерживает:

• Сценарии инициирования: SQL, JS, SH, в зависимости от двигателя БД.
• Том. Постоянство: Таким образом, вы можете повторно использовать данные через прогоны.
• Инъекция окружающей среды: Полезно для шаблона сценариев.
• Местные водители: psycopg2ВpymongoВpyodbcВmysql-connectorПолем

Все, что вам нужно, это Docker и Python 3.7+ и экземпляр Docker на хост -машине.

Для чего вы можете использовать его

Вот некоторые варианты использования, которые я исследовал или видел:

• Научные записные книжкиС SQL Backens, которые загружаются по требованию.
• Среда тестирования CIкоторые требуют одноразовых контейнеров базы данных.
• ПреподаваниеSQL или NOSQL, не прося студентов что -либо установить.
• Разработка микросервисас предсказуемыми, изолированными экземплярами DB.
• Быстрое прототипированиеДля приложений, которые нуждаются в посевных данных в первый день.
• 
  

Философия

py-dockerdbнамеренноминимальныйПолем Это не пытается заменитьdocker-composeдля полного стека оркестровки. Это не обезвреживание и не догадается ваши намерения.

Вместо этого он фокусируется на одной вещи:Позвольте вам управлять локальными базами данных, полностью из Python, используя настоящие контейнеры Docker.

Нет DSLS. Нет скрытого автомага. Просто код.

Поддерживаемые базы данных

• Postgresql
• Mysql
• Mongodb
• Microsoft SQL Server

И Кассандра находится на дорожной карте.

Установка

Просто установите его от PYPI:

pip install py-dockerdb

И ты готов к работе.

Суть

Работа с базами данных локально не должна быть запоздалой мыслью. Это один из самых повторяющихся шагов в любом бэкэнд, данных или DevOps. Тем не менее, мы все еще откладываем его вручную с расплывчатыми инструкциями и сценариями настройки.

Сpy-dockerdb, Вы можете сохранить настройку базы данных вместе с вашей логикой - упрощенной, изолированной и проверенной.

Ваши товарищи по команде (и Future Self) будут вам благодарны.