Определение сети приложения AWS с помощью Terraform

Введение

Прежде чем приложение сможет работать, ему нужно адресное пространство. Вы определите VPC и подсеть AWS с помощью Terraform, сравните развёрнутую сеть с состоянием Terraform и удалите только сеть своего приложения.

Вы уже должны знать рабочий процесс init/plan/apply в Terraform, адреса ресурсов и основы CIDR для VPC и подсетей AWS. Terminal, инструменты Terraform, AWS CLI и отдельная эталонная сеть уже подготовлены. Каждая лабораторная работа начинается в независимой среде; ресурсы из предыдущей VM не нужны.

Связь с сертификацией

Сертификация	Задача экзамена	Практика
Solutions Architect – Associate (SAA-C03)	Задача 1.2	Практика основ адресного пространства VPC и подсетей и зон доступности, используемых для сегментации сети.

Обзор лабораторной работы

Обзор концепции: Terraform определяет VPC с одной подсетью в us-east-1a.

Определение и развёртывание VPC

На этом шаге вы выразите адресный план приложения в ресурсе Terraform и изучите полученную VPC.

Откройте Terminal. AWS View показывает текущие сетевые ресурсы; наблюдайте в нём за топологией, тогда как CLI предоставляет точные поля, а Terraform управляет изменениями. Существующая сеть reference-network принадлежит другому приложению и должна остаться без изменений.

VPC задаёт границу сети в пределах региона. Её блок CIDR определяет диапазон адресов: 10.62.0.0/16 резервирует адреса для этого приложения. aws_vpc.application в Terraform — это адрес в конфигурации, а не идентификатор AWS. AWS назначает идентификатор после создания.

Каталог application-network содержит подготовленную конфигурацию провайдера. Она выбирает предоставленную учётную запись и проверенные версии инструментов. Перейдите в этот каталог:

cd /home/labex/project/application-network

Создайте main.tf. Heredoc с разделителем в кавычках записывает следующий HCL без подстановок до HCL; > создаёт или заменяет этот файл. Тег Name позволяет легко отличить сеть приложения от эталонной сети.

cat > main.tf <<'HCL'
resource "aws_vpc" "application" {
  cidr_block = "10.62.0.0/16"
  tags = {
    Name = "application-network"
  }
}
HCL

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

terraform init
terraform fmt
terraform validate

Если init сообщает Incomplete lock file information for providers, речь идёт о контрольных суммах для других платформ. Эта подготовленная VM использует linux_amd64; продолжайте после успешного завершения инициализации и валидации.

Изучите план. Terraform также описывает настройки VPC по умолчанию; найдите cidr_block и тег Name в предлагаемом добавлении.

terraform plan

Итоговая сводка должна показывать добавление одного ресурса. Примените конфигурацию и введите yes, когда Terraform запросит подтверждение:

terraform apply

Запросите фактическую VPC. --filters выбирает тег приложения; --query показывает только идентификатор и CIDR. Идентификатор будет различаться, а CIDR должен быть 10.62.0.0/16.

aws ec2 \
  describe-vpcs \
  --filters Name=tag:Name,Values=application-network \
  --query 'Vpcs[].{ID:VpcId,CIDR:CidrBlock}'

Обновите представление в AWS View: VPC приложения появится рядом с эталонной VPC. В новой VPC пока нет подсети приложения.

Подключение подсети с помощью ссылки на ресурс

На этом шаге вы создадите подсеть внутри VPC приложения и проверите её диапазон адресов, зону доступности и сопоставление в Terraform.

Подсеть принадлежит ровно одной VPC и одной зоне доступности. Используйте 10.62.1.0/24 — меньший диапазон внутри /16 вашей VPC — в us-east-1a. Ни этот CIDR, ни зона доступности сами по себе не делают подсеть публичной; маршрутизация в интернет и правила доступа будут рассмотрены позже.

