×Закрыть

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

Привет! Я Денис Медведенко 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 окружении, то он попадет на продакшн.
— Решилась проблема безопасности. Если кто-то внесет изменения в инфраструктуру в ручном режиме, то при следующей проверке мы обнаружим это.
— Нашей инфраструктурой можно управлять из одной точки. То есть у нас один инструмент для внесения изменений. И это очень круто.
— Мы сократили временные трудозатраты на развертывание новой инфраструктуры.

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Нужен совет от автора). На данный момент меня беспокоит такая вещь, как нечаянный destroy из-за человеческого фактора. Например, Application Insights удаляется в hard режиме — таким образом, при удалении classic ресурса у нас улетают в бездну все метрики (а если пишем туда и логи, то они тоже). Второй вариант: создать Log Analytics workspace (который удаляется в soft режиме), подсунуть его в workspace-based Application Inisghts (preview фича) ресурс руками при создании, чтобы все данные летели в Log Analytics, и таким образом обезопасить себя. В Terraform’е же подключить его как data source, т.к. workspace-based Application Insights TF пока не поддерживает (что, в принципе, логично, если он ещё в preview Ажура). Как вообще правильно: полагаться на прямые руки и ограничение прав, или всё-таки подключать stateful ресурсы без soft delete как data source, чтобы не потерять данные? Пока я склоняюсь ко второму варианту.

еще наброшу ;)
Infrastructure as code — это здорово... но как все знают — код пишут девелоперы, значит DevOps не нужен? ;)

У девелоперов своих проблем хватает. И не все девелоперы разбираются в инфраструктурных вещах.

DevOps — это когда разработчик педалит код, педалит под него в облаке инфраструктуру и несет за это все ответственность. Если еще используется SRE — то тот же разработчик отвечает еще и за отказоустойчивость своего кода. Инфраструктурный инженер (сисадмин) при таком подходе несет роль эксперта — консультанта, а за одно роль ревьювера кода, экспертизы решений, планирования архитектуры. Но такой подход «это не про нас», у нас «все как всегда». Разраб педалит код, эфемерный DevOps — педалит окружения и деплой, а классические проблемы так и остаются проблемами и ничего не решается.

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

Если говорить в разрезе Ажура, то АРМ темплейты как-то не очень красиво смотрятся по сравнению с Тераформом, и они не такие гибкие. Но какждый выбирает сам под себя.
Тераформ охватывает довольно таки большей набор объектов Ажура и «костылей» с какждым годом все меньше и меньше.

Terraform — вещь хорошая, но только если часто происходит развертывание инфраструктуры. А такое происходит не особо часто. Поэтому некуда пристроить Терраформ, к сожалению...

Мы часто работаем с инфраструктурой. И реально помогает.

Привет, спасибо автору.. Статья хорошая , но очень поверхностная.. Готов помочь с продолжением =) Если есть желание взять меня в сооавторство

Наконец-то dou как dou. А то одна политика от 14 летних

Подписывайтесь на
t.me/dou_tech
где публикуется только технический контент.

Цікаво як ви дивитеся на використання Ansible замість Terraform?)

P.S. Дякую за статтю, було цікаво почути про використання Terraform з Azure

Ansible — крутой инструмент. Но на тот момент, когда мы начали использовать Terrafrom, Ansible не поддерживал тот функционал, который был нужен нам. Terrafrom был проще и поддерживал больше объектов Ажура.

Ansible

был крутым 10 лет назад ;) теперь он древний ;) и его использование для локального сетапа на каждой ноде еще можно как-то оправдать, но менеджить им клауд — костыль еще хуже терраформа ;) но лучше чем «рукам», да...

был крутым 10 лет назад ;)

и это особенно удивительно, учитывая тот факт, что ansible появился меньше 8 лет тому назад

не, все правильно ;)
Salt Stack — он как Ansible, только сделан правильнее(например апдейт 10к серваков будет идити одновременно. на Ansible, вероятно, и пробовать не стоит...)
Salt Stack — Initial release 19 March 2011 — 9 лет назад, поэтому что б быть крутым, Ansible должен был появиться 10 лет назад ;)

Та не, все еще крутой. Как и терраформ.
И ни тот ни другой не является костылем.

Мы используем Ансибл вместе(и из) с Терраформом. Ибо CM нужен.

Мы тоже используем Ansible, но не в разрезе создания инфраструктуры.

В них різні призначення, тому зазвичай використовуються паралельно.

Подписаться на комментарии