Или как построить простую архитектуру в Terraform
Если вы следили за моим путешествием, этот проект может показаться немного знакомым. Ранее я завершил проект с использованием AWS CloudFormation и YAML для создания примера трехуровневой архитектуры. На этот раз мы сократим его до двух уровней, и это будет сделано в Terraform.
Что такое Терраформ?
Проще говоря, Terraform — это инструмент «инфраструктура как код» (IaC), который позволяет создавать целые архитектуры независимо от того, какой провайдер вы используете (AWS, GCP, Azure и т. д.). Подобно CloudFormation, в котором вы создаете «шаблон» для запуска, Terraform использует центральный документ для перечисления точек данных и ресурсов для создания.
Что мы строим?
Перед нами стояла задача построить двухуровневую архитектуру со следующими характеристиками:
- VPC с CIDR 10.0.0.0/16
- 2 общедоступные подсети с CIDR 10.0.1.0/24 и 10.0.2.0/24. Все в разных зонах доступности для обеспечения высокой доступности.
- 2 частные подсети с CIDR 10.0.3.0/24 и 10.0.4.0/24. Все в разных зонах доступности для обеспечения высокой доступности.
- Экземпляр RDS MySQL в одной из частных подсетей.
- Балансировщик нагрузки, который будет направлять трафик в общедоступные подсети.
- Экземпляр EC2 t2.micro в каждой общедоступной подсети.
Что мне нужно?
- Учетная запись AWS с правами администратора
- Доступ к Документации Terraform
- IDE/терминал по вашему выбору. (Я использую комбинацию Visual Code Studio и Cloud9)
- Terraform установлен в вашей среде IDE или на локальной рабочей станции.
Пойдем!!
Для этого проекта мы собираемся немного запутаться и создадим «монолитный» файл Terraform (tf). Это просто означает, что все наши ресурсы, точки данных и т. д. будут в одном файле. Tf допускает более модульную конструкцию, позволяя инженеру разделять элементы на разные документы, но мы просто собираемся создать зверя для этого проекта.
Я рекомендую создать новый каталог для вашего проекта Terraform, так как при его запуске будет создано несколько файлов/папок. Но на данный момент простые 1,2,3 приведут нас туда, где мы должны быть:
mkdir <projectname>cd <projectname>touch main.tf
Файл main.tf — это то, что мы будем редактировать.
Провайдер
Здесь мы сообщаем tf, какой сервис мы будем использовать. Обратите внимание, что у вас может быть несколько провайдеров (на самом деле, это одна из прелестей tf), но сейчас мы просто собираемся использовать AWS.
VPC
Далее мы собираемся создать наш VPC. Это будет наша среда, содержащая все наши компоненты. Сразу после этого мы продолжим и создадим наши подсети:
Подсети легко переключаются с общедоступных на частные с помощью элемента map_public_ip_on_launch. Элемент vpc_id гарантирует, что подсети находятся внутри нашего созданного VPC. Приведенный выше код также показывает, как мы можем вручную назначить каждую подсеть отдельной зоне доступности для надежности.
Таким образом, мы получили «скелет» нашего маленького проекта, так что теперь давайте добавим несколько органов!
Экземпляры
Проекту, моделирующему двухуровневую архитектуру, требуется экземпляр RDS MySQL в частной подсети для нашего «уровня базы данных» и пара экземпляров EC2 в общедоступных подсетях, которые будут выступать в качестве нашего «веб-уровня». В следующем коде также показаны некоторые дополнительные элементы, которые необходимо было создать, такие как пара ключей для экземпляров EC2, группа безопасности для них и группа подсети для экземпляра RDS.
Группу безопасности мы рассмотрим в следующем разделе, а пока давайте рассмотрим RDS. Как и в случае с 99% этого проекта, мы можем обратиться к реестру Terraform за документацией по всем этим элементам. Здесь есть пример кода, а также список всех компонентов (обязательных или необязательных), а также внутренние атрибуты, на которые можно ссылаться в выходных данных и т. д. Подставьте наши значения, и все готово! Отмечу, что создание/удаление RDS может занять довольно много времени, поэтому я изменил свой размер, чтобы он был намного меньше, чем в примере, который они предоставили, а также отключил multi-az, так как он мне не нужен для этого проекта.
Так много элементов говорят сами за себя, поэтому создание ресурса (например, изменение шаблона) стало довольно быстрым и простым.
Экземпляры EC2 были такими же, как их создание в консоли, AWS CLI или любым другим способом создания экземпляра EC2. Мы просто собираемся убедиться, что subnet_id и vpc_security_group_ids установлены правильно, в противном случае это *много* устранения неполадок. Я добавляю свой бутстрап в строку (хотя с более крупными скриптами бутстрапа его можно передать как файл или источник данных), и вот у нас есть наши экземпляры!
Интерфейс
Если бы экземпляры были нашими органами, то сетевые интерфейсы были бы подобны рту или глазам… воротам в нашу среду.
Шлюз
Первая часть, с которой на самом деле будет взаимодействовать пользователь или клиент, — это интернет-шлюз. Это то, что пропускает трафик в наш VPC. Мы также установим здесь наши таблицы маршрутизации:
Вы можете заметить, что я добавил в таблицу маршрутизации только публичные подсети. Это связано с тем, что, поскольку это скорее упражнение в Terraform, чем в полной архитектуре, нет причин подключать мои частные подсети к общедоступным. Поскольку мой веб-уровень представляет собой не более чем простую HTML-страницу, ему не нужно взаимодействовать с экземпляром RDS/частными подсетями/"уровнем базы данных". Однако, если бы это было так, нам понадобилось бы еще несколько элементов:
- другая таблица маршрутов для частных подсетей
- еще одна запись в общедоступной таблице маршрутов
- Шлюз NAT
- EIP
- и, может быть, один или два, которые я сейчас забываю :)
Балансировщик нагрузки
Затем мы переходим внутрь к устройству, которое распределяет трафик на наш веб-уровень. Это то, что на самом деле обеспечивает DNS, который мы используем для доступа к нашему веб-серверу, поэтому кажется, что это будет первая часть, но поскольку DNS является просто адресом внутри нашего VPC, он должен сначала пройти через IG.
Довольно просто: мы создаем наш ALB так, чтобы он указывал на наши общедоступные подсети, убеждаемся, что у него есть правильная группа безопасности, устанавливаем internal на false, чтобы он был балансировщиком нагрузки с выходом в Интернет, и все готово! О, подождите, не совсем… мне потребовалось некоторое время, чтобы понять это, но наличие слушателя (и ОСОБЕННО target_group_arn) является абсолютным ключом к тому, чтобы заставить эту работу работать.
Итак, чтобы быстро резюмировать:
- создать ALB, которому нужен слушатель
- создать слушателя, которому нужна целевая группа
- создать целевую группу, которой нужны цели
- прикрепить цели к группе
Все еще со мной? Хороший!
Я скажу, что документация для всех этих частей довольно хорошо объясняет, что каждая часть *является*, но, как правило, совсем не помогает вам узнать, *какие* части идут вместе или какие части вам *нужны* для ее создания. работа. Эти проекты определенно научили меня этому.
Группы безопасности
Этот последний раздел, прежде чем мы попробуем запустить его, будет охватывать три группы безопасности, которые нам нужны, чтобы позволить правильному трафику течь туда, куда он должен идти.
VPC, ALB и EC2.
Честно говоря, это то, из-за чего я больше всего боролся за весь проект. В конце концов, я забыл cidr_blocks в своей группе безопасности VPC, и мне нужно было создать группы безопасности для инстансов EC2 и балансировщика нагрузки. Разрешение трафика с ALB на веб-уровень было сделано путем ссылки на группу безопасности ALB.
С этим последним кусочком головоломки мы теперь готовы пройтись по командам Terraform, чтобы построить это творение!
Терраформирование
1. терраформировать инициализацию
terraform init — это первая команда, которую мы собираемся запустить на нашем терминале. Как вы можете догадаться, это инициализирует все файлы и зависимости, которые будет использовать наш проект.
2. terraform fmt/terraform validate
Эти две разные команды являются необязательными, но могут пригодиться. fmt просто форматирует ваши файлы .tf, чтобы у них был чистый интервал и еще много чего. validate просматривает ваши файлы и проверяет синтаксис. Он не сможет обнаружить все проблемы, но определенно может сэкономить вам время, обнаружив эти маленькие раздражающие ошибки! Оба они просто вернут любые файлы, в которые они внесли изменения. (можно использовать -diff с fmt, чтобы показать, какие изменения были внесены)
3. план терраформирования
Эта следующая команда пройдет через ваш код и предоставит вывод, показывающий действия, которые Terraform выполнит при «применении».
4. применить терраформирование
Итак, ребята, вот большая красная кнопка! Эта команда говорит Terraform «Go», и после вторичного «да» для подтверждения tf начнет создание всех ресурсов.
А пока выпейте чашечку кофе или перекусите. Для этого проекта даже при небольшом размере RDS это может занять 5–6 минут.
Когда сборка будет завершена, мы должны увидеть следующий экран:
Классная команда, которую мы можем запустить, это terraform state list, которая покажет нам все различные элементы, которые были созданы:
Мы можем вручную подтвердить, что все было создано, проверив различные места в консоли AWS, но наша последняя проверка — посмотреть, можем ли мы подключиться к нашему веб-серверу.
5. терраформировать уничтожить
Эпический успех! Теперь почистим. Эта единственная команда закроет все и удалит все активы/ресурсы, которые мы создали.
Итак, мы увидели, как создать простую двухуровневую архитектуру AWS в Terraform. Спасибо, что присоединились ко мне в этом путешествии, и если вы хотите увидеть окончательный файл main.tf, обязательно посетите мой GitHub:
