Что здесь интересного?
Статья поможет разобраться с тем, как управлять произвольным количеством конфигурационных файлов некоего сервиса в SaltStack.
SaltStack (underfloor): что это и как с ним быть?
Многие уже имели опыт работы с сисSaltStack (uтемами автоматизированного управления конфигурациями, к которым относится Salt, и рассказывать подробно о том как его готовить и что он может я не стану, тут можно прочесть что это, а тут почитать как его быстро и легко приготовить.
SaltStack (lobby): типичное применение на простом примере
Итак, предположим, у Вас есть задача автоматизировать установку, внедрение конфигурационных файлов и мониторинг их изменений, перезагрузку в случае необходимости такого популярного сервиса как nginx. Для упрощения системы, сделаем предположение что обслуживаемые сервера построены на базе Debian Wheezy. (Для всех остальных, — читаем про grains систему, — она поможет определить на какой системе мы применяем стейт и соответствующим образом поменять его поведение).
Итак:
nginx-repo-key-install: cmd.run: - name: 'apt-key adv --keyserver keys.gnupg.net --recv-keys ABF5BD827BD9BF62' - unless: 'apt-key list | grep -q 7BD9BF62' nginx-repo: pkgrepo.managed: - humanname: nginx-repo - name: deb http://nginx.org/packages/mainline/debian/ wheezy nginx - require_in: - pkg: nginx-pkg - required: - cmd: nginx-repo-key-install nginx-pkg: pkg.installed: - name: nginx - refresh: True - require: - pkgrepo: nginx-repo nginx-service: service.running: - name: nginx - full_restart: True - require: - pkg: nginx-pkg - watch: - file: nginx-config-vhost nginx-config-vhost: file.managed: - name: /etc/nginx/conf.d/vhost.conf - source: salt://__CONFIGS/vhost.conf - user: root - group: root - mode: 644 Тут все, как «книжка пишет», но рассмотрим подробнее (очень важно как бэкграунд для последующих выкладок):
- nginx-repo-key-install: импортируем в систему ключ официального репозитория
- nginx-repo: вносим в apt официальный репозиторий
- nginx-pkg: ставим свеженький пакет
- nginx-service: берем под контроль сервис и заставляем следить за изменениями конфигурационного файла
- nginx-config-vhost: собственно — конфигурационный файл и место откуда его брать
Для пытливых умов, невооруженным взглядом, видны упущения (к примеру, — не описан контроль над nginx.conf) но все они сделаны для того, чтобы уменьшить не связанную с проблемной областью информационную нагрузку.
SaltStack (second floor): Много конфигурационных файлов
В первом примере был показан сервис в котором есть один файл где описан какой-то виртуальный сервер nginx. При его изменении на Salt мастере (salt://__CONFIGS/vhost.conf) и перезапуске стейта, файл будет обновлен на машине и сервис nginx будет перезапущен (full_restart: True) автоматически.
Зачастую виртуальных хостов на машине с nginx будет несколько. Рассмотрим как организовать управление ими.
Допустим, что есть файлы vhost{1,2,3,4,5}.conf. В таком случае нижняя часть стейта будет выглядеть так:
...... nginx-service: service.running: - name: nginx - full_restart: True - require: - pkg: nginx-pkg - watch: {% for cnf in ['vhost1.conf', 'vhost2.conf', 'vhost3.conf', 'vhost4.conf', 'vhost5.conf'] %} - file: nginx-config-{{ cnf }} {% endfor %} {% for cnf in ['vhost1.conf', 'vhost2.conf', 'vhost3.conf', 'vhost4.conf', 'vhost5.conf'] %} nginx-config-{{ cnf }}: file.managed: - name: /etc/nginx/conf.d/{{ cnf }} - source: salt://__CONFIGS/{{ cnf }} - user: root - group: root - mode: 644 {% endfor %} Тут начинается немного магии Salt, а именно: Jinja — шаблонизатор для Python (на котором и написан SaltStack). В стейте все очевидно, — делаем много объектов file с разными названиями и подвязываем все их к службе, чтобы при изменениях проводился её перезапуск. Для оптимизации можно использовать систему pillar-ов чтобы хранить имена файлов с конфигурациями. Но это — домашнее задание.
SaltStack (one floor upper): Много конфигурационных файлов — но сколько и каких — неизвестно.
Итак то, зачем и задумывалась эта статья, — ситуация достаточно обыденная для большинства рабочих систем с виртуальным хостингом: большое, заранее неизвестное и постоянно меняющееся количество конфигурационных файлов. Как же в таком случае поступить с разворачиванием инфраструктуры через Salt? Решение есть! К сожалению недостаточно очевидное (пришлось даже к разработчикам за разъяснениями обращаться), но работающее.
Итак:
...... nginx-service: service.running: - name: nginx - full_restart: True - require: - pkg: nginx-pkg - watch: {% for cnf in salt['cp.list_master'](prefix='__CONFIGS/') %} - file: nginx-config-{{ cnf }} {% endfor %} {% for cnf in salt['cp.list_master'](prefix='__CONFIGS/') %} {% set items = cnf.split('/') %} nginx-config-{{ cnf }}: file.managed: - name: /etc/nginx/conf.d/{{ items|last }} - source: salt://{{ cnf }} - user: root - group: root - mode: 644 {% endfor %} Собственно теперь о самых интересных местах:
{% for cnf in salt['cp.list_master'](prefix='__CONFIGS/') %} вызываем ф-цию list_master из модуля cp с префиксом ‘__CONFIGS/’ (имя папки на Salt мастере где лежат все конфигурационные файлы для этого сервиса) которая с выдает список файлов в этом каталоге и итерируем по списку циклом for.
{% set items = cnf.split('/') %} Проблема cp.list_master заключается в том, что она выдает полный путь к файлу (вместе с префиксом), а нам нужно лишь имя файла для того, чтобы указать его в директиве "- name:". В связи с этим мы сплиттим полный путь по слешам и используем только последний элемент списка — т.е. имя файла:
- name: /etc/nginx/conf.d/{{ items|last }} В итоге получаем пересмотренный каталог, включенные в оборот файлы конфигураций имеющиеся в этом каталоге и сразу же подвязываем к автоматическому перезапуску сервиса в случае правок в файлах.
Заключение
Очень кратенько, но надеюсь поможет тем читателям Хабра, которые только начинают внедрять SaltStack и хотят пойти немного дальше чем книжные примеры с простым менеджментом пакетов. Успехов!
ссылка на оригинал статьи http://habrahabr.ru/post/218231/
Добавить комментарий