Поиск по сайту:

Как создать Ansible Playbook для автоматизации настройки системы в Ubuntu


Статус: устарело

В этой статье рассматривается версия Ubuntu, которая больше не поддерживается. Если вы в настоящее время используете сервер под управлением Ubuntu 12.04, мы настоятельно рекомендуем обновить или перейти на поддерживаемую версию Ubuntu:

  • Обновите Ubuntu до версии 14.04.
  • Обновление Ubuntu 14.04 до Ubuntu 16.04
  • Перенесите данные сервера в поддерживаемую версию.

Причина:

Смотрите вместо этого:

Введение

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

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

Предположим, что у вас есть настроенный сервер Ansible и несколько клиентов, как мы и остановились в предыдущем уроке. В нашем руководстве сервер — это машина с Ubuntu 12.04, и клиенты, которые мы собираемся настраивать, также являются машинами с Ubuntu 12.04, для простоты объяснения.

Что такое Ansible Playbook?

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

Плейбуки Ansible написаны в формате сериализации данных YAML. Если вы не знаете, что такое формат сериализации данных, подумайте о нем как о способе перевода программной структуры данных (списков, массивов, словарей и т. д.) в формат, который можно легко сохранить на диск. Затем файл можно использовать для воссоздания структуры позднее. JSON — еще один популярный формат сериализации данных, но YAML намного легче читать.

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

Изучение базовой книги игр

Давайте посмотрим на базовую книгу игр:

---
- hosts: droplets
  tasks:
    - name: Installs nginx web server
      apt: pkg=nginx state=installed update_cache=true
      notify:
        - start nginx

  handlers:
    - name: start nginx
      service: name=nginx state=started

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

Файл начинается с:

---

Это требование для YAML, чтобы интерпретировать файл как правильный документ. YAML допускает существование нескольких «документов» в одном файле, каждый из которых разделен ---, но Ansible хочет только один документ для каждого файла, поэтому он должен присутствовать только в верхней части файла.

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

Элементы, начинающиеся с -, считаются элементами списка. Элементы в формате ключ:значение работают как хэши или словари. Это почти все, что есть в базовом YAML.

Документы YAML в основном определяют иерархическую древовидную структуру с элементами, расположенными дальше слева.

Во второй строке имеем следующее:

---
- hosts: droplets

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

Далее у нас есть набор задач:

---
- hosts: droplets
  tasks:
    - name: Installs nginx web server
      apt: pkg=nginx state=installed update_cache=true
      notify:
        - start nginx

На верхнем уровне у нас есть \tasks: на том же уровне, что и \hosts:. Он содержит список (поскольку он начинается с \-), который содержит пары ключ-значение.

Первый, \имя, является скорее описанием, чем именем. Вы можете называть его как хотите.

Следующий ключ — «apt». Это ссылка на модуль Ansible, точно так же, как когда мы используем команду ansible и вводим что-то вроде:

ansible -m apt -a 'whatever' all

Этот модуль позволяет нам указать пакет и состояние, в котором он должен быть, которое в нашем случае «установлено». Часть update-cache=true сообщает нашей удаленной машине обновить кэш пакетов. (apt-get update) перед установкой программного обеспечения.

Пункт «уведомить» содержит список с одним пунктом, который называется «запустить nginx». Это не внутренняя команда Ansible, это ссылка на обработчик, который может выполнять определенные функции при вызове из задачи. Ниже мы определим обработчик «start nginx».

---
- hosts: droplets
  tasks:
    - name: Installs nginx web server
      apt: pkg=nginx state=installed update_cache=true
      notify:
        - start nginx

  handlers:
    - name: start nginx
      service: name=nginx state=started

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

Например, у нас есть обработчик, который запускает службу Nginx после установки пакета. Обработчик не вызывается, если только задача «Установка веб-сервера nginx» не приводит к изменениям в системе, что означает, что пакет должен быть установлен, а его еще нет.

Мы можем сохранить этот плейбук в файл с именем что-то вроде \nginx.yml.

