0,1
рейтинг
3 февраля 2013 в 19:54

Разработка → SALT – ПО для управления конфигурациями на Python

Уважаемые коллеги, хочу представить вашему вниманию одну из систем управления конфигурациями, полностью написанную на Python. Она достаточно новая, но уже заслуживает внимания. Если вам интересно как можно управлять парком серверов и рабочих станций как единой системой с помощью этого приложения – прошу под кат.



Почему Salt?

Некоторое время назад задумался над тем, что количество управляемых мной серверов увеличилось с нескольких до более чем 20 и продолжает расти. Возникли вопросы централизованного обновления ПО, смены паролей, быстрого поднятия новых виртуальных машин и тому подобные рутинные задачи любого ИТ-специалиста.

Естественно я начал изучать особенности рынка. Вот, например, список бесплатных систем управления на wikipedia: Comparison_of_open_source_configuration_management_software, на который я собственно и ориентировался при выборе системы для изучения. При выборе я пользовался следующими критериями:

  • хоть слабая, но поддержка Windows
  • хорошая поддержка Linux
  • Открытый код
  • Не Ruby(знаю, это мое упущение, но не сложились у меня с ним отношения)

Как вы поняли, выбор пал на Salt.

Концепция и базовые понятия

Насколько я понял, Salt позволяет решать 2 задачи:
  1. Централизованный запуск команд на группах компьютеров
  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

  1. fail2ban.conf:
  2.    file.managed:
  3.     - name: /etc/fail2ban/fail2ban.conf
  4.     - source: salt://fail2ban/fail2ban.conf 
  5.  
  6. jail.conf:
  7.    file.managed:
  8.     - name: /etc/fail2ban/jail.conf
  9.     - source: salt://fail2ban/jail.conf 
  10.  
  11. fail2ban:
  12.    pkg:
  13.     - installed
  14.  
  15.    service.running:
  16.     - enable: True
  17.     - watch:
  18.       - file: fail2ban.conf
  19.       - file: jail.conf

В этом SLS файле есть 3 сущности:
  • Файл fail2ban.conf (строка 1)
  • Файл jail.conf (срока 6)
  • Сам пакет fail2ban (строка 11)


