Расскажите о себе и сути проекта?

Благодаря клубу в мае 2024 года я нашел себе работу на должность Junior DevOps в одной Швейцарской компании. Не подумайте, там нет никаких фантастических цифр. Я бы даже сказал, что не Junior - а что там идет ниже - Associate скорее всего. То есть что-то может, но мало чего полезного, на вырост так сказать.

Там меня сразу же закинули в реалии Enterprise - Azure и Kubernetes.
Это затянутая предыстория о том, что Kubernetes кластеры я активно последний год трогал только на работе, но сам боялся подступить. Не будем учитывать пару моих постов, как в K8S запустить HTML-страничку, это были малые эксперименты, потрогать что это такое хотя бы отдаленно.

Как появилась идея? Что вдохновило?

Сейчас я стал более опытным и после неудавшегося предыдущего проекта - Dokyard, после простоя в полгода я случайно подслушал разговор в чатах Вастрик.Тех и Вастрик.Индихакеры о "Вот бы был PostgreSQL или MongoDB сервер для тестов". Да, есть бесплатный Supabase, я им пользовался, но насколько я помню:

1. Схему нужно создавать руками, а не кодом
2. Если некоторое время не проводить операций - проект ставят на паузу.

Также, есть Neon.com, но в Бесплатном тарифе только 190 Compute Hours.

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

Добавлю, что в Dokyard проекте тоже были зачатки Cloud PostgreSQL - там можно было из веб-интерфейса создать себе до 3 база, управлять ими, использовать в своих контейнерах.

Текущая идея заключаться вот в чем. Использовать облачную базу PostgreSQL для быстрого прототипирования и если всё понравилось быстро загрузить сервис в облако, а база останется прежней. Если что-то не понравилось, можно базу пересоздать (удалить и создать новую), если, к примеру не хочется ручками или кодом вычищать структуру, данные. Для первого подходит SQLite, который идет "из-коробки", но в любом случае при миграции в облако вы скорее всего захотите перейти на PostgreSQL и надо будет дописывать композ, править Connection String.

Понимаю, что врядли кто-то будет пользоваться этим сервисом для "прода", но как мне кажется для пет-проектов этого точно должно быть достаточно.

Что вошло в прототип и сколько времени на него было потрачено?

Приступил к работе я не сразу. Я некоторое время обдумывал, как лучше реализовать этот сервис. В случае с Dokyard все пользовательские базы данных хранились в одном инстансе СУБД PostgreSQL в Docker-контейнере и с помощью дополнительных прав я разграничивал доступ пользователей в свои базы, но чтобы чужие они даже читать не могли. Это был бы самый простой способ реализовать поставленную задачу, но в том случае я не мог контролировать использование ресурсов: диска, процессорного времени, ОЗУ, то есть один пользователь мог забрать все ресурсы себе, а остальные от этого могли пострадать.

Потому я принял решение использовать Kubernetes, а конкретно K3S.
Оператор, который помогает создавать пользовательские поды-базы: Zalando Postgres Operator.
Каждый клубный пользователь через Telegram бот может создать 1 базу данных - отдельный Pod с PostgreSQL 17 с выделенными ресурсами:

• Размер диска: 200 Мб
• CPU request: 30m
• CPU limit: 45m
• Mem request: 90Mi
• Mem limit: 105Mi

В будущем ресурсы каждого отдельного Pod можно легко расширить без его рестарта и без потери данных в PVC.

Скорее всего вы задались вопросом, как были расчитаны лимиты на потребляемые ресурсы.
Был написан скрипт, который с интервалом 0.001 сек совершает следующие действия:

• создаётся один пользователь в таблице users;
• случайно добавляются записи в 2–3 таблицы: posts, comments, categories, subscriptions;
• данные между таблицами связаны через FK user_id и post_id;
• удаляются старые пользователи без связанных записей;
• каждые 2 итерации выполняется JOIN COUNT.

Под пиковой нагрузкой я получал следующие показатели:
CPU: 40m, Mem: 100Mi

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

Отвечу на вопрос: ушло 2 полных дня, учитывая, что у меня есть две основные работы.

Какой технологический стек вы использовали? Почему?

VPS на Ubuntu 24.04 в Hetzner с 4 ядрами и 8 Гб ОЗУ с 80 Гб NVME-накопителем.
K3S+Zalando postgres-operator+HELM и yaml манифесты.
Отдельный PostgreSQL 17 pod для хранения пользовательских данных. Стоит уточнить, что пароль от пользовательских баз я не храню ни в каком виде, он отдается пользователю один раз и если пользователь потеряет его (удалит сообщение от бота), то единственным выходом будет удалить текущую базу и создать новую.
Python, Aiogram - Telegram бот; тоже живет в кластере. Клубный API для проверки, что пользователь является пользователем клуба.

Новое для меня: динамические поддомены для каждого инстанса пользовательской базы. У меня был тестовый домен, который никак не использовался: frogspond.xyz, решил применить его.
Теперь каждая база получает FQDN-адрес до своей базы вида:
username-db-<random id>.frogspond.xyz, где username - клубный username.

Для удаления базы используется команда /drop с простым математическим уравнением, чтобы не получилось удалить базу случайно:

Повторюсь, для баз создается инстанс с PostgreSQL 17;
Если большинство людей проголосует, что 17 - too much и им нужен 15 или 16, а 17 не нужен, то я могу достаточно быстро передеплоить всё на 15 или 16 версию, простой небольшой конечно же будет.

Картинка взята из источник.

Как вы запускались и искали первых пользователей?

Пользователей ещё нет, клубчане - мои первые пользователи.

С какими самыми неожиданными трудностями пришлось столкнуться?

Как я ранее упоминал - выбор технологии разграничения доступа к базам и установка лимитов на использование ресурсов.
Определение лимитов на выделяемые пользовательским Pods.

Сколько потратили и заработали? Есть идеи как это можно монетизировать?

Как и многие свои проекты я делаю для клуба, чтобы клубчанам было приятно пользоваться клубом, не только нетоксичное коммьюнити, но и полезные сервисы.

Нужны ли какие-то советы или помощь Клуба?

Да, мне очень нужна обратная связь. Я чувствую, что получил недостаточно её при публикации Dokyard и хотелось бы тут получить больше ответов в комментариях или в ЛС, любые идеи и предложения я изучу, рассмотрю, дам ответ.
А также, прошу, найдитесь те, кто сможет протестировать сервис, базы "в хвост и в гриву", может быть стоит уменьшить или увеличить заявленные запросы и лимиты на ресурсы.

Какие планы на будущее?

На данный момент лимит по выделяем ресурсам позволит создать около 80 пользовательских баз с равным объемом выделенных ресурсов. Если вы понимаете, что база вам больше не нужна, пожалуйста, удалите её, чтобы другим пользователям точно хватило ресурсов. Если будет большой спрос буду увеличивать ресурсы ВМ.


Скорее всего данный проект я опубликую в Open Source на Github, каждый сможет изучить код и переиспользовать в своих пет-проектах.

Какой совет вы бы сами могли дать идущим по вашим стопам?

У вас всё получиться. Не сдавайтесь. Очень много пет-проектов выбрасывается, потому что решали не ту задачу или не в своё время.