定义应用网络

介绍

应用运行前需要有地址空间。你将使用 Terraform 定义 AWS VPC 和子网，比较已部署的网络与 Terraform 状态，并且仅删除你的应用网络。

你应已了解 Terraform 的 init/plan/apply 工作流、资源地址，以及 AWS VPC/子网的 CIDR 基础知识。Terminal、Terraform 工具、AWS CLI 和一个独立的参考网络均已准备就绪。每个实验均独立开始；无需之前虚拟机中的资源。

与认证考试的关联

实验概览

定义并部署 VPC

在这一步中，你将把应用的地址规划转换为 Terraform 资源，并检查生成的 VPC。

打开 Terminal。AWS View 显示当前的网络资源；用它观察拓扑，用 CLI 获取精确字段，并用 Terraform 管理变更。现有的 reference-network 属于另一个应用，必须保持不变。

VPC 是区域级的网络边界。它的 CIDR 块定义地址范围：10.62.0.0/16 为此应用预留地址。Terraform 中的 aws_vpc.application 是配置地址，并非 AWS ID。AWS 会在创建后分配 ID。

application-network 目录包含已准备好的 Provider 配置。它选择环境提供的账户和已测试的工具版本。进入此目录：

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

初始化工作目录以选择所需的 Provider，然后格式化并验证配置。验证检查的是配置结构，不能证明资源已经存在。

terraform init
terraform fmt
terraform validate

如果 init 显示 Incomplete lock file information for providers，它是在说明其他平台的校验和信息。已准备好的虚拟机使用 linux_amd64；初始化和验证成功后即可继续。

审查计划。Terraform 还会描述 VPC 的默认设置；在计划新增的资源中找到 cidr_block 和 Name 标签。

terraform plan

最终摘要应显示新增一个资源。应用配置，并在 Terraform 请求确认时输入 yes：

terraform apply

查询实际的 VPC。--filters 根据应用标签筛选；--query 仅显示 ID 和 CIDR。ID 会有所不同，而 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 和一个可用区。在 us-east-1a 中使用 10.62.1.0/24，它是 VPC 的 /16 范围内一个较小的地址范围。仅凭此 CIDR 或某个可用区都不能使子网成为公有子网；互联网路由和访问规则将在后续配置。

创建 subnet.tf。表达式 aws_vpc.application.id 引用 VPC 资源。Terraform 利用此依赖关系先创建 VPC，再创建子网，并自动获取实际 ID。你无需将命令输出中的 ID 复制到 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

保存并显示生成的 ID。$(...) 捕获命令的输出；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 ID 一致，其 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/子网 ID 与 AWS 查询结果比较，不要把状态条目视为网络可以正常工作的证明。

terraform state list
terraform state show aws_subnet.application

列表包含 aws_vpc.application 和 aws_subnet.application。现在检查是否已收敛：

terraform plan

预期看到 No changes.。在 AWS View 中，应用子网出现在它实际所属的 VPC 内，旁边是保持不变的参考网络。

仅删除应用网络

在这一步中，你将审查删除顺序，销毁自己的 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 文件仍然保留，可供审阅。

总结

你使用 HCL 定义了 VPC 和子网，通过资源引用连接两者，比较了实际的 AWS 网络字段与 Terraform 状态，并确认计划没有变更。随后，你仅删除了自己管理的网络，并保留了无关的参考网络。要使应用可以访问，还需要分别配置路由和安全规则。