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