Централизованное управление конфигурациями linux

Централизованное управление конфигурациями: Puppet + Foreman. Часть ІI

Это вторая часть из серии статей о связке Puppet + Foreman, в ней будет рассмотрено следующее:

* Создание групп хостов
* Добавление хоста в группу
* Применение манифестов на группу хостов
* Автоподпись сертификатов
* Автоматическое распределение хостов по группам

Для создания группы хостов заходим в Foreman и выбираем в меню «Настройка» — «Группы узлов» — «Новая группа узлов», у нас открывается страница с настройками новой группы. Здесь можно выбрать родителя группы(то есть получается можно делать вложения групп), имя(в нашем случае Bobrovka), окружение, центр сертификации и мастер-сервер выбираем наш Puppet сервер.

Если хотим сразу добавить манифесты которые будут применяться на группу — переходим во вкладку «Классы Puppet» — здесь все аналогично с применением манифеста к одиночному клиенту, только манифест будет применен на все хосты входящие в группу. Подтверждаем изменения.

Теперь если мы перейдем в «Настройка» — Группы узлов» — мы увидим список наших групп.

Для того чтобы добавить существующий хост в определенную группу — переходим в «Узлы» — «Все узлы», нажимаем на имени нужного нам узла(открывается детальная информация об узле) и жмем кнопку «Изменить» и в поле «Группа» выбираем нужную нам группу. Подтверждаем изменения.

После того как мы добавили нужные нам хосты в группу мы можем добавить манифесты для них(если Вы не сделали это при создании группы). Для добавления манифеста в существующую группу переходим в «Настройки» — «Группы узлов» — нажимаем на имя нужной нам группы и повторяем процедуру описанную 3 абзаца назад.

Итак — у нас есть работающий сервер со связкой Puppet + Foreman, но если мы хотим добавить новый хост в Puppet нам каждый раз приходится подписывать сертификаты(меня это напрягает) в веб-интерфейсе либо же в консоли. Для того чтобы сертификаты подписывались автоматически можно использовать возможность автоматической подписи сертификатов на основе имени клиента. Для этого переходим в меню «Инфраструктура» — «Smart Proxies» жмем на «Сертификаты» и в правой верхней части нажимаем «Записи autosign» — создаем новую запись. В поле где пишется имя — пишем * и сохраняем.

В результате у нас будут подписываться все клиентские сертификаты без исключений, что есть не очень хорошо(но для начала подойдет). Чтобы подписывать не все сертификаты, а например только сертификаты от веб серверов нужно изменить запись на web-*(это сработает если у Вас все веб сервера именуются так: www-1.domain.name, www-n.domain.name).

Для автоматического распределения новосозданных хостов по группам можно использовать плагин foreman_default_hostgroup. Этот плагин позволяет распределять хосты по группам на основе фактов.
Для установки плагина нужно выполнить комманду apt-get install ruby-foreman-default-hostgroup
Если плагин устновился — он будет отображаться в меню «Администратор» — «О программе» во вкладке «Модули»(возможно потребуется перезапуск Foreman)

После установки нужно отредактировать файл в каталоге /usr/share/foreman/config/settings.plugins.d/default_hostgroup.yaml

Если Вы используете мой конфиг от плагина, тогда у Вас будет производиться сортировка по группам на основе IP адреса клиента. В данном примере — если клиент имеет IP 10.10.55.12 — он попадет в группу «Bobrovka», если же у него адрес 10.210.138.7 — он попадет в группу «Medvedka», если IP адрес клиента не попадает ни под одно из условий — он попадает в группу «Default». Плагин считывает конфиг с верху в низ, поэтому группа «Default» находится в самом низу, так как под ее критерии подпадают абсолютно все IP адреса.

На этом вторая часть моей публикации завершается.
Результат нашей работы — работающий Puppet + Foreman с возможностью автоматической подписи сертификатов и распределения хостов по группам на основе фактов.

Источник

Выбор системы управления конфигурациями

Опрос или не подтвердят, или подтвердят через очень много времени. Сделаю тему здесь

Выбираю систему управления конфигурациями для разворачивания у нас (если ещё удастся пробить её использование). Кроме определённых фич, хотелось бы получить знания/опыт работы с более популярным софтом, чтобы пригодилось в дальнейшем. Что стоить осваивать?

Выбираю между cfengine, puppet, chef. Про первый ругаются, что сложный и плохо документированный. Вторые оба тяжёлые, и требуют учить руби, а мну лениво, си с питоном немного знаю и пока большего не требуется.

У пуппета комьюнити овер9000, ruby почти не нужен — все уже придумано до нас.

