Почему в ansible мы не можем полностью использовать декларативный подход во всех плейбуках?

Компромисс между декларативностью и императивностью в Ansible

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

Ограничения декларативного подхода в Ansible

• Декларативность реализована на уровне отдельных модулей, а не всей системы. Например, модуль file декларативен: вы указываете state: directory, и Ansible сам решает, нужно ли создавать каталог.

  - name: Ensure directory exists
    ansible.builtin.file:
      path: /etc/myapp
      state: directory
      mode: '0755'
  

• Последовательность выполнения (control flow) остаётся императивной. Задачи в плейбуке выполняются строго сверху вниз, и вы явно управляете этим потоком с помощью директив when, failed_when, changed_when, block, rescue. Это императивное программирование.

  - name: Install package (декларативная задача)
    ansible.builtin.apt:
      name: nginx
      state: present
  
  - name: Start service (декларативная задача)
    ansible.builtin.systemd:
      name: nginx
      state: started
    when: ansible_facts['os_family'] == "Debian" # Императивное условие
  

Причины, по которым полностью декларативный подход невозможен

1. Обработка исключений и сложной логики. Реальные инфраструктурные задачи требуют ветвления, циклов и обработки ошибок.

    *   Чисто декларативные системы (например, Terraform для provisioning) плохо справляются с внутрисерверной конфигурацией, требующей условных действий.
    *   В Ansible вы используете **императивные конструкции** в Jinja2-шаблонах и условиях.

1. Работа с состоянием (state) приложений. Декларативный подход идеален для ресурсов с чётким жизненным циклом (файл, пакет, служба). Но многие операции (миграция БД, переключение трафика, обработка данных) — это процессы, а не состояния. Для них нужны императивные шаги.

   - name: Run database migration (императивный шаг)
     ansible.builtin.command: /app/bin/migrate
     changed_when: "'Success' in migration_result.stdout"
     register: migration_result
   

2. Отсутствие единой модели желаемого состояния. В отличие от Terraform, который строит граф ресурсов и вычисляет план изменений для всей системы, Ansible не хранит полное состояние инфраструктуры. Он применяет декларации последовательно к каждому хосту. Невозможно декларативно описать взаимозависимые изменения на множестве серверов в одной транзакции.

3. Философия «батарейки в комплекте». Ansible жертвует «чистой» декларативностью ради простоты использования и мощных возможностей. Модули command, shell, raw — чисто императивные, но они необходимы для ситуаций, где нет подходящего декларативного модуля. Это сознательное решение.

4. Идемпотентность — ключ, а не декларативность. Основная цель Ansible — обеспечить идемпотентность (многократное выполнение даёт один результат). Это достигается не только декларативными модулями, но и правильным использованием changed_when, failed_when.

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

Важно понимать эту двойственную природу Ansible:

• Стремитесь к декларативности на уровне задач: используйте специализированные модули (copy, template, service, uri), а не command/shell.
• Используйте императивные конструкции для управления потоком выполнения: это нормально и необходимо. Разница в том, где применяется логика: в модели состояния (декларация) или в порядке действий (императивный flow).
• Используйте преимущества обоих подходов:

  - name: Deploy application (декларативная часть)
    ansible.builtin.copy:
      src: /tmp/app.war
      dest: /opt/tomcat/webapps/
      owner: tomcat
    notify: "Restart Tomcat" # Декларативный триггер
  
  - name: Check if new feature is enabled in DB (императивная проверка)
    ansible.builtin.shell: "mysql -NBe 'SELECT flag FROM features WHERE id=10'"
    register: db_flag
    changed_when: false
  
  - name: Enable feature in config (декларативное действие после императивной проверки)
    ansible.builtin.lineinfile:
      path: /etc/app/config.properties
      regexp: '^feature.enable='
      line: 'feature.enable={{ "true" if "1" in db_flag.stdout else "false" }}'
    when: db_flag is succeeded
  

Таким образом, Ansible — это гибридный инструмент с декларативной идеологией, но императивной реализацией потока выполнения. Его сила именно в этом компромиссе: он предоставляет высокоуровневые декларативные абстракции для типовых операций, но не лишает инженера возможности опускаться на императивный уровень, когда это требуется для сложной бизнес-логики или интеграций.