Глава 2. Автоматизация вашей инфраструктуры ИТ при помощи Ansible

Данная глава содержат примеры основывающиеся на следующих технологиях:

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

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

Все обсуждаемые примеры кода данной главы доступны с GitHub.

Получение Ansible поднятым и исполняющимся является прямолинейным предприятием и пакет доступны для большинства дистрибутивов Linux, FreeBSD и практически для любых платформ в которых запускается Python. Если у вас имеются установленными последние версии Microsoft Windows, которые поддерживают WSL (Windows Subsystem for Linux) Ansible будет установлен и запустится и там.

Имеющаяся официальная документация предоставляет документацию по установке для всех основных платформ.

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

Следуя официальной документации по установке, для установки самой последней версии Ansible в нашей демонстрационной системе выполняются такие команды:

$ sudo apt-get update
$ sudo apt-get install software-properties-common
$ sudo apt-add-repository --yes --update ppa:ansible/ansible
$ sudo apt-get install ansible
		

Если всё прошло хорошо, у вас появится возможность запросить исполняемый файл Ansible на предмет его версии выполнив такую команду:

$ ansible --version
		

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

Наши поздравления! Теперь, когда Ansible установлен, давайте рассмотрим основы исполнения ваших первых настроек задач Ansible, носящих название плейбуков. Для получения одной из таковых для запуска вам в действительности требуется иметь на своих местах три вещи:

При установке Ansible обычно в /etc/ansible/ansible.cfg устанавливается файл настроек по умолчанию. Имеется множество расширенных свойств, которые можно изменять в данном файле, причём они могут перекрываться с применением некоторого числа методов. Для целей данной книги мы будем работать почти исключительно с настройками по умолчанию, что означает, что на данный момент нам достаточно знать об их наличии в данном файле.

В Ansible ничто не происходит без какого- нибудь файла описи (учёта ресурсов, inventory). Такая опись это текстовый файл (или сценарий), который снабжает исполняемые файлы Ansible списком имён хостов для работы с ними, даже когда это всего лишь сам данный локальный хост. В следующей части данной главы мы рассмотрим описи более подробно, поскольку они рассматриваются как важнейшие в нашем путешествии по автоматизации. На текущий момент мы обнаружим что в большинстве платформ linux образец файла описи установлен в /etc/ansible/hosts как часть установки Ansible. Когда такой файл описи пустой (или содержит одни комментарии, как в случае файла образца), подразумевается что Ansible исполняется только для самого локального хоста.

