Установка ansible astra linux

linux-notes.org

Установка и настройка Ansible в Unix/Linux

Ansible — бесплатное ПО для конфигурирования и управления компьютерами, сочетает в себе развертывание многоузлового программного обеспечения, выполнения различных задач и управление конфигурациями. Он управляет нодами (которые должны иметь поддержку Python 2.4 или более поздней версии) через SSH. Модули работают над JSON и стандартный вывод может быть написан на любом языке программирования. Система использует YAML для написании функций (задач выполнения).

Установка Ansible в CentOS/RedHat

Чтобы установить ansible для начала, стоит подключить репозиторий EPEL, вот статья как это сделать:

После чего, обновим ОС:

Устанавливаем ansible из пакета:

Установка Ansible в Fedora

После чего, обновим ОС:

Устанавливаем ansible из пакета:

Или можно установить ansible как описывалось для Centos.

Установка Ansible в Debian/Ubuntu

Для Ubuntu 14.04 LTS

Для установки, на управляющем сервере введите:

Здесь мы будем использовать официальный Ansible PPA репозиторий, по этому, добавляем его:

И собственно, выполняем установку:

Установка Ansible на Mac OS X

Первое что необходимо сделать — Устанавливаем Xcode:

Нашел пакет ansible в репозитории homebrew, попробовал установить:

Установку можно выполнить и через python:

Опция «—quiet» — дает возможность установить пакет в «тихом» режиме без вывода на экран.

Чтобы обновить, используйте:

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

Если инструменты не установлены, вы увидите этот вывод:

Установка ansible через GIT

Так же, вы можете установить ансибл из github.

Клонируем ansible с github-а:

Проверяем, загрузились ли модули:

Установить некоторые необходимые модули:

Собираем и устанавливаем:

Установим environment для ансибл:

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

Проверка версии ansible

Проверяем версию ansible:

Как работает ansible?

Главная цель Ansible — это с одного (можно сделать и пару) серверов с ансиблом можно было управлять всеми другими нодами. С такого сервера можно отправлять различные команды (набор некоторых инструкций, так называемых playbooks) на любую из подключенных нод на сервере. Выполнение команд выполняется путем подключения сервера к ноде через публичный ключ по SSH. Внизу представлена наглядная схема того как все на нем устроено:

В файле «Host inventory» содержится информация о обслуживаемых нодах ( где собственно все команды будут исполнены). Конфигурационный файл с Ansible может быть использован для настройки переменного окружения.

В ansible, используются playbooks — это набор инструкций и они состоят из задач. Плейбуки описываются с помощью функциональности модуля ядра самого Ansible ( так же, могут использовать сторонние модули). Playbooks — последовательность или набор команд в которых так же, может использоваться различные проверки: если условие не выполняется, то определенные команды могут пропускаться. Данные кукбуки, описываются в формате YAML.

С Ansible API — вы можете запускать скрипты. Если скрипту-обертке (wrapper) может понадобится запуск playbook, то это можно сделать через API.

Настройка Ansible в Unix/Linux

Сам конфигурационный файл описывается в формате INI. Так же, имеется возможность переопределения части конфигурации( можно даже всего конфига) в параметрах playbook или в переменных окружения.
При выполнении команд, Ansible выполняет проверку и ищет наличия файла с конфигурациями в следующих расположениях:
Параметр ANSIBLE_CONFIG проверяется переменная окружения, который может быть указывать на файл конфигурации.

./ansible.cfg – в текущей папке.

/.ansible.cfg — в домашней директории пользователя.

/etc/ansible/ansible.cfg — в папке, смого ansible.

Настройка через переменные окружения

Много опций, можно задать с помощью переменного окружения, для этого стоит использовать префикс ANSIBLE_ перед названием самого параметра с конфигурацией (большими буквами). Например:

После чего переменная ANSIBLE_SUDO_USER может быть использована в playbook.

Настройка в ansible.cfg

Самих параметров в Ansible конфигурации много, но основные я перечислю:

• hostfile: Данная опция указывает на путь к inventory file. В нем хранится список ваших хостов, к которым Ansible сможет выполнить подключение.
  Например: hostfile = /etc/ansible/hosts
• library: Путь к папке. В ней сохранены все модули Ansible.
  Например: library = /usr/share/ansible
