Идемпотентность
Тема дорожной карты · Ansible
Идемпотентность в Ansible означает, что многократный запуск playbook на одном и том же хосте приводит к тому же конечному состоянию, что и однократный, при этом Ansible вносит изменения только тогда, когда текущее состояние отличается от желаемого. Большинство встроенных модулей Ansible идемпотентны по своей конструкции — модуль file с state: directory создаёт каталог только если он отсутствует, модуль package устанавливает пакет только если он ещё не установлен, а service изменяет состояние службы только когда оно отличается от запрошенного. Идемпотентность делает playbook Ansible безопасными для применения в CI-конвейерах, заданиях cron или рабочих процессах исправления дрейфа конфигурации без риска нежелательных побочных эффектов. При использовании модулей command или shell, не являющихся идемпотентными по природе, параметры creates, removes, changed_when и when позволяют авторам явно объявить условия, при которых задача должна считаться no-op, восстанавливая идемпотентное поведение.
Как это работает
Идемпотентность — agentless инструмент управления конфигурацией: control-node ходит по SSH (или WinRM/local) на целевые хосты и гоняет модули, сводящие состояние. Конфиг — YAML-плейбуки; задачи зовут модули (apt, copy, service, template, user, file); модули идемпотентны — два запуска дают тот же результат. Inventory описывает таргеты; переменные параметризуют поведение. Ansible — push-based (вы триггерите с control-node); сравните с Puppet/Chef (pull-based).
Когда применять
Ansible — когда нужно настраивать существующие серверы (применять OS-настройки, деплоить приложения, управлять юзерами), не когда нужно провижионить новую cloud-инфраструктуру (Terraform лучше). Для эфемерных cattle-серверов — immutable-образы (Packer) + Terraform; Ansible хорош на долгоживущих pet. Для маленьких флотов — проще Salt/Puppet/Chef; для тысяч хостов SSH-модель может стать тесной.
Типичные ошибки
Ловушки Идемпотентность: пишут Ansible как shell-скрипты (command: / shell: повсюду — убивает идемпотентность, используйте реальные модули); запуск плейбуков с ноута в production (нет аудита — запускайте из CI-раннера или AWX); не запиннены версии collection/role; запуск против prod без --check --diff сначала (dry-run ваш друг).