- PVSM.RU - https://www.pvsm.ru -
Статья предназначена для тех кто использует или думает использовать SaltStack в качестве инструмента для управления конфигурациями. Постараюсь очень кратенько поделится опытом использования этой системы для гибкого управления конфигурациями сервисов на примере Tinyproxy [1].
Это вторая статься в серии о SaltStack, первую читайте здесь [2].
Напомню, что в SaltStack для конфигураций управляемых машин введено понятие state [3] (состояние), изменения в котором производятся на мастере, с последующим выполнением на всех подчиненных машинах. Модель очень похожа на тот же Puppet [4] с его манифестами но в 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
Важные моменты:
Все остальное в стейте достаточно стандартно: установка пакета (благо в большинстве 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 %}
. . .
Важный момент: про то как правильно создавать шаблоны и зачем там тире возле % можно почитать тут [5]; данные для шаблона берутся из системы Pillar [6]-ов.
Сам 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*'.
Автор: eugenechepurniy
Источник [7]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/python/58427
Ссылки в тексте:
[1] Tinyproxy: https://banu.com/tinyproxy/
[2] здесь: http://habrahabr.ru/post/218231/
[3] state: http://docs.saltstack.com/en/latest/topics/tutorials/starting_states.html
[4] Puppet: http://puppetlabs.com/puppet/what-is-puppet
[5] тут: http://jinja.pocoo.org/docs/templates/
[6] Pillar: http://docs.saltstack.com/en/latest/topics/pillar/
[7] Источник: http://habrahabr.ru/post/218249/
Нажмите здесь для печати.