以下內容為依據原文整理出的可實作、可教學的 17 個問題解決案例。每一案均包含問題、根因、解法、關鍵指令/設定、實測成效及練習與評估要點，適用於實戰教學、專案演練與能力評估。

Case #1: 用 Hyper-V 取代 VirtualBox，消除 Hypervisor 衝突並提升整合度

Problem Statement（問題陳述）

業務場景：開發者在 Windows 10 桌機上使用 Docker 進行日常開發，但過去依賴 Docker Toolbox（VirtualBox + Boot2Docker）。Hyper-V 與 VirtualBox 無法共存，導致環境衝突、切換成本高。為了避免破壞工作機器，開發者過去常改走 Linux VM + SSH 的繞路方案，無法與 Windows 工具鏈緊密整合。 技術挑戰：Hypervisor 排他性、工具分散（VirtualBox/Boot2Docker/docker-machine）、與 Windows CLI/批次流程整合困難。 影響範圍：開發體驗不佳、維運成本高、腳本自動化與本機整合困難。 複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

1. Hyper-V 與 VirtualBox 皆需獨占 VT-x，無法同時啟用，導致工具鏈衝突。
2. Docker Toolbox 依賴 Boot2Docker/VirtualBox，與 Windows 原生環境割裂。
3. 過去需 SSH 進 Linux VM 執行 Docker CLI，增加操作成本。

深層原因：

• 架構層面：倚賴第三方 Hypervisor（VirtualBox）與外置 VM，缺乏 OS 級整合。
• 技術層面：Boot2Docker 架構與 Windows 主機工具鏈（PowerShell、批次檔）整合弱。
• 流程層面：開發/測試流程需跨 VM、跨工具切換，摩擦高。

Solution Design（解決方案設計）

解決策略：改用 Docker for Windows（Beta），採 Hyper-V 管理的 MobyLinuxVM，提供原生 UI、整合 CLI/Compose，移除 VirtualBox 依賴，統一在 Windows 端操作 Docker，降低摩擦並提升可靠性。

實施步驟：

1. 安裝 Docker for Windows（Beta）
   • 實作細節：下載 MSI，依精靈完成安裝；首啟動自動檢查 Hyper-V。
   • 所需資源：Docker for Windows（Beta）安裝檔。
   • 預估時間：10-20 分鐘
2. 確認/啟用 Hyper-V
   • 實作細節：若未啟用，Docker 會提示「Install & Restart」自動安裝並重開。
   • 所需資源：Windows 功能啟用、系統重啟。
   • 預估時間：10 分鐘

關鍵程式碼/設定：

# 啟用 Hyper-V（替代圖形化步驟）
dism /Online /Enable-Feature /All /FeatureName:Microsoft-Hyper-V

# 驗證 Docker CLI 可用
docker version
docker run --rm hello-world

實際案例：作者由 Docker Toolbox（VirtualBox）轉向 Docker for Windows（Hyper-V），不再手工替換 Hypervisor，CLI 可直接在 Windows 端使用。 實作環境：Windows 10 Enterprise 10586，Docker for Windows（Beta），Hyper-V 後端 MobyLinuxVM。 實測數據：

• 改善前：VirtualBox 與 Hyper-V 衝突；需 SSH 進 VM 操作；整合性差。
• 改善後：以 Hyper-V 為後端，Docker CLI 直用於 Windows；原生 UI；自動更新。
• 改善幅度：安裝/操作步驟減少，整合度與穩定性顯著提升（定性）。

Learning Points（學習要點） 核心知識點：

• Hypervisor 排他性與工具鏈衝突來源
• Docker for Windows 原生整合優勢
• 在 Windows 直用 Docker CLI 的工作流

技能要求：

• 必備技能：Windows 功能管理、基本 Docker CLI
• 進階技能：Hyper-V 管理、CLI 自動化

延伸思考：

• 在 CI 開發機上如何規模化部署 Docker for Windows？
• Hyper-V 政策/群組原則對開發機的影響？
• 如何從 Toolbox 平滑遷移現有腳本與設定？

Practice Exercise（練習題）

• 基礎練習：安裝 Docker for Windows 並執行 hello-world。
• 進階練習：以 PowerShell 撰寫腳本自動檢查 Hyper-V 並啟動 Docker。
• 專案練習：將既有 Docker Toolbox 專案改造為 Docker for Windows 本機開發流程（含 Compose）。

Assessment Criteria（評估標準）

• 功能完整性（40%）：能安裝、啟用 Hyper-V、執行容器
• 程式碼品質（30%）：自動化腳本健壯性/可讀性
• 效能優化（20%）：啟動速度、步驟最少化
• 創新性（10%）：整合 Windows 工具鏈的改良程度

Case #2: 在 VM 內測 Docker for Windows 的「Nested Hyper-V」建置

Problem Statement（問題陳述）

業務場景：不希望在工作主機直接裝 Beta 版工具，欲在 Hyper-V VM 內進行 Docker for Windows 測試，避免風險影響生產環境。 技術挑戰：在 VM 裡再跑 Hyper-V（Nested Virtualization）、在第二層啟動 MobyLinuxVM。 影響範圍：若未正確設定，內層 Hyper-V/VM 無法啟動，Docker for Windows 無法使用。 複雜度評級：高

Root Cause Analysis（根因分析）

直接原因：

1. 預設 VM 不會暴露 VT-x 給內層客體。
2. 使用動態記憶體、VBS/Device Guard 會阻斷虛擬化擴充。
3. 未啟用 MAC Spoofing 導致內層 VM 網路失效。

深層原因：

• 架構層面：Nested Virtualization 尚處預覽（文中時點），設計限制多。
• 技術層面：內外兩層 Hyper-V 版本/設定需對齊。
• 流程層面：缺少 GUI，需以 PowerShell 配置，易遺漏。

Solution Design（解決方案設計）

解決策略：依 Microsoft 官方指引，在外層主機啟用內層 VT-x 暴露、停用動態記憶體、開啟 MAC Spoofing，並確保 OS/Hyper-V 版本符合最低需求。

實施步驟：

1. 建立外層 VM（WIN10）並安裝 Windows 10 Pro/Enterprise 10586+
   • 實作細節：建立 Generation 2 VM、至少 4GB RAM、停用動態記憶體。
   • 所需資源：Hyper-V 主機、Windows 安裝媒體。
   • 預估時間：30-60 分鐘
2. 啟用 Nested Virtualization 與網路必要設定
   • 實作細節：PowerShell 設定 VT-x 暴露與 MAC Spoofing。
   • 所需資源：系統管理權限。
   • 預估時間：10 分鐘

關鍵程式碼/設定：

# 在外層主機（CHICKEN-PC）設定內層 VM（WIN10）
Set-VMProcessor -VMName "WIN10" -ExposeVirtualizationExtensions $true
Set-VMMemory -VMName "WIN10" -DynamicMemoryEnabled $false -StartupBytes 4GB
Set-VMNetworkAdapter -VMName "WIN10" -MacAddressSpoofing On

# 確認 Hyper-V 版本（內外層需為新版）
Get-ComputerInfo | Select-Object OsName, OsVersion

實際案例：作者在外層 CHICKEN-PC 上建 WIN10 VM，套用上述設定後於內層安裝 Docker for Windows，成功啟動 MobyLinuxVM。 實作環境：Host/Guest 皆為 Windows 10 Enterprise 10586，Hyper-V。 實測數據：

• 改善前：MobyLinuxVM 無法啟動（Nested 未啟）。
• 改善後：MobyLinuxVM 正常啟動，Docker for Windows 可用。
• 改善幅度：可行性從 0% → 100%（定性）。

Learning Points（學習要點） 核心知識點：

• Nested Virtualization 限制與必要條件
• VT-x 暴露、動態記憶體關閉、MAC Spoofing 要點
• 風險隔離的實驗環境設計

技能要求：

• 必備技能：Hyper-V 管理、PowerShell
• 進階技能：虛擬化網路、資源規劃

延伸思考：

• 如何在企業 IT 政策（VBS/Device Guard）下規避限制？
• 何種情況適合以 Nested 方式試驗？何時該改用實體機？

Practice Exercise（練習題）

• 基礎練習：對既有 VM 啟用 VT-x 暴露與 MAC Spoofing。
• 進階練習：自動化腳本建立可跑 Docker for Windows 的內層 VM。
• 專案練習：打造「安全試驗沙箱」，提供團隊試用 Beta 工具。

Assessment Criteria（評估標準）

• 功能完整性（40%）：內層 Hyper-V/VM 可正常建立與啟動
• 程式碼品質（30%）：自動化腳本與錯誤處理
• 效能優化（20%）：資源配置合理（RAM/CPU）
• 創新性（10%）：沙箱隔離策略與共享方式

Case #3: 修復 MobyLinuxVM 啟動失敗（Nested 未正確設定）

Problem Statement（問題陳述）

業務場景：在內層 WIN10 VM 安裝 Docker for Windows，首次啟動提示 MobyLinuxVM 無法啟動，或在 Hyper-V 管理員手動啟動也失敗。 技術挑戰：判斷是內層設定錯誤或外層 Nested 未完成；建立最小重現。 影響範圍：Docker for Windows 無法使用；無法進入後續容器開發。 複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

1. 外層未暴露 VT-x；內層 Hyper-V 無法再建 VM。
2. 內層 VM 啟用動態記憶體；啟動失敗。
3. 外層 VBS/Device Guard 啟用阻斷虛擬化擴充。

深層原因：

• 架構層面：兩層 Hyper-V 設定耦合，任一處理錯皆導致失敗。
• 技術層面：Nested 限制（Save/Restore、Live Migration、Checkpoint）的誤用。
• 流程層面：缺少驗證手段，難以快速定位故障點。

Solution Design（解決方案設計）

解決策略：先在內層手動建立第二台測試 VM 驗證，再逐一比對 Nested 配置（VT-x、動態記憶體、MAC Spoofing、VBS），修正後重試 Docker for Windows。

實施步驟：

1. 內層建立測試 VM 以驗證 Nested 可行
   • 實作細節：若測試 VM 啟動失敗，即為 Nested 設定未就緒。
   • 所需資源：Hyper-V Manager 或 PowerShell。
   • 預估時間：10-15 分鐘
2. 修正外層設定並重啟內層
   • 實作細節：檢查 VT-x 暴露、關閉動態記憶體、關閉 VBS、開啟 MAC Spoofing。
   • 所需資源：PowerShell、系統管理權限。
   • 預估時間：15-30 分鐘

關鍵程式碼/設定：

# 內層建立測試 VM（驗證 Nested）
New-VM -Name "NestedProbe" -Generation 2 -MemoryStartupBytes 1024MB
Start-VM -Name "NestedProbe"

# 若啟動失敗，回外層修正
Set-VMProcessor -VMName "WIN10" -ExposeVirtualizationExtensions $true
Set-VMMemory -VMName "WIN10" -DynamicMemoryEnabled $false
Set-VMNetworkAdapter -VMName "WIN10" -MacAddressSpoofing On

實際案例：作者於內層手動啟動第二台 VM，定位為 Nested 問題而非 Docker 安裝問題，回到外層修設定後即恢復。 實作環境：同上。 實測數據：

• 改善前：MobyLinuxVM/測試 VM 皆啟動失敗。
• 改善後：測試 VM 與 MobyLinuxVM 皆可啟動。
• 改善幅度：啟動成功率由 0%→100%（定性）。

Learning Points（學習要點） 核心知識點：

• 以「最小可重現」驗證定位 Nested 問題
• 外層與內層設定對應關係
• 常見限制（動態記憶體、VBS、Checkpoint）

技能要求：

• 必備技能：Hyper-V 操作、故障診斷
• 進階技能：系統化驗證流程設計

延伸思考：

• 可否以健康檢查腳本自動檢測 Nested 檢查清單？
• 如何在 CI/CD 試驗機器大規模套用修正？

Practice Exercise（練習題）

• 基礎練習：建立 NestedProbe VM 驗證；觀察失敗訊息。
• 進階練習：撰寫 PowerShell 健康檢查腳本，逐項回報 Nested 檢測結果。
• 專案練習：將健康檢查整合到 IT 設備交付流程。

Assessment Criteria（評估標準）

• 功能完整性（40%）：可可靠定位與修復啟動失敗
• 程式碼品質（30%）：檢測腳本涵蓋度
• 效能優化（20%）：診斷時間縮短
• 創新性（10%）：診斷流程自動化程度

Case #4: 確認 OS 與版本門檻（Host/Guest 條件）

Problem Statement（問題陳述）

業務場景：團隊機器規格不一，部分為 Windows 10 Home，部分為舊版 Build，導致 Hyper-V 或 Docker for Windows 不支援。 技術挑戰：釐清 Host 需要 Nested（10565+）、Guest 需要 Docker for Windows（10586+）、Home 版淘汰。 影響範圍：安裝/啟動失敗、排查時間浪費。 複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

1. Windows 10 Home 不含 Hyper-V。
2. Nested 要求 Host 為 10565+；Docker for Windows 要求 Guest 為 10586+。
3. 舊版 Hyper-V 不支援 Nested。

深層原因：

• 架構層面：功能依賴 OS 版本能力。
• 技術層面：Hyper-V 與 Docker for Windows 各自有最低門檻。
• 流程層面：未先做版本盤點與核查。

Solution Design（解決方案設計）

解決策略：導入「版本核對清單」，安裝前以腳本驗證 OS SKU、Build、Hyper-V 可用性，杜絕不合格安裝。

實施步驟：

1. 盤點 Host/Guest OS 版本與 SKU
   • 實作細節：用 systeminfo/PowerShell 取回版本資訊。
   • 所需資源：管理者權限。
   • 預估時間：10 分鐘
2. 制定升級/替換策略（Home→Pro/Ent、Build 升級）
   • 實作細節：WSUS/SCCM 或手動升級。
   • 所需資源：安裝媒體、升級維護窗。
   • 預估時間：依環境而定

關鍵程式碼/設定：

# 查詢 OS SKU 與版本
Get-ComputerInfo | Select-Object OsName, OsVersion, WindowsProductName, WindowsEditionId

# 檢查 Hyper-V 可用性
Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All

實際案例：作者 Host/Guest 皆使用 Windows 10 Enterprise 10586，驗證可行。 實作環境：Windows 10 Ent 10586。 實測數據：

• 改善前：嘗試在 Home/舊 Build 安裝，無法啟動。
• 改善後：確認版本門檻後一次成功。
• 改善幅度：避免無效嘗試（定性）。

Learning Points（學習要點） 核心知識點：

• Docker for Windows 與 Nested 的版本門檻
• OS SKU 差異（Home vs Pro/Ent）
• 安裝前核對的重要性

技能要求：

• 必備技能：Windows 設備盤點
• 進階技能：企業版升級/維運流程

延伸思考：

• 建置標準化開發鏡像（符合門檻的 VHDX 範本）
• 以腳本自動阻擋不合規安裝流程

Practice Exercise（練習題）

• 基礎練習：撰寫檢查腳本並回報是否符合門檻。
• 進階練習：腳本提出具體修正建議（升級路徑）。
• 專案練習：整合到 IT 開發機交付流程。

Assessment Criteria（評估標準）

• 功能完整性（40%）：準確偵測與回報
• 程式碼品質（30%）：可維護、可擴充
• 效能優化（20%）：盤點效率
• 創新性（10%）：與資產管理系統整合

Case #5: 內層啟用 Hyper-V 功能以支援 Docker for Windows

Problem Statement（問題陳述）

業務場景：在內層 WIN10 VM 安裝 Docker for Windows 首次啟動彈出「需安裝 Hyper-V」提示，需自動完成安裝與重開機。 技術挑戰：快速啟用 Hyper-V，確保安裝流程不中斷。 影響範圍：安裝體驗、時間成本。 複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

1. 內層 Windows 尚未啟用 Hyper-V 功能。
2. Docker for Windows 後端依賴 Hyper-V 啟動 MobyLinuxVM。

深層原因：

• 架構層面：Docker for Windows 與 Hyper-V 強耦合。
• 技術層面：Windows 功能預設未開啟 Hyper-V。
• 流程層面：缺少安裝前檢查與自動化。

Solution Design（解決方案設計）

解決策略：透過 Docker 內建提示快速安裝，或以 DISM/PowerShell 預先啟用 Hyper-V，減少重啟與中斷。

實施步驟：

1. 依 Docker 提示安裝 Hyper-V
   • 實作細節：按「Install & Restart」完成安裝。
   • 所需資源：系統管理權限、重啟。
   • 預估時間：10 分鐘
2. 以命令行預先啟用
   • 實作細節：DISM 或 PowerShell 啟用並安排重啟。
   • 所需資源：系統管理權限。
   • 預估時間：5-10 分鐘

關鍵程式碼/設定：

# 以 DISM 啟用 Hyper-V
dism /Online /Enable-Feature /All /FeatureName:Microsoft-Hyper-V

# PowerShell 等效指令
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All -NoRestart
Restart-Computer

實際案例：作者選擇按提示自動安裝與重啟，之後順利輸入 Beta Token 並啟動。 實作環境：WIN10 VM（Ent 10586）。 實測數據：

• 改善前：Docker for Windows 無法建立後端 VM。
• 改善後：Hyper-V 啟用後可建立 MobyLinuxVM。
• 改善幅度：阻斷點排除（定性）。

Learning Points（學習要點） 核心知識點：

• Docker for Windows 與 Hyper-V 依賴關係
• DISM/PowerShell 啟用系統功能

技能要求：

• 必備技能：系統管理、命令列
• 進階技能：安裝腳本自動化

延伸思考：

• 如何在企業映像預先啟用 Hyper-V？
• 非管理員情境下的流程設計？

Practice Exercise（練習題）

• 基礎練習：用 DISM 啟用 Hyper-V 並重啟。
• 進階練習：撰寫一鍵安裝 Docker for Windows 的批次檔。
• 專案練習：將啟用 Hyper-V 納入企業 IT 開發機建置腳本。

Assessment Criteria（評估標準）

• 功能完整性（40%）：Hyper-V 可用、Docker 可啟動
• 程式碼品質（30%）：腳本穩定、參數化
• 效能優化（20%）：安裝步驟最少化
• 創新性（10%）：自動檢查與回復機制

Case #6: Nested 環境資源規劃（關閉動態記憶體、至少 4GB RAM）

Problem Statement（問題陳述）

業務場景：在 VM 內跑 Docker for Windows，若資源不足或啟用動態記憶體，可能導致內層 VM 啟動不穩或效能差。 技術挑戰：確保內層 VM/MobyLinuxVM 可用且穩定。 影響範圍：容器啟動失敗、開發體驗差。 複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

1. Nested 受限，動態記憶體必須關閉。
2. 低於 4GB RAM 場景「緊繃」，容易不穩。
3. CPU/記憶體配置不當。

深層原因：

• 架構層面：VM in VM 資源疊加損耗。
• 技術層面：Nested 模式功能限制多（Runtime resize 失敗等）。
• 流程層面：未在安裝前規劃資源。

Solution Design（解決方案設計）

解決策略：以腳本固定關閉動態記憶體，配置至少 4GB RAM，必要時增加 CPU；使用 Docker Settings 管理內層 Linux VM 資源。

實施步驟：

1. 固定內層 VM 記憶體
   • 實作細節：關閉動態記憶體，設定固定 4GB 以上。
   • 所需資源：Hyper-V/PowerShell。
   • 預估時間：5 分鐘
2. 調整 Docker Settings 資源
   • 實作細節：以 Docker UI 調整 CPU/RAM。
   • 所需資源：Docker Desktop 設定。
   • 預估時間：5 分鐘

關鍵程式碼/設定：

# 外層為 WIN10 VM 配置固定記憶體
Set-VMMemory -VMName "WIN10" -DynamicMemoryEnabled $false -StartupBytes 4GB

# 內層 Docker Settings -> Resources：調整 CPU/Memory（圖形界面）

實際案例：作者配置 4GB RAM 後，MobyLinuxVM 啟動穩定。 實作環境：同上。 實測數據：

• 改善前：VM in VM 僅有 4GB 主記憶體時「緊繃」。
• 改善後：配置 4GB+ 並關閉動態記憶體後可穩定啟動。
• 改善幅度：穩定性顯著提升（定性）。

Learning Points（學習要點） 核心知識點：

• Nested 資源疊加效應
• 動態記憶體與 Nested 不相容
• Docker Settings 與 Hyper-V 的關聯

技能要求：

• 必備技能：資源規劃、Hyper-V 操作
• 進階技能：效能觀測與調優

延伸思考：

• 如何在多開 VM 的情況下做資源隔離與保證？
• 以 PerfMon/Container 指標做容量規劃？

Practice Exercise（練習題）

• 基礎練習：關閉動態記憶體、配置 4GB。
• 進階練習：壓測容器啟動，調整資源找最佳點。
• 專案練習：建立「資源基線」文檔與自動檢查腳本。

Assessment Criteria（評估標準）

• 功能完整性（40%）：穩定啟動並可連續部署容器
• 程式碼品質（30%）：資源腳本可靠
• 效能優化（20%）：在有限資源下達到最佳穩定性
• 創新性（10%）：監控與自動化調優

Case #7: 用 Docker Settings 統一管理後端 VM 資源與設定

Problem Statement（問題陳述）

業務場景：開發者不熟 Hyper-V 細節，需簡化後端 VM（MobyLinuxVM）的資源調整與共享磁碟設定。 技術挑戰：降低進入門檻、避免直接操作 Hyper-V。 影響範圍：配置錯誤風險、管理成本。 複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

1. 手動調 Hyper-V 易誤設；缺少統一界面。
2. Shared Drives、CPU/RAM 等需常態調整。

深層原因：

• 架構層面：Docker 將 Hyper-V 細節抽象化。
• 技術層面：以 UI 轉換底層 Hyper-V 操作。
• 流程層面：圖形化配置更利於團隊推廣。

Solution Design（解決方案設計）

解決策略：集中使用 Docker Settings 進行資源與共享設定，避免手動進 Hyper-V 管理員，降低出錯機率。

實施步驟：

1. 在 Docker Settings 調整 Resources
   • 實作細節：CPU/Memory/Swap 等。
   • 所需資源：Docker 介面。
   • 預估時間：5 分鐘
2. 設定 Shared Drives
   • 實作細節：勾選要共享的磁碟（如 C、D）。
   • 所需資源：Docker 介面、Windows 憑證。
   • 預估時間：5 分鐘

關鍵程式碼/設定：

Docker Desktop -> Settings -> Resources：調整 CPU/Memory
Docker Desktop -> Settings -> Shared Drives：勾選 C:\ 或 D:\

實際案例：作者透過 Settings 完成 VM 規格與共享設定，不需直接進 Hyper-V。 實作環境：同上。 實測數據：

• 改善前：需手動改 Hyper-V；步驟多。
• 改善後：用 Docker Settings 一處管理。
• 改善幅度：管理便利性與正確性提升（定性）。

Learning Points（學習要點） 核心知識點：

• Docker Settings 與 Hyper-V 設定映射
• Shared Drives 的作用
• 管理界面與底層的關聯

技能要求：

• 必備技能：Docker Desktop 操作
• 進階技能：設定治理與基準化

延伸思考：

• 如何將 Settings 變更納管（政策、審計）？
• 多人共用開發機的設定規範？

Practice Exercise（練習題）

• 基礎練習：調整 CPU/Memory，觀察容器啟動時間差異。
• 進階練習：切換 Shared Drives，測試掛載可見性。
• 專案練習：制定團隊 Settings 建議值與操作手冊。

Assessment Criteria（評估標準）

• 功能完整性（40%）：資源與共享設定正確生效
• 程式碼品質（30%）：（無代碼）以流程與紀錄評估
• 效能優化（20%）：設定對效能的正向影響
• 創新性（10%）：設定標準化與文件化程度

Case #8: 以 hello-world 快速驗證完整鏈路

Problem Statement（問題陳述）

業務場景：Nested + Docker for Windows + MobyLinuxVM 多層結構，需有最簡單的驗證手段確認整體可用。 技術挑戰：快速、無依賴地驗證網路、映像抓取、容器執行。 影響範圍：安裝成敗判定、後續教學/演練開場。 複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

1. 多層組件任一失效皆導致 Docker 指令不可用。
2. 需要最小化依賴的驗證容器。

深層原因：

• 架構層面：多層抽象疊加。
• 技術層面：鏡像拉取與容器執行路徑需一次打通。
• 流程層面：驗證步驟最好標準化。

Solution Design（解決方案設計）

解決策略：使用 hello-world 官方映像，一行指令完成從拉取到執行的全鏈路驗證，作為環境健康檢查基準。

實施步驟：

1. 執行 hello-world
   • 實作細節：PowerShell/CMD 直接執行 Docker CLI。
   • 所需資源：網路可達 Docker Hub。
   • 預估時間：1-2 分鐘

關鍵程式碼/設定：

docker run --rm hello-world

實際案例：作者成功看到 hello-world 輸出，確認整體架構可運作。 實作環境：同上。 實測數據：

• 改善前：不可確定是哪一層出錯。
• 改善後：hello-world 正常輸出，證明全鏈路暢通。
• 改善幅度：診斷時間縮短（定性）。

Learning Points（學習要點） 核心知識點：

• 最小可行驗證（sanity check）
• Docker 拉取/執行基本流程
• 故障時的分層排查思路

技能要求：

• 必備技能：Docker CLI
• 進階技能：快速故障定位

延伸思考：

• 建立團隊標準「環境驗證清單」？
• 以 CI 任務自動做環境自檢？

Practice Exercise（練習題）

• 基礎練習：執行 hello-world 並截圖保存。
• 進階練習：以腳本偵測並報告失敗層級（DNS/影像/執行）。
• 專案練習：將驗證腳本整合到開發機開機工作。

Assessment Criteria（評估標準）

• 功能完整性（40%）：hello-world 輸出正確
• 程式碼品質（30%）：自動化檢測腳本健壯
• 效能優化（20%）：驗證耗時短
• 創新性（10%）：報表/告警整合

Case #9: 啟用 Shared Drives，將 Windows 資料夾掛載到容器

Problem Statement（問題陳述）

業務場景：需要讓容器直接讀寫本機 Windows 檔案以加速開發（程式碼同步、輸出入資料）。 技術挑戰：跨 OS 檔案系統共享，過去需手動配置 SMB/CIFS，流程繁瑣。 影響範圍：開發效率、錯誤率、資料一致性。 複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

1. 過去需自行搭 SMB 或 CIFS 掛載，步驟多且易錯。
2. 未啟用 Shared Drives 時，-v 綁定不會映射到主機。

深層原因：

• 架構層面：Windows 與 Linux 檔案系統共享需橋接。
• 技術層面：Docker for Windows 透過 Volume Driver + SMB 實現。
• 流程層面：缺少標準化手續導致失敗率高。

Solution Design（解決方案設計）

解決策略：使用 Docker Settings 的 Shared Drives 勾選要共享的磁碟（如 C:\、D:\），再以 -v 將 Windows 路徑綁定到容器目錄，達成雙向可見。

實施步驟：

1. 勾選 Shared Drives
   • 實作細節：Settings → Shared Drives 勾選磁碟，輸入 Windows 憑證。
   • 所需資源：Docker Desktop、有效帳密。
   • 預估時間：3 分鐘
2. 以 -v 執行容器並測試雙向可見
   • 實作細節：在 Windows 建立檔案，容器中讀取；容器中寫入，Windows 可見。
   • 所需資源：alpine 等輕量映像。
   • 預估時間：5-10 分鐘

關鍵程式碼/設定：

# 本機路徑與容器路徑的綁定（請確保已啟用 C:\ 共享）
docker run -it --rm -v C:\Users\chicken\Docker\alpine-data:/data alpine /bin/ash

# 在容器內讀/寫測試
ls -l /data
cp /proc/version /data/alpine-version.txt

實際案例：作者在 C:\Users\chicken\Docker\apline-data 放置 readme.txt，啟用 C:\ 共享後，容器內可看到檔案，並能把 /proc/version 複製到 /data，在 Windows 檔案總管可見。 實作環境：同上。 實測數據：

• 改善前：需自行搭 SMB/CIFS，或根本無法映射。
• 改善後：Settings 一鍵共享，-v 可直用。
• 改善幅度：共享配置時間大幅縮短（定性）。

Learning Points（學習要點） 核心知識點：

• Docker for Windows 的 Shared Drives 與 -v 綁定
• 跨 OS 檔案系統共享機制
• 雙向可見性測試方法

技能要求：

• 必備技能：Docker CLI、路徑處理
• 進階技能：共享機制安全性與疑難排解

延伸思考：

• 如何在公司網域帳號/密碼策略下管理 Shared Drives？
• 大量小檔 I/O 與效能考量？

Practice Exercise（練習題）

• 基礎練習：建立資料夾、啟用共享、用容器讀寫檔案。
• 進階練習：以 Compose 定義多個服務共享。
• 專案練習：搭建可即時同步程式碼的開發容器模板。

Assessment Criteria（評估標準）

• 功能完整性（40%）：雙向可見、持久化成功
• 程式碼品質（30%）：Compose/CLI 可重用
• 效能優化（20%）：I/O 行為合理
• 創新性（10%）：對共享策略與安全的設計

Case #10: 診斷未勾選 Shared Drives 時「看得到掛載、看不到檔案」

Problem Statement（問題陳述）

業務場景：以 -v 指定 Windows 路徑掛載到容器，但容器看不到主機的檔案，且容器寫入的檔案主機看不到。 技術挑戰：辨識掛載成功訊息與實際綁定位置的差異；釐清 Docker 後端回退行為。 影響範圍：資料一致性、測試誤判。 複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

1. 未啟用 Shared Drives，-v 不會映射到主機實體路徑。
2. Docker 可能在後端替容器準備了匿名 Volume（仍可持久但不在主機路徑）。

深層原因：

• 架構層面：安全與權限考量下的回退策略。
• 技術層面：匿名 Volume 與 Bind Mount 差異。
• 流程層面：未先啟用共享即進行掛載操作。

Solution Design（解決方案設計）

解決策略：先啟用 Shared Drives，再執行 -v 綁定；若已產生匿名 Volume，列出並清理或重新指向正確的 Bind Mount。

實施步驟：

1. 啟用 Shared Drives 並重跑容器
   • 實作細節：Settings 勾選磁碟後再執行 -v。
   • 所需資源：Docker Desktop。
   • 預估時間：3 分鐘
2. 檢查/清理匿名 Volume（可選）
   • 實作細節：列出 volume，視需要 prune。
   • 所需資源：Docker CLI。
   • 預估時間：5 分鐘

關鍵程式碼/設定：

# 啟用 Shared Drives 後再執行（Windows -> 容器）
docker run -it --rm -v C:\Users\chicken\Docker\alpine-data:/data alpine /bin/ash

# 觀察可能殘留的匿名 volume
docker volume ls
# 視需要清理（小心使用）
docker volume prune -f

實際案例：作者在未共享時容器看不到 readme.txt，且在容器內寫入主機看不到；啟用 C:\ 共享後即可雙向可見。 實作環境：同上。 實測數據：

• 改善前：資料不可見；誤以為已綁定。
• 改善後：共享後雙向可見；持久化到主機路徑。
• 改善幅度：資料一致性問題消失（定性）。

Learning Points（學習要點） 核心知識點：

• 匿名 Volume vs Bind Mount
• Shared Drives 啟用前後行為差異
• Volume 清理風險

技能要求：

• 必備技能：Docker Volume 基礎
• 進階技能：資料持久化設計、清理策略

延伸思考：

• 何時該用 Named Volume？何時該用 Bind Mount？
• 匿名 Volume 遺留的資安/合規風險？

Practice Exercise（練習題）

• 基礎練習：復現未共享導致的「看不到檔案」案例。
• 進階練習：列出/清理匿名 Volume，改為正確綁定。
• 專案練習：設計一套資料卷管理指引與腳本。

Assessment Criteria（評估標準）

• 功能完整性（40%）：成功復現與修復
• 程式碼品質（30%）：Volume 管理腳本
• 效能優化（20%）：避免多餘 Volume 佔用
• 創新性（10%）：資料管理策略完善度

Case #11: 了解 Shared Drives 背後其實是 Windows SMB 共用

Problem Statement（問題陳述）

業務場景：啟用 Shared Drives 後，Windows 出現 C、D 的分享，團隊需理解其安全影響與故障排查方法。 技術挑戰：辨識 Docker for Windows 如何橋接檔案系統；以系統工具驗證設定。 影響範圍：安全、權限、網路可見性。 複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

1. Docker for Windows 透過 SMB 共享磁碟給後端 Linux VM。
2. 共用設定錯誤可能導致權限或可用性問題。

深層原因：

• 構面：跨 OS 檔案共享以 SMB 為橋。
• 技術面：Windows 帳密與網路共用管理。
• 流程面：缺乏安全基準與盤點。

Solution Design（解決方案設計）

解決策略：以 net share/電腦管理檢視 SMB 分享，設定必要的最小權限，限制網路可見性，並納入安全審視。

實施步驟：

1. 檢視/驗證 SMB 共用
   • 實作細節：列出共用、檢視權限。
   • 所需資源：Windows 內建工具。
   • 預估時間：5 分鐘
2. 安全性評估
   • 實作細節：最小權限、僅本機可見、防火牆規則。
   • 所需資源：IT 安全政策。
   • 預估時間：30 分鐘

關鍵程式碼/設定：

REM 列出 Windows 目前的共用
net share

REM 使用「電腦管理」-> 系統工具 -> 共享資料夾 -> 共用 進一步檢視/調整

實際案例：作者觀察啟用 C、D 共享後，Windows 多了 C 與 D 的 share，驗證 Docker for Windows 的實作方式。 實作環境：同上。 實測數據：

• 改善前：對共享實作不透明。
• 改善後：可檢視與管控 SMB 共用。
• 改善幅度：可觀測性、安全掌控度提升（定性）。

Learning Points（學習要點） 核心知識點：

• Shared Drives 實作原理（SMB）
• 權限與可見性管理
• 故障排查（共用失效/憑證錯誤）

技能要求：

• 必備技能：Windows 共享管理
• 進階技能：企業網路安全政策套用

延伸思考：

• 如何在網域環境控管這些共用？
• 是否需隔離 Docker 後端 VM 的網路？

Practice Exercise（練習題）

• 基礎練習：觀察/列出共用，調整權限。
• 進階練習：模擬憑證錯誤並修復。
• 專案練習：撰寫安全硬化指引（含防火牆/權限基準）。

Assessment Criteria（評估標準）

• 功能完整性（40%）：能正確檢視/調整共用
• 程式碼品質（30%）：（無代碼）以流程與紀錄評估
• 效能優化（20%）：共用對 I/O 的影響考量
• 創新性（10%）：安全強化策略

Case #12: 在 Windows 端直接操作 Docker CLI，免 SSH

Problem Statement（問題陳述）

業務場景：需將 Docker 操作納入 Windows 批次/PowerShell 腳本，過去需 SSH 進 Linux VM 操作，流程冗長。 技術挑戰：以 Windows CLI 直接驅動容器生命週期。 影響範圍：自動化、整合效率。 複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

1. Docker Toolbox 模式下 CLI 與主機分離。
2. 缺乏直接在 Windows 端操作容器的能力。

深層原因：

• 架構層面：Docker for Windows 提供原生 CLI/Compose。
• 技術層面：後端由 Docker 服務管理 MobyLinuxVM，對使用者透明。
• 流程層面：自動化步驟可收斂。

Solution Design（解決方案設計）

解決策略：使用 Windows PowerShell/CMD 直接執行 Docker 指令，與現有 Windows 腳本整合，簡化自動化與 CI 任務。

實施步驟：

1. 使用 PowerShell 執行 docker run
   • 實作細節：無需 SSH。
   • 所需資源：Docker 安裝完成。
   • 預估時間：5 分鐘
2. 與批次/CI 整合
   • 實作細節：撰寫批次檔或 PowerShell 模組。
   • 所需資源：CI 系統。
   • 預估時間：30-60 分鐘

關鍵程式碼/設定：

# 以 PowerShell 啟動容器並查看輸出
docker run --rm hello-world

# 範例：以 PowerShell 啟動交互式容器
docker run -it --rm alpine /bin/ash

實際案例：作者直接在 Windows 命令提示字元執行 docker run，免 SSH。 實作環境：同上。 實測數據：

• 改善前：需 SSH 進 VM。
• 改善後：Windows 端直控 Docker。
• 改善幅度：自動化整合性提升（定性）。

Learning Points（學習要點） 核心知識點：

• Docker CLI 在 Windows 的使用
• 與 PowerShell/批次整合
• 自動化與可移植性

技能要求：

• 必備技能：Docker CLI、PowerShell
• 進階技能：CI 整合

延伸思考：

• 如何處理 Windows 路徑與容器路徑差異？
• 在 CI 上的憑證與安全管理？

Practice Exercise（練習題）

• 基礎練習：以 PowerShell 啟動與清除容器。
• 進階練習：寫一個多步驟 PowerShell 部署腳本。
• 專案練習：將容器操作整合入既有 CI pipeline。

Assessment Criteria（評估標準）

• 功能完整性（40%）：可完成容器全生命週期
• 程式碼品質（30%）：腳本結構清晰
• 效能優化（20%）：步驟精簡
• 創新性（10%）：與 Windows 工具鏈融合度

Case #13: 用 VM 沙箱降低 Beta 工具風險

Problem Statement（問題陳述）

業務場景：需在不干擾工作機的前提下評估 Beta 工具（Docker for Windows Beta）。 技術挑戰：在 VM 內進行完整試驗並還原。 影響範圍：主機穩定性、IT 政策遵循。 複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

1. Beta 工具可能影響基礎架構（Hyper-V/網路/共享）。
2. 需要可還原、可丟棄的安全場域。

深層原因：

• 架構層面：沙箱化可隔離風險。
• 技術層面：Nested 提供可行途徑。
• 流程層面：試驗與生產分離。

Solution Design（解決方案設計）

解決策略：以 Hyper-V VM 建立沙箱，啟用 Nested，於沙箱內安裝與評估 Docker for Windows，驗證完畢後可直接丟棄或重置 VM。

實施步驟：

1. 建立與配置沙箱 VM（見 Case #2）
   • 實作細節：固定資源、啟用 Nested。
   • 所需資源：Hyper-V。
   • 預估時間：60-90 分鐘
2. 在沙箱內安裝/測試/回報
   • 實作細節：執行 hello-world、Volume 挂載測試。
   • 所需資源：同上。
   • 預估時間：30-60 分鐘

關鍵程式碼/設定：

# 參照 Case #2 的 Nested 配置指令
Set-VMProcessor -VMName "WIN10" -ExposeVirtualizationExtensions $true
Set-VMMemory -VMName "WIN10" -DynamicMemoryEnabled $false -StartupBytes 4GB
Set-VMNetworkAdapter -VMName "WIN10" -MacAddressSpoofing On

實際案例：作者全部在 VM 裡演練 Docker for Windows，避免動到工作機。 實作環境：同上。 實測數據：

• 改善前：在工作機安裝 Beta 有風險。
• 改善後：沙箱可拋棄、可重置，風險隔離。
• 改善幅度：風險降到最低（定性）。

Learning Points（學習要點） 核心知識點：

• 風險隔離與沙箱設計
• 驗證流程標準化
• 回滾/拋棄策略

技能要求：

• 必備技能：Hyper-V、快照/映像管理
• 進階技能：測試計畫與回報

延伸思考：

• 如何將沙箱標準化為團隊可複用的模板？
• 何時應轉向實體機器做性能驗證？

Practice Exercise（練習題）

• 基礎練習：建立一個「可丟棄」的測試 VM。
• 進階練習：撰寫沙箱初始化腳本（安裝 Docker、執行驗證）。
• 專案練習：制定「新工具評估 SOP」。

Assessment Criteria（評估標準）

• 功能完整性（40%）：沙箱可用且可還原
• 程式碼品質（30%）：初始化腳本完善
• 效能優化（20%）：建立/還原效率
• 創新性（10%）：團隊化模板/流程

Case #14: 內層 VM 網路失效的關鍵設定：啟用 MAC Spoofing

Problem Statement（問題陳述）

業務場景：在 Nested 環境下，內層 VM（包含 MobyLinuxVM 或測試 VM）網路無法連線，容器也無法拉取映像。 技術挑戰：辨識 Nested 下必需的網路設定。 影響範圍：容器無法工作、整體驗證中斷。 複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

1. 未啟用 MAC Spoofing，內層 VM 網路封包被擋。
2. 虛擬交換器策略未允許 MAC 偽裝。

深層原因：

• 架構層面：Nested 下封包需允許內層轉發。
• 技術層面：Hyper-V 預設關閉 MAC Spoofing。
• 流程層面：網路設定未納入標準檢查清單。

Solution Design（解決方案設計）

解決策略：對承載內層 VM 的 vNIC 啟用 MAC Spoofing，確保內層來回封包可正確轉發。

實施步驟：

1. 啟用 MAC Spoofing
   • 實作細節：對內層宿主 VM 的網卡啟用。
   • 所需資源：PowerShell。
   • 預估時間：2 分鐘
2. 驗證網路連通
   • 實作細節：內層 VM Ping/拉取映像測試。
   • 所需資源：網路可達。
   • 預估時間：5 分鐘

關鍵程式碼/設定：

# 在外層主機對承載內層 Hyper-V 的 VM 啟用 MAC Spoofing
Set-VMNetworkAdapter -VMName "WIN10" -MacAddressSpoofing On

# 內層驗證
ping 8.8.8.8
docker pull hello-world

實際案例：文中列為官方限制與必要設定之一。 實作環境：同上。 實測數據：

• 改善前：內層網路不可用。
• 改善後：可拉取映像並啟動容器。
• 改善幅度：網路可用性恢復（定性）。

Learning Points（學習要點） 核心知識點：

• Nested 網路封包轉發機制
• Hyper-V MAC Spoofing 設定
• 網路連通性驗證

技能要求：

• 必備技能：Hyper-V 網路設定
• 進階技能：Nested 網路故障排查

延伸思考：

• 是否需要對虛擬交換器做額外隔離/ACL？
• 生產環境是否允許 MAC Spoofing？

Practice Exercise（練習題）

• 基礎練習：開關 MAC Spoofing 對比測試。
• 進階練習：腳本化啟用與驗證步驟。
• 專案練習：撰寫 Nested 網路問題 SOP。

Assessment Criteria（評估標準）

• 功能完整性（40%）：可拉取映像/網路可達
• 程式碼品質（30%）：腳本化與日誌
• 效能優化（20%）：故障定位效率
• 創新性（10%）：網路隔離與安全設計

Case #15: 關閉 Device Guard/VBS 以允許 Nested Virtualization

Problem Statement（問題陳述）

業務場景：企業設備啟用 Device Guard/Virtualization Based Security，導致無法將虛擬化擴充暴露給內層 VM。 技術挑戰：在遵從政策前提下停用/繞過限制以便試驗。 影響範圍：Nested 無法啟用、Docker for Windows 無法在內層運行。 複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

1. 啟用 VBS/Device Guard 後，Hyper-V 無法將 VT-x 暴露至客體。
2. 安全政策阻擋虛擬化擴充。

深層原因：

• 架構層面：VBS 與 Nested 互斥。
• 技術層面：安全功能鉤掛底層虛擬化擴充。
• 流程層面：IT 政策未納入開發需求例外。

Solution Design（解決方案設計）

解決策略：與 IT 協作，在測試機/沙箱關閉 VBS/Device Guard；生產機保留安全策略。

實施步驟：

1. 檢查目前 Device Guard/VBS 狀態
   • 實作細節：透過 PowerShell 查詢。
   • 所需資源：管理者權限。
   • 預估時間：5 分鐘
2. 依政策停用 VBS（僅限沙箱/測試機）
   • 實作細節：群組原則/BCD/登錄視情況調整，並重啟。
   • 所需資源：IT 協作。
   • 預估時間：依環境而定

關鍵程式碼/設定：

# 查詢 Device Guard/VBS 狀態
Get-CimInstance -ClassName Win32_DeviceGuard | Select-Object SecurityServicesConfigured, SecurityServicesRunning

（停用方式視企業政策與版本而定，需與 IT 協作）

實際案例：文中列為官方限制；需先停用 VBS 才能預覽 Nested。 實作環境：同上。 實測數據：

• 改善前：Nested 無法啟用。
• 改善後：可成功暴露 VT-x，內層 VM 正常。
• 改善幅度：可行性由 0%→100%（定性）。

Learning Points（學習要點） 核心知識點：

• VBS/Device Guard 與 Nested 的衝突
• 安全與研發需求的取捨
• 與 IT 協作流程

技能要求：

• 必備技能：系統查詢、溝通協作
• 進階技能：安全政策例外處理

延伸思考：

• 是否能以實體測試機替代停用 VBS？
• 以隔離網段/無網環境降低安全風險？

Practice Exercise（練習題）

• 基礎練習：查詢當前 VBS 狀態。
• 進階練習：提出停用方案並撰寫風險評估文件。
• 專案練習：制定「安全例外」申請與審核流程。

Assessment Criteria（評估標準）

• 功能完整性（40%）：Nested 成功啟用
• 程式碼品質（30%）：檢查腳本與文件化
• 效能優化（20%）：流程效率
• 創新性（10%）：風險控制與替代方案

Case #16: 避免 Nested 不相容操作：動態記憶體、Checkpoint、Save/Restore

Problem Statement（問題陳述）

業務場景：內層承載 VM 或容器時，操作動態記憶體/Checkpoint/Save/Restore 導致失敗或無法啟動。 技術挑戰：理解 Nested 限制並調整操作流程。 影響範圍：內層 VM/容器穩定性、可用性。 複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

1. Nested 下動態記憶體、Checkpoint、Save/Restore 不支援或會失敗。
2. Live Migration 等操作同樣不支援。

深層原因：

• 架構層面：Nested 的虛擬化能力受限。
• 技術層面：Hyper-V 功能在 Nested 場景下被禁用/降級。
• 流程層面：沿用既有 VM 操作習慣未調整。

Solution Design（解決方案設計）

解決策略：制定 Nested 作業準則：固定記憶體、不用 Checkpoint/Save/Restore/Live Migration；採用替代流程（冷關機/完整重新部署）。

實施步驟：

1. 設定 VM 固定記憶體（見 Case #6）
   • 實作細節：關閉動態記憶體。
   • 所需資源：PowerShell。
   • 預估時間：5 分鐘
2. 調整運維程序
   • 實作細節：以停止/啟動替代 Save/Restore、避免 Checkpoint。
   • 所需資源：SOP 文件。
   • 預估時間：30 分鐘

關鍵程式碼/設定：

# 關閉動態記憶體
Set-VMMemory -VMName "WIN10" -DynamicMemoryEnabled $false

# 禁用（或避免使用）Checkpoint 操作
Set-VM -Name "WIN10" -CheckpointType Disabled

實際案例：文中引用官方限制，提醒避免這些操作。 實作環境：同上。 實測數據：

• 改善前：套用不支援操作導致失敗。
• 改善後：遵循準則後運行穩定。
• 改善幅度：穩定性提升（定性）。

Learning Points（學習要點） 核心知識點：

• Nested 下的 Hyper-V 功能限制
• 替代操作流程設計
• SOP 制定與落地

技能要求：

• 必備技能：Hyper-V 管理
• 進階技能：流程治理

延伸思考：

• 如何以 IaC 讓「重建」取代「快照回復」？
• 以容器不可變基礎設施思維減輕 VM 操作需求？

Practice Exercise（練習題）

• 基礎練習：關閉動態記憶體、禁用 Checkpoint。
• 進階練習：撰寫 Nested 操作準則。
• 專案練習：將準則融入日常維運流程。

Assessment Criteria（評估標準）

• 功能完整性（40%）：避免不支援操作
• 程式碼品質（30%）：準則文件化
• 效能優化（20%）：作業成功率提升
• 創新性（10%）：以 IaC 取代快照依賴

Case #17: Windows 容器隔離模式：–isolation=process vs hyperv

Problem Statement（問題陳述）

業務場景：在 Windows 上需要更強隔離（例如多租戶、合規要求），僅有 process 隔離不足。 技術挑戰：選擇並啟用適合的隔離技術（Windows Containers vs Hyper-V Containers）。 影響範圍：安全、穩定性、資源開銷。 複雜度評級：高

Root Cause Analysis（根因分析）

直接原因：

1. Linux 主要以 namespaces（process 隔離）；Windows 支援 Hyper-V Container 提供 kernel 隔離。
2. 預設隔離模式可能不符合安全需求。

深層原因：

• 架構層面：不同隔離等級的設計與取捨。
• 技術層面：Docker on Windows 提供 –isolation 參數。
• 流程層面：場景導向的隔離選型未明確。

Solution Design（解決方案設計）

解決策略：在 Windows 主機運行 Windows 容器時，根據需求指定 –isolation=process 或 –isolation=hyperv；高隔離場景使用 hyperv。

實施步驟：

1. 以預設（或 process）隔離啟動
   • 實作細節：低開銷、較高密度。
   • 所需資源：Windows 容器基底鏡像（如 nanoserver）。
   • 預估時間：5 分鐘
2. 以 Hyper-V 隔離啟動
   • 實作細節：以 –isolation=hyperv 啟動更強隔離的容器。
   • 所需資源：支援 Hyper-V 的 Windows 主機。
   • 預估時間：5 分鐘

關鍵程式碼/設定：

# 顯示 run 指令說明，確認 --isolation 參數存在
docker run --help

# 啟動 Windows 容器（以 Hyper-V 隔離）
docker run -it --isolation=hyperv mcr.microsoft.com/windows/nanoserver cmd

# Linux 上等效為 default（--isolation default）

實際案例：文中引用官方文件與 CLI 幫助的截圖，展示 –isolation 參數，並給出 nanoserver 範例。 實作環境：Windows 主機、Windows 容器。 實測數據：

• 改善前：僅 process 隔離，安全隔離不足。
• 改善後：可選 hyperv 隔離，提升安全與隔離等級。
• 改善幅度：隔離強度提升（定性）。

Learning Points（學習要點） 核心知識點：

• Windows 容器隔離模式差異
• –isolation 參數使用
• 隔離與資源開銷的取捨

技能要求：

• 必備技能：Docker run 參數、Windows 容器基礎
• 進階技能：安全需求落地與基準制定

延伸思考：

• 何時應選 hyperv？何時選 process？
• Hyper-V Container 的啟動開銷與密度影響？

Practice Exercise（練習題）

• 基礎練習：各啟動一次 process 與 hyperv 隔離容器。
• 進階練習：測試兩者啟動時間/資源使用差異（定性記錄）。
• 專案練習：撰寫團隊隔離選型指南。

Assessment Criteria（評估標準）

• 功能完整性（40%）：兩種隔離模式皆可啟動
• 程式碼品質（30%）：操作步驟清晰、可複現
• 效能優化（20%）：對開銷差異有觀測
• 創新性（10%）：隔離策略制定能力

案例分類 ——————————–

1) 按難度分類

• 入門級（適合初學者）
  • Case 4（版本門檻核查）
  • Case 5（啟用 Hyper-V）
  • Case 7（Docker Settings 管理）
  • Case 8（hello-world 驗證）
  • Case 12（Windows 端 Docker CLI）
• 中級（需要一定基礎）
  • Case 1（Hyper-V 取代 VirtualBox）
  • Case 6（資源規劃）
  • Case 9（Shared Drives 綁定）
  • Case 10（未共享時的掛載診斷）
  • Case 11（SMB 共享原理與安全）
  • Case 13（沙箱風險隔離）
  • Case 14（MAC Spoofing）
• 高級（需要深厚經驗）
  • Case 2（Nested 建置）
  • Case 3（MobyLinuxVM 啟動失敗診斷）
  • Case 15（VBS/Device Guard 與政策協作）
  • Case 16（Nested 作業準則）
  • Case 17（Windows 容器隔離選型）

2) 按技術領域分類

• 架構設計類：Case 1, 2, 13, 16, 17
• 效能優化類：Case 6
• 整合開發類：Case 7, 8, 9, 12
• 除錯診斷類：Case 3, 4, 5, 10, 14
• 安全防護類：Case 11, 15, 17

3) 按學習目標分類

• 概念理解型：Case 1, 4, 7, 11, 17
• 技能練習型：Case 5, 6, 8, 9, 12, 14
• 問題解決型：Case 2, 3, 10, 15, 16
• 創新應用型：Case 13（沙箱策略）、Case 16（以流程替代快照）

案例關聯圖（學習路徑建議） ——————————–

• 建議先學： 1) Case 4（版本門檻核查）→ 2) Case 5（啟用 Hyper-V）→ 3) Case 7（Settings 管理）→ 4) Case 8（hello-world）
• 進階串接：
  • 若在 VM 內測試：Case 2（Nested 建置）→ Case 6（資源規劃）→ Case 14（MAC Spoofing）→ Case 3（啟動失敗診斷）
  • 檔案共享路徑：Case 9（Shared Drives）→ Case 10（診斷未共享綁定）→ Case 11（SMB 安全）
• 高階專題：
  • 安全與政策：Case 15（VBS/Device Guard）→ Case 16（Nested 作業準則）
  • 隔離選型：Case 17（–isolation）
• 完整學習路徑建議：
  • 基礎搭建（4→5→7→8）
  • 若需沙箱：加入（2→6→14→3→13）
  • 開發效率：加入（9→10→11→12）
  • 安全與隔離：加入（15→16→17）
  • 最終能在受控沙箱中，以正確資源與共享設定完成 Docker for Windows 的開發體驗，並能依需求選擇合適的隔離等級與安全策略。