Исправление selivan, (текущая версия) :
Push-модель с ростом единиц обслуживаемой техники стремительно перестаёт скалироваться. Pull-модель продолжает работать как работала. При чём в моём случае есть некое n серверов ... с медленным и ненадёжным доступом.
Ещё юз-кейс: юниты с непредсказуемым эпизодическим доступом к сети или вообще без такового (лаптопы, промышленное оборудование без доступа к публичным сетям итп).
ansible-pull позволяет использовать pull-модель, но гибкости в нём маловато.
Далее, не каждый сервер готов в данный момент времени принять обновления.
Аргумент. Ну тут у меня просто: всё критичное имеет горячий резерв, так что для серьёзных обновлений делаем часть серверов неактивными, обновляем, включаем обратно, переходим к следующей части. Несерьёзные наживую можно катить.
Ещё один юз-кейс: упавший SSH. Такое бывает, причин для этого вагон и маленькая тележка, уверен, что если ты не сталкивался ещё с этим, то обязательно столкнёшься.
Он автоматом перезапускаеся при падении. И upstart и systemd это умеют, к sysv прикручивается supervisord и прочие костыли. Ну а если уж так падает, что перезапуститься не может, будем считать хост сбойным и лезть внутрь аварийными средствами - IPMI для физического хоста, для виртуалки - прицепить диск к другому инстансу и смотреть.
У меня есть юниты вообще без SSH-сервера и пользователей с паролями, при этом они успешно обслуживаются при помощи CFEngine и предоставляют доступ через публичную сеть.
Сложность поставить и нормально настроить ssh или специальный демон для cfengine вполне сравнима, ИМХО не аргумент.
А Ansible удобно использовать для других вещей.
Пока в ограничения ansible серьёзно не упирался, но в общем верю.
Исправление selivan, :
Push-модель с ростом единиц обслуживаемой техники стремительно перестаёт скалироваться. Pull-модель продолжает работать как работала. При чём в моём случае есть некое n серверов ... с медленным и ненадёжным доступом.
Ещё юз-кейс: юниты с непредсказуемым эпизодическим доступом к сети или вообще без такового (лаптопы, промышленное оборудование без доступа к публичным сетям итп).
ansible-pull позволяет использовать pull-модель, но гибкости в нём маловато.
Далее, не каждый сервер готов в данный момент времени принять обновления.
Аргумент. Ну тут у меня просто: всё критичное имеет горячий резерв, так что для серьёзных обновлений делаем часть серверов неактивными, обновляем, включаем обратно, переходим к следующей части. Несерьёзные наживую можно катить.
Ещё один юз-кейс: упавший SSH. Такое бывает, причин для этого вагон и маленькая тележка, уверен, что если ты не сталкивался ещё с этим, то обязательно столкнёшься.
Он автоматом перезапускаеся при падении. И upstart и systemd это умеют, к sysv прикручивается supervisord и прочие костыли. Ну а если уж так падает, что перезапуститься не может, будем считать хост сбойным и лезть внутрь аварийными средствами - IPMI для физического хоста, для виртуалки - прицепить диск к лругому инстансу.
У меня есть юниты вообще без SSH-сервера и пользователей с паролями, при этом они успешно обслуживаются при помощи CFEngine и предоставляют доступ через публичную сеть.
Сложность поставить и нормально настроить ssh или специальный демон для cfengine вполне сравнима, ИМХО не аргумент.
А Ansible удобно использовать для других вещей.
Пока в ограничения ansible серьёзно не упирался, но в общем верю.
Исходная версия selivan, :
Push-модель с ростом единиц обслуживаемой техники стремительно перестаёт скалироваться. Pull-модель продолжает работать как работала. При чём в моём случае есть некое n серверов ... с медленным и ненадёжным доступом.
Ещё юз-кейс: юниты с непредсказуемым эпизодическим доступом к сети или вообще без такового (лаптопы, промышленное оборудование без доступа к публичным сетям итп).
ansible-pull позволяет использовать pull-модель, но гибкости в нём маловато.
Далее, не каждый сервер готов в данный момент времени принять обновления.
Аргумент. Ну тут у меня просто: всё критичное имеет горячий резерв, так что для серьёзных обновлений делаем часть серверов неактивными, обновляем, включаем обратно, переходим к следующей части. Несерьёзные наживую можно катить.
Ещё один юз-кейс: упавший SSH. Такое бывает, причин для этого вагон и маленькая тележка, уверен, что если ты не сталкивался ещё с этим, то обязательно столкнёшься.
Он автоматом перезапускаеся при падении. И upstart и systemd это умеют, к sysv прикручивается supervisord и прочие костыли. Ну а если уж так падает, что перезапуститься не может, будем считать хост сбойным и лезть внутрь аварийными средствами - IMPI для физического хоста, для виртуалки - прицепить диск к лругому инстансу.
У меня есть юниты вообще без SSH-сервера и пользователей с паролями, при этом они успешно обслуживаются при помощи CFEngine и предоставляют доступ через публичную сеть.
Сложность поставить и нормально настроить ssh или специальный демон для cfengine вполне сравнима, ИМХО не аргумент.
А Ansible удобно использовать для других вещей.
Пока в ограничения ansible серьёзно не упирался, но в общем верю.