用Terraform管理团队的AWS资源

2 年 ago

雅, 悟

1 minute

X种子公司的团队，我是工程师浅野。
我的孩子向我索要了一辆迷你车作为圣诞礼物，于是我在亚马逊上寻找了一下，但不知不觉中也买了几辆相同的迷你车给自己。
亚马逊真的很方便，但有点可怕。

提起亚马逊的话题，说到AWS，我打算写一下团队如何通过Terraform代码管理AWS资源的故事。

为什么选择使用Terraform进行(基础设施的)构建？

为什么不使用CloudFormation而选择Terraform？

如果使用AWS的话，虽然CloudFormation也可以，但是个人更喜欢HashiCorp的Terraform，因为使用原生的JSON太麻烦了。而且，由于Terraform是用Go语言编写的，单个可执行文件运行起来也很方便。

虽然如此，似乎还有一些功能只能通过CloudFormation实现。
顺便提一句，Terraform可以执行CloudFormation。这可能会方便地用于尝试提供的CloudFormation示例。

为什么要费心将其编码呢？

使用画面点点构建的方式确实很方便，但是当构建对象增加时很难完全管理。手动操作容易出错。同时还需要进行文档维护，管理成本会进一步增加。通过进行代码化，希望它本身成为当前正在运行的基础设施配置的文档。

它是如何组成的？ (Tā shì de?)

说到AWS，我就想到了classmethod。在我进行AWS相关的调查研究时，我经常参考他的资料。关于Terraform，以下的文章对我来说也是很大的参考。事实上，几乎是一样的。

├── .envrc
├── Makefile
├── README.md
├── bastion.tf
├── common
│   └── all
│       ├── main.tf
│       └── variables.tf
├── devops
│   ├── prod
│   │   ├── main.tf
│   │   └── variables.tf
│   └── stg
│       ├── main.tf
│       └── variables.tf
├── init
│   ├── igw.tf
│   ├── route-table.tf
│   ├── s3.tf
│   ├── terraform.tfstate
│   ├── terraform.tfstate.backup
│   └── vpc.tf
├── modules
│   ├── audit-trail
│   │   ├── cloudtrail.tf
│   │   ├── cloudwatch.tf
│   │   ├── iam.tf
│   │   ├── s3.tf
│   │   └── variables.tf
│   ├── billing-alert
│   │   ├── cloudwatch.tf
│   │   └── variables.tf
│   └── efs
│       └── efs.tf
├── s3.tf
├── security-group.tf
├── subnet.tf
├── user-data
│   └── bastion.yml
├── variables.tf
└── x
    ├── prod
    │   ├── main.tf
    │   └── variables.tf
    └── stg
        ├── main.tf
        └── variables.tf

以下是我稍作修改的方面：
只需要一种选择，因为是以母语中文进行的重新表述：

チーム x 環境毎の構成

这里是源代码。

利用环境变量

terraform 可以使用 TF_VAR_hoge 设置的环境变量来读取”${var.hoge}”。
此外，还可以使用环境变量来读取AWS的凭证。
基本上，我们希望将这些变量从源代码管理中排除，但是在terraform中使用的变量都变为了环境变量。
我们可以准备一个像下面的.envrc文件，在进入项目根目录并使用direnv操作时，可以自动通过direnv设置环境变量。

# TF_VAR
export TF_VAR_team=seeds

# AWS key
export AWS_ACCESS_KEY_ID=xxxxxxxx
export AWS_SECRET_ACCESS_KEY=xxxxxxxx
export AWS_DEFAULT_REGION=ap-northeast-1

在初始构建阶段中的设置（在init文件夹下）。

Terraform使用.tf文件编写基础设施定义，并使用由Terraform生成的.tfstate文件保存基础设施状态。
主要将.tf文件纳入代码管理，并将.tfstate指定为S3作为保存位置。然而，如果可能，希望将此存储桶也由Terraform进行管理，所以将此部分单独分为名为”init”的文件夹，并将init文件夹中的tfstate包含在代码管理范围内。
init文件夹及其下方基本上不会被销毁，而是作为专用资源存放位置。
(出于相同的原因，VPC相关资源也被放置在init文件夹下。)

团队X根据每个环境的配置而构建。

为了在除了环境（staging 或者本番）之外根据团队（X团队或者DevOps团队或者团队共有）来分配资源，我们稍微更改了团队>环境的配置。

在进行何种terraform转换

基本方针

虽然宣称要进行代码化，但基本上是在不过分努力的前提下放松地进行。具体来说，已经在屏幕上点点点做了资源的，会逐渐地在空闲时间中进行terraform化；对于无法通过terraform来处理的资源，比如sns的email相关资源，会在界面上进行创建，并使用环境变量来保存生成的arn。

目标

然而，为了能够让代码审查者审阅，我们通常将今后要创建的或者过去只有我一个人接触过的东西（例如VPC等）进行了代码化。

未来计划

因为还没有将CI集成进去，所以我想要自动化 commit/push -> pull request -> review -> dry run -> deploy 的流程。