Однако использование центрального сервера имеет серьезные недостатки.
•Дополнительная инфраструктура. Вам нужно развернуть дополнительный сервер или даже кластер дополнительных серверов (для высокой доступности и масштабируемости).
• Обслуживание. Центральный сервер нуждается в обслуживании, обновлении, резервном копировании, мониторинге и масштабировании.
•Безопасность. Вам нужно сделать так, чтобы клиент мог общаться с центральным сервером, а последний — со всеми остальными серверами. Это обычно требует открытия дополнительных портов и настройки дополнительных систем аутентификации, что увеличивает область потенциальных атак.
У Chef, Puppet и SaltStack есть разного уровня поддержка режимов работы без центральных серверов. Для этого на каждом сервере запускаются их агенты (обычно по расписанию; например, раз в пять минут), которые загружают последние обновления из системы управления версиями (а не из центрального сервера). Это существенно снижает количество вовлеченных компонентов, но, как вы увидите в следующем подразделе, все равно оставляет без ответа ряд вопросов, особенно касательно того, каким образом в этом случае будут инициализироваться серверы и устанавливаться сами агенты.
У Ansible, CloudFormation, Heat и Terraform по умолчанию нет центрального сервера. Или, если быть более точным, некоторые из них работают с центральным сервером, но он уже является частью используемой инфраструктуры, а не каким-то дополнительным компонентом, требующим отдельного внимания. Предположим, Terraform общается с облачными провайдерами через их API, которые в каком-то смысле являются центральными серверами. Вот только им не нужно никакой дополнительной инфраструктуры или механизмов аутентификации (то есть вы просто применяете свои API-ключи). Ansible подключается к каждому серверу напрямую по SSH, поэтому вам не нужны дополнительная инфраструктура или механизмы аутентификации (то есть вы просто используете свои SSH-ключи).
Наличие или отсутствие агентов
Chef, Puppet и SaltStack требуют установки своих агентов (вроде Chef Client, Puppet Agent и Salt Minion) на каждый сервер, который вы хотите настраивать. Агент обычно работает в фоне и отвечает за установку последних обновлений конфигурации.
У этого подхода есть несколько недостатков.
•Требуется предварительная подготовка. Как изначально происходит инициализация серверов и установка на них агентов? Некоторые средства управления конфигурацией игнорируют этот момент, подразумевая, что об этом за них позаботится какой-то внешний процесс (например, вначале используется Terraform для развертывания кучи серверов с образами AMI, в которых уже установлен агент). У других предусмотрен специальный подготовительный процесс, в ходе которого вы выполняете одноразовые команды для инициализации серверов (с помощью API облачного провайдера) и установки на них агентов (по SSH).
• Необходимо выполнять обслуживание. Вам требуется тщательно и регулярно обновлять программное обеспечение агента, чтобы синхронизировать его с центральным сервером (если таковой имеется). Нужно также следить за агентами и перезапускать их, если они выйдут из строя.
• Следует обеспечить безопасность. Если ПО агента загружает конфигурацию с центрального сервера (или какого-то другого сервера, если у вас нет центрального), вам придется открыть исходящие порты на каждом узле. Если центральный сервер сам передает конфигурацию агентам, вам нужно будет открыть на каждом узле входящие порты. В любом случае вы должны найти способ аутентификации агента на сервере, с которым он взаимодействует. Все это увеличивает область потенциальных атак.
И снова Chef, Puppet и SaltStack предлагают разного уровня поддержку режимов работы без агента (например, salt-ssh), но все они выглядят так, будто о них вспомнили задним числом, и ни в одном из них не доступен полный набор возможностей по управлению конфигурацией. В связи с этим в реальных условиях стандартный или идиоматический способ использования Chef, Puppet и SaltStack подразумевает наличие агента и, как правило, центрального сервера (рис. 1.7).
Все эти дополнительные компоненты создают много слабых мест в вашей инфраструктуре. Каждый раз, когда вы получаете отчет о сбое в три часа ночи, вам нужно понять, куда закралась ошибка: в код приложения или IaC, а может, в клиент управления конфигурацией, или в центральный (-е) сервер (-ы), или в процесс взаимодействия между центральным (-и) сервером (-ами) и клиентами или остальными серверами, или же…