处理的流程大致如下。

• GitHubにpushされるとCircleCI上でterraform planが走る

そのPRがmasterにマージされるとterraform applyが走る

Terraform模板

首先，描述一下DNSimple提供商。

variable "dnsimple_email" {} # 環境変数TF_VAR_dnsimple_email
variable "dnsimple_token" {} # 環境変数TF_VAR_dnsimple_token

provider "dnsimple" {
  token = "${var.dnsimple_token}"
  email = "${var.dnsimple_email}"
}

当与DNSimple连接时，需要将token和email传递给Terraform，但由于不想将它们存放在代码库中，所以将它们作为环境变量传递。在传递环境变量时，需要使用TF_VAR_前缀，例如，环境变量TF_VAR_foo可以通过$var.foo进行引用。

如果要将www.example.com连续地设置为example.herokuapp.com的ALIAS记录，则应按照以下方式进行描述。

resource "dnsimple_record" "example-com" {
  domain  = "example.com"           # 設定する対象のドメイン
  name    = "www"                   # サブドメイン部分。ルートドメインなら空文字を渡す
  value   = "example.herokuapp.com" # ALIAS先。AレコードならIPアドレス、CNAMEなら転送先を渡す
  type    = "ALIAS"                 # レコードのタイプ
}

DNSimple_record资源还有其他选项，比如TTL。有关设置值，可以参考DNSimple的记录创建API。

反映到DNSimple

在具有先前模板文件的目录中运行terraform apply命令。

$ terraform apply

将tfstate保存到AWS S3中。

terraform apply执行资源更改时，会创建并更新一个名为terraform.tfstate的文件来记录最新状态。虽然详细情况可以参考文档，但如果发现这个文件在CircleCI上每次都被创建并且销毁，那么在本地操作时可能会感到困惑。因此，决定将其记录到S3上。

如果要将其保存为s3://example-terraform-state/terraform.tfstate，首先需要进行以下准备工作。

1. 使用S3来创建example-terraform-state存储桶

1. 创建一个具有写入该存储桶权限的IAM用户（例如S3FullAccess）

1. 将以下三个环境变量设置为键信息和存储桶区域信息

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AWS_DEFAULT_REGION

当那个步骤完成后，请使用terraform remote config2来设置保存路径。

$ terraform remote config \
  -backend=S3 \
  -backend-config="bucket=example-terraform-state" \
  -backend-config="key=terraform.tfstate"

在S3中获取（pull）、更新（push）数据，并在反映之前和之后执行此操作。

$ terraform remote pull
$ terraform apply # もしくはplan
$ terraform remote push

顺便提一下，执行terraform remote config命令后，之前位于当前目录中的terraform.tfstate和terraform.tfstate.backup文件会被创建在名为.terraform的文件夹中。由于该文件夹的内容与保存在S3中的内容相同，我认为可以将其添加到.gitignore文件中而无需担心问题。

circle.yml的中文释义是“环形配置文件”。

确保内容包括以下内容。

• Terraformをダウンロードしてきて~/.terraformに展開、パスを通す

• ~/.terraformをキャッシュする

• testで

terraform remote config
terraform remote pull
terraform plan
terraform remote push

masterブランチにマージされたら

terraform remote config
terraform remote pull
terraform apply
terraform remote push

machine:
  environment:
    PATH: $HOME/.terraform:$PATH
    TERRAFORM_VERSION: 0.5.1
dependencies:
  cache_directories:
    - ~/.terraform
  pre:
    - |
      mkdir -p $HOME/.terraform
      if [ -z "$(ls -A $HOME/.terraform)" ]; then
        cd $HOME/.terraform
        curl -LO https://dl.bintray.com/mitchellh/terraform/terraform_${TERRAFORM_VERSION}_linux_amd64.zip
        unzip terraform_${TERRAFORM_VERSION}_linux_amd64.zip
        rm terraform_${TERRAFORM_VERSION}_linux_amd64.zip
      fi
test:
  pre:
    - |
      terraform remote config -backend=S3 -backend-config="bucket=example-terraform-state" -backend-config="key=terraform.tfstate"
      terraform remote pull
  override:
    - |
      terraform plan
  post:
    - |
      terraform remote push
deployment:
  production:
    branch: master
    commands:
      - |
        terraform remote config -backend=S3 -backend-config="bucket=example-terraform-state" -backend-config="key=terraform.tfstate"
        terraform remote pull
        terraform apply
        terraform remote push

顺便提一下，在”circle.yml”中仅仅编写代码处理并不方便，在实际操作时需要进行执行操作，因此我实际上会将其定义为一个”rake”任务，并调用该任务来执行。

使用CircleCI的配置

将GitHub和CircleCI进行整合。

请在CircleCI项目的界面上设置以下出现的5个环境变量。

Here’s one option for paraphrasing “所感” in Chinese: 自己的感受

• Terraformで管理する前にすでに同じレコードが登録されている場合、applyで上書きできずに失敗する。遊びで使っているドメインなら削除してからapplyして作りなおせばいいけど、業務で使っているような場合には厳しい。

ちなみに今回の場合はtfファイルで一度でも記述したドメインのみが管理対象になるのに対し、Roadworkerの場合はドメイン（Hosted Zone）以下全てが管理対象になる。

テストとしてterraform planが走るだけだと、実際の記述が正しいかどうかはわからない。ただtfファイルの記述の時点で処理が入り乱れるようなものでもないし、あくまでも誰か人間がterraform applyしなきゃいけないっていう手間を省くものとしてはアリな気がしている。

请提供更多的上下文或者需要翻译的句子。

• Amazon S3 で Terraform の状態管理ファイル terraform.tfstate を管理 / 共有する

• Terraform + GitHub + CircleCI + Atlasを利用してAWSの操作を自動化した

• CircleCIで任意のツールをインストールして使う際の定番スニペット

Route53のレコードをRoadworkerとCircleCIを使ってPull Requestベースで管理する