Версию продукта которую можно установить вне слоев виртуализации, сетевого оверхеда и проблем с диагностикой при падении отдельных контейнеров или служб/компонентов внутри их среды Docker.
Вы про тот 0.01% оверхеда, который в зоне погрешности?
падении отдельных контейнеров
Контейнер один. И службы в нем хотя бы воспроизводятся, а не у каждого свои (как при установке в ОС)
Вас попросили сделать продукт вне Docker окружения
Что переводится как "ухудшить продукт для поддержки редкого юзкейса, потратив пару недель разработки на давно решенную контейнерами задачу, вместо улучшения текущих функций"
в том числе люди которые по тем или иным причинам не буду ставить Docker ради вашего проекта
Значит проект для них не предназначен
Хотите больше аудиторию?
Только ту, которым подходит мой проект. А кому не подходит - есть масса других инструментов. Databasus - это не история про поддержку 100% пользовательских сценариев, они слишком разные
Зачем писать здесь статью?
Чтобы аудитория, которой полезен проект - о нем узнали. А не для всех и сразу. В статье нигде не идёт речи, что все должны пользоваться моим проектом
Это не функция или фича - это способ распространить/адаптировать продукт на большую аудиторию
Это способ потратить уйму времени с КПД около нуля, уменьшить предсказуемость среды и испортить проект тем 99.9%, которые используют Docker
Может подскажите, на какую аудиторию вы распространили свой проект, убрав Docker?
Docker Hub заблокирован в РФ с Мая 2024 года
Если бы Docker Hub не работал в РФ, из РФ не было бы ~12% пользователей
---
Будьте готовы получить фидбек
Это не фидбек. Это попытка доказать свою правоту, хотя я объяснил рациональные причины, почему принято такое решение
Вы зачем-то хотите от проекта то:
для чего он не предназначен;
контрпродуктивно и ухудшит его maintability;
требует эдак ~$5 000 вложений в виде моего времени, если его конвертировать в деньги;
не расширит аудиторию проекта, потому что у 99.9% разработчиков \ DevOps'ов нет проблем с Docker'ом, но ухудшит его для всех остальных;
...так ещё и вы не факт, что этим будете пользоваться :)
У любого решения есть компромиссы. Для Databasus'a был сознательно выбран Docker, потому что:
он даёт воспроизводимую среду, тем самым улучшая maintability при разработке;
даёт запустить проект за минуту, а не возиться с установкой и вечным дебагом;
даёт поддержку большинства платформ и не зависеть от пакетных менеджеров \ архитектур: Windows, MacOS, Linux - практически любые версии, включая ARM;
Не использовать Docker для такого проекта - это всё равно, что вставлять себе палки в колёса, постреливая в колено время от времени. Очень странно фокусироваться на преодолении проблем, которые давно решил прогресс, а не на проекте, функциях и пользе
А ещё напомню, что главный пользователь Databasus'a - это я. У меня есть Docker
>60к загрузок из Docker Hub и ~4к звёзд на GitHub показывают, что пользователи уже решили. Точнее что очень крупному сегменту людей этого не хватает:
Если вам не подходит мой проект, на GitHub точно есть >5 CLI инструментов, которые во многом даже эффективнее и с ещё большим сообществом — используйте их. Зачем требовать от моего то, что навредит проекту?
Начать можно сперва с Debian подобных систем или подробной докой или sh скриптом, потом написать для RHEL подобных.
Я вот не готов вложить несколько недель работы в нестабильную фичу, которая нужна 1%< пользователей и которая уменьшит предсказуемость среды исполнения. А потом её годами ещё сопровождать и чинить. Зачем эта возможность, учитывая, что проект работатает надёжнее без неё и ничего не теряет в функциональности?
Но, если вы считаете, что это полезная функция и готовы доказать, что так лучше - буду рад, если сделаете форк и докажете это. Проект в open source, всё открыто, вам никто не мешает дорабатывать под себя
Чем? Можете привести примеры, в которых такой подход привёл к негативным последствиям?
---
Я рад конструктивной критике. Но вы:
1) Сказали как "легко" собрать всё в бинарник, но только в теории без понимания устройств проекта. Со стороны всё легко, а я спустя полгода развития проекта не разбираюсь, видимо :)
2) Предложили переусложненный путь, который приведет к непредсказуемости окружения, увеличению стоимость сопровождения проекта и усложнению пользовательского пути.
При этом не объяснили, какие преимущества даёт такой подход в обмен на всех эти минусы (в равнении с тем, который сейчас отлично работает).
Судя по сообщениям выше, это должно убрать оверхед докера в ~0.01%.
3) Обосрали проект. Не рассказав, какое решение сопоставимого размера вы выложили в open source и принесли сопоставимую пользу людям.
Легко критиковать усилия других людей, не выставляя свои решения напоказ.
Я посмотрел ваш GitHub, но нашёл только заброшенный dev kit восьмилетней давности и сборник скриптов из ощутимого.
Поэтому не совсем понял, откуда такая экспертиза в том, как другим проектам нужно поставлять системы, состоящие из API, фронта, базы и других утилит. Может покажете пример?
...а зачем это всё, если можно удобно сложить всё в один образ, чтобы систему можно было запустить одной командой на любой ОС (Windows, MacOS, Linux) и нескольких архитектурах (amd64 и ARM)?
Сейчас удобный CI \ CD, полное покрытие тестами с предсказуемой средой, воспроизводимость среды на серверах пользователей. И удобный пользовательский путь — что очень важно
В вашем варианте исчезает предсказуемость среды, постоянно нужно обновлять бинарники и заставлять пользователя делать лишние действия. Не очень user friendly получается...
Но запросы обычно по делу: или баг репорты, или действительно наболевшее. Только в ~20% случаев приходится писать "это не нужно 95% пользователей, поэтому такое делать не буду"
Логи самих контейнеров - к сожалению, нет. Log Bull все-таки ориентирован на код. Хотя, в теории, если этих логи засунуть в HTTP и отправить через curl - тогда можно
сравнения аналогичными существующими решениями Объективное сравнение возможно разве что по метрикам и перформансу, а это не приоритет проекта. По производительности что-то среднее между ELK и Loki. В целом, может даже и похуже обоих (но какая разница, если логов не тысячи в секунду?)
Приоритет - это удобный UX для разработчика. Просто установить, просто отправить через библиотеку, удобно смотреть логи. Но это, все-таки - субъективная оценка
Почему было не взять в качестве сервера, например, rsyslog, если у вас midsize проект, и сосредоточится на интерфейсе управления
Так тоже можно. Но я знаком с OpenSearch, поэтому взял его. Которому, в каком-то смысле, и сделал интерфейс управления для просмотра логов и разделения между проектами
Почему во всех примерах http
Потому что с HTTPS сложнее деплой и нужен домен. А приоритет Log Bull - максимально простой деплой. Просто docker compose up -d не сработает. Если информация действительно sensetive, я бы лучше взял ELK и DevOps'a, который его настроит
Здравствуйте, а у вас какую-то ошибку выдаёт?
Лучше с этим вопросом напишите сюда - https://t.me/databasus_community
Так нажмите и оно спросит "куда" :)
Databasus даёт и делать бекапы, и восстанавливать
Вы про тот 0.01% оверхеда, который в зоне погрешности?
Контейнер один. И службы в нем хотя бы воспроизводятся, а не у каждого свои (как при установке в ОС)
Что переводится как "ухудшить продукт для поддержки редкого юзкейса, потратив пару недель разработки на давно решенную контейнерами задачу, вместо улучшения текущих функций"
Спасибо 😄❤️
Значит проект для них не предназначен
Только ту, которым подходит мой проект. А кому не подходит - есть масса других инструментов. Databasus - это не история про поддержку 100% пользовательских сценариев, они слишком разные
Чтобы аудитория, которой полезен проект - о нем узнали. А не для всех и сразу. В статье нигде не идёт речи, что все должны пользоваться моим проектом
Это способ потратить уйму времени с КПД около нуля, уменьшить предсказуемость среды и испортить проект тем 99.9%, которые используют Docker
Может подскажите, на какую аудиторию вы распространили свой проект, убрав Docker?
Если бы Docker Hub не работал в РФ, из РФ не было бы ~12% пользователей
---
Это не фидбек. Это попытка доказать свою правоту, хотя я объяснил рациональные причины, почему принято такое решение
Вы зачем-то хотите от проекта то:
для чего он не предназначен;
контрпродуктивно и ухудшит его maintability;
требует эдак ~$5 000 вложений в виде моего времени, если его конвертировать в деньги;
не расширит аудиторию проекта, потому что у 99.9% разработчиков \ DevOps'ов нет проблем с Docker'ом, но ухудшит его для всех остальных;
...так ещё и вы не факт, что этим будете пользоваться :)
У любого решения есть компромиссы. Для Databasus'a был сознательно выбран Docker, потому что:
он даёт воспроизводимую среду, тем самым улучшая maintability при разработке;
даёт запустить проект за минуту, а не возиться с установкой и вечным дебагом;
даёт поддержку большинства платформ и не зависеть от пакетных менеджеров \ архитектур: Windows, MacOS, Linux - практически любые версии, включая ARM;
Не использовать Docker для такого проекта - это всё равно, что вставлять себе палки в колёса, постреливая в колено время от времени. Очень странно фокусироваться на преодолении проблем, которые давно решил прогресс, а не на проекте, функциях и пользе
А ещё напомню, что главный пользователь Databasus'a - это я. У меня есть Docker
На этот случай у меня есть мем:
>60к загрузок из Docker Hub и ~4к звёзд на GitHub показывают, что пользователи уже решили. Точнее что очень крупному сегменту людей этого не хватает:
Если вам не подходит мой проект, на GitHub точно есть >5 CLI инструментов, которые во многом даже эффективнее и с ещё большим сообществом — используйте их. Зачем требовать от моего то, что навредит проекту?
Я вот не готов вложить несколько недель работы в нестабильную фичу, которая нужна 1%< пользователей и которая уменьшит предсказуемость среды исполнения. А потом её годами ещё сопровождать и чинить. Зачем эта возможность, учитывая, что проект работатает надёжнее без неё и ничего не теряет в функциональности?
Но, если вы считаете, что это полезная функция и готовы доказать, что так лучше - буду рад, если сделаете форк и докажете это. Проект в open source, всё открыто, вам никто не мешает дорабатывать под себя
К сожалению, версия без Docker'a для Databsus'a не выйдет. У системы много компонентов
Установка даже в рамках одной ОС разных версий выйдет непредсказуемой. На разных ОС - вообще разные способы
В общем, тут выйдет неоправданно трудозатратно для проекта и неудобно для большинства пользователей
Если нужна версия без Docker'a, лучше взять условный go-backup или wal-g
Внезапно оказалось, что да))
После статьи было очень много запросов - и это оказалось относительно простой задачей
Поэтому фокус на PostgreSQL, но появилась поддержка других баз
Спасибо
Нет, только PostgreSQL. Не хочу распылять фокус проекта. Для меня важнее быть лучшим в чем-то одно, чем средним/хорошим в нескольких БД
Да
Точнее некоторые пользователи уже её сделали поверх Docker'a без изменений в самом проекте
Но и нативную поддержку тоже планирую сделать
Чем? Можете привести примеры, в которых такой подход привёл к негативным последствиям?
---
Я рад конструктивной критике. Но вы:
1) Сказали как "легко" собрать всё в бинарник, но только в теории без понимания устройств проекта.
Со стороны всё легко, а я спустя полгода развития проекта не разбираюсь, видимо :)2) Предложили переусложненный путь, который приведет к непредсказуемости окружения, увеличению стоимость сопровождения проекта и усложнению пользовательского пути.
При этом не объяснили, какие преимущества даёт такой подход в обмен на всех эти минусы (в равнении с тем, который сейчас отлично работает).
Судя по сообщениям выше, это должно убрать оверхед докера в ~0.01%.
3) Обосрали проект. Не рассказав, какое решение сопоставимого размера вы выложили в open source и принесли сопоставимую пользу людям.
Легко критиковать усилия других людей, не выставляя свои решения напоказ.
Я посмотрел ваш GitHub, но нашёл только заброшенный dev kit восьмилетней давности и сборник скриптов из ощутимого.
Поэтому не совсем понял, откуда такая экспертиза в том, как
другим проектамнужно поставлять системы, состоящие из API, фронта, базы и других утилит. Может покажете пример?...а зачем это всё, если можно удобно сложить всё в один образ, чтобы систему можно было запустить одной командой на любой ОС (Windows, MacOS, Linux) и нескольких архитектурах (amd64 и ARM)?
Сейчас удобный CI \ CD, полное покрытие тестами с предсказуемой средой, воспроизводимость среды на серверах пользователей. И удобный пользовательский путь — что очень важно
В вашем варианте исчезает предсказуемость среды, постоянно нужно обновлять бинарники и заставлять пользователя делать лишние действия. Не очень user friendly получается...
Совсем не только бинарник. Я даже в теории не знаю, как засунуть все функции Postgresus в один бинарник...
https://github.com/RostislavDugin/postgresus
Там и бек, и фронт, и внутренняя БД, и
pg_dumpбинарники PG 12-18, и сборка под разные архитектуры. Без докера это удобно поставлять не выйдетМинимальные требования для Postgresus - это 512 Мб RAM и 1 vCPU (вот тут детальнее). На условный Raspberry Pi влезет
Да и у Docker'а оверхед 0.1% на уровне погрешности (пример)
Совсем без Docker'a нет. Но для Ubuntu \ Debian есть скрипт установки, который сначала установить Docker, а потом Postgresus - https://postgresus.com/installation#option-1-automated-script
Неожиданно, что Postgresus включили в сборку. Спасибо :)
Второй?)
Спасибо за статью, давно с таким интересном не читал)
Но, честно говоря, немного удивился от объема запроса пользователей. У меня тоже open source инструмент для бекапа PostgreSQL - https://github.com/RostislavDugin/postgresus
Но запросы обычно по делу: или баг репорты, или действительно наболевшее. Только в ~20% случаев приходится писать "это не нужно 95% пользователей, поэтому такое делать не буду"
Не уверен, потому что в библиотеки не выйдет встроить что-то, что может работать после завершения работы самого приложения
Добрый день, спасибо
Логи самих контейнеров - к сожалению, нет. Log Bull все-таки ориентирован на код. Хотя, в теории, если этих логи засунуть в HTTP и отправить через curl - тогда можно
сравнения аналогичными существующими решениямиОбъективное сравнение возможно разве что по метрикам и перформансу, а это не приоритет проекта. По производительности что-то среднее между ELK и Loki. В целом, может даже и похуже обоих (но какая разница, если логов не тысячи в секунду?)
Приоритет - это удобный UX для разработчика. Просто установить, просто отправить через библиотеку, удобно смотреть логи. Но это, все-таки - субъективная оценка
Почему было не взять в качестве сервера, например, rsyslog, если у вас midsize проект, и сосредоточится на интерфейсе управленияТак тоже можно. Но я знаком с OpenSearch, поэтому взял его. Которому, в каком-то смысле, и сделал интерфейс управления для просмотра логов и разделения между проектами
Почему во всех примерах httpПотому что с HTTPS сложнее деплой и нужен домен. А приоритет Log Bull - максимально простой деплой. Просто
docker compose up -dне сработает. Если информация действительно sensetive, я бы лучше взял ELK и DevOps'a, который его настроит