Terraform: инфраструктура на уровне кода — страница 9 из 65

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

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

Рис. 1.8. Terraform использует архитектуру, не требующую наличия центральных серверов и агентов. Вам достаточно лишь запустить клиент Terraform, а тот уже позаботится обо всем остальном, применяя API облачных провайдеров, таких как AWS

Размер сообщества

Вместе с технологией вы выбираете и сообщество. Во многих случаях впечатления от использования проекта могут в большей степени зависеть от экосистемы вокруг него, чем от качества самой технологии. Сообщество определяет то, сколько людей помогают проекту, сколько у него подключаемых модулей и расширений, насколько просто получить помощь в Интернете (например, посредством статей или вопросов на StackOverflow) и проблематично ли нанять того, кто мог бы вам помочь (вроде работника, консультанта или компании технической поддержки).

Сложно провести точное сравнение между разными сообществами, но вы можете заметить некоторые тенденции, используя поисковую систему. В табл. 1.1 сравниваются популярные средства IaC с использованием данных, которые я собрал в мае 2019 года. Здесь учитывается, имеет ли инструмент открытый исходный код, с какими провайдерами он совместим, общее количество участников проекта и звезд в GitHub, сколько фиксаций кода и активных заявок было с середины апреля до середины мая, сколько открытых библиотек доступно для этого инструмента, количество вопросов о нем на StackOverflow и в скольких вакансиях на Inde­ed.com он упоминается11.

Естественно, это неидеальное сравнение равнозначных показателей. Например, некоторые инструменты имеют больше одного репозитория, а некоторые используют другие методы для отслеживания ошибок и вопросов. Поиск вакансий по таким общеупотребимым словам, как chef или puppet, нельзя считать надежным. В 2017 го­ду код провайдеров Terraform был разделен по отдельным репозиториям, поэтому оценка активности лишь по основному репозиторию будет крайне заниженной (минимум в десять раз).

Таблица 1.1. Сравнение сообществ IaC121314151617181920212223

Инструмент

Код

Облака

Участ­ники

Звезды

Фиксации (30 дней)

Заявки (30 дней)

Библио­теки

Stack­Over­flow

Вакансии

Chef

Откр.

Все

562

5794

435

86

38322

5982

43783

Puppet

Откр.

Все

515

5299

94

3144

61105

3585

42006

Ansible

Откр.

Все

4386

37 161

506

523

20 6777

11 746

8787

SaltStack

Откр.

Все

2237

9901

608

441

3188

1062

1622

CloudFormation

Закр.

AWS

?

?

?

?

3779

3315

3218

Heat

Откр.

Все

361

349

12

60010

011

88

220112

Terraform

Откр.

Все

1261

16 837

173

204

146213

2730

3641

Тем не менее некоторые тенденции очевидны. Во-первых, все средства IaC в этом сравнении имеют открытый исходный код и совместимы со многими облачными провайдерами; исключение составляет проект с закрытым исходным кодом CloudFormation, который работает только с AWS. Во-вторых, в плане популярности лидирует проект Ansible, за которым с небольшим отставанием следуют Salt и Terraform.

Еще одна интересная тенденция — все эти цифры поменялись с момента выхода первого издания. В табл. 1.2 показано относительное изменение каждого показателя по сравнению с той информацией, которую я собрал в сентябре 2016 года.

Таблица 1.2. Как изменились сообщества IaC с сентября 2016 по май 2019 года

Инструмент

Код

Облака

Участники

Звезды

Фиксации (30 дней)

Заявки (30 дней)

Библиотеки

StackOverflow

Вакансии

Chef

Откр.

Все

+18 %

+31 %

+139 %

+48 %

+26 %

+43 %

–22 %

Puppet

Откр.

Все

+19 %

+27 %

+19 %

+42 %

+38 %

+36 %

–19 %

Ansible

Откр.

Все

+195 %

+97 %

+49 %

+66 %

+157 %

+223 %

+125 %

SaltStack

Откр.

Все

+40 %

+44 %

+79 %

+27 %

+33 %

+73 %

+257 %

CloudFor­mation

Закр.

AWS

?

?

?

?

+57 %

+441 %

+249 %

Heat

Откр.

Все

+28 %

+23 %

–85 %

+1566 %

0

+69 %

+2957 %

Terraform

Откр.

Все

+93 %

+194 %

–61 %

–58 %

+3555 %

+1984 %

+8288 %

