容器生命週期：為什麼它一啟動就結束了？

容器不是「開著」或「關著」兩種狀態而已，它有一個完整的生命週期。先建立這張地圖，之後每個指令的作用就有地方掛。

        docker create                docker start
（映像） ──────────→ [Created] ──────────────→ [Running]
                                                 │  ↑
                              docker pause  ─────┤  │ docker unpause
                                                 ↓  │
                                             [Paused]
                                                 │
                          docker stop / 主程式自己結束
                                                 ↓
                                            [Exited]
                                                 │ docker rm
                                                 ↓
                                            （消失，可寫層一併刪除）

五個狀態的意義

• Created（已建立）：容器的檔案系統、網路設定都準備好了，但裡面的程式還沒開始跑。
• Running（執行中）：PID 1 的程式正在執行。
• Paused（暫停）：process 被凍結（用 cgroup 的 freezer），記憶體內容保留著，可以解凍繼續。很少用。
• Exited（已結束）：裡面的程式已經結束（正常或異常）。注意：容器本身還在，可寫層還在，log 也還在——只是沒在跑。這就是 docker ps -a 看得到、docker ps 看不到的那些。
• Removed（已刪除）：docker rm 之後才真正消失，可寫層一併刪掉（ch03 講的資料就是在這一刻沒的）。

那 docker run 是什麼？

來看這個讓無數新手困惑的現象：

$ docker run ubuntu
$ docker ps
CONTAINER ID   IMAGE   STATUS
（空的，什麼都沒有）

$ docker ps -a
CONTAINER ID   IMAGE    STATUS
7f3a9c1b2e4d   ubuntu   Exited (0) 2 seconds ago    ← 已經結束了

「我明明啟動了一個 Ubuntu，怎麼馬上就死了？是不是壞了？」

推理過程

• ubuntu 映像的預設指令是 bash。
• 你沒有給它終端機（沒加 -it），bash 一啟動發現沒有輸入可讀，立刻正常結束。
• PID 1 結束 → 容器結束。Exit code 0 代表「正常結束」，不是錯誤。

所以這不是壞掉，是它正確地做完了你叫它做的事——執行 bash，然後 bash 結束了。

正確的做法

# 想要進去互動：給它終端機
docker run -it ubuntu bash

# 想要它一直跑：讓 PID 1 是一個不會結束的程式
docker run -d nginx        # nginx 本來就會常駐

• -i（interactive）：保持標準輸入開著。
• -t（tty）：分配一個虛擬終端機。兩個要一起用才有互動 shell 的效果。
• -d（detach）：背景執行，指令立刻返回，不佔住你的終端機。

由此推導出一條 Dockerfile 鐵律

PID 1 在 Linux 裡不是普通的編號，它有兩個特殊責任。搞不清楚這個，你的服務每次部署都會硬生生斷線。

特殊責任一：預設不理會訊號

• 一般 process 收到 SIGTERM（禮貌的結束請求）時，就算程式沒寫處理邏輯，核心也會用預設行為把它終止。
• 但 PID 1 例外：核心對 PID 1 不套用預設訊號行為（因為在真實系統上 PID 1 是 init，隨便被殺掉整台機器就掛了）。所以 PID 1 如果自己沒有註冊訊號處理器，SIGTERM 就等於被完全忽略。

這造成 docker stop 卡 10 秒的現象

docker stop myapp
  ① Docker 送 SIGTERM 給容器的 PID 1 →「請你收工」
  ② 等待寬限期（預設 10 秒）
  ③ 時間到還沒死 → 送 SIGKILL（強制砍，無法被忽略）

如果你的程式收不到 SIGTERM，就會走完整整 10 秒然後被硬殺——正在處理的 HTTP 請求直接斷線、資料庫交易沒有 rollback、連線池沒有正常釋放。

真正的兇手：shell form vs exec form（差幾個字元，天差地遠）

Dockerfile 的 CMD 和 ENTRYPOINT 有兩種寫法：

# ❌ shell form（字串）
CMD java -jar /app/app.jar

# ✅ exec form（JSON 陣列）
CMD ["java", "-jar", "/app/app.jar"]

shell form 會被 Docker 自動改寫成 /bin/sh -c "java -jar /app/app.jar"，於是容器裡變成：

PID 1: /bin/sh -c java -jar /app/app.jar   ← 收到 SIGTERM 的是它
  └─ PID 7: java -jar /app/app.jar          ← 你的應用在這裡

改用 exec form，Java 就直接是 PID 1，SIGTERM 直達 JVM，Spring Boot 的關機流程正常運作：

PID 1: java -jar /app/app.jar   ← 訊號直達，優雅關機生效

Spring Boot 的完整優雅關機設定

# application.yml
server:
  shutdown: graceful          # 停止收新請求，等現有請求做完
spring:
  lifecycle:
    timeout-per-shutdown-phase: 20s

搭配 docker stop --time=30（把寬限期拉長到 30 秒），確保應用有足夠時間收尾。兩邊的時間要對得上：Docker 的寬限期必須大於應用的關機逾時，否則還是會被硬殺。

特殊責任二：收養孤兒行程

