salt

Введение

Software Configuration Management — очень интересная и полезная тема, к которой должен придти каждый вменяемый системный администратор. ПО SCM позволяет получать одинаковый воспроизводимый результат на большим количестве машин с разным окружением за короткое время. Кроме того, использование SCM позволяет более четко понимать архитектуру разворачиваемой системы, а описание при помощи “рецептов” или “состояний” больше похоже на проектирование, нежели на настройку. Управлением конфигурациями пришло из производства, где конфиугурацией было сочетание состава деталей и их взаимного расположение.

Сегодня выбор ПО SCM довольно широкий, в статье же речь пойдет о такой обойденной вниманием харба новике, да и вообще малоизвестной в рунете системе как Salt.

Описание

Простота

Независимо от размера вашего проекта развернуть и настроить Salt просто — используется простая клиент-серверная модель топологии. Salt может быть установлен даже на RaspberryPi, а также в masterless standalone режиме.

Параллельное выполнение команд

Базовой фичей Salt является параллельное выполненение там, где только это возомжно.

Построен на провернных технологиях

Сетевой уровень в Salt построен на замечательной библиотеке ZeroMQ.
Для аутентификации используется клиентов на сервере использвуются публичные ключи, AES шифрование для защиты канала передачи данных.

Интерфейс python

Salt написан на Python и легко расширеяем модулями. Процедуры могут быть написаны как обычные модули Python. Salt может быть вызван с помощью простого Python API или из командной строки для выполнениия одноразовых комнад или использован как часть более крупного приложения.

Быстрота, Гибкость, Расширяемость

Salt может выполнять комманды применительно к группам различный размеров на огромной скорости. Система очень быстрая, легко настраивается и расширятся модулями и функциями.

Открытость

Salt распостраняется под лицензией Apache 2.0 и может быть использован как в составе открытых, так и проприетарных проектов.

Установка

Salt пока что не доступен в стандартных репозиториях популярных дистрибутивов.
В Centos необходимо включить epel
Устанавливаем:

yum install salt-master
yum install salt-minion

В Ubuntu подключаем ppa:saltstack/salt, выполняем:

apt-get install salt-master
apt-get install salt-minion

Начальная настройка

Мастер процесс(сервер) называется salt-master, клиенты — salt-minion.
После установки настройки как мастера и миньона лежат в /etc/salt/
Файл master должен распологаться на master сервере и хорошо документирован сам по себе, вот настройки которые стоит установить сразу же:

interface: 0.0.0.0 # мастер процесс принимает входящие подключения на этом ip
publish_port: 4505 #порт для входящих подключений
user: root #пользователь, от которого работает salt
worker_threads: 5 #количество потоков мастера
file_roots: #Описание папок файл сервера
  base:
    - /srv/salt

Файл minion распологается на миньонах(клиентах) и обязательно требует 2 параметра:

master: master.example.com #адрес master’а
id: minion.example.com

Директория /etc/salt/pki содержит ключи аутентификации.

Настроив мастера и миньона перезапускаем процессы:

root@master.example.com:/# /etc/init.d/salt-master restart
root@minion.example.com:/# /etc/init.d/salt-minion restart

Теперь необоходимо авторизовать minion на master’e. Делать это нужно от того пользователя, под которым выполняется salt-master.

Просмотриваем список всех ключей, про которые знает наш мастер:

root@master.example.com:/# salt-key -L
Unaccepted Keys:
minion.example.com
Accepted Keys:
Rejected:

Unaccepted Keys: — ключи с новых миньонов, еще не принятые.
Accepted Keys: — принятые, активные ключи.
Rejected: — непринятые ключи
Имя ключа совпадает с id миньона.
Удаленые ключи в списки не отображаются, потому что они удалены.

Принимаем ключ с вновь созданного миньона:

root@master.example.com:/# salt-key -a minion.example.com

Теперь снова просмотриваем список ключей:

root@master.example.com:/# salt-key -L
Unaccepted Keys:
Accepted Keys:
minion.example.com
Rejected:

