Автоматическая повторная попытка отправки конфигурации с помощью Ansible или Saltstack?
Я пытаюсь выбрать систему управления конфигурацией для 500-2000 очень географически распределенных хостов. Из-за разной надежности сети некоторые хосты могут быть временно недоступны в любой момент времени. По этой причине я изначально выбрал Chef, поскольку он использует модель «тянуть», и когда хосты подключаются к сети и регистрируются, они немедленно получают текущую конфигурацию.
Однако, если мои хосты опрашивают сервер Chef на предмет новой конфигурации только каждые 30 минут, быстрое развертывание невозможно. Кроме того, я не рубист. Я бы предпочел использовать модель на основе push, когда я могу как можно быстрее передавать конфигурацию на хосты. Итак, естественным выбором кажется Ansible или SaltStack (возможно, SaltStack). Но мой вопрос: как Ansible и SaltStack обрабатывают отказавшие или неработающие хосты? Есть ли способ постоянно повторять попытки отправки, пока хост не вернется в сеть? Существуют ли существующие шаблоны для правильной обработки возможной согласованности отключенных хостов с помощью любого из этих инструментов? Спасибо!
Соль проходит по модели вытягивания от узлов к мастеру.Вы можете запускать глобальные команды от мастера, например
salt 'api*.domain.com` state.highstate
, который будет запускать highstate на всех хостах, имеющих идентификатор (имя хоста) api * .domain.com. Highstate подобен полному шеф-повару.
Обычно по умолчанию люди либо имеют главное расписание highstate запускается на миньонах, либо они запускают расписание на самих миньонах, чтобы сказать запускать highstate каждые 10 минут.
Таким образом, если узел не работает, и вы запускаете команду на главном устройстве для запуска состояния, тогда соль сообщит, что узел не работает в своем выводе выполнения, который может быть отформатирован многими различными способами для вас. Например, он может быть зарегистрирован в mysql.
Так, например, если вы выполнили указанную выше команду на главном сервере, чтобы запустить highstate на всех узлах api * .domain.com . Если бы 2 из 5000 в настоящее время перезагружались, когда salt-minion снова подключался к сети, они бы получили четность от мастера через шину сообщений и запустили highstate.
Salt также имеет прокси-узлы, помогающие загрузке мастера. У вас может быть один главный узел и прокси-узел в каждом центре обработки данных, и все команды, отправленные от ведущего, проходят через прокси-узлы, и миньоны в этих центрах обработки данных попадают в их прокси-узел, а не на главный
Я могу ответить на это только для Ansible.
Сам Ansible не обрабатывает хосты, которые недоступны. Он попытается подключиться и один раз, и если это невозможно, хост выбрасывается из текущей игры. Но Ansible дает вам несколько инструментов для решения этой проблемы.
Во-первых, это модуль wait_for . При этом вы можете подождать с очень большим таймаутом, пока хосты не станут доступными.
- wait_for:
port: 22
delay: 10
timeout: 3600
host: "{{ inventory_hostname }}"
delegate_to: localhost
Уже одно это будет проблемой при запуске игры, потому что Ansible по умолчанию не будет обрабатывать дальнейшие задачи, пока все хосты не пройдут эту задачу. Что в данном случае контрпродуктивно. Согласно вашему описанию, первые хосты могут быть снова недоступны, когда последний хост, наконец, станет доступным.
Для решения этой проблемы вам необходимо использовать Ansible 2, в котором есть новая функция под названием стратегии . стратегия: бесплатно позволяет запускать каждую задачу как можно быстрее, что означает, что она запускает все задачи, как только хост становится доступен.
Тем не менее, соединение может разорваться, и в этом случае есть нет встроенного способа автоматически повторить попытку. Если соединение ssh не может быть установлено, для этого хоста будет выдана фатальная ошибка, и поскольку Ansible ~ 1.9. нет возможности поймать такую ошибку соединения. Однако это не влияет на другие хосты, все они будут работать нормально.
Вы можете повторить попытку. Отказавшие хосты будут сохранены в файле рядом с самой playbook. Чтобы повторить попытку только сбойных хостов, вы затем можете запустить:
ansible-playbook ... --limit @<playbook-name>.retry
Чтобы расширить ответ Майка, вы можете одновременно нажимать и нажимать с помощью Salt. Толкать так же просто, как
salt 'api*.domain.com` state.highstate
В то же время, ваши приспешники могут делать запланированные тянуть каждые X минут или часов с помощью встроенного планировщика . Я предпочитаю настраивать его через столб, но добавление его в конфигурацию фаворита тоже работает. Something like:
schedule:
highstate:
function: state.highstate
maxrunning: 1
hours: 1
splay: 600