http://habrahabr.ru/post/218249/

Что здесь интересного?

Статья предназначена для тех кто использует или думает использовать SaltStack в качестве инструмента для управления конфигурациями. Постараюсь очень кратенько поделится опытом использования этой системы для гибкого управления конфигурациями сервисов на примере Tinyproxy.
Это вторая статься в серии о SaltStack, первую читайте здесь.

SaltStack: идеология построения конфигураций стейтов

Напомню, что в SaltStack для конфигураций управляемых машин введено понятие state (состояние), изменения в котором производятся на мастере, с последующим выполнением на всех подчиненных машинах. Модель очень похожа на тот же Puppet с его манифестами но в SaltStack есть одно, на мой взгляд, преимущество, — выполнение стейтов инициируется с мастера, а не самими клиентами как это реализовано в Puppet.

Но, ближе к делу. Поигравшись с салтом некоторое время, перепробовав различные способы организации данных стейта (sls файлы), я пришел к обобщенной модели подходящей для большинства обслуживаемых мною проектов. Суть модели — построенные на наследовании и переопределении отношения Сервис/Ресурс/Проект и их описания в терминах SaltStack. Об этом будет следующая статья. Сейчас я буду использовать методологию этой модели для описания управления сервисом TinyProxy не особо вдаваясь в подробности самой модели.

Первичное описание стейта

Итак, не буду детально говорить что такое TinyProxy и зачем он нужен (знающим и так понятно, пытливым — гугл в помощь), скажу лишь, что я использую его в одном из проектов для предоставления прокси сервиса своим клиентам. Схема: 20-30 серверов с TinyProxy разбросанных по всему миру. Установка и настройка крайне проста, потому упустим подробное описание, и остановимся лишь на том, что важно для выполнения задачи, а она в данном случае такова: ограничить доступ к прокси сервисам на основании IP адреса клиента. В терминах конфигурации TinyProxy это директива Allow.

Собственно стейт который создает Сервис (в терминах моей модели) TinyProxy:
tinyproxy.sls

tinyproxy-config:
  file.managed:
    - name: /etc/tinyproxy.conf
    - source: salt://__DEFAULT-CONFIGS/tinyproxy.conf
    - template: jinja
    - require:
      - pkg: tinyproxy-pkg

tinyproxy-pkg:
  pkg.installed:
    - name: tinyproxy

tinyproxy-service:
  service.running:
    - name: tinyproxy
    - full_restart: True
    - require:
      - pkg: tinyproxy-pkg
    - watch:
      - file: tinyproxy-config

Важные моменты:

• Мы берем файл /etc/tinyproxy.conf под управление
• Его прототип (шаблон) находится на мастере salt://__DEFAULT-CONFIGS/tinyproxy.conf
• Мы сообщаем стейту о том, что данный файл нужно обработать с помощью Jinja ( — template: jinja) и в нем есть команды шаблонизации (будут описаны ниже)

Все остальное в стейте достаточно стандартно: установка пакета (благо в большинстве Linux систем TinyProxy доступен из коробки), взятие под контроль системной службы и привязка её перезапуска к изменениям к конфигурационном файле. Абстрагируемся от того, что в разных системах файл может находится в разных каталогах относительно /etc.

часть tinyproxy.conf с шаблоном Jinja

. . .
#
# Allow: Customization of authorization controls. If there are any
# access control keywords then the default action is to DENY. Otherwise,
# the default action is ALLOW.
#
# The order of the controls are important. All incoming connections are
# tested against the controls based on order.
#

{% for allowed_ip in pillar['tinyproxy']['allowed_ips'] -%}
Allow {{ allowed_ip }}
{% endfor %}
. . . 

Важный момент: про то как правильно создавать шаблоны и зачем там тире возле % можно почитать тут; данные для шаблона берутся из системы Pillar-ов.

Сам Pillar (в терминах моей модели — Ресурс) для этих случаев выглядит так:
tinyproxy-pillar.sls

tinyproxy:
  allowed_ips:
    - 1.2.3.4
    - 2.3.4.5
    - 3.4.5.6

То есть вся последовательность выглядит так: При каждом запуске стейта на подчиненных машинах, файл tinyproxy.conf прогоняется через шаблонизатор Jinja, который вживляет в него необходимые данные взятые из pillar и отправляется на клиента с последующим перезапуском сервиса.
итоговый tinyproxy.conf:

. . .
#
# Allow: Customization of authorization controls. If there are any
# access control keywords then the default action is to DENY. Otherwise,
# the default action is ALLOW.
#
# The order of the controls are important. All incoming connections are
# tested against the controls based on order.
#

Allow 1.2.3.4
Allow 2.3.4.5
Allow 3.4.5.6
. . . 

Что в итоге?

Все эти манипуляции были призваны к тому, чтобы в случае если Вам прийдётся добавить или удалить IP адрес какого-либо клиента (в соответствии с политикой доступов) достаточно подправить данные в pillar файле (добавить или удалить строку) и запустить state.highstate для всех проксей '*proxy*'.