Пример настройки Ansible

Вы изучили плейбуки, инвентаризацию, роли и переменные. В этом разделе все эти элементы объединяются, описывая пример настройки для автоматизации веб-сервиса. Вы можете найти больше примеров плейбуков, иллюстрирующих эти шаблоны, в нашем репозитории ansible-examples. (ПРИМЕЧАНИЕ: они могут не использовать все функции последней версии, но по-прежнему являются отличной ссылкой!).

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

• Пример структуры каталогов
• Альтернативная структура каталогов
• Пример переменных групп и хостов
• Пример плейбуков, организованных по функциям
• Пример файлов задач и обработчиков в роли на основе функций
• Возможности примерной настройки
• Организация для развертывания или настройки
• Использование локальных модулей Ansible

Пример структуры каталогов

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

production                # inventory file for production servers
staging                   # inventory file for staging environment

group_vars/
   group1.yml             # here we assign variables to particular groups
   group2.yml
host_vars/
   hostname1.yml          # here we assign variables to particular systems
   hostname2.yml

library/                  # if any custom modules, put them here (optional)
module_utils/             # if any custom module_utils to support modules, put them here (optional)
filter_plugins/           # if any custom filter plugins, put them here (optional)

site.yml                  # master playbook
webservers.yml            # playbook for webserver tier
dbservers.yml             # playbook for dbserver tier
tasks/                    # task files included from playbooks
    webservers-extra.yml  # <-- avoids confusing playbook with task files

roles/
    common/               # this hierarchy represents a "role"
        tasks/            #
            main.yml      #  <-- tasks file can include smaller files if warranted
        handlers/         #
            main.yml      #  <-- handlers file
        templates/        #  <-- files for use with the template resource
            ntp.conf.j2   #  <------- templates end in .j2
        files/            #
            bar.txt       #  <-- files for use with the copy resource
            foo.sh        #  <-- script files for use with the script resource
        vars/             #
            main.yml      #  <-- variables associated with this role
        defaults/         #
            main.yml      #  <-- default lower priority variables for this role
        meta/             #
            main.yml      #  <-- role dependencies
        library/          # roles can also include custom modules
        module_utils/     # roles can also include custom module_utils
        lookup_plugins/   # or other types of plugins, like lookup in this case

    webtier/              # same kind of structure as "common" was above, done for the webtier role
    monitoring/           # ""
    fooapp/               # ""

Альтернативная структура каталогов

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

inventories/
   production/
      hosts               # inventory file for production servers
      group_vars/
         group1.yml       # here we assign variables to particular groups
         group2.yml
      host_vars/
         hostname1.yml    # here we assign variables to particular systems
         hostname2.yml

   staging/
      hosts               # inventory file for staging environment
      group_vars/
         group1.yml       # here we assign variables to particular groups
         group2.yml
      host_vars/
         stagehost1.yml   # here we assign variables to particular systems
         stagehost2.yml

library/
module_utils/
filter_plugins/

site.yml
webservers.yml
dbservers.yml

roles/
    common/
    webtier/
    monitoring/
    fooapp/

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

Пример переменных групп и хостов

В этих образцах файлов переменных групп и хостов записываются значения переменных, которые применяются к каждой машине или группе машин. Например, в дата-центре в Атланте есть свои собственные NTP-серверы, поэтому при настройке ntp.conf мы должны использовать их:

---
# file: group_vars/atlanta
ntp: ntp-atlanta.example.com
backup: backup-atlanta.example.com

Аналогично, веб-серверы имеют некоторые настройки, которые не применяются к серверам базы данных:

---
# file: group_vars/webservers
apacheMaxRequestsPerChild: 3000
apacheMaxClients: 900

Значения по умолчанию или значения, которые являются универсальными, должны находиться в файле group_vars/all:

---
# file: group_vars/all
ntp: ntp-boston.example.com
backup: backup-boston.example.com

При необходимости можно определить конкретные отличия оборудования систем в файле host_vars:

