Для чего используется инструмент ansible
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 и как его использовать
Что такое 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
Представьте себе, что вам нужно управлять парком серверов, расположенных к тому же в разных географических точках. Каждый из этих серверов требует настройки, регулярного обновления и мониторинга. Конечно, для решения этих задач можно воспользоваться самым простым способом: подключиться к каждому серверу по ssh и внести необходимые изменения. При всей своей простоте этот способ сопряжен с некоторыми трудностями: он чрезвычайно трудоемок, а на выполнение однообразных операций уходит очень много времени.
Чтобы упростить процессы настройки и конфигурирования серверов, можно также писать shell-скрипты. Но и этот способ вряд ли можно назвать совершенным. Скрипты нужно постоянно изменять, подстраивая их под каждую новую задачу. При их написании необходимо учитывать различие операционных систем и версий. Не будем забывать и о том, что отладка скриптов отнимает много усилий и забирает немало времени.
Оптимальным вариантом решения описанных проблем является внедрение системы удаленного управления конфигурацией. В таких системах достаточно лишь описать нужное состояние управляемого узла. Система должна сама определить, что нужно сделать для достижения этого состояния, и осуществит все необходимые действия.
Со всеми сложностями, о которых идет речь выше, мы хорошо знакомы на собственном опыте: у нас имеется 10 точек присутствия с NS-серверами, расположенные в разных точках планеты. На них необходимо регулярно вносить различные изменения: обновлять операционную систему, устанавливать и обновлять различное ПО, изменять конфигурцию и т.п. Мы решили все эти операции автоматизировать и внедрить систему удаленного управления конфигурациями. Изучив имеющиеся решения, мы остановили свой выбор на Ansible.
В этой статье мы бы хотели подробно рассказать о его возможностях этого инструмента управления конфигурациями и поделиться собственным опытом его использования.
Что такое Ansible?
Ansible — опенсорсное программное решение для удаленного управления конфигурациями, разработанное Майклом Де Хаанном в 2012 году. Название продукта взято из научно-фантастической литературы: в романах американской писательницы Урсулы Ле Гуин ансиблом называется устройство для оперативной космической связи.
Ansible берет на себя всю работу по приведению удаленных серверов в необходимое состояние. Администратору необходимо лишь описать, как достичь этого состояния с помощью так называемых сценариев (playbooks; это аналог рецептов в Chef). Такая технология позволяет очень быстро осуществлять переконфигурирование системы: достаточно всего лишь добавить несколько новых строк в сценарий.
Почему Ansible?
Преимущества Ansible по сравнению с другими аналогичными решениями (здесь в первую очередь следует назвать такие продукты, как Puppet, Chef и Salt) заключаются в следующем:
Установка
Требования для установки Ansible минимальны. На машине с которой производится управление должен быть установлен Python 2.6 или выше. На управляемых узлах должен быть установлен только Python версии не ниже 2.4, но он, как правило, по умолчанию включен в состав большинства дистрибутивов linux-систем. MS Windows не поддерживается.
Вам также могут потребоваться следующие модули Python, устанавливаемые через pip или пакетный менеджер вашей операционной системы:
В Ubuntu установка самого Ansible и зависимостей осуществляется добавлением репозитория и установкой пакета:
О процедуре установки в других ОС можно прочитать в официальной документации.
Группы серверов
Файл hosts
Помимо списка управляемых узлов, в файле hosts могут быть указаны и другие сведения, необходимые для работы: номера портов для подключения по SSH, способ подключения, пароль для подключения по SSH, имя пользователя, объединения групп и т.п. В некоторых случаях — в частности, при работе с большими и сложными конфигурациями, — различные параметры можно выносить в отдельные файлы и каталоги (о структуре каталогов см. ниже).
Более подробно о файле hosts и правилах его написания можно почитать в официальной документации.
Информация об узлах (Facts)
Перед внесением изменений Ansible подключается к управляемым узлам и собирает информацию о них: о сетевых интерфейсах и их состоянии, об установленной операционной системе и т.п. Он может делать это как с помощью собственного модуля, так и с помощью инструментов ohai и facter, если они установлены (такая возможность специально предусмотрена для пользователей, уже имеющих опыт работы с системами удаленного управления конфигурациями: ohai и facter являются библиотеками фактов для Chef и Puppet).
Переменные
Во время деплоя, как правило, требуется не только установить какое-либо приложение, но и настроить его в соответствии с определенными параметрами на основании принадлежности к группе серверов или индивидуально (например, ip-адрес BGP-соседа и номер его AS или параметры для базы данных). Как уже было сказано, загромождать файл hosts будет не очень красиво, поэтому разработчики Ansible пошли следующим путём:
Модули Ansible
В состав Ansible входит огромное количество модулей для развёртывания, контроля и управления различными компонентами, которые можно условно разделить на следующие группы (в скобках приведены названия некоторых продуктов и сервисов):
Примеры простых задач
С помощью Ansible можно одновременно выполнить одну задачу на целой группе серверов. Попробуем, например, отправить запрос ping на серверы выбранной группы:
Следующий пример соберёт информацию о хостах и выведёт её на консоль в формате JSON:
А вот так можно создать логический том (или, в зависимости от текущего состояния, изменить его размер) с именем examplevolume в группе examplegroup:
Ansible позволяет не только выполнять единичные задачи, но и писать сценарии, которые необходимо выполнить на управляемых узлах. Рассмотрим структуру и правила написания таких сценариев более подробно.
Cценарии (playbooks)
Все сценарии в Ansible пишутся на YAML. Это — человекочитаемый формат сериализованных данных, гораздо более простой, чем XML или JSON.
Чтобы выполнить сценарий используется команда ansible-playbook со следующим сиснтаксисом:
В начале сценария обязательно должна присутствовать последовательность символов «» (так в YAML обозначается начало документа). Перед каждым новым разделом списка ставится дефис ( — ):
Основными параметрами/группами простого сценария являются:
В разделе hosts указывается группа управляемых узлов, к которой будут применены описываемые в сценарии изменения.
Так, строка формата:
означает, что изменения будут применены к узлам из группы webservers.
Сценарии могут выполняться не только от имени пользователя, под именем которого установлено соедиение, но и любого другого. В следующем примере авторизация на хосте будет произведена с именем yourname, но задачи будут выполняться от имени пользователя root (если, конечно, этому пользователю это разрешено использовать sudo):
Если добавить параметр “user: postgres”, то все действия будут выполняться с привилегиями пользователя postgres.
В разделе vars указываются переменные, которые будут использованы в сценарии, и их значения:
Список изменений/состояний, которые необходимо произвести на управляемом узле, приводится в разделе tasks. Каждой задаче (task) присваивается имя (name), его можно опустить. Далее указывается модуль Ansible, который будет задействован при её выполнении:
Для каждой задачи можно указывать пользователя, от имени которого она будет выполнена:
Шаблонизация
В Ansbile используется шаблонизатор Jinja2. Приведём пример простого шаблона (часть конфига powerdns):
Обратим внимание на то, что файл шаблона и файл с паролем пользователя базы данных находятся на машине управления, а результатом будет файл на удалённом узле.
Обработчики событий (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 исходным кодом проекта и хорошим набором примеров проектов
http://www.ansibleworks.com/docs/ — официальная документация (активно пополняется);
http://jpmens.net/2012/06/06/configuration-management-with-ansible/ — статья Яна Пита Менса об управлении конфигурациями с помощью Ansible (в его блоге есть и много других материалов по теме).
https://gist.github.com/marktheunissen/2979474 — пример сценария с подробными комментариями, правда для старой версии.
www.ansibleworks.com/docs/contrib.html — ещё больше ссылок на примеры использования, включая в том числе и очень сложные конфигурации.
Для тех кто не может комментировать посты на Хабре, приглашаем к нам в блог.