• forks: Задается количество процессов, которые может породить Ansible. По-умолчанию параметр установлен в 5.
  Например: forks = 5
• sudo_user: Пользователь который будет использоватся по умолчанию и от которого Ansible собственно будет выполнять запуск команд на удаленных нодах.
  Например: sudo_user = root
• remote_port: Порт для соединения по SSH к нодам (по умолчанию использует стандартный 22-й порт).
  Например: remote_port = 22
• host_key_checking: Данная опция дает возможность выключить проверку SSH–ключа на хосте, но по-умолчанию даная проверка включена.
  Например: host_key_checking = False
• timeout: Данная опция задает таймаут ( время попытки подключения по SSH).
  Например: timeout = 60
• log_path: Путь для сохранения лог-файлов. По-умолчанию Ansible не сохранит их вообще.
  Например: log_path = /var/log/ansible.log

Пишем первый файл конфигурации Ansible

Сейчас я создам первый конфигурационный файл для Ansible. Для этого нужно выполнить подключение по SSH к серверу где установлен Ansible. Я создам папку для всех моих проектов и после чего, перейду в нее:

Также создаем директорию для сохранения всех модулей для Ansible и так же, директорию для сохранения всех логов (куда же без них):

Подошло время к созданию файл ansible.cfg:

В него прописываем:

В новой версии ansible поля «hostfile» нет, за место его, есть другое:

Указываем обслуживаемые сервера в host inventory

Как я описывал раньше, данный файл, служит для внесения IP адресов всех имеющихся нод ( те, которые будут обслуживаться) и так же, сгруппирую их. Для этого создаем файл inventory:

И добавляем IP всех удаленных хостов:

Возьму для примера, один сервер на локальной машине с 192.168.1.216.

Генерация ключа для ansible

Как я говорил ранее, ansible использует подключение SSH по ключу (для доступа к настраиваемым серверам), по этому, нужно сгенерировать его:

Или более расширенный вариант:

Заблокирую доступ к SSH каталогу, что только вы cмогли читать или писать в данную папку:

Нужно изменить разрешения, чтобы сохранить этоти файлы в безопасности:

Создаем простой ключ, все пропускаем (нажимаем enter на все вопросы). После того как ключ сгенерировали, нужно его передать на все имеющийся ноды, для этого есть команда:

PS: И так для каждой управляемой ноды!

Выставим правильные права:

Чтобы проверить работает ли все хорошо, можно подключится на сервер по SSH и если не спросит пароль, то все работает хорошо ( можно и выполнить ПИНГ на удаленный хост с сервера ансибл).

Можно попинговать обслуживаемые сервера:

Можно пингануть и проверить все сервера:

Можно так же, выполнить пинг по группированной группе:

Можно бы также указать индивидуальный хост:

We can specify multiple hosts by separating them with colons:

Опция «-m ping» — часть команды для анзибль которая дает возможность использовать модуль «Ping». Вы можете проверить работу данной команды с опций «-a» и проверить как работает данная опция.

Модуль «shell» позволяет нам послать команду на удаленный хост и получить результаты. Например, чтобы узнать использование памяти на нашей машине some_your_host_1, мы могли бы использовать:

Проверка аптайма на серверах:

Проверить hostname и архитектуру на всех нодах:

Если нам нужен выход в файл, то можно и это сделать:

Управление ansible конфигурациями

Работаем с playbook-ами

На playbook-ах основан собственно весь ansible, так как они служат ( содержат) для выполнения разных задач. Каждая написанная задача внутри самого Ansible использует кусок кода-модуля. Плейбуки, используют формат YAML, но собственно, любые другие ваши модули могут быть написаны на любом языке программирования.

Хочу заметить, что очень важно, чтобы формат сообщений от модулей был в JSON.

YAML

Каждый плейбук пишется на языке YAML и для ансибл, почти каждый YAML файл начинается с некоторого списка, а этот элемент данного списка — список пар «ключ-значение»(иногда зовут словарем).

Данные файлы обязаны начинаться с «—» (такой формат присущий YAML )и означает начало вашего документа.

Так же, все ваши списки должны находится с одинаковым отступом от начала каждой строки, и должны начинаться с пробела или «-«. Чтобы закомментировать, используйте «#».
Например:

