Поведение средств управления конфигурацией при сбое
В настоящее время я пытаюсь продать "DevOps" своему руководству. Одна из вещей, которую я исследую, - это инструмент "Управление конфигурациями". Для нас очень важно то, что у нас есть система с высокой доступностью и хорошим режимом отработки отказа.
- Для CF-Engine это не проблема, поскольку каждый узел может быть настроен для работы в качестве сервера, и запуск будет продолжен, если сервер недоступен.
- Для Puppet у вас есть выбор режимов Master/Masterless и их плюсы и минусы.
- Для Chef первоначальный запуск требует, чтобы главный сервер извлек политику, но после этого любой запуск продолжится с этой текущей политикой, если мастер недоступен.
- Для Salt, если главный сервер выходит из строя, тогда конфигурация не применяется, так как все действия выполняются на главном сервере.
- Для Ansible (например, salt), если главный сервер выходит из строя, тогда конфигурации больше не применяются, поскольку все главные действия снова выполняются главными серверами.
Я не включаю Windows PowerShell DSC в этот список, так как мой текущий пользовательский случай заключается в том, что я буду использовать PowerShell DSC, чтобы помочь в управлении системами Windows с Puppet, Chef, Ansible, Salt или CF-Engine в качестве общего инструмента управления.
Я хочу знать, правильно ли мое занижение каждого инструмента, и если нет, то почему?
4 ответа
Итак, во-первых, я хочу поблагодарить jscott, Fredi, user378016 и coderanger за все ответы.
Ответить на мой вопрос
- Для CF-Engine это не проблема, поскольку каждый узел может быть настроен для работы в качестве сервера, и запуск будет продолжен, если сервер недоступен.
Все это хорошо задокументировано на веб-сайте CF-Engine, пример можно найти здесь: https://cfengine.com/learn/how-cfengine-works/
- Для Puppet у вас есть выбор режимов Master/Masterless и их плюсы и минусы.
У Puppet есть множество режимов, и, как указал Фреди, режим один или другой. Однако после выполнения дополнительных работ Puppet становится очень гибким и обладает хорошими функциями, которые могут поддерживаться как в режиме master, так и в режиме masterless.
- Для Chef первоначальный запуск требует, чтобы главный сервер извлек политику, но после этого любой запуск продолжится с этой текущей политикой, если мастер недоступен.
Так что это было не совсем правильно, когда работа в режиме сервера (без использования chef-solo) для прогона требует подключения к мастеру для каждого прогона. Как уже было упомянуто, есть способы сделать резервное кеширование, которое имеет некоторый интересный потенциал и, возможно, стоит посмотреть еще.
- Для Salt, если главный сервер выходит из строя, тогда конфигурация не применяется, так как все действия выполняются на главном сервере.
Так что спасибо user378016 за подтверждение, я думаю, что предоставленный ответ действительно отвечает на этот вопрос (постоянная ссылка: /questions/480245/povedenie-sredstv-upravleniya-konfiguratsiej-pri-sboe/480249#480249)
- Для Ansible (например, salt), если главный сервер выходит из строя, тогда конфигурации больше не применяются, поскольку все главные действия снова выполняются главными серверами.
Так что Ansible хитрый (еще раз спасибо Фреди за его ответ). Это дает сильное преимущество только от необходимости устанавливать программное обеспечение Ansible на одном сервере. Playbook, которые хранятся на этом "master", не обязательно работают на master, но могут быть применены к другим через SSH. Это, конечно, требует, чтобы все эти блоки, которые вы хотите настроить, были доступны через SSH и соответствовали определенным предварительным условиям (как описано в книге игр). В некоторых случаях это не всегда так желательно.
Редактировать: я должен добавить, что Ansible может работать так же, как и puppet-masterless, chef-solo, установив Ansible на управляемый узел и заставив его вытащить конфигурацию откуда-то, например, git, а затем применить ее локально.
Для тех, кто интересуется направлением, я рекомендую CF-Engine, Chef или Puppet. Хотя Ansible и Salt оба интересны, для моего пользовательского случая это, однако, не оптимальное решение, так как я должен быть в состоянии обеспечить применение политики независимо от того, что с хорошими показателями отчетности, уверенность в том, что SSH всегда доступен, на самом деле не вариант (и да, хотя мы могли бы установить серверные компоненты на каждый блок или какой-либо планировщик, чтобы принудительно настроить конфигурацию, это кажется противоречащим их первоначальной архитектуре с самого начала).
Все эти продукты очень хороши и имеют разные сильные и слабые стороны, в этом случае я чувствовал, что Ansible и Salt не подходят не только по вышеуказанной причине, но также и по различным другим причинам.
Я буду комментировать только те, с которыми у меня есть опыт, это означает Puppet и Ansible. И я опускаю некоторые детали.
Оба могут быть настроены для запуска без агента или локально, только если это необходимо. Чтобы использовать их только локально, вам, очевидно, нужен какой-то способ передачи необходимых манифестов / сборников игр на целевые машины и запуска их там.
Говоря об использовании Puppet с мастерами, вы можете иметь избыточность, используя балансировщик нагрузки с реальными мастерами позади.
Вместо этого в Ansible отсутствует основная концепция, которую может выполнить каждая машина, которая может подключаться к управляемым машинам с помощью ssh / powershell, при условии, что у вас есть доступ к книгам воспроизведения. Возможно, вы имели в виду Ansible Tower, которая использует БД для своей работы, и вы можете кластеризовать ее при необходимости.
Это приводит нас к реальной избыточности в обоих случаях, то есть к подлинным сценариям. Почти во всех случаях я видел, что они остаются в репозитории git, так что он по своей сути избыточен, просто клонируя его, и вы можете получить столько "мастер" копий, сколько пожелаете.
Надеюсь это поможет.
Если вы посмотрите на соль, единственная информация, которая составляет рабочую связь между мастером и миньонами:
- тот факт, что миньон может как-то разрешить мастер ip
- открытые ключи миньонов в каталогах / etc / salt / pki / master
Если ваш мастер соли умирает, системы продолжат работать без эффекта. Но вы правы, вы не можете запускать какие-либо изменения в ваших конфигурациях, пока мастер отсутствует. Итак, вопрос в том, как быстро вы можете получить его обратно?
Вы можете просто переустановить мастер и запустить его - вы можете снова принять ключи миньонов (или переустановить потенциальную резервную копию), и вы окажетесь в том же месте, где остановились со своим старым мастером. Если вы не можете повторно использовать одну и ту же машину, вам нужно как-то указать миньонов на нового мастера.
Нет данных о состоянии в базе данных, которые могут быть повреждены или пропали. Это для меня красота этого. Это наложение, оно не сжимается. Не - как другой пример - как juju, где, когда ваша база данных исчезла, ваши системы работают так, как будто они обезглавлены, и вы должны переустановить.
Существует также Multimaster и Syndic в соли - высокая доступность является давней темой в его разработке.
Чтобы округлить вещи с вышеизложенным, шеф-повар (при использовании chef-client, chef-solo является чисто локальным и не имеет серверного компонента, который может выйти из строя) требует сервера при каждом запуске. Существуют способы использования данных кэша в случае сбоя, но это определенно не поведение по умолчанию или даже простота. Мы рекомендуем запускать Chef Server в избыточной / кластерной системе с одним кластером на зону сбоя. Познакомьтесь с продуктом chef-backend для кластеризации и службой доставки продуктов в Facebook для синхронизации на нескольких серверах.