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

Естественно, это упрощенные примеры. Ansible позволяет использовать теги для поиска имеющихся серверов EC2, прежде чем добавлять новые (скажем, с помощью параметров instance_tags и count_tag). Однако ручная организация такого рода логики для каждого ресурса, которым вы управляете с применением Ansible, с учетом истории его изменений может оказаться на удивление сложной. Вам придется искать существующие серверы не только по тегам, но также по версии образа и зоне доступности. Из этого вытекают две основные проблемы с процедурными средствами IaC.

•Процедурный код не полностью охватывает состояние инфраструктуры. Даже если вы прочитаете все три предыдущих шаблона Ansible, вы все равно не будете знать, что у вас развернуто. Помимо прочего, вам должен быть известен

порядок, в котором эти шаблоны были применены. Если применить их не в том порядке, можно получить другую инфраструктуру, и этого нельзя увидеть по одной лишь кодовой базе. Иными словами, чтобы разобраться в коде Ansible или Chef, вам нужно знать историю всех изменений, которые когда-либо произошли.

•Процедурный код ограничивает повторное использование. Универсальность процедурного кода всегда ограничена, так как вам приходится самостоятельно учитывать текущее состояние инфраструктуры. Поскольку оно постоянно меняется, код, который вы использовали неделю назад, может оказаться неактуальным, если состояние инфраструктуры, на которое он был рассчитан, больше не существует. В итоге процедурные кодовые базы со временем разрастаются и усложняются.

Благодаря декларативному подходу Terraform код всегда описывает текущее состоя­ние вашей инфраструктуры. Вы можете с одного взгляда определить, что сейчас развернуто и как оно сконфигурировано, не заботясь об истории изменений или синхронизации. Это также облегчает написание кода, пригодного для повторного использования, поскольку вам не нужно самостоятельно учитывать текущее состояние окружающего мира. Вместо этого вы можете сосредоточиться лишь на описании нужного вам состояния, а Terraform автоматически сообразит, как к нему перейти. Поэтому кодовая база Terraform обычно остается компактной и понятной.

Конечно, у декларативного подхода есть свои недостатки. Отсутствие доступа к полноценному языку программирования сказывается на выразительности. Например, некоторые виды изменения инфраструктуры, такие как развертывание без простоя, сложно (но реально, как вы увидите в главе 5) выразить в чисто декларативном стиле. Аналогично ограниченные средства описания «логики» (такие как условные выражения и циклы) делают непростым написание универсального кода, который можно применять повторно. К счастью, Terraform предоставляет ряд мощных примитивов: входные и выходные переменные, модули, create_before_destroy, count, тернарный синтаксис и встроенные функции. Все это позволяет писать чистый, конфигурируемый, модульный код даже на декларативном языке. Мы вернемся к этим темам в главах 4 и 5.

Наличие или отсутствие центрального сервера

Chef, Puppet и SaltStack по умолчанию требуют наличия центрального (master) сервера для хранения состояния вашей инфраструктуры и распространения обновлений. Каждый раз, когда вы хотите что-то обновить в своей инфраструктуре, вам необходимо использовать клиент (например, утилиту командной строки), чтобы передать новые команды центральному серверу, который выкатывает обновления на все остальные серверы или позволяет им их загружать на регулярной основе.

У центрального сервера несколько преимуществ. Во-первых, это единое централизованное место, где вы можете просматривать и администрировать состояние своей инфраструктуры. У многих средств управления конфигурацией для этого даже есть веб-интерфейс (например, Chef Console, Puppet Enterprise Console), который помогает ориентироваться в происходящем. Во-вторых, некоторые центральные серверы умеют работать непрерывно, в фоновом режиме, обеспечивая соблюдение вашей конфигурации. Таким образом, если кто-то поменяет состояние узла вручную, центральный сервер может откатить это изменение, тем самым предотвращая дрейф конфигурации.

Однако использование центрального сервера имеет серьезные недостатки.

•Дополнительная инфраструктура. Вам нужно развернуть дополнительный сервер или даже кластер дополнительных серверов (для высокой доступности и масштабируемости).

• Обслуживание. Центральный сервер нуждается в обслуживании, обновлении, резервном копировании, мониторинге и масштабировании.

•Безопасность. Вам нужно сделать так, чтобы клиент мог общаться с центральным сервером, а последний — со всеми остальными серверами. Это обычно требует открытия дополнительных портов и настройки дополнительных систем аутентификации, что увеличивает область потенциальных атак.