Накипело. Playbook "идемпотентный" ровно до первого shell или command модуля. Половина наших ролей утыкана костылями changed_when: false. Кто как с этим живёт, или уже сбежали на что-то другое?
✔ Лучший ответ сформирован автоматически — rojo7509
У нас перелом наступил, когда перестали полагаться на сознательность и внесли ansible-lint в CI с жёсткими правилами: shell без creates, removes или changed_when просто не проходит пайплайн. Первые две недели команда ныла, потом костыли кончились сами собой — оказалось, что под половину «уникальных» шеллов давно есть штатные модули, просто никто не искал. Дисциплина, которую проверяет робот…
shell/command по дизайну не идемпотентны, это ТВОЯ задача описать им creates/removes или нормальный changed_when. Если весь плейбук на shell — виноват не Ansible, его просто готовят как обёртку над bash.
Справедливо. Но когда готового модуля под задачу нет, выбор между кривым shell и написанием своего модуля на питоне. На дедлайне понятно что выберет живой человек.
Мы для серверов ушли на immutable: Packer печёт золотой образ, выкатываем его целиком. Конфиг-менеджмент в рантайме почти не нужен, дрифта нет by design.
Это прекрасно работает пока инфра однородная. У нас зоопарк из легаси-железа и виртуалок, на всё это Packer не натянешь. Там Ansible пока безальтернативен.
А ещё Ansible тормозной на сотнях хостов. SSH по очереди, крутили forks, прикручивали mitogen — всё равно полный прогон 40 минут. Частично спас переход на pull-модель через ansible-pull.
Salt заметно быстрее на тысячах хостов, но порог входа выше и комьюнити меньше. Для 50-200 хостов Ansible выигрывает по простоте. От 2000+ — да, есть смысл смотреть в сторону Salt.
Идемпотентность это не свойство Ansible, это дисциплина того кто пишет роли. Видел идеально идемпотентные плейбуки и видел Terraform который руками доламывали в консоли. Инструмент не лечит криворукость.
