AWS と OCI のマルチクラウド環境構築中の社内SEです。
AWS は運用歴5年で OCI は初となります。苦労しながら構築しています。
この記事にはコンパートメントの概念や説明等はありません。
コンパートメントを利用した運用を計画したが頓挫してしまい、
ルートのみの運用に戻したお話となります。
OCI コンソールの利用者（管理者？）は
1. コンパートメントの概念を知っていないといけない。
2. 子のリソースが親のリソースに表示されない。
2-1. 設計(構成)が頭に無いといけない。
2-2. 画面遷移の度にコンパートメントを変更しなければいけない。
3. MySQL はリソースの移動に対応していない。
に頭を悩まされます。
「1.」おそらく OCI の売りにしたいのだろうと思うのですが、非常にわかり辛いです。
皆様も検索に苦労されていると思います。はっきり言いまして VMware 時代からやっていた、
アクセス権のコントロールで十分可能です。理由は主に「2.」に記載します。
「2.」が非常につらいです。
「えっと、このセキュリティ・リストはＡというコンパートメントにあって…、だけどこのサブネットはＢというコンパートメントあって」とか、「あれ？、セキュリティ・リストがないぞ…、どこにあるのかなぁ。Ａ→Ｂ→Ｃとあった」みたいな事になります。
コンパートメントの概念があるリソースと無いリソースがあるのも非常に面倒です。【ロードバランサー】は紐づくリソースの【リスナー】および【バックエンドセット】にはコンパートメントの概念はありません。それに対して【ボールド】に紐づく【キー】はコンパートメントの概念があり、別々に配置可能です。結果「あれボールドの下にキーが無いぞ。作ってなかったかな？」とかになりかねません。というか何度もなりました。
「3.」これはイカンでしょうといいたいです。
MySQL を作り直さないといけません。
利点をあげるとしましたら、プロジェクトや部署ごとにコストを管理することができます。
但し、コストに関したら「タグ別コスト」が出せますのでコンパートメントで括る必要性はないかなと感じます。
予想ですがバージョンアップによって将来的には子のリソースが親のリソースに表示できるようになると思います。これがないとかなり厳しいです。
◆おまけ
Q. コンパートメント削除時にリソースが残っていたらどうなるのか？
A. リソースがまだコンパートメントに存在する場合、削除アクションは失敗し、コンパートメントはアクティブ状態に戻ります。
失敗の前に警告を出して欲しいです。
一旦「削除中」のステータスになり、しばらく待たされます。画面を見たら「アクティブ」に戻っていました。CLI で探せそうな気がしますが、CLI も学習中なので今は手で探しています。
◆追記(2023/04/11)
「コンパートメントが空ではありません。」と警告が出るパターンもあるようです。
おまけの画像は移動し忘れたリソースが残っていました。
今回の警告は予想ですが、サブコンパートメントのステータスが「削除済み」で残っているからではと思っております。現在調査中です。
