十年前我就在玩 OpenStack：翻出 2016 年的 Horizon 簡報

整理 Notion 舊筆記的時候，翻到一頁標題寫著 「Introduction OpenStack Horizon」 的簡報，作者欄寫的是我自己的名字。

點進去看日期——2016 年 8 月 5 日。

那一刻有點恍惚。2016 年，Kubernetes 才剛滿兩歲、還沒變成今天這個「容器界的作業系統」；Docker 正紅但大家還在吵它到底能不能上 production；AWS、GCP、Azure 三雄鼎立的局面也還沒完全定型。而那時候的我，已經在台上講一套叫 OpenStack 的東西——一套讓你自己蓋一朵雲的開源軟體。

這篇就當作一個時間膠囊：把那份簡報講過的內容，用 2026 年的角度重新復刻一次。在此留個紀錄，原來我碰雲端基礎建設是在那麼古早年代。

原始簡報還掛在 SlideShare 上：Introduction OpenStack Horizon。介面是 2016 年的味道 XD。

introduction-openstackhorizon　from　bobo52310

先講脈絡：OpenStack 是什麼？

簡單說，OpenStack 是一套開源軟體，讓你在自己的機房裡蓋出一朵「私有雲」——也就是 AWS EC2、GCP Compute Engine 那種「點一下就生出一台虛擬機」的能力，只是這次跑在你自己的硬體上。

它不是單一程式，而是一堆服務組合起來的：

Nova — 運算（開虛擬機）
Glance — 映像檔管理（VM 的範本）
Keystone — 身分驗證（誰能用、能用什麼）
Neutron — 網路（虛擬網路、子網、路由）
Cinder / Swift — 區塊儲存 / 物件儲存

問題來了：這麼多服務，每個都有自己的 API。一般使用者總不能每開一台機器就去敲一次 REST API 吧？ 得有一個圖形化、最好是網頁版的入口，讓人點一點就能管理自己的運算、儲存、網路資源。

那個入口，就是 Horizon。

什麼是 Horizon？

當年簡報上我寫了三句話，到今天依然準確：

Horizon 是 OpenStack 應用程式的「門戶」。 提供 Web-based 圖形化介面，方便使用者針對服務資源進行設定。建構在 Django 框架之上。

換句話說，Horizon 就是 OpenStack 的官方儀表板（Dashboard）。你登入後看到的那個能開機器、掛硬碟、設防火牆規則的網頁後台，就是它。

而它自己其實什麼都不做——它只是個前台。所有實際操作，都是 Horizon 透過 API 去呼叫後面的 Nova、Neutron、Glance……幫你轉達。這個設計有個好處：

Horizon 可以獨立部署。 它跟其他服務之間只靠 API 溝通，所以你可以把它單獨架在一台機器上，後端服務散在別處，互不綁死。

Horizon 的三種 Dashboard

簡報裡我特別拆解了 Horizon 的權限分層——它依角色提供三種不同的 Dashboard：

Dashboard	給誰用	能做什麼
使用者 Dashboard	終端使用者	在管理員開放的權限與配額範圍內，管理自己的資源
權限設定 Dashboard	管理者	設定每個使用者可以操作哪些服務
系統 Dashboard	最高管理者	總覽整個應用程式的大小與執行狀況

這套「使用者 / 管理 / 系統」的分層，其實就是今天所有雲端控制台都有的 RBAC（角色權限控制）雛形——只是 2016 年的 Horizon 已經把它做成內建的三張面板了。

怎麼安裝？還有那個經典的坑

簡報第 7 頁列了最小安裝需求，Horizon 要跑起來，後面至少得有這幾個服務在：

Nova（compute、api、scheduler、network）
Glance
Keystone
Neutron（除非你用的是舊的 nova-network）

📌 2026 註：這裡的「nova-network」選項今天已經不存在了——它就在這份簡報之後幾個月被標記淘汰，後來整個被移除，現在 Neutron 是唯一的網路方案。完整時間軸見文末〈2026 更正備註〉。

然後第 8 頁，我放了一張截圖，上面只有一行字：

Oops! Unable to establish connection to keystone endpoint.

這大概是每個第一次裝 Horizon 的人都會撞到的畫面。Horizon 自己沒壞，是它找不到 Keystone。 因為 Horizon 開機第一件事就是去問 Keystone「這個人是誰、有沒有權限」，只要 endpoint 設錯、Keystone 沒起來、或網路不通，整個儀表板就直接給你這張臉。

