Пример настройки 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 and optional Galaxy info
        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
  ansible.builtin.service:
    name: ntpd
    state: started
    enabled: true
  tags: ntp

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

---
# file: roles/common/handlers/main.yml
- name: restart ntpd
  ansible.builtin.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

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