CLOUD SECURITY LAB

如何使用AWS和Terraform将基础设施作为代码进行管理 🏗️

—

by

cslab
in

通过一次控制台点击创建的服务器，没有人知道是谁创建的。

如果不以代码形式留下记录，该基础设施很快就会变成幽灵。

>

>

将IaC（通过一份代码重复部署相同基础设施）的一致性和可控性，比喻为“根据蓝图同时建造的城市”。

>

🎯 本文涵盖内容

  • AWS是什么，以及它为何成为云标准
  • Terraform是什么，以及为什么需要IaC（基础设施即代码）
  • AWS + Terraform组合所产生的自动化力量
  • Terraform的核心5步工作流程（init → plan → apply → destroy）
  • 团队在实际工作中如何共同管理基础设施

📌 引言 / 背景

想象一下，您在AWS控制台中手动创建了一个EC2实例。

区域是ap-northeast-2，实例类型是t3.medium，安全组设置开放了端口22……一步步点击完成。感觉很棒。但是六个月后，如果需要为预发布服务器再创建一个相同的环境呢？那时的设置是什么来着？

这就是手动基础设施管理的陷阱。

  • 没有设置记录
  • 无法追踪谁更改了什么
  • 不同环境之间存在细微差异
  • 新团队成员加入时需要从头开始解释

为了解决这个问题，IaC（基础设施即代码）应运而生，其代表工具就是Terraform。

🔍 AWS是什么？

AWS (Amazon Web Services) 是亚马逊运营的全球云计算平台。它在全球数十个区域拥有数据中心，允许企业通过互联网租用计算资源，而无需自行购买服务器。

AWS核心服务
类别 服务 一句话描述
计算 EC2 虚拟服务器 (VM)
存储 S3 对象存储 (文件存储)
无服务器 Lambda 无需服务器运行代码
网络 VPC 虚拟私有网络
安全/访问控制 IAM 权限管理
数据库 RDS 托管式关系型数据库

AWS最大的特点是按使用量付费的结构。不使用的资源可以关闭，如果流量激增，可以在几分钟内进行扩展。

🔍 Terraform是什么？

Terraform 是 HashiCorp 创建的 IaC 工具。它允许您将基础设施定义和管理为代码，并且可以使用一种语言管理 AWS、Azure、GCP 甚至本地环境。

HCL — Terraform的语言

Terraform 使用一种名为 HCL (HashiCorp Configuration Language) 的专用语言。它看起来像 JSON，但更易于阅读。

# AWS 提供商配置
provider "aws" {
  region = "ap-northeast-2"
}

# 创建 EC2 实例
resource "aws_instance" "web_server" {
  ami           = "ami-0c9c942bd7bf113a2"  # Amazon Linux 2
  instance_type = "t2.micro"

  tags = {
    Name = "MyWebServer"
  }
}

这份代码文件可以替代在AWS控制台中需要点击10次才能完成的操作。

提供商(Provider)概念

Terraform 要与 AWS 对话，需要一个提供商 (Provider)。提供商是连接 Terraform 与特定云服务的插件。

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

除了 AWS，还有数百个提供商，例如 azurerm (Azure) 和 google (GCP)。

🔍 AWS + Terraform，为什么一起使用？

在企业环境中，使用 AWS 很快就会出现以下情况：

  • 开发团队 → 需要开发环境 VPC
  • QA 团队 → 需要测试环境 VPC
  • 运维团队 → 需要生产环境 VPC

这三个环境结构相同，但配置值略有不同。如果手动创建每个环境会怎样？

  • 容易出错
  • 之后，三个环境会逐渐产生细微差异，导致“在我的环境中可以，为什么在生产环境中不行？”的问题。

如果使用 Terraform 进行代码化，只需更改一个变量即可将三个环境以相同方式部署。

# variables.tf
variable "environment" {
  description = "배포 환경"
  type        = string
  default     = "dev"
}

variable "instance_type" {
  description = "EC2 인스턴스 타입"
  type        = string
  default     = "t2.micro"
}

💻 Terraform 基本工作流程 5步

以下是使用 Terraform 管理 AWS 基础设施的核心工作流程。

第1步: 编写代码 (Write)

在 .tf 文件中定义基础设施。这是前面提到的 HCL 代码编写步骤。

my-terraform-project/
├── main.tf          # 定义核心资源
├── variables.tf     # 声明变量
├── outputs.tf       # 定义输出值
└── provider.tf      # 提供商配置

第2步: terraform init — 初始化

terraform init

此命令在首次启动项目时必须执行。执行后，它会：

  • 创建 .terraform/ 文件夹
  • 自动下载所需的提供商插件
  • 初始化外部模块