Словарь представлен в виде «ключ:» (двоеточие и пробел) «значение»:

При необходимости словари могут быть представлены в сокращенной форме:

Можно указать логические значение (истина/ложь) так:

Целиком наш пример YAML–файла будет выглядеть так:

Для переменных Ansible использует «<< var >>». Если значение после двоеточия начинается с « <«, то YAML будет думать, что это словать.
Для использования переменных нужно заключить скобки в кавычки:

Этого достаточно для начала написания playbooks.

Пишем наш первый playbook

Playbooks может состоять из списка обслуживаемых серверов, переменных пользователя, задач, обработчиков (хендлеров) и т.д. Большинство настроек конфигурации можно переопределить в playbook. Каждый playbook состоит из одного или более действия (игры) в списке.

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

В качестве примера давайте рассмотрим процесс установки nginx.
Создадим директорию, где будут хранится playbooks:

Создадим файл setup_nginx.yml в директории playbooks:

со следующим содержанием:

Давайте рассмотрим содержимое:

• hosts: Список хостов или группа, на которой вы запускаете задачу. Это поле обязательное и каждый playbook должен иметь его, за исключением ролей. Если указана хост-группа, сначала Ansible ее ищет в playbook, а затем в файле inventory. Узнать, на каких хостах будет происходить работа, можно командой: ansible-playbook —list-host, где – путь к вашему playbook (playbooks/setup_nginx.yml).
• tasks: Задачи. Все playbooks содержат задачи. Задача — это список действий, которые вы хотите выполнить. Поле задачи содержит имя задачи (справочная информация о задаче для пользователя playbook), модуль, который должен быть выполнен и аргументы, требуемые для модуля. Параметр «name» опциональный, но рекомендуемый.

Команды

playbook для ansible
Выполнение плейбука с названием test_job.yml для определенного хоста или группы хостов (прописано в файле):

Опция «-i» говорит ансиблу использовать произвольные хосты с файла. Иногда вы можете захотеть выполнить данный playbook (или часть его), только на определенных хостах. Вместо того, чтобы делать различные хосты в разные файлы, можно попробовать эти методы:

Используйте опцию «—limit» чтобы указать на каком хосте запустить указанный плейбук (например на host1):

Используйте опцию «—limit» чтобы указать несколько хостов (розделенные запятыми), например для host1,host2,host3:

Используйте опцию «—limit» чтобы указать диапазон подобных хостов, например host10-host20 или host5-15:

Используйте опцию «—limit» чтобы указать файл с которого будет браться хосты (должны идти в столбик):

Если вы не уверены в том, что опция «—limit» будет работать, вы можете использовать опцию «—list-hosts» и вы получите список хостов, на которых будет выполняться playbook.

Можно задавать так званые метки для некоторых задач и потом выполнять их по этим заданным меткам. Можно сделать задачу чтобы она выполнялась в любых условиях, независимо от меток. Это может быть сделано путем добавления:

Примеры

Пример использования «—tags» и «—skip-tags», открываем main.yml файл и прописываем:

Теперь, если хотите скопирывать ТОЛЬКО MY_FILE_HERE_1, выполните:

Если хотите наоборот, скопировать все, НО КРОМЕ MY_FILE_HERE_1, запустите:

Проверьте, какие задачи будут выполнены из данного плейбука «—tags или —skip-tags»:

Пример хэш-цикла в ансибль:

Выполнить любую команду с ансиблом — это просто:

Запускаем команду «-a «/bin/uptime»» на всех хостах ( опция «all») с определенного файла (опция «-i») с установленным паралельным использованием в 10.

Запускаем команды с использованием модуля «shell»:

Где, some_host — Хост, на котором будет выполняться команда.

Копируем файл на удаленный сервер:

Мы же создадим чистую роль:

PS: У меня запускается с текущей директории ( где находится проект с ансиблом).

Вот и все! Тема «Установка и настройка Ansible в Unix/Linux» завершена.

2 thoughts on “ Установка и настройка Ansible в Unix/Linux ”

Приветствую тебя. Сперва хочу поблагодарить тебя за проделанный труд. От души! Ну а теперь к делу. Скажи пожалуйста, как установить определенную версия ansible? Возможно ли это? Или всегда будет устанавливаться последняя? И еще, может ли быть какое-либо противоречие, если например писал playbook в одной версии, а пытаешься выполнить в другой?