Я предпочитаю хорошо разбираться в системе, которую использую.

saltstack, писан на питоне, для простых задач самое то.

Сотня с лишним серверов по стране, и штук десять в головном офисе. Разные версии убунты, в паре случаев центось. Однотипных много, но с исторически накопившемися мелкими различиями.

Требования: централизованное хранение конфигурации в удобочитаемом виде, одновременные изменения конфигурации на куче серверов(типа «вчера у нас был вот такой ipsec — а завтра будет уже сильно другой»). Если можно — python

У пуппета комьюнити овер9000, ruby почти не нужен — все уже придумано до нас.

А вот и нет. Годных модулей на forge.puppetlabs.com чуть больше чем 0 штук. Почти все приходится делать самому.

я придумал решение с конфигурацией ipsec — выкинуть его нахер, заменив openvpn, всё равно вы все по какой-то причине делаете в нём PSK и айпишники

Вторые оба тяжёлые, и требуют учить руби, а мну лениво, си с питоном немного знаю и пока большего не требуется.

Я тоже по началу много матерился, но по факту ruby оказался куда приятнее пистона.

Это абстрактный пример, не обязательно про ipsec. Ну и кстати: openvpn через TCP работает медленно, IP-телефония хреново ходит. А через UDP работает как повезёт — иногда просто летает, а иногда, если у провайдера криво настроенный шейпер, который сильно переупорядочивает длинные последовательности UDP-пакетов — просто пиздец. В логах сплошные replay window attack, включишь noreply — всё равно получается страшный джиттер.

Шеф. Осилишь за неделю.

Шеф, да, пупетчики дико радуются шефу.

Я использую dsh и простые скрипты. У меня мало одинаковых, среди сотни, серверов.

cfengine — не плохо документированный, у него вся документация на сайте производителя и очень не много сторонних текстов а-ля how-to для начинающих, обсуждений на форумах и проч. Мне пока удается найти в ней ответы на все возникающие вопросы.
Сложность — ну да, первые шаги мне довольно трудно дались, но по мере изучения мне эта система нравится все больше и больше.
Прочие здесь упомянутые (chef, puppet) практически не пробовал. Причина проста — у меня известный «зоопарк», и не везде их можно собрать. Cfengine написан на С и собирается практически везде

у меня в зоопарке винды живут, и я тоже смотрю в сторону cfengine именно поэтому

Юзал puppet на конторе с

150 однотипный юзерских PC под Debian Весьма экономит время

использовал puppet и выбросил, достало везде ruby собирать..

cfengine рулит, если разобраться..

Если разобраться, рулить может что угодно.

Chef вполне себе поддерживается и на платформе windows. Puppet вроде бы тоже. По крайней мере его Enterprise версия точно.

puppet в google используют

Chef вполне себе поддерживается и на платформе windows.

там же вроде была какая то минималистичная имплементация, которая почти ни на что не была способна. То же самое касается и puppet. enterprise на данный момент мне не интересен

Можно, только нафига выбирать из того, где питона нет совсем?

Источник

Система управления конфигурациями Linux Ansible

Представьте себе, что вам нужно управлять парком серверов, расположенных к тому же в разных географических точках. Каждый из этих серверов требует настройки, регулярного обновления и мониторинга. Конечно, для решения этих задач можно воспользоваться самым простым способом: подключиться к каждому серверу по ssh и внести необходимые изменения. При всей своей простоте этот способ сопряжен с некоторыми трудностями: он чрезвычайно трудоемок, а на выполнение однообразных операций уходит очень много времени.

Чтобы упростить процессы настройки и конфигурирования серверов, можно также писать shell-скрипты. Но и этот способ вряд ли можно назвать совершенным. Скрипты нужно постоянно изменять, подстраивая их под каждую новую задачу. При их написании необходимо учитывать различие операционных систем и версий. Не будем забывать и о том, что отладка скриптов отнимает много усилий и забирает немало времени.

Оптимальным вариантом решения описанных проблем является внедрение системы удаленного управления конфигурацией. В таких системах достаточно лишь описать нужное состояние управляемого узла. Система должна сама определить, что нужно сделать для достижения этого состояния, и осуществит все необходимые действия.

Со всеми сложностями, о которых идет речь выше, мы хорошо знакомы на собственном опыте: у нас имеется 10 точек присутствия с NS-серверами, расположенные в разных точках планеты. На них необходимо регулярно вносить различные изменения: обновлять операционную систему, устанавливать и обновлять различное ПО, изменять конфигурцию и т.п. Мы решили все эти операции автоматизировать и внедрить систему удаленного управления конфигурациями. Изучив имеющиеся решения, мы остановили свой выбор на Ansible.

