資料持久化：容器刪了，資料要怎麼活下來

ch03 的結論再複習一次：容器所有的寫入都在「可寫層」，而可寫層屬於那個容器，docker rm 就一併消失。

但這不是缺陷，而是刻意的：正因為每個容器都從乾淨的映像出發，才有「壞了不修、重建就好」的自由。問題只在於——有些資料真的必須活下來。

三類資料，三種處理

• ① 必須永久保存（狀態）：資料庫檔案、使用者上傳的檔案、產生的報表。→ 必須放到容器外面，這章的主題。
• ② 需要即時同步（開發便利）：你正在改的原始碼、想快速調整的設定檔。→ Bind mount，讓宿主機的改動立刻反映到容器裡。
• ③ 用完即丟（暫存）：快取、臨時檔、解密後的秘密。→ 留在可寫層沒關係，或用 tmpfs 放在記憶體裡（更快、更安全）。

Docker 提供三種把資料放到容器外的方式

接下來三張卡逐一拆解。它們的共同機制其實一模一樣：都是 mount，把容器裡的某個路徑「換成」外面的某個東西。

Volume 就是一塊由 Docker 建立與管理的儲存空間，掛載到容器裡的某個路徑。你不需要知道它實際在磁碟的哪裡，只要記得名字。

三種寫法，同一件事

# 指令列
docker run -v mssql-data:/var/opt/mssql mcr.microsoft.com/mssql/server:2022-latest

# compose 檔（你已經在用的寫法）
services:
  sqlserver:
    volumes:
      - mssql-data:/var/opt/mssql   # ← 冒號左邊沒有斜線 = volume 名稱
volumes:
  mssql-data:                       # ← 這裡宣告，Docker 幫你建

# 明確版寫法（可讀性最好，推薦用在正式設定）
    volumes:
      - type: volume
        source: mssql-data
        target: /var/opt/mssql

Volume 的四個好處

1. 生命週期獨立於容器：容器砍掉重建幾百次，volume 都還在。這正是你想要的——docker compose down 再 up，資料庫內容原封不動。
2. 繞過 overlay 檔案系統，效能好：ch03 說過 Copy-on-Write 對大檔案頻繁寫入很不友善。Volume 直接寫到宿主機檔案系統，沒有 CoW 開銷。資料庫必須用 volume，效能是和持久性同等重要的理由。
3. 跨平台一致：不用煩惱 Windows 的 C:\ 路徑、macOS 的權限差異——名字在哪都一樣。
4. 可管理、可備份：有專門的一組指令可以操作它。

Volume 的日常指令

docker volume ls                    # 列出所有 volume
docker volume inspect mssql-data    # 看它實際在宿主機的哪個目錄
docker volume create my-data        # 手動建立
docker volume rm my-data            # 刪除（有容器在用會拒絕）
docker volume prune                 # 清掉所有沒被使用的 ⚠️危險

具名 vs 匿名 volume

• 具名（named）：-v mssql-data:/var/opt/mssql —— 有名字，你找得到、管得到。正式用法。
• 匿名（anonymous）：-v /var/opt/mssql（只有容器內路徑）—— Docker 自動產生一個亂碼名字。很容易變成孤兒垃圾佔滿磁碟，而且下次啟動不會自動接回去。避免使用。

Bind mount 是把宿主機上一個你指定的路徑，直接掛到容器裡的某個路徑。兩邊看到的是同一份檔案——任何一邊改動，另一邊立刻看到。

# 開發時同步原始碼
docker run -v /home/user/myapp/src:/app/src myapp:dev

# compose（相對路徑以 compose 檔所在位置為基準）
services:
  app:
    volumes:
      - ./src:/app/src              # 程式碼同步
      - ./config/app.yml:/app/config/app.yml:ro   # 單一檔案，唯讀

• :ro ＝ read-only，容器只能讀不能改。掛設定檔時養成加 :ro 的習慣，避免容器裡的程式意外改壞你的檔案。
• 可以掛單一檔案，不一定要整個目錄。

典型用途

• 開發熱更新：改了程式碼不用重建映像，容器裡立刻看到（配合 Spring Boot DevTools 或前端的 dev server）。
• 注入設定檔：同一個映像，掛不同的設定檔就變成不同環境。
• 取出產物：把容器產生的報表、日誌寫到掛出來的目錄，方便你直接用本機工具打開。

四個真實會卡住你的地雷

1. 權限與 UID 對不上（最常見）
   容器內的程式若以 root（uid 0）執行，它寫出來的檔案在宿主機上擁有者就是 root——你的一般帳號可能改不動也刪不掉，得用 sudo。反過來，容器內的非 root 使用者（例如 uid 1000）可能沒有權限寫入你掛進去的目錄，於是應用啟動就報 Permission denied。
   解法：docker run -u $(id -u):$(id -g) ... 讓容器以你的 UID 執行，或事先把目錄權限設好。這是 Linux 上做 bind mount 最常見的卡關點——記住這個症狀，省你半天。
2. Windows／macOS 上的效能懸崖
   Docker Desktop 底下是一台 Linux 虛擬機，宿主機的檔案要透過檔案共享層轉進去，大量小檔案的存取會慢到不可思議（Java 專案的 target/、Node 的 node_modules/ 是重災區）。解法：只掛真正需要同步的目錄；把相依套件目錄改用 volume（見下一張卡的技巧）。
