Пример настройки 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                  # main 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. Это отличный способ сохранения модулей, идущих вместе с плейбуком. Это показано в примере структуры каталога в начале этого раздела.