Initializing provider plugins...
- Finding hashicorp/aws versions matching "~> 5.0"...
- Installing hashicorp/aws v5.31.0...
- Installed hashicorp/aws v5.31.0 (signed by HashiCorp)

💡 提示：务必将 .terraform/ 文件夹添加到 .gitignore。它体积较大，应在每个环境中直接下载。

第3步: terraform plan — 计划确认

terraform plan

实际上不进行任何更改，只输出预期的更改内容。这是部署前必不可少的审查步骤。

Terraform will perform the following actions:

  # aws_instance.web_server 将被创建
  + resource "aws_instance" "web_server" {
      + ami           = "ami-0c9c942bd7bf113a2"
      + instance_type = "t2.micro"
      ...
    }

Plan: 1 to add, 0 to change, 0 to destroy.

+ 表示创建，~ 表示修改，- 表示删除。如果看到 -，务必确认是预期的删除操作。

第4步: terraform apply — 实际部署

terraform apply

将 plan 中确认的内容实际应用到 AWS。执行前会再次请求确认。

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

部署完成后，会创建/更新 terraform.tfstate 文件。此文件是记录当前基础设施状态的核心文件。

⚠️ 注意：可以使用 terraform apply -auto-approve 跳过确认，但在生产环境中绝不要使用。

第5步: terraform destroy — 删除基础设施

terraform destroy

删除所有创建的资源。用于清理测试环境或开发完成后删除资源。对节省 AWS 成本非常有效。

🔍 实际工作流程 — 团队协作管理

通过模块化提高重用性

将通用组件制作成模块以实现重用。

# VPC 模块重用示例
module "dev_vpc" {
  source      = "./modules/vpc"
  environment = "dev"
  cidr_block  = "10.0.0.0/16"
}

module "prod_vpc" {
  source      = "./modules/vpc"
  environment = "prod"
  cidr_block  = "10.1.0.0/16"
}

在开发/生产环境中重用相同的 VPC 模块。在没有代码重复的情况下保持一致性。

远程状态管理 — S3 + DynamoDB

如果多个团队成员同时执行 terraform apply，将发生状态文件冲突。为防止这种情况，请配置远程状态管理。

terraform {
  backend "s3" {
    bucket         = "my-terraform-state-bucket"
    key            = "prod/terraform.tfstate"
    region         = "ap-northeast-2"
    dynamodb_table = "terraform-lock"  # 防止并发执行 (锁定)
    encrypt        = true
  }
}
  • S3：集中存储状态文件
  • DynamoDB：管理锁，防止多人同时应用

与 Git + CI/CD 集成

在实际工作中，Terraform 与 Git 分支策略结合使用。

feature 브랜치 → PR 생성 → terraform plan 자동 실행 → 코드 리뷰 → main 병합 → terraform apply 자동 실행

利用 GitHub Actions 或 GitLab CI 可以完全自动化此过程。

⚠️ 注意事项 / 常见错误

🔴 不要将状态文件提交到 Git

terraform.tfstate 可能包含资源 ID、IP，甚至明文密码。务必将其添加到 .gitignore 并使用 S3 等远程后端。

# .gitignore
*.tfstate
*.tfstate.backup
.terraform/

🔴 谨慎使用 terraform destroy

在生产环境中误操作会导致所有资源被删除。养成对重要资源添加 prevent_destroy 设置的习惯。

resource "aws_db_instance" "production" {
  lifecycle {
    prevent_destroy = true  # 执行 destroy 命令时发生错误
  }
}

🔴 不要将 Access Key 硬编码到代码中

# ❌ 绝不要这样做
provider "aws" {
  access_key = "AKIAXXXXXXXXXXXXXXXX"
  secret_key = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
}

# ✅ 使用环境变量或 IAM 角色
provider "aws" {
  region = "ap-northeast-2"
  # 使用 AWS CLI 环境变量或 IAM 角色进行自动认证
}

✅ 总结 / 结束语

AWS 和 Terraform 的组合总结如下。
类别 内容
AWS 提供云资源的平台
Terraform 将这些资源作为代码进行管理的工具
核心工作流程 init → plan → apply → destroy
团队协作核心 S3 远程状态 + DynamoDB 锁 + Git 分支策略
最大优势 一致性、可重用性、变更追踪、自动化

随着云基础设施变得越来越复杂，手动管理的局限性会迅速显现。养成使用 Terraform 将基础设施作为代码进行管理的习惯，即使环境不断增加，您也能自信地部署和维护。

推荐的下一步学习方向：

  • 利用 Terraform Module Registry (registry.terraform.io)
  • 使用 Terraform Cloud / Atlantis 构建 GitOps 流水线
  • 通过 terraform import 将现有手动创建的资源导入到代码中

Comments

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注