Знакомство с монолитной архитектурой

Как вы, наверное, заметили, я отношусь к монолитным архитектурам в технологиях.

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

Однако службы, которые связаны вместе, также могут дать сбой вместе — как я узнал, пытаясь собрать воедино простой бэкенд, состоящий из экземпляра RDS MySQL и внешнего интерфейса из веб-экземпляров, управляемых балансировщиком нагрузки приложения. Легко, верно?

Цель

Для своего первого проекта Terraform я создал монолитную структуру, содержащую VPC с общедоступными и частными подсетями, балансировщик нагрузки приложений и экземпляр RDS MySQL.

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

Задания

Для достижения цели мне нужно было выполнить шаги, описанные ниже:

1. Использование I.D.E. по выбору установить Terraform.

2. Используя официальную документацию, составить единый файл, содержащий код для следующих спецификаций:

— 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 (микро) в одной из подсетей

— Балансировщик нагрузки, который будет направлять трафик в общедоступные подсети.

— 1 экземпляр EC2 t2.micro в каждой общедоступной подсети

Окружающая среда и технические характеристики

  • Device — MacBook Pro, 14 дюймов, 2021 г., M1 Pro
  • AWS учетная запись и учетные данные
  • I.D.E. — AWS Cloud9 работает на Amazon Linux 2, инстанс t2.micro (бесплатный уровень)
  • Terraform в. 1.2.3 (поставляется с Cloud9)

Анализ основного конфигурационного файла монолита

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

Аналогичные чувства у меня к единственному конфигурационному файлу в Terraform — main.tf. Потенциально громоздкий файл содержит всю конфигурацию и значения для развертывания приложения. К сожалению, это также может привести к нарушениям безопасности и проблемам с производительностью.

Провайдеры: AWS

Первая часть основного файла конфигурации должна содержать объявление провайдера(ов). Провайдеры позволяют Terraform управлять ресурсами или источниками данных. В приведенном ниже примере я объявил AWS в качестве провайдера, жестко закодировал учетные данные (— серьезно, не делайте этого!*) и свой рабочий регион, чтобы можно было создавать ресурсы и управлять ими.

  • **Конфиденциальные значения или информация никогда не должны включаться в файл main.tf, поскольку эта информация может и, вероятно, будет использоваться для захвата ваших учетных записей и увеличения расходов или уничтожения всего, что вы знаете и любите в своей жизни. цифровое пространство. → Попробуйте вместо этого: используйте предложение HashiCorp установить переменные для защиты конфиденциальных данных.

После этого шага сохраните файл и запустите $ terraform init для инициализации рабочего каталога и серверной части.

Ресурсы: VPC et al.

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

  • *Поскольку я выбрал стандартный подход, я был ограничен одной подсетью на aws_route_table_association ресурс. Это расширило код для каждой подсети, которую мне нужно было явно связать. → Попробуйте вместо этого: используйте count = length(var.subnets) под ресурсом, чтобы указать количество желаемых подсетей.

Уровень приложений — ресурсы: EC2, группы безопасности, балансировщик нагрузки приложений

Эта часть кода представляет собой набор общедоступных экземпляров под управлением Amazon Linux 2, загруженных с установленным веб-сервером Apache. Правила группы безопасности разрешают доступ по ssh с порта 22, а также доступ в Интернет через порт 80. Обозначение EOF вокруг пользовательских данных позволяет использовать многострочные строки в конфигурации Terraform.

Балансировщик нагрузки, указанный как «приложение» по умолчанию, связан с общедоступными подсетями и распределяет веб-трафик между экземплярами на этом уровне.

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

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

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

Экземпляр базы данных создается в RDS с использованием указанной группы подсети и группы безопасности. Я мог бы добавить ряд опций, таких как добавление информации журнала, но, поскольку это приложение не на стадии производства, я пока не особо заинтересован в сборе журналов.

Вот и все! Все, что осталось сделать сейчас, — это спланировать и применить эту конфигурацию, чтобы посмотреть, как все будет работать вместе.

Момент истины…

Я запустил команду $ terraform plan, чтобы запустить список всех желаемых спецификаций конфигурации. Многие значения были помечены как «известно после применения», поскольку ресурсы еще не были созданы.

Ознакомившись с планом, я пошел вперед $ terraform apply , чтобы сделать перечисленные ресурсы и надеяться на лучшее — без ошибок.

Terraform проверяет в последний раз, чтобы убедиться, что я понимаю, что собираюсь делать.

Через несколько коротких минут все заявленные ресурсы должны были быть созданы. Я обязательно проверил консоль AWS для каждого ресурса, сравнив ее с указанной конфигурацией.

Отражение

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

Хотя я нашел преимущество в использовании единой структуры для простоты, а не необходимости ссылаться на несколько файлов, риск безопасности и практичность — или их отсутствие — просто не стоят того.

Ну и что дальше? Я использовал $ terraform destroy для очистки всех недавно созданных ресурсов так же легко, как я их создал. Занятый облачный инженер может быть спокоен, когда одна команда может быстро развернуть и уничтожить ресурсы, не забывая при этом об одном ресурсе, который продолжает нести расходы.

Теперь, когда у меня есть понимание Terraform на самом базовом уровне, я буду изучать некоторые более продвинутые функции Terraform — модули! Оставайтесь с нами, Земляне.