Уважаемые коллеги, хочу представить вашему вниманию одну из систем управления конфигурациями, полностью написанную на 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 после того как сам все попробую.
Спасибо за внимание к материалу. Жду комментариев и замечаний.
Автор: stavinsky