Просто для некоторого контекста, если бы вы написали тот же файл в формате JSON, он мог бы выглядеть примерно так:

[
    {
        "hosts": "droplets",
        "tasks": [
            {
                "name": "Installs nginx web server",
                "apt": "pkg=nginx state=installed update_cache=true",
                "notify": [
                    "start nginx"
                ]
            }
        ],
        "handlers": [
            {
                "name": "start nginx",
                "service": "name=nginx state=started"
            }
        ]
    }
]

Как видите, YAML намного компактнее, и большинство людей сказали бы, что он более удобочитаем.

Запуск Ansible Playbook

После того, как вы создали плейбук, вы можете легко вызвать его, используя этот формат:

<пред>

Например, если мы хотим установить и запустить Nginx на всех наших дроплетах, мы можем ввести эту команду:

ansible-playbook nginx.yml

Поскольку сам плейбук указывает хосты, на которых он должен работать (а именно, группа «дроплетов», которую мы создали в последнем уроке), нам не нужно указывать хост для запуска.

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

<пред>

Итак, если бы мы хотели установить и запустить Nginx только на нашем «host3», мы могли бы ввести это:

ansible-playbook -l host3 nginx.yml

Добавление функций в Playbook

Сейчас наша игровая книга выглядит так:

---
- hosts: droplets
  tasks:
    - name: Installs nginx web server
      apt: pkg=nginx state=installed update_cache=true
      notify:
        - start nginx

  handlers:
    - name: start nginx
      service: name=nginx state=started

Это просто и работает, но все, что он делает, это устанавливает часть программного обеспечения и запускает его. Само по себе это не очень выгодно.

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

Добавить индексный файл по умолчанию

Мы можем сказать ему передать файл с нашего сервера Ansible на хост, добавив несколько строк, подобных этой:

<пред>

  • хост: капельки задания:
    • имя: устанавливает веб-сервер nginx. apt: pkg=nginx state=установлен update_cache=true поставить в известность:
      • запустить nginx

      - name: Загрузить index.html по умолчанию для хоста

      обработчики:

      Затем мы можем создать каталог с именем static_files в нашем текущем каталоге и поместить внутрь файл index.html.

      mkdir static_files
      nano static_files/index.html
      

      Внутри этого файла давайте просто создадим базовую HTML-структуру:

      <html>
        <head>
          <title>This is a sample page</title>
        </head>
        <body>
          <h1>Here is a heading!</h1>
          <p>Here is a regular paragraph.  Wow!</p>
        </body>
      </html>
      

      Сохраните и закройте файл.

      Теперь, когда мы перезапустим плейбук, Ansible проверит каждую задачу. Он увидит, что Nginx уже установлен на хосте, поэтому оставит его в покое. Он увидит новый раздел задач и заменит файл index.html по умолчанию файлом с нашего сервера.

      Регистрация результатов

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

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

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

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

      Например, мы могли бы указать нашему плейбуку загрузить файл index.php, если он существует. Если эта задача не удалась, мы могли бы вместо этого попытаться загрузить файл index.html. Мы проверим состояние сбоя в другой задаче, потому что мы хотим загрузить файл HTML только в случае сбоя файла PHP:

      <пред>

      • хосты: капли задания:
        • имя: устанавливает веб-сервер nginx. apt: pkg=nginx state=установлен update_cache=true поставить в известность:
          • запустить nginx

          - имя: Загрузить index.php по умолчанию для хоста

          - name: Удалить index.html для хоста

          • имя: Загрузить index.html по умолчанию для хоста копия: src=static_files/index.html dest=/usr/share/nginx/www/mode=0644 когда: php|сбой

          обработчики:

          • имя: запустить nginx служба: name=nginx state=started

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

          Эта новая версия пытается загрузить индексный файл PHP на хост. Он регистрирует успех операции в переменной с именем \php.

          Если эта операция прошла успешно, далее запускается задача по удалению файла index.html.

          Если операция не удалась, вместо нее загружается файл index.html.

          Заключение

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

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

          Джастин Эллингвуд