Автоматическая установка следующего очередного обновления (далее - АУ) предназначена для обновления клиентских компьютеров и не должна применяться для серверов, то есть для компьютеров, предоставляющих разделяемые ресурсы и сервисы для других компьютеров.
Относительно утилиты обновления: промежуточный вариант - для служб сначала происходит перенос настройки из старой системы, потом пробуем стартануть, если не выходит - возвращаем дефолтные настройки от новых пакетов.
Также есть возможность использовать пользовательские скрипты, в которых можно задать перенос нестандартных/кастомных конфигов.
Об этом поговорим подробнее наверное во второй части статьи, спасибо за вопросы и интересы.
Добрый день. Рад, что сразу появились технические вопросы, так как думал готовить вторую часть статьи или нет, но теперь понятно, что она точно нужна. Заранее сделаю спойлеры, у нас было 2 версии коллекции под новый и старый ansible (отличия были не большие). Версии питона на конечных клиентах мы не правили.
Масштабирование по расписанию (Cron) — можно использовать CronJob для изменения количества реплик в определённое время (например, увеличивать днём, уменьшать ночью). Но это не встроено в HPA, реализуется через kubectl scale по расписанию или через операторы.
HPA "не знает", что завтра в 9 утра случится наплыв пользователей. Он начнет масштабироваться только тогда, когда этот наплыв уже произойдет, и при наличии небольшой пролага пока развернуться новые поды, может получить небольшие тормоза.
А зная что завтра 8 марта, или еще какая-то акция или обучение, мы заранее говорим системе, подготовь мне к утру следующего дня не 5, а 10 реплик, и убери их после конца рабочего дня
Базовая статья, по обычному функционалу k8s. Но в начале статьи есть байт:
на деле «из коробки» это не работает.
И далее нам рассказали как работают все возможные автоскейлы, KEDA, CA и тому подобные вещи . Однако про cronjob не добавили, ну и ладно. Тогда получается, вы просто использовали уже известный функционал и настроили его для своего приложение ( кластера, стенда ). Очень похоже, что темы была сгенерена ИИшкой, и далее статью причесали на человеческий язык и добавили каких-то подробностей ( не осуждаю, как источник вдохновения ИИ - ок )
Я с вами полностью согласен и не претендую на гуру модулей. Просто показал с чего начал, для чего была необходимость, а модуль появился уже для другой задачи, и решил весь путь объединить в статью.
Конечно, буду разбираться с модулями и автотестами благодаря сообществу!
Ну и вам спасибо, что хоть и критикуете, но говорите о правильных вещах и по делу.
Приветствую, так я и сказал вот мой пр, чтобы люди после статьи могли придти и посмотреть.
А линтеры поругались только на тесты в их ci/cd. А сам код уже все ок, там все поправлено и сделано.
А с тестами сложно протестировать этот модуль в рамках ci/cd, так как опыт написания тестов у меня не большой и я попросил помощи коллег в ПР с тестами.
Приветствую! Очень подробно и по теме, но не со всем я готов согласиться. На то это и форум, где каждый говорит что думает, а мой код - это опенсорс, и любой может прийти и добавить комментарии в PR.
Отказались от публичного, поддерживаемого API
Я не отказался, а как вы правильно указали сделал углубленное изучение общения утилиты и системы. Далее просто убрал утилиту, и общаюсь самостоятельно, минуя proxy в лице sssctl
Про «минимальное количество зависимостей» особенно показательно
Dbus-python vs sssd-tools — это переход от функциональной зависимости к системной абстракции. D-Bus — это стандартный системный IPC-механизм, который уже присутствует в любом современном дистрибутиве. Это как заменить прямой вызов конкретной программы на использование системного сокета.
Жёсткая привязка к infopipe
Жёсткая привязка к infopipe — но это и есть официальный публичный D-Bus интерфейс SSSD, зарегистрированный в системе. Это не reverse engineering, а использование предоставленного разработчиками SSSD API, который более стабилен, чем парсинг CLI вывода.
Зависимость от конкретной реализации SSSD
Dbus-python является стандартной библиотекой для работы с системной шиной, тогда как sssd-tools — это специфичная утилита конкретного пакета. Первая является частью экосистемы системного программирования на Python, вторая — внешней CLI обёрткой.
Заметный прирост производительности» без единого замера — это отдельный жанр технической фантастики
Вы правы в том, что я не предоставил детальных замеров производительности — это действительно упущение, которое стоило бы исправить.
Однако позвольте объяснить, почему даже без точных цифр этот подход даёт системные преимущества.
Вы утверждаете, что sssctl тоже использует D-Bus, но здесь есть принципиальная разница: прямой вызов метода против запуска процесса, который внутри себя делает тот же вызов.
Даже если накладные расходы на запуск процесса составляют миллисекунды, в контексте Ansible-модуля, выполняющегося на сотнях хостов, эта разница становится значимой.
Но что ещё важнее — это качество интеграции. Для модуля Ansible, который должен быть предсказуемым и лёгким, прямой D-Bus вызов — это более чистая архитектура, даже если абсолютный прирост скорости измеряется миллисекундами на одном вызове.
Хардкод путей вида: /org/freedesktop/sssd/infopipe/Domains/{domain.replace(".", "_2e")}
Путь /org/freedesktop/sssd/infopipe/Domains/{domain} — это не хардкод в смысле "зашитых значений", а следование документально зафиксированной схеме D-Bus именования, которую использует сам SSSD.
Кодирование точки как _2e — это стандартное преобразование D-Bus для специальных символов в object paths, а не произвольное решение.
Важный нюанс: если разработчики SSSD изменят эту схему путей в будущей версии, то сломается не только мой код, но и любой другой софт, использующий этот интерфейс, включая потенциально GUI-утилиты и системные мониторинговые инструменты. D-Bus интерфейсы, особенно зарегистрированные в системе, имеют определённые ожидания стабильности.
Ansible-модуль — отдельная категория
Мой PR открыт для комментариев, на то это и open-source
Так я разработчик AstraWizard, я пишу то, что хочу.
Я делаю тесты и показываю их не видео.
Я не пишу что-то просто, чтобы делать тесты на молекуле.
Это не обычные роли или коллекции, которые легко проверить, учитывая всю мою обертку на баш и гуи.
Я не заявлял , что я пишу что-то на ansible , я сказал я его использую под капотом, чтобы удаленно выполнять то, что моя первая версия софта делала локально через баш.
То есть расписать пример использования утилиты = целая статья на Хабре?
Причем с ошибками, опечатками, и иногда не понятными комментариями.
Как будто иишке сказали: у меня есть инструмент, опиши чо как куда кого, и даже не читая выхлоп вставили сюда и добавили три скрина
Добрый день, вы правы - это только для десктопных версий.
Это ограничения самой утилиты обновления.
Оф.документация - https://wiki.astralinux.ru/pages/viewpage.action?pageId=333809857
Автоматическая установка следующего очередного обновления (далее - АУ) предназначена для обновления клиентских компьютеров и не должна применяться для серверов, то есть для компьютеров, предоставляющих разделяемые ресурсы и сервисы для других компьютеров.
случайно
Добрый день, к сожалению нет. Утилита мажорного обновления сделана для перехода с 1.7 до 1.8.
В коллекции мы делали одноэтапное обновление с 1.7.х до 1.8 путем обновления ОС 1.7х до актуальной и далее сразу же мажорное обновление.
В случае с 1.6 старая пакетная база и отсутствуют утилиты для обновления
Добрый день.
Относительно утилиты обновления: промежуточный вариант - для служб сначала происходит перенос настройки из старой системы, потом пробуем стартануть, если не выходит - возвращаем дефолтные настройки от новых пакетов.
Также есть возможность использовать пользовательские скрипты, в которых можно задать перенос нестандартных/кастомных конфигов.
Об этом поговорим подробнее наверное во второй части статьи, спасибо за вопросы и интересы.
Добрый день.
Рад, что сразу появились технические вопросы, так как думал готовить вторую часть статьи или нет, но теперь понятно, что она точно нужна.
Заранее сделаю спойлеры, у нас было 2 версии коллекции под новый и старый ansible (отличия были не большие).
Версии питона на конечных клиентах мы не правили.
Масштабирование по расписанию (Cron) — можно использовать
CronJobдля изменения количества реплик в определённое время (например, увеличивать днём, уменьшать ночью). Но это не встроено в HPA, реализуется черезkubectl scaleпо расписанию или через операторы.HPA "не знает", что завтра в 9 утра случится наплыв пользователей. Он начнет масштабироваться только тогда, когда этот наплыв уже произойдет, и при наличии небольшой пролага пока развернуться новые поды, может получить небольшие тормоза.
А зная что завтра 8 марта, или еще какая-то акция или обучение, мы заранее говорим системе, подготовь мне к утру следующего дня не 5, а 10 реплик, и убери их после конца рабочего дня
Базовая статья, по обычному функционалу k8s.
Но в начале статьи есть байт:
И далее нам рассказали как работают все возможные автоскейлы, KEDA, CA и тому подобные вещи . Однако про cronjob не добавили, ну и ладно.
Тогда получается, вы просто использовали уже известный функционал и настроили его для своего приложение ( кластера, стенда ). Очень похоже, что темы была сгенерена ИИшкой, и далее статью причесали на человеческий язык и добавили каких-то подробностей ( не осуждаю, как источник вдохновения ИИ - ок )
https://docs.ansible.com/projects/ansible/latest/collections/community/general/sssd_info_module.html#ansible-collections-community-general-sssd-info-module
PR принят, в ближайшие недели ожидается релиз в 12.2 версии
Я с вами полностью согласен и не претендую на гуру модулей. Просто показал с чего начал, для чего была необходимость, а модуль появился уже для другой задачи, и решил весь путь объединить в статью.
Конечно, буду разбираться с модулями и автотестами благодаря сообществу!
Ну и вам спасибо, что хоть и критикуете, но говорите о правильных вещах и по делу.
Приветствую, так я и сказал вот мой пр, чтобы люди после статьи могли придти и посмотреть.
А линтеры поругались только на тесты в их ci/cd. А сам код уже все ок, там все поправлено и сделано.
А с тестами сложно протестировать этот модуль в рамках ci/cd, так как опыт написания тестов у меня не большой и я попросил помощи коллег в ПР с тестами.
Приветствую! Очень подробно и по теме, но не со всем я готов согласиться.
На то это и форум, где каждый говорит что думает, а мой код - это опенсорс, и любой может прийти и добавить комментарии в PR.
Я не отказался, а как вы правильно указали сделал углубленное изучение общения утилиты и системы.
Далее просто убрал утилиту, и общаюсь самостоятельно, минуя proxy в лице sssctl
Dbus-python vs sssd-tools — это переход от функциональной зависимости к системной абстракции. D-Bus — это стандартный системный IPC-механизм, который уже присутствует в любом современном дистрибутиве. Это как заменить прямой вызов конкретной программы на использование системного сокета.
Жёсткая привязка к infopipe — но это и есть официальный публичный D-Bus интерфейс SSSD, зарегистрированный в системе. Это не reverse engineering, а использование предоставленного разработчиками SSSD API, который более стабилен, чем парсинг CLI вывода.
Dbus-python является стандартной библиотекой для работы с системной шиной, тогда как sssd-tools — это специфичная утилита конкретного пакета. Первая является частью экосистемы системного программирования на Python, вторая — внешней CLI обёрткой.
Вы правы в том, что я не предоставил детальных замеров производительности — это действительно упущение, которое стоило бы исправить.
Однако позвольте объяснить, почему даже без точных цифр этот подход даёт системные преимущества.
Вы утверждаете, что sssctl тоже использует D-Bus, но здесь есть принципиальная разница: прямой вызов метода против запуска процесса, который внутри себя делает тот же вызов.
Даже если накладные расходы на запуск процесса составляют миллисекунды, в контексте Ansible-модуля, выполняющегося на сотнях хостов, эта разница становится значимой.
Но что ещё важнее — это качество интеграции. Для модуля Ansible, который должен быть предсказуемым и лёгким, прямой D-Bus вызов — это более чистая архитектура, даже если абсолютный прирост скорости измеряется миллисекундами на одном вызове.
Путь /org/freedesktop/sssd/infopipe/Domains/{domain} — это не хардкод в смысле "зашитых значений", а следование документально зафиксированной схеме D-Bus именования, которую использует сам SSSD.
Кодирование точки как _2e — это стандартное преобразование D-Bus для специальных символов в object paths, а не произвольное решение.
Важный нюанс: если разработчики SSSD изменят эту схему путей в будущей версии, то сломается не только мой код, но и любой другой софт, использующий этот интерфейс, включая потенциально GUI-утилиты и системные мониторинговые инструменты.
D-Bus интерфейсы, особенно зарегистрированные в системе, имеют определённые ожидания стабильности.
Мой PR открыт для комментариев, на то это и open-source
https://github.com/ansible-collections/community.general/pull/11120
Супер! Спасибо что подробно и по теме.
Благодарю за информацию
Так понимаю не open-source, а чисто идея и общий концепт разобран? Или можно подглядеть ваши исходнички?
пока что нет.
В скором времени будет доступно начиная с версии 3.0.0.
https://www.tadviser.ru/index.php/Статья:Алексей_Фоменко,_Группа_Астра:_служба_каталога_ALD_Pro_трансформирует_разрозненную_ИТ-инфраструктуру_в_управляемую_систему?erid=no
Можно оформить ПР. Я буду только рад развитию проекта с помощью сообщества
Согласен, есть что доработать.
Но пароль не видно в открытом виде нигде.
History и логи не видно пароля, насколько я смотрел.
Так я разработчик AstraWizard, я пишу то, что хочу.
Я делаю тесты и показываю их не видео.
Я не пишу что-то просто, чтобы делать тесты на молекуле.
Это не обычные роли или коллекции, которые легко проверить, учитывая всю мою обертку на баш и гуи.
Я не заявлял , что я пишу что-то на ansible , я сказал я его использую под капотом, чтобы удаленно выполнять то, что моя первая версия софта делала локально через баш.
спасибо я знаю в чем разница.
Проекту более 2-х лет. Использования bash не более чем мое удобство, и не желания плодить множество файлов с шаблонами.
Данный код не виден конечному пользователю, а красота для меня стоит на втором месте, после функционала полезного конечному пользователю.