はじめに
こんにちは、技術部の内藤です。
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
- productA
ネットワークとアプリケーションを分離
ネットワーク管理者とアプリケーション管理者が別の場合は、以下のようにネットワークとアプリケーションを分離するのもよいです。
- root
- productA
- network
- env1
- env2
- env3
- app
- env1
- env2
- env3
- network
- productB
- 省略
- productC
- 省略
- productA
なお、以下のように、プロダクトより先にネットワークとアプリケーションを分けるのは、アプリケーション管理者とネットワーク管理者が明確に分けられていない限りは、私はおすすめしません。コンソールでのコンパートメントの切り替えがわかりにくくなります。
※あくまで主観です
- root
- network
- productA
- env1
- env2
- env3
- productB
- env1
- env2
- env3
- productC
- env1
- env2
- env3
- productA
- app
- productA
- env1
- env2
- env3
- productB
- env1
- env2
- env3
- productC
- env1
- env2
- env3
- productA
- network
おわりに
おわりです。