В этой статье мы бы хотели подробно рассказать о его возможностях этого инструмента управления конфигурациями и поделиться собственным опытом его использования.

Что такое Ansible?

Ansible — опенсорсное программное решение для удаленного управления конфигурациями, разработанное Майклом Де Хаанном в 2012 году. Название продукта взято из научно-фантастической литературы: в романах американской писательницы Урсулы Ле Гуин ансиблом называется устройство для оперативной космической связи.

Ansible берет на себя всю работу по приведению удаленных серверов в необходимое состояние. Администратору необходимо лишь описать, как достичь этого состояния с помощью так называемых сценариев (playbooks; это аналог рецептов в Chef). Такая технология позволяет очень быстро осуществлять переконфигурирование системы: достаточно всего лишь добавить несколько новых строк в сценарий.

Почему Ansible?

Преимущества Ansible по сравнению с другими аналогичными решениями (здесь в первую очередь следует назвать такие продукты, как Puppet, Chef и Salt) заключаются в следующем:

• на управляемые узлы не нужно устанавливать никакого дополнительного ПО, всё работает через SSH (в случае необходимости дополнительные модули можно взять из официального репозитория);
• код программы, написанный на Python, очень прост; при необходимости написание дополнительных модулей не составляет особого труда;
• язык, на котором пишутся сценарии, также предельно прост;
• низкий порог вхождения: обучиться работе с Ansible можно за очень короткое время;
• документация к продукту написана очень подробно и вместе с тем — просто и понятно; она регулярно обновляется;
• Ansible работает не только в режиме push, но и pull, как это делают большинство систем управления (Puppet, Chef);
• имеется возможность последовательного обновления состояния узлов (rolling update).

Push или pull?

“Из коробки” все сценарии и команды выполняются методом push: когда возникает необходимость, мы запускаем сценарий, и он последовательно выполняется на удалённых серверах. Однако разработчики также предусмотрели метод pull и даже написали специальное приложение для установки необходимой для этого части ansible на удалённые хосты.

Установка

Требования для установки Ansible минимальны. На машине с которой производится управление должен быть установлен Python 2.6 или выше. На управляемых узлах должен быть установлен только Python версии не ниже 2.4, но он, как правило, по умолчанию включен в состав большинства дистрибутивов linux-систем. MS Windows не поддерживается.

Вам также могут потребоваться следующие модули Python, устанавливаемые через pip или пакетный менеджер вашей операционной системы:

В Ubuntu установка самого Ansible и зависимостей осуществляется добавлением репозитория и установкой пакета:

О процедуре установки в других ОС можно прочитать в официальной документации.

Группы серверов

Список групп серверов, которыми нужно управлять, Ansible может получать двумя основными способами:

• из специального текстового файла (далее этот вариант будет рассмотрен более подробно);
• с помощью внешнего скрипта, возвращающего нужный нам список серверов, например из MongoDB. В официальном github-репозитории есть готовые скрипты для получения списка из Cobbler, Digital Ocean, EC2, Linode, OpenStack Nova, Openshift, Spacewalk, Vagrant,Zabbix.

Файл hosts

Дефолтное расположение файла — /etc/ansible/hosts, но оно может также быть задано параметром окружения $ANSIBLE_HOSTS или параметром -i при запуске ansible и ansible-playbook. Содержимое этого файла может выглядеть, например, так (в квадратных скобках указаны имена групп управляемых узлов, ниже перечисляются входящие в эти группы серверы):

Помимо списка управляемых узлов, в файле hosts могут быть указаны и другие сведения, необходимые для работы: номера портов для подключения по SSH, способ подключения, пароль для подключения по SSH, имя пользователя, объединения групп и т.п. В некоторых случаях — в частности, при работе с большими и сложными конфигурациями, — различные параметры можно выносить в отдельные файлы и каталоги (о структуре каталогов см. ниже).

Более подробно о файле hosts и правилах его написания можно почитать в официальной документации.

Информация об узлах (Facts)

Перед внесением изменений Ansible подключается к управляемым узлам и собирает информацию о них: о сетевых интерфейсах и их состоянии, об установленной операционной системе и т.п. Он может делать это как с помощью собственного модуля, так и с помощью инструментов ohai и facter, если они установлены (такая возможность специально предусмотрена для пользователей, уже имеющих опыт работы с системами удаленного управления конфигурациями: ohai и facter являются библиотеками фактов для Chef и Puppet).

Переменные

