Comments 20
А инсталляция без докера возможна?
Совсем без Docker'a нет. Но для Ubuntu \ Debian есть скрипт установки, который сначала установить Docker, а потом Postgresus - https://postgresus.com/installation#option-1-automated-script
Эмммм, у Вас там не один бинарник? почему нельзя без докера? А если я не хочу докер, ну банально ресурсы не позволяют этот слоеный пирог запустить.
Совсем не только бинарник. Я даже в теории не знаю, как засунуть все функции Postgresus в один бинарник...
https://github.com/RostislavDugin/postgresus
Там и бек, и фронт, и внутренняя БД, и pg_dump бинарники PG 12-18, и сборка под разные архитектуры. Без докера это удобно поставлять не выйдет
Минимальные требования для Postgresus - это 512 Мб RAM и 1 vCPU (вот тут детальнее). На условный Raspberry Pi влезет
Да и у Docker'а оверхед 0.1% на уровне погрешности (пример)
Фронт и бэк легко можно засунуть в 1 бинарник. Бд для сервиса это служебная часть и она может и должна быть за пределами контейнера с приложением, запускаете приложение - оно идет в бд и если там пусто то запускает миграции и создает все нужные объекты. Служебные бинарники pg_dump так же нет смысла постоянно держать рядом с программой, можно скачивать их из офф репо дистрибутива ос и обновлять, что тоже важно тк в сторонних утилитах находят уязвимости и баги и их нужно обновлять
...а зачем это всё, если можно удобно сложить всё в один образ, чтобы систему можно было запустить одной командой на любой ОС (Windows, MacOS, Linux) и нескольких архитектурах (amd64 и ARM)?
Сейчас удобный CI \ CD, полное покрытие тестами с предсказуемой средой, воспроизводимость среды на серверах пользователей. И удобный пользовательский путь — что очень важно
В вашем варианте исчезает предсказуемость среды, постоянно нужно обновлять бинарники и заставлять пользователя делать лишние действия. Не очень user friendly получается...
Напихать все в одну кучу (докер-образ) нарушив все принципы проектирования Вы конечно можете. Чем это обернется? Покажет время. Лично я не стану использовать такой продукт и рекомендовать его кому-то так же не стану, как накопленная поделка сгодится, но не более, при всем моем уважении. Альтернативы есть, причем довольно неплохие.
Чем это обернётся?
Чем? Можете привести примеры, в которых такой подход привёл к негативным последствиям?
---
Я рад конструктивной критике. Но вы:
1) Сказали как "легко" собрать всё в бинарник, но только в теории без понимания устройств проекта. Со стороны всё легко, а я спустя полгода развития проекта не разбираюсь, видимо :)
2) Предложили переусложненный путь, который приведет к непредсказуемости окружения, увеличению стоимость сопровождения проекта и усложнению пользовательского пути.
При этом не объяснили, какие преимущества даёт такой подход в обмен на всех эти минусы (в равнении с тем, который сейчас отлично работает).
Судя по сообщениям выше, это должно убрать оверхед докера в ~0.01%.
3) Обосрали проект. Не рассказав, какое решение сопоставимого размера вы выложили в open source и принесли сопоставимую пользу людям.
Легко критиковать усилия других людей, не выставляя свои решения напоказ.
Я посмотрел ваш GitHub, но нашёл только заброшенный dev kit восьмилетней давности и сборник скриптов из ощутимого.
Поэтому не совсем понял, откуда такая экспертиза в том, как другим проектам нужно поставлять системы, состоящие из API, фронта, базы и других утилит. Может покажете пример?
Чем? Можете привести примеры, в которых такой подход привёл к негативным последствиям?
У вас в одной куче stateful сервис (это база) и stateless (сервис). Что будет если oom-killer решит прибить контейнер с этой кучей сервисов? База может крэшнуться и не запуститься в следующий раз, может еще что-то нехорошее приключиться.
А захардкоженый пароль пользователя postgres, так задумано? Мне тоже объяснить к чему это может привести или сами догадаетесь? Ну сделайте хоть рандом, это не сложно. Про то что у Вас приложение работает с БД под пользователем postgres я тоже умолчу, для меня как для ДБА со стажем - это как минимум странно.
И я не понимаю, что мешало запускать ваш сервис через Docker Compose где база будет в отдельном контейнере, а сервис, пусть и с набором бинарников pg_dump в отдельном? Зачем базу держать рядом с приложением? Это 2 разные сущности.
А если в БД обнаружиться критическая уязвимость, то как ее обновить в такой куче мала?
А если я хочу отказоустойчивую БД с репликами и прочими прелестями то как быть?
А если я хочу PostgreSQL 18 (у вас внутри 17-я версия), то что делать?
Ответьте мне на эти вопросы пожалуйста. Просто ответе, без холивара.
3) Обосрали проект. Не рассказав, какое решение сопоставимого размера вы выложили в open source и принесли сопоставимую пользу людям.
Я не обсирал Ваш проект, поставил ему звезду и добавил в закладки в надежде, что Вы примите во внимание как минимум 2 комментария про то что было бы неплохо иметь отдельные бинарники и краткую инструкцию как их запустить без докера и встроенной БД, но у вас это вызывает бурю негодования, что это какие-то сложности, нарушит пользовательский опыт и прочие отговорки. Печально.
В предыдущей статье в комментариях некоторые люди спрашивали как настроить работу вашей программы через IaC. Ну как бы 21-й век, все описывают инфраструктуру как код, чтобы можно было деплоить все одинаково настроенное в разные проекты. Но Вы пропустили мимо эти комментарии, они не важны, печально.
>Легко критиковать усилия других людей, не выставляя свои решения напоказ.
А причем тут мои решения? Речь не про них, речь про Ваш продукт, не переводите разговор на другую тему. Почитайте, что я написал повнимательней. Альтернативы Вашему решения есть, вот пожалуйста gobackup, один бинарник, все умеет, никаких зависимостей.
>Я посмотрел ваш GitHub
Зачем его смотреть? Ну реально? Речь не обо мне, а о Вашем проекте. Повторюсь, я написал несколько вопросов выше. Очень хочется чтобы Вы на них ответили четко и по делу, не переходя на личности и достижения.
Интегрировал Postgresus в свой Docker Compose стек буквально за 5 минут - 7 строк конфига и всё работает. Именно потому что автор упаковал всё в Docker-образ. Использую в проде для бэкапа баз, работает стабильно. Docker сейчас стандарт для self-hosted, и это было правильное архитектурное решение.
Красивый инструмент. Респект за старания.
Но в целом, похожий инструментарий мало когда нужен в production. Объясню почему:
Как правило, если мы говорим про k8s, то вполне хватает обычного pg_dump и cronjob . В случае падения джоба есть prometheus со своим алертингом. Мы, например у себя, сделали отдельный k8s оператор jobchain, который позволяет выполнять цепочку джобов. Собственно, сначала в цепочке выполняются дампы (баз несколько и очередность тоже имеет значение). Потом rclone закидываем в s3. У всего есть статусы k8s и метрики prometheus.
Дампы, как таковые в реальном production, больше нужны для анализа разработке. Для отказоустойчивости/восстановления/отката гораздо лучше подходит штатная репликация ("в обертке" от zalando и т.п.) + wal-g в s3.
Иногда размер БД становится непомерно большим. Сотни ГБ или даже несколько ТБ. И с такими размерами "бэкапить" уже не реально. Ежедневный дамп "начинает наступать на пятки следующему через сутки". Восстанавливать в случае аварии такую БД - это даунтайм больше чем на сутки. В общем "такое себе".
Сидеть и любоваться UI дело конечно приятное, но обычно приходится заниматься другой работой, и лишь только в случае алертинга, начинаешь смотреть "что там, да как". Там уже логи контейнера/pgsql/pg_dump или статусы/события k8s больше расскажут, чем gui.
Всё вышесказанное, разумеется - IMHO.
Плюсую.
Может у меня какое-то профессиональная деформация на оракле, но считаю что бэкапом транзакционной БД может считаться то, что позволяет восстановится на момент последней закомиченной транзакции (если не потеряны логи транзакций, конечно), оно же PITR по сути.
И в доке pg_dump написано такое :
Note, however, that except in simple cases, pg_dump is generally not the right choice for taking regular backups of production databases.
Поэтому, сторго говоря, это не должно называться backup tool/инструмент резервного копирвания.
Очень понравилась идея и реализация. Поставил себе, бекапить несколько небольших пет проектов. Только один вопрос, авторизация по ssh планируется?
Я правильно понял из статьи, что используются механизмы pg_dump (по сути не предназначенный для РК) или, как альтернатива, копирование ФС?
Несколько вопросов
1 - Почему не использовать хотя-бы pg_basebackup, изначально предназначенный для целей РК?
2 - При выполнении РК с файл-системы (очень надеюсь) используются pg_start_backup|pg_stop_backup?
3 - планируется ли использовать механизм реплики, наиболее оптимальный для РК тяжелых баз?
Отличный продукт, обязательно попробуем у себя
Планируется ли поддержка MySQL / MariaDB? Зоопарк решений вынуждает у себя хостить и pgsql и все остальное
Postgresus 2.0: новая версия open source инструмента для резервного копирования PostgreSQL