株式会社ROXXのTerraform Cloud 導入レビュー
株式会社ROXX / take4s5i
テックリード / テックリード / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名
利用プラン | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
---|---|---|---|
スタンダード | 10名以下 | 2023年5月 | B to B |
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
Terraform Cloud利用以前はGitHub ActionsでTerraformを運用していました。
1. CI/CDの作り込み・メンテナンスコスト
次のようなワークフローをGitHub Actionsで自作していました。
- PRを作成したら自動で
terraform plan
を実行して、結果をコメントとして投稿する - PRをマージすると自動で
terraform apply
を実行する
これを運用していて課題に感じていたのは次の点です。
- PRの差分と関係ある部分だけ
terraform plan
してほしい(全て実行すると時間がかかる) terraform plan
の結果がただのテキストで見づらいterraform apply
の結果がGitHub Actionsのログを見に行かないとわからない- GitHub Actionsの調整とデバッグに時間がかかる
2. AWS認証情報や権限の管理
以前はAWSに接続するための認証情報は各自で管理していました。
- 自分のPCから
terraform plan
する場合は自分の認証情報(aws sso login
等) - GitHub Actionsで実行する場合はOIDC認証
課題は以下の点です。
- 別環境で実行したい場合は認証情報を毎回切り替える必要がある
- どの環境で作業しているのかわかりにくい
terraform_remote_state
で別環境の情報を取得している箇所が非常に扱いにくい- 環境毎に認証が異なるため、state backendへの接続情報を変える必要がある
- しかも自PCとGitHub Actionsで認証方法が異なるためそこにも対応する必要がある
3. workspaceを跨いだstateの参照
terraform_remote_state
の扱いにくさが原因となり以下の問題も出てきました。
terraform_remote_state
を使いたくないので、workspaceが分割されずにどんどん大きくなっていくterraform plan
に時間がかかるようになる
4. Variables の管理
環境毎に設定値を切り替えるためにtfvars
ファイルやlocals
ブロックで定義しterraform.workspace
の値に基づいて切り替えるという方式を利用していました。
課題は以下の点でした。
- 開発環境で実験的に変えたい値なども毎回PRを出す必要があり、作業効率が悪かった
- コミットされてしまうため、機密情報は実質的に利用できなかった
5. terraformの運用環境自体の管理
terraformを実行できるようにするためのAWSリソース(tfstateのS3バケット、IAM等)はterraform管理外であり、手動で作成していました。
そのため、作業内容が不透明でレビューしにくく属人的になっていました。
どのような状態を目指していたか
当時はインフラ担当が2名だったため、なかなか改善のための工数を取れずにいました。
また、システム構成の改善やデプロイの効率化等のプロダクト運営に直結する、よりクリティカルな部分に時間を使いたいという思いもありました。
比較検討したサービス
- Terraform Cloud
- 自前実装を継続して改善する
- Atlantis
選定理由
- Terraformの開発元であるHashiCorp運営しているクラウドサービスであること。
- 無料プランで運用に関わる大半の機能を利用することができ、導入後の改善イメージが明確につかめた点。
- 導入のステップが簡単だったこと。
導入の成果
改善したかった課題はどれくらい解決されたか
CI/CDの作り込み・メンテナンスコスト
GitHub Appとして設定するだけで簡単にCI/CDに組み込むことができました。
- PRの差分と関係ある部分だけ
terraform plan
してほしい。(全て実行すると時間がかかる)- →特定のパスの変更、ブランチ、タグの時だけ実行するように設定できます。
terraform plan
の結果がただのテキストで見づらい。- →見やすく整形された状態で見れるようになりました。
- →URLを共有するだけで他の人に見てもらえるのでレビューしやすくなりました。
terraform apply
の結果がGitHub Actionsのログを見に行かないとわからない。- →履歴がTerraform Cloud上に残っているのとSlack通知ができるので追いやすくなりました。
- GitHub Actionsの調整とデバッグに時間がかかる
- →GitHub Appに変わったのでGitHub Actionsでの作り込みは一切不要になりました。
AWS認証情報や権限の管理
Terraform CloudもGitHub Actionsと同じくAWSのOIDC認証に対応しています。
また、Terraform Cloudを使ってterraform plan
やterraform apply
する場合は実行者の認証情報ではなくTerraform Cloud上に設定した認証情報が利用されます。
- 別環境で実行したい場合は認証情報を毎回切り替える必要がある。
- →Terraform Cloudに一度ログインしておけば、workspace毎に適切な認証情報を使ってくれます。切り替え不要になりました。
- どの環境で作業しているのかわかりにくい。
- →Terraform Cloudの設定でCI以外での
terraform apply
を禁止することができるため、間違える事故は起きなくなりました。
- →Terraform Cloudの設定でCI以外での
terraform_remote_state
で別環境の情報を取得している箇所が非常に扱いにくい。- →tfe_outputsという別の方法で別環境の情報を取得できるようになりました。
- →認証情報を意識する必要がなく非常に扱いやすくなりました。
workspaceを跨いだstateの参照
terraform_remote_state
を使いたくないので、workspaceが分割されずにどんどん大きくなっていく。- →
tfe_outputs
を活用してworkspaceの分割を進めることができました。
- →
terraform plan
に時間がかかるようになる。- →workspaceの分割が進んだことで高速化されました。
Variables の管理
Terraform CloudにはVariables管理機能があり、Terraform Cloudの画面上でVariablesの設定や編集ができます。
- 開発環境で実験的に変えたい値なども毎回PRを出す必要があり、作業効率が悪かった。
- →画面上で変更できるようになったため、値変更のためのPRは不要になった。
- →
tfvars
ファイルやlocals
との併用も可能。
- コミットされてしまうため、機密情報は実質的に利用できなかった。
- →
sensitive
かどうかも設定できるため、機密情報も管理できるようになりました。
- →
terraformの運用環境自体の管理
tfe providerを利用すると、Terraform Cloudの環境自体をterraformで管理することができます。
コードで管理できるようになったため、workspaceの新規作成作業等を自動化することができました
導入に向けた社内への説明
上長・チームへの説明
- チームの規模を考えると、自前で実装する工数(人件費)やOSSを運用していく工数より、Terraform Cloudの料金の方が安いこと
- 無料プランを使った試験導入の結果から、確実な改善が見込めること
- 環境の整備のような間接的なものではなく、プロダクトのインフラの改善という直接な施策にすぐに取り掛かれるようになること
活用方法
本番環境への反映から、普段のコーディングまでインフラチームはほぼ毎日利用しています。
よく使う機能
- GitHub Appを使ったPRへの組み込み
- Slack通知
- Variables管理
- 特定のパスが変更された時のみ
terraform plan
やterraform apply
を実行する機能(Trigger Pattern) tfe_outputs
を使ったworkspace間の情報参照- tfe providerを使ったTerraform Cloud自体の管理
terraform apply
後にtfe_outputs
で参照されている別workspaceを自動でterraform apply
する機能(Run Trigger)
ツールの良い点
- 開発元が提供しているクラウドサービスなだけあってterraformを運用していくにあたって必要・便利な機能が揃っています
- 機能面での不足感を感じる可能性は低いと思います
- 従量課金である点
- 小規模ならかなり少額から使い始められます
- リソース数で課金されるので事前にどれぐらいかかるのか予測がしやすいです
ツールの課題点
- いくつか使えない機能があるので多用している場合は注意が必要です
local-exec
の利用(非推奨とされている)terraform plan
やterraform apply
時の-target
オプション- 自分のPCからterraformコマンドを使って実行するときは利用できるが、Terraform CloudのUIやCI/CDなどでは利用できないです
- 利用プランによってplan, applyの同時並列実行数が決まるため、利用規模によっては遅く感じるかもしれないです
ツールを検討されている方へ
機能性は十分なので、Terraform Cloudに払う金額が自前実装する工数・時間に見合っているかがポイントです。
小規模チームの場合はかなりメリットが大きいのではないかと思います。
株式会社ROXX / take4s5i
テックリード / テックリード / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名
よく見られているレビュー
株式会社ROXX / take4s5i
テックリード / テックリード / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名
レビューしているツール
目次
- 導入の背景・解決したかった問題
- 活用方法