(社内のQiitaTeamに上げたものを再編して供養。コードのプラグイン入れるのに手間取った。)
概要
TerraformにおけるAWSのリソース作成に入門したので雑に書いていきます。
Goals:既存のTerraformコードがある程度読めて、新しいリソースの追加がある程度書けるようになる。
前提
- AWSの経験
- SecurityGroup、IAMがある程度分かる
- 追加するリソースについてマネコンで作れる程度に分かる
- (自分はCloudFormationの経験があった)
参考資料
- 公式ドキュメント
- 書籍
- (あれば社内ドキュメント)
導入
すでにawscliのセットアップは終わっているものとする。
バージョン管理ツール:tfenvを用いて、既存で使っているバージョンとか、最新版を入れる
参考はじめてのTerraform 0.12 ~環境構築~
※useしてからじゃないとlistでエラーになった
$ tfenv list
*0.14.3(set by /usr/local/Cellar/tfenv/2.0.0/version)
会社の環境(要MFAやスイッチロール)によってはassume-roleを入れると楽になれたりする
1st step terraform initを行う
ワークスペースを初期化するコマンド。環境には変更がないので安心
ここでは会社のリポジトリをクローンしてやった。ゼロからリソース作成場合は2stへ
$ cd /XXXXX/
$ eval $(assume-role XXXX)
$ terraform init
...
Terraform has been successfully initialized!
...
2st step サンプルを元にリソースの作成を行う
EKSの場合
(eksctlをterrafromに置き換えるという作業の都合上題材に上げる)
公式を参考にクローンしてリージョンを適宜書き換えた上で実行
https://learn.hashicorp.com/tutorials/terraform/eks
$ terraform init
$ terraform plan #どのようなリソースが作られるか確認
$ terraform apply #yesで作成される
消すとき。カレントディレクトリの.tfの内容しか消えないので安心感
$ terraform destloy #どのようなリソースが消えるか確認されyesで消される
とりあえずクローンしてサクッと作れるのがとても良い
※各々やりたいことに合わせて元となるリポジトリ等を探すと良さそう
3st step 追加したいリソースを追加する
公式ページのfilterに追加したいリソースを検索すると記述方法が出てくる
例えばIAMポリシーだとこんな感じ。
例えばjsonを参照しポリシーを作成するならこんな感じ。
resource "aws_iam_policy" "ClusterAutoScaler-test" {
name = "ClusterAutoScaler-test"
path = "/"
policy = file("iam/ClusterAutoScaler-test.json")
}
※別途ポリシーを記述したjsonを配置する
リソース名の指定
<リソースの種類>.<リソース名>.<属性名>
policy_arnの場合aws_iam_policy.ClusterAutoScaler-test.arn
moduleへのリソースの追加など
先程のサンプルの中身をよく見ると module “eks” や module.vpcとかが出てくる
書籍になく自分もハマったのだが、手っ取り早く作るときのパッケージがmoduleとして提供されている。少ないインプットでいろんなリソースが作られる。
以下の詳細ページから動きを見ていく必要がある。
https://registry.terraform.io/modules/terraform-aws-modules/eks/aws/latest
moduleで作られたロールに、aws_iam_policyで作ったリソースをアタッチするときはこう書く
outputから参照したい値を探す感じ
resource "aws_iam_role_policy_attachment" "woker-group" {
role = module.eks.worker_iam_role_name
policy_arn = aws_iam_policy.ClusterAutoScaler-test.arn
}
自分でmoduleに追加するときはinputを参照していく。
tips
terraform.tfstate
こいつが消えると死ぬ。実環境ではterraformで管理しないS3に置いている。
リソースIDが見れるのでマネコンで追うときに稀に使う
targetオプション
特定のリソースのみデプロイしたいときに使う。
変更してないのにリソースが消えたり作られたりする現象(バグらしい)と上手く付き合っていくときとかに使う。壊さないように注意が必要。
個人的にterraformとCloudFormationを比較して
- リソース名の参照が定義しなくて良い。Cfnだとoutputで明示的に宣言する必要がある。
- 参照が分かりにくく迷子になる
- 1度にすべてのリソースが作成できる。Cfnだとリソース毎にスタック(区切り)を切ってやっていた。
- 例えばvpcとEC2で2つにスタックを分けるので、2回実行が必要(設計次第かも
- 消す順番も意識が必要。
- スタックが独立するので1つ目の変更に2つ目が振り回される可能性がある
- 新規構築フェーズのCloudFormationによる作成はやってたけど、運用後の変更管理まではやってなかったから実際分からん
- Terraformもまだ追加とかしてないから分からん
今後身につけたいこと
- エラーのときのトラブルシューティング
- 今回記載していないコマンドなどの活用(全然使ってない)
- 実環境へのリソース追加(直近でやることでもある)