• 真實系統上，父行程死掉後留下的孤兒會被 PID 1（init）收養，並在它結束時負責回收，避免變成殭屍行程（zombie）。
• 但你的 Java 應用當 PID 1 時，它不會做這件事——它不是 init。如果你的程式會 fork 出子行程（例如呼叫外部指令），久了就會累積殭屍行程佔用 PID 表。
• 解法：docker run --init，Docker 會塞一個極小的 init 程式（tini）當 PID 1，由它負責轉發訊號與回收殭屍，你的程式當 PID 2。兩個問題一次解決。

學過前四章之後，這些參數不再是要背的咒語，而是有原理可推的開關。

docker run -d --name myapp \
  -p 8080:8080 \
  -e SPRING_PROFILES_ACTIVE=dev \
  -v app-data:/data \
  -m 512m --cpus 1.5 \
  --restart unless-stopped \
  myapp:1.0

重啟策略（--restart）：容器界的自動復活

• no（預設）：死了就死了。
• on-failure[:次數]：只有非零結束碼才重啟，可限制次數。適合批次任務。
• unless-stopped：常駐服務的最佳選擇——會一直重啟，但如果是你主動 docker stop 的，就尊重你的決定不再自動拉起（重開機後也不會擅自啟動）。
• always：無論如何都重啟，連你手動停掉後、Docker 服務重啟時也會把它拉回來。

docker logs —— 它其實只是在讀一個檔案

docker logs -f --tail 100 myapp      # 跟隨最後 100 行
docker logs --since 10m myapp        # 只看最近 10 分鐘

這個心智模型直接推導出兩個重要結論：

• 如果你的應用把日誌寫進容器裡的檔案（例如 /var/log/app.log），docker logs 什麼都看不到，而且那個檔案會隨容器一起消失。容器化應用的日誌應該直接印到 stdout，讓外部的日誌系統去收集。（Spring Boot 預設就是印到 console，不要畫蛇添足去設定 file appender。）
• 日誌檔會無限長大吃光磁碟——這是真實會發生的事故。生產環境務必設定輪替：

  docker run --log-opt max-size=10m --log-opt max-file=3 ...

docker exec —— 進去看看（但不要改東西）

docker exec -it myapp bash          # 開一個 shell 進去
docker exec myapp ls /app           # 只執行一個指令就出來
docker exec -u root -it myapp bash  # 以 root 身分進去（除錯用）

• 它是在既有容器裡「多開」一個 process，跟 PID 1 並存。所以 exit 離開時只是結束那個 shell，容器不會停。
• 對比 docker attach：attach 是「接上 PID 1 的終端機」，你在裡面按 Ctrl+C 會直接殺掉主程式、容器結束。幾乎所有情況都該用 exec 而不是 attach。
• 如果映像很精簡（distroless、scratch），裡面連 bash 都沒有，exec 會失敗。這是刻意的取捨（ch10），除錯要改用 docker debug 或臨時掛一個含工具的容器進同一個 namespace。
• 再提醒一次（ch01 的心態）：exec 進去是為了觀察，不是為了修改。你在裡面裝的東西重建就消失。

其他日常指令

• docker ps -a：列出所有容器（含已結束的）。容器「消失了」時的第一個排查點。
• docker inspect myapp：傾印該容器的完整設定 JSON——IP、掛載、環境變數、OOMKilled 與 ExitCode（ch02 的 137 就在這裡確認）。
• docker stats：即時看各容器的 CPU／記憶體用量，記憶體那欄會顯示「已用 / cgroup 上限」。
• docker cp myapp:/app/heapdump.hprof ./：把容器裡的檔案複製出來（撈 heap dump、log 很好用）。
• docker top myapp：看容器裡有哪些 process，可以驗證你的程式到底是不是 PID 1。

Healthcheck：讓 Docker 知道「活著」不等於「能服務」

容器在 Running 狀態，只代表 PID 1 還活著。但你的 Spring Boot 可能正卡在啟動階段、或資料庫連線池已經爆掉——process 活著，服務其實已經廢了。

# Dockerfile 裡宣告
HEALTHCHECK --interval=30s --timeout=3s --start-period=60s --retries=3 \
  CMD curl -f http://localhost:8080/actuator/health || exit 1

• --start-period：啟動寬限期，對 Java 特別重要——Spring Boot 冷啟動動輒 30~60 秒，這段期間檢查失敗不算數，否則容器會在啟動途中被判死刑。
• 狀態會顯示在 docker ps 的 STATUS 欄：(healthy) / (unhealthy)。
• 在 Compose 裡它更關鍵：depends_on 搭配 condition: service_healthy，才能真正做到「等資料庫準備好再啟動應用」（ch11 會詳細拆解這個大坑）。

Docker 會偷偷吃掉你的磁碟

用久了突然發現 C 槽／根目錄滿了，元兇通常是這四類：

• 停止但沒刪除的容器（可寫層還在）——docker ps -a 一看嚇一跳。
• 懸空映像（dangling images）：重新 build 後被取代、標籤變成 <none> 的舊映像層。
• 沒人用的 volume：容器刪了但 volume 留著（這是刻意的保護，避免誤刪資料）。
• 建置快取：BuildKit 的快取可以長到數十 GB。

docker system df           # 先看誰在吃空間（強烈建議先跑這個）
docker system prune        # 清停止的容器、無用網路、懸空映像
docker system prune -a     # 連「沒有容器在用的映像」都清掉
docker builder prune       # 清建置快取