Автор курса Terraform База Павел Селиванов рассказывает о Terraform в условиях ухода «большой тройки» облаков с российского рынка, отечественных облачных сервисах и IaC.

Павел — архитектор Yandex Cloud, выстроивший десятки инфраструктур и написавший сотни пайплайнов CI/CD. Certified Kubernetes Administrator, автор нескольких курсов по Devops и Kubernetes.

Долгое время занимался внедрением Devops, сопровождением инфраструктуры и развитием сценариев на базе Terraform. Работал с Docker, Kubernetes, Ansible. Выстраивал внутренние и публичные облака в ряде крупнейших российских компаний. Сейчас Павел помогает клиентам, мигрирующим с «большой тройки», адаптировать их инфраструктуры под облако Яндекса и настраивать Terraform.

Материал подготовлен на основе профессиональной беседы по душам.

В 2022 году мы столкнулись с ситуацией, когда «большая тройка» облачных сервисов — Amazon Web Services (AWS), Google Cloud Platform (GCP) и Microsoft Azure — свернули свою деятельность в России. У них никогда не было дата-центров в нашей стране, но теперь они перестали принимать оплату от российских компаний. Да и наше законодательство давно подстраивается под хранение персональных данных исключительно в России, поэтому использовать иностранные облака для 100% архитектуры стало еще более проблематично.

Когда зарубежные облака перестали принимать наши карты, перед многими бизнесами возникла срочная необходимость мигрировать свою инфраструктуру в Россию. К счастью, рынок отечественных облачных сервисов очень большой. Самыми крупными считаются Yandex Cloud, VK Cloud и SberCloud. Можно сказать, это наша «большая тройка». Еще есть Selectel, КРОК, MTS Cloud, DataLine — список можно продолжать достаточно долго. Хотя не все так радужно. 

Российские облачные сервисы вступили в игру совсем недавно в отличие от западной «большой тройки», которая существует много лет. Кроме того, AWS, GCP и Azure работают на весь мир и приносят больше денег своим инвесторам, следовательно, те вкладываются в развитие облачной инфраструктуры гораздо охотнее. Отечественные облака только-только выходят на СНГ, поэтому не могут развиваться так же быстро, как западные.

Однако нашим сервисам нужно отдать должное: за последнюю пару лет они выросли из простого «запусти виртуалочку на VMware, натыкай в интерфейсе и привяжи IP-адрес» в полноценно функционирующие облака. Конечно, количество сервисов сильно уступает иностранным игрокам, но это все-таки уже не просто хостинги. Нашими облаками сейчас можно спокойно пользоваться, выстраивать сценарии, применять workaround-ы; благодаря связке сервисов делать даже то, чего облако изначально не предлагает. Уровень явно подрос.

Мы выяснили, что мигрировать на российские облачные сервисы можно. Но возникает вопрос: будет ли Terraform работать после переезда? Мгновенный ответ — да, будет. Но с некоторыми деталями, которые обсудим позже. Сначала поговорим о том,

Что такое Terraform

Terraform — один из инструментов управления инфраструктурой, имплементирующий концепцию Infrastructure as Code (IaC). Этот инструмент позволяет создавать описание инфраструктуры в виде текстовых файлов и затем выстраивать инфраструктуру из этих файлов. Другими словами, Terraform — это оркестратор.

Небольшое дополнение. Стоит различать оркестрацию и управление конфигурациями (configuration management). Terraform как инструмент оркестрации нужен для создания инфраструктуры, в которую входят: виртуальные машины, сети, подсети, роутеры, DNS-ы, БД, кластеры БД, Managed Kubernetes-ы. К инструментам управления конфигурациями относится, например, Ansible. Он нужен, чтобы настроить инфраструктуру после ее создания. Это совершенно другой тип задач.

При чем здесь вообще Ansible? Во-первых, в связке с этим инструментом Terraform работает в разы эффективнее. Во-вторых, когда говорят об Infrastructure as Code, в первую очередь вспоминают об Ansible как об одном из самых популярных инструментов в подходе IaC. Мы можем заменить Ansible на Chef, Puppet или SaltStack, но сути это не поменяет: все эти инструменты относятся к управлению конфигурациями и не заменяют Terraform. Дополняют, но не заменяют.

