rm для описания кучи серверов, баз данных, балансировщиков нагрузки и другой инфраструктуры в AWS, можете ли вы несколькими щелчками кнопкой мыши развернуть все это в другом облаке, таком как Azure или Google Cloud?
На практике этот вопрос оказывается не совсем корректным. Вы не можете развернуть «идентичную инфраструктуру» в разных облаках, поскольку инфраструктура, предоставляемая облачными провайдерами, разнится! Серверы, балансировщики нагрузки и базы данных, предлагаемые в AWS, Azure и Google Cloud, сильно различаются с точки зрения возможностей, конфигурации, управления, безопасности, масштабируемости, доступности, наблюдаемости и т. д. Не существует простого и прозрачного способа преодолеть эти различия, особенно учитывая то, что некоторые функции одного облачного провайдера часто отсутствуют во всех остальных.
Подход, который используется в Terraform, позволяет писать код для каждого провайдера отдельно, пользуясь его уникальными возможностями; при этом внутри для всех провайдеров применяются тот же язык, инструментарий и методики IaC.
Сравнение Terraform с другими средствами IaC
Инфраструктура как код — замечательная идея, чего нельзя сказать о процессе выбора инструментов IaC. Многие из них пересекаются в своих возможностях, имеют открытый исходный код и предоставляют коммерческую поддержку. Если вы не использовали каждый из них лично, не совсем понятно, по каким критериям следует выбирать.
Все усложняется тем, что большинство сравнений этих инструментов, которые вы найдете, просто перечисляют их общие характеристики. В итоге может показаться, что выбор любого из них будет одинаково удачным. Хотя теоретически все действительно так, это никак не помогает с выбором. Это как если бы вы уверяли новичка в программировании в том, что сайт можно одинаково успешно написать на 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, который развертывается на группе новых узлов, а затем удаляете старые узлы. Поскольку при каждом развертывании используются неизменяемые образы и свежие серверы, этот подход уменьшает вероятность дрейфа конфигурации, упрощает отслеживание того, какое ПО установлено на каждом сервере, и позволяет легко развернуть любую предыдущую версию ПО (любой предыдущий образ) в любой момент. Это также повышает эффективность вашего автоматического тестирования, поскольку неизменяемый образ, прошедший проверку в тестовой среде, скорее всего, будет вести себя аналогично и в промышленных условиях.
Конечно, с помощью средств управления конфигурацией можно выполнять и изменяемые развертывания, но для них такой подход не характерен; в то же время для средств инициализации ресурсов он является вполне естественным. Стоит также отметить, что у неизменяемого подхода есть и недостатки. Например, даже в случае тривиального изменения придется заново собрать образ из шаблона сервера и снова развернуть его на всех ваших узлах, что займет много времени. Более того, неизменяемость сохраняется только до запуска образа. Как только сервер загрузится, он начнет производить запись на жесткий диск и испытывать дрейф конфигурации в той или иной степени (хотя это можно минимизировать, если делать частые развертывания).
Выбор между процедурными и декларативными языками
Chef и Ansible поощряют процедурный стиль — когда код пошагово описывает, как достичь желаемого конечного состояния. А вот Terraform, CloudFormation, SaltStack, Puppet и Open Stack Heat исповедуют более декларативный подход: вы описываете в своем коде нужное вам конечное состояние, а средства IaC сами разбираются с тем, как его достичь.
Чтобы продемонстрировать это различие, рассмотрим пример. Представьте, что вам нужно развернуть десять серверов (экземпляров, или инстансов,EC2 в терминологии AWS) для выполнения AMI с идентификатором ami-0c55b159cbfafe1f0 (Ubuntu 18.04). Так выглядит шаблон Ansible, который делает это в процедурном стиле:
- ec2:
count: 10
image: ami-0c55b159cbfafe1f0
instance_type: t2.micro
А вот упрощенный пример конфигурации Terraform, который делает то же самое, используя декларативный подход:
resource "aws_instance" "example" {
count = 10
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t2.micro"
}
На первый взгляд подходы похожи, и если выполнить их с помощью Ansible или Terraform, получатся схожие результаты. Но самое интересное начинается тогда, когда нужно что-то поменять.
Представьте, что у вас повысилась нагрузка и вы хотите увеличить количество серверов до 15. В случае с Ansible написанный ранее процедурный код становится бесполезным; если вы просто запустите его снова, поменяв значение на 15, у вас будет развернуто 15 новых серверов, что в сумме даст 25! Таким образом, чтобы добавить пять новых серверов, вам нужно написать совершенно новый процедурный скрипт с учетом того, что у вас уже развернуто:
- ec2:
count: 5
image: ami-0c55b159cbfafe1f0
instance_type: t2.micro
В случае с декларативным кодом нужно лишь описать желаемое конечное состояние, а Terraform разберется с тем, как этого достичь, учитывая любые изменения, сделанные в прошлом. Таким образом, чтобы развернуть еще пять серверов, вам достаточно вернуться к той же конфигурации Terraform и поменять поле count с 10 на 15:
resource "aws_instance" "example" {
count = 15
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t2.micro"
}
Если вы примените эту конфигурацию, Terraform поймет, что у вас уже есть десять серверов и нужно создать еще пять. Еще до применения конфигурации можно воспользоваться командой Terraform plan, чтобы увидеть, какие изменения будут внесены:
$ terraform plan
# aws_instance.example[11] will be created
+ resource "aws_instance" "example" {
+ ami = "ami-0c55b159cbfafe1f0"
+ instance_type = "t2.micro"
+ (...)
}
# aws_instance.example[12] will be created