Terraform Cloud のススメ

今年4月に Terraform Cloud を利用し始めて２ヶ月が経ちました。

back checkでは主に AWS 環境を terraform で管理しているため、AWS 環境での使用感も交えて記事にまとめようと思います。

Terraform Cloud とは

Terraform Cloud (以下TFC)は Terrafrom を使ってインフラ管理をする上で、辛みになってくる部分を解消してくれるクラウドサービスです。

例えば以下のような点です。

  • terraform のCI/CDの作り込み
  • AWS認証情報や権限の管理
  • workspaceを跨いだstateの参照
  • variables の管理
  • tfe provider で Terraform Cloud も terraform 管理

それでは詳しくみていきましょう。

Terraform Cloud の料金

まず、最初に気になるであろうTFC の料金について簡単に説明します。

TFCのStandardプランの料金は

  • 1リソース, 1時間あたり $0.00014 (記事執筆時点)

となってます。

ユーザ数による課金は無くなったのでチームで使いやすくなりました。 （その分ヘビーユースしている小規模チームは割高になりましたね・・・）

また毎月500リソース*１ヶ月分の無料枠があります。

1000リソースをプロビジョニングしている場合、無料枠を超えた500リソース分課金され約50$になります。 リソース数は terraform state list | wc -l で大体数えられます。(dataもしっかりと含まれます)

利用規模によりますが、調査や検証で利用する分には無料枠で十分足りそうです。

CI / CD の作り込み

Terraform では コーディング (write) → 変更内容の確認 (plan) → 変更の反映 (apply) というワークフローでインフラを構築していきます。

PRを出したらplan, マージしたらapplyみたいなことがやりたくなるわけですが、GitHub Actions Workflow等で作り込んでいくのはなかなかに時間がとられます。 特にworkspaceの数が増えてきたり、mono repo にしようと思うとかなり辛くなってきます。

TFC の場合はGitHub Appsとしてリポジトリにインストールし、TFC 上のworkspaceでVCS連携を有効にするだけです。

  • speculative plan を on にするとPRでplanが自動実行される
  • 指定したbranch(デフォルトはGitHub上のデフォルトブランチ) にマージするとplan→applyが実行される
  • trigger patternにファイルパターンを設定すると、特定のファイルに変更があった場合のみplan, applyが実行される

設定の幅は広くないですが、必要十分な機能を備えていると思います。

AWS 認証情報や権限管理

Terraform で AWS 環境の管理する場合、多数の認証情報を管理する必要が出てきます。

  • CI / CD で plan/applyするための認証情報
  • 開発者のローカルからplanして事前確認したり、検証環境にapplyするための認証情報

TFC を利用すると（設定によりますが）TFC 上でplanやapplyが実行されます。 AWSの認証はTFCで設定すればOKで、個々の開発者にTerraformのためのAWS権限を配る必要がありません。

TFC 上のどのworkspaceで何ができるかというのは、ProjectやTeamといった機能で管理できます。

開発者はローカルで terraform login するだけで自分に割り当てられたworkspaceで作業できるようになりますし、 VCS連携したworkspaceは手元からのapplyが自動で禁止されるので、勝手にメチャクチャになってしまう心配もありません。

コーディング時点で事前に本番planできるといったメリットを享受できます。

workspaceを跨いだstateの共有

workspaceはデプロイの単位になるのでシステム単位や環境単位で分けたくなります。 workspace間の参照は terraform_remote_state で行えるわけですが、これを使うにはbackendに対する認証が必要になります。

一方TFCの場合は tfe_outputs でTFC上の他workspaceのoutputを簡単に参照できます。

workspaceの設定でstate共有先のworkspaceを選択 or organization全体で共有をすれば、他workspaceから tfe_outputs で参照できるようになります。 認証情報等も不要です。

terraform_remote_state による他workspaceのstate参照は権限周りの複雑さも相まってかなり導入ハードルが高く感じていましたが、 tfe_outputs であればすぐに導入できます。

これもかなり嬉しいですね。

variables の管理

TFCではworkspace単位でvariablesを設定できる他、Variable Setsという機能があります。

これは複数workspaceやproject単位, organization全体といった複数のスコープにまとめてvariableを設定できるような機能になります。

backcheck では以下のような用途に使っています。 - dev, stg, prodといった環境名をenv というvariableに共通で渡している - datadog API key のようなproviderの認証情報をまとめて設定

TFCを使わない場合はそもそもvariablesをどこで管理するのかというのも考えなくてはいけないため便利な機能ですね。

tfe provider

ここまで書いてきたTFCの機能、設定を全てterraformで管理することができます！ それを可能にしているのが tfe provider です。

backcheckではTFC ×tfe provider ×mono repo という構成を採用していますが、 これによってかなり生産性が上がったのを実感しています。

例えば

dev, stg, prod の３環境に新システム用のworkspaceをそれぞれ作ってCIの設定をし、AWSの認証情報も設定する のような作業が30分もかからずにできるようになりました。

コードジェネレータを使えばテンプレ化もできると思います。

おわりに

TFC は Terraform を活用している場合はかなりフィットするサービスかなと思います(あとはお財布と相談)

無料枠もあるのでぜひ試してみることをおすすめします！