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