Terraform与CloudFormation实践指南：从手动运维到基础设施即代码

提到基础设施搭建，不少开发者可能还停留在“手工操作”的模式。打开云厂商控制台，点击EC2，选择镜像，配置安全组和子网，最后再加上负载均衡器……一套流程下来，既繁琐又容易出错。最令人头疼的是，你很难记住上一次安全组的入站规则到底开放的是80端口还是8080端口。这种配置不一致、难以复现的“雪花服务器”，是运维工作中常见的痛点。

这正是我们需要深入探讨基础设施即代码的原因。虽然这个概念并不新颖，但能真正掌握并落地应用，将极大提升效率和稳定性。本文将以两个主流工具——Terraform和CloudFormation为例，提供一套从入门到实战的详细指南。

核心概念：Terraform 与 CloudFormation 是什么？

如果你尚未接触过IaC，可能会觉得这些术语有些抽象。简单来说，基础设施即代码就是将服务器、网络、数据库等基础设施资源，通过编写配置文件的方式进行定义和管理。

传统方式如同手工建造房屋，需要图纸和施工队。而IaC则像拥有一台3D打印机，你只需编写好“设计图”（配置文件），明确楼层、窗户和门的朝向，机器便能自动构建出完整的基础设施。

CloudFormation 是AWS原生的模板服务，专用于管理AWS上的资源。作为“亲儿子”，它对AWS新特性的支持最为迅速，且与AWS服务深度集成。你只需要编写一个JSON或YAML格式的模板文件，由CloudFormation服务读取并创建资源。如果创建过程中出错，它能自动执行回滚操作，确保环境干净，这一点非常可靠。

Terraform 是HashiCorp公司推出的开源工具。这家公司以开发运维领域的实用工具而闻名。Terraform最大的优势在于其多云兼容性，它不绑定任何特定云厂商，支持AWS、Azure、Google Cloud，甚至能管理本地环境如VMware和Kubernetes。这就像拥有一支全能施工队，能够依据同一套设计规范，在不同的平台上进行部署，对于构建多云架构而言尤其有用。

那么如何选择？如果你的业务完全基于AWS，且追求与云服务的最新同步，CloudFormation是稳妥的选择。但如果你希望避免供应商锁定，或未来有多云部署规划，那么从 Terraform 开始学习将是更明智的决策。下文我们将主要以Terraform为例进行演示，同时也会涵盖CloudFormation的关键用法。

环境准备：安装与配置

理论与实践结合，我们首先搭建好本地环境。

对于Terraform，macOS用户如果已安装Homebrew，可以通过以下命令安装：

brew install terraform

Linux或Windows用户则需要从官网下载二进制包，解压后将其所在目录添加到系统的PATH环境变量中。安装完成后，在终端执行 terraform version，若能正常显示版本号即表示安装成功。

CloudFormation无需单独安装软件，它是AWS服务的一部分。你只需要拥有一个AWS账号以及对应的访问密钥，即可通过AWS管理控制台或AWS CLI进行操作。对于自动化场景，我们更推荐使用CLI。

Terraform 入门：从零创建一台EC2实例

Terraform的核心是 .tf 配置文件。它使用HashiCorp配置语言，这种语言可读性很高，即使新手也容易理解。

首先，创建一个名为 terraform_demo 的目录，并在其中创建 main.tf 文件。这个文件将定义我们所需的所有资源。

第一步，我们需要声明要使用的云提供商，这被称为Provider。

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

provider "aws" {
  region = "ap-northeast-1" # 此处以东京区域为例
  # 默认会读取环境变量 AWS_ACCESS_KEY_ID 和 AWS_SECRET_ACCESS_KEY
}

这段代码很直观。terraform 块声明了我们要使用 hashicorp/aws 这个Provider。provider “aws” 块则指定了区域。

接下来，我们定义一台最简单的EC2实例。

resource "aws_instance" "my_server" {
  ami           = "ami-0c55b159cbfafe1f0" # 这是一个Amazon Linux 2的镜像ID，不同区域需更换
  instance_type = "t2.micro" # 免费套餐涵盖的实例类型，适用于测试

  tags = {
    Name = "MyFirstTerraformServer"
  }
}

在这段代码中，resource 是关键字，后面跟着资源类型 aws_instance 和我们自定义的资源名称 my_server。花括号内是该资源的配置参数。请注意，AMI ID因区域而异，你需要从AWS控制台的“启动实例”界面获取对应区域的正确ID。

配置文件编写完成后，就可以执行了。

