В настоящее время я пытаюсь продать «DevOps» своему руководству. Одна из вещей, которые я исследую, - это инструменты управления конфигурацией. Одним из важных моментов для нас является то, что у нас есть система с высокой доступностью и хорошим поведением при отказе.
Я не включаю Windows PowerShell DSC в этот список, так как мой текущий пользовательский случай состоит в том, что я бы использовал PowerShell DSC для помощи в управлении системами Windows с помощью Puppet, Chef, Ansible, Salt или CF-Engine в качестве общего инструмента управления.
Я хочу знать, правильно ли я понимаю каждый инструмент, а если нет, то почему?
Я буду комментировать только те, с которыми у меня есть опыт, то есть Puppet и Ansible. И я опускаю некоторые детали.
Оба могут быть настроены для работы без агента или локально только при необходимости. Чтобы использовать их только локально, вам, очевидно, нужен какой-то способ перенести необходимые манифесты / плейбуки на целевые машины и запустить их там.
Говоря об использовании Puppet с мастерами, вы можете иметь избыточность, используя балансировщик нагрузки с реальными мастерами.
Вместо этого в Ansible нет основной концепции, это может делать каждая машина, которая может подключаться к управляемым машинам с помощью ssh / powershell, при условии, что у вас есть способ доступа к playbook. Возможно, вы имели в виду Ansible Tower, который использует БД для своей работы, и вы можете кластеризовать ее при необходимости.
Это приводит нас к реальной избыточности в обоих случаях, то есть к реальным сценариям. Почти во всех случаях я видел, что они оставались в репозитории git, поэтому он изначально избыточен, просто клонируйте его, и вы можете иметь сколько «мастер-копий», сколько захотите.
Надеюсь это поможет.
Если вы посмотрите на соль, единственная информация, которая составляет рабочее соединение между мастером и миньонами, это:
Если ваш соляной мастер умрет, системы продолжат работать без каких-либо последствий. Но вы правы, вы не можете вносить какие-либо изменения в свои конфигурации, пока мастер отсутствует. Итак, вопрос в том, как быстро вы сможете его вернуть?
Вы можете просто переустановить мастер и запустить его - вы можете снова принять свои ключи миньонов (или переустановить потенциальную резервную копию), и вы окажетесь на том же месте, где остановились со своим старым мастером. Если вы не можете повторно использовать одну и ту же машину, вам нужно как-то указать миньонов на нового хозяина.
Нет данных о состоянии в базе данных, которые могли быть повреждены или исчезли. В этом для меня красота. Это наложение, оно не втискивается. Не - как другой пример - как juju, когда когда ваша база данных отсутствует, ваши системы действуют так, как будто они обезглавлены, и вам нужно переустановить.
А также есть Multimaster и Syndic in Salt - Высокая доступность - давняя тема в его развитии.
Чтобы завершить сказанное выше, Chef (при использовании chef-client, chef-solo является чисто локальным и не имеет серверного компонента, который мог бы выйти из строя) требует сервера при каждом запуске. Есть способы использовать данные кеша в случае сбоя, но это определенно не поведение по умолчанию и даже не простое. Мы рекомендуем запускать Chef Server в резервированной / кластерной системе с одним кластером на зону отказа. Ознакомьтесь с продуктом Chef-backend для кластеризации и продуктом Facebook Grocery Delivery для синхронизации на нескольких серверах.
Итак, сначала я хочу поблагодарить jscott, Fredi, user378016 и coderanger за все ответы.
Чтобы ответить на мой собственный вопрос
- Для CF-Engine это не проблема, поскольку каждый узел может быть настроен для работы в качестве сервера, и запуски продолжатся, если сервер недоступен.
Все это хорошо задокументировано на сайте CF-Engine, пример можно найти здесь: https://cfengine.com/learn/how-cfengine-works/
- Для Puppet у вас есть выбор режимов Мастер / Без Мастера, а также их плюсы и минусы.
Puppet имеет множество режимов, и, как указал Фреди, это один или другой режим. Однако после того, как вы покопались, Puppet стал очень гибким и имеет хорошие функции, которые могут поддерживаться как в мастер-режиме, так и без него.
- Для Chef первоначальный запуск требует, чтобы главный сервер получил политику, но после этого любой запуск будет продолжен с этой текущей политикой, если главный сервер недоступен.
Так что это было не совсем правильно, при запуске в серверном режиме (без использования chef-solo) запуск требует подключения к мастеру для каждого запуска. Как уже упоминалось, существуют способы выполнить резервное кэширование, которые имеют некоторый интересный потенциал и, возможно, стоит изучить еще немного.
- Для Salt, если главный сервер выходит из строя, конфигурация не применяется, поскольку все действия выполняются на главном сервере
Итак, спасибо user378016 за подтверждение, я думаю, что предоставленный ответ действительно отвечает на это довольно хорошо (постоянная ссылка: https://serverfault.com/a/805791/225383)
- Для Ansible (например, соли), если главный сервер выходит из строя, конфигурации больше не применяются, так как снова все действия выполняются главными серверами.
Итак, Ansible - непростая задача (снова спасибо Фреди за его ответ). Это дает серьезное преимущество, заключающееся в необходимости установки программного обеспечения Ansible только на один сервер. Плейбуки, которые хранятся на этом «главном», не обязательно запускаются на главном сервере, но могут применяться к другим через SSH. Это, конечно, требует, чтобы все эти поля, которые вы хотите настроить, были доступны через SSH и удовлетворяли определенным предварительным условиям (как указано в инструкции). В некоторых случаях это не всегда так желательно.
Изменить: я должен добавить, что Ansible может работать аналогично puppet-masterless, chef-solo, установив Ansible на управляемом узле и получив конфигурацию откуда-то вроде git, а затем применив конфигурацию локально.
Тем, кому интересно направление, я рекомендую CF-Engine, Chef или Puppet. Хотя Ansible и Salt интересны, для моего случая пользователя, однако, это не оптимальное решение, поскольку мне нужно иметь возможность гарантировать, что политика применяется независимо от того, что с хорошими показателями отчетности, уверенность в том, что SSH всегда доступен, на самом деле не вариант (и да, хотя мы могли бы установить серверные компоненты на каждый компьютер или какой-либо планировщик, чтобы принудительно настроить конфигурацию, это кажется интуитивно противоречащим их исходной архитектуре с самого начала).
Все из этих продуктов очень хороши и имеют разные сильные и слабые стороны, в этом случае я почувствовал, что Ansible и Salt не подходят не только по вышеуказанной причине, но и по ряду других причин.