Введение в Терраформу

Когда мне в первый раз объяснили, что такое Terraform, я, наверное, отключился сразу после того, как понял, что речь идет не об изменении атмосферы соседней планеты. Я проработал инженером чуть меньше года и все еще был довольно непосвященным в DevOps-технологии. С тех пор у меня была возможность вернуться к этой технологии и использовать ее в качестве разработчика, и я подумал, что мой пример использования может стать хорошим введением для тех, кому, как и мне, трудно разобраться в ней!

Что это такое?

Terraform в своей основе — это набор файлов (конфигурация), которые при правильном использовании могут управлять всей вашей инфраструктурой из одного места. Terraform поддерживает множество IaaS, PaaS и SaaS сервисов через провайдеров, которые могут быть созданы и управляться Hashicorp или сделаны на Golang сообществом. Провайдеры работают как интерпретаторы для вашей конфигурации, которые взаимодействуют с API сервиса или платформы, над которой вы работаете.

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

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

  1. Обновить текущее состояние с тем, что вы имеете в реальном мире

    terraform refresh

  2. Вывести и зафиксировать то, что будет обновлено или добавлено в реальный мир в соответствии с вашей конфигурацией

    terrafrom plan

  3. Фактически произвести эти изменения через провайдера

    terraform apply

  4. Уничтожить ранее выделенные ресурсы.

    terraform destroy

Terraform может управлять инфраструктурой всей вашей платформы, от CI/CD до сетей и безопасности, но чтобы не усложнять ситуацию, я сосредоточусь на примере использования Terraform для управления предоставлением ресурсов AWS.

Пример AWS

Когда вы только начинаете изучать инфраструктуру для небольшого веб-приложения, вы можете подумать: «Почему Terraform — это такая важная вещь? Разве большинство платформ не позволяют довольно легко настроить базу данных или создать виртуальную машину?». Ответ на это приходит довольно быстро, когда ваша сложность начинает расти и количество поваров на кухне должно увеличиваться.👩🍳

Рассмотрим команду из трех человек с приложением, которое собирает немного данных о клиенте, создает поверхность статического документа для загрузки и сохраняет данные пользователя в базе данных. Вам необходимо поддерживать несколько служб. Возможно, экземпляр EC2 для размещения вашей внутренней службы API, экземпляр RDS для базы данных и ведра S3 для хранения приложения React и статических файлов, которые нужно предоставить клиенту для загрузки.

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

Теперь предположим, что в течение нескольких месяцев с нашей воображаемой командой произойдет несколько ключевых событий:

  • Клиентская база растет (хорошая проблема, которую нужно решать)🚀.
  • Появляется новый тип клиентов, которым требуется:✨
    • Новый путь в веб-приложении
    • Новый микросервис для обработки даты для нового типа клиентов.
  • В связи с изменением требований законодательства, ранее статичные документы теперь должны содержать данные, специфичные для клиента, и храниться📃.

К этому времени они уже создали несколько новых сервисов в AWS для обработки всех новых функций, включая несколько новых ведер S3 и AWS Lambda для обработки генерации документов. Они даже контейнеризировали внутреннее приложение, управляя им с помощью ECS, и планируют интегрировать новый микросервис таким же образом.

Перед лицом этой новой сложности они удваивают численность своей инженерной команды. Теперь они хотят создать идентичные окружения для staging и QA.👷.

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

Это именно тот тип сложности, который решает Terraform. После принятия решения о стратегии управления для разделения сред в коде Terraform наша команда может запустить terraform refresh для обновления файла (или файлов) состояния в соответствии с текущей средой. Когда новый микросервис будет готов к настройке, его тоже можно инициализировать из конфигурационных файлов. Если требуется более высокий уровень безопасности для ведер S3, команда может сначала добавить это в тестовую среду, чтобы убедиться, что все будет работать при изменении разрешений или правил CORS, а затем применить это точно так же в производственной среде.

Если требуется больший контроль над тем, как и когда применяется Terraform, можно установить Terraform Cloud, который также включает в себя контроль версий конфигурационных файлов. ☁️

Прежде чем закончить, я хочу отметить, что AWS предоставляет своего рода Infrastructure-as-Code решение для этого с CloudFormation, однако оно кажется ограниченным по ряду параметров, включая ограничение только управлением инфраструктурой AWS, не поддерживаются циклы или условные выражения, и в нем отсутствует функция безопасности terrafrom plan.

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

(Я создал изображение для заголовка с помощью MidJourney!)

Оцените статью
devanswers.ru
Добавить комментарий