SALT – ПО для управления конфигурациями на Python
Уважаемые коллеги, хочу представить вашему вниманию одну из систем управления конфигурациями, полностью написанную на Python. Она достаточно новая, но уже заслуживает внимания. Если вам интересно как можно управлять парком серверов и рабочих станций как единой системой с помощью этого приложения – прошу под кат.
Почему Salt?
Некоторое время назад задумался над тем, что количество управляемых мной серверов увеличилось с нескольких до более чем 20 и продолжает расти. Возникли вопросы централизованного обновления ПО, смены паролей, быстрого поднятия новых виртуальных машин и тому подобные рутинные задачи любого ИТ-специалиста.
Естественно я начал изучать особенности рынка. Вот, например, список бесплатных систем управления на wikipedia: Comparison_of_open_source_configuration_management_software, на который я собственно и ориентировался при выборе системы для изучения. При выборе я пользовался следующими критериями:
- хоть слабая, но поддержка Windows
- хорошая поддержка Linux
- Открытый код
- Не Ruby(знаю, это мое упущение, но не сложились у меня с ним отношения)
Как вы поняли, выбор пал на Salt.
Концепция и базовые понятия
Насколько я понял, Salt позволяет решать 2 задачи:
- Централизованный запуск команд на группах компьютеров
- Поддержка систем в заранее описанных состояниях
Система состоит из клиентов – minion, и серверов – master. Подключение является исходящим по отношению к миньону, следовательно NAT и прочее нам не очень страшно.
Grains
Группы компьютеров формируются на основе так называемых «зерен»(Grains): параметров системы, собираемых сервисом миньона в момент старта.
Например если мы хотим проверить доступность всех узлов, на которых установлена ОС CentOS, нам достаточно написать:
salt -G 'os:CentOS' test.ping
или хотим узнать количество ядер во всех наших 64х битных системах:
salt -G 'cpuarch:x86_64' grains.item num_cpus
Так же наравне со стандартными зернами мы можем добавлять свои:
grains:
roles:
- webserver
- memcache
deployment: datacenter4
cabinet: 13
cab_u: 14-15
States
Вторая составляющая – это файлы состояний, которые позволяют описать требования к состоянию системы и позже на основе этих файлов миньон может привести необходимые параметры клиентской системы в нужное нам состояние.
Но это как-то сложно написано, предлагаю пример:
Для начала проверим в конфигурационном файле мастера, где должны храниться SLS файлы
vim /etc/salt/master
ищем что-то похожее на:
file_roots:
base:
- /srv/salt
Следовательно в этой папке (/srv/salt/ ) и будут лежать наши файлы наши SLS файлы.
Обязательным является файл top.sls находящийся в этой папке.
Вот пример содержания этого файла у меня на тестовой машине:
base:
'web2':
- fail2ban
fail2ban(Третья строка) может быть: или файлом sls или папкой в которой бы лежал файл init.sls. Второй вариант мне кажется более удобным, по этому я так и сделал:
Содержанием файла fail2ban у меня является:
cat fail2ban/init.sls
- fail2ban.conf:
- file.managed:
- - name: /etc/fail2ban/fail2ban.conf
- - source: salt://fail2ban/fail2ban.conf
- jail.conf:
- file.managed:
- - name: /etc/fail2ban/jail.conf
- - source: salt://fail2ban/jail.conf
- fail2ban:
- pkg:
- - installed
- service.running:
- - enable: True
- - watch:
- - file: fail2ban.conf
- - file: jail.conf
В этом SLS файле есть 3 сущности:
- Файл fail2ban.conf (строка 1)
- Файл jail.conf (срока 6)
- Сам пакет fail2ban (строка 11)
В соответствии с описанным нами sls файле Salt сделает следующие действия:
- Сравнит файлы на клиенте с тем что у него и при наличии изменений обновит клиента (строки 2 и 7)
- Проверит наличие установленного пакета fail2ban(12- 13)
- Проверит включенность службы(15)
- Проверит автозапуск службы(16)
- В случае если один из файлов изменился – перезагрузит службу(17)
Установка
Во-первых, очень настоятельно не рекомендую пользоваться предложенным авторами проекта bootstrap файлом. Так как он делает очень много, на мой взгляд, странных действий. (например yum –y update и использованием тестового репозитория epel)
На самом деле, по крайней мере, с centos, делать ничего сложного не придется.
Пакеты salt-master и salt-minion есть в epel.
Имена сервисов в CentOS такие же.
Файлы конфигурации служб находятся в /etc/salt/
Master
По умолчанию master открывает 2 порта, которые следует разрешить в iptables:
iptables -I INPUT -j ACCEPT -p tcp --dport 4505:4506
4505 – для общения миньонов с сервером
4506 – для передачи файлов
Minion
Базовая настройка файла миньона заключается в указании адреса мастера и, я лично еще добавляю другой ID. Если этого не сделать – будет использовано FQDN.
Запускаясь, миньон подключается к мастеру и передает ему свой публичный ключ.
Далее на мастере при запуске утилиты salt-key:
[root@test salt]# salt-key
Accepted Keys:
Unaccepted Keys:
web2
Rejected Keys:
Нужный нам ключ появляется в списке Unaccepted Keys, что бы добавить его в разрешенные:
[root@test salt]# salt-key -a web2
Key for minion web2 accepted.
На этом подключение первого миньона закончено. И можно проверить его доступность
[root@test salt]# salt 'web2' test.ping
web2: True
ну и если мы захотим проверить как настроен наш fail2ban:
[root@test salt]# salt 'web2' state.highstate
Что можно делать с миньонами?
Список модулей для удаленного управления: salt.readthedocs.org/en/latest/ref/states/all/salt.states.pkg.html#module-salt.states.pkg
Список модулей для управления и контроля состояний: salt.readthedocs.org/en/latest/ref/states/all/salt.states.file.html#module-salt.states.file
Вопросы
Я пока не разобрался в 2 моментах:
- Как можно автоматизировать прописывание на сервере ключей, для полной автоматизации? (скорее всего напишу свой модуль, с http запросами)
- Что будет с миньоном если ему подменить сервер. Будет ли он слушаться этого нового сервера? За вопрос спасибо моему коллеге и хорошему другу, Яну.
На эти вопросы я постараюсь ответить в следующих статьях о salt после того как сам все попробую.
Спасибо за внимание к материалу. Жду комментариев и замечаний.