Terraform使用指南 2017冬季版

我写了续篇→https://qiita.com/uraura/items/e13d883827443f27bf98

简述

我使用Terraform来管理AWS资源,但是由于人员较少,所以我想分享一下我们取得了不错的进展。

为了简化表达,假设我们使用Terraform来管理AWS资源。

请问有什么问题吗?

当使用Terraform时,一开始会觉得它非常方便,可以将一切都编码化。然而,很快就会遇到以下问题。

    1. 随着代码化的推进,计划和应用所需的时间不断增加。

即使计划能够通过,应用仍可能失败。

推动代码化会导致计划和实施所需的时间增加。

只要已經編碼的資源很少,這不會成為太大的問題。但是隨著時間的推移,編碼量增加,計劃/應用所需的時間將不斷增加。

当存在一个庞大的模块时,即使代码的增加只有几行,但所需时间也会迅速增加,因此需要注意。

有时即使计划成功了,申请也可能失败。

在中文中原文含义的一种可能的表达方式是:
在我看到的很多情况下,人们会创建一个Pull Request后进行计划,在合并后再进行应用。这个流程一开始看起来很清晰明了,但是无论计划是否成功,如果最后不进行应用,结果将无法预知。一旦陷入这种状态,

    • applyを通すために微修正したプルリクエストを何度も作ることになってつらい

 

    applyが通っても意図した通りの結果になっていなくてつらい

如果遇到类似的情况,而且代码量相当多,那么会出现(1)的问题。

你怎么了?

总体来说,可以分为两大类。

    • AWSアカウントを開発(dev)/ステージング(stg)/本番(prd)で分ける

Terraform Providerを使う

将AWS账户分为开发(dev)/阶段性测试(stg)/生产(prd)阶段。

我认为这是一个常见的故事。如果能完全掌握IAM,也许能在一个帐号上努力,但对我来说有点困难……

以下是每个账户的用途,具体如下:

    • devはローカルマシンからplan/applyできるようにしてしまう

 

    • CIからapplyする確認はstgで取る

 

    stgで確認できたらprdにもapplyする

将`dev`视为专门针对目标项目的沙盒的关键点。首先,`dev`就是为了破坏而创建的,如果被破坏了,重新创建就好了吧?(如果不这样做,那写代码的目的是什么呢?)无论是添加新资源还是考虑到已存在的资源,都可以在`dev`中执行apply操作,这样就可以避免创建不必要的pull request,也不需要等待CI,并且可以顺畅地进行开发。

※我在开头提到“只有少数人”,这是根据这个情况而定的。如果多人同时申请一个环境,可能会变得非常混乱,让人难以理解。

关于用于Terraform验证的AWS账户

过去,验证Terraform通常在一个用于调查/学习的(共享的)AWS账户中进行。在这种情况下,我认为可以从本地计算机上进行应用。但是,还存在以下问题。

    • 関係ない他のリソースが作られていたりする

 

    • 検証したいリソースに必要な依存先があればそれも含めて作る必要がある

 

    検証終わったらちゃんと消さないと無駄に金がかかる

此外,由于通常只会创建必要的最低资源,因此在添加该代码后,增加的apply时间完全看不到。

因此,确认与项目无关的资源(如个人爱好或将来可能使用的资源等)是可以的,但如果目的是确认当前项目需要使用的资源,那么最好在该项目的开发环境中进行确认。

使用Terraform Provider

有一个叫Terraform Provider的提供者。简单来说,它是一个可以引用其他Terraform执行的tfstate的提供者。下面是它的形象描述。

resource "aws_s3_bucket" "foo" {
 :
} 

output "s3_bucket_foo" {
  value = "${aws_s3_bucket.foo.id}"
}
data "terraform_remote_state" "tf_a" {
  backend     = "s3"

  config {
   :
  }
}

data "aws_s3_bucket" "foo" {
  bucket = "${data.terraform_remote_state.tf_a.s3_bucket_foo}"
}

通过这种方式,当terraform_A应用后生成了一个名为foo的S3存储桶时,另一个terraform_B将能够引用该存储桶。在terraform_B中假设存在S3存储桶foo,因此计划/应用过程会变得非常快速。

基本上可以通過模組來完成,模組外所需的資源需定義為輸出(output),這樣能夠清晰地知道在哪裡有什麼,感覺很好。透過terraform output指令可以列出已輸出的值,這也有助於迅速查找所需的資源。

总结

    • Terraformはapplyしやすい環境を整えると捗る

 

    Terraform Providerをつかってtfstateを分割すると時短になる4

由于我本人从未处于这样一个同时有很多人操作Terraform的环境中,而且从实际角度来看,调整基础设施配置的人数应该不多,因此存在这样的猜测。具体配置可能会在另一篇文章中进行描述。为了在terraform_remote_state中进行引用,必须在根级别进行输出(规格),这有点麻烦。这也是Terraform的最佳实践建议。
广告
将在 10 秒后关闭
bannerAds