放這張截圖不是為了搞笑——是因為它太典型了。雲端基礎建設的痛，從來不是「功能不會用」，而是一堆服務之間的連線、憑證、endpoint 對不起來。十年過去，這件事一點都沒變，只是場景換成了 K8s 的 Service、Ingress 跟 ServiceAccount。

為什麼 Horizon 選 Django？

最後一頁，我整理了 Horizon 用 Django 當底層框架的理由：

Open Source — 跟 OpenStack 整體的開源精神一致
i18n 多國語系 — 雲端產品要面對全球使用者
MVC 架構 — 把介面、邏輯、資料切乾淨
內建權限管理 — 剛好接上前面那套三層 Dashboard
套件生態豐富、易擴充 — 而且能用 pip 這個 Python 套件管理工具直接裝

現在回頭看，這個選擇蠻合理的：OpenStack 本身就是 Python 寫的，Horizon 用 Django（同樣是 Python 生態的當家網頁框架）等於跟整個專案的技術棧無縫對接。

🕰️ 2026 更正備註：哪些講法已經過時

十年是一段不短的時間。把這份簡報重貼出來之前，我特地查證了一輪——有三件事，當年的講法到 2026 年已經要改口：

一、nova-network 整個消失了。 安裝那頁我寫「Neutron（除非你用舊的 nova-network）」。這個「除非」今天已經不成立：nova-network 在 2016 年底的 Newton 版（就在這份簡報之後幾個月）被標記淘汰，2018 年的 Rocky 移除相關 API，2019 年的 Stein（19.0.0）正式整個拔掉。今天要在 OpenStack 上做網路，Neutron 是唯一解。

二、版本命名把英文字母用完了。 簡報裡有一頁叫「Series and milestones」，連到 OpenStack 的版本命名規則。當年的命名是照英文字母順序走（Austin、Bexar……一路到簡報當下的 Mitaka / Newton）。但字母總會用完——2022 年的 **Zed（Z）**就是字母表的終點。之後 OpenStack 改成「年份.序號」制，從 **2023.1「Antelope」**重新由 A 開始算。截至 2026 年 6 月，最新的正式版是 2026.1「Gazpacho」（2026 年 4 月釋出），已經是第 33 個版本了。

三、OpenStack 換了東家。 2016 年管理 OpenStack 的是 OpenStack Foundation。後來它在 2020 年宣布改名、2021 年正式啟用新名 OpenInfra Foundation（Open Infrastructure，因為旗下早就不只 OpenStack）；2025 年 3 月先宣布要併入 Linux Foundation，並於同年 7 月正式完成。也就是說，今天 Linux、OpenStack、Kubernetes 這三個專案，正式收在同一個基金會的傘下了。

岔題一句：連載這份簡報的 SlideShare 平台本身，也在 2020 年被 Scribd 收購——連放簡報的地方都換過老闆了。XD 真有趣

從 2026 回頭看

把這份簡報重讀一遍，有幾個感觸：

一、OpenStack 的歷史定位。 在「自建私有雲」這個需求最旺的那幾年（大約 2013–2018），OpenStack 幾乎是唯一的開源答案。電信商、銀行、政府這些不能把資料丟上公有雲的單位，都靠它撐起自己的 IaaS。後來公有雲變便宜、Kubernetes 把「容器編排」這層抽象做得更漂亮，戰場才慢慢轉移——但 OpenStack 並沒有消失，今天在電信（尤其是 5G 核網）和私有雲市場依然活著。

二、底層的道理是相通的。 當年我講的那些東西——「要有一個圖形化入口」「服務之間靠 API 溝通」「身分驗證是一切的前提」「endpoint 對不起來整個就掛」——換到今天的雲原生世界，一個字都不用改。技術名詞會換，但基礎建設的本質不會變。先搞懂過一輪 OpenStack 這種「把一朵雲拆給你看」的系統，再回頭學 Kubernetes 或任何一家公有雲，會輕鬆很多。

三、留個紀錄。 這才是我把它寫出來的真正原因。很多人認識我，是從這幾年的 AI、Side Project 或部落格開始的。但其實早在 2016 年，我就已經站在台上講雲端基礎建設了。(一轉眼就十年過去了，光陰似箭呀…)

十年前蓋一朵雲要懂 Nova、Glance、Keystone、Neutron 怎麼兜在一起；十年後我在玩的是 AI Agent 怎麼兜在一起。工具一直換，但那個「想把複雜系統拆開、搞懂、再講給別人聽」的人，還是同一個。