Ключ нашего миньона отмечен как принятый.

Для переименования миньона процедуру необходимо повторить заново, сначала удалив старый ключ:

root@master.example.com:/# salt-key -d minion.example.com

Миньон активирован на мастере и может принимать от него команды:

root@master.example.com:/# salt ‘minion.example.com’ test.ping
minion.example.com: True

Здесь ‘minion.example.com’ — цель, на которой будет выполнена команда. Можно использовать регекспы, например `*web*example.com`, а также ключи Grains. test — один из модулей salt. ping — метод модуля test.

Просмотреть список всех встроенных модулей можно в документации или выполнив команду:

root@master.example.com:/# salt ‘*’ sys.doc | less

Модули можно легко дописывать и на лету подключать к salt.

В некоторых случаях может быть более удобным генерировать ключи на мастере и затем распостранять на миньонах.
Для amazon EC2 есть готовое решение Bootstrapping Salt on Linux EC2 with Cloud-Init

State

Прямое управление модулями salt не является основным use case! Главной и самой важной частью salt являются модуль State.
Это текстовое описание получаемой в результате системы. State могут быть написаны в yaml, json и python нотациях. Также могут быть использованы рецепты от других систем конфируационного менеждмента. По умолчанию используется yaml.
States должны распологаться в file_roots(/srv/salt/) master сервера.

Файл top .sls описывает какие states к каким миньоном должен применять master.

#/srv/salt/top.sls
base:
  ‘target’
   - app 

Файл app.sls описывает какое либо состояние, к которому миньон должен придти:

#/srv/salt/app.sls
app:
  pkg:
    - installed 
  service:
    - running
    - enabled: True   

Чтобы применить state на миньонах необходимо выполнить команду
root@master.example.com:/# salt ‘*’ state.highstate
Результатом будет состояние системы после применения описанных state. В случае неудачи текст будет красным, в случае успешного применения синим. Отображаются только изменения состояния.

Чтобы только протестировать, но не применять изменения, используется аргумент test

root@master.example.com:/# salt ‘*’ state.highstate test

app.sls также может быть папкой, тогда файл с состоянием будет называться init.sls — /srv/salt/app/init.sls

Один из вопросов, который возникает при использовании SCM — порядок испонения описанных состоянией. В salt по умолчанию все состояния равноценны и могут быть выполенены в произвольном порядке параллельно. Однако в большинсте случаев необходимо управлять процессом, заставляя те или иные действия выполнять в определенном порядке. Salt предлагает для это несколько инструментов.
Это require, watch, use и order.
State из предыдущего примера в реальном применении может принимать такой вид:

app:
  pkg:
    - installed 
    - require:
      - cmd.run: app-repo
  service:
    - running
    - enabled: True  
    - watch:
       - file.managed: /etc/app/app.conf

/etc/app/app.conf:
  file.managed:
    - source: salt://app/app.conf
    - require:
       - pkg: app

app-repo:
  cmd.run:
    - run
    - name: ‘echo |  apt-add-repository repo’
    - unless: ‘'apt-key list | grep 00000’

В этом примере порядок выполнения будет такой: app-repo — app.pkg — /etc/app/app.conf — app.service.
Разлчиие watch и require в том, что require всего лишь требует наличия, а watch требует точного соответствия отслеживаемого состояния на мастере и а миньоне. Поэтому повторное применение state после правки app.conf приведет к перезагрузке сервиса app, при этом app-repo и app.pkg не сработают.
У watch и require есть браться близнецы watch_in и require_in. Они позволяют указать, какие состояния зависят от состояния, в котором указан watch_in и require_in.

Иногда необходимо явно указать порядок выполнения, для этого нужен order:
В сложных рецептах с большим количеством состояний, которые зависят от одного состяния (установленный репозиторий например) и спользование order позволит избежать перечислений всех зависимых состяний.

К последовательности выполнения не относится, но часто используется вместе с order такая опция как failhard

