Что здесь интересного?
Статья предназначена для тех кто использует или думает использовать SaltStack в качестве инструмента для управления конфигурациями. Постараюсь очень кратенько поделится опытом использования этой системы для гибкого управления конфигурациями сервисов на примере Tinyproxy.
Это вторая статься в серии о SaltStack, первую читайте здесь.
SaltStack: идеология построения конфигураций стейтов
Напомню, что в SaltStack для конфигураций управляемых машин введено понятие state (состояние), изменения в котором производятся на мастере, с последующим выполнением на всех подчиненных машинах. Модель очень похожа на тот же Puppet с его манифестами но в SaltStack есть одно, на мой взгляд, преимущество, — выполнение стейтов инициируется с мастера, а не самими клиентами как это реализовано в Puppet.
Но, ближе к делу. Поигравшись с салтом некоторое время, перепробовав различные способы организации данных стейта (sls файлы), я пришел к обобщенной модели подходящей для большинства обслуживаемых мною проектов. Суть модели — построенные на наследовании и переопределении отношения Сервис/Ресурс/Проект и их описания в терминах SaltStack. Об этом будет следующая статья. Сейчас я буду использовать методологию этой модели для описания управления сервисом TinyProxy не особо вдаваясь в подробности самой модели.
Первичное описание стейта
Итак, не буду детально говорить что такое TinyProxy и зачем он нужен (знающим и так понятно, пытливым — гугл в помощь), скажу лишь, что я использую его в одном из проектов для предоставления прокси сервиса своим клиентам. Схема: 20-30 серверов с TinyProxy разбросанных по всему миру. Установка и настройка крайне проста, потому упустим подробное описание, и остановимся лишь на том, что важно для выполнения задачи, а она в данном случае такова: ограничить доступ к прокси сервисам на основании IP адреса клиента. В терминах конфигурации TinyProxy это директива Allow.
Собственно стейт который создает Сервис (в терминах моей модели) TinyProxy:
tiniproxy.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*’.
ссылка на оригинал статьи http://habrahabr.ru/post/218249/
Добавить комментарий