Спасибо за статью! Но для чайников можно было подробней расписать использование утилиты ssh-copy-id. Как минимум то, что при ее использовании надо перейти в каталог .ssh затем уже ее использовать с опцией -i [ ssh-copy-id -i *.pub root@root@ip_адрес_настраиваемого_сервера ]

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

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

Источник

Ansible + Alt Linux

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

Необходим инструмент, который позволит гибко управлять состоянием множества машин, на котором живет ваша система. Такие инструменты называются системами управления конфигурациями. Ansible, Chef, Puppet – лидеры на этом рынке, и далее мы рассмотрим, в чем их основные отличия. Как вы поняли из названия статьи, мой выбор пал на Ansible. Мы попробуем использовать этот продукт на примере развертывания кластера Elasticsearch.

В последние несколько лет в законодательстве России началось активное движение в сторону отечественного программного обеспечения в государственных структурах. Это движение коснулось и нашей компании, так как многие заказчики являются различными министерствами. Скоро в гос. структурах будет установлен российский дистрибутив ОС ALT Linux (Альт Линукс). В связи с этим в задаче конфигурирования серверов с помощью Ansible возникает новый вопрос, с которым мы будем разбираться: насколько поддерживает Ansible российскую ОС?

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

Рассмотрим три главные системы управления конфигурациями на сегодняшний день:

• Puppet. Одно из первых подобных решений. Puppet использует архитектуру мастер-агенты. Агенты устанавливаются на управляемые сервера и запрашивают информацию об изменении конфигурации у мастера или получают ее непосредственным запросом от него. Puppet написан на Ruby и требует описания конфигураций на этом же языке. Это крупный enterprise продукт, который обладает наибольшим перечнем возможностей среди подобных систем и поддержкой большинства ОС.
• Chef. Это решение во многом похоже на Puppet. Chef тоже написан на Ruby и предполагает написание модулей и конфигураций на Ruby. Он также основывается на идее мастер-агенты. Для конфигурирования серверов в Chef используются “рецепты” – описания состояний операционной системы в конкретные моменты времени. Считается, что Chef обладает меньшей функциональностью, чем Puppet, но обладает своими преимуществами при определенных сценариях.
• Ansible. Если первые два продукта похожи во многих аспектах, Ansible совсем другой. Во-первых, для работы Ansible, не нужно устанавливать агенты на управляемые узлы, так как все команды выполняются по SSH. Во-вторых, он написан на Python, а для конфигурирования используется язык YAML. Это значительно повышает возможности инженеров для создания конфигураций самостоятельно. YAML – интуитивно понятный язык разметки, в то время как для изучения Ruby может потребоваться некоторое время. Кроме того, Ansible делает упор на скорость и выигрывает в производительности у своих конкурентов.

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

Первоначальная настройка

Для демонстрации возможностей Ansible я буду использовать несколько виртуальных машин с установленным ALT Linux Server. Скачать дистрибутив можно отсюда. Одна из виртуалок будет использоваться как Ansible-хост, остальные будем пробовать конфигурировать.

В первую очередь нужно установить Ansible на один из серверов:

Далее проведем начальную настройку машин, которые будем конфигурировать. Основное отличие использования Ansible с дистрибутивами ALT Linux от других дистрибутивов заключается именно в этом шаге. Непосредственное же использование системы на разных ОС семейства Unix отличается незначительно (например, вызываются разные менеджеры пакетов).

Необходимо предоставить пользователю, под которым мы будем заходить на сервер, права sudo. Пользователь, который создается при установке ОС, автоматически добавляется в группу wheel. Поэтому достаточно раскомментировать строчку WHEEL_USERS ALL = (ALL) ALL в файле /etc/sudoers.

Далее добавим возможность подключаться к удаленному серверу под созданным пользователем без ввода пароля. Для этого на Ansible-сервере выполним команды ssh-keygen и ssh-copy-id. Первая создает ключ SSH, а вторая устанавливает его на удаленный сервер.

И последний шаг перед использованием Ansible – это установка Python-пакета simplejson. Все ответы Ansible отправляет в формате JSON, а дистрибутив ALT Linux не содержит этот пакет. Решается это двумя командами:

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

