ansible что такое роль
Ansible что такое роль
Роли это способ логического разбития файлов Ansible. По сути роли это просто автоматизация выражений include, которая основана на определенной файловой структуре. То есть, нам не нужно будет явно указывать полные пути к файлам с задачами или сценариями, а достаточно лишь соблюдать определенную структуру файлов.
Но, засчет этого, работать с Ansible намного удобней. И у нас рождается модульная структура, которая разбита на роли, например, на основе функциональности.
Для того, чтобы мы могли использовать роли, нужно соблюдать определенную структуру каталогов:
Например, playbook all_roles.yml выглядит так:
Остальные файлы: инвентарный, конфигурационный файл Ansible и каталоги с переменными, находятся в тех же местах (в том же каталоге, что и playbook).
Все роли, по умолчанию, должны быть определены в каталоге roles:
Каталоги внутри роли:
Пример использования ролей¶
Рассмотрим пример использования ролей.
Структура каталога 8_playbook_roles выглядит таким образом:
Файл конфигурации Ansible, инвентарный файл и каталоги с переменными остались без изменений.
Добавлен каталог roles, в котором находятся три роли: usability, security и ospf.
Для ролей usability и security создан только каталог tasks и в нем находится только один файл: main.yml.
Содержимое файла roles/usability/tasks/main.yml:
В нем находятся две задачи. Они достаточно простые и должны быть полностью понятны.
Обратите внимание, что в файле определяются только задачи. К каким хостам они будут применяться, будет определять playbook, который будет использовать роль.
Содержимое файла roles/security/tasks/main.yml также должно быть понятно:
Несмотря на то, что функционал достаточно простой и общий, мы разделили его на две роли. Такое разделение позволяет более четко описать цель роли.
Теперь посмотрим как будет выглядеть playbook, который использует обе роли (файл cfg_initial.yml):
Теперь запустим playbook (предварительно на маршрутизаторах сделаны изменения):
Обратите внимание, что теперь, когда задачи выполняются, перед именем задачи написано имя роли:
Теперь разберемся с ролью ospf. В этой роли используется несколько файлов.
Файл roles/ospf/tasks/main.yml описывает задачи:
Разберемся с содержимым файла:
В шаблоне мы используем переменные:
Получается, что в шаблоне настраиваются команды network, на основе IP-адресов устройства, а затем удаляются лишние команды network.
Проверим работу роли на примере такого playbook cfg_ospf.yml:
Начальная конфигурация R1 такая (две лишних команды network):
Теперь запустим playbook и посмотрим удалятся ли две лишние команды:
Обратите внимание, что до выполнения конфигурации было 4 команды network (мы их видим по содержимому переменной current_ospf_networks):
А после конфигурации, осталось две команды network:
Скорее всего, в реальной жизни вы уберете задачи, которые отображают содержимое переменных. Но, для того чтобы лучше разобраться с тем, что делает роль, они полезны.
На этом мы заканчиваем раздел. О других возможностях использования ролей вы можете почитать в документации, в разделе роли.
Ansible. Роли в Ansible
В этом руководстве вы поймете, как структурированы роли в Ansible. Вы также научитесь использовать готовые роли из Ansible Galaxy.
Кроме того, вы научитесь создавать свои собственные роли Ansible.
Прежде чем приступить к изучению этой статьи, обратитесь к другим главам серии руководств по Ansible, чтобы лучше понять различные темы, упомянутые здесь.
Понимание ролей Ansible
Роль Ansible – это набор файлов, задач, шаблонов, переменных и обработчиков, которые вместе служат определенной цели, например, для настройки службы. Роли позволяют легко повторно использовать код и делиться решениями Ansible с другими пользователями, что делает работу с большими средами более управляемой.
Структура каталога ролей
Типичная роль Ansible следует определенной структуре каталогов, которая обычно состоит из следующих каталогов:
Имейте в виду, что у роли могут быть все вышеупомянутые каталоги или только их часть. Фактически, вы можете определить пустую роль, у которой нет каталогов, но это бесполезно!
Хранение и расположение ролей
По умолчанию Ansible будет искать роли в двух местах:
Однако вы можете сохранить свои роли в другом месте; если вы решите это сделать, вы должны указать и установить параметр конфигурации roles_path в файле конфигурации Ansible ( ansible.cfg ).
Использование ролей Ansible в Playbooks
Есть два разных способа, которыми вы можете импортировать роли в пьесе Ansible :
Например, чтобы статически импортировать роли в playbook, вы можете использовать ключевое слово роли в заголовке playbook следующим образом:
Динамически импортировать роли; вы можете использовать модуль include_role следующим образом:
Использование Ansible Galaxy для готовых ролей
Представьте себе место, где все нужные вам роли Ansible уже предоставляются бесплатно; Это место называется Ansible Galaxy и оно реально!
Ansible Galaxy – это общедоступный веб-сайт, на котором предлагаются роли, предоставленные сообществом. По сути, это публичный репозиторий, в котором размещается огромное количество ролей Ansible. Мы рекомендуем вам посетить сайт Ansible Galaxy galaxy.ansible.com и ознакомиться с его потрясающим контентом.
Поиск ролей
В Ansible Galaxy есть собственная утилита CLI (интерфейс командной строки), и вы можете использовать ее для выполнения операций, связанных с ролями.
Например, вы можете найти роль в репозитории Galaxy с помощью команды поиска ansible-galaxy следующим образом:
Как вы видете; в нем перечислены все роли galaxy, связанные с моим поисковым запросом mariadb.
Получение информации о ролях
Вы можете использовать команду ansible-galaxy info для отображения информации о роли.
Например, на основе результатов поиска, которые вы получили ansible-galaxy search mariadb; вы можете получить дополнительную информацию о роли geerlingguy.mysql:
Как вы видете; Он показал вам подробное описание роли geerlingguy.mysql.
Установка и использование ролей
Прежде чем я покажу вам, как установить роли Ansible Galaxy; Теперь создайте новый каталог ролей в каталоге вашего проекта (plays):
Теперь вы можете использовать команду ansible-galaxy install для установки роли geerlingguy.mysql следующим образом:
Теперь перейдите в каталог ролей и перечислите содержимое каталога ролей geerlingguy.mysql:
Как вы видете; geerlingguy.mysql роль следует стандартной структуре каталогов, что мы показали вам ранее.
Теперь давайте вернемся в каталог plays и создать новый PlayBook с именем MySQL-role.yml, который прикладывает роль geerlingguy.mysql на группу хоста dbservers:
Теперь запустите playbook:
После того, как playbook будет запущен; mysql должен быть запущен на node4:
Если вам больше не нужна роль; вы можете удалить его с помощью команды ansible-galaxy remove следующим образом:
Использование файла требований для установки нескольких ролей
Ansible galaxy может установить сразу несколько ролей, используя файл требований.
Каждая роль, которую вы определяете в своем файле требований, будет иметь еще один из следующих атрибутов:
Чтобы продемонстрировать это, создайте файл requirements.yml со следующими тремя ролями:
Как вы видете; три роли, определенные в файле requirements.yml, успешно установлены. Вы также можете использовать список ansible-galaxy, чтобы перечислить установленные роли вместе с их версиями:
Создание пользовательских ролей
Вы также можете определить свои собственные роли. Для этого вы можете использовать команду ansible-galaxy init, чтобы определить структуру ролей.
Для демонстрации давайте создадим новую роль с именем httpd-role. Сначала перейдите в каталог ролей, а затем запустите команду ansible-galaxy init, за которой следует новое имя роли, как показано ниже:
Обратите внимание, что была создана новая роль с именем httpd-role, и в ней есть все типичные каталоги ролей.
Теперь начните определять задачи, шаблоны и переменные по умолчанию для новой роли httpd.
Во-первых, вы можете начать с определения задач, отредактировав файл tasks/main.yml так, чтобы он содержал следующее содержимое:
Затем вы можете создать файл шаблона Jinja2 index.j2 внутри каталога шаблонов роли:
Наконец, вы можете определить и установить переменную sysadmin в defaults/main.yml:
Хорошо! Теперь вы закончили создание роли. Давайте создадим сценарий, в котором используется httpd-role.
Вернитесь в каталог проекта и создайте playbook apache-role.yml со следующим содержимым:
Обратите внимание, что вы перезаписали переменную sysadmin в playbook. Идите вперед и запустите playbook:
Все выглядит хорошо. Давайте проверим, проверив ответ, который вы получаете на обоих веб-серверах ( node2 и node3 ):
Отлично! Ваша заказная httpd-роль работала безупречно.
Если вы когда-нибудь создадите потрясающую роль Ansible, которая, по вашему мнению, принесет пользу многим; не забудьте опубликовать свою роль в Ansible Galaxy, чтобы поделиться ею со всем миром!
Управление порядком выполнения задач
Вы должны хорошо знать порядок выполнения задач в сценарии Ansible.
Если вы используете ключевую работу ролей для статического импорта роли; тогда все задачи в этой роли будут выполняться перед всеми другими задачами (включенными в раздел задач) в вашей игре.
Таким образом, Ansible выполняет playbook в следующем порядке:
Для демонстрации взгляните на следующую книгу pre-post.yml, в которой используются pre_tasks, роли, задачи и post_tasks:
В сборнике plays используется созданная мной роль myrole, которая выполняет две простые задачи:
Теперь запустите playbook:
Как вы видите, сначала выполняется pre_tasks, затем две задачи в myrole, затем задачи и, наконец, последними запускаются post_tasks.
Надеюсь, вам понравилось узнавать, как использовать и создавать роли Ansible.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Ansible: роли (roles) – пример
Роли отлично подходят для организации различных, но связанных между собой задач (task), и размещения всех связанных с этими задачами данных в одном месте.
Для примера – выполним установку NGINX, которая будет включать в себя добавление файла репозитория, установку пакетов и установку файла конфигурации виртуалхоста.
В данной статье используются примеры из предыдущей части – Ansible: сценарии (playbook) и обработчики (handler).
Роли имеют свою структуру каталогов, которая выглядит так:
На сервере с Ansible cоздаём необходимые каталоги:
По факту – не обязательно использовать все директории, и не обязательно все их создавать.
Files
Тут мы разместим файл репозитоия NGINX – files/nginx.repo :
Handlers
В старом Playbook у нас было несколько обработчиков – добавим их сюда.
Создаём файл handlers/main.yml и вписываем в него наши обработчики:
В данном случае зависимостей и мета-данных нет, поэтому – либо можно оставить директорию пустой, либо создать файл meta/main.yml с пустым описанием зависимостей:
Если же вы захотите добавить роль-зависимость, например – установку PHP-FPM, это можно сделать так:
Template
Создадим шаблон файла настроек для виртуалхоста.
Например – создадим файл templates/ans2.domain.local.conf :
Тут мы используем три переменные:
Variables
Теперь – зададим переменные для шаблона и задач.
Кроме переменных в шаблоне – мы используем ещё одну – << root >> в описании задачи, добавим и её сюда.
Создаём файл vars/main.yml с таким содержимым:
Tasks
Теперь – соберём всё в одну задачу.
В каталоге Tasks создаём файл tasks/main.yml :
Теперь – нам необходимо указать Ansible где искать описания ролей.
Редактируем файл /etc/ansible/ansible.cfg и находим блок:
Раскомментируем его, и указываем директорию с ролями:
Теперь – создаём обычный Playbook, в котором описываем хосты и роли, которые необходимо к ним применить:
Создадим файл nginx_run_role.yml :
На хосте cent_ans_client1 проверяем:
Файлы скопированы, файл настроек виртуалхоста создан со всеми необходимыми значениями из переменных. Всё работает.
Эффективная разработка и сопровождение Ansible-ролей
Ansible — система, которая решает различные задачи автоматизации, включая конфигурирование, резервное копирование и деплой проектов. Систему приятно использовать для написания сценариев автоматизации от простого окружения до крупного проекта. В сценариях важную роль играют playbooks и роли — структурированные playbooks.
Ansible не волшебная таблетка, и помогает только на первых порах. Когда проект растет, становится сложно поддерживать разросшееся количество ролей. Помогает решить проблему механизм непрерывной поставки для ролей.
Как раз об этом расшифровка доклада Александра Харкевича на DevOps Conf Russia. В докладе: разработка Ansible-ролей через CI, механизм разработки публичных ролей и публичных ролей с тестовыми прогонами в приватной инфраструктуре. А еще в докладе нет вывода.
О спикере: Александр Харкевич (kharkevich) старший системный инженер в компании EPAM Systems.
Начнем с краткого обзора.
Про Ansible
Ansible — система для управления конфигурациями. Написана на Python, шаблонизируется Junja, а в качестве DSL используется YAML. Управляется через Ansible Tower — WebUI для управления и мониторинга работы системы.
Ansible появилась в 2012 году, через 3 года Red Hat купил проект целиком, а еще через два года представила AWX — Project Open Source-версию Ansible Tower.
Установка
Чтобы использовать Ansible, нужно сделать две простые вещи.
На первом этапе составить файл инвентаризации в случае статической инфраструктуры.
На втором — написать Playbook, который приведет систему в ожидаемое состояние.
Часто у нас возникает непреодолимое желание написать автоматизацию, которую можно переиспользовать еще раз. Автоматизация — хорошее желание, и ребята из Ansible придумали классную концепцию — роль.
Это структурированная сущность, которая приведет систему в ожидаемое состояние с возможностью переиспользовать автоматизацию.
Например, мы можем написать роль для Oracle Java: возьмем Playbook, поставим роль и применим ее к целевой системе. На выходе получим установленную Java.
Как мы представляли работу с ролями
Раз в Ansible есть такая прекрасная вещь, как роли, то мы думали, что сейчас возьмем и напишем много-много ролей на все случаи жизни, пошарим, и будем переиспользовать, чтобы сократить количество работы.
Мы думали, что будем писать красивые и умные роли…
Но жизнь оказалась сложнее.
Как оказалось на самом деле
Когда над написанием роли или ее улучшением работает больше, чем один человек, то все пишут в одно место и возникают неприятные сюрпризы: роль ведет себя не так, как изначально задумывалось автором.
Хорошо, когда она применяется до конца, но это не всегда случается. Иногда роль успешно исполняется, но на целевой системе это сказывается совсем не так, как хотелось изначально.
В результате возникают ужасные конструкции, попытки перенести bash в Ansible и подать все это под соусом configuration management. Мы столкнулись с этим явлением и взгрустнули.
Подумав, мы обнаружили, что в нашем configuration management есть некое подобие кода, а значит, практики, которые применимы к управлению кодом в Systems Development Life Cycle, применимы и в Ansible.
Инструменты
С точки зрения систем контроля версий и непрерывной интеграции есть десяток доступных решений, и развесистый зоопарк по тестированию.
С точки зрения release management в Ansible не так уж и много решений: тегировать в Git, либо тегировать в Git и выкладывать в Galaxy.
По инструментам тестирования много подходов, каждый использует то, что нравится. Популярны решения с использованием KitchenCI, InSpec, Serverspec.
У нас душа не лежала брать Ansible написанный на Python, и примешивать к нему инструменты из мира Ruby. Поэтому, выкинув всё неродное миру Python, мы получили следующую картину.
Molecule
Данный инструмент помогает полноценно протестировать ansible-роль. Для этого у него все есть:
Тестовая матрица
Рассмотрим тестовую матрицу по шагам. Всего шагов 11, но буду краток.
№ 1. Lint
Прогоняются YAML lint и Ansible lint, и что-нибудь находят.
В примере выше lint ругается на то, что shell нужно не просто вызывать в Ansible, а фиксировать его, привязывая к чему-то.
№ 2. Destroy
Molecule избавляется от всего, что осталось после предыдущих тестов.
Бывают случаи, когда прошел прогон, развернулся полигон и тестирование завершилось. Стенд должен в конце почиститься, но вмешались непреодолимые силы и чистки не было. Для таких ситуаций Molecule прогоняет destroy и чистит среду от остатков.
№ 3. Dependency
Берем файлик requirements.yml и добавляем зависимости нашей роли от других ролей. Например, отсылку к тому, что роль не взлетит без установленной на системе Java:
Molecule это понимает и исполнит сценарий:
№ 4. Syntax
Следующий шаг — проверка синтаксиса. но не вашей роли, а тестовой Playbook, которую вы добавляете в Molecule. На этом шаге тоже бывают ошибки связанные с синтаксисом.
На слайде видно, что ansible-роль называется ‘kibana’, а в тестовой Playbook — ansible-role-kibana. Система говорит: «Все бы хорошо и здесь можно создавать, но я так делать не буду, потому что имена не совпадают!»
№ 5. Create
На этом этапе указываем драйвер, с помощью которого разворачивается тестовый полигон. Укажете Google — он поднимет в Google Cloud тестовые машинки.
Мы можем в файле molecule.yml прописать, что мы хотим. Посмотрим как это выглядит на примере для Docker.
№ 6. Prepare
Это шаг предварительной подготовки среды выполнения тестов.
Вроде бы все поднялось, но иногда нужно выполнить какие-нибудь дополнительные настройки. В случае тестирования внутри приподнятого Docker в Debian или Ubuntu, требуется поставить второй Python, что часто бывает.
№ 7. Converge
Этап первого большого прогона роли внутрь instance, чтобы убедиться, что она добегает до конца, прогоняется, и Ansible подтверждает, что все хорошо.
№ 8. Idempotence
Проверка на идемпотентность простая и выглядит так.
Этот этап у ребят, с которыми я работаю, вызвал боль. Они пытались пойти обходными путями, чтобы победить проверку на идемпотентность. У Molecule можно управлять этапами, которые она проходит, и первое, что они сделали — отключили проверку на идемпотентность.
Мы ловили отключения и били за это по рукам, но инженеры умные и пошли глубже. Разработчики решили говорить, что этот шаг в Ansible ничего не меняет.
Хотя на самом деле здесь появится какая-то команда. Ansible прямо возьмет и
будет перезаписывать файл, но при этом все выглядит идемпотентно.
Когда эту хитрость тоже отловили, картинка стала выглядеть так.
Хорошо — сценарий пробежал под именем default, и он идемпотентный.
№ 9. Side_effect
На следующем этапе накладываются побочные эффекты. Это делать необязательно, но удобно, когда вы тестируете сложные развесистые роли, зависимые друг от друга.
Например, поднимаете ELK stack, затем Elasticsearch в кластере. На этапе side_effect добавляете тестовых данных и удаляете пару узлов из кластера. Тестовый полигон готов для функциональных тестов, которые происходят на следующем этапе.
№ 10. Verify
Выше пример очень простого теста. Мы проверяем, что у нас пакет Docker Community Edition в случае Ubuntu установлен, у него нужная версия, и сервис запущен.
На этом этапе запуска функциональных тестов можно все сильно усложнить.
Наверно, лучшим примером будет, в случае ELK stack, если на каких-то тестовых данных сделаем запрос в Elasticsearch, и так как тестовые данные нам известны, то он нам ответит. Мы не будем проверять, что все установленные компоненты собраны, а посмотрим, что Elasticsearch поднят, работает и выдает на поиске именно то, что нужно.
Когда бегут функциональные тесты, это выглядит вроде бы красиво, прогоняется по всей инвентаризации вверх-вниз, и система сообщает нам о том, что у нас все хорошо. Опять же, тесты будут бежать, если мы их напишем.
№ 11. Destroy
Мы провели тесты, test report в каком-то виде есть и теперь убираем весь мусор за собой.
Автоматизация
Molecule — отличный инструмент. Теперь осталось самое простое — подключить к нему систему непрерывной интеграции, чтобы наслаждаться автоматическим тестированием наших ролей, что мы и сделали.
Как и везде, есть несколько особенностей.
Некоторые роли, которые мы пишем для автоматизации чего-то, хороши, но мы не можем тестировать систему с помощью Travis, потому что роли разворачивают продукты, которые мы не можем выложить в общий доступ по лицензионным соображениям.
Например, у вас есть автоматизация разворачивания базы Oracle. Если выложите в файл инсталлятор базы, то к вам придут юристы компании и будут сильно ругаться. Чтобы все жили в мире и не ругались, мы решили сделать следующее.
Давайте посмотрим по шагам, как это выглядит в Travis.
Travis
Публичный CI
Публичный CI выглядит элементарно.
От GitHub стрелочка к Travis, внутри которого живёт Molecule и Docker.
Приватный CI
Для приватной части GitLab все то же самое.
В приватном периметре у нас запущен runner, и картинка выглядит веселее.
Код попадает из GitHub в GitLab, где-то бежит приватный runner, который умеет дергать внешние сервисы, например, запускать что-то в Amazon.
Маленькое отступление. Запуск и разворачивание тестовой среды в Amazon не хочется переносить, потому что нужны ключи. Придумывать механизмы, чтобы положить их в паблик, но при этом не стать очередной стартап-платформой для майнинга — это нетривиальная задача. Поэтому мы ее не решали, а унесли runner в приват, чтобы не майнить биткойны Amazon.
Даже здесь, мы чуть-чуть поленились и сделали следующее. У нас в EPAM есть свое приватное облако и оно гибридное. Это значит, что многие публичные облака доступны из внутреннего облака, как регионы. Можно не писать тысячу тестов, а поиграться с регионами и сказать: «Теперь проведи тест вот по этому тестовому сценарию для региона AWS, EPAM Cloud, Azure».
Ansible Galaxy
Подошли к финалу, наша роль зеленая, красивая, опубликуем ее в Galaxy.
Это простая операция:
Если вы что-то публикуете в Galaxy, не забывайте это тегировать, прямо чтобы были версии, и все было клево.
Шаблоны
Делюсь маленькой хитростью: чтобы каждый раз не копипастить при написании новой роли, мы решили создать шаблоны и отдельный репозиторий, в который положили шаблон, чтобы быстро с нуля писать роли.
У шаблона есть настройки по умолчанию для Ansible lint и GitHub issue_template. Всё в свободном доступе, поэтому issue_template в красивой форме, чтобы pull request или bug reports нам оформляли тоже красиво. В тот же репозиторий складываем шаблоны для Gitignore, Gitlab-ci и лицензию.
По умолчанию мы публикуемся под лицензией Apache 2.0. Если захотите сходить к нам и переиспользовать шаблоны, то можете всё забрать, создать закрытый репозиторий и никому ничего не объяснять. Спасибо Apache.
У нас лежит несколько вариантов тестов, чтобы можно было быстренько все пнуть и завести.
Заключения не будет, вместо него есть ссылки на мой GitHub, мой профайл в Galaxy, на GitHub Lean Delivery и Ansible Galaxy. По ссылкам можно посмотреть, как все работает. Все примеры в свободном доступе.
Пока мы в ожидании события, подпишитесь на YouTube-канал и рассылку. Канал будет пополняться записями лучших докладов, а в рассылке будут подборки полезных материалов, расшифровки и DevOps-новости.
Подписывайтесь, будет интересно:)