Вернемся к принципам работы Terraform. Для управления инфраструктурой ему нужно некое API этой инфраструктуры. Есть провайдеры — то, что умеет взаимодействовать с конкретным API конкретной инфраструктуры. Благодаря провайдерам Terraform может превращать то, что написано в виде текста (as code) в инфраструктуру (infrastructure). Terraform применяется в облачной инфраструктуре, потому что именно облачные провайдеры предоставляют API для создания и управления инфраструктурой.

Массово предоставлять полноценный API начали сервисы «большой тройки». До этого были просто UI-интерфейсы, куда админ мог прийти и потыкать кнопочки. AWS, GCP и Azure, собственно, и популяризировали работу с Terraform. Зачем именно полноценный API? Возьмем AWS: его интерфейс — огромная структура, в которой непросто разобраться. Иногда куда проще взять готовые модули Terraform, чем натыкать то, что нужно. Особенно если работать в более-менее большой инфраструктуре.

Для Terraform не важно, с какой облачной инфраструктурой взаимодействовать. Провайдеры, дающие возможность работать с API, есть как под «большую тройку», так и под облачные продукты OpenStack и VMware, а также под часть российских облаков. И здесь мы плавно переходим к следующему вопросу:

Актуален ли Terraform в России

Многие отечественные облачные сервисы построены на технологиях OpenStack и VMware, о которых упоминалось выше: их стандартные провайдеры подойдут для работы с российскими облаками. OpenStack, к тому же — опенсорсная система, которую может установить и использовать кто угодно. В России есть несколько облаков на OpenStack: VK Cloud, Selectel. Провайдеры VMware предоставляют API не слишком часто, но такое случается.

Крупнейшие игроки российского рынка (Yandex Cloud, VK Cloud) активно пилят свои собственные технологии и провайдеры для Terraform. Они понимают, что полноценное облако, способное конкурировать с «большой тройкой», на ванильных опенсорсных технологиях не построить.

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

Terraform все так же актуален для работы с российскими облачными сервисами

Стоит добавить, что Terraform может работать и без облака. Дело в том, что до сих пор не все компании в России перешли на облачную инфраструктуру. У таких бизнесов на горизонте появляется дилемма: облака нет, а Terraform использовать хочется или нужно (при миграции с западных облаков, например). Встает несколько выборов. 

1. Создать внутреннее облако. На своем железе можно прекрасно развернуть тот же OpenStack, чтобы точно так же создавать виртуальные машины, роутеры, диски и т. д. Terraform умеет этим эффективно управлять.

2. Работать с bare metal. Если приватного облака не предусмотрено, можно найти в документации Terraform провайдеры для работы с bare metal инфраструктурой. Функционал может быть урезан по сравнению с облачными провайдерами, но Terraform здесь все еще очень полезен.

Вообще, в 2022 году история с bare metal выглядит несерьезно. Если раньше бизнесы могли выжить, развернув некую инфраструктуру не в стадии активной разработки (потому что есть приложение для бэк-офиса, приложение учета, приложение для автоматизации деятельности и заказанный на стороне сайт), то сейчас это уже невозможно.

Компании, которые еще не поняли, что они IT-компании, либо скоро это осознают и начнут развивать IT, либо вымрут в ближайшие 5 – 10 лет.

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

Бывает, что «железная» инфраструктура сохраняется. Например, когда внутренний отдел безопасности или требования законодательства не позволяют использовать облака. Даже в таком случае компании приходят к использованию облачной инфраструктуры: переносят в нее некритичные части своего бизнеса и используют как некий буст скорости разработки. Кстати, о бусте.

