Какой подход использует ansible, декларативный или императивный?

Декларативный подход Ansible: Сущность и его проявления

Ansible в своей основе придерживается декларативной (описательной) парадигмы, и это является одним из его ключевых философских и архитектурных принципов. Это означает, что в плейбуках и ролях вы описываете желаемое состояние целевой системы (например, "пакет nginx должен быть установлен и служба запущена"), а не предписываете точную последовательность команд для достижения этого состояния ("выполни apt-get install, затем отредактируй файл конфигурации, потом выполни systemctl start").

Ключевые аспекты декларативной природы Ansible

1. Идемпотентность (Idempotence) — фундаментальное следствие декларативного подхода. Вы можете запускать один и тот же плейбук многократно, и результат после первого успешного применения всегда будет одинаков: система приведется к описанному состоянию, а если она уже в нем находится, то изменений не произойдет (за исключением задач, явно помеченных как changed_when: false). Это реализуется внутри модулей Ansible.

   # Декларативное описание: "Сервис nginx должен быть запущен"
   - name: Ensure nginx is running
     ansible.builtin.service:
       name: nginx
       state: started
     # При первом запуске задача изменит состояние (стартует службу).
     # При повторном запуске задача будет иметь статус OK (состояние уже достигнуто).
   

2. Реализация через модули (Modules): Декларативность обеспечивается "интеллектом" модулей. Вы передаете модулю параметры, описывающие цель, а он сам решает, какие действия (если они вообще нужны) выполнить на целевом хосте. Например, модуль ansible.builtin.copy сначала вычисляет контрольную сумму файла, и копирование происходит только если файлы различаются.

3. Отсутствие явного потока управления: В идеальном декларативном плейбуке вы не управляете циклом "если-то". Вместо этого вы используете конструкции, которые сами по себе являются декларациями.

   # Более императивный, "скриптовый" подход (не лучшая практика в Ansible):
   - name: Check if file exists
     ansible.builtin.stat:
       path: /etc/nginx/nginx.conf
     register: file_stat
   - name: Create config if missing
     ansible.builtin.template:
       src: nginx.conf.j2
       dest: /etc/nginx/nginx.conf
     when: not file_stat.stat.exists # Явная условная проверка
   
   # Более декларативный, идиоматичный для Ansible подход:
   - name: Ensure nginx config is present
     ansible.builtin.template: # Модуль template сам по себе идемпотентен.
       src: nginx.conf.j2
       dest: /etc/nginx/nginx.conf
     # Условие здесь часто излишне, так как модуль не будет менять файл, если он уже соответствует шаблону.
   

Наличие императивных элементов

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

• Модуль ansible.builtin.command и ansible.builtin.shell: Это явно императивные модули. Они выполняют переданную команду "как есть", каждый раз, когда задача запускается, и не могут проверить, достигнуто ли желаемое состояние. Их использование требует от инженера явного управления идемпотентностью (через creates, removes или changed_when).

  # Императивная задача. Будет выполняться всегда, если не добавить условие.
  - name: Run database migration script
    ansible.builtin.command: /opt/app/migrate.sh
    args:
      creates: /opt/app/.migrated # Императивная проверка для имитации идемпотентности
  

• Конструкции управления потоком: Директивы when, failed_when, changed_when, loop, until и блоки rescue/always вносят элементы процедурного программирования, позволяя реагировать на условия, которые сложно описать чисто декларативно.

• Стратегия выполнения (Strategy): По умолчанию Ansible использует стратегию linear (линейное выполнение задач по очереди на всех хостах). Но стратегия free или явное использование async позволяют перейти к более императивной модели управления порядком выполнения.

Практический вывод и баланс

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

Императивные приемы используются осознанно там, где декларативный подход недостаточен: для запуска одноразовых скриптов, сложных проверок, обработки ситуаций, не охватываемых стандартными модулями. Задача DevOps-инженера — стремиться к максимально декларативному стилю, используя императивные конструкции только при необходимости, чтобы сохранить преимущества идемпотентности и простоты поддержки кодовой базы Ansible.

Таким образом, подход Ansible можно охарактеризовать как "декларативный по дизайну, с прагматичными императивными расширениями для реальных задач".