Чтобы управлять состоянием машин, не перечисляя каждый раз список айпишников, в Ansible есть файл Inventory. В нем можно определить группы серверов и указать имена, по которым к ним обращаться. Файлом Inventory на самом деле называется файл hosts, который находится в директории /etc/ansible:

Для каждого хоста можно указать название и пользователя, под которым мы будем на него заходить. В Linux системах не рекомендуется использовать для подключения по SSH root-пользователя. Поэтому используем обычного пользователя, которого добавили в группу wheel на этапе настройки Ansible.

Модули

Модули – это готовые библиотеки, которые позволяют взаимодействовать с системными ресурсами (например: сервисами, пакетами, файлами) и обрабатывать системные команды. Модули можно использовать в командной строке или в плейбуках (об этом в следующем разделе). Для вызова из командной строки нужно выполнить команду ansible “host” -m “module”. Рассмотрим простейший модуль ping, который подключается к серверу, проверяет, что все необходимые python модули установлены и отвечает pong.

Большинство модулей требует передачи аргументов. В командной строке для этого служит ключ -a, после которого следует строка из имен и значений аргументов в формате “name1=value1 name2=value2”.

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

• command – выполнение команды на удаленном сервере.
• apk (apt, apt_rpm) – установка ПО через менеджер пакетов.
• copy – копирование файла на удаленный сервер.
• user – создание, удаление и другие действия с пользователями.
• setup – сбор информации о хосте.
• raw — аналогично command, но ответ не в формате JSON. Благодаря этому модулю можно провести первоначальную настройку на ALT Linux, установив пакет simplejson.

Важная идея модулей в их идемпотентности. То есть, состояние машины после повторного выполнения модуля останется тем же, что и при первом. Этой же идее следуют и плейбуки.

Плейбуки

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

Плейбуки (playbooks) – основной инструмент для конфигурирования серверов в Ansible. На первый взгляд это и есть та самая последовательность команд, только представленная не bash-скриптом, а YAML файлом. Тем не менее, плейбуки обладают возможностями, которые простыми скриптами реализовать значительно сложнее.

Рассмотрим структуру плейбуков:

• Сервера и пользователи. Первоначально необходимо указать, на каких хостах (параметр hosts) будет отрабатывать этот плейбук и под каким пользователем (remote_user) будут выполняться его команды. В качестве hosts можно использовать группу серверов или список групп, а также маски. Если в файле Inventory для хостов указан ansible_ssh_user, то прописывать параметр remote_user необязательно.
• Переменные. В блоке vars можно перечислить имена переменных и их значения. Их можно будет использовать только в рамках этого плейбука. Если переменных очень много, можно вынести их в отдельный файл и указать его имя в блоке var_files.
• Задания. Это обязательная часть любого плейбука. Задания перечисляются в блоке tasks. Каждому заданию соответствует название (name), модуль и значения его аргументов.
• Обработка событий. Выполнение модулей может менять состояние системы, но может и не менять. В плейбуках есть возможность определить события, которые генерируется при изменении состояния хоста после выполнения задания. В конце плейбука необходимо описать обработчики событий – задания, которые будут выполняться при возникновении события.

Elasticsearch

Давайте используем Ansible для решения реальной задачи. Напишем плейбук, который разворачивает кластер из поисковых движков Elasticsearch на нескольких хостах. Для начала добавим в файл Inventory новую группу хостов, которую назовем elastic. Пусть в ней будет пара серверов из тех, что мы уже определили.

Пропишем в поле hosts плейбука только что созданную группу. Первое задание будет устанавливать Java. Для этого воспользуемся модулем apt_rpm, который устанавливает указанный пакет. Это действие нужно выполнять с sudo-привелегиями, поэтому используем параметр become в начале плейбука.

Теперь воспользуемся модулем unarchive. Он распаковывает архив с Ansible-хоста на удаленный сервер. Интересно, что в первоначальной версии плейбука я использовал три другие модуля для этого действия: copy для копирования архива, command с выполнением tar для распаковки и command с выполнением chown для присвоения нужных прав. Однако, в результате выполнения плейбука, Ansible вывел подсказку об упрощении этих команд.

