История изменений

Вот на счет ролей не скажу - я так и не въехал какой профит от них, для меня это как раз лишняя сущность, которая при этом еще и жестко прибита к именам файлов и каталогов, в общем мне не нравится.

В итоге использование ansible сводится к первичной конфигурации хоста.

Я не согласен вот с этим - прекрасно использую Ansible для поддержания и управлением существующими хостами. Хотя да, из официальной документации и best practice видно что используют его как раз таки для «развернуть определенное ПО на виртуалках амазона и пользоваться».

У меня нет сценариев, завязанных на хосты (вот те же роли как раз таки и завязываются на хосты, хотя тоже не сильно, тоже больше компонентый подход, но с учетом того что все хосты с определенным компонентом сконфигурированы одинаково) - у меня идет привязка именно к «компонентам». Есть компонент (ну или абстракция) «конфиги» - есть сценарий который работает с файлами - он может копировать готовые файлы и работать с шаблонами, выставлять права, проверять существования файлов, проверять ссылки и так далее. Объединив это с vcs получаем «тулзу», которая сможет в случае факапа сконфигурировать любой хост, сможет проверять валидность конфигов на серверах и в то же время у нас есть бэкап конфигурации, история изменений и прочие плюшки. Другой компонент - скажем это «приложения» - сценарий для того чтоб этими приложениями управлять - включать\выключать, проверять состояние и я даже не знаю что тут еще можно придумать. В обоих «абстракциях» сценарии к хостам никак не привязаны, просто в первом случае мы берем список файлов из inventory, во втором - команды для запуска и остановки приложений и так далее из того же inventory. В итоге через некоторое время использования таких скриптов просто забываешь где у тебя там что на хосте лежит и как управляется - надо внести правки в конфиг - закоммитил в vcs и запустил сценарий, откатиться - опять же это пара команд в vcs и запуск сценария. Надо погасить всю среду или часть - запустил другой сценарий, запустить - опять этот же сценарий но с другим тэгом, и при всем при этом ты не паришься что у тебя на хостах 1 и 2 стоят nginx и апач и управляются инитскриптами, на хосте 3 крутится бд с управлением через systemd а на 4 хосте вообще скрипт на питоне, которые останавливается через pkill -9 myscript.py. Надо поправить сам список команд или файлов - правишь только нужный инвентарь.

А от проверки «руками» (или какими-то автоматизированными средствами) ты не уйдешь в любом случае - не важно, доставляешь ли ты изменения руками или делаешь правки на месте, или же используешь оркестратор.

А про то что проще сделать на хосте, чем мучаться с какой-то там vcs с последующей доставкой изменений или просто сценариями - может и так, когда на одном хосте что-то надо сделать, но когда у тебя как раз таки сложная система из сотни разных хостов и надо что-то сделать одновременно - имхо проще поручить слежение за тем где у тебя какой конфиг лежит и в каком состоянии как раз оркестратору, а самому только вносить правки в этот конфиг, не задумываясь о доставке, бэкапах и прочем.

Вот на счет ролей не скажу - я так и не въехал какой профит от них, для меня это как раз лишняя сущность, которая при этом еще и жестко прибита к именам файлов и каталогов, в общем мне не нравится.

В итоге использование ansible сводится к первичной конфигурации хоста.

Я не согласен вот с этим - прекрасно использую Ansible для поддержания и управлением существующими хостами. Хотя да, из официальной документации и best practice видно что используют его как раз таки для «развернуть определенное ПО на виртуалках амазона и пользоваться».

У меня нет сценариев, завязанных на хосты (вот те же роли как раз такие) - у меня идет привязка именно к «компонентам». Есть компонент (ну или абстракция) «конфиги» - есть сценарий который работает с файлами - он может копировать готовые файлы и работать с шаблонами, выставлять права, проверять существования файлов, проверять ссылки и так далее. Объединив это с vcs получаем «тулзу», которая сможет в случае факапа сконфигурировать любой хост, сможет проверять валидность конфигов на серверах и в то же время у нас есть бэкап конфигурации, история изменений и прочие плюшки. Другой компонент - скажем это «приложения» - сценарий для того чтоб этими приложениями управлять - включать\выключать, проверять состояние и я даже не знаю что тут еще можно придумать. В обоих «абстракциях» сценарии к хостам никак не привязаны, просто в первом случае мы берем список файлов из inventory, во втором - команды для запуска и остановки приложений и так далее из того же inventory. В итоге через некоторое время использования таких скриптов просто забываешь где у тебя там что на хосте лежит и как управляется - надо внести правки в конфиг - закоммитил в vcs и запустил сценарий, откатиться - опять же это пара команд в vcs и запуск сценария. Надо погасить всю среду или часть - запустил другой сценарий, запустить - опять этот же сценарий но с другим тэгом, и при всем при этом ты не паришься что у тебя на хостах 1 и 2 стоят nginx и апач и управляются инитскриптами, на хосте 3 крутится бд с управлением через systemd а на 4 хосте вообще скрипт на питоне, которые останавливается через pkill -9 myscript.py. Надо поправить сам список команд или файлов - правишь только нужный инвентарь.

А от проверки «руками» (или какими-то автоматизированными средствами) ты не уйдешь в любом случае - не важно, доставляешь ли ты изменения руками или делаешь правки на месте, или же используешь оркестратор.

А про то что проще сделать на хосте, чем мучаться с какой-то там vcs с последующей доставкой изменений или просто сценариями - может и так, когда на одном хосте что-то надо сделать, но когда у тебя как раз таки сложная система из сотни разных хостов и надо что-то сделать одновременно - имхо проще поручить слежение за тем где у тебя какой конфиг лежит и в каком состоянии как раз оркестратору, а самому только вносить правки в этот конфиг, не задумываясь о доставке, бэкапах и прочем.