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

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

В следующих разделах я подробно сравню самые популярные средства управления конфигурацией и инициализации ресурсов: Terraform, Chef, Puppet, Ansible, SaltStack, CloudFormation и OpenStack Heat. Моя цель — помочь вам определиться с тем, является ли Terraform хорошим выбором. Для этого я объясню, почему моя компания, Gruntwork (www.gruntwork.io), выбрала Terraform в качестве средства IaC и — в каком-то смысле — почему я написал эту книгу9. Как и с любым техническим решением, все сводится к компромиссам и приоритетам. Даже если ваши задачи отличаются от моих, надеюсь, что описанный здесь ход мыслей поможет вам принять собственное решение.

Вам придется выбирать между такими вещами, как:

• управление конфигурацией или инициализация ресурсов;

• изменяемая или неизменяемая инфраструктура;

• процедурный или декларативный язык;

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

• наличие или отсутствие агента;

• большое или маленькое сообщество;

• зрелость или новизна.

Или же совместно использовать несколько инструментов.

Управление конфигурацией или инициализация ресурсов?

Как упоминалось ранее, Chef, Puppet, Ansible и SaltStack управляют конфигурацией, тогда как CloudFormation, Terraform и OpenStack Heat инициализируют ресурсы. Это не совсем четкое разделение, так как средства управления конфигурацией обычно в какой-то степени поддерживают инициализацию ресурсов (например, вы можете развернуть сервер с помощью Ansible), а средства инициализации ресурсов занимаются какого-то рода конфигурацией (скажем, на каждом сервере, инициализированном с помощью Terraform, можно запускать конфигурационные скрипты). Поэтому следует выбирать тот инструмент, который лучше всего подходит для вашего случая10.

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

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

Выбор между изменяемой и неизменяемой инфраструктурой

Обычно в средствах управления конфигурацией, таких как Chef, Puppet, Ansible и SaltStack, по умолчанию применяется парадигма изменяемой инфраструктуры. Например, если приказать Chef установить новую версию OpenSSL, процесс обновления ПО запустится на существующем сервере, где и произойдут все изменения. Со временем обновления накапливаются, а вместе с ними и история изменений сервера. В итоге у каждого сервера появляются небольшие отличия по сравнению со всеми остальными серверами, что приводит к неочевидным ошибкам в конфигурации, которые трудно диагностировать и воспроизводить (та же проблема с дрейфом конфигурации, возникающая при ручном управлении серверами, хотя благодаря средствам управления конфигурацией у нее куда менее серьезные последствия). Их сложно обнаружить даже с использованием автоматических тестов. Измененная конфигурация может нормально работать в ходе тестирования и при этом вести себя совсем иначе на боевом сервере, который, в отличие от тестовой среды, месяцами накапливал обновления.

Если вы применяете средства инициализации ресурсов наподобие Terraform для развертывания системных образов Docker или Packer, большинство изменений будет заключаться в создании совершенно новых серверов. Например, чтобы развернуть новую версию OpenSSL, вы включаете ее в новый образ Packer, который развертывается на группе новых узлов, а затем удаляете старые узлы. Поскольку при каждом развертывании используются неизменяемые образы и свежие серверы, этот подход уменьшает вероятность дрейфа конфигурации, упрощает отслеживание того, какое ПО установлено на каждом сервере, и позволяет легко развернуть любую предыдущую версию ПО (любой предыдущий образ) в любой момент. Это также повышает эффективность вашего автоматического тестирования, поскольку неизменяемый образ, прошедший проверку в тестовой среде, скорее всего, будет вести себя аналогично и в промышленных условиях.