---
# file: host_vars/db-bos-1.example.com
foo_agent_port: 86
bar_agent_port: 99

Опять же, если вы используете динамическую инвентаризацию, Ansible автоматически создает множество динамических групп. Таким образом, такой тег, как «class:webserver», автоматически загрузит переменные из файла «group_vars/ec2_tag_class_webserver».

Пример плейбуков, организованных по функциям

В этой настройке один плейбук может определять всю инфраструктуру. Плейбук site.yml импортирует два других плейбука, один для веб-серверов и один для серверов базы данных:

---
# file: site.yml
- import_playbook: webservers.yml
- import_playbook: dbservers.yml

Файл webservers.yml, также на верхнем уровне, сопоставляет конфигурацию группы веб-серверов с ролями, связанными с группой веб-серверов:

---
# file: webservers.yml
- hosts: webservers
  roles:
    - common
    - webtier

С этой настройкой вы можете настроить всю инфраструктуру, «запустив» site.yml, или запустить подмножество, запустив webservers.yml. Это аналогично параметру Ansible «–limit», но немного более явно:

ansible-playbook site.yml --limit webservers
ansible-playbook webservers.yml

Пример файлов задач и обработчиков в роли на основе функций

Ansible загружает любой файл, называемый main.yml в подкаталоге роли. Этот пример tasks/main.yml файл прост — он настраивает NTP, но мог бы делать больше, если бы мы захотели:

---
# file: roles/common/tasks/main.yml

- name: be sure ntp is installed
  yum:
    name: ntp
    state: present
  tags: ntp

- name: be sure ntp is configured
  template:
    src: ntp.conf.j2
    dest: /etc/ntp.conf
  notify:
    - restart ntpd
  tags: ntp

- name: be sure ntpd is running and enabled
  service:
    name: ntpd
    state: started
    enabled: yes
  tags: ntp

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

---
# file: roles/common/handlers/main.yml
- name: restart ntpd
  service:
    name: ntpd
    state: restarted

См. Роли для получения дополнительной информации.

Возможности примерной настройки

Базовая организационная структура, описанная выше, обеспечивает множество вариантов автоматизации. Для повторной настройки всей инфраструктуры:

ansible-playbook -i production site.yml

Для повторной настройки NTP для всего:

ansible-playbook -i production site.yml --tags ntp

Для повторной настройки только веб-серверов:

ansible-playbook -i production webservers.yml

Для повторной настройки только веб-серверов в Бостоне:

ansible-playbook -i production webservers.yml --limit boston

Для повторной настройки только первых 10 веб-серверов в Бостоне, а затем следующих 10:

ansible-playbook -i production webservers.yml --limit boston[0:9]
ansible-playbook -i production webservers.yml --limit boston[10:19]

Примерная настройка также поддерживает базовые ад-хок команды:

ansible boston -i production -m ping
ansible boston -i production -m command -a '/sbin/reboot'

Для выяснения, какие задачи будут запущены или какие имена хостов будут затронуты конкретной командой Ansible:

# confirm what task names would be run if I ran this command and said "just ntp tasks"
ansible-playbook -i production webservers.yml --tags ntp --list-tasks

# confirm what hostnames might be communicated with if I said "limit to boston"
ansible-playbook -i production webservers.yml --limit boston --list-hosts

Организация для развертывания или настройки

Примерная настройка моделирует типичную топологию конфигурации. При выполнении развертывания многоуровневых приложений будут добавлены дополнительные плейбуки, которые переходят между уровнями, чтобы развернуть приложение. В этом случае ‘site.yml’ может быть дополнен плейбуками, такими как ‘deploy_exampledotcom.yml’, но общие концепции по-прежнему применимы. Ansible позволяет развертывать и настраивать с помощью одного инструмента, поэтому вы, вероятно, будете повторно использовать группы и сохранять настройки ОС в отдельных плейбуках или ролях, отличных от развертывания приложения.

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

Использование локальных модулей Ansible

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