Какие знаешь этапы работы Ansible?

Этапы работы Ansible

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

1. Анализ инвентаря (Inventory Parsing)

Первым делом Ansible загружает файл инвентаря — статический (inventory.ini) или динамический скрипт. Инвентарь определяет, на каких узлах (hosts) и в каких группах будут выполняться задачи. Динамический инвентарь особенно важен в облачных средах, где список машин может постоянно меняться.

# Пример статического инвентаря (inventory.ini)
[webservers]
web1.example.com ansible_user=admin
web2.example.com ansible_ssh_private_key_file=~/keys/web2.pem

[dbservers]
db.example.com ansible_user=root

2. Сбор фактов (Gathering Facts)

Если этап не отключен (с помощью gather_facts: false), Ansible подключается к целевым узлам по SSH (для Linux) или WinRM (для Windows) и собирает информацию о системе — facts. Это данные об ОС, сетевых интерфейсах, памяти, дисках и т.д. Они хранятся в переменных и могут использоваться в задачах для условного выполнения.

# Пример использования факта в задаче
- name: Restart Apache on Debian-based systems
  ansible.builtin.service:
    name: apache2
    state: restarted
  when: ansible_facts['os_family'] == "Debian"

3. Компиляция и обработка плейбука (Playbook Compilation)

Ansible загружает плейбук (playbook) — YAML-файл, содержащий plays, которые, в свою очередь, содержат tasks. На этом этапе происходит:

• Проверка синтаксиса YAML.
• Загрузка и проверка ролей (roles), если они указаны. Роли — это способ структурировать и переиспользовать задачи, переменные, шаблоны и файлы.
• Интерпретация директив (directives), таких как vars, handlers, become (привилегированное выполнение).

4. Выполнение задач (Task Execution)

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

# Пример задач в плейбуке
- name: Ensure nginx is installed
  ansible.builtin.package:
    name: nginx
    state: present

- name: Ensure nginx service is running and enabled
  ansible.builtin.service:
    name: nginx
    state: started
    enabled: yes

- name: Deploy nginx configuration template
  ansible.builtin.template:
    src: templates/nginx.conf.j2
    dest: /etc/nginx/nginx.conf
  notify: Restart nginx # Запускает handler, если задача изменила состояние системы

5. Обработка обработчиков (Handlers Execution)

Обработчики (handlers) — это специальные задачи, которые выполняются один раз в конце play, и только если какая-либо из обычных задач уведомила (notify) о необходимости их запуска. Обычно используются для перезапуска служб после изменения конфигурации, как в примере выше (Restart nginx). Это предотвращает множественные ненужные перезагрузки.

6. Завершение и формирование отчета (Completion and Reporting)

После выполнения всех задач и обработчиков Ansible разрывает соединения и формирует сводный отчет (play recap). В нем указывается статус выполнения для каждого узла: OK (состояние уже соответствовало желаемому), CHANGED (состояние было изменено), FAILED (ошибка), UNREACHABLE (узел недоступен) или SKIPPED (условие when не выполнено).

PLAY RECAP *********************************************************************
web1.example.com        : ok=5    changed=2    unreachable=0    failed=0    skipped=1    rescued=0    ignored=0
db.example.com          : ok=3    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Дополнительные аспекты архитектуры

• Соединение и транспортировка: Основной транспорт — SSH, что не требует установки агентов на управляемые узлы. Используется параллельное выполнение (параметр fork), управляемое контроллером.
• Использование Jinja2: Перед выполнением все шаблоны (*.j2) и многие значения в плейбуках обрабатываются движком шаблонов Jinja2, что позволяет динамически генерировать конфигурационные файлы на основе переменных и фактов.
• Работа с переменными: Ansible имеет строгий порядок приоритета переменных, начиная от значений по умолчанию в ролях и заканчивая переменными, переданными через командную строку (-e).
• Теги (Tags): Позволяют выборочно запускать подмножества задач, что критически важно в больших плейбуках.

Эти этапы обеспечивают предсказуемость, надежность и повторяемость операций, что является фундаментом для инфраструктуры как кода (Infrastructure as Code) и практик DevOps. Понимание каждого этапа позволяет эффективно отлаживать плейбуки, оптимизировать время выполнения (например, отключая сбор фактов, где не нужен) и строить сложные, поддерживаемые автоматизированные рабочие процессы.