Случай из практики. Как подход Infrastructure as Code помог бустануть бизнес. Было время, когда инженеры управляли инфраструктурой и сотнями виртуалок вручную. Причем каждую создавали и конфигурировали руками по инструкциям в Вики: как настроить БД, как настроить сервер под nginx и т. д. Это был хаос, который требовал постоянной работы шести человек. В переход на IaC было вложено немало сил и времени (3 – 6 месяцев), но после перехода вся система отлично управлялась двумя специалистами, а создание инфраструктуры под новый сервис начало занимать меньше часа. Теперь работа стала выглядеть так: на задачу создать инфраструктуру производился запуск автоматизации, которая создавала новые сервера и настраивала всю инфраструктуру.

Мы разобрались, зачем нужен Terraform при работе с инфраструктурой. Но есть проблема: этот инструмент оказался под угрозой блокировки своим создателем HashiCorp. Несмотря на то, что Terraform — опенсорсная утилита, всей инфраструктурой вокруг него владеет компания-создатель. Сюда входят сайты с документацией, провайдеры и модули в registry. HashiCorp как частная компания имеет право закрыть доступ к своей инфраструктуре.

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

Альтернативы для Terraform

Альтернативы действительно есть. Расскажем о двух самых раскрученных на сегодняшний день: Pulumi и Crossplane. Обе системы позволяют превращать инфраструктуру в код. Но надо иметь в виду, что под капотом у них все равно используется Terraform, — настолько это удобный инструмент. Его можно автоматизировать, где-то сделать красивее с помощью надстроек, но непосредственную работу все равно будет выполнять Terraform. 

То же произошло с Kubernetes, чьи альтернативы в виде Rancher и OpenShift основаны на нем же.

Pulumi позволяет описывать инфраструктуру на любимом языке программирования. Если посмотреть в документацию, их можно найти много: Python, Go, Node.js и т. д. Инструмент поддерживает самые популярные языки, поэтому программистам удобно описывать инфраструктуру. Но есть и недостаток: для не-программиста порог входа повышается, потому что работа с Pulumi требует умения программировать.

Crossplane преобразует ресурсы облака в объекты кластера Kubernetes. Точно так же, как в K8S деплоятся pod-ы, deployment-ы, сервисы, ingres-ы, с помощью этого инструмента можно задеплоить туда манифест виртуальной машины, сети и подсети, DNS-а, Managed Kubernetes кластера. Crossplane читает эти манифесты и применяет их к облаку.

Сейчас эти двое — основные жизнеспособные альтернативы Terraform, так что если все актуальные ограничения вокруг этого инструмента не устраивают, то имеет смысл посмотреть в сторону Pulumi и Crossplane. В будущем они продолжат развиваться не только в России, но и в мире. Кстати, о будущем.

Что будет с Terraform дальше

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

Здесь можно провести аналогию с Ассемблером или C. Несмотря на то, что они еще есть, и в них может так или иначе транслироваться код, мы все же работаем с фреймворками и высокоуровневыми языками программирования. А эти языки нужны для работы, с которой среднестатистический программист обычно не сталкивается.

Возможно, с Terraform произойдет то же: он станет выполнять функции своеобразного низкоуровневого языка описания инфраструктуры, поверх которого будут работать высокоуровневые языки и фреймворки. Однако полноценно заменить Terraform в обозримом будущем не сможет ни один аналог.

Пара слов о недостатках

Когда что-то становится кодом, это хочется использовать как код. Но у Terraform (в сущности, как у любого другого инструмента IaC) есть свой собственный язык, который не на 100% покрывает все, что можно сделать на языке программирования. При использовании инструмента можно столкнуться с кучей заморочек: как сделать if-ы или циклы, как повторить что-то несколько раз. Все это есть в документации, но найти с первой попытки сложно. Особенно на старте.

Заключительный совет

При работе с Terraform рекомендуем не забывать про приставку as Code. Она сообщает не только о том, что описание инфраструктуры превращается в текст, но и о том, что с ним надо работать, как с кодом: тестировать, применять статический анализ, применять gitflow и автоматизировать (CI/CD пайплайны, процесс доставки, canary releases).

Infrastructure as Code — это не только инфраструктура, превращенная в текст; полезно помнить, что теперь с этим текстом (который на самом деле код) необходимо работать соответствующе — как с кодом.