Комментарии 3
Отличная статья. Удачи в будущих проектах!
Здарова, отец
Работаю во внутренней техподдержке и у наших пользователей зоопарк разных линуксов и windows. При обновление основного образа debian или внесении неких локальных изменений постоянно возникала проблема обновления уже имеющихся систем. До этого использовался ansible, но его проблема - если пк нет в сети, обновления не будет, а чем больше не полученных изменений - тем хуже и проще перезалить пк с нуля.
Задался вопросом централизации конфигурации - все настройки лежат на сервере, агент с пк должен подключаться к нему, выгружать и применять их. Были рассмотрены и опробованы:
ansible-pull - жирно по весу, отсутствие контроля за состоянием системы (никаких данных по умолчанию не присылает). Для пользовательского пк не подходит
Puppet - была установка сервера с foreman и агенты на пк. С первого взгляда устраивало всё, функционал работал, но возникли первые проблемы:
Puppet шифрует соединение выпуском ssl сертификатов в своём личном центре сертификации. Его же использует для web-интефейса, а следовательно подключение к web интерфейсу изначально недоверенное. Замена его на корпоративный wildcard сертификат, с последующим обновлением, оборачивается долгими развлечениями с тонкими настройками сервиса, который представляет из себя мутанта из apache и perl (? не помню точно), так, чтобы и web-интерфейс работал и агенты имели возможность подключения к сервису по старому серту. При обновлении сервиса все настройки конечно могут успешно отвалиться и начинать можно с нуля.
Всё тот же ЦС используется для выпуска ssl-сертификатов для агентов на пк. Но есть нюанс - у нас есть пк внутри сети с DNS-сервером и "удаленщики" подключающиеся по vpn без dns, только с DHCP. SSL-сертификаты на IP-адрес не выпускаются. Делать костыль - резервировать для сети vpn dns имена? Проблем станет еще больше - либо обновляй ключи при подключении клиента, либо регистрируй каждый MAC в белом списке. Опять таки проблема.
Pupper DSL - после yaml, jinja2 от ansible puppet dsl смотрится необычно и придется учить его с нуля. По сути не проблема, но компетенция других членов команды расти будет медленно (я же не для себя сервис поднимаю, его еще поддерживать потомкам)
Итог - Puppet конечно хорошо если используется внутри сети с DNS, нет проблем с подменой SSL-сертификата для web-панели или iptables ограничение доступа с определенных хостов, есть навыки работы с ruby. В плане работы отзыв оставить не могу, отказался от него еще на этапе настройки сервиса, по причинам выше.
Chef - не попробовал, но в обзорах он шел под руку с puppet. Причина - сначала деньги, потом - тапки.
SaltStack - начинаю строить систему сейчас на нём. Плюшки и нюансы которые уже удалось выявить:
В отличии от puppet, для безопасного подключения агент-сервер используется AES ключи. Нет страданиям с SSL для web и меж агентами на ПК. Успешная работа при наличии только ip-адреса и nat.
Структура sls-файлов в yaml-формате и адаптация после ansible проходит гораздо проще (в основной части)
Minion может работать без сервера, используя локальные файлы состояний. Пробую схему заливки пк через salt-minion, чтобы структура образа была одинакова и в момент установки и при использовании.
Для web-интерфейса использую https://github.com/erwindon/SaltGUI . Пока идет только подготовка системы про его функциональность ничего не скажу - можно подтвердить ключ агента, посмотреть состояние подключенных агентов и запустить обновление состояний. Вроде бы ОК.
Использование Foreman и Puppet в подходе IaC