Альтернативой States является модуль Pillar.

Grains

Эффективное управление конфигурациями невозможно без механизма получения и хранения информации о управляемых системах.
Grains представляет собой интерфейс для управления такой информацией.

Изначально grains cодержит такую информацию как id, os, arch, fqdn, kernel и другие 45 динамических параметров системы. Эти базовые параметры миньон собирает самостоятельно при старте и они могут быть расширены. Salt просто выполняет все публичные функции в директории file_roots (/srv/salt/_grains). Функция должна возвращать тип dict. Пример расширения grains можно увидеть здесь.

Есть возможность создать статические ключи и присвоить им значения непосредственно в конфигурационном файле миньона:

#/etc/salt/minon
grains:
  roles:
    - webserver
    - memcache
  deployment: datacenter4
  cabinet: 13
  cab_u: 14-15

Чтобы начать использовать grains выполним команду:

root@master.example.com:/# salt ‘*’ grains.items

Таким образом мы получим все данные со всех миньонов.
Как уже говорилось выше, grains можно использовать в salt target:

root@master.example.com:/# salt -G ‘os:Ubuntu’ grains.item osrelease

Результатом команды будет версия Убунты со всех миньонов.

Первый use-case grains — обеспечение воспроизводимости конфигурации в различном окружнии. Конечно некоторый уровень абстракции дают сами модули Salt, но не всегда.
Пример установки app в дистрибутив-незавимой версии может принять вид:

#/srv/salt/app/init.sls
app:
  pkg:
    - installed 
    - require:
      - cmd.run: app-repo
   {% if grains['os'] == 'RedHat' %}
   - name: package_name
   {% if grains['os'] == 'Ubuntu' %}
   - name: name_package
   {% endif %}
  service:
    - running
    - enabled: True  
    - watch:
       - file.managed: /etc/app/app.conf

/etc/app/app.conf:
  file.managed:
    - source: salt://app/app.conf
    - require:
       - pkg: app

app-repo:
  {% if grains['os'] == 'RedHat' %}
  cmd.run:
    - run
    - name ‘rpm -ivh repo_uri’
    - unless ‘yum repolist | grep repo’
    {% elif grains['os'] == 'Ubuntu' %}
   cmd.run:
    - run
    - name: ‘echo |  apt-add-repository repo’
    - unless: ‘'apt-key list | grep repo_key’
  {% endif %}

Применив этот state к своим миньонам под управлением Redhat и Ubuntu вы получите одинаковый результат.

Другим use-case grains является получение разного результата на разных системах. Например в конфигурации может быть указан fqdn системы:

...
/etc/app/app.conf
  file.managed:
    - source: salt://app/app.conf
    - template: jinja
    - require:
       - pkg: app
...

#/srv/salt/app/app.conf
...
Hostname={{ grains['fqdn'] }}
...

Ресурсы

Множество вопросов выходит за рамки этой статьи. Большинство информации по Salt можно найти на следующих ресурсах:
Официальный сайт saltstack.org

Документация salt.readthedocs.org/en/latest/index.html

Примеры рабочих files_root state:
github.com/blast-hardcheese/blast-salt-states
github.com/kevingranade/kevingranade-salt-state
github.com/uggedal/states
github.com/mattmcclean/salt-openstack/tree/master/salt

Окружение-песочница на Vagrant для тестирования модулей Salt:
github.com/elasticdog/salt-sandbox

Список рассылки:
groups.google.com/forum/?fromgroups#!forum/salt-users

Презентация Mike Chesnaut на LSPE
www.slideshare.net/mchesnut/sweetening-systems-management-with-salt

Резюме:

Salt — очень молодая, перспективная система управления конфиграциями. В настоящий момент поддерживаются в первую очередь Linux системы, но также уже есть частичная поддержка Windows. Не так давно добавлена поддержка FreeBSD. Salt уже успела обрасти сторонними модулями и проектами, сильным community и вполне может быть применена в проектах с большой и динамичной инфраструктурой.