Это уже лишние, все задачи внутри ВМ делает сам packer через провижинеры. Чтобы как раз не подключаться к установленной вм по ссш, не узнавать ее айпи и тд.
Ansible лишь инструмент для того чтобы собрать все файлы на билдере, запустить пакер, и собрать результат.
Пакер в части сборки, установки, запуска выгрузки и тд делает сам
Приветствую, так я и использую kickstart - в моем случае sberos на базе rpm, поэтому использую ks.cfg ( ks.cfg - это и есть KickStart сокращенная аббревиатура).
А packer нужен чтобы из iso установить полностью операционную систему и провижинер VB для работы через него, и далее настроить ее созданную вм.
я полный удаленщик, и когда я приезжал в командировки в офис, или на выступления/конференции и далее коллеги шли в бар, или на кофе-брейк, мы обсуждали все в живую и быстро. И когда у вас много продуктовых команд, то офлайн встречи дают не шаг в развитии, а скорей всего прыжок.
Автоматическая установка следующего очередного обновления (далее - АУ) предназначена для обновления клиентских компьютеров и не должна применяться для серверов, то есть для компьютеров, предоставляющих разделяемые ресурсы и сервисы для других компьютеров.
Относительно утилиты обновления: промежуточный вариант - для служб сначала происходит перенос настройки из старой системы, потом пробуем стартануть, если не выходит - возвращаем дефолтные настройки от новых пакетов.
Также есть возможность использовать пользовательские скрипты, в которых можно задать перенос нестандартных/кастомных конфигов.
Об этом поговорим подробнее наверное во второй части статьи, спасибо за вопросы и интересы.
Добрый день. Рад, что сразу появились технические вопросы, так как думал готовить вторую часть статьи или нет, но теперь понятно, что она точно нужна. Заранее сделаю спойлеры, у нас было 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
Это уже лишние, все задачи внутри ВМ делает сам packer через провижинеры. Чтобы как раз не подключаться к установленной вм по ссш, не узнавать ее айпи и тд.
Ansible лишь инструмент для того чтобы собрать все файлы на билдере, запустить пакер, и собрать результат.
Пакер в части сборки, установки, запуска выгрузки и тд делает сам
да это понятно, можно было и с паролем не париться и не отключать судо, а делать например:
echo “$password” | sudo -S dnf clear
Да согласен с вами, но я щас посмотрел с ПК еще раз.
Так у меня так и используется:
Только права на файл не выставил, а так у меня же создается дефолтный user с именем user )
Все верно, это образ чтобы пользователь далее от которого действует packer, смог работать от рута для установки пакетов и настройки системы.
В самом образе далее вы даже не будете знать об этом пользователе.
Цель образа сделать образ ОС и настроить его для облака, а далее через облако вы настраиваете пользователей ключи и тд.
Стоит просто добавить в конце 1 строчку кода, чтобы вернуть обратно запрет на судо без пароля.
Это не рекомендации от нас, это то, как все можно настроить, а как настраивать и кому это ваше дело.
Я лишь показал инструменты, и их возможности которые в силу своего опыта я смог раскрыть
Приветствую, так я и использую kickstart - в моем случае sberos на базе rpm, поэтому использую ks.cfg ( ks.cfg - это и есть KickStart сокращенная аббревиатура).
А packer нужен чтобы из iso установить полностью операционную систему и провижинер VB для работы через него, и далее настроить ее созданную вм.
Установка идет автоматом через файл kickstart.
я полный удаленщик, и когда я приезжал в командировки в офис, или на выступления/конференции и далее коллеги шли в бар, или на кофе-брейк, мы обсуждали все в живую и быстро. И когда у вас много продуктовых команд, то офлайн встречи дают не шаг в развитии, а скорей всего прыжок.
То есть расписать пример использования утилиты = целая статья на Хабре?
Причем с ошибками, опечатками, и иногда не понятными комментариями.
Как будто иишке сказали: у меня есть инструмент, опиши чо как куда кого, и даже не читая выхлоп вставили сюда и добавили три скрина
Добрый день, вы правы - это только для десктопных версий.
Это ограничения самой утилиты обновления.
Оф.документация - 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
Супер! Спасибо что подробно и по теме.
Благодарю за информацию