Автоматизируйте все с помощью Ansible: часть вторая

обзор

Это вторая часть учебника из двух частей по Ansible . Часть первая здесь . В этой части вы узнаете о ролях (строительные блоки Ansible), переменных, циклах, о том, как использовать роли в книгах игр и как организовать роли в структуру каталогов.

Роли

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

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

Мне очень нравятся псевдонимы и функции оболочки, потому что я не могу вспомнить все тайные переключатели и опции для каждой команды, а также потому, что это экономит много времени на ввод. Мне также нравится иметь некоторые инструменты, такие как htop и tmux на каждом сервере, на котором я вхожу.

Вот файл, который содержит некоторые из моих любимых псевдонимов и функций. Я назову это «.gigirc». Кстати, если вы когда-нибудь задумывались, что означает суффикс «rc» во всех этих файлах rc, то он означает «Run Commands».

Давайте определим роль с именем «common», которая создает пользователя с именем «gigi», добавляет открытый ключ ssh, копирует файл «.gigirc» и добавляет строку в конце «~ / .bashrc», которая запускает этот файл, и, наконец, устанавливает общие пакеты vim, htop и tmux (определенные в файле vars / main.yml).

Я представлю здесь много нового: четыре разных модуля, переменные и циклы. Кроме того, роли обычно распределяются между несколькими файлами в стандартной структуре каталогов. Я покажу вам пару файлов, а затем объясню структуру каталогов. Вот файл ‘tasks / main.yml’:

А вот файл vars / main.yml, который содержит определение переменной ‘COMMON_PACKAGES’, используемой для указания, какие общие пакеты устанавливать.

Модули

Пользовательский модуль может управлять учетными записями пользователей. Здесь я использую его для создания пользователя ‘GIGI’.

Модуль author_key предназначен для добавления / удаления авторизованных ключей SSH. Здесь я использую его, чтобы добавить свой открытый ключ для пользователя ‘gigi’.

Модуль lineinfile может использоваться для замены или добавления отдельных строк в файл. В этом случае я использую его для получения файла «.gigirc» из «.bashrc», поэтому все классные псевдонимы и функции в «.gigirc» всегда доступны в любом интерактивном сеансе.

Наконец, модуль apt имеет множество опций для управления пакетами apt. Здесь я просто устанавливаю некоторые распространенные пакеты.

переменные

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

Loops

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

Ролевая структура каталогов

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

общий

Hand── обработчики

Main └── main.yml

Meta── мета

Main └── main.yml

Tasks── задачи

Main └── main.yml

Templates── шаблоны

Ars── вары

Deb── Debian.yml

Bu── Ubuntu.yml

Main── main.yml

Файл tasks / main.yml — это место, где определены все задачи. Каждая задача соответствует команде Ansible, которая обычно использует модуль.

Файл meta / main.yml будет содержать список других ролей, от которых зависит текущая роль. Задачи этих ролей будут выполнены до текущей роли, поэтому можно быть уверенным, что все ее предпосылки выполнены.

В файле ‘handlers / main.yml’ хранятся ваши обработчики, как и тот обработчик, который вы видели ранее, который запускает Nginx после установки.

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

Каталог vars содержит различные переменные и может условно содержать разные значения для разных операционных систем (очень распространенный вариант использования).

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

Использование ролей

Роли делают тяжелую работу, но книги-игры — это то, как ты на самом деле работаешь. Сборники сочетают инвентарь и роли и определяют, какие роли на каком хосте играть. Вот как выглядит книга с ролями:

Запуск playbook дает следующий вывод:

Вывод

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