В первую очередь, при внедрении новой архитектуры Salt-standalone вендор оптимизировал нагрузку на КД, так как клиент инициирует подключение, получает только параметры ГП и применяет их локально. Также решена проблема поддержания единообразия настроек при геораспределенности (все параметры хранятся и реплицируются посредством LDAP) и уход от распределенной файловой системы GlusterFS. Более подробное описание архитектуры в статье вендора: https://habr.com/ru/companies/astralinux/articles/886300/ Однако в ней есть и минусы: отсутствие PUSH сценариев, которые инициализировались со стороны Salt-master. Теперь даже если вам необходим разовый запуск сценария на клиенте, он будет работать в режиме PULL (но единоразово).
Спасибо за Ваш комментарий, абсолютно с вами согласен, как показывает опыт - если вам не требуется поддержка и у вас небольшая инфраструктура достаточно будет opensource решений для администрирования небольшого парка АРМ.
Добрый день! Спасибо за Ваш комментарий. Согласен с вами скрипты пишутся для разных целей в ИТ-инфраструктуре, есть несрочные, но также бывают срочные (одноразовые) - например получение конкретной информации. При наличии правильного инструмента необходимую информацию можно получить и без скриптов. Ценность продукта зависит от инфраструктуры организации, для небольшого кол-ва пользователей действительно можно осуществлять управление с помощью открытых инструментов, в большинстве случаев без ACM не обойтись.
У каждой инфраструктуры организации свои потребности, для маленькой организации ACM может быть избыточен, а в каких-то без ACM не обойтись.
Большое спасибо за ваш комментарий! 1) Исправил - согласен с вами! 2) Исправил - согласен с вами! 3) Эта конструкция возможно будет удобнее, протестирую. 4) Эта конструкция возможно будет удобнее, протестирую. 5) Не согласен - по требованиям вендора необходимо использовать последовательность и конфигурационные файлы согласно скриптам.
В первую очередь, при внедрении новой архитектуры Salt-standalone вендор оптимизировал нагрузку на КД, так как клиент инициирует подключение, получает только параметры ГП и применяет их локально. Также решена проблема поддержания единообразия настроек при геораспределенности (все параметры хранятся и реплицируются посредством LDAP) и уход от распределенной файловой системы GlusterFS. Более подробное описание архитектуры в статье вендора: https://habr.com/ru/companies/astralinux/articles/886300/ Однако в ней есть и минусы: отсутствие PUSH сценариев, которые инициализировались со стороны Salt-master. Теперь даже если вам необходим разовый запуск сценария на клиенте, он будет работать в режиме PULL (но единоразово).
Спасибо за Ваш комментарий, абсолютно с вами согласен, как показывает опыт - если вам не требуется поддержка и у вас небольшая инфраструктура достаточно будет opensource решений для администрирования небольшого парка АРМ.
Добрый день! Спасибо за Ваш комментарий.
Согласен с вами скрипты пишутся для разных целей в ИТ-инфраструктуре, есть несрочные, но также бывают срочные (одноразовые) - например получение конкретной информации. При наличии правильного инструмента необходимую информацию можно получить и без скриптов.
Ценность продукта зависит от инфраструктуры организации, для небольшого кол-ва пользователей действительно можно осуществлять управление с помощью открытых инструментов, в большинстве случаев без ACM не обойтись.
У каждой инфраструктуры организации свои потребности, для маленькой организации ACM может быть избыточен, а в каких-то без ACM не обойтись.
Большое спасибо за ваш комментарий!
1) Исправил - согласен с вами!
2) Исправил - согласен с вами!
3) Эта конструкция возможно будет удобнее, протестирую.
4) Эта конструкция возможно будет удобнее, протестирую.
5) Не согласен - по требованиям вендора необходимо использовать последовательность и конфигурационные файлы согласно скриптам.