OCIのコンパートメント設計の参考資料と設計例

はじめに

こんにちは、技術部の内藤です。

OCIでコンパートメント設計をするときに参考にしたほうがよい公式の資料と、それらを参考にしたシンプルなコンパートメント設計を紹介します。

OCIのコンパートメントはAWSにはない概念なので、まずは公式資料で理解を深めましょう。

参考にしたほうがよい資料

まずはこの資料で、コンパートメントの基本を理解しましょう。左下のページでいう19ページからがコンパートメントです。

OCI技術資料 : IDおよびアクセス管理 (IAM) 概要 - Speaker Deck


次にこの資料で、コンパートメントの設計を理解しましょう。コンパートメントの内容はいくつかありますが、設計の観点だと、左下のページでいう60ページからです。
OCI技術資料 : IDおよびアクセス管理 (IAM) 詳細 - Speaker Deck


上記で、基本的なコンパートメント設計はできる、というより例をそのままマネすればいいわけですが、以下の公式ブログもぜひご覧ください。Oracleの公式が考えるベストプラクティスです。

コンパートメントのベスト・プラクティス


最後に、公式ドキュメントも読んでおきましょう。

テナンシを設定するためのベスト・プラクティスについて学習

資料を参考にしたシンプルなコンパートメント設計例

前提

この前提で例を記載します。

  • テナンシ内に複数プロダクトが存在している
  • プロダクトごとに複数の環境が存在している

なお、コンパートメント内のリソースやコンパートメント自体の移動は可能なので、最初は以下のようにシンプルに作成しておいて、慣れてきて不都合が出てから分割することも可能です。

最もシンプル

productA,B,Cは、組織によっては部署などのほうが適している可能性があるので、適宜変えてください。

  • root
    • productA
      • env1
      • env2
      • env3
    • productB
      • env1
      • env2
      • env3
    • productC
      • env1
      • env2
      • env3

ネットワークとアプリケーションを分離

ネットワーク管理者とアプリケーション管理者が別の場合は、以下のようにネットワークとアプリケーションを分離するのもよいです。

  • root
    • productA
      • network
        • env1
        • env2
        • env3
      • app
        • env1
        • env2
        • env3
    • productB
      • 省略
    • productC
      • 省略

なお、以下のように、プロダクトより先にネットワークとアプリケーションを分けるのは、アプリケーション管理者とネットワーク管理者が明確に分けられていない限りは、私はおすすめしません。コンソールでのコンパートメントの切り替えがわかりにくくなります。
※あくまで主観です

  • root
    • network
      • productA
        • env1
        • env2
        • env3
      • productB
        • env1
        • env2
        • env3
      • productC
        • env1
        • env2
        • env3
    • app
      • productA
        • env1
        • env2
        • env3
      • productB
        • env1
        • env2
        • env3
      • productC
        • env1
        • env2
        • env3

おわりに

おわりです。