В соответствии с описанным нами sls файле Salt сделает следующие действия:
  1. Сравнит файлы на клиенте с тем что у него и при наличии изменений обновит клиента (строки 2 и 7)
  2. Проверит наличие установленного пакета fail2ban(12- 13)
  3. Проверит включенность службы(15)
  4. Проверит автозапуск службы(16)
  5. В случае если один из файлов изменился – перезагрузит службу(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
карма
24,0
рейтинг 0,1
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (20)

  • –4
    Сейчас сам активно разбираюсь с Puppet. После ознакомления с описанием Salt из этой статьи, заметил что авторы ПО прям категорически не хотели применять устоявшиеся термины/понятия из систем на Ruby. Master, noda, fact что может быть логичней, ИМХО.
    Синтаксис описания состояний сравнивать тяжело, чувствуется влияние Python. Но если предположить что данные файлы могут состовлять администраторы не знакомые с ним, то синтаксис того же Puppet более привычней. Но это все субъективно.

    При беглом осмотре сайта не обнаружил какой либо веб-морды ко всему этому. Не остро необходимая, но при наличии приятное дополнение.
    Как выполняется кофигурирование какой конфиг на какую машину разливать? Есть ли механизм авторизации узлом на мастере?
    • 0
      Про авторизацию вопрос снимается, не заметил сначала.
  • +1
    по поводу веб морды набрел на salt-ui, в зачатке, но мне пока и не нужен был.
    по поводу языка описания — это yaml, думаю его желательно знать любому сисадмину
    по поводу терминов — тут сказывается то что автор судя по всему писал это на коленке. Самому понравилось «minion», сразу rpg вспоминаются, где же Raid Boss???))
    по поводу авторизации — если вы имеете в виду как узел авторизуется на мастере — то это описано в статье, больше интересует вопрос привязки ноды к серверу, что бы не было подмены сервера.
    по поводу конфига тоже. система grains.

    сравнивать проекты пока бессмысленно, так как salt очень молод.
  • 0
    А документация по написанию кастом-модулей, плагинов и фактов (пользуясь терминологией паппита) имеется?
  • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      Для меня такой фичей был питон и простота развертывания. Работает реально из коробки. (этап скрещивания миньона с мастером)
      Быстро понимаешь что и как делать. У меня на понимание работы ушло часа полтора.
      Думаю что паппет в разы функциональнее, но и боюсь сложнее.
  • +1
    Сильно напомнило ansible: ansible.cc/
    • 0
      Спасибо, читаю! Впечатлен!
  • 0
    Почему-то никто не вспоминает про CFEngine в таких тредах. А ведь у него есть преимущества хотя-бы в скорости работы, т.к. и сервер и агент написаны на си. Да и теория обещаний за ним стоит.

    Хотя бы почитайте про него, интересная штука, да и удобная тоже.
    • 0
      я честно говоря так и не понял держит ли он windows
      а так — согласен было бы интересно
    • –1
      Уже не в первый раз плюсом CFEngine называется то, что он на С. Это не плюс, просто так исторически сложилось. Нет, конечно скорость работы — конечно плюс, но оно никому не надо. Большая тройка(папит, чиф и энджин) работает достаточно быстро.
      • –1
        Есть еще одно преимущество, которое для меня явилось решающим. Ну вот не люблю я на сервера ставить пакеты, которые там не нужны по прямому назначению. Например, руби.
        • 0
          Мое знакомство с руби началось при установке ред майна. Больше я пока с ним знакомиться не хочу. (надо поставить именно такую версию такого-то пакета, потом что-то запустить, потом еще, потом все не заработает, потом что-то обновить, потом что-то поставить по зависимостям потом опять что-то запустить и может быть заведется. Больше не хочу!!! Если стану писать на руби и буду понимать что за пакеты и библиотеки я ставлю — будет легче)
          • +1
            Да против самого руби я ничего не имею. Я против ситуации, когда он нужен на сервере только для того, чтобы работал какой-нибудь шеф.

            А с рейдмайном да, первый раз много времени угробил. Потом оказалось, что все довольно просто — ставишь руби, бундлер, и гемы нужные для редмайна подтягиваются этим бундлером по большей части автоматом.
  • 0
    en.wikipedia.org/wiki/Comparison_of_open_source_configuration_management_software — Неверная информация о Chef. Поддержка Windows в нём есть.

    Не Ruby
    wiki.opscode.com/display/chef/Just+Enough+Ruby+for+Chef.
  • 0
    Как можно автоматизировать прописывание на сервере ключей, для полной автоматизации? (скорее всего напишу свой модуль, с http запросами)

    Если у вас сеть закрытая от внешнего мира, то на мастере можно включить опцию «принимать все ключи автоматически».

    Что будет с миньоном если ему подменить сервер. Будет ли он слушаться этого нового сервера?

    После принятия ключа на новом мастере будет слушаться, как миленький.
    • 0
      да выяснил уже и тот и тот момент.
      По первому вопросу даже туториал есть как автоматизировать процесс для EC вроде
      Вот вторая часть меня расстраивает. Не знаете как бороться? А то реально кто-то захватывает днску и кирдык всему
      • 0
        А то реально кто-то захватывает днску и кирдык всему


        Еще не думал над этим. Первое, что приходит на ум — указывать ip-адрес сервера, вместо его доменного имени.
        • 0
          IP адрес конечно получить сложнее, но тоже возможно! Например купить сервер у того же хостера на том же коммутаторе. Мало вероятно но все же. В общем ключи надо как-то двусторонними что ли делать
          • 0
            Диалог с #Salt канала IRC
            (11:37:18 AM) s1acky: I have a stupid question. What if someone will hack my DNS server or find other way to replace my master server. Will minions listen to new server?
            (11:41:48 AM) EugeneKay: No.
            (11:42:12 AM) EugeneKay: The masters and minions both have keys to identify themselves to the other side
            (11:42:16 AM) jcristau: they cache the server's key

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.