Создайте subnet.tf. Выражение aws_vpc.application.id ссылается на ресурс VPC. Terraform использует эту зависимость, чтобы создать VPC раньше подсети, и автоматически получает фактический идентификатор. Вам не нужно копировать идентификатор из вывода команды в HCL.

cat > subnet.tf <<'HCL'
resource "aws_subnet" "application" {
  vpc_id            = aws_vpc.application.id
  cidr_block        = "10.62.1.0/24"
  availability_zone = "us-east-1a"
  tags = {
    Name = "application-subnet"
  }
}

output "vpc_id" {
  value = aws_vpc.application.id
}

output "subnet_id" {
  value = aws_subnet.application.id
}
HCL

Отформатируйте и проверьте новый файл, затем изучите план. Он должен добавлять подсеть и предоставлять два выходных значения, не заменяя вашу VPC.

terraform fmt
terraform validate
terraform plan

Примените изменения и подтвердите, введя yes:

terraform apply

Сохраните и выведите созданные идентификаторы. $(...) захватывает вывод команды; terraform output -raw возвращает строку без кавычек.

VPC_ID=$(terraform output -raw vpc_id)
echo "$VPC_ID"
SUBNET_ID=$(terraform output -raw subnet_id)
echo "$SUBNET_ID"

Выполните независимый запрос к AWS. Поле VPC у подсети должно совпадать с выведенным идентификатором VPC, её CIDR должен быть 10.62.1.0/24, а зона доступности — us-east-1a.

aws ec2 \
  describe-subnets \
  --subnet-ids "$SUBNET_ID" \
  --query 'Subnets[].{ID:SubnetId,VPC:VpcId,CIDR:CidrBlock,Zone:AvailabilityZone}'

Состояние Terraform сопоставляет адреса в конфигурации с развёрнутыми ресурсами. Изучите это сопоставление; сравните идентификаторы VPC и подсети с AWS, не принимая одну лишь запись в состоянии за доказательство работоспособности сети.

terraform state list
terraform state show aws_subnet.application

Список содержит aws_vpc.application и aws_subnet.application. Теперь проверьте согласованность:

terraform plan

Ожидайте No changes. В AWS View подсеть приложения отображается внутри своей фактической VPC, рядом с нетронутой эталонной сетью.

Состояние работающей среды: VPC приложения содержит свою подсеть в us-east-1a, а отдельная эталонная сеть сохранена. Идентификаторы ресурсов приведены как примеры.

Удаление только сети приложения

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

Terraform использует тот же граф зависимостей в обратном порядке: он удаляет подсеть раньше VPC. План удаления охватывает ресурсы, которыми управляет этот рабочий каталог, поэтому отдельно подготовленная эталонная сеть не должна в нём появляться.

Изучите запланированные удаления:

terraform plan -destroy

Ожидайте удаление двух ресурсов. Проверьте адреса ресурсов, прежде чем продолжать. Затем удалите сеть приложения и введите yes:

terraform destroy

Запросите ресурсы приложения по тегу. Оба запроса должны вернуть пустые списки; неудачный запрос не доказывает удаление.

aws ec2 \
  describe-vpcs \
  --filters Name=tag:Name,Values=application-network \
  --query 'Vpcs[].VpcId'
aws ec2 \
  describe-subnets \
  --filters Name=tag:Name,Values=application-subnet \
  --query 'Subnets[].SubnetId'

Убедитесь, что Terraform больше не управляет никакими ресурсами:

terraform state list

Команда не выводит адресов ресурсов. Наконец, изучите сохранённую эталонную подсеть:

aws ec2 \
  describe-subnets \
  --filters Name=tag:Name,Values=reference-subnet \
  --query 'Subnets[].{CIDR:CidrBlock,Zone:AvailabilityZone}'

Её CIDR остаётся 10.90.1.0/24 в us-east-1b. AWS View теперь показывает только эталонную сеть. Ваши файлы HCL остаются доступными для изучения, хотя ресурсы приложения уже удалены.

Резюме

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