Terraform: инфраструктура на уровне кода

У 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, а может, в клиент управления конфигурацией, или в центральный (-е) сервер (-ы), или в процесс взаимодействия между центральным (-и) сервером (-ами) и клиентами или остальными серверами, или же…

Рис. 1.7. Типичная архитектура Chef, Puppet и SaltStack состоит из множества компонентов. Например, в стандартной конфигурации клиент Chef, запущенный на вашем компьютере, общается с центральным сервером Chef, который развертывает изменения, взаимодействуя с клиентами Chef на всех остальных серверах

Ansible, CloudFormation, Heat и Terraform не требуют установки никаких дополнительных агентов. Или, если быть более точным, некоторым из них нужны агенты, но обычно они уже установлены в рамках используемой вами инфраструктуры. Например, AWS, Azure, Google Cloud и любые другие облачные провайдеры сами занимаются установкой, администрированием и аутентификацией ПО агента на всех своих физических серверах. Вам как пользователю Terraform не нужно об этом беспокоиться: вы просто вводите команды, а агенты облачного провайдера выполняют их для вас на каждом сервере, как показано на рис. 1.8. В случае с Ansible на серверах должен быть запущен демон SSH, который обычно и так есть в большинстве систем.