着物アプリのインフラをTerraformで構築するためのリポジトリ
tfenvとDockerの利用を紹介します。どちらを利用してもいいです。
Dockerのほうが環境によって差異が出ないのでオススメです。
詳細はtfenvを確認してください。
brew install tfenv
でインストールします。
その後以下の手順で設定を行います。
tfenv install 0.13.06
tfenv use 0.13.06
terraform --version
で Terraform v0.13.06 が表示されればOK
Docker上でTerraformを実行します。
初回起動
docker-compose up --build -d
起動
二回目以降は下記のコマンドを実行します。
docker-compose up -d
Macの場合 brew install awscli
を実行してaws cliのインストールを行います。
その後、aws configure --profile kimono-app-stg
対話形式のインターフェースに従い入力します。
AWS Access Key ID [None]: `アクセスキーIDを入力`
AWS Secret Access Key [None]: `シークレットアクセスキーを入力`
Default region name [None]: ap-northeast-1
Default output format [None]: json
ちなみに aws cli なしでもAWSクレデンシャルを設定する事は可能です。
~/.aws/credentials
という名前のファイルを作成して以下の内容を設定します。
[kimono-app-stg]
aws_access_key_id = あなたのアクセスキーID
aws_secret_access_key = あなたのシークレットアクセスキー
このプロジェクトではprofile名を kimono-app-stg
としています。
profile名を書き換えた場合、providers/aws/environments/○○/○○/
配下の provider.tf
, backend.tf
を書き換えて下さい。
.tfstate
はS3Bucketに保存します。Terraformを実行する前にS3S3Bucketを作成してください。
このプロジェクトでは stg-kimono-app-tfstate
という名前で作成します。
下記のようなディレクトリ構成になっています。
terraform-boilerplate/
├ modules/
│ └ aws/
└ providers/
└ aws/
└ environments/
├ dev/
│ ├ 10-network/
│ └ 20-xxxx/
└ prod/
├ 10-network/
└ 20-xxxx/
本番環境とステージング・開発環境など複数環境に構築するケースを想定し、environments/
配下に環境ごとのディレクトリを作成しています。
providers
の頭の数字に注目して下さい。
.tfstate
はこれらのディレクトリ配下毎に存在しますが、数字の大きなディレクトリは数字が小さなディレクトリに依存しています。
その為、必ず数字が小さいディレクトリから terraform apply
を実行する必要があります。
今後このプロジェクトをベースに機能を追加する際も依存関係を意識してディレクトリ名を決める必要があります。
数カ所 terraform.tfvars
の設置が必要な箇所があります。(後に terraform.tfvars
を自動生成する処理を追加します)
設定が必要な変数は以下の通りです。
// providers/aws/environments/○○/11-acm/terraform.tfvars
// providers/aws/environments/○○/20-api/terraform.tfvars
// providers/aws/environments/○○/21-frontend/terraform.tfvars
main_domain_name = "Route53に設定されているドメイン名を指定"
// providers/aws/environments/○○/13-ses/terraform.tfvars
email_address = "送信元となるメールアドレスを指定、開発用途ならGmailのアドレス等で十分"
- 今はAWSのみだが、他のproviderが増えても大丈夫なように
providers/
を作ってあります - 各moduleには特定のリージョンに依存した値はハードコードしない(AZの名前とか)
- 各moduleには特定の環境に依存した値はハードコードしない
- マルチリージョンでの運用にも耐えられるディレクトリ設計
以下の命名規則に従って命名します。
項目名 | 命名規則 |
---|---|
ファイル名 | ケバブケース |
ディレクトリ名 | ケバブケース |
リソースID | スネークケース |
リソース名 | ケバブケース |
変数名 | スネークケース |
リソースIDというのは resource
や data
等のTerraformの予約語に付けられる名前です。
resource "aws_security_group_rule" "ssh_from_all_to_bastion" {
}
リソース名はそのリソースの中で一意になっている必要がある値です。
下記の例だと key_name
がそれに該当します。
resource "aws_key_pair" "ssh_key_pair" {
public_key = "${file(var.ssh_public_key_path)}"
key_name = "${terraform.workspace}-ssh-key"
}
他にもタグ名を良く付ける事がありますが、それもこちらのルールの通りケバブケースで命名します。
このようなややこしい規則になっている理由ですが、RDSCluster等、一部のリソース名で _
が禁止文字に設定されている為です。
他にもインデント等細かいルールがありますが、こちらに関しては terraform fmt -recursive
を実行すれば自動整形されるのでこれを利用すれば良いでしょう。
terraform fmt
は必ずプロジェクトルートで実行を行ってください。
そうしないと全ての .tf
ファイルに修正が適応されません。