Во время деплоя, как правило, требуется не только установить какое-либо приложение, но и настроить его в соответствии с определенными параметрами на основании принадлежности к группе серверов или индивидуально (например, ip-адрес BGP-соседа и номер его AS или параметры для базы данных). Как уже было сказано, загромождать файл hosts будет не очень красиво, поэтому разработчики Ansible пошли следующим путём:

• файлы с переменными групп хранятся в директории “group_vars/имя_группы”;
• файлы с переменными хостов в директории “hosts_vars/имя_хоста”;
• файлы с переменными роли (о них речь пойдет ниже) в директории “имя_роли/vars/имя_задачи.yml”;

Помимо пользовательских переменных можно (и даже нужно) использовать факты, собранные ansible перед выполнением сценариев и отдельных задач.

Модули Ansible

В состав Ansible входит огромное количество модулей для развёртывания, контроля и управления различными компонентами, которые можно условно разделить на следующие группы (в скобках приведены названия некоторых продуктов и сервисов):

• облачные ресурсы и виртуализация (Openstack, libvirt);
• базы данных (MySQL, Postgresql, Redis, Riak);
• файлы (шаблонизация, регулярные выражения, права доступа);
• мониторинг (Nagios, monit);
• оповещения о ходе выполнения сценария (Jabber, Irc, почта, MQTT, Hipchat);
• сеть и сетевая инфраструктура (Openstack, Arista);
• управление пакетами (apt, yum, rhn-channel, npm, pacman, pip, gem);
• система (LVM, Selinux, ZFS, cron, файловые системы, сервисы, модули ядра);
• работа с различными утилитами (git, hg).

О том, с чем умеет работать Ansible “из коробки”, можно прочитать в официальной документации. Список действительно впечатляет.

Примеры простых задач

С помощью Ansible можно одновременно выполнить одну задачу на целой группе серверов. Попробуем, например, отправить запрос ping на серверы выбранной группы:

Следующий пример соберёт информацию о хостах и выведёт её на консоль в формате JSON:

$ ansible dnsservers -m setup

А вот так можно создать логический том (или, в зависимости от текущего состояния, изменить его размер) с именем examplevolume в группе examplegroup:

Ansible позволяет не только выполнять единичные задачи, но и писать сценарии, которые необходимо выполнить на управляемых узлах. Рассмотрим структуру и правила написания таких сценариев более подробно.

Cценарии (playbooks)

Все сценарии в Ansible пишутся на YAML. Это — человекочитаемый формат сериализованных данных, гораздо более простой, чем XML или JSON.

Чтобы выполнить сценарий используется команда ansible-playbook со следующим сиснтаксисом:

В начале сценария обязательно должна присутствовать последовательность символов «–––» (так в YAML обозначается начало документа). Перед каждым новым разделом списка ставится дефис ( – ):

Основными параметрами/группами простого сценария являются:

• hosts — в нем указываются управляемые узлы или группы узлов, к которым нужно применить изменения;
• tasks — здесь описывается состояние, в которое необходимо привести управляемый узел, альтернативой этому могут служить роли;

Также в сценарии перед непосредственным описанием задач могут быть указаны следующие параметры или группы параметров:

• gather_facts — собирать или нет информацию о хостах перед выполнением задач, по умолчанию — да;
• vars — в нем указываются различные переменные, которые будут использованы при выполнении сценария;
• connection — можно указать метод соединения с хостами: pure ssh, paramiko, fireball, chroot, jail, local, accelerate (применимо также для выполнения отдельного модуля);
• sudo — после установления соединения выполнять задачу с привилегиями другого пользователя, по умолчанию другой пользователь — root;
• sudo_user — в сочетании с предыдущим параметром можно указать с привилегиями какого именно пользователя будет выполнена задача;
• vars_prompt — перед выполением плэйбука Ansible в интерактивном режиме может уточнить указанные в этом разделе параметры;
• remote_user (в предыдущих версиях — просто user) — имя пользователя для авторизации на удалённом хосте.

Рассмотрим все эти разделы более подробно.

В разделе hosts указывается группа управляемых узлов, к которой будут применены описываемые в сценарии изменения.

Так, строка формата:

означает, что изменения будут применены к узлам из группы webservers.

Сценарии могут выполняться не только от имени пользователя, под именем которого установлено соедиение, но и любого другого. В следующем примере авторизация на хосте будет произведена с именем yourname, но задачи будут выполняться от имени пользователя root (если, конечно, этому пользователю это разрешено):

Если добавить параметр “user: postgres”, то все действия будут выполняться с привилегиями пользователя postgres.

В разделе vars указываются переменные, которые будут использованы в сценарии, и их значения:

Список изменений, которые необходимо произвести на управляемом узле, приводится в разделе tasks. Каждой задаче (task) присваивается имя (name). Далее указываются модули Ansible, которые будут задействованы при ее выполнении:

Для каждой задачи можно указывать пользователя, от имени которого она будет выполнена:

Шаблонизация

В Ansbile используется шаблонизатор Jinja2. Приведём пример шаблона (часть конфигаpowerdns):

В приведённом примере мы подставляем в шаблон следующие значения:

• из заранее собранных фактов о хосте:
  • ansible_default_ipv4.address — основной IPv4-адрес хоста;
  • ansible_default_ipv6.address — основной IPv6-адрес хоста;
  • ansible_hostname — имя хоста (результат выполнения команды hostname).
• inventory_hostname — имя хоста в инвентарном файле;
• пароль пользователя powerdns из внешнего источника данных (в данном случае файл) для подключения к базе Postgresql , полученный с помощью lookup-плагина password из стандартной поставке. Особенность некоторых lookup-плагинов — если данных нет, то они могут их сгенерировать и сохранить для последующего использования.

Обработку шаблонов и, в данном случае, генерацию конфигурационного файла выполняет модуль template; он же может задать необходимые права доступа и изменить владельца/группу:

Обратим внимание на то, что файл шаблона и файл с паролем пользователя базы данных находятся на машине управления, а результатом будет файл на удалённом узле.

Обработчики событий (Handlers)

Ansible не просто выполняет задачи в указанном порядке, но и проверяет их состояние на наличие изменений. Если при выполнении сценария требовалось, например, добавить строку в конфигурационный файл, и в результате выполнения он изменился (необходимой строки действительно не было), то Ansible может выполнить специальную задачу, описанную как обработчик события (handler). Если при выполнении строка уже была в конфигурационном файле, то обработчик выполнен не будет. Обработчики событий описываются в конце сценария; в описании задачи они указываются через параметр notify. Приведём пример:

Контроль выполнения

Допустим, что при выполнении сценария нам нужно проверять определённые переменные или состояния и, в зависимости от них, выполнять или не выполнять какие-либо задачи. Для этого можно использовать оператор “when”:

Делегирование задачи другому хосту

Иногда требуется выполнить задачу на определённом узле, но в контексте другого узла. Например, во время обновления узла может возникнуть необходимость отключить для него мониторинг, находящийся на отдельном сервере. Для этого используется управляющая директива delegate_to. Приведём пример:

Результатом выполнения этой задачи будет отключение сообщений для сервиса dnsserver в Nagios.

Ролью называется типовой набор переменных и задач, назначаемых для одного или нескольких серверов. Если вам нужно применить к серверу или группе серверов типовой набор операций, вам достаточно просто назначить ему роль. Предварительно в проекте каталоге проекта должна быть создана соответствующая структура. В сценариях роли назначаются следующим образом:

Структура проекта

Пример сценария

Чтобы понять, как это все работает, рассмотрим практический пример: простой сценарий развёртывания новой версии PostgreSQL 9.3 на debian-based ОС. Роли в этом примере не используются.

Ansible AWX

Во всех приведенных выше примерах управление Ansible осуществляется с помощью интерфейса командной строки. Но с официального сайта можно загрузить графическую панель управления Ansibleworks AWX, очень симпатичную внешне и удобную в использовании. Собственно, за счет ее распространения и осуществляется монетизация продукта: управление небольшим (до 10) количеством серверов обходится бесплатно, если же серверов больше — нужно приобретать лицензию. Похожие варианты монетизации используются и разработчиками конкурирующих решений — Puppet и Chef.

Заключение

Ansible — достаточно простой, но при этом эффективный инструмент для удаленного управления конфигурациями. В рамках этой статьи мы сделали лишь беглый обзор его возможностей и рассказали, как пишутся сценарии для решения простых задач. Все возможности и варианты использования Ansible в рамках одной статьи охватить невозможно. О применении этого инструмента для решения более специфических задач мы расскажем в последующих публикациях.

Для желающих узнать больше — несколько ссылок:

https://github.com/ansible/ — официальный аккаунт на github c исходным кодом проекта и хорошим набором примеров проектов

https://jpmens.net/2012/06/06/configuration-management-with-ansible/ — статья Яна Пита Менса об управлении конфигурациями с помощью Ansible (в его блоге есть и много других материалов по теме).

https://gist.github.com/marktheunissen/2979474 — пример сценария с подробными комментариями, правда для старой версии.

https://www.ansibleworks.com/docs/contrib.html — ещё больше ссылок на примеры использования, включая в том числе и очень сложные конфигурации.

Добавить комментарий Отменить ответ

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.

Источник