Chef, Puppet и SaltStack по умолчанию требуют наличия центрального (master) сервера для хранения состояния вашей инфраструктуры и распространения обновлений. Каждый раз, когда вы хотите что-то обновить в своей инфраструктуре, вам необходимо использовать клиент (например, утилиту командной строки), чтобы передать новые команды центральному серверу, который выкатывает обновления на все остальные серверы или позволяет им их загружать на регулярной основе.
У центрального сервера несколько преимуществ. Во-первых, это единое централизованное место, где вы можете просматривать и администрировать состояние своей инфраструктуры. У многих средств управления конфигурацией для этого даже есть веб-интерфейс (например, Chef Console, Puppet Enterprise Console), который помогает ориентироваться в происходящем. Во-вторых, некоторые центральные серверы умеют работать непрерывно, в фоновом режиме, обеспечивая соблюдение вашей конфигурации. Таким образом, если кто-то поменяет состояние узла вручную, центральный сервер может откатить это изменение, тем самым предотвращая дрейф конфигурации.
Однако использование центрального сервера имеет серьезные недостатки.
•Дополнительная инфраструктура. Вам нужно развернуть дополнительный сервер или даже кластер дополнительных серверов (для высокой доступности и масштабируемости).
• Обслуживание. Центральный сервер нуждается в обслуживании, обновлении, резервном копировании, мониторинге и масштабировании.
•Безопасность. Вам нужно сделать так, чтобы клиент мог общаться с центральным сервером, а последний — со всеми остальными серверами. Это обычно требует открытия дополнительных портов и настройки дополнительных систем аутентификации, что увеличивает область потенциальных атак.
У Chef, Puppet и SaltStack есть разного уровня поддержка режимов работы без центральных серверов. Для этого на каждом сервере запускаются их агенты (обычно по расписанию; например, раз в пять минут), которые загружают последние обновления из системы управления версиями (а не из центрального сервера). Это существенно снижает количество вовлеченных компонентов, но, как вы увидите в следующем подразделе, все равно оставляет без ответа ряд вопросов, особенно касательно того, каким образом в этом случае будут инициализироваться серверы и устанавливаться сами агенты.
У Ansible, CloudFormation, Heat и Terraform по умолчанию нет центрального сервера. Или, если быть более точным, некоторые из них работают с центральным сервером, но он уже является частью используемой инфраструктуры, а не каким-то дополнительным компонентом, требующим отдельного внимания. Предположим, Terraform общается с облачными провайдерами через их API, которые в каком-то смысле являются центральными серверами. Вот только им не нужно никакой дополнительной инфраструктуры или механизмов аутентификации (то есть вы просто применяете свои API-ключи). Ansible подключается к каждому серверу напрямую по SSH, поэтому вам не нужны дополнительная инфраструктура или механизмы аутентификации (то есть вы просто используете свои SSH-ключи).
