Что такое Ansible и как его использовать
Авторизуйтесь
Что такое Ansible и как его использовать
Что такое Ansible? Это ПО с открытым исходным кодом, которое автоматизирует поставку программного обеспечения, управление конфигурацией и развёртывание приложений. Ansible помогает DevOps-специалистам автоматизировать сложные задачи.
Примечание Вы читаете улучшенную версию некогда выпущенной нами статьи.
Ключевые особенности программы Ansible
Установка и запуск
Инструкцию по установке на другие ОС можно найти здесь.
Структура Ansible
Модули
Это небольшие программы, выполняющие определённую работу на сервере. Например, вместо запуска этой команды:
Мы можем использовать модуль apt и установить htop:
Использование модуля даст вам возможность узнать, установлен он или нет.
Плагины
Ansible поставляется с несколькими удобными плагинами, и вы можете легко написать свой собственный.
Инвентаризация хостов
Чтобы предоставить перечень хостов, нам нужно обозначить список, находящийся в файле инвентаризации. Он напоминает содержание файла hosts.
В простейшем виде он может содержать одну строку:
Playbooks
Ansible playbooks — это способ отправки команд на удалённые компьютеры с помощью скриптов. Вместо того, чтобы индивидуально использовать команды для удалённой настройки компьютеров из командной строки, вы можете настраивать целые сложные среды, передавая скрипт одной или нескольким системам.
group_vars
Файл содержит набор переменных, например имя пользователя и пароль базы данных.
Это способ сгруппировать несколько задач в один контейнер, чтобы эффективно автоматизировать работу с помощью понятной структуры каталогов.
Обработчики
Представляют собой списки задач, которые на самом деле не отличаются от обычных задач, на которые ссылается глобально уникальное имя и которые оповещаются уведомителями. Если ничто не уведомляет обработчик, он не будет запускаться. Независимо от того, сколько задач уведомляет обработчик, он запускается только один раз, после того как все задачи завершены.
Если у вас playbook с большим объёмом, может быть полезно иметь возможность запускать только определённую часть его конфигурации.
Демо «Реальное приложение»
Цель этой демонстрации — установить приложение Laravel в VPS. Для этого используем Lightsail.
Последовательность действий для создания и запуска Laravel APP:
Рассмотрим каждый пункт подробнее.
Создание экземпляра Ubuntu Lightsail
Перейдите на панель управления Lightsail и нажмите «Создать экземпляр».
Выберите свою любимую ОС.
Выберите «Добавить скрипт запуска», который запускается после создания вашего экземпляра. Не забудьте получить SSH-ключ.
Установка зависимостей Ansible на нашем VPS
Добавьте эти sh-команды для установки зависимостей:
Теперь у нас есть готовый экземпляр, перейдём к построению Ansible Project.
Добавление SSH-ключей в Git
Вы должны добавить свой сервер id_rsa.pub к своим ключам GitHub SSH, войдя в свой сервер.
Сборка хостов и ansible.cfg
Определение роли в Ansible
Используем модуль Ping, чтобы убедиться, что хост работает, после чего нужно обновить все пакеты и установить два модуля: git и htop.
Определение обработчика
Установка модулей PHP
Чтобы вызвать обработчик, мы должны использовать notify: Restart PHP-FPM, имена обработчиков должны быть уникальными.
В этом руководстве мы определили php как тег, поэтому, например, если вы хотите запустить только эту задачу из своего playbook, вам необходимо выполнить её с —tags = ”php”, которая будет исполнять только её.
Установка Nginx
Добавление default-конфигурации Nginx
vars.yml
Примечание: Рекомендуется использовать ansible-vault для шифрования и дешифрования переменных.
Как использовать Ansible-Vault
Создайте секретный файл хранилища, содержащий ключ шифрования, который шифрует ваши переменные.
Чтобы зашифровать переменные, используйте:
Чтобы расшифровать переменные, используйте:
Создание базы данных MySql, имени пользователя и пароля
mysql_user и mysql_pass определены внутри vars.yml.
Клонирование кодовой базы
repo_git_url и app_work_dir определены внутри vars.yml.
Генерирование .env
Ansible использует шаблонизатор Jinja2 для динамических выражений и доступа к переменным. Создадим файл env.conf.
Создание playbook
Как видно, мы определили aws как хост для этого playbook, и sudo yes даёт нам возможность выполнять команду как пользователю sudo. У нас есть vars_files, где мы храним наши vars. Мы установили roles, каждая role выполняет определённую задачу. И, наконец, у нас есть handlers, которые содержат все обработчики проекта.
Ansible с чего начать
В последние пару лет я все чаще использую Ansible для решения практически любых задач связанных с автоматизацией, будь то конфигурирование, резервное копирование или деплой проектов. Не смотря на то, что система очень хорошо документирована, я думаю смогу добавить немного полезной информации для тех кто еще только начинает пользоваться Ansible. Для начала я хотел бы рассказать об основных вещах, таких как структура проекта в котором будут содержаться плейбуки, роли, переменные, шаблоны и файлы необходимые для автоматизации развертывания серверов, кода и всего другого, что можно сделать с помощью Ansible.
Итак, Ansible это очень гибкий и легкий инструмент для написания сценариев автоматизации любой сложности. Вы можете описать в нем как простое окружение разработчика так сложную структуру крупного проекта с несколькими окружениями (dev/stage/prod).
Как мне видится с Ansible можно решать следующие задачи:
Пара замечаний для тех кто еще не знаком с Ansible:
— Прежде чем приступить к написанию плейбуков/ролей вам нужно почитать документацию Ansible-playbook, Ansible-role и научиться понимать YAML-syntax (это очень просто);
— Также стоит сразу сказать, что лучше вести разработку в git-репозитории, поэтому не поленитесь обзавестись аккаунтом на github или заведите локальный git-repo (mercurial, svn, etc). Если вы еще не научились пользоваться git, то сейчас самое время.
На мой взгляд, Ansible гораздо проще и легче для «усвоения» чем puppet и chef (мне доводилось использовать и то и другое) хоть это и немного разные продукты. После того как вы ознакомились с введением и заглянули в Module Index, вы уже можете начинать писать плейбуки которые заметно облегчат вам жизнь.
Пример плейбука для распространения вашего ssh pub-key на серверы:
Это все понятно, но что дальше?
Расширенная структура проекта
Если хотите описывать структуру более или менее сложного проекта с n-tier архитектурой, стоит сразу определиться со списком групп хостов по ролям и на основании этого прикинуть какие задачи должны быть общими для всех хостов (например подключение репозиториев, создание пользователей и т.д.), а какие частные (конфигурирование nginx, mysql, создние python venv и т.д.) и исходя из этого начинать писать роли начиная с базовой общей роли постепенно переходя к частным.
Если вы хотите иметь несколько окружений то придется завести несколько файлов inventory, по умолчанию (в deb-пакете) в конфиге ansible.cfg используется файл hosts (/etc/ansible/hosts). Путь к inventory не обязательно прописывать в конфиге можно задавать разные файлы с ключом -i.
Чтобы логика описанная в ваших ролях или плейбуках работала одинаково на разных окружениях заводите группы с одинаковыми именами для всех окружений, например:
Production inventory
Develop inventory
Как видно из примера, группы могут включать в себя другие группы, а также можно объявлять общие переменные прямо в inventory.
Структура директорий может выглядеть следующим образом:
Каждая группа и каждый хост могут иметь набор переменных в разных файлах (например common, secret).Названия файлов в директориях здесь не приципиальны, главное чтобы имя директории совпадало с именами (группы или хоста) в соответствующем inventory. Заводить директорию для группы или единичного хоста не обязательно, можно просто создать файл и записать в нем все необходимые переменные. Но если вы хотите хранить пароли в шифрованном виде (не хеши, а именно пароли), отдельно от общих переменных, то стоит завести описанную выше структуру, об этом я расскажу ниже.
Шифрование переменных с Ansible-vault
Ansible-vault утилита для шифрования(default AES256) файлов групповых или хостовых переменных и в принципе любых файлов в которых вы хотите хранить секретные переменные (пароли, ключи и т.д.). Таким образом, вы сможете хранить в репозитории (даже в публичном, хотя это всё же не желательно) любые данные и не переживать за их безопасность.
Пользовательские пароли имеет смысл хранить в групповых файлах (group_vars) по имени группы или как all если у вас на всех окружениях одни и те же юзеры.
В описанной выше структуре я указывал файлы secret в которых и предполагается хранить шифрованные переменные.
Отредактировать зашифрованный файл:
Показать зашифрованный файл:
Конечно, чтобы шифровать и расшифровывать файлы нужен будет достаточно длинный ключ и хранить его нужно в надежном месте (например KeePass). Чтобы автоматически расшифровывать файлы во время запуска (runtime) плейбуков нужно будет указывать ключ —vault-password-file либо задавать путь к файлу через конфиг ansible.cfg, в этом случае также нужно будет позаботиться о сохранности ключа и выставить ему нужные права (0400). Ну и конечно не стоит его хранить в репозитории вместе с зашифрованными файлами.
Плейбуки
Все действия (tasks) которые вы хотите выполнить можно записывать в плейбуки (если их скажем не больше десятка и вы не используете файлы и шаблоны) в остальных случаях стоит использовать роли.
Роли
Роль представляет собой структурированный плейбук содержащий набор (как и минимум) тасков (task), и дополнительно — обрабработчиков событий (handler), переменных (defaults), файлов (files), шаблонов (templates), а также описание и зависимости (meta).
Структура роли Deploy
Файл с переменными по умолчанию:
Здесь очень удобно задавать какие-то общие вещи, например по умолчанию хост для БД localhost, а group_vars/host_vars вы можете задавать нужные хосты для соответствующих окружений.
Файл с обработчиками событий
В обработчиках можно указывать абсолютно любые действия которые необходимо выполнять после тех или иных тасков, будь то выкладка нового кода или изменение конфига.
Файл с описанием тасков
Можно задавать жесткие условия для выполнения некоторых тасков. В примере выше я задал условие:
что означает, что таск будет выполняться только для хостов которые состоят в группе app_python-servers.
Шаблоны
В качестве шаблонизатора Ansible использует jinja2 со всеми его прелестями. Пример простого конфига uwsgi в виде ini файла с переменными:
Можно использовать любые приемы jinja2 в сочетании с переменными Ansible. Например:
— Задавать строки только хост состоит в той или иной группе (либо задать строки только для определенного хоста) и при этом использовать loop:
Зависимости
Под зависимостями здесь подразумеваются другие роли которые необходимо выполнить перед тем как выполнять вашу конечную роль, в формате — < role: role_name, var_name: value >, например:
Указав все необходимые зависимости для конечной роли (например app-servers) вы можете создать всего один плейбук в котором достаточно будет указать целевую группу хостов и роль. И этого будет достаточно чтобы поддерживать систему в консистентном состоянии, запуская например плейбук по крону. Если нужно обновить какие-то определенные конфиги по месту, то вам придут на помощь теги.
Если вы хотите делать периодические билды и контролировать их выполнение или просто дать «кнопку» разработчикам, могу порекомендовать плагин Ansible для Jenkins подключив который вы сможете задавать в тасках Jenkins пути до playbook, inventory, а также tags и extra-vars.
Что дальше?
Описаная в статье структура не претендует на звание эталонной или универсальной, но наверняка подойдет для большинства случаев. Вы можете использовать её как отправную точку. В процессе написания собственных ролей вы найдете лучший и более удобный для вас способ описания инфраструктуры которую вы строите. Главное не пытайтесь все усложнять, чем проще вы пишите и чем понятнее ваши плейбуки для других тем лучше.
Держите открытой вкладку с официальной документацией по Ansible, она постоянно дополняется по мере развития проекта. Я до сих пор нахожу в ней новые и интересные для себя вещи.
В этой статье я рассказал не все что хотел, есть мысли и идеи еще на одну-две заметки. Если вас интересуют определенные вопросы пишите их комментариях или мне на почту, я постараюсь ответить и возможно учесть ваши пожелания при написании следующей статьи.
UPD:
Полезный пример разделения окружений (production/staging) здесь. Спасибо shuron за ссылку.
Ansible
Ansible — yet another система управления конфигурациями. Отличительная особенность — простота, при большой гибкости. И это не просто слова — дальше я покажу на примерах несколько простейших операций и познакомлю вас с некоторыми “бест практис”.
Итак, у нас есть группы хостов:
| WebServersG1 | webserver1-g1, webserver2-g1 |
| WebServersG2 | webserver1-g2, webserver2-g2 |
| WebServersProxy | webserver-proxy1, webserver-proxy2 |
| DataBase | db1, db2 |
| DataBaseSlave | dbs1, dbs2 |
| SomeServers | someserver1, someserver2 |
Мы хотим подготовить все хосты к адекватной работе — установить необходимый набор софта (htop, zsh, vim, iftop, sudo, mc, tmux, wget), скопировать свои ключи и конфиги и поставить и сконфигурировать софт специфичный для этого сервера.
Ansible подразумевает минимум два файла для начала работы — инвентарный файл, в который мы пишем список хостов и делим их по группам — inventory и файл задач — playbook.
Они нужны для того, чтобы когда мы все сделаем запустить все красиво:
Давайте создадим инвентарный файл по имени “infrastructure” на основе наших хостов:
Собственно все не плохо, но наши хосты из групп WebServersG1 и WebServersG2 отличаются только структурой каталогов, количеством подключений и репозиторием. А WebServersProxy отличается от них только конфигом nginx и отсутствием какого-то софта. К тому же может понадобиться сделать какую-то задачу сразу на всех трех группах. Так что давайте сродним эти три группы и дадим им родителя:
По структуре инвентарного файла: ansible считает группой все, чья строка в описании начинается с ‘[‘ и заканчивается ‘]’. Все что под этой строчкой и до начала следующей группы — хосты. У группы могут быть дети — другие группы, которые перечисляются после [название группы:children] и существуют.
Еще я коротко коснусь переменных, которые тоже можно описывать сразу в этом списке.
Тут мы назначили ssh порт и ssh хост. По практике скажу что другие переменные в inventory файле его захламляют и делают нечитаемым. Да и нестандартные порты лучше перечислять в таком виде:
И раз уж зашла речь о портах — порт по умолчанию для всех хостов (как и многое другое) можно назначить и в ansible.cfg, но не суть.
Итак, мы только что создали список хостов. Давайте теперь создадим список задач, а я окунусь в воспоминания.
В далекие времена (примерно май-июль этого года), до выхода версии 1.2 ролей не было в принципе, мы довольствовались обычными тасками и плейбук выглядел как елка пестревшая инклудами. Потом появились роли, а совсем недавно, неделю-две назад, в версии 1.3 — наследование ролей. И мы, как истинные джедаи, будем пользоваться тем что имеем сейчас. И давайте разберемся, наконец, что такое эти плейбуки и роли, а то непонятно.
Плейбуки — исполняемый набор чего-угодно. Они, в отличии от chef, запускаются один раз и только по вашей команде. Хотя нет ничего, что бы помешило поставить задачу в крон. Раньше под плейбуком подразумевался основной список задач, но сейчас они превратились в набор указателей на нужные нам роли.
Роли, в свою очередь, это набор задач, шаблонов, тригеров-обработчиков, переменных, файлов и ссылок на другие роли распиханых по каталогам в стандартной для ansible структуре. Роли лучше всего группировать по логическим группам. Я, например, в рамках поставленной выше задачи, выделю такие роли:
1) преподготовка — установка разных админских софтов, создание пользователей с ключами, генерация локалей, копирование конфигов и т.п.
2) установка софта для нужного в итоге сервиса и копирование его конфигов
3) создание необходимой структуры директорий, копирование гита и т.п.
Итак, начнем создание плейбука main.yml c пока единственной ролью preconf
Модулей очень много, они есть на любой вкус и цвет. При помощи модулей мы можем развернуть машину в облаке, выполнить команду шела, управлять базами данных, создавать файлы и папки, копировать шаблоны, отправлять сообщения в очереди, управлять сетевой инфраструктурой, писать сообщения в чаты, ставить программы, управлять системой и много чего еще. Останавливаться на каждом из них — тема для отдельной статьи, ровно, как и написание своих — это не слишком сложно.
А пока попробуем что-то установить.
В данном случае мы использовали модуль apt для установки на наши Debian сервера программы zsh.
Конечно, можно заспамить таск-лист отдельной задачей под установку каждой программы, но такие файлы очень плохо читаются. Поэтому мы воспользуемся очередью, котораю можно вызвать через ‘with_items’:
В синтаксисе YAML, если я ничего не путаю, подобная запись обозначает массив. И элементы этого масива, словно бы пройдя через xargs по очереди присваиваются переменной item, которую мы вызвали выше и уже с новым значением выполняются в задаче. Раз за разом, пока не закончится список.
Теперь мы создадим всех пользователей отдела сопровождения и к случаю воспользуемся переменными.
Добавление пользователей выглядит как-то так:
Так наш пользователь добавится на ура. Но мы же хотим чтобы пользователь пупкин пользовался zsh и являлся членом группы sudo? А давайте так и сделаем, ведь модуль ‘user’ поддерживает кучу всего.
Мы уже выучили with_items, поэтому мы им воспользуемся для добавения нескольких пользователей… Но… это ведь надо две переменных передавать в потоке…
Ничего сложного. Ansible поддерживает хеши — массивы в виде ‘ключ: значение’. Удобнее всего записывать хеши в jinja2 формате.
Основы Ansible, без которых ваши плейбуки — комок слипшихся макарон
Я делаю много ревью для чужого кода на Ансибл и много пишу сам. В ходе анализа ошибок (как чужих, так и своих), а так же некоторого количества собеседований, я понял основную ошибку, которую допускают пользователи Ансибла — они лезут в сложное, не освоив базового.
Для исправления этой вселенской несправедливости я решил написать введение в Ансибл для тех, кто его уже знает. Предупреждаю, это не пересказ манов, это лонгрид в котором много букв и нет картинок.
Ожидаемый уровень читателя — уже написано несколько тысяч строк ямла, уже что-то в продакшене, но «как-то всё криво».
Названия
Главная ошибка пользователя Ansible — это не знать как что называется. Если вы не знаете названий, вы не можете понимать то, что написано в документации. Живой пример: на собеседовании, человек, вроде бы заявлявший, что он много писал на Ансибле, не смог ответить на вопрос «из каких элементов состоит playbook’а?». А когда я подсказал, что «ожидался ответ, что playbook состоит из play», то последовал убийственный комментарий «мы этого не используем». Люди пишут на Ансибле за деньги и не используют play. На самом деле используют, но не знают, что это такое.
Так что начнём с простого: как что называется. Может быть вы это знаете, а может и нет, потому что не обратили внимания, когда читали документацию.
ansible-playbook исполняет playbook. Playbook — это файл с расширением yml/yaml, внутри которого что-то такое:
Мы уже поняли, что весь этот файл — плейбука. Мы можем показать где тут роли (roles), где таски (tasks). Но где тут play? И чем отличается play от role или playbook?
В документации это всё есть. И это пропускают. Начинающие — потому что там слишком много и всё сразу не запомнишь. Опытные — потому что «тривиальные вещи». Если вы опытный — перечитывайте эти страницы хотя бы раз в полгода, и ваш код станет классом лучше.
и вот это тоже ещё одна play:
Что же такое play? Зачем она?
Если вы хотите «что-то» исполнить «где-то» — вы пишете play. Не роль. Не роль с модулями и делегейтами. Вы берёте и пишете play. В которой, в поле hosts вы перечисляете где исполнять, а в roles/tasks — что исполнять.
Просто же, да? А как может быть иначе?
Одним из характерных моментов, когда у людей возникает желание сделать это не через play, это «роль, которая всё настраивает». Хочется иметь роль, которая настраивает и сервера первого типа, и сервера второго типа.
Архетипичным примером является мониторинг. Хочется иметь роль monitoring, которая настроит мониторинг. Роль monitoring назначается на хосты мониторинга (в соотв. play). Но, выясняется, что для мониторинга нам надо поставить пакеты на хосты, которые мы мониторим. Почему бы не использовать delegate? А ещё надо настроить iptables. delegate? А ещё надо написать/поправить конфиг для СУБД, чтобы мониторинг пускала. delegate! А если креатив попёр, то можно сделать делегацию include_role во вложенном цикле по хитрому фильтру на список групп, а внутри include_role можно ещё делать delegate_to снова. И понеслось.
Благое пожелание — иметь одну-единственную роль monitoring, которая «всё делает» — ведёт нас кромешный ад из которого чаще всего один выход: всё переписать с нуля.
Где тут случилась ошибка? В тот момент, когда вы обнаружили, что для выполнения задачи «x» на хосте X вам надо пойти на хост Y и сделать там «y», вы должны были выполнить простое упражнение: пойти и написать play, которая на хосте Y делает y. Не дописывать что-то в «x», а написать с нуля. Пусть даже с захардкоженными переменными.
Вроде бы, в абзацах выше всё сказано правильно. Но это же не ваш случай! Потому что вы хотите написать переиспользуемый код, который DRY и похож на библиотеку, и нужно искать метод как это сделать.
Вот тут вот притаилась ещё одна грубая ошибка. Ошибка, которая превратила множество проектов из терпимо написанных (можно лучше, но всё работает и легко дописать) в совершенный ужас, в котором даже автор не может разобраться. Оно работает, но упаси боже что-то поменять.
Эта ошибка звучит так: роль — это библиотечная функция. Эта аналогия сгубила столько хороших начинаний, что просто грустно смотреть. Роль — не библиотечная функция. Она не может делать вычисления и она не может принимать решения уровня play. Напомните мне, какие решения принимает play?
Спасибо, вы правы. Play принимает решение (точнее, содержит в себе информацию) о том, какие таски и роли на каких хостах выполнять.
Если вы делегируете это решение на роль, да ещё и с вычислениями, вы обрекаете себя (и того, кто ваш код будет пытаться разобрать) на жалкое существование. Роль не решает где ей выполняться. Это решение принимает play. Роль делает то, что ей сказали, там, где ей сказали.
Почему заниматься программированием на Ансибле опасно и чем COBOL лучше Ансибла мы поговорим в главе про переменные и jinja. Пока что скажем одно — каждое ваше вычисление оставляет за собой нестираемый след из изменения глобальных переменных, и вы ничего с этим не можете сделать. Как только два «следа» пересеклись — всё пропало.
play и только play решает на каких хостах что исполняется.
В этом разделе мы разобрались с противостоянием play и role. Теперь поговорим про отношения tasks vs role.
Таски и Роли
… И куда делись tasks?
Мы снова начинаем с азов — устройство play. Если вы плаваете в этом вопросе, вы не можете использовать play как основу для всего остального, и ваш результат получается «шатким».
Устройство play: директива hosts, настройки самой play и секции pre_tasks, tasks, roles, post_tasks. Остальные параметры для play нам сейчас не важны.
Но мы всё ещё не ответили на вопрос: а куда вызов модуля foo писать? Надо ли нам под каждый модуль писать целую роль? Или лучше иметь толстую роль подо всё? А если не роль, то куда писать — в pre или в post?
Разумеется, формулировка вопроса намекает, что сломается. Но что именно?
И, возвращаемся, к нашему ‘foo’. Куда его поместить? В pre, post или в roles? Очевидно, это зависит от того, нужны ли нам результаты работы хэндлера для foo. Если их нет, то foo не нужно класть ни в pre, ни в post — эти секции имеют специальный смысл — выполнение тасок до и после основного массива кода.
Теперь ответ на вопрос «роль или таска» сводится к тому, что уже есть в play — если там есть tasks, то надо дописать в tasks. Если есть roles — надо делать роль (пусть и из одной task). Напоминаю, tasks и roles одновременно не используются.
Понимание основ Ансибла даёт обоснованные ответы на, казалось бы, вопросы вкусовщины.
Таски и роли (часть вторая)
Теперь обсудим ситуацию, когда вы только начинаете писать плейбуку. Вам надо сделать foo, bar и baz. Это три таски, одна роль или три роли? Обобщая вопрос: в какой момент надо начинать писать роли? В чём смысл писать роли, когда можно писать таски?… А что такое роль?
Одна из грубейших ошибок (я про это уже говорил) — считать, что роль — это как функция в библиотеке у программы. Как выглядит обобщённое описание функции? Она принимает аргументы на вход, взаимодействует с side causes, делает side effects, возвращает значение.
Теперь, внимание. Что из этого можно сделать в роли? Вызвать side effects — всегда пожалуйста, это и есть суть всего Ансибла — делать сайд-эффекты. Иметь side causes? Элементарно. А вот с «передать значение и вернуть его» — вот тут-то и нет. Во-первых, вы не можете передать значение в роль. Вы можете выставить глобальную переменную со сроком жизни размером в play в секции vars для роли. Вы можете выставить глобальную переменную со сроком жизни в play внутри роли. Или даже со сроком жизни плейбуки ( set_fact / register ). Но вы не можете иметь «локальные переменные». Вы не можете «принимать значение» и «возвращать его».
Итого: роль — это не функция.
Что же хорошего есть в роли? Во-первых, у роли есть default values ( /default/main.yaml ), во-вторых у роли есть дополнительные каталоги для складывания файлов.
Ещё одна деталь: можно пытаться делать роли, которые будут доступны для переиспользования (через galaxy). После появления коллекций распространение ролей можно считать почти забытым.
Таким образом, роли обладают двумя важными особенностями: у них есть дефолты (уникальная особенность) и они позволяют структурировать код.
Возвращаясь к исходному вопросу: когда делать таски а когда роли? Таски в плейбуке чаще всего используются либо как «клей» до/после ролей, либо как самостоятельный строительный элемент (тогда в коде не должно быть ролей). Груда нормальных тасок в перемешку с ролями — это однозначная неряшливость. Следует придерживаться конкретного стиля — либо таски, либо роли. Роли дают разделение сущностей и дефолты, таски позволяют прочитать код быстрее. Обычно в роли выносят более «стационарный» (важный и сложный) код, а в стиле тасок пишут вспомогательные скрипты.
Существует возможность делать import_role как таску, но если вы такое пишете, то будьте готовы к объяснительной для собственного чувства прекрасного, зачем вы это хотите делать.
Въедливый читатель может сказать, что роли могут импортировать роли, у ролей может быть зависимость через galaxy.yml, а ещё есть страшный и ужасный include_role — напоминаю, мы повышаем навыки в базовом Ансибле, а не в фигурной гимнастике.
Хэндлеры и таски
Давайте обсудим ещё одну очевидную вещь: хэндлеры. Умение их правильно использовать — это почти искусство. В чём разница между хэндлером и таской?
Так как мы вспоминаем основы, то вот пример:
У роли handler’ы лежат в rolename/handlers/main.yaml. Handler’ы шарятся между всеми участниками play: pre/post_tasks могут дёргать handler’ы роли, а роль может дёргать handler’ы из плей. Однако, «кросс-ролевые» вызовы handler’ов вызывают куда больший wtf, чем повтор тривиального handler’а. (Ещё один элемент best practices — стараться не делать повторов имён handler’ов).
Основное различие в том, что таска выполняется (идемпотентно) всегда (плюс/минус теги и when ), а хэндлер — по изменению состояния (notify срабатывает только если был changed). Чем это чревато? Например, тем, что при повторном запуске, если не было changed, то не будет и handler. А почему может быть так, что нам нужно выполнить handler когда не было changed у порождающей таски? Например, потому что что-то сломалось и changed был, а до хэндлера выполнение не дошло. Например, потому что сеть временно лежала. Конфиг поменялся, сервис не перезапущен. При следующем запуске конфиг уже не меняется, и сервис остаётся со старой версией конфига.
Ещё одно положительное свойство handler’а состоит в том, что он не засоряет вывод. Не было изменений — нет лишних skipped или ok в выводе — легче читать. Оно же является и отрицательным свойством — если опечатку в линейно исполняемой task’е вы найдёте на первый же прогон, то handler’ы будут выполнены только при changed, т.е. при некоторых условиях — очень редко. Например, первый раз в жизни спустя пять лет. И, разумеется, там будет опечатка в имени и всё сломается. А второй раз их не запустить — changed-то нет.
Отдельно надо говорить про доступность переменных. Например, если вы notify для таски с циклом, то что будет в переменных? Можно аналитическим путём догадаться, но не всегда это тривиально, особенно, если переменные приходят из разных мест.
… Так что handler’ы куда менее полезны и куда более проблемны, чем кажется. Если можно что-то красиво (без выкрутас) написать без хэндлеров лучше делать без них. Если красиво не получается — лучше с ними.
Чем меньше if’ов (явных или декларативных — в форме when или форме include_vars по набору переменных), тем лучше роль. Иногда приходится делать ветвления, но, повторю, чем их меньше, тем лучше. Так что вроде бы хорошая роль с galaxy (работает же!) с кучей when может быть менее предпочтительна, чем «своя» роль из пяти тасок. Момент, когда роль с galaxy лучше — когда вы что-то начинаете писать. Момент, когда она становится хуже — когда что-то ломается, и у вас есть подозрение, что это из-за «роли с galaxy». Вы её открываете, а там пять инклюдов, восемь таск-листов и стопка when ‘ов… И в этом надо разобраться. Вместо 5 тасок линейным списком, в котором и ломаться-то нечему.