Terraform Associate 004 #9 HCP Terraform — workspace、variable set、ポリシー、drift detection

インフラ Terraform IaC Certification
読了 5分

最後の範囲は HashiCorp のマネージドプラットフォーム、HCP Terraform です(旧名の Terraform Cloud のほうが広く知られており、試験やドキュメントには 2 つの名前が混ざって出ることがあります)。トラックでは 運用 #6 でプラットフォーム比較の 1 項目として触れただけでしたが、004 はこの領域の出題範囲を広げたので、概念の構造をきちんと組み立てておく必要があります。ハンズオンなしでも解けるように、「何が何を含み、何がどこで実行されるのか」という構造を中心に整理していきます。

workspace — CLI のそれとは別物です #

最も重要な区別から始めます。

HCP Terraform の workspace は、CLI の terraform workspace コマンドと名前だけ同じ別概念です。

  • CLI のワークスペース: 同じ設定に対して state だけを複数持つローカル機能です(実践 #9 で限界を確認して採用しなかった、あれです)。
  • HCP の workspace: プラットフォームの管理単位です。1 つの設定(ふつうはリポジトリ 1 つ、またはディレクトリ 1 つ)に対する state、変数、実行履歴、権限が 1 つの workspace にまとまります。ローカルに置き換えると「バックエンドの key 1 つ + その運用画面」に相当します。

この区別自体が定番の出題です。そして project は複数の workspace を束ねる上位フォルダで、チームやサービス単位の権限管理の境界になります。構造は「組織(organization)→ project → workspace」の 3 層です。

実行方式 — VCS、CLI、API #

HCP Terraform で plan・apply が始まる方式は 3 つあり、それぞれの性格を区別します。

  1. VCS 連携(VCS-driven): リポジトリと workspace を接続すると、PR に plan が付き、マージが apply をトリガーします。運用 #1 で GitHub Actions を使って自前で組み立てたフローを、プラットフォームが組み込みで提供する形であり、試験が想定する「チーム標準」のルートです。
  2. CLI 連携(CLI-driven): ローカルで terraform コマンドを打ちますが、実行は HCP のリモート環境で行われます。設定の cloud ブロックで接続します。
  3. API 連携(API-driven): 外部システムが API で実行をトリガーします。カスタムパイプライン向けです。

リモート実行に共通する利点は、資格情報と state がローカルに存在しないこと、そして実行履歴がプラットフォームに残ることです。また、run trigger(ある workspace の apply 完了が別の workspace の実行を起動する機能)は、運用 #5 のスタック間依存をプラットフォーム機能でつなぐ装置だ、という位置づけまで押さえれば十分です。

変数と variable set #

workspace には Terraform 変数と環境変数を登録でき、sensitive の指定も可能です。出題ポイントは variable set です。複数の workspace に共通で注入される変数の束で、「すべての workspace に同じクラウド資格情報を供給する」ための標準的な方法です。workspace ごとにコピーして登録する選択肢は誤答の方向で、優先順位は workspace 個別の変数が variable set より優先されます(狭いほうが勝つ、基礎 #3 以来の一貫した原理です)。

ポリシー — Sentinel・OPA と 2 種類の失敗 #

ポリシーのコード化(policy as code)は、plan と apply の間にルール検査を挟む機能です。HashiCorp の Sentinel または OPA でポリシーを書き、「インスタンスタイプは許可リストのみ」「タグ必須」のようなルールが plan の結果に対して評価されます。試験で区別を問われるのは失敗の強度です。

  • hard-mandatory: 違反すると無条件でブロックします。オーバーライド不可です。
  • soft-mandatory: 違反するとブロックしますが、権限を持つ人が明示的にオーバーライドして続行できます。
  • advisory: 警告を残すだけで続行します。

運用 #4 で CI にスキャナーとして組み込んだガードレールの、プラットフォーム内蔵版だと理解すると位置づけがつかめます。

drift detection とその他の機能 #

  • drift detection(ドリフト検知): プラットフォームが定期的に実際のインフラと state を照合し、ずれを知らせます。運用 #2 で cron ワークフローを使って自作した検知器の内蔵版です。health assessment の一部で、continuous validation(設定の check ブロックを継続的に評価する機能、#7 のあの check です)とセットで出てきます。
  • プライベートレジストリ: 組織専用のモジュール・provider レジストリを提供します。組織標準モジュールの配布では、これが正答の方向です。
  • Terraform Enterprise: HCP Terraform のセルフホスト版です。機能は同じ系統で、設置場所が違うという区別だけが出ます。

料金ティアの詳細は出題というより常識レベルで、無料ティアが存在し、上位ティアでポリシーやガバナンスの機能が開放される、という程度で十分です。

まとめ #

今回の内容です。

  • HCP の workspace は CLI のワークスペースとは別概念で、state・変数・実行履歴を持つ管理単位であり、project がその上位の束です
  • 実行方式は VCS、CLI、API の 3 つで、VCS 連携がチーム標準のルートです。run trigger が workspace 間の依存をつなぎます
  • variable set は複数の workspace への共通変数の標準的な供給方法で、workspace 個別の変数が優先されます
  • ポリシーは Sentinel・OPA で plan と apply の間に評価され、hard・soft-mandatory・advisory という強度の区別が出題の軸です
  • drift detection・continuous validation はトラックで自作した装置の内蔵版で、Enterprise はセルフホスト版です

次回(#10 模擬試験)が最終回です。9 本ぶんの範囲全体から 50 問を出し、解説付きで解いていきます。

X