Как использовать Terraform для управления сложными многокомпонентными инфраструктурами в Azure

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Привет! Я Денис Медведенко Senior DevOps Engineer в Wirex. В этой статье я хочу поделиться нашим опытом использования Terraform при разработке нашего финтех-продукта, который объединяет традиционные и цифровые валюты в одном приложении. Как показывает практика, в основном разработчики используют Terraform для AWS, и очень мало компаний применяют его для Azure. В этом материале я расскажу, что можно делать в Azure при помощи Terraform, какие мы получаем преимущества. А также объясню, какие возникают трудности при переходе на этот инструмент, и как Terraform помогает в работе компаниям, которые реально хотят использовать Azure и подход Infrastructure as code.

Когда наша компания только начинала свое существование, наша инфраструктура состояла из очень простых объектов Azure таких, как виртуальные машины, load balancers, сети, сторадж аккаунты и даже клауд сервисы. Тогда никто и не думал о таком подходе как Infrastructure as code, и соответственно все объекты создавались руками.

Особенности подготовки инфраструктуры до перехода на Terraform

Как же мы раньше готовили инфраструктуру? Например, если мы хотели внедрить какую-то фичу, то аналитики, девелоперы, архитекторы обсуждали архитектуру и требования. Затем готовили документацию, которая содержала описание архитектуры и то, как фича должна работать, с чем она должна взаимодействовать и т.д. После чего документацию выдавали DevOps инженерам и разработчикам. Девопсы, в свою очередь, готовили инфраструктуру и вносили изменения в CI/CD пайплайны.

Обычно, разворачивание инфраструктуры происходило без какой-либо автоматизации, по инструкциям, шаг за шагом в ручном режиме, иногда готовили скрипты. Сначала развертывание и тестирование происходило на dev окружении, затем на UAT окружении и, в заключении, на Prod.

Подготовка инфраструктуры до перехода на Terraform

Со временем, когда наша компания начала расти, наша инфраструктура тоже начала увеличиваться. Azure начал предоставлять новые фишки, и уже стало неудобно работать на обычных виртуальных машинах. Поэтому мы начали продумывать микросервисную архитектуру, которую нам удалось реализовать с помощью Azure Service Fabric. Были добавлены virtual machine scale sets, application gateways, load balancers, новые сети, множество новых правил на фаерволах, storage accounts и другое. И, понятное дело, что деплоить такой объем объектов в ручном режиме уже становилось невозможно.

Поэтому наш подход изменился. Описание архитектуры осталось прежним, это же касается и подготовки требований, — DevOps инженеры продолжали готовить те же скрипты и инструкции. Но появился один очень важный шаг — мы добавили разворачивание и описание инфраструктуры в Terraform. Начинали работать с 11 версий, но недавно мигрировали на 12-ю версию. Начинали с малого — с разворачивания самых простых объектов Azure с помощью Terraform таких, как load balancers, storage accounts, scale sets, виртуальных машин.

Постепенно мы хотели автоматизировать развертывание всей нашей инфраструктуры. И благодаря Terraform мы это сделали. Мы импортировали в Terraform практически всю инфраструктуру, и привели ее к модулям. Это позволило нам создавать новые окружения в разы быстрее, по сравнению с ручным развертыванием инфраструктуры. Ведь каждая команда разработчиков требовала под себя отдельную среду для разработки какой-то фичи, чтобы не мешать друг другу. И благодаря Terraform мы смогли деплоить несколько окружений одновременно и уменьшили время подготовки каждого окружения. Количество наших окружений увеличилось в разы, вместо одного dev и UAT окружений мы развернули много окружений на каждую команду разработчиков.

Подготовка инфраструктуры при помощи Terraform

Из чего состоит Terraform для использования в Azure

Теперь я расскажу, как у нас построен Terraform, как у нас построены модуля, и что мы добавляли в них.

Начнем с сетевой инфраструктуры. Каждое окружение имеет свой пул сетей, все сети имеют свой фаервол со своими правилами. Одни сети — публичные, другие — приватные, часть сетей взаимодействует между собой, еще часть имеет vpn туннели к другим программным продуктам. В общем, каждая сеть уникальна. Все фаервольные правила на всех окружениях одинаковые, что достигается за счет модулей.

Сетевая инфраструктура

Справа на картинке представлена сетевая структура окружения: набор сетей (network), набор пирингов между разными сетями (network_peering), ресурсная группа (resource_group) и секьюрити группа (security_group). Ниже мы видим модуля для ресурсной группы (RG) и секьюрити группы (NSG). Модули упрощают жизнь при работе с Terraform. Все что повторяется на всех окружениях мы выносим в модуль. В данном случае описание ресурсной группы и все правила фаерволов вынесены в модули. А в окружении (Dev-01) в модуль передаются только имена для ресурсной группы, сети которым нужно открыть фаервол и ip адреса.

Если мы знаем, что нам нужно будет на всех окружениях открыть порт ХХХХ, то мы его пропишем в модуле, а так как все окружения ссылаются на этот модуль, то порт ХХХХ автоматически появится в изменениях на всех окружениях. Таким образом мы вносим изменение в одном месте, в модуле, а это изменение появляется на всех окружениях.

То же самое в нашей вычислительной инфраструктуре. Она состоит из Azure Service Fabric, он в свою очередь состоит из большого количества virtual machine scale set’ов, у каждого scale set’а есть по два балансировщика — internal и public. Эти балансеры состоят из большого количества правил и проб. И создавать руками эти правила, и такое количество scale set’ов очень ресурсозатратно и неудобно.

Вычислительная инфраструктура

Используя модуля в Terraform под наши ресурсы, такие как Service Fabric, scale sets, балансировщики и другие, мы ускоряем разворачивание и упрощаем внесение каких-либо изменений в окружения.

Использование подхода Infrastructure as a Code в разы сократило нам время разворачивания окружения и внесения изменений. И мы не мучаемся тем, что где-то что-то забыли развернуть.

Также мы используем много дополнительных компонентов для каждой инфраструктуры — application gateway, редис, базы данных, app service, traffic manager, key vault, service bus, очереди и другое.

С помощью Terraform можно в одном месте описать любой объект инфраструктуры и применить на все окружения.

Что в итоге нам дал Terraform?
— Он привел нашу инфраструктуру к единой политике именования. Теперь все объекты на всех окружения называются одинаково, единственное чем они отличаются — это приставкой номера окружения.
— У нас вся инфраструктура описана в одном месте.
— Консистентность окружения. Это то, к чему мы и стремились. Теперь dev соответствует продакшену. И мы точно знаем, если мы открыли порт или добавили правило в балансировщик на dev окружении, то он попадет на продакшн.
— Решилась проблема безопасности. Если кто-то внесет изменения в инфраструктуру в ручном режиме, то при следующей проверке мы обнаружим это.
— Нашей инфраструктурой можно управлять из одной точки. То есть у нас один инструмент для внесения изменений. И это очень круто.
— Мы сократили временные трудозатраты на развертывание новой инфраструктуры.