Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

SaltStack: применение образцов jinja и хранилища pillar для эластичной настройки конфигураций

Anna | 15.06.2014 | нет комментариев

Что тут увлекательного?

Статья предуготовлена для тех кто использует либо думает применять 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*’.

Источник: programmingmaster.ru

Оставить комментарий
БАЗА ЗНАНИЙ
СЛУЧАЙНАЯ СТАТЬЯ
СЛУЧАЙНЫЙ БЛОГ
СЛУЧАЙНЫЙ МОД
СЛУЧАЙНЫЙ СКИН
НОВЫЕ МОДЫ
НОВЫЕ СКИНЫ
НАКОПЛЕННЫЙ ОПЫТ
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB