Docker Desktop for Linux 常見問題 (FAQs)
為什麼 Docker Desktop for Linux 需要執行虛擬機器 (VM)？
Docker Desktop for Linux 執行虛擬機器 (VM) 的原因如下：
確保 Docker Desktop 在跨平台時提供一致的體驗。
根據研究，使用者希望使用 Docker Desktop for Linux 最常提到的原因是，希望能確保與所有主流作業系統上的 Docker Desktop 保持一致的體驗與功能對等。使用 VM 可以確保 Linux 使用者的 Docker Desktop 體驗將與 Windows 和 macOS 的體驗高度一致。
為了使用新的核心功能。
有時我們會想要利用新的作業系統功能。由於我們掌控 VM 內部的核心與作業系統，因此我們能立即將這些功能推送給所有使用者，即使是那些刻意停留在機器作業系統 LTS 版本的使用者也能使用。
為了增強安全性。
容器映像檔的弱點對主機環境構成了安全風險。網路上有大量非官方映像檔，無法保證其已針對已知弱點進行驗證。惡意使用者可能會將映像檔推送至公開登錄庫，並透過各種方式誘騙使用者拉取並執行它們。採用 VM 方式可降低此威脅，因為任何取得 root 權限的惡意軟體都僅限於 VM 環境內，無法存取主機。
為什麼不直接執行 rootless Docker？雖然這樣做在表面上有限制 root 使用者存取的好處，讓一切在「top」指令中看起來比較安全，但它允許非特權使用者在自己的使用者命名空間中取得
CAP_SYS_ADMIN並存取核心 API，而這些 API 並非預期供非特權使用者使用，從而導致弱點。在對效能影響最小的情況下，提供功能對等與增強安全性的優勢。
Docker Desktop for Linux 所使用的 VM 採用
VirtioFS，這是一種共享檔案系統，允許虛擬機器存取位於主機上的目錄樹。我們的內部基準測試顯示，在為 VM 配置適當資源的情況下，使用 VirtioFS 可以達到近乎原生的檔案系統效能。因此，我們調整了 Docker Desktop for Linux 中 VM 的預設可用記憶體。您可以在 Docker Desktop 的設定 (Settings) > 資源 (Resources) 分頁中，透過記憶體 (Memory) 滑桿根據您的特定需求調整此設定。
如何啟用檔案共享？
Docker Desktop for Linux 使用 VirtioFS 作為在主機與 Docker Desktop VM 之間啟用檔案共享的預設（目前也是唯一）機制。
為了不需要提升權限，且不對共享檔案的操作進行不必要的限制，Docker Desktop 在使用者命名空間（請參閱 user_namespaces(7)）內執行檔案共享服務 (virtiofsd)，並設定了 UID 與 GID 對應。因此，Docker Desktop 依賴主機設定以啟用當前使用者使用從屬 ID 委派。若要實現這一點，必須存在 /etc/subuid（請參閱 subuid(5)）與 /etc/subgid（請參閱 subgid(5)）檔案。Docker Desktop 僅支援透過檔案設定的從屬 ID 委派。Docker Desktop 將當前使用者 ID 與 GID 對應到容器內的 0。它會使用 /etc/subuid 與 /etc/subgid 中對應於當前使用者的第一個項目，來設定容器內大於 0 的 ID 對應。
| 容器內的 ID | 主機上的 ID |
|---|---|
| 0 (root) | 執行 Docker Desktop 的使用者 ID（例如 1000） |
| 1 | 0 + /etc/subuid//etc/subgid 中指定的 ID 範圍起始值（例如 100000） |
| 2 | 1 + /etc/subuid//etc/subgid 中指定的 ID 範圍起始值（例如 100001） |
| 3 | 2 + /etc/subuid//etc/subgid 中指定的 ID 範圍起始值（例如 100002） |
| ... | ... |
如果缺少 /etc/subuid 與 /etc/subgid，則需要建立它們。兩者都應包含格式為 <使用者名稱>:<ID 範圍起始值>:<ID 範圍大小> 的項目。例如，若要允許當前使用者使用從 100,000 到 165,535 的 ID：
$ grep "$USER" /etc/subuid >> /dev/null 2&>1 || (echo "$USER:100000:65536" | sudo tee -a /etc/subuid)
$ grep "$USER" /etc/subgid >> /dev/null 2&>1 || (echo "$USER:100000:65536" | sudo tee -a /etc/subgid)
若要驗證設定已正確建立，請檢查其內容：
$ echo $USER
exampleuser
$ cat /etc/subuid
exampleuser:100000:65536
$ cat /etc/subgid
exampleuser:100000:65536
在此情況下，如果 Docker Desktop 容器內的共享檔案被 chown 為 UID 為 1000 的使用者所有，它在主機上顯示為 UID 為 100999 的使用者所有。這會產生一個不幸的副作用，即無法在主機上輕鬆存取該檔案。解決此問題的方法是建立一個具有新 GID 的群組並將我們的使用者加入其中，或者為與 Docker Desktop VM 共享的資料夾設定遞迴 ACL（請參閱 setfacl(1)）。
Docker Desktop 將 Linux 容器儲存在哪裡？
Docker Desktop 將 Linux 容器與映像檔儲存在 Linux 檔案系統中的單個大型「磁碟映像檔」檔案中。這與 Linux 上的 Docker 不同，後者通常將容器與映像檔儲存在主機檔案系統的 /var/lib/docker 目錄中。
磁碟映像檔在哪裡？
若要找到磁碟映像檔，請從 Docker Desktop 儀表板選擇設定 (Settings)，然後從資源 (Resources) 分頁中選擇進階 (Advanced)。
進階 (Advanced) 分頁會顯示磁碟映像檔的位置。它也會顯示磁碟映像檔的最大大小以及磁碟映像檔目前實際佔用的空間。請注意，其他工具可能會以最大檔案大小而非實際檔案大小來顯示該檔案的空間使用量。
如果檔案太大怎麼辦？
如果磁碟映像檔太大，您可以：
- 將其移動到更大的磁碟機
- 刪除不必要的容器與映像檔
- 減小檔案允許的最大大小
如何將檔案移動到更大的磁碟機？
若要將磁碟映像檔移動到不同的位置：
從資源 (Resources) 分頁選擇設定 (Settings)，然後選擇進階 (Advanced)。
在磁碟映像檔位置 (Disk image location) 區段中，選擇瀏覽 (Browse) 並為磁碟映像檔選擇一個新位置。
選擇套用 (Apply) 以使變更生效。
請勿在 Finder 中直接移動該檔案，因為這可能會導致 Docker Desktop 無法追蹤該檔案。
如何刪除不必要的容器與映像檔？
檢查您是否有任何不必要的容器與映像檔。如果您的用戶端與 Daemon API 執行的是 1.25 或更新版本（使用用戶端上的 docker version 指令來檢查您的用戶端與 Daemon API 版本），您可以透過執行以下指令查看詳細的空間使用資訊：
$ docker system df -v
或者，若要列出映像檔，請執行：
$ docker image ls
若要列出容器，請執行：
$ docker container ls -a
如果有許多冗餘物件，請執行該指令：
$ docker system prune
此指令會移除所有已停止的容器、未使用的網路、懸空映像檔以及建置快取。
根據磁碟映像檔的格式，回收主機上的空間可能需要幾分鐘的時間：
- 如果檔案名稱為
Docker.raw：主機上的空間應在幾秒鐘內回收。 - 如果檔案名稱為
Docker.qcow2：空間將由背景處理程序在幾分鐘後釋放。
空間僅在刪除映像檔時才會釋放。當檔案在執行中的容器內被刪除時，空間不會自動釋放。若要隨時觸發空間回收，請執行指令：
$ docker run --privileged --pid=host docker/desktop-reclaim-space
請注意，許多工具會回報最大檔案大小，而非實際檔案大小。若要從終端機查詢主機上檔案的實際大小，請執行：
$ cd ~/.docker/desktop/vms/0/data
$ ls -klsh Docker.raw
2333548 -rw-r--r--@ 1 username staff 64G Dec 13 17:42 Docker.raw
在此範例中，磁碟的實際大小為 2333548 KB，而磁碟的最大大小為 64 GB。
如何減小檔案的最大大小？
若要減小磁碟映像檔的最大大小：
從 Docker Desktop 儀表板，從資源 (Resources) 分頁選擇設定 (Settings)，然後選擇進階 (Advanced)。
磁碟映像檔大小 (Disk image size) 區段包含一個滑桿，可讓您變更磁碟映像檔的最大大小。調整滑桿以設定較低的上限。
選取 Apply（套用）。
當您減小最大大小時，目前的磁碟映像檔會被刪除，因此所有容器與映像檔都會遺失。