Docker 在 Proxmox 上該放在哪裡：擺放位置的決定與 compose 陷阱

Proxmox 已經裝好，接下來想執行容器。問題不在於怎麼安裝，而在於要放在哪裡。這不是品味問題，而是一個東西壞掉時會連帶壞掉多少東西的問題。

三種擺放位置

直接裝在主機上。最簡單，也正是不該做的那一種。主機是上面所有東西所倚靠的那一層。裝在那裡的任何東西，都落在每一台虛擬機器的爆炸半徑之內：一次相依套件衝突、一顆塞滿的磁碟或一次有問題的更新，帶走的不只是容器，而是所有東西。

裝在系統容器裡。輕量，架設也快。代價是在容器裡面執行容器，而這種安排有它自己的棘手之處：權限模型、檔案系統層、共用的核心。經過深思熟慮選擇它是合理的；只因為比較簡單而選擇它，就會帶來意外。

裝在虛擬機器裡。帳面上最重，實務上最乾淨。容器環境垮掉時，垮掉的是一台虛擬機器，而不是整台伺服器。想重建時，重建的也只是一台機器。

決定一切的那個問題

如果這個壞了，其他所有東西會怎樣？裝在主機上，答案是全部；裝在虛擬機器裡，答案是其中一台。資源用量、安裝難易度，跟這個答案相比都是次要的。

後半段：compose 是一支程式

compose 檔案看起來像設定，但它不是。執行它就是在執行程式碼，而且是以執行者的權限執行。裡面的兩行就足以把整台機器交給容器。

人們從網路上複製 compose 檔案時，不會有複製指令時的那種不安。差別不在危險程度，而在外觀：指令看起來就是指令，compose 看起來卻像設定檔。看起來像設定檔，並不代表它安全。

執行前要檢查的四行

是否把主機的檔案系統掛載進去。是否要求特權模式。是否把管理程式本身的 socket 交給容器。是否直接使用主機的網路。

這四項正是刺穿容器邊界的那幾行：只要出現其中一項，那個容器就不再是容器，而是主機本身。檢查它們只需要十秒，而這十秒比本文其他所有內容都更有價值。

Atlas 的做法

Atlas 會在安裝之前掃描 compose 檔案與安裝腳本，而且這項掃描位於伺服器端，而不是介面上。因此無論介面送出什麼，這項檢查都無法被略過。

發現的問題分為兩個等級。紅色代表會讓容器跨出容器邊界的項目，也就是等同於主機的權限；這種情況需要明確的核准。黃色代表可以刻意這麼做、但必須事先告知的項目。在應用程式目錄這一側，紅色完全不被接受。

還有一個重要的細節：掃描器不提供意見，只回報事實。它不會說這很危險，而是說明這一行會做什麼。由閱讀的人來決定，因為同一行在某個環境中可以接受，在另一個環境中卻可能無法接受。