В статье будет дан краткий обзор подхода к построению архитектуры, основанной на клетках - Cell-Based Architecture

Cell-Based Architecture - это подход к построению сервисной архитектуры, в котором один сервис и его инфраструктурные потребности объеденены в единое целое - клетки. Каждая клетка может содержать логически-связанные микросервесы, хранилеще данных, системы обсервабилити (мониторинг, логирование, трейсинг). Таким образом формируется сплочённая (cohesive) и самодостаточная единица деплоя. Каждая такая клетка живёт автономно. Причём, она может взаимодействовать с другими клетками вокруг путём таких механизмов как события, прямой вызов и т.д. Для этого в оболочке клетки существуют точки взаимодействия - строго определённые интерфейсы. Сервисы внутри клетки взаимодействуют только друг с другом.

Rye — это пакетный менеджер для Python, написанный на Rust. Но Rye — это не только пакетный менеджер, но и удобный инструмент, который позволяет управлять проектами, зависимостями, виртуальными окружениями и версиями Python. Под капотом у Rye находится uv — более быстрый аналог pip, который, как и Rye, написан на Rust. Автором Rye является небезызвестный Armin Ronacher.

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

Один из вариантов был использовать Docker, но я от него отказался по причине того, что окружение для Docker тоже надо будет готовить. Потом надо будет правильно запуск этот образ и правильно с ним взаимодействовать. Конечно, для упрощения можно использовать docker compose, но это не сильно снижает сложность для конечного пользователя. Кроме того, образ будет достаточно большим.

Поэтому я после некоторых размышлений обратился к таким инструментам как Python Compilers, а именно - Nuitka и PyInstaller и провёл небольшое исследование на предмет

Оба инструмента упаковывают Python-приложение со всеми зависимостями в один пакет таким образом, что конечный пользователь приложения может обойтись без установки Python на свою машину.

Есть два варианта того, что мы получаем от их работы в качестве результата (кроме эмоциональных ощущений):

Сложилось так исторически, что мы долго не обновляли PostgreSQL и застряли на версии 12. Но пришло время обновлять зависимости проекта и оказалось, что Django 5.1 версию 12 PostgreSQL уже не поддерживает и это мотивировало меня провести обновление до новейшей 16 версии.

На момент написания у нас всё организовано достаточно просто — все необходимые компоненты запускаются в Docker-контейнерах через Docker Compose.

У меня было два варианта, как произвести миграцию: