Как пользоваться ansible?

Эээээ, очень похоже на глубинный XY. Оркестрация != сделать зашибись. Если где-то что-то отваливается, то это надо чинить, а не перезапускать не теми инструментами.

Если где-то что-то отваливается, то это надо чинить, а не перезапускать

Не могу с этим не согласится, но не всегда есть ресурсы на чинить, а периодический запуск сервиса всех устраивает. (знаю, что плохая практика, пока ничего не могу с этим поделать, это не всегда моё решение)

Оркестрация != сделать зашибись

А что же это тогда? Просто apt install и конфиги принести?

А что же это тогда? Просто apt install и конфиги принести?

x1000 например.

Не могу с этим не согласится, но не всегда есть ресурсы на чинить, а периодический запуск сервиса всех устраивает. (знаю, что плохая практика, пока ничего не могу с этим поделать, это не всегда моё решение)

Вот же проблема. Сам спросил сам ответил.

Я не вижу тут конфликта. У меня есть задача (условно) «принести на сервера X сервисы Y и поддерживать их в рабочем активном состоянии»

Я использую провизию(puppet) для автоматического выполнения этих действий. Да, не в масштабах x1000, но всёравно быстрее и удобнее чем руками.

PS. Вопрос темы - как похожее делать на ansible.

Запускай по cronу.

Хз, в концепции нужный плейбук с перезапуском по крону? Или тебе прям колбэк на падение нужен?

Да, cron подходит как простое решение.

В большей части инструкций «запускаем в консоли плейбук» и на этом всё. Как дальше это использовать всегда опускают. Ближайшее, что находил это git hook, который запускал плейбук.

Ожидал, что я или что-то в упор не замечаю, или решение достаточно простое чтобы использовать просто cron.

колбэк на падение

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

сервис периодически падает

Пусть systemd его поднимает, он умеет. Ansible это рецепт, который можно запустить на нескольких машинах. Другой вариант это система мониторинга, которая может по тригеру поднять сервис, что может быть гибче чем systemd.

P.S. ниже уже icinga2 советуют, присоединяюсь.

Если что-то отваливается и надо выполнить какие-то действия по реанимации (перезапуск демона например), то тебе нужна система мониторинга (icinga2 например) и обратная связь (event handler) от мониторинга к серверу для отработки реанимационных действий.

Смысл простой: мониторинг сервиса обнаруживает проблему и запускает её устранение, попутно информируя админов об этом

А встречал кто-нибудь готовое решение? Можно без серьёзного мониторинга, просто продвинутый крон.

Мне бы пригодилось.

А как это реализуется в ansible?

В голом ansible естественно никак.

А для инфраструктуры основанной на ansible есть https://www.ansible.com/products/controller

он платный :-) (бесплатно до 10 хостов)

А если по какой-то странной причине ты не хочешь платить деньги RedHat то можно побыть бесплатным бетатестером и потестировать на своём проде их бетаверсию: https://www.ansible.com/products/awx-project/faq (Q: Does Red Hat recommend AWX for production environments? A: No)

и там будут как пишут: «управления плейбуками, расписанием их запусков, управления инвентори, учетными данными для доступа к серверам, а также механизм callback’ов для запроса конфигураций со стороны сервера». Почти puppet.

Либо можно поставить выделенный сервер в котором по cron или CI/CD дёргать ansible-playbook -l all, так вроде тоже делают :-)

А какое может быть готовое решение на локальном кроне? Примитив же

#!/bin/sh

if /path/to/check_service; then
# service fail
  /path/to/start_service
  mailx ... "service XXX failed. Try to restart"
fi

сервис периодически падает и puppet используется для периодического его запуска

Использовать локальный менеджер сервисов.

Не всегда машина, которая провизируется доступна прямо сейчас

Пусть анзибль делает машину доступной.

вот у меня сейчас абсолютно точно доступный сервер, я его один раз спровизирую и более его состояние меняться не будет

все так - это механизм администрирования групп серверов, а не менеджер конфигураций.

например на всех серверах обновить какой-то пакет или поменять сертификат

Если же хочется именно управлять конфигурациями, то смотри в сторону связки etcd (consul) - confd

А для инфраструктуры основанной на ansible есть https://www.ansible.com/products/controller

Это они Tower переименовали?

Это они Tower переименовали?

Угу.

Я знаком с этим по вершкам, но по-моему у ansible иная концепция: ты сам проактивно запускаешь плэйбуки. И концептуально они скорее для провижинга и реже обновления инфраструктуры. У паппета абсолютно иной подход, который предполагает полуавтоматическое приведение системы из состояния А в состояние Б.

Наверное при некотором желании можно из одного сделать подобие другого, а из второго первое, но зачем? А про то, чтобы их использовали для мониторинга хелс-чеков, я вообще никогда не слышал :)