3. 路徑不存在會被「自動建立成目錄」
   你想掛一個設定檔卻打錯路徑，Docker 不會報錯，而是在宿主機建一個空目錄掛進去——於是應用讀到的是個目錄不是檔案，錯誤訊息還很莫名其妙。掛單一檔案前先確認檔案真的存在。
4. 可攜性差
   Bind mount 綁死了宿主機的目錄結構，別人 clone 你的專案不一定有那個路徑。所以正式環境幾乎不用 bind mount，開發環境才用。

這是最反直覺、也最容易讓人卡住一整個下午的行為。

核心規則：掛載是「蓋住」，不是「合併」

經典災難現場：Node 的 node_modules

volumes:
  - ./:/app          # 把整個專案目錄掛進去

• 你在建置映像時已經在 /app/node_modules 裝好了所有套件。
• 但你把宿主機的專案目錄整個掛到 /app 上——而你本機沒有 node_modules（或是給另一個作業系統用的版本）。
• 結果：映像裡那份好好的 node_modules 被遮住了，應用啟動就噴 Cannot find module。

解法：再疊一個 volume 把那個子路徑「蓋回來」

volumes:
  - ./:/app                  # 專案程式碼同步
  - /app/node_modules        # ← 匿名 volume 蓋在上面，保住映像裡那份

Java 專案的等價情境是 /app/target 或 Maven 的 ~/.m2——把 .m2 做成 volume，可以讓每次建置不用重新下載相依套件。

那個很重要的特例：空的具名 volume 會先「複製」映像內容進去

• 這就是為什麼你第一次跑 mssql-data:/var/opt/mssql，資料庫的初始檔案結構能正常建立——volume 不是空空地把它們遮掉，而是先繼承了一份。
• 但這個貼心行為只發生在「volume 是空的」的第一次。之後 volume 有內容了，就純粹是覆蓋。
• 而且 bind mount 完全沒有這個行為——bind mount 永遠是無情覆蓋。這正是 node_modules 災難只發生在 bind mount 的原因。

把前面的知識套到你實際在用的情境。

正確的 compose 設定

services:
  sqlserver:
    image: mcr.microsoft.com/mssql/server:2022-latest
    environment:
      ACCEPT_EULA: 'Y'
      MSSQL_SA_PASSWORD: ${MSSQL_SA_PASSWORD}   # ← 從 .env 讀，不要寫死
    ports:
      - '1433:1433'
    volumes:
      - mssql-data:/var/opt/mssql               # 資料（必須）
      - ./backup:/backup                        # 備份檔交換區

volumes:
  mssql-data:

• /var/opt/mssql 底下同時放了資料檔、log 檔和設定——整個目錄掛出來最安全，不要只挑子目錄。
• 密碼絕對不要寫死在 compose 檔裡（這份檔案會進版控）。用 .env，並把 .env 加進 .gitignore。

備份 volume 的通用技巧（任何 volume 都適用）

Volume 沒有內建的匯出指令，標準作法是開一個臨時容器，同時掛上 volume 和你的目錄，用 tar 打包：

# 備份
docker run --rm \
  -v mssql-data:/source:ro \
  -v $(pwd):/backup \
  alpine tar czf /backup/mssql-backup.tar.gz -C /source .

# 還原
docker run --rm \
  -v mssql-data:/target \
  -v $(pwd):/backup \
  alpine sh -c 'cd /target && tar xzf /backup/mssql-backup.tar.gz'

看懂這兩行，你就真的理解 volume 了：volume 只是一塊可以被任何容器掛載的儲存空間，誰掛它就能讀寫它。

誰擁有這些檔案：UID 的真相

• SQL Server 官方映像內部以 uid 10001 的使用者執行。你在宿主機上看 volume 目錄，會發現檔案的擁有者顯示成 10001（一個你機器上不存在的使用者）。
• 這是正常的——UID 是純數字，容器內外共用同一組數字空間，只是名字對不上（因為 Docker 預設沒開 user namespace，見 ch02）。
• 由此推出一個實務原則：不要用 bind mount 給資料庫存資料。權限問題會沒完沒了，用 volume 讓 Docker 處理。

那個核彈級指令

docker compose down       # 停止並刪除容器與網路，volume 保留 ✅
docker compose down -v    # 連 volume 一起刪除 💣 資料全毀

tmpfs：只存在記憶體的掛載

docker run --tmpfs /app/tmp:size=100m myapp

# compose
services:
  app:
    tmpfs:
      - /app/tmp:size=100m

• 資料完全不落地，容器一停就徹底消失。
• 用途一：速度——記憶體比磁碟快幾個數量級，適合大量暫存檔。
• 用途二：安全——解密後的秘密、暫時的 token 放這裡，不會留在磁碟上被鑑識。
• 注意它吃的是宿主機記憶體，一定要設 size 上限，否則寫爆記憶體。

唯讀根檔案系統：進階的安全實務

docker run --read-only --tmpfs /tmp myapp

• --read-only 讓整個容器檔案系統唯讀，攻擊者即使進來也無法植入或修改檔案。
• 再用 tmpfs 開放少數真的需要寫入的路徑（/tmp、JVM 的暫存目錄）。
• 這是容器安全強化的標準作法之一，K8s 裡對應 readOnlyRootFilesystem: true（ch14）。

怎麼確認到底掛了什麼？

docker inspect -f '{{json .Mounts}}' myapp | jq

會列出每個掛載的類型（volume/bind）、來源、目標、是否唯讀。「我明明改了檔案怎麼沒生效」的第一個排查點就是這裡——先確認你以為的掛載真的存在、而且掛在你以為的位置。