OCI Resource Manager

解決する課題

クラウドのインフラを手作業のクリック操作で構築・変更する運用は、再現性がなく、構成のばらつきやヒューマンエラーを生みます。OCI Resource Manager は Terraform をマネージド環境で実行する IaC（Infrastructure as Code） により、これらの課題を解決します。

• インフラ構成をコードで宣言的に管理し、レビュー・バージョン管理・再利用したい
• 開発／検証／本番など同一構成の環境を何度でも再現したい
• 手作業の構築をなくし、変更前に影響範囲（plan）を確認してから適用したい
• Terraform の state（状態ファイル）やロックを自前で管理する手間をなくしたい
• 不要になった環境を**まとめて削除（destroy）**してコストを抑えたい

AWS で言えば CloudFormation に相当する位置づけですが、独自のテンプレート言語ではなく**標準の Terraform（HCL）**を使う点が大きく異なります。

主要概念と用語

• スタック（Stack）: Terraform 構成（HCL ファイル一式）と変数、状態をまとめた Resource Manager の管理単位。CloudFormation の「スタック」に近い概念
• 構成（Configuration）: スタックに含まれる Terraform コード本体。ZIP アップロード、Object Storage、Git リポジトリ（ソース管理）、テンプレートなどから取り込める
• ジョブ（Job）: スタックに対して実行する操作の単位。plan（変更計画の算出）／apply（適用）／destroy（削除）／import（既存リソースの取り込み） などがある
• 状態（State）: Terraform が管理する現実のリソースとコードの対応表。Resource Manager が自動で保管・ロックし、利用者は state ファイルを直接扱わなくてよい
• ドリフト検出（Drift Detection）: state とクラウドの実体との乖離（手作業変更など）を検出する機能
• 変数（Variables）: HCL の入力変数。コンソールや API で値を与える。機密値は Vault（Secrets） から参照させる
• プライベートエンドポイント（Private Endpoint）: VCN 内の非公開リソース（プライベートな Git や Kubernetes など）へ Resource Manager から到達するための接続経路
• テンプレート（Template）: よくある構成を雛形化したもの。Oracle 提供のものや自作のものをスタック作成の起点にできる

仕様・制限・クォータ

• 実行エンジンは標準の Terraform で、OCI Terraform プロバイダーを介してリソースを操作する。HCL の知識がそのまま使える
• state はサービス側でマネージドに保管・ロックされる。S3 + DynamoDB のようなバックエンドを自前で組む必要がない
• ジョブは plan / apply / destroy / import が基本。apply は通常直前の plan の結果に基づいて適用する（意図しない変更の抑止）
• 構成の取り込み元は ZIP・Object Storage・Git（ソース管理）・テンプレートなどに対応する
• 1 つの apply で扱えるリソース数やジョブの実行時間には実務上の上限があり、巨大な構成はスタックを分割するのが定石（Terraform 一般のベストプラクティスと同じ）
• スタック・ジョブはコンパートメントとリージョン単位で管理され、テナンシ／リージョンのサービス制限が掛かる。上限引き上げはサービスリクエストで申請する
• Resource Manager 上で動く Terraform のバージョンは選択肢から指定する形で、利用可能なバージョンは更新されていく（特定バージョンへの固定はコード側の required_version でも担保する）

内部の仕組み

スタックを作成すると、Terraform 構成・変数・state が Resource Manager に保持されます。ジョブを起動すると、サービスがマネージドな実行環境で Terraform を起動し、OCI プロバイダー経由で API を呼び出してリソースを作成・変更・削除します。

• plan ジョブは、現在の state と HCL の差分からこれから起きる変更（追加・変更・削除）を算出し、適用はせず計画だけを返す
• apply ジョブは計画に従って実際に API を呼び、完了後に state を自動更新する。実行中は state がロックされ、同時実行による破壊が防がれる
• destroy ジョブは state が管理するリソースをまとめて削除する。環境のクリーンアップに使う
• ドリフト検出は、state とクラウドの実体を突き合わせ、手作業で変更された差分を一覧化する。検出後はコードを直すか apply で収束させる
• 認証はリソースプリンシパルを使え、API 署名キーを構成に埋め込まずに OCI を操作できる

設計パターン / ベストプラクティス

• 環境ごとにスタックを分割: dev / stg / prod を別スタックにし、変数で差分を吸収する。本番の state を取り違える事故を防ぐ
• Git ソース管理と連携: 構成を Git で管理し、Resource Manager のスタックを Git に紐づけてコードレビュー → plan → apply のフローを回す
• モジュール化と再利用: 共通構成を Terraform モジュールに切り出し、複数スタックで再利用する
• 機密値は Vault から: パスワードや API キーを HCL や変数に直書きせず、Vault（Secrets） から参照する
• 大きな構成は分割: ネットワーク基盤・共有サービス・アプリ層などレイヤごとにスタックを分け、爆発半径と実行時間を抑える
• 既存リソースは import で取り込む: 手作業で作った既存リソースを import で state に取り込み、以後コード管理に移行する
• destroy はガードを付ける: 本番スタックの destroy は権限分離・承認フローで保護し、誤実行を防ぐ

運用・監視

• ジョブの実行履歴（plan / apply / destroy のログと結果）はスタックから参照でき、失敗時はログでエラー箇所を特定する
• 「誰がいつスタックを操作したか」は OCI Audit で追跡する。IaC 操作の監査証跡として重要
• ドリフト検出を定期的に実行し、手作業変更を検知してコードへ反映（または是正）する運用を回す
• ジョブの開始・完了を Events（イベント）で受け、Notifications へ通知したり Functions で後処理を起動するとパイプライン化できる
• state ロック中の同時実行はサービスが防ぐが、人による並行 apply の運用ルール（承認・ブランチ戦略）はチームで定める
• 失敗ジョブはコード修正後に再実行する。部分適用後の失敗では state とコードの差分を plan で確認してから収束させる

コスト

Resource Manager サービス自体の利用料は基本的にかからず、課金されるのは実際にプロビジョニングした OCI リソース（Compute・Storage・Database など）です。コスト最適化の本質は「不要な環境を残さないこと」にあります。

セキュリティ

• リソースプリンシパルで認証し、API 署名キーや認証情報を構成・変数に埋め込まない（鍵レス運用）。AWS の IAM ロール相当の考え方
• IAM ポリシー＋コンパートメントで、スタックの管理権限と Terraform が操作できるリソース範囲を最小権限に絞る
• 機密の入力値は変数に直書きせず Vault（Secrets） から取得する。state にも秘密情報が残り得る点に注意する
• プライベートな Git やプライベート Kubernetes へ到達する場合はプライベートエンドポイントを使い、経路を VCN 内に閉じる
• 本番スタックの destroy や apply は権限分離・承認フローで保護し、誤操作・内部不正による一括削除を防ぐ

Well-Architected の観点

• 運用上の優秀性（Operational Excellence）: 手作業を排し、すべての構成変更をコードのレビュー → plan → apply という再現可能な手順に乗せる。変更履歴は Git と Audit で追跡できる
• 信頼性（Reliability）: 同一構成を何度でも再現でき、災害復旧時の再構築や環境のスケールアウトが容易。state ロックとドリフト検出により構成の整合性を保つ
• セキュリティ（Security）: リソースプリンシパルによる鍵レス認証と最小権限ポリシーで、認証情報の漏洩リスクと過剰権限を抑える
• コスト最適化（Cost Optimization）: 検証環境を destroy で一括撤去でき、放置による無駄な課金を減らせる

試験で問われるポイント

関連サービス・比較

OCI Resource Manager と、相当する AWS のサービスである CloudFormation を比較します。最大の違いは、テンプレート言語が独自仕様か標準 Terraform かという点です。

なお OCI 内では、構成変更の通知連携に Events / Notifications、機密値の保管に Vault（Secrets）、操作監査に Audit を組み合わせて使います。

ハンズオン / CLI例

oci resource-manager コマンドで、スタックの作成からジョブ実行までを行えます。次は Object Storage 上の構成 ZIP からスタックを作り、plan と apply を実行する例です。

# 1) Terraform 構成（ZIP）からスタックを作成する
#    rm-stack 用の権限とリソースプリンシパルでの実行を前提にする
oci resource-manager stack create \
  --compartment-id "$COMPARTMENT_OCID" \
  --display-name "network-baseline" \
  --description "VCN and subnets via Terraform" \
  --config-source ./network-baseline.zip \
  --variables '{"region":"ap-tokyo-1","vcn_cidr":"10.0.0.0/16"}'

# 2) 変更計画（plan）ジョブを実行し、これから起きる差分を確認する
oci resource-manager job create-plan-job \
  --stack-id "$STACK_OCID"

# 3) plan の内容を確認してから apply ジョブを実行する
#    apply-job-plan-resolution で「どの plan を適用するか」を指定できる
oci resource-manager job create-apply-job \
  --stack-id "$STACK_OCID" \
  --apply-job-plan-resolution '{"isUseLatestJobId": true}'

# 4) ジョブの実行ログを取得して結果を確認する
oci resource-manager job get-job-logs \
  --job-id "$JOB_OCID" --output table

# 5) 検証環境を片付ける（destroy）。本番では権限分離・承認フローで保護する
oci resource-manager job create-destroy-job \
  --stack-id "$STACK_OCID"