Вас могут задеть мои слова, поэтому не воспринимайте, пожалуйста, на личный счёт - это скорее накапливающаяся боль от того, что в ИТ перестали считать деньги от слова совсем как будто.
Вот я взял просто калькулятор того же Облако Яндекс (у них как раз средние цены "по больнице") и посчитал из ваших рассказов стоимость и вот что примерно получилось:
примерно 1.5 млн просто за виртуальные машины и память (считал 20% нагрузки самого дешёвого проца)
считал что это входит в первый пункт
примерно 820к просто за хранилище данных (даже GET-запросы не считал)
это отдельно посчитать от п.1?
даже не считал сеть и запросы наружу, которых явно должно быть много при таком объёме в базах и т.п.
И это всё (ориентировочно с сетью и доп.расходами на разные сервисы 3млн рублей) в месяц и три вообще не напрягающихся инженера. При этом описанная конфигурация уместится в две стойки (одна из которых тупо ИБП промышленного уровня) и не требует особого обслуживания (раз в месяц сдохший SSD менять). Даже если раскидать это по трём разным ДЦ, заложить зп отдельного сетевика, ещё пары линуксоидов и пары дежурных - такая конфигурация отобъётся за год на bare-metal. При этом, если бизнесу не нужно четыре девятки после запятой по доступности (а если вы не маркетплейс где каждую минуту оформляется 100 заказов или вы не система мониторинга транспорта/газопровода/авиарейсов или вы не связаны с онлайн процессингом и т.п. то скорее всего так и есть), то можно и проще сделать, при этом отбить стоимость по сравнению с облаком за полгода.
Если CTO такой расклад устраивает, то у меня как бизнеса было бы дофига вопросов к квалификации. Это от создателей "хадупа на 500Гб" и "доступности интернет-магазина с оборотом меньше 1млн руб на 99.99999%".
Представил себе ситуацию у меня при переезде на bare-metal
То что вы описали это прям очень маленькая инфраструктура, ради которой даже облако вроде OpenStack/CloudStack/OpenNebula не нужно разворачивать и можно уложиться в VMWare/ProxmoxVE/oVirt (хотя тут спорно насчёт последнего куда его относить). Если девопсы всё же потрудятся, то могут всю эту инфраструктуру автоматизировать обычным Ansible/Terraform даже без контейнеров и Kubernates и втроём смотреть в красивые дашборды.
Единственное, когда облако выгоднее чем bare-metal, это резко меняющаяся нагрузка с крутыми и короткими пиками нагрузки (чёрная пятница, экстренные новости и т.п.) или с периодическими крупными параллельными вычислениями (вроде научных или там всякие аналитические обработки), которые требуют резкого увеличения количества стоек (не серверов, а именно стоек с плотно упакованными серверами). А вторая категория "облачного смузихлёбства" это прям наноорганизации или стартапы, когда ещё неизвестно взлетит ли проект вообще, чтобы реализовать минимально работоспособный продукт и выпустить его с готовностью перенести всё на bare-metal, как только проект вырастет и стабилизируется. Но в такой организации отдельные инженеры это прям вообще трата денег на ветер, если это не дешёвые дежурные глазастики.
Я в ИТ прошёл и путь "красноглазика-гентушника" и путь "сеньора-помидора смузиразработчика". Чем больше трудится маркетолог облачных провайдеров или инфоцыган курсов по ИТ, тем грустнее мне становится.
Единственное, когда облако может быть лучше bare-metal - отсутствие в компании 2-3 более или менее адекватных админов. Но даже тогда, порой достаточно дешёвых vps.
Ну не может быть в облаке дешевле, просто потому что в реальном мире арифметика положительных чисел только увеличивает итог, но никак не уменьшает. Полно инструментов, чтоб поднять достаточно отказоустойчивую систему виртуализации, которые чуть ли не сами за собой следят и обслуживают.
Единственное преимущество облака: кнопка "сделать хорошо" (обновить кластер бд, куба и т.п.). Но даже это преимущество в какой-то момент становится недостатком, потому что приходится сталкиваться с теми или иными ограничениями.
Согласен, ранчер в угоду stupid-friendly интерфейса стал тяжеловат. Но зато обновления из коробки, мониторинг и управление всеми кластерами из одного интерфейса прям подкупает.
А можете поделиться как вы werf converge пользуетесь для нескольких кластеров в CI? Используете matrix или хардкодите конфиги? Просто интересно, как вы динамически добавляете кластера.
Ну вообще есть, через патчинг самого арго - почитайте доку у верфи. Но я вас услышал.
Лично мне у верфи converge не зашёл из-за гитерменизма, поэтому выкатываю бандлы, а самописным оператором (исходники открыты, бандл тоже есть для удобства) выкатываю их с переменными на разных окружениях.
Тогда если вы ArgoCD не пользуете почти, что мешало управлять всем через Rancher Server? У них даже своя CD есть, управление чартами и весьма гуёвенько. К тому же обновлять k3s можно по клику.
Мне не надо играть в "русскую рулетку", чтобы понять, что это может вынести мне мозг на стену. А вот опыт, когда разработчик в торопях полагается на "угадайку" и получает неожиданный результат видел лично.
Можно сколько угодно спорить, но ненадёжная подсказка иногда хуже её отсутствия. Использование ChatGPT последние полгода тому опытное доказательство.
Ну и вы мне пытаетесь что доказать? Я вполне конкретно обозначил, что в достаточно большом проекте, в который регулярно что-то куда-то мержат и берут наработки друг друга до попадания их в основные ветки, используют squash при мержах и т.п. эта угадайка вообще офигеет и никогда не найдёт исходной ветки. Зачем тогда функционал, который будет больше путать, чем помогать? А маленькие проекты и без этого прям прекрасно справляются.
А мы вот на лету научились парсить схему и делать приложения практически без написания js/ts кода. Это я так, хвастаюсь. А если серьёзно, то это капец удобно. Очень много времени на разработку экономит. Но требует определённой дисциплины: стандартные интерфейсы, изначально качественный дизайн и т.п.
Используем swagger-typescript-api, но там мерзкий баг с camelCase преобразованием из snake_case. Спасибо, что подкинули куда ещё посмотреть.
Не знаю что у вас за проект, его масштабы и количество коммитов, но в команде 5-6 человек и регулярной выкаткой это всё бесполезным и нерабочим становится от слова совсем. Угадайка больше опасна, чем полезна.
Никогда не пойму прикола всех этих компиляторов. Прирост минимальный, результат - непредсказуемый.
В этом плане либо проще написать код на C-API, либо даже на Rust (pyo), потому что есть хорошие инструменты. Если прям совсем хочется не париться, есть Cython, где прям можно миксовать код на python и cython. Ну сконцентрировали бы лучше усилия на этих инструментах, зачем плодить несовместимые решения?
Если у proxmox подключён zfs на хранилище и zfs на backup server, то очень часто проще, предсказуемее и эффективнее сделать через backup/restore. Потому что в 99% случаев минимальные простои ни на что не влияют, кроме красивых 9 после запятой.
Но в этой статье решение интересное. Правильно ли я понял, что структуру хранилищ на конечном кластере можно тоже безопасно изменить, подключив, например, диски к разным хранилищам?
Просто выглядит как заход с чёрного хода и начинаешь в такие моменты думать где потом сломается.
Побольше бы таких статей на Хабре. Михаил, спасибо за интересное чтиво.
Конечно всю статью можно сократить до заголовка, что динамическая длина плохо для больших данных и кеша в памяти у СУБД, но так более развёрнуто для джунов что-ли. В этом плане меня всегда восхищали архитекторы систем, которые смотрели вперёд и проектировали систему так, что после их ухода из проекта сталкиваясь с их решениями ты вспоминаешь их добрым словом. Это бывает крайне редко, конечно, но хочется быть таким человеком.
Пока читал вспомнил случай с этой же проблемой.
Байка
В общем, меня знакомый позвал помочь с решением одной проблемы похожего плана, что таблица начинала нещадно тормозить на запросах через какое-то время. Это была база какой-то самописной системы управления инцидентами (что иронично) и мониторинга, в которой после деплоя новой версии появлялось очень много уведомлений, которые закрывались с каким-то комментарием. На основе этой таблицы происходила некоторая аналитика и срез её раз в месяц отправлялся на почту.
Так вот, в один прекрасный день этот отчёт вместо одного часа начал завис почти на сутки. Сначала мой знакомый обратился по моему совету к тому, кто на мой взгляд "шарил" в MariaDB. Он как раз получил совет - OPTIMIZE TABLE. Собственно это и было сделано. Но проблема возникла снова уже через месяц и задача уже зависла на почти 2 суток. Сначала в лоб было предложено решение делать OPTIMIZE TABLE перед каждым запуском таски. Но как оказалось, операция была тоже не быстрая и хотелось найти проблему.
Собственно, я спросил что менялось за последние 3-4 месяца в системе. Ничего существенного не было. Изменения были в разработке - стали чаще релизить на прод, от чего количество уведомлений в систему увеличилось. Ещё одно изменение было в том, что из-за частых релизов, начали происходить частые откаты. Не буду в даваться в подробности, но мы снова обратились к знакомому "эксперту". Вариант вызывать OPTIMIZE TABLE каждый день не понравился нам обоим, поэтому мы начали копать дальше.
Самое забавное, когда оказалось, что при переходе этой самописной системы с чего-то там и палок на фреймворк, они создали ORM соответствующий имеющимся таблицам. Но фреймворк по умолчанию как раз для миграций использует varchar, поэтому при скромном изменении длины в большую сторону, миграция создалась автоматически и изменила тип поля. Это было много раньше (почти год до начала событий), но проявилось после того как стали чаще релизить проект.
Я проникся уважением к админу, который писал изначально эту систему под себя, когда мы подключили его к проблеме (он и указал на решение). Он как раз сказал, что при планировании таблицы у него было желание сразу использовать varchar, но он заметил, что комментарий после закрытия всегда есть и он осмысленный (занимает почти весь размер), поэтому такая оптимизация бессмысленна, а char "ровнее в память ложится" (цитата). Вот что значит понимать как устроен современный CPU!
Мне тогда так стыдно стало, что я даже не подумал об этом. И правда, свободное место на диске прям не драматично изменилось, а скорость вернулась на круги свои.
Насчёт чуваков, которые округляют глаза на "в GET может быть тело". Я думаю они справедливо их округляют, если они читали RFC7231 или RFC2616:
A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.
The GET method means retrieve whatever information ([...]) is identified by the Request-URI.
A server SHOULD read and forward a message-body on any request; if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request.
Там как бы в обоих подразумевается, что GET-запрос не может и не должен иметь тело. Это вообще может оказаться неожиданностью для клиента и сервера. А тех, кто так делает надо сжигать на костреприкладывать головой об распечатанный RFC вразумлять и исправлять.
А насчёт "не бывает api кроме rest", я надеюсь вы хотели сказать наоборот, что бывает, но есть те, кто не понимает расшифровки этой аббревиатуры? Ведь так?
VMWare можно сравнивать с Hyper-V, Proxmox, oVirt, потому что они на одном уровне абстракции.
OpenStack выше уровнем абстракции и может под капотом легко работать в VMWare, Hyper-V, KVM, LXC и прочими. Видел даже управление виртуалками в AWS через OpenStack (решение было временное и на коленках, но оцените размах!). Ближайшие аналоги это OpenNebula и Apache CloudStack.
https://github.com/vstconsulting/polemarch - оркестратор инфраструктуру с очень крутой системой плагинов, чтобы заточить практически под любые нужды (разница с энтерпрайзной версией, которая тоже есть, в том, что там некоторые нужды уже из коробки и всё). Основной инструмент - Ansible, но можно написать свои плагины под всё, что можно запустить: terraform, bash, скрипты и т.п. Есть встроенный планировщик выполнения задач, проекты, шаблоны и история запуска. Лицензия AGPLv3/EULA (в зависимости от редакции).
https://github.com/vstconsulting/vstutils - платформа, на которой написан Polemarch. По сути это фреймворк фреймворков, нацеленный на то, чтобы уменьшить количество кода и получать максимально быстро GUI из API. Недавно статью писал по то, как мы придумали этот проект. Лицензия Apache.
https://github.com/onegreyonewhite/configparserc - типизированный парсер конфигов для Python. На выходе получается типа словарь или можно получить прям словарь. Может переваривать довольно большие файлы конфигов, с некоторым ускорением по отношению к стандартному ConfigParser. Лицензия Апач.
Вообще чтоб авторизацию по сертификату производить. Но хранилище то же самое. Кажется Android даже не спрашивает для чего его использовать. Просто сертификат для vpn и приложений.
Вас могут задеть мои слова, поэтому не воспринимайте, пожалуйста, на личный счёт - это скорее накапливающаяся боль от того, что в ИТ перестали считать деньги от слова совсем как будто.
Вот я взял просто калькулятор того же Облако Яндекс (у них как раз средние цены "по больнице") и посчитал из ваших рассказов стоимость и вот что примерно получилось:
примерно 1.5 млн просто за виртуальные машины и память (считал 20% нагрузки самого дешёвого проца)
считал что это входит в первый пункт
примерно 820к просто за хранилище данных (даже GET-запросы не считал)
это отдельно посчитать от п.1?
даже не считал сеть и запросы наружу, которых явно должно быть много при таком объёме в базах и т.п.
И это всё (ориентировочно с сетью и доп.расходами на разные сервисы 3млн рублей) в месяц и три вообще не напрягающихся инженера. При этом описанная конфигурация уместится в две стойки (одна из которых тупо ИБП промышленного уровня) и не требует особого обслуживания (раз в месяц сдохший SSD менять). Даже если раскидать это по трём разным ДЦ, заложить зп отдельного сетевика, ещё пары линуксоидов и пары дежурных - такая конфигурация отобъётся за год на bare-metal. При этом, если бизнесу не нужно четыре девятки после запятой по доступности (а если вы не маркетплейс где каждую минуту оформляется 100 заказов или вы не система мониторинга транспорта/газопровода/авиарейсов или вы не связаны с онлайн процессингом и т.п. то скорее всего так и есть), то можно и проще сделать, при этом отбить стоимость по сравнению с облаком за полгода.
Если CTO такой расклад устраивает, то у меня как бизнеса было бы дофига вопросов к квалификации. Это от создателей "хадупа на 500Гб" и "доступности интернет-магазина с оборотом меньше 1млн руб на 99.99999%".
То что вы описали это прям очень маленькая инфраструктура, ради которой даже облако вроде OpenStack/CloudStack/OpenNebula не нужно разворачивать и можно уложиться в VMWare/ProxmoxVE/oVirt (хотя тут спорно насчёт последнего куда его относить). Если девопсы всё же потрудятся, то могут всю эту инфраструктуру автоматизировать обычным Ansible/Terraform даже без контейнеров и Kubernates и втроём смотреть в красивые дашборды.
Единственное, когда облако выгоднее чем bare-metal, это резко меняющаяся нагрузка с крутыми и короткими пиками нагрузки (чёрная пятница, экстренные новости и т.п.) или с периодическими крупными параллельными вычислениями (вроде научных или там всякие аналитические обработки), которые требуют резкого увеличения количества стоек (не серверов, а именно стоек с плотно упакованными серверами). А вторая категория "облачного смузихлёбства" это прям наноорганизации или стартапы, когда ещё неизвестно взлетит ли проект вообще, чтобы реализовать минимально работоспособный продукт и выпустить его с готовностью перенести всё на bare-metal, как только проект вырастет и стабилизируется. Но в такой организации отдельные инженеры это прям вообще трата денег на ветер, если это не дешёвые дежурные глазастики.
Я в ИТ прошёл и путь "красноглазика-гентушника" и путь "сеньора-помидора смузиразработчика". Чем больше трудится маркетолог облачных провайдеров или
инфоцыганкурсов по ИТ, тем грустнее мне становится.Дешёвый макбук - вот так начинается апокалипсис.
Единственное, когда облако может быть лучше bare-metal - отсутствие в компании 2-3 более или менее адекватных админов. Но даже тогда, порой достаточно дешёвых vps.
Ну не может быть в облаке дешевле, просто потому что в реальном мире арифметика положительных чисел только увеличивает итог, но никак не уменьшает. Полно инструментов, чтоб поднять достаточно отказоустойчивую систему виртуализации, которые чуть ли не сами за собой следят и обслуживают.
Единственное преимущество облака: кнопка "сделать хорошо" (обновить кластер бд, куба и т.п.). Но даже это преимущество в какой-то момент становится недостатком, потому что приходится сталкиваться с теми или иными ограничениями.
Прям очень интересно как Postgres реагирует на alter в этом случае. Неужели только пересоздание таблицы может спасти ситуацию?
Согласен, ранчер в угоду stupid-friendly интерфейса стал тяжеловат. Но зато обновления из коробки, мониторинг и управление всеми кластерами из одного интерфейса прям подкупает.
А можете поделиться как вы werf converge пользуетесь для нескольких кластеров в CI? Используете matrix или хардкодите конфиги? Просто интересно, как вы динамически добавляете кластера.
Ну вообще есть, через патчинг самого арго - почитайте доку у верфи. Но я вас услышал.
Лично мне у верфи converge не зашёл из-за гитерменизма, поэтому выкатываю бандлы, а самописным оператором (исходники открыты, бандл тоже есть для удобства) выкатываю их с переменными на разных окружениях.
Тогда если вы ArgoCD не пользуете почти, что мешало управлять всем через Rancher Server? У них даже своя CD есть, управление чартами и весьма гуёвенько. К тому же обновлять k3s можно по клику.
Блин, ничего себе! Вы умудрились собрать весь мой любимый DevOps стек: k3s, werf, gitlab, victoria metrics, argo. Прям страйк в самое сердечко, ребят.
Вопрос: вы взяли ArgoCD только из-за werf operator'а?
Мне не надо играть в "русскую рулетку", чтобы понять, что это может вынести мне мозг на стену. А вот опыт, когда разработчик в торопях полагается на "угадайку" и получает неожиданный результат видел лично.
Можно сколько угодно спорить, но ненадёжная подсказка иногда хуже её отсутствия. Использование ChatGPT последние полгода тому опытное доказательство.
Ну и вы мне пытаетесь что доказать? Я вполне конкретно обозначил, что в достаточно большом проекте, в который регулярно что-то куда-то мержат и берут наработки друг друга до попадания их в основные ветки, используют squash при мержах и т.п. эта угадайка вообще офигеет и никогда не найдёт исходной ветки. Зачем тогда функционал, который будет больше путать, чем помогать? А маленькие проекты и без этого прям прекрасно справляются.
А мы вот на лету научились парсить схему и делать приложения практически без написания js/ts кода. Это я так, хвастаюсь. А если серьёзно, то это капец удобно. Очень много времени на разработку экономит. Но требует определённой дисциплины: стандартные интерфейсы, изначально качественный дизайн и т.п.
Используем swagger-typescript-api, но там мерзкий баг с camelCase преобразованием из snake_case. Спасибо, что подкинули куда ещё посмотреть.
Не знаю что у вас за проект, его масштабы и количество коммитов, но в команде 5-6 человек и регулярной выкаткой это всё бесполезным и нерабочим становится от слова совсем. Угадайка больше опасна, чем полезна.
Стесняюсь спросить, а как у гита узнать какой была родительская ветка? Или я чего-то не знаю о гите?
Никогда не пойму прикола всех этих компиляторов. Прирост минимальный, результат - непредсказуемый.
В этом плане либо проще написать код на C-API, либо даже на Rust (pyo), потому что есть хорошие инструменты. Если прям совсем хочется не париться, есть Cython, где прям можно миксовать код на python и cython. Ну сконцентрировали бы лучше усилия на этих инструментах, зачем плодить несовместимые решения?
Если у proxmox подключён zfs на хранилище и zfs на backup server, то очень часто проще, предсказуемее и эффективнее сделать через backup/restore. Потому что в 99% случаев минимальные простои ни на что не влияют, кроме красивых 9 после запятой.
Но в этой статье решение интересное. Правильно ли я понял, что структуру хранилищ на конечном кластере можно тоже безопасно изменить, подключив, например, диски к разным хранилищам?
Просто выглядит как заход с чёрного хода и начинаешь в такие моменты думать где потом сломается.
Побольше бы таких статей на Хабре. Михаил, спасибо за интересное чтиво.
Конечно всю статью можно сократить до заголовка, что динамическая длина плохо для больших данных и кеша в памяти у СУБД, но так более развёрнуто для джунов что-ли. В этом плане меня всегда восхищали архитекторы систем, которые смотрели вперёд и проектировали систему так, что после их ухода из проекта сталкиваясь с их решениями ты вспоминаешь их добрым словом. Это бывает крайне редко, конечно, но хочется быть таким человеком.
Пока читал вспомнил случай с этой же проблемой.
Байка
В общем, меня знакомый позвал помочь с решением одной проблемы похожего плана, что таблица начинала нещадно тормозить на запросах через какое-то время. Это была база какой-то самописной системы управления инцидентами (что иронично) и мониторинга, в которой после деплоя новой версии появлялось очень много уведомлений, которые закрывались с каким-то комментарием. На основе этой таблицы происходила некоторая аналитика и срез её раз в месяц отправлялся на почту.
Так вот, в один прекрасный день этот отчёт вместо одного часа начал завис почти на сутки. Сначала мой знакомый обратился по моему совету к тому, кто на мой взгляд "шарил" в MariaDB. Он как раз получил совет - OPTIMIZE TABLE. Собственно это и было сделано. Но проблема возникла снова уже через месяц и задача уже зависла на почти 2 суток. Сначала в лоб было предложено решение делать OPTIMIZE TABLE перед каждым запуском таски. Но как оказалось, операция была тоже не быстрая и хотелось найти проблему.
Собственно, я спросил что менялось за последние 3-4 месяца в системе. Ничего существенного не было. Изменения были в разработке - стали чаще релизить на прод, от чего количество уведомлений в систему увеличилось. Ещё одно изменение было в том, что из-за частых релизов, начали происходить частые откаты. Не буду в даваться в подробности, но мы снова обратились к знакомому "эксперту". Вариант вызывать OPTIMIZE TABLE каждый день не понравился нам обоим, поэтому мы начали копать дальше.
Самое забавное, когда оказалось, что при переходе этой самописной системы с чего-то там и палок на фреймворк, они создали ORM соответствующий имеющимся таблицам. Но фреймворк по умолчанию как раз для миграций использует varchar, поэтому при скромном изменении длины в большую сторону, миграция создалась автоматически и изменила тип поля. Это было много раньше (почти год до начала событий), но проявилось после того как стали чаще релизить проект.
Я проникся уважением к админу, который писал изначально эту систему под себя, когда мы подключили его к проблеме (он и указал на решение). Он как раз сказал, что при планировании таблицы у него было желание сразу использовать varchar, но он заметил, что комментарий после закрытия всегда есть и он осмысленный (занимает почти весь размер), поэтому такая оптимизация бессмысленна, а char "ровнее в память ложится" (цитата). Вот что значит понимать как устроен современный CPU!
Мне тогда так стыдно стало, что я даже не подумал об этом. И правда, свободное место на диске прям не драматично изменилось, а скорость вернулась на круги свои.
Насчёт чуваков, которые округляют глаза на "в GET может быть тело". Я думаю они справедливо их округляют, если они читали RFC7231 или RFC2616:
Там как бы в обоих подразумевается, что GET-запрос не может и не должен иметь тело. Это вообще может оказаться неожиданностью для клиента и сервера. А тех, кто так делает надо
сжигать на костреприкладывать головой об распечатанный RFCвразумлять и исправлять.А насчёт "не бывает api кроме rest", я надеюсь вы хотели сказать наоборот, что бывает, но есть те, кто не понимает расшифровки этой аббревиатуры? Ведь так?
А тем временем, Nginx ingress всё ещё на 1.23.4 версии (это они ещё обновились).
Поскорее бы завезли эту версию, чтобы попробовать http/3 не на traefik'е.
Так себе сравнение руки с пальцем.
VMWare можно сравнивать с Hyper-V, Proxmox, oVirt, потому что они на одном уровне абстракции.
OpenStack выше уровнем абстракции и может под капотом легко работать в VMWare, Hyper-V, KVM, LXC и прочими. Видел даже управление виртуалками в AWS через OpenStack (решение было временное и на коленках, но оцените размах!). Ближайшие аналоги это OpenNebula и Apache CloudStack.
Поэтому сравнение крайне странное.
И ведь строят же: kubevirt, harvester, что-то там флант ещё выкатил. Но не пойму - зачем? Обслуживать нифига не проще.
Раз уж пошла такая жара...
https://github.com/vstconsulting/polemarch - оркестратор инфраструктуру с очень крутой системой плагинов, чтобы заточить практически под любые нужды (разница с энтерпрайзной версией, которая тоже есть, в том, что там некоторые нужды уже из коробки и всё). Основной инструмент - Ansible, но можно написать свои плагины под всё, что можно запустить: terraform, bash, скрипты и т.п. Есть встроенный планировщик выполнения задач, проекты, шаблоны и история запуска. Лицензия AGPLv3/EULA (в зависимости от редакции).
https://github.com/vstconsulting/vstutils - платформа, на которой написан Polemarch. По сути это фреймворк фреймворков, нацеленный на то, чтобы уменьшить количество кода и получать максимально быстро GUI из API. Недавно статью писал по то, как мы придумали этот проект. Лицензия Apache.
https://github.com/onegreyonewhite/configparserc - типизированный парсер конфигов для Python. На выходе получается типа словарь или можно получить прям словарь. Может переваривать довольно большие файлы конфигов, с некоторым ускорением по отношению к стандартному ConfigParser. Лицензия Апач.
https://github.com/onegreyonewhite/pytimeparse2 - уже самостоятельный форк pytimeparse, но с поддержкой большего количества дат (месяцы, годы, миллисекунды) и timedelta. Лицензия MIT.
Надеюсь проекты будут полезны сообществу.
Вообще чтоб авторизацию по сертификату производить. Но хранилище то же самое. Кажется Android даже не спрашивает для чего его использовать. Просто сертификат для vpn и приложений.