😺

Terraform Cloudのほぼ全機能(2024/02時点)を雑に調査

2024/02/17に公開

Terraform

自動テスト可能なインフラプロジェクトの設計をテーマにこのブログを書き始めたのだが、3ヶ月経過した今でも技術選定が完了していない箇所がまだいくつもある。

そのうちの一つがクラウド上のリソースのドリフト検知だが、いくつか候補となるツールはあるものの、保守継続性が少し不安なところがあり、決めかねている状態だった。

しかし色々と調べていくうちに、Terraform Cloudもドリフト検知の機能を持っているということだったので、実質有料サービスという課題はあるものの、保守継続性の観点からは申し分ないツールであるため、今回はその能力を調査することにした。

またドリフト検知の他にも、もしかしたらインフラプロジェクトの設計を劇的に進化させる機能があるかもしれないと思い、せっかくなのでTerraform Cloudの機能を全体的に調査しようというのが今回の内容となる。

ーーなお、結論から先に言うと、自分のインフラプロジェクトではTerraform Cloudは不採用となった。

詳細については以下で説明していくことになるが、不採用の早期確定以後はTerraform Cloudに対する必要以上の調査/検証は行なっていないため、この記事はTerraform Cloudの実践的な操作方法等を知りたい人向けではないことをあらかじめ断っておく。

かわりに、Terraform Cloudの各種機能に対する商品レビュー(使ったことないけど評価☆3)のような情報を知りたい人向けの記事となっている。

もしこの話題に興味がある人は引き続き記事を読み進めていただきたい。

ちなみに、この記事を作成するにあたって調べた内容は以下になる。

Terraform Cloudのチュートリアルをすべて動作確認
Terraform Cloud内の機能を利用可能な範囲で操作
Terraform Cloudのドキュメントのうち、興味のある機能全文とその他の機能の強調文周辺を流し読み
応用記事一覧のうち、ドリフト検知、OPA関連といった興味のある記事のみ全文

もちろん全ページ精読をおこなったわけではないので、誤解釈がもしかしたら含まれているかもしれないので、その点についてはご容赦いただきたい。

それでは、まずTerraform Cloudの基本情報から紹介していく。

Terraform Cloudのサービスプラン

Terraform Cloudは、Terraformを利用したインフラストラクチャ構築における便利な機能を提供しているHashiCorp社のSaaSプロダクトである。

サービスプランとしては、機能制限版のFree Edition、一部機能を従量課金で利用可能なStandard Edition、ほとんどの機能が利用可能かつ包括的なサポートが受けられるPlus EditionおよびEnterprise Editionの4種類がある。

料金やプランごとに利用可能な機能についてはこちらを参照。

なお、Plus EditionとEnterprise Editionの価格は、お決まりの"Contact Sales"となっていて、詳しい価格は不明となっているが、おそらくは個人や零細プロジェクトが利用できる価格ではないと予想される。

(ちなみにSaaSのサービス価格はその会社の決算資料を見れば結構書いていたりして、直接の料金が書いてなくても売上と会員数からだいたい予測できたりすることもあるが、米国企業のIRを自分は調べたことがないので、もしTerraform Cloudの料金について何か書いていたら教えてほしい)

基本的に自分が作るインフラプロジェクトは、自分のような零細でも利用可能な設計にしたいので、せいぜいStandard Editionまでしか利用しない想定で、Terraform Cloudの各種機能を吟味していく。

Terraform Cloudの機能

Terraform Cloudを自分で試したい場合は、チュートリアルを参照。

Terraform Cloudのアカウントの作成手順は、ユーザ名、メールアドレス、パスワードを入力して、認証メールのリンクをクリックするだけで完了するので、簡単に始められる。

🔗 Basic Features (Free Edition+ ✅)

Terraform Cloudを利用しても、基本的には各自の開発マシンやCIインスタンス等から、terraformコマンドのplanやapplyなどを実行して、インフラストラクチャを構築していくという点においては、コミュニティ版のTerraformとまったく変わらない。

Terraform Cloudのアカウントを作成したのち、terraform loginコマンドでログインして、さらにterraform initコマンドを実行すると、Terraform Cloudとインフラプロジェクトが連携した状態となり、以下のような基本的な機能が使用可能な状態になる。

Terraform Cloud上でplanやapplyなどのコマンド実行を一元管理(=非個人環境依存)
applyオペレーションが複数同時に発行された場合の実行順序制御
terraform applyコマンドの実行承認フローをTerraform CloudのUI上で管理
terraform applyコマンド実行履歴、インフラストラクチャの状態、各種機能の利用状況などを閲覧可能なダッシュボード