1. 初始化：在终端中，进入项目目录并执行 terraform init。此命令会下载并初始化配置中声明的Provider插件。你会看到提示 Terraform has been successfully initialized!。
2. 执行计划：运行 terraform plan。这是Terraform一个非常强大的功能，它会模拟执行过程，列出将要创建、修改或销毁的资源，并用 +、~、- 等符号标识，而不会实际操作云资源。这提供了一个安全的“预演”机会。
3. 应用变更：确认计划无误后，执行 terraform apply。命令会再次要求你确认，输入 yes 后，Terraform便会开始在AWS上创建EC2实例。你可以在终端日志中观察创建进度，无需登录控制台手动点击。

通过代码声明需求，由工具自动执行，这就是“声明式”管理的魅力——你只需关心“最终状态”是什么。

CloudFormation 实战：使用YAML模板创建资源

那么，在纯AWS环境中，如何使用原生的 CloudFormation 呢？它使用JSON或YAML格式的模板。考虑到可读性，我们通常选择YAML。

创建一个名为 template.yaml 的文件。

AWSTemplateFormatVersion: '2010-09-09'
Description: 'My First CloudFormation Stack'

Resources:
  MyEC2Instance:
    Type: 'AWS::EC2::Instance'
    Properties:
      ImageId: 'ami-0c55b159cbfafe1f0'
      InstanceType: 't2.micro'
      Tags:
        - Key: Name
          Value: 'MyFirstCfnServer'

模板结构清晰：Resources 部分定义资源，MyEC2Instance 是逻辑名称，Type 指定资源类型，Properties 内是详细参数。其逻辑与Terraform是相通的。

接下来，使用AWS CLI来创建这个“堆栈”。

aws cloudformation create-stack --stack-name my-first-stack --template-body file://template.yaml

执行后，你可以在AWS控制台的CloudFormation服务中查看堆栈的创建状态。堆栈是一个逻辑容器，包含了模板定义的所有相关资源。CloudFormation的核心优势之一是其健壮的回滚机制，如果在创建过程中任何资源失败，它会自动清理已创建的部分，确保不会留下孤立资源，这对于生产环境的稳定性至关重要。

进阶技巧：变量、状态与模块化

在实际生产中，硬编码配置是不可取的。真正的 基础设施即代码 实践要求代码与配置分离。

在Terraform中，可以定义变量。创建 variables.tf 文件：

variable "instance_type" {
  description = "The type of EC2 instance"
  default     = "t2.micro"
}

然后在 main.tf 中引用：instance_type = var.instance_type。这样，修改实例类型只需更新变量文件或通过命令行传递，实现了配置的灵活管理。

这里必须提到Terraform的一个核心概念：状态文件。执行 terraform apply 后，会在本地生成一个 terraform.tfstate 文件。它记录了当前管理资源在云上的真实状态，Terraform依靠对比状态文件与代码来决定执行何种操作。对于团队协作，必须将状态文件存储在远端后端，如AWS S3，以实现状态共享和锁定。

terraform {
  backend "s3" {
    bucket = "my-terraform-state-bucket"
    key    = "prod/terraform.tfstate"
    region = "ap-northeast-1"
  }
}

CloudFormation的状态由AWS自身管理，用户无需操心，这是其简便之处。

另一个重要实践是模块化。当配置变得复杂或需要在多项目中复用时，应将通用部分抽象为模块。

module "web_cluster" {
  source = "./modules/web-server"
  instance_count = 3
}

这类似于软件开发中的函数封装，能极大提升代码的复用性和可维护性。Terraform官方和社区提供了大量现成模块。

资源销毁与日常维护

基础设施管理不仅关乎创建，也关乎清理。手动删除资源易遗漏，导致不必要的费用。

Terraform提供了完美的解决方案：terraform destroy。该命令会根据状态文件，按依赖顺序销毁所有已管理的资源，确保环境清理得干净彻底。

CloudFormation同样简单，删除堆栈即可自动清理其中所有资源。

注意事项：务必妥善保管状态文件。如果本地状态文件丢失，Terraform将无法正确管理现有资源。同时，需警惕“配置漂移”——即有人通过控制台手动修改了由IaC工具管理的资源。下次执行 apply 时，工具会试图将配置改回代码定义的状态，可能导致服务中断。最佳实践是确立规则：所有变更都应通过代码进行。

总结

掌握Terraform或CloudFormation，意味着从手工、重复的“点选式”运维，转向自动化、可重复、版本可控的工程化运维。你将更像一位设计系统和编写蓝图的架构师，而非忙于救火的消防员。

无论选择哪个工具，其核心理念都是将基础设施视作软件来进行管理。这种范式转变，是迈向现代DevOps和云原生实践的关键一步。建议立即使用云厂商的免费套餐进行实践，从创建一个VPC或S3存储桶开始，逐步构建更复杂的架构。

如果在学习或实践中遇到问题，欢迎来到 云栈社区 与更多开发者交流探讨，共同进步。