Это неидеальные данные, но их достаточно, чтобы заметить четкую тенденцию: Terraform и Ansible испытывают взрывной рост. Увеличение количества участников, звезд, открытых библиотек, вопросов на StackOverflow и вакансий просто зашкаливает24. Сегодня оба инструмента имеют большие и активные сообщества, которые, судя по приведенным выше тенденциям, продолжат расти.

Выбор между зрелостью и новизной

Еще один ключевой фактор при выборе любой технологии — ее зрелость.

В табл. 1.3 приводятся даты выпуска начальной версии каждого инструмента IaC и их версии на данный момент (по состоянию на май 2019 года).

Таблица 1.3. Сравнение инструментов IaC в плане зрелости по состоянию на май 2019 года

Инструмент

Начальный выпуск

Текущая версия

Puppet

2005

6.12.0

Chef

2009

13.1.58

CloudFormation

2011

???

SaltStack

2011

3000

Ansible

2012

2.9.5

Heat

2012

13.0.0

Terraform

2014

0.12.21

Здесь сравниваются не совсем равнозначные вещи, поскольку разные инструменты используют разные методы управления версиями, но некоторые тенденции бросаются в глаза. Terraform, безусловно, является самым молодым инструментом IaC в этом сравнении. Он все еще не достиг версии 1.0.0, поэтому не ожидайте гарантий стабильного или обратно совместимого API, и программные ошибки встречаются относительно часто (хотя большинство из них незначительные). Это самое слабое место Terraform: несмотря на достижение огромной популярности за короткое время и применение передовых технологий, это менее зрелый проект по сравнению с некоторыми другими средствами IaC.

Совместное использование нескольких инструментов

Я сравнивал разные инструменты IaC на протяжении всей этой главы, но в реальности при построении своей инфраструктуры вам, скорее всего, придется работать сразу с несколькими из них. У каждого представленного здесь инструмента есть свои сильные и слабые стороны, и вы должны выбрать подходящий для ваших задач вариант.

Далее описываются три распространенные комбинации, которые хорошо себя проявили в ряде компаний.

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

Пример: Terraform и Ansible. Terraform используется для развертывания всей внутренней инфраструктуры, включая топологию сети (то есть виртуальные частные облака (virtual private cloud, или VPC), подсети, таблицы маршрутизации), хранилища данных (MySQL, Redis), балансировщики нагрузки и серверы. Ansible берет на себя развертывание ваших приложений поверх этих серверов, как показано на рис. 1.9.

Рис. 1.9. Совместное использование Terraform и Ansible

Этот подход позволяет быстро приступить к работе, поскольку вам не нужна никакая дополнительная инфраструктура (Terraform и Ansible — сугубо клиентские приложения) и оба инструмента можно интегрировать множеством разных способов (например, Terraform назначает вашим серверам специальные теги, которые Ansible использует для поиска и конфигурации этих серверов). Основной недостаток состоит в том, что применение Ansible обычно подразумевает много процедурного кода и изменяемые серверы, поэтому расширение кодовой базы, инфраструктуры и вашей команды может осложнить обслуживание.

Инициализация ресурсов плюс шаблонизация серверов

Пример: Terraform и Packer. Packer используется для упаковки ваших приложений в виде образов ВМ. Затем Terraform развертывает: а) серверы с помощью этих образов; б) всю остальную инфраструктуру, включая топологию сети (то есть VPC, подсети, таблицы маршрутизации), хранилища данных (как MySQL, Redis) и балансировщики нагрузки. Это проиллюстрировано на рис. 1.10.

Рис. 1.10. Совместное применение Terraform и Packer

Этот подход тоже позволяет быстро приступить к работе, так как вам не нужна никакая дополнительная инфраструктура (Terraform и Packer являются сугубо клиентскими приложениями). Позже в этой книге вы сможете вдоволь попрактиковаться в развертывании образов ВМ с помощью Terraform. Кроме того, вы получаете неизменяемую инфраструктуру, что упростит ее обслуживание. Однако у этой комбинации есть два существенных недостатка. Во-первых, на сборку и развертывание образов ВМ может уходить много времени, что замедлит выпуск обновлений. Во-вторых, как вы увидите в последующих главах, Terraform поддерживает ограниченный набор стратегий развертывания (например, сам по себе этот инструмент не позволяет реализовать «сине-зеленые» обновления), поэтому вам придется либо написать много сложных скриптов, либо обратиться к средствам оркестрации, как это будет показано далее.