コマンドベースでの利用以外にも、VCS(Github、Gitlab等)上のインフラプロジェクトリポジトリのブランチへのpushをトリガーにして、テストコードの実行やポリシーテストを実行したのち、インフラストラクチャへのapply承認フローを開始するといった、CI/CDパイプラインのような利用方法も提供されている。

以上がざっくりとしたTerraform Cloudの基本機能の説明となる。

ここからは自分の意見となるが、まず自分のインフラプロジェクトでTerraform Cloudにログインしてapplyを実行しようとしたところ、フォルダ構成および設定ファイルをDRYにするためにシンボリックリンクを利用しているのが原因でエラーが発生した。

もちろん回避策はあるのかもしれないが、少なくとも既にある程度出来上がったプロジェクトに導入する場合、Terraform Cloudの方針に合わせたフォルダ構成にする必要がありそうなのが難点に感じる。

他にも、インフラプロジェクトがTerraformによるインフラリソースの管理しか行っていないのなら、Terraform Cloud上でCI/CDパイプラインの実行を行なっていいかもしれないが、アプリケーションのデプロイまでCI/CDで行いたい場合、ブランチへのマージのタイミングで

VCS側(Github Actions等)ではアプリケーションのデプロイ
Terraform Cloud側ではインフラリソースの更新

のように、並列実行の状態となり、仮にこれらのタスクに実行順序関係が存在するようだと、問題が発生する気がしている。

基本的にCI/CDは1ヶ所に集約して実行されるべきなので、その場合はより汎用性の高いGithub Actions等VCS側のCI/CD上での実行に一本化すべきなのではと思った。

Terraform Cloudの基本機能の良い点を挙げるとすれば、まずstateファイルの保存先としてAWSのS3バケットやGCPのGCSバケットを作成して、閲覧/編集権限を設定するといった作業が不要で、Terraform Cloud内で保存してくれるのは少し面倒が解消されて便利だと思う。

他にも、applyオペレーションの同時実行制御のためのロック、インフラストラクチャの変更履歴にコメントを残せる機能、オペレーション発生時にWebhook、メール、Slack、Microsoft Teams等への通知機能などについては普通に運用で使いたいと思った。

🔗 Drift Detection (Plus Edition+ ✅)

ここまで長々と前置きをしてきたが、ここでようやく今回の主役であるドリフト検知機能について説明していく。

ちなみにドリフト検知の機能は、Plus Edition以上でなければTerraform Cloud上で試すことができないため、ドキュメントを読んでどのような機能なのか推測するしかない。

そこでドリフト検知機能の利用方法を説明しているドキュメントを読んでみると、以下のような機能の仕様に関する情報を拾うことが出来る。

...
Assessments use non-actionable, refresh-only plans.
...
Terraform Cloud will perform assessments once every 24 hours or so.
...
Drift detection only reports on changes to the resource attributes defined in your configuration.
...

つまり、"約24時間に1回、terraform plan -refresh-onlyコマンドを実行して、ドリフトが発生していないかチェックするが、このコマンドで認識可能な範囲のドリフトしか報告しない" という仕様の機能だと自分は解釈した。

試しにこの仕様に沿ったドリフト検知を自前で実装できないか色々と試行錯誤してみたところ、以下のコマンドで再現出来そうだった。

$ terraform plan -refresh-only --out /tmp/tfplan.binary
$ terraform show -json /tmp/tfplan.binary > /tmp/tfplan.json
$ cat /tmp/tfplan.json | jq .resource_drift

あとはcron系のサービスで24時間に1回上記コマンドを実行して、出力結果を整形したのち、Slackなどに通知を行えば、おそらくは劣化版機能ではあれど最低限のドリフト検知は行えるような気がする。

ただしこれだと、クラウドのコンソール上から手動で作られたリソースなどについては検知できない。

ドリフト検知ツールのdriftctlではこのような手動作成のケースに対応可能なようだが、そのdriftctlの開発者のような専門家が ドリフトはすべて検知できない と主張しているので、とりあえずは神経質にならずに上記コマンドのような必要最低限の機能でもいいような気がしてきた。

(ちなみにdriftctlを使えばいいのではと思うだろうが、現在driftctlはメンテナンスモードとなっていて、今後の機能維持に懸念があるため利用を断念した)

