OCI 架構入門：Tenancy、Compartment、Resource 三層結構完整圖解
恭喜你，帳號開好了！
如果你照著上一篇文章的建議申請了 OCI Always Free 帳號，你應該已經成功登入了 OCI Console。但接下來，你大概會碰到一個讓人有點困惑的畫面。
開好帳號之後，你一定會碰到的問題
打開 OCI Console，你想做的第一件事可能是「來開一台 VM 吧」。但你很快會發現：
- 建 VM 的時候，表單要你選一個 Compartment
- 建資料庫的時候，又要你選 Compartment
- 左側選單有一個 Compartment 下拉篩選器，而且選錯就什麼資源都看不到
- 你的帳號底下好像只有一個叫 root 的東西
「Compartment 到底是什麼？為什麼每個動作都要選它？我是不是應該先建幾個出來？」
如果你有這個疑問，恭喜你——你問對了問題。
在 OCI 的世界裡，搞懂資源的組織結構，比開一台 VM 更重要。因為這個結構決定了三件事：
- 誰能碰什麼 — 權限控制（IAM Policy）
- 錢花在哪裡 — 成本追蹤（Budget & Cost Analysis）
- 誰能看到什麼 — 資源可見性（Resource Visibility）
這篇文章會帶你搞懂 OCI 的三層架構——Tenancy → Compartment → Resource，並且跟 GCP 的組織結構做個對比。最後，我會設計一套簡單但實用的 Dev / Test / Prod Compartment 結構，讓你在 OCI 上從第一天就建立好的管理習慣。
OCI 的三層架構：Tenancy → Compartment → Resource
OCI 把所有東西裝在一個簡單的三層結構裡。你可以把它想像成一棟辦公大樓：
| 層級 | OCI 概念 | 大樓比喻 |
|---|---|---|
| 第 1 層 | Tenancy | 整棟大樓 |
| 第 2 層 | Compartment | 大樓裡的樓層與房間 |
| 第 3 層 | Resource | 房間裡的辦公設備 |
讓我們逐層拆解。
Tenancy：你的 OCI 世界的起點
當你成功註冊 OCI 帳號的那一刻，Oracle 就替你建立了一個 Tenancy。
一個帳號 = 一個 Tenancy，就這麼簡單。
Tenancy 是你在 OCI 裡的最頂層容器，所有的資源、所有的設定、所有的帳單，都歸屬在這個 Tenancy 底下。你可以把它理解為「你的 OCI 世界」——它有一個唯一的 ID（OCID），也有一個你在註冊時選定的 Home Region。
給新手的重點：你不需要「建立」Tenancy，它在你開帳號時就自動產生了。你也不會有第二個 Tenancy——除非你再申請一個新帳號。
還有一個容易搞混的地方：Tenancy 本身就是一個 Compartment——它是 root Compartment。所以當你登入 Console 只看到一個 root，那就是你的 Tenancy。
Compartment：OCI 最核心的管理概念
如果這篇文章你只記住一個概念，請記住這個：Compartment。
Compartment 是 OCI 用來分組和管理資源的邏輯容器。它不是實體的機房或網路區段，而是一個管理層面的「資料夾」。但這個資料夾比你電腦上的資料夾強大得多，因為它能控制三件事：
| 能力 | 說明 | 範例 |
|---|---|---|
| 權限控制 | 透過 IAM Policy 定義「誰能在這個 Compartment 裡做什麼」 | 「Dev 團隊只能管理 dev-compartment 裡的資源」 |
| 成本追蹤 | 設定 Budget，追蹤每個 Compartment 的花費 | 「prod 環境這個月花了多少錢？」 |
| 資源可見性 | Console 的 Compartment 篩選器決定你看到哪些資源 | 「切到 test-compartment，只看到測試環境的機器」 |
Compartment 的幾個重要特性
- 可以巢狀：Compartment 裡面可以再建 Compartment，最多 6 層深。就像大樓裡的樓層還可以隔成不同的房間
- 資源可以搬家：建錯 Compartment 了？沒關係，Resource 可以 Move 到另一個 Compartment（不需要重建）
- Policy 會繼承：在上層 Compartment 設定的 Policy，會自動套用到所有子 Compartment
- 刪除有條件：Compartment 必須清空（裡面沒有任何資源）才能刪除
給新手的建議：剛開始不用想太複雜。先建 2–3 個 Compartment 把環境分開就好，後面可以隨時調整。文章最後會給你一個現成的結構範本。
Resource：你真正在用的東西
Resource 就是你在 OCI 上實際使用的服務實例。例如：
- 一台 Compute Instance（VM）
- 一個 Autonomous Database
- 一個 VCN（Virtual Cloud Network）
- 一個 OCI Function
- 一個 Object Storage Bucket
每一個 Resource 都有一個全域唯一的 OCID（Oracle Cloud Identifier），格式長這樣：
ocid1.<resource-type>.<realm>.<region>.<unique-id>
例如：ocid1.instance.oc1.ap-singapore-1.abcdefg12345
每個 Resource 都必須住在某個 Compartment 裡——就像每張辦公桌都必須放在某個房間裡。建立 Resource 的時候選錯 Compartment 也不用緊張，之後可以 Move。
如果你用過 GCP：架構對照表
如果你有 GCP 的使用經驗，這一段會幫你快速建立 OCI 的心智模型。如果你是雲端新手，也可以反過來讀——學完 OCI 再看 GCP，你會發現概念完全相通。
GCP 的四層架構
GCP 的資源組織結構比 OCI 多一層，一共四層：
| 層級 | GCP 概念 | 說明 |
|---|---|---|
| 第 1 層 | Organization | 綁定 Google Workspace 或 Cloud Identity 網域，是整個組織的最頂層 |
| 第 2 層 | Folder | 選用的分組工具，可巢狀，常用來區分團隊或環境 |
| 第 3 層 | Project | GCP 最核心的管理單位——所有資源都住在 Project 裡 |
| 第 4 層 | Resource | Compute Engine、Cloud SQL、Cloud Functions 等實際服務 |
圖解對照：OCI vs GCP
先看 OCI 的結構：
再看 GCP 的結構：
逐層對照表
| 功能 | OCI | GCP | 差異重點 |
|---|---|---|---|
| 最頂層 | Tenancy | Organization | OCI 開帳號自動產生；GCP 需綁定 Google Workspace 網域 |
| 分組管理 | Compartment | Folder + Project | OCI 一層搞定；GCP 用 Folder 分組 + Project 管理，兩層分工 |
| 資源容器 | Compartment | Project | 資源最終住在這裡。OCI 的 Compartment 同時扮演「分組」和「容器」兩個角色 |
| 可否巢狀 | 可，最多 6 層 | Folder 可 / Project 不可 | OCI Compartment 可以無限套娃（6 層限制）；GCP 的 Project 是扁平的，不能巢狀 |
| 權限繼承 | 有，Policy 向下繼承 | 有，IAM 向下繼承 | 概念相同，語法不同 |
| 計費單位 | Compartment（透過 Budget） | Project（Billing Account） | GCP 以 Project 為帳單單位；OCI 以 Compartment + Budget 追蹤 |
| 資源搬家 | 支援 Move Resource | 支援 Move Resource | 兩邊都支援，但操作方式不同 |
關鍵差異總結
最大的差異在於 Compartment 身兼多職：
- 在 GCP 的世界裡，「分組」和「資源容器」是兩個獨立概念——Folder 負責分組，Project 負責裝資源。你可以有 Folder 但不一定要有。
- 在 OCI 的世界裡，Compartment 同時是分組工具也是資源容器。這讓結構更簡潔，但也代表你需要更仔細地規劃 Compartment 的層級。
一句話記住：GCP 是「Folder 管分類、Project 管資源」；OCI 是「Compartment 全包」。
實戰設計：Dev / Test / Prod Compartment 結構
理解了三層架構之後，下一個問題就是：「那我應該怎麼規劃 Compartment？」
最常見的錯誤是——什麼都丟在 root Compartment 裡。
剛開始玩 OCI 的時候，你可能覺得「反正就我一個人在用，分那麼多 Compartment 幹嘛？」但隨著資源越來越多，你會開始遇到這些問題：
- 權限無法細分：所有 Policy 都綁在 root，想限制某個 API Key 只能存取測試環境？做不到
- 帳單看不清楚：prod 和 dev 的花費混在一起，根本不知道錢花去哪了
- 誤刪風險：清理測試資源的時候，一不小心砍到正式環境的東西
解決方法很簡單：從第一天就把環境分開。
建議的 Compartment 結構
以下是一個適合獨立開發者或小團隊的基本結構：
每個 Compartment 的角色
| Compartment | 用途 | 放什麼資源 |
|---|---|---|
| network | 集中管理所有網路資源 | VCN、Subnet、Internet Gateway、Security List、NSG |
| shared-services | 跨環境共用的服務 | Vault（密鑰管理）、Object Storage、Container Registry、Logging |
| dev | 開發環境 | 開發用的 VM、資料庫、測試用的 Functions |
| test | 測試 / Staging 環境 | QA 驗證用的資源，資料可以是 prod 的脫敏副本 |
| prod | 正式生產環境 | 對外服務的 VM、正式資料庫、排程 Functions |
為什麼要把 Network 和 Shared 獨立出來？
Network 獨立：VCN 通常是跨環境共用的（dev / test / prod 的 VM 可能都在同一個 VCN 裡，用不同的 Subnet 隔離）。把網路資源集中管理，可以避免「每個環境各搞一套網路，最後搞不清楚哪個 Security List 開了哪些 Port」的混亂局面。
Shared-services 獨立：有些服務天生就是跨環境的。例如 Vault 裡的 Master Key 不會分 dev/prod 各一把；Object Storage 的備份 Bucket 也可能跨環境使用。把這些共用服務集中管理，Policy 寫起來更乾淨。
設計原則
最後整理三個設計原則，不管你的專案規模大小都適用：
- 環境隔離：Dev / Test / Prod 各自獨立，互不干擾。最理想的狀態是——砍掉整個 dev Compartment 的所有資源，prod 完全不受影響
- 最小權限：每個 Compartment 只授予必要的權限。例如 CI/CD 的 Service Account 只能存取 prod Compartment 裡的特定資源
- 計費透明：為每個 Compartment 設定 Budget，每月收到花費報告。就算現在全用免費額度，養成這個習慣，未來擴展時會省下很多麻煩
總結：一張圖記住 OCI 架構
整篇文章濃縮成一張圖：
- Tenancy：你的 OCI 世界，開帳號自動產生
- Compartment：分組 + 權限 + 計費的核心單位，可巢狀
- Resource：你實際使用的服務，必須住在 Compartment 裡
如果你用過 GCP，記住：OCI 的 Compartment ≈ GCP 的 Folder + Project 合體。
如果你是雲端新手，記住：先把 Compartment 結構想好，再開始建資源。這個習慣會在未來幫你省下無數的麻煩。
想了解更多？
如果您對我們的技術架構感興趣，歡迎查看 系統架構頁面，了解可轉債實驗室背後的 Data Pipeline 與即時監控系統。
也歡迎加入我們的 Telegram 頻道，每天分享最新的可轉債精選策略整理。
接下來
這是 cb lab 雲端架構系列的第二篇文章。如果你還沒看過第一篇，建議先從 什麼是 OCI？獨立開發者為什麼應該試試 Oracle Cloud Infrastructure 開始。
後續我們會繼續深入每個 OCI 服務的實作紀錄：
- Autonomous Database：什麼是 OLAP？OLTP？OCI ADB 說：我全都要
- OCI Functions：用 Serverless 打造 ETL Pipeline
- OCI Networking：VCN、Security List、與防火牆設定
- OCI Compute：ARM VM 的設定與效能體驗