И последнее, но не в отношении его значимости, вам на практике требуется иметь некий плейбук для его запуска над сервером (или серверами). давайте теперь поработаем с неким примером чтобы получить очень простой плейбук для его запуска с Ansible. Плейбуки Ansible пишутся в YAML (рекурсивное сокращение, означающее YAML Ain't Markup Language YAML не является языком разметки) и, поскольку он является очень простым для чтения - на самом деле именно это одна из центральных сильнейших черт Ansible - плейбуки запросто могут прихватываться кем- то с минимальными навыками Ansible и всё ещё быть простыми для понимания чтобы их можно было применять или изменять.

Если вы не пользовались кодом на Python или YAML, тогда одна из вещей, которую вам следует уяснить относительно написания YAML для плейбуков это значение отступов. Вместо использования для блоков кода скобок или фигурных скобок и точек с запятой для обозначения концов строк (как это имеет место во многих языках программирования), YAML применяет соответствующий уровень отступа сам по себе для задания того где именно в коде вы находитесь и как это соотносится с окружающим вас кодом. Отступы всегда создаются при помощи пробелов - никогда не применяйте табуляцию. Даже хотя такие отступы и выглядят одинаковыми для невооружённого взгляда, синтаксический анализатор YAML не будет рассматривать их одинаковыми.

Рассмотрим такой блок кода:

---
- name: Simple playbook
  hosts: localhost
  become: false
 	   

Это самое начало некого плейбука Ansible. Файлы YAML Ansible всегда начинаются с трёх дефисов (---), причём без каких бы то нибыло отступов. Далее у нас имеется отдельная строка, которая определяет начало воспроизведения (play), обозначаемое одиночным дефисом (-), также без отступов. Обратите внимание, что плейбук Ansible может состоять из одного или более воспроизведений, причём каждое воспроизведение будет (на неком базовом уровне) каким- то набором задач для выполнения на данном множестве хостов. Эта конкретная строка данного плейбука предписывает значение name для данного плейбука. Хотя такое ключевое слова name и является не обязательным и в большинстве мест может опускаться, настоятельно рекомендуется включать его во все определения плейбука (в точности как это сделали мы), причём для абсолютно всех задач. Это очень просто, добавляет удобство чтения данного плейбука и тот факт чтобы кто- то новый быстро смог его распознавать, а следовательно это предлагает эффективность и более низкий порог для входа вновь приобщающихся, как мы это обсуждали в своей предыдущей главе.

Третья строка данного кода сообщает Ansible какие hosts данная задача содержит в данном воспроизведении и для которых она должна запускаться. В данном экземпляре мы намерены выполнить действия только для localhost. Четвёртая строка сообщает Ansible о том что ему не следует become (становиться) определённым суперпользователем (root), так как это не требуется для данной задачи. Некоторые задачи - например, перезапуск системной службы - должны исполняться от имени суперпользователя, а потому в таком случае вам следует определить become: true. Обратите внимание на отступ в два символа как в третьей, так и в четвёртой строках предыдущего кода - это сообщает синтаксическому анализатору YAML что эти строки являются частью того воспроизведения, которое определяется его второй строкой.

Теперь давайте добавим в своё плейбук две задачи вставляя в конец два следующих блока кода под уже приведённым выше:

  tasks:
    - name: Show a message
      debug:
        msg: "Hello world!"

    - name: Touch a file
      file:
        path: /tmp/foo
        state: touch
	   

Наше ключевое слово tasks задаёт конец определения данного воспроизведения и начало реальных задач, которые мы желаем выполнить. Обратите внимание что оно всё ещё выделяется отсупом в два пробела, что сообщает его синтаксическому анализатору что оно всё ещё является частью заданного нами ранее воспроизведения. Затем мы снова увеличиваем отступ для своей следующей строки чтобы обозначить, что она входит в состав данного блока tasks.

Теперь мы знакомы с шаблоном сборки. Всякий раз, когда некая строка кода составляет часть предыдущего оператора, мы увеличиваем значение отступа на два пробела. Всякий новый элемент начинается с одиночного дефиса (-), таким образом, наш предыдущий блок кода содержит две задачи.

Самая первая применяет ключевое слово name со значением Show a message, следуя документации (вспомните комментарии в прочих языках программирования) и применяет нечто, носящее название модуля Ansible. Модулями являются предварительно определённые блоки кода Ansible, которые Ansible использует для выполнения предписанных задач. На включённый в данном случае модуль debug применяется в основном для отображения сообщений или содержимого переменных, а следовательно для отладки плейбука. Мы передаём значение параметра msg в заданный модуль debug через последующий отступ двумя пробелами для msg, сообщая именно тот модуль в котором мы желаем вывести на печать сообщение при исполнении данного плейбука.

Нана вторая задача обладает ключевыми словами name и Touch a file и применяет модуль file для касания (touch) с файлом, расположенным в /tmp/foo. Когда мы запускаем этот плейбук, его вывод выгдядит как- то так:

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

echo "Hello World!"
touch /tmp/foo
 	   

Самая первейшая причина использования Ansible в том, что хотя данный пример очень простой и лёгкий для его понимания, по мере того как необходимые задачи для некого сценария усложняются, их становится сложнее читать и требуется некто понимающий язык сценариев для их отладки и изменения. Для нашего плейбука Ansible вы можете видеть что его код обладает невероятным восприятием для его чтения, а с его каждой частью связано некое name. принудительные отступы также служат превращению данного кода в более читаемый и, хотя и комментарии и отступы так же поддерживаются языком сценариев, ни то ни другое не являются принудительными и, как правило, опускаются. Поверх этого, все модули должны обладать документацией, принимаемой установленным ядром дистрибутива Ansible - таким образом, вам на руки предоставлена документация достойного качества для вашего плейбука. К примеру, когда мы желаем изучить как применять модуль file, которым мы воспользовались ранее, мы бы могли просто ввести в оболочке своей системы такую команду:

$ ansible-doc file
		

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

Следующая причина состоит в том, что имеющиеся модули Ansible (в основном) предлагают поддержку для идемпотентных изменений. Это означает то, что когда некое изменение уже выполнено, мы не сделаем его повторно. Это в особенности важно для некоторых изменений, которые могут быть разрушительными по своей природе. Это также сохраняет время и вычислительные ресурсы и даже способствует аудиту систем. Кроме того, Ansible предоставляет управление потоком и надёжную обработку ошибок и, в то время как некий сценарий продолжит своё выполнение даже после некой ошибки, до тех пор пока вы не внедрите свой собственный код обработки ошибок (возможно, вызывающий непредсказуемые и нежелательные результаты), Ansible остановит всё последующее исполнение и потребует от вас исправления имеющихся проблем прежде чем запускать этот плейбук снова.

Будет не лишним упомянуть, что хотя модули из некого ядра являются сильной стороной Ansible, существуют случаи, когда необходимая вам функциональность не обрабатывается никакими из доступных модулей. Особую прелесть Ansible состоит в том что он является OSS (open source software, программным обеспечением с открытым исходным кодом) и вы имеете возможность написать и свой собственный модуль и осуществить его интеграцию. Это выходит за рамки данной книги, но стоит того чтобы изучить по мере совершенствования ваших навыков Ansible. В тех случаях, когда существующие модули не обладают необходимой функциональностью, а у вас нет времени или ресурсов для написания своего собственного модуля, Ansible способен также отправлять сырые команды оболочки в соответствующую подлежащую автоматизации систему. На практике имеются два модуля - shell и command - которые способны отправлять сыры е команды в удалённые системы. Таким образом, вы даже можете смешивать сценарии оболочки с Ansible, когда возникает такая потребность, хотя вам всегда следует применять естественные модули Ansible прежде чем прибегать к использованию shell или command. Таким образом, Ansible невероятно гибок - его встроенные функции обширны, однако в случае когда он чего- то не дотягивает, невероятно просто расширять имеющуюся функциональность самостоятельно.

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

В своём следующем разделе мы рассмотрим вероятно одну из основных причин использования Ansible вместо простого сценария оболочки.

Как мы уже касались этого, одна из ключевых причин быстрого восприятия Ansible состоит в том факте, что он может интегрироваться без агента в большинство основных операционных систем. например, отдельный хост Ansible способен автоматизировать команды только под прочие хосты Linux (или BSD), с которыми он способен взаимодействовать поверх SSH. Он способен автоматизировать задачи в хостах Windows, которые обладают включённым WinRM и именно здесь мы начнём раскрывать истинную мощь Ansible.

В своём предыдущем разделе данной главы мы рассматривали лишь исполнение Ansible для своего локального хоста в явном виде, без применения SSH. Ansible поддерживает два различных вида описей (учёта ресурсов, inventory): статическую и динамическую. На протяжении данной книги мы в основном будем работать со статическими описями, поскольку они обслуживают рассматриваемые нами примеры. Действительно, статические описи исключительны для небольших сред, в которых рабочие нагрузки отслеживают небольшой перечень серверов, которые подлежат автоматизации (который в сущности и составляет опись Ansible). Тем не менее, по мере роста описей в масштабах, или когда они оставаясь небольшими часто меняются (например, облачные вычислительные ресурсы или контейнеры Docker), та работа, которая требуется для поддержки файла описи Ansible в актуальном состоянии становится намного большей и склонной к появлению ошибок.

Ansible предлагает некое число готовых к применению динамических решений ведения учёта, которые интегрируются с популярными облачными платформами, такими как Microsoft Azure и Amazon Web Services, размещаемыми локально вычислительными платформами, подобными OpenStack и VMware, а также решениями управления инфраструктурой наподобии Katello. Даже допустимо написание собственных сценариев динамических описей и по мере масштабирования вашего окружения вы скорее всего найдёте себя идущим по этому пути.

Но на данный момент мы сосредоточимся на статических описях. Допустим, что мы желает рассмотреть пример своего плейбука из предыдущей части главы и запустить его для двух удалённых хостов вместо выполнения для локального хоста. Прежде всего, давайте создадим некий файл описи , который содержит названия/ адреса наших двух хостов. Статическая опись записывается в формате INI (в противоположность применяемому для плейбуков формату YAML) и, на своём самом простом уровне состоит из одного хоста в каждой строке. Обратите внимание, что хосты могут определяться либо записями DNS, либо через IP адреса.

Вот тот файл описи, который мы будем применять в своей демонстрационной среде:

[test]
testhost1
testhost2
 	   

Как вы можете видеть, этот файл очень простой. Самая первая строка, с квадратными скобками вокруг неё, это название группы перечисляемых ниже серверов. Серверы могут располагаться в более чем одной группе и это в целом служит для повседневного управления серверами. Например, когда у вас имеется некий плейбук для применения обновлений безопасности ко всем серверам Linux, тогда скорее всего вы пожелаете иметь группу с названием, подобным [linux-servers], которая содержит адреса всех подобных серверов. Если далее у вас имеется некий плейбук для развёртывания некого веб приложения, вы скорее всего захотите поместить все веб серверы в группу с названием [web-servers]. Это упрощает целеуказание верного набора серверов при запуске конкретного плейбука - помните строку hosts: в самом верху нашего плейбука в нашем более раннем примере?

Группы могут даже быть потомками прочих групп. Таким образом, если вы знаете что все ваши веб серверы основываются на Linux, вы можете описать свою группу web-servers как потомка группы linux-servers, тем самым включая всем веб серверам обновления безопасности без необходимости дублирования в соответствующей описи.

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

---
- name: Simple playbook
  hosts: all
  become: false
 	   

Как вы можете видеть, теперь мы изменили свой параметр hosts с localhost на all (all это особенное ключевое слово, означающее все без исключения хосты из данной описи, вне зависимости от их группы). Если бы вы пожелали определить только конкретную группу test, нам бы пришлось поместить hosts: test или даже hosts: testhost1 для того чтобы определённый плейбук запускался бы только для отдельного хоста.

Теперь, когда мы знаем что Ansible применяет SSH для соединения с удалёнными хостами Linux из своей описи, а на данном этапе, у нас не настроена аутентификация на основании ключей SSH. Таким образом, нам требуется сообщить Ansible выводить приглашение на ввод значения пароля SSH (по умолчанию это не так, что означает что мы будем получать отказ в случае не настроенной аутентификации на основании ключей). Аналогично соответствующей утилите SSH командной строки, пока мы не сообщим Ansible обратного, он будет инициировать некое подключение SSH с соответствующей удалённой системой с применением имени пользователя из текущего сеанса из его локальной машины. Таким образом, для моего примера, в нашем сервере Ansible имеется соответствующий пользователь james и две тестовые системы, а все задачи выполняются от имени этого пользователя. Для исполнения своего плейбука в отношении своих двух удалённых систем я могу запустить такую команду:

$ ansible-playbook -i hosts --ask-pass simple.yml
		

Это выглядит слегка по- иному по сравнению с нашим последним разом - отметьте следующие новые параметры:

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

Здесь вы можете видеть, что обе созданные нами ранее в этой главе задачи были выполнены - только в этот раз они были исполнены в паре удалённых систем при помощи естественного протокола взаимодействия SSH. Обычно SSH включён в большинстве систем Linux, это немедленно предоставляет нам огромную сферу для расширения автоматизации - данный пример был выполнен для некой описи, содержащей только два хоста, но он также запросто может быть выполнен и для содержащей 200 или более хостов.

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

Когда мы настроим ключи SSH для имеющихся удалённых хостов, тогда наш параметр --ask-pass более станет не нужным и наш плейбук запускается без какого бы то ни было прерывания от своего пользователя, что для многих сценариев автоматизации более желательно:

Давайте пробежимся по простому процессу выработки некого ключа SSH и его настройки в своих тестовых системах для аутентификации в Ansible:

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

Хотя здесь мы и воспользовались преимуществом того факта что Ansible считает (по умолчанию) значение необходимых частных ключей SSH, которые обнаруживаются в установленном каталоге .ssh для соответствующего пользователя из запроса, вы не ограничены применением этих ключей. Вы можете определять некий файл частного ключа вручную при помощи переменной хоста ansible_ssh_private_key_file в своей описи, любо можете воспользоваться ssh-agent для выработки другого частного ключа SSH, доступного Ansible в устанавливаемом текущем сеансе оболочки.

Осуществление этого оставлено вам в качестве некого упражнения, а следующие страницы из официальной документации Ansible помогут вам с этим:

Конечно же, вам не требуется выполнять все задачи в качестве своего текущего пользователя - вы можете использовать соответствующий флаг --user (-u) в ansible-playbook для задания его применения по всем хостам из установленной описи, либо даже можете воспользоваться значением переменной хоста ansible_user внутри самой описи для задания учётных записей пользователя под каждый хост. Очевидно, вам следует попытаться избегать подобного этому сценария, посольку он идёт вразрез с принципом единообразия, который мы обсуждали в Главе 1, Построение стандартной среды работы в Linux, однако это важный момент, на который стоит обратить внимание, и он состоит в том, что Ansible предлагает гигантскую гибкость и возможность персонализации. Он невероятно отлично масштабируется в SOE, однако когда существуют отклонения, очень просто адаптировать Ansible без каких бы то ни было трудностей.

Позднее в этой главе мы углубимся в большие подробности переменных, но на данном этапе не лишним будет отметить, что описи также могут содержать переменные. Это могут быть либо создаваемые пользователем переменные, либо специальные переменные, такеи как ansible_user. Если вы желаете настроить своего пользователя SSH bob и создать некую новую определяемую пользователем переменную http_port для её последующего применения в неком плейбуке, расширение нашей простой описи из данной главы может выглядеть следующим образом:

[test]
testhost1
testhost2

[test:vars]
ansible_user=bob
http_port=8080
 	   

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

С Ansible также просто начинать как и с чтением некого плейбука когда он короток, причём он усложняется по мере необходимости. Кроме того,существуют определённые функции, которые могут повторно требоваться в прочих сценариях. Например, вам может потребоваться развёртывать некий сервер базы данных MariaDB в качестве распространённой задачи в вашей среде. Некий модуль apt применяется для управления пакетами в серверах Ubuntu, а потому, когда мы желаем устанавливать в своей тестовой системе соответствующий пакет mariadb-server, наш плейбук для выполнения такой задачи может выглядеть подобным образом:

---
- name: Install MariaDB Server
  hosts: localhost
  become: true

  tasks:
    - name: Install mariadb-server package
      apt:
        name: mariadb-server
        update_cache: yes
 	   

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

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

Именно тут и вступают в действие роли и некая роль Ansible, которая по существу представляет собой ничто иное как некий структурированный набор каталогов и YAML, обеспечивает действенное и эффективное повторное применение кода. Это также делает более простым чтение начального плейбука, как мы вскоре увидим. После того как роли созданы, они могут быть сохранены в каком- то централизованном местоположении, таком как репозиторий управления версиями (например, GitHub), а затем, всякий раз когда необходимо установить MariaDB, всегда можно получать доступ к самой последней версии.

Роли (по умолчанию) запускаются из некого подкаталога с названием roles/, причём в том же самом каталоге что и ваш плейбук. На протяжении данной книги мы будем применять то соглашение, согласно которому будет устанавливаться что Ansible также будет выполнять поиск ролей в /etc/ansible/roles и те пути, которые определяются значением параметра roles_path в файле настроек самого Ansible (который, по умолчанию, может быть найден в /etc/ansible/ansible.cfg, хотя существуют способы перекрытия и его). Всякая роль обладает своим собственным подкаталогом в ней и такое название каталога формирует само название данной роли. Давайте изучим это на простом приводимом ниже примере:

Обратите внимание насколько более компактен теперь это плейбук! Его также проще читать и всё же, если мы запустим его, мы обнаружим что он выполняет ту же самую функцию. Обратите внимание что состояние самой задачи установки сервера MariaDB когда мы её запускали последний раз было changed, а теперь оно ok. Это означает, что Ansible определил что наш пакет mariadb-server уже был установлен, а следовательно не требуются никакие дальнейшие действия. Именно это и составляет ранее упомянутый пример идемпотентного изменения в действии, который мы можем наблюдать на следующем снимке экрана:

отлично сработано! Вы создали и выполнили свою первую роль. Если вы желаете прочитать дополнительно о ролях и необходимой структуре каталога, обратитесь, пожалуйста, к https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html.

В ролях имеется даже более того - не просто то, что они неоценимы при структурировании ваших плейбуков и делают возможным повторное применение кода; существует также некий центральный репозиторий для ролей вклада сообщества, носящий название Ansible Galaxy. Когда вы выполните поиск в Ansible Galaxy на предмет относящегося к MariaDB, вы обнаружите (на момент написания этих строк) 277 различных ролей, причём все они разработаны для осуществления различных задач установки базы данных. Это означает, что вам даже не придётся писать свои собственные роли для распространённых задач - вы можете либо воспользоваться вкладом сообщества, либо сделать ответвление от него и внести изменения в своих собственных окончаниях. Наиболее распространённые задачи автоматизации сервера уже были решены каким- то способом в имеющемся сообществе Ansible, а потому скорее всего вы найдёте в точности то что ищите.

Давайте теперь проверим это таким образом:

Наш конечный результат, тем не менее, сотоит в том, что необходимый пакет mariadb-server установлен в нашей тестовой системе - и на этот раз нам практически не пришлось писать какой- то код! Конечно же, желательно проверить какую роль намерен исполнять Ansible Galaxy прежде чем вслепую запускать её в ваших системах, особенно в том случае когда она вносит изменения которые вы не ожидаете (или не желаете!). Тем не менее, роли в сочетании с Ansible Galaxy составляют мощное дополнение к той ценности, которую должен предлагать Ansible.

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

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

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

Короче говоря, переменные могут определяться в некотором числе местоположений и верное место для определённого сценария будет направляться имеющимися обстоятельствами конкретного плейбука. Например, когда некая переменная является общей для некой группы серверов, было бы логичным определить её в той же описи, в которой пребывает переменная группы. Когда она применяется ко всем хостам в определённом запускаемом вне всякой зависимости плейбуке, тогда вы почти несомненно зададите её в самом плейбуке. Давайте рассмотрим это по- быстрому изменив свой появлявшийся ранее в этой главе плейбук simple.yml, но на этот раз определяя для отображения своим оператором debug при выполнении данного плейбука некую переменную воспроизведения с именем message:

---
- name: Simple playbook
  hosts: localhost
  become: false

  vars:
    message: "Life is beautiful!"

  tasks:
    - name: Show a message
      debug:
        msg: "{{ message }}"
    - name: Touch a file
      file:
        path: /tmp/foo
        state: touch
 	   

Заметьте, что нам пришлось перед одной из tasks задать некий раздел vars и что значение переменной доступно через помещение его в двойные фигурные скобки. Запуск этого плейбука даст следующие результаты:

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

$ ansible-playbook simple.yml -e "message=\"Hello from the CLI\""
		

Обратите внимание на особые кавычки и их экранирование, требуемые для обработки пробелов в содержимом такой переменной, а также на сам эффект от этой операции с нашим плейбуком:

Переменные также могут передаваться в роли и это простой но всё ещё мощный способ создания обобщённых ролей, которые могут применяться во множестве сценариев без использования идентичных данных конфигурации. Например, в своём предыдущем разделе мы изучали установку сервера MariaDB. Хотя это и достойный претендент для роли, несомненно,вы не желаете устанавливать один и тот же самый пароль root базы данных в настройках всех серверов. Может иметь смысл определить некую переменную для значения пароля и передавать его в определённую роль из вызываемого плейбука (или другого надлежащего источника, такого как некая переменная хоста или группы).

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

Например, когда вам требуется узнать значение имени текущего хоста, для которого выполняется действие конкретной задачи, это можно выполнить через значение переменной inventory_hostname. Полный список этих переменных доступен по https://docs.ansible.com/ansible/latest/reference_appendices/special_variables.html.

Многие читатели успели к данному моменту обратить внимание, что получаемый вывод из всех наших примеров плейбуков содержит некую строку, которая сообщает Gathering Facts {сбор сведений}. Хотя это и можно отключить, на самом деле это невероятно полезно и наполняет широкий массив переменных с очень полезными ключевыми системными сведениями. Для получения некого представления этом виде данных, которые собираются на данном этапе, запустите из своей командной строки такой код:

$ ansible -m setup localhost
		

Данная команда вместо того чтобы запускать некий плейбук инструктирует Ansible выполнить указанный модуль setup непосредственно в localhost - модуль setup это один из исполняемых за сценой на этапе Gathering Facts. Его вывод будет выглядеть как- то подобно приводимому далее и растягивается на многие страницы - вот всего лишь первые нексолько строк:

Мы незамедлительно можем обнаружить, что тут и в самом деле имеются некоторые полезные сведения, такие как значения IP адресов данного хоста, значение тома root и тому подобное. Помните наше обсуждение относительно единообразия в Главе 1, Построение стандартной среды работы в Linux и особой сложности при определении значения операционной системы в которой происходит выполнение? Что же, Ansible с лёгкостью делает это, так как эти сведения доступны в собранных фактах. Мы можем видоизменить свой оператор debug для отображения значения дистрибутива Lnux, в котором мы осуществляем выполнение, причём просто определяя значение соответствующего факта, доступного из получаемого в нашей последней команде вывода следующим образом:

- name: Show a message
      debug:
        msg: "{{ ansible_distribution }}"
 	   

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

Ansible позволяет вам выполнять индивидуальные задачи, роли и даже целые блоки задач по некому условию, а следовательно обладание доступом к фактам делает достаточно прямолинейным написание надёжных плейбуков, которые способны запускаться для множества платформ и выполнять верные действия в каждой из них.

Также не лишним будет отметить, что переменные нет нужды хранить в неком незашифрованном тексте. Порой требуется сохранять некий пароль в какой-то переменной (как уже обсуждалось ранее - возможно, значение пароля root для нашей установки сервера MariaDB). Хранение таких сведений в формате открытого текста представляет большой риск для безопасности, но к счастью, Ansible содержит некую технологию с названием Vault (сейф, хранилище), которая способна хранить сведения переменных зашифрованными с помощью AES256. К таким зашифрованным vault можно обращаться из любого плейбука, предоставляя пароль vailt передаваемым в этот плейбук при его запуске. Vault выходят за рамки данной главы, но если вы желаете узнать о них больше, обратитесь, пожалуйста, к https://docs.ansible.com/ansible/latest/user_guide/playbooks_vault.html {Прим. пер.: или к нашему переводу 3 издания Полного руководства Ansible Джеймса Фримана и Джесса Китинга}. В этой книге мы не будем пользоваться ими интенсивно, просто оставляя это вам с целью упражнения со своим примером кода. Тем не менее, настоятельно рекомендуется чтобы в промышленном окружении вы применяли vault всякий раз когда некому плейбуку требуется сохранять чувствительные сведения.

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

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

<VirtualHost *:80>
    DocumentRoot "/var/www/automation"
    ServerName www.example.com
</VirtualHost>
 	   

Мы хотим развернуть эту конфигурацию, но внести индивидуальную правку для значения параметра DocumentRoot в каждом из хостов. Естественно, мы можем просто развернуть приведённый выше файл в точности как он представлен во всех хостах и затем воспользоваться неким регулярным выражением совместно с имеющимся в Ansible модулем replace для посика строки DocumentRoot и её изменения (аналогично применению соответствующей утилиты командной строки sed). Получаемый в результате плейбук может выглядеть таким:

---
- name: Deploy and customize an Apache configuration
  hosts: localhost
  become: true

  vars:
    docroot: "/var/www/myexample"

  tasks:
    - name: Copy static configuration file to remote host
      copy:
        src: files/vhost.conf
        dest: /etc/apache2/sites-available/my-vhost.conf

    - name: Replace static DocumentRoot with variable contents
      replace:
        path: /etc/apache2/sites-available/my-vhost.conf
        regexp: '^(\s+DocumentRoot)\s+.*$'
        replace: '\1 {{ docroot }}'
 	   

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

Однако это не элегантное решение. Прежде всего, мы применяем две задачи и когда мы бы пожелали персонализировать также и ServerName, нам потребовалось бы ещё больше. Кроме того, те, кто знаком с регулярными выражениями, будут понимать, что не потребуется слишком много чтобы просто запутаться при их использовании здесь. Напсание хороших надёжных регулярных выражений для подобных этой задач само по себе является искусством.

К счастью, Ansible унаследован из Python, в котором имеется уже написанной некая технология с названием шаблоны Jinja2. Именно она исключительно подходит для подобных данному случаев (и для многих прочих сценариев автоматического развёртывания). Вместо громоздкого многоэтапного аналогичного приведённому подхода мы теперь определяем свой начальный файл конфигурации виртуального хоста как некий шаблон в templates/vhost.conf.j2 следующим образом:

<VirtualHost *:80>
    DocumentRoot {{ docroot }}
    ServerName www.example.com
</VirtualHost>
 	   

Как вы можете видеть, он почти идентичен нашему первоначальному файлу настроек за исключением того, что здесь мы заменили одно из своих статических значений одной из своих переменных, представленных парой фигурных скобок, в точности как это имело бы место в самом нашем плейбуке. Прежде чем мы продолжим этот пример, недурно отметить, что Jinja2 невероятно мощная система шаблонов, которая выходит далеко за рамки простой подстановки переменной в обычный файл. Также существуют и условные операторы, такие как if...else и циклы for, а также содержится широкий массив фильтров, которые могут применяться для манипуляций с содержимым (например, для преобразования какой- то строки в верхний регистр, или для соединения всех участников какого- то списка воедино в виде некой строки).

С учётом сказанного, данная книга не служит в качестве полного справочного руководства ни для Ansible, ни для Jinja2 - вместо этого она предназначена в качестве практического руководства для демонстрации того как собирать вашй собственную SOE при помощи Ansible. Обратитесь, пожалуйста, к разделу Последующее чтение в самом конце данной главы для знакомства со ссылками, по которым вы получите более полный обзор как Ansible, так и Jinja2.

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

---
- name: Deploy and customize an Apache configuration
  hosts: localhost
  become: true

  vars:
    docroot: "/var/www/myexample"

  tasks:
    - name: Copy across and populate the template configuration
      template:
        src: templates/vhost.conf.j2
        dest: /etc/apache2/sites-available/my-vhost.conf
 	   

Обратите внимание, насколько более элегантен этот плейбук - кго модуль template копирует шаблон конфигурации в необходимый удалённый хост, просто так же как это делал модуль copy из нашего предыдущего примера, а также заполняет все заданные нами переменные. Это невероятно мощный способ развёртывания файлов настроек неким повторяемым, общим образом и вам настоятельно рекомендуется приспособить такой подход везде где он возможен. Когда файлы меняются персоналом, это зачастую выполняется несогласованно и это может превратиться во врага для автоматизации, поскольку вам придётся собирать действительно надёжные регулярные выражения для обеспечения отлова всех возможных граничных случаев. Развёртывание из шаблонов с помощью Ansible создаёт повторяемые, надёжные результаты, которые запросто могут утверждаться в промышленной среде. Запуск данного плейбука даёт идентичные предыдущим результаты, причём для более сложного примера:

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

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

Как это уже обсуждалось в нашей предыдущей главе, несмотря на то что хорошо определённая SOE и будет согласованной в сам момент развёртывания, такая согласованность может быть вскорости утрачена если администраторам дозволено вносить изменения по своему усмотрению при помощи предпочитаемых ими методов. В точности так же как это желательно для развёртывания некой SOE для достижения успеха в автоматизации, также желательно превратить автоматизацию своим делом для такого числа задач администрирования, какое только возможно (в идеале для всех).

В идеале должен существовать лишь один источник истины для плейбуков (например, какой- то централизованный репозиторий Git) и единственный источник истины для описей (он может иметь форму некого централизованно хранимого статического учёта ресурсов или применять какую- то динамическую опись).

Основной целью любого написанного подобающим образом плейбука (или роли) Ansible является то, что их результаты исполнения повторяемы и предсказуемы. Возьмём в качестве примера тот плейбук, который мы запускали в самом конце своего предыдущего раздела, когда мы развёртывали некий образец файла vhost.conf Apache при помощи написанного нами плейбука. При каждом запуске вами этого плейбука в любом сервере содержимое /etc/apache2/sites-available/my-vhost.conf будет одним и тем же, так как этот плейбук развёртывает данный файл применяя некий шаблон и переписывает имеющийся целевой файл когда тот имеется.

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

Сама повторяемая природа хорошо написанных плейбуков также важна для упоминания здесь - просто то что вы развернули какую- то согласованную конфигурацию Apache не означает что она продолжит оставаться согласованной. Пятью минутами позднее после того как вы развернули данную конфигурацию, некто с необходимыми полномочиями может войти в систему и изменить эту конфигурацию. Тем самым ваша среда может почти немедленно отклониться от заданной вами SOE. Повторное выполнение ваших плейбуков по всей вашей инфраструктуре не самом деле важная часть ваших повседневных процессов, ибо сама природа таких плейбуков будет способна привносить данные настройки обратно в строй с вашими первоначальными стандартами. Тем самым плейбуки Ansible выступают жизненно важным составляющим не только при определении и развёртывании вашей SOE, но также и в продолжающемся принуждении к установленным стандартам.

Никакие исправления не следует развёртывать вручную, когда это возможно. Предположим, некто вручную подправил установленную конфигурацию в /etc/apache2/sites-available/my-vhost.conf чтобы победить некую проблему. Само по себе это не является какой- то проблемой, но жизненно важно чтобы такие изменения помещались бы обратно в надлежащий плейбук, роль или шаблон. Когда развёртывание или принудительное применение вашей SOE через Ansible каким- то образом нарушает его, тогда в ваших процессах кроется нечто неладное.

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

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

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

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

В нашей следующей главе вы раскроете как рационализировать управление инфраструктурой и дополнительно совершенствовать ваш процесс автоматизации с применением AWX.

Для более глубокого понимания Ansible и шаблонов Jinja2, будьте добры ознакомиться с Mastering Ansible, Third Edition — James Freeman и Jesse Keating {Прим. пер.: рекомендуем также свой перевод этого 3 издания Полного руководства Ansible Джеймса Фримана и Джесса Китинга}.