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

Push-модель с ростом единиц обслуживаемой техники стремительно перестаёт скалироваться. Pull-модель продолжает работать как работала. При чём в моём случае есть некое n серверов ... с медленным и ненадёжным доступом.
Ещё юз-кейс: юниты с непредсказуемым эпизодическим доступом к сети или вообще без такового (лаптопы, промышленное оборудование без доступа к публичным сетям итп).

ansible-pull позволяет использовать pull-модель, но гибкости в нём маловато.

Далее, не каждый сервер готов в данный момент времени принять обновления.

Аргумент. Ну тут у меня просто: всё критичное имеет горячий резерв, так что для серьёзных обновлений делаем часть серверов неактивными, обновляем, включаем обратно, переходим к следующей части. Несерьёзные наживую можно катить.

Ещё один юз-кейс: упавший SSH. Такое бывает, причин для этого вагон и маленькая тележка, уверен, что если ты не сталкивался ещё с этим, то обязательно столкнёшься.

Он автоматом перезапускаеся при падении. И upstart и systemd это умеют, к sysv прикручивается supervisord и прочие костыли. Ну а если уж так падает, что перезапуститься не может, будем считать хост сбойным и лезть внутрь аварийными средствами - IPMI для физического хоста, для виртуалки - прицепить диск к другому инстансу и смотреть.

У меня есть юниты вообще без SSH-сервера и пользователей с паролями, при этом они успешно обслуживаются при помощи CFEngine и предоставляют доступ через публичную сеть.

Сложность поставить и нормально настроить ssh или специальный демон для cfengine вполне сравнима, ИМХО не аргумент.

А Ansible удобно использовать для других вещей.

Пока в ограничения ansible серьёзно не упирался, но в общем верю.

Push-модель с ростом единиц обслуживаемой техники стремительно перестаёт скалироваться. Pull-модель продолжает работать как работала. При чём в моём случае есть некое n серверов ... с медленным и ненадёжным доступом.
Ещё юз-кейс: юниты с непредсказуемым эпизодическим доступом к сети или вообще без такового (лаптопы, промышленное оборудование без доступа к публичным сетям итп).

ansible-pull позволяет использовать pull-модель, но гибкости в нём маловато.

Далее, не каждый сервер готов в данный момент времени принять обновления.

Аргумент. Ну тут у меня просто: всё критичное имеет горячий резерв, так что для серьёзных обновлений делаем часть серверов неактивными, обновляем, включаем обратно, переходим к следующей части. Несерьёзные наживую можно катить.

Ещё один юз-кейс: упавший SSH. Такое бывает, причин для этого вагон и маленькая тележка, уверен, что если ты не сталкивался ещё с этим, то обязательно столкнёшься.

Он автоматом перезапускаеся при падении. И upstart и systemd это умеют, к sysv прикручивается supervisord и прочие костыли. Ну а если уж так падает, что перезапуститься не может, будем считать хост сбойным и лезть внутрь аварийными средствами - IPMI для физического хоста, для виртуалки - прицепить диск к лругому инстансу.

У меня есть юниты вообще без SSH-сервера и пользователей с паролями, при этом они успешно обслуживаются при помощи CFEngine и предоставляют доступ через публичную сеть.

Сложность поставить и нормально настроить ssh или специальный демон для cfengine вполне сравнима, ИМХО не аргумент.

А Ansible удобно использовать для других вещей.

Пока в ограничения ansible серьёзно не упирался, но в общем верю.

Push-модель с ростом единиц обслуживаемой техники стремительно перестаёт скалироваться. Pull-модель продолжает работать как работала. При чём в моём случае есть некое n серверов ... с медленным и ненадёжным доступом.
Ещё юз-кейс: юниты с непредсказуемым эпизодическим доступом к сети или вообще без такового (лаптопы, промышленное оборудование без доступа к публичным сетям итп).

ansible-pull позволяет использовать pull-модель, но гибкости в нём маловато.

Далее, не каждый сервер готов в данный момент времени принять обновления.

Аргумент. Ну тут у меня просто: всё критичное имеет горячий резерв, так что для серьёзных обновлений делаем часть серверов неактивными, обновляем, включаем обратно, переходим к следующей части. Несерьёзные наживую можно катить.

Ещё один юз-кейс: упавший SSH. Такое бывает, причин для этого вагон и маленькая тележка, уверен, что если ты не сталкивался ещё с этим, то обязательно столкнёшься.

Он автоматом перезапускаеся при падении. И upstart и systemd это умеют, к sysv прикручивается supervisord и прочие костыли. Ну а если уж так падает, что перезапуститься не может, будем считать хост сбойным и лезть внутрь аварийными средствами - IMPI для физического хоста, для виртуалки - прицепить диск к лругому инстансу.

У меня есть юниты вообще без SSH-сервера и пользователей с паролями, при этом они успешно обслуживаются при помощи CFEngine и предоставляют доступ через публичную сеть.

Сложность поставить и нормально настроить ssh или специальный демон для cfengine вполне сравнима, ИМХО не аргумент.

А Ansible удобно использовать для других вещей.

Пока в ограничения ansible серьёзно не упирался, но в общем верю.