Пример конфигурации Ansible

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

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

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

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

---
# 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 автоматически.

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

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

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

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

---
# 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

Для переконфигурации только webservers:

ansible-playbook -i production webservers.yml

Для переконфигурации только webservers в Бостоне:

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

Для переконфигурации только первых 10 webservers в Бостоне, а затем следующих 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

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

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

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

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

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