Далее создадим конфиг Elasticsearch, который будем копировать на сервера. Пока укажем в нем только параметр network.host со значением 0.0.0.0. По умолчанию Elasticsearch использует значение 127.0.0.1, но для создания кластера нам необходимо, чтобы движок был доступен в публичной сети. Добавим задание copy, которое копирует созданный конфиг на удаленные хосты.

Осталось только запустить полнотекстовый движок. Для этого используем модуль command. Это задание будем выполнять не под sudo, поэтому укажем become: false. Также мы не будем дожидаться окончания выполнения этого задания, для этого пропишем async: 10 (асинхронно в течение 10 секунд) и poll: 0 (не проверять состояние). Так выглядит наша первая версия плейбука:

Выполнение плейбука осуществляется командой ansible-playbook “имя плейбука”.

Обработка событий

Преобразуем задание по запуску Elasticsearch в обработчик события. Событие же будем генерировать при изменении конфига движка. Я вижу два преимущества событий перед обычными заданиями:

• Если такое задание встречается в нескольких местах плейбука (например, под условием when), то вынос его в обработчики событий улучшит читаемость плейбука и будет соответствовать парадигме Don’t Repeat Yourself.
• Второе же замечание куда важнее с технической стороны, нежели с эстетической. Событие будет сгенерировано только в том случае, если состояние системы действительно изменилось. То есть, если в результате выполнения задания конфиг остался прежним, то перезапуск Elasticsearch не произойдет. Это возможно, благодаря идемпотентности модулей.

Так изменился плейбук:

Переменные

На текущий момент в нашем конфиге Elasticsearch, есть информация только о том, что мы используем публичный ip. Эта информация представляется одинаковым образом для всех хостов, поэтому проблемы с реализацией этого в Ansible не возникло. Но если нам потребуется использовать специфичную для серверов информацию, то появятся вопросы: где ее указать и как ее оттуда извлечь? (Переменные и шаблоны)

В Ansible есть несколько мест, где можно определять переменные, и с двумя из них мы уже столкнулись.

• Файл Inventory. При определении хостов, можно указывать значения зарезервированных Ansible переменных, таких как ansible_ssh_port, ansible_ssh_user и тд.
• Плейбук. Специфичные для плейбука переменные определяются в блоках vars и var_files.
• host_vars. Переменные, относящиеся к конкретному серверу можно определить в отдельном файле. Для этого необходимо создать файл /etc/ansible/host_vars/”имя хоста” и перечислить в нем переменные и их значения.
• group_vars. Аналогично можно сделать и с группами серверов. Для этого используется директория group_vars.

Создадим файлы переменных для группы elastic и каждого из хостов этой группы. Определим в них имя кластера и имена нод (каждого сервера).

Файл host_vars/alt.linux1 (для alt.linux2 аналогично):

Шаблоны

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

Шаблонизатор Jinja2 поддерживает и более сложные конструкции, чем подстановка значений переменных. Например, в шаблонах можно описывать условия и циклы. Кроме того, в шаблонах можно использовать не только переменные, которые мы определили самостоятельно. В них доступно все, что было собрано первым модулем любого плейбука (кроме тех, где было указано обратное) — setup. Воспользуемся этими двумя идеями для того, чтобы добавить настройку обнаружения узлов кластера в конфиг. В поле discovery.zen.ping.unicast.hosts укажем список IP серверов группы elastic.

Осталось изменить задание с копированием конфига, указав модуль template и путь к шаблону.

Выполнение плейбука разворачивает кластер Elasticsearch на конфигурируемых серверах.

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

Один из плюсов ролей состоит в том, что это стандартная структура, и вы можете использовать готовые роли из публичных репозиториев. Помимо этого, Ansible предлагает некоторые дополнительные возможности при использовании ролей. Например, зависимости ролей друг от друга – роль будет автоматически выполнена после той, от которой зависит.

Итак, создадим роль elastic_role. Для этого перенесем архив с Elasticsearch в папку files, а шаблон конфига в папку templates. Список заданий вынесем в файл main.yml (дефолтное имя) директории tasks, а обработчик события в main.yml директории handlers. Директория vars используется для переменных, специфичных для роли (нам такие не нужны), а meta включает описание зависимостей. Осталось описать новый плейбук, который будет запускать нашу роль:

Заключение

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

Written on June 2nd , 2018 by Alexey Kalina

Источник