主控台、Shell 與 SSH：進入同一台機器的三扇門

連不上某台機器。先別慌，只要問一個問題：當時走的是哪一扇門？

進入同一台機器的門有三扇，每一扇都依賴不同的元件保持運作。知道是哪一扇關上了，就能直接看出問題出在哪裡。

三扇門

主控台。直接看機器的螢幕、使用它的鍵盤。相當於走到實體伺服器前面接上一台螢幕。它不使用客體的網路，而是經由主機。

Shell。輸入指令並取得輸出。它不模擬螢幕，而是直接開啟一條指令通道。

SSH。在客體內部執行的服務。它需要網路，需要服務正在執行，也需要有效的登入資訊。

規則：門越舒適，客體內部就要有越多東西正常運作

SSH 最舒適。從自己的終端機連線，可以複製貼上，也能搬移檔案。代價是它要求最多：網路設定必須正確，網路介面必須啟用，服務必須執行中，防火牆必須放行，金鑰或密碼必須有效。這條鏈上任何一環斷掉，這扇門就關上了。

主控台最不舒適。在瀏覽器裡看著一個畫面，複製貼上通常也不順手。代價是它幾乎什麼都不要求：客體的網路可以是壞的，防火牆可以擋下一切，SSH 甚至可以根本沒有安裝，畫面照樣會出現。因為那個畫面來自主機，而不是來自客體的網路。

所以主控台是一條救援途徑。不是因為它舒適，而是因為它依賴的東西極少。

典型事故

修改了一項網路設定並套用。連線中斷，而且再也連不回來。

所做的變更甚至不一定有錯：有時設定是正確的，只是網路介面切換的那一刻工作階段就斷了。但現在已經無法透過網路連上機器，而要修正問題，偏偏又必須先連上機器。

打開主控台，畫面出現，把設定改正。因為主控台從不經過網路，網路壞了也碰不到它。

由此而來的實務習慣：動網路設定之前，先確認主控台打得開。在手上已經握有一條可用救援途徑的時候做有風險的事，而不是出事之後才去找。

在 Shell 這一側，容器和虛擬機器不是同一回事

這個區別讓很多人意外，因為在面板上兩者並排出現，而且都提供同一個按鈕。

在容器中，主機可以直接進入。容器與主機共用核心，所以容器內的處理程序對主機來說本來就看得見。主機可以在裡面執行指令，不需要容器內部配合任何事。

在虛擬機器中就不是這樣。虛擬機器是一個密封的盒子：主機只把它的磁碟和記憶體看成一個個資料區塊，不知道裡面裝了什麼。主機無法把指令塞進盒子裡。

唯一的進入方式，是盒子裡有某個東西在聆聽。這正是客體代理程式的角色：安裝在虛擬機器內部的一個小服務，負責聆聽來自主機的請求並回應。如果沒有安裝，這台虛擬機器就沒有 Shell 這扇門，這不是故障，而是架構本身的結果。

基於同樣的原因，虛擬機器關機時 Shell 也無法使用。那裡沒有任何東西在聆聽。相反地，主控台可以顯示一台已關機機器的畫面，一旦啟動，從第一秒起發生的一切都看得到。

主控台也有極限

老實說，主控台不是魔法。

如果主機本身停擺，三扇門全都會關上。主控台經由主機運作，主機倒下，它也跟著倒下。

另外還有一點：主控台提供的是畫面，不是檔案。需要把檔案取出時，主控台是很差的工具。適合救援，不適合日常工作。

最後，主控台存取是一項獨立的權限。使用者能讀取面板，不代表就能查看機器的畫面，而這種區隔是刻意的：畫面會顯示正在進行的工作內容。

Atlas 的做法

Atlas 從自己的畫面開啟主控台，不需要再登入一次。這聽起來是小事，但背後有一段值得老實交代的經過。

主控台其實位在 Proxmox 面板自己的位址上，Atlas 則在另一個位址。對瀏覽器來說，這是兩個不同的網站，一個網站的工作階段不會自行帶到另一個網站。如果什麼都不做，使用者按下主控台按鈕時會得到沒有工作階段的錯誤，並被要求再登入面板一次。

第一個解法是：在一個看不見的框架裡把工作階段交給面板。它確實有效。後來瀏覽器收緊了第三方 Cookie 規則，它就不再有效了。程式碼本身沒有錯誤；是它所依賴的地基變了。

第二個解法留了下來，因為它更穩固：主控台改由 Atlas 自己的位址提供。瀏覽器看到的是單一網站，不再有需要交接的工作階段，問題從根源消失。

兩個小而誠實的細節：從面板傳回的回應中，設定 Cookie 的標頭會被移除，因此 Atlas 不會在自己的位址上累積面板的 Cookie。而且與面板之間的連線始終留在機器內部，從不經由網路向外傳送。

不論是哪一套產品，通用的教訓都是：原本可用的解法失效，不一定代表有錯誤。有時是原本依賴的某個假設改變了。能長久留存的解法，是依賴最少假設的那一個。