他にも、以下のようなGCSバケットをGCP上に作成すると、labels = {}が自動的に付与されてしまい、terraform plan -refresh-onlyコマンドを実行すると、labelsがドリフトとして扱われてしまうといった問題に対処しなければいけない。

resource "google_storage_bucket" "example" {
  name          = "${var.env}-example-bucket"
  location      = "ASIA"
  storage_class = "MULTI_REGIONAL"
  versioning {
    enabled = true
  }
  uniform_bucket_level_access = true
  public_access_prevention    = "enforced"
  # 以下の設定を追記するか、lifecycle.ignore_changesを定義することでドリフトが解決
  #labels                      = {}
}

それでもいったんは上記コマンドベースでドリフト検知を実装/運用してみるべきとの結論に至った。

そもそも第一に、ドリフトが発生する原因は手動オペレーションにあり、このオペレーションをチーム内で厳格に禁止することをまずは優先した方がいい気がしている。

結論として、自分のプロジェクトでTerraform Cloudのドリフト検知機能の採用は見送りとなった。

🔗 Continuous Validation (Plus Edition+ ✅)

インフラにリソースがデプロイされた後の運用フェーズで、各インフラリソースが意図通りの構成や挙動となっているか定期的なヘルスチェックを行うのが、Continuous Validation機能である。

こちらもPlus Edition以上でなければ使用できない機能なので詳細は不明だが、おそらくは上記ドリフト検知と同じタイミング(24時間に1回)でチェックの実行が行われる。

Continuous ValidationではTerraformのバージョン1.5から登場したcheckブロックによるアサーションをTerraformのコード内に定義することで、チェックが可能になる。

なおこの機能についても、ドリフト検知同様に自前での実装である程度は再現できるような気がしている。

(今回のメイン目的ではないので検証はいずれやる)

🔗 Private Registry (Free Edition+ ✅)

社内からのみアクセス可能なTerraform Registryを提供する機能で、自社内で開発したTerraformのプロバイダやモジュールを社内限定で配布および利用を可能とする機能。

このようなプライベートレジストリ機能は、一見するとライブラリ等を保存するだけのコンテンツサーバを1台運用する程度で見積もられがちだが、実際に自分で構築/運用を行なってみると、かなり負荷の高い作業であることが分かる。

まずリポジトリサーバ自体を構築するのはそこまででもないが、ライブラリのAuthorや利用者それぞれが守らなければいけないルールや手順のドキュメントを作成しなければいけない。

さらには、導入のために多くの利害関係者との交渉、リポジトリ利用者の質問や問題が発生した場合のサポート、基盤システムと化したレジストリの権限管理や継続保守作業など、やらなければいけないことは山ほど出てくる。

それに対して、Terraform CloudのようなSaaSであれば、導入さえ決まればあとは各自のチームで公式のドキュメントを確認しながら利用してもらうだけなので、自前での実装/管理に比べてかなり労力は減らせる。

よってこの機能に関しては、個人的にかなりの高評価。

🔗 Module Tests Generation (only Plus Edition ✅)

Private Registryでは、登録したモジュールに対するTerraform Testのコードを自動生成するというモダンな機能を提供している。

(操作感がわかる動画)

利用手順のドキュメントを見る限り、現状はモジュールをTerraform Cloud上のPrivate Registryに作成して、そこからテストコードが固められたgzipをダウンロードして、ローカルのインフラプロジェクトに解凍したテストコードをコピーするといった運用になる模様。

なおこの機能は、競合製品に対するTerraformのコード利用を制限するライセンス変更の問題に影響を与える機能のような気がしていて、OSSでTerraformのテストコード自動生成ツールはもしかすると現れないのではないかと予想される。

代わりにGithub CopilotやChatGPT等でテストコードの生成を出来ないかと考えると思うが、どちらもデータのカットオフ日が現時点で2022年頃なのに対して、Terraform Testの構文が誕生したのはつい最近であることから無理である。

あと、Terraform Testのコードはdev、本番などの環境単位ではなく、各モジュール単位で用意すべきというHashiCorpの考え方が把握できたのは、個人的には収穫。

🔗 Configuration Designer (Free Edition+ ✅)

まずドキュメントを読んでみたが、どういった機能なのかまったく分からなかったため、実際にPrivate Registryにモジュールを作成して機能を試す必要があった。

(Private Registryにテスト用のモジュールを作成する手順はこちら)

テストモジュールとしてこちらのサンプルリポジトリをPrivate Registryに追加して、Configuration Designerを使用した結果、variableに値を入力するとmoduleの宣言方法を出力してくれるだけの機能だった。

moduleのvariableに値を設定

moduleの宣言を出力

🔗 No-code Provisioning (Plus Edition+ ✅)

機能名の字面だけを見ると、HashiCorpやコミュニティのノウハウが詰まったモジュールを定義するだけでインフラ構築が完了してしまうといったような、ロマン溢れる機能であるかのような印象を受ける。

しかし実態は、組織内のTerraformモジュール開発者が頑張って汎用的なモジュールを作成してPrivate Registryに公開、それをモジュール利用者がvariableの値の調整だけしか行わずに使えるようにするといった、運用フローを示しているだけの機能だった。

一応、Public RegistryにNo-codeの便利なモジュールがないか、"no-code"や"no code"で検索してみたが、数件しかヒットしない。

🔗 Policy Enforcement (Free Edition+ ✅)

ポリシーテストを実行するための機能。

ポリシーテストでは、変更対象となるTerraformのリソース内に、ストレージのバケットが一般公開設定になっていたり、DBリソースに対して削除保護設定が行われていない等といった問題のある設定が含まれていないかをチェックする。

Free Editionでもポリシーテストは実行できるが、作成できるポリシー数が5つまでと限りがあり、無制限での利用はPlus Edition以上が必要となる。

ポリシーのコードはTerraform CloudのUI上から登録したり、ポリシー専用のソースコードリポジトリを作成するなどして定義する。

ポリシーのコードが設定されている状態で、Terraform Cloud上でterraform planが成功すると、その直後にそれらのポリシーを使用したテストが行われ、ポリシーに違反したコードが発見された場合はapplyを中止したり、インフラ管理者に判断を委ねるといったフローを構築することが出来るようになる。

ポリシーを実装する言語としては、HashiCorpが提供するPaC(policy-as-code)言語であるSentinelと、ポリシー言語のデファクトであるOPA(=Rego)の2種類のうちから選択できる。

まずSentinelについてだが、これは実質HashiCorp社製品でしか使えないプログラム言語でしかなく、こちらに学習コストを払うくらいなら、さまざまなインフラツールで使用することが出来るRegoを学んだ方が良いという判断となる。

さらに有料の機能を使用しなくても、Regoで記述されたポリシーでTerraformのHCLファイルに対してポリシーテストを実行するためのOSSツールは実にたくさんある。

その中でもConftestはTerraform以外の設定ファイルに対しても容易にポリシーのテストを実行できることから、少なくとも自分の中ではTerraform Cloudのポリシーテスト実行機能を採用する可能性はほぼない。

🔗 Cost Estimation (Free Edition+ ✅)

インフラストラクチャ上のTerraformリソースから一時間毎＆月毎のコストを見積もって表示してくれる機能らしいが、この機能の説明を見た瞬間、(権限の問題はあるものの)AWSのBilling and Cost ManagementサービスやGCPのCloud Billingサービスを確認した方が正確なのではと思った。

ただこのデータは、ポリシーテストの際に見積もりコストがxxxドル以上になる場合に警告を発生させるといった利用が出来るらしく、それについては成る程と思った。

Misc

Terraform CloudではAWS Service CatalogやSplunkといった外部サービスや製品の連携もいくつか提供している。

インテグレーション系の機能としては他にも、Terraform Cloud上でのplanタスクおよびapplyタスクの実行間に、カスタムタスクを実行する機能などもある。

さらに組織管理、ユーザの認証/認可、SSO、2FA、監査ログ、請求書発行、さらにはオンプレ環境のサポートといった企業で利用するにあたって必要な機能も一通り揃っている。

おわり

以上ですべてのTerraform Cloudの機能について一定レベルで触れたと思う。

基本機能の一部やPrivate Registry、Module Tests Generationなど、運用で利用したいと思える機能はいくつかあったが、Terraform Cloudの思想にインフラの設計や運用を従わせないといけない点と、良い機能は大抵Plusプラン以上である点を考えると、やはり個人的には導入は厳しいとの結論に至った。

また、扱う対象がインフラストラクチャでしかも危険なボタンも結構搭載しているにもかかわらず、管理ツールやドキュメントが英語版しかないのは、日本国内で導入する妨げになっている気がする。

そもそもTerraformのライセンス問題の発端は、Terraform Cloudの収益性から始まった疑惑が強く、これ以上収益が悪化すると再度自分の設計が破綻する可能性も出てくるので、HashiCorp社には是が非でも頑張っていただきたい所存。

追記