為什麼會有容器：從「在我電腦上可以跑」說起

幾乎每個工程師都遇過：同一份程式碼，在自己筆電上跑得好好的，交給同事或丟上測試機就爆炸。要理解容器，得先看清楚這件事為什麼會發生。

關鍵觀念：程式從來不是「單獨」執行的

你以為你交付的是一個 app.jar，但那個 jar 檔要跑起來，其實踩在一整疊「它假設一定存在」的東西上面：

• 執行環境版本：JDK 17 還是 JDK 8？你本機是 17，測試機是 8，直接 UnsupportedClassVersionError。
• 作業系統與系統函式庫：Windows 還是 Linux？Linux 的 glibc 版本對不對？很多套件（影像處理、加解密）底層是 C 寫的，會直接呼叫系統函式庫。
• 環境變數與設定檔：你本機 application.yml 指向 localhost 的資料庫，測試機沒有那個資料庫。
• 檔案路徑：你寫 C:\temp\upload，Linux 機器上根本沒有 C 槽。
• 時區與語系：本機 UTC+8，伺服器 UTC，日期一整個差 8 小時；語系不同導致中文變亂碼。
• 相依的外部服務版本：你本機接 SQL Server 2022，正式環境是 2019，某個語法不支援。
• Port 佔用狀況：本機 8080 是空的，那台機器上已經有別的服務佔住了。

所以真正的問題是：我們一直只交付食譜，卻假設每個人的廚房都一樣。容器的答案很暴力也很有效——那就把廚房一起寄過去。

「把廚房一起交付」不是新想法，容器只是最後的答案。看過前面三代的失敗，才知道容器的每個設計在補什麼洞。

解法一：寫一份安裝文件（Word / Confluence）

• 做法：把「裝 JDK 17 → 裝 SQL Server → 改這個設定檔 → 開這個 port」寫成 30 步驟文件，交給對方照做。
• 死因：① 人一定會漏步驟或看錯；② 文件永遠比現實舊——有人手動改了某台機器卻忘了更新文件；③ 同樣步驟在不同 OS 版本上結果不同。

解法二：寫自動化腳本（Shell Script / Ansible）

• 做法：把那 30 步驟寫成腳本，執行就好，不靠人手。
• 死因：腳本依賴機器的初始狀態。在一台全新乾淨的機器上跑，成功；在一台已經裝過別的東西的機器上跑，可能因為套件版本衝突而失敗。同一份腳本、不同機器、不同結果——這叫做不可重現。

解法三：整台虛擬機（VM）打包交付

• 做法：把裝好裝滿的整台虛擬機做成映像檔，誰要用就複製一份開起來。（VM 是什麼見 基礎篇 ch05 虛擬化與容器。）
• 這招真的解決了環境問題——連作業系統都一起帶走，不可能不一致。
• 死因是「重」：① 一個 VM 映像動輒 10~40 GB，傳輸和儲存成本高；② 開機要跑完整開機流程，分鐘級；③ 每台 VM 都要獨占好幾 GB 記憶體來養一整套作業系統，一台筆電開不了幾台；④ 你只是想跑一個 50 MB 的 Java 程式，卻要為它搬一整套 Ubuntu。

先給定義，再拆解：

拆解一：「使用者空間」和「核心」是什麼？

一台 Linux 電腦的軟體其實分成兩層：

• 核心（Kernel）：作業系統最底層那一小塊，直接管硬體——分配記憶體、排程 CPU、讀寫磁碟、收發網路封包。全機器只有一份。
• 使用者空間（User Space）：核心之上的所有東西——你的程式、JDK、各種函式庫（libssl、glibc）、設定檔、/usr/bin 底下的指令工具。「Ubuntu 和 CentOS 的差別」幾乎都在這一層，不在核心。

關鍵洞見來了：你的程式真正需要的，其實只是「一堆使用者空間的檔案」＋「一個能執行它的核心」。既然同一台機器上的核心大家都能用，那只要打包使用者空間就夠了——這正是容器做的事。

拆解二：搬家類比

• VM ＝ 連地基、水管、電線一起挖走的整棟房子。搬過去絕對能住，但巨大、笨重、搬一次要好幾小時。
• 容器 ＝ 只打包你房間裡的所有家當（家具、衣服、書），到新地方接當地的水電（宿主機核心）就能住。輕、快、一間房子塞得下很多組。

拆解三：所以你得到什麼？

• 體積小：映像檔幾十 MB 到幾百 MB（不含核心），而不是幾十 GB。
• 啟動快：容器不需要「開機」——它本質上只是在宿主機上啟動一個 process（下一章會把這句話講透）。所以是毫秒到秒級，不是分鐘級。
• 密度高：一台機器同時跑幾十個容器很正常。

你現在的用法大概是這樣：寫個 docker-compose.yml，打一句指令，SQL Server 就活了。

services:
  sqlserver:
    image: mcr.microsoft.com/mssql/server:2022-latest
    environment:
      ACCEPT_EULA: 'Y'
      MSSQL_SA_PASSWORD: '請放在 .env，不要寫死在這裡'
    ports:
      - '1433:1433'
    volumes:
      - mssql-data:/var/opt/mssql

volumes:
  mssql-data:

你按下 docker compose up 的那幾秒鐘，底下依序發生了六件事。這六件事正好就是這門課的地圖——每一件都有專章拆解：

1. 解析設定、算出要哪個映像：把 mcr.microsoft.com/mssql/server:2022-latest 這串座標翻譯成「哪個倉庫、哪個映像、哪個版本」。→ ch04
2. 檢查本機有沒有，沒有就下載：而且是一層一層下載（你應該看過畫面上好幾條進度條同時跑）。為什麼會分層、分層有什麼好處？→ ch03
3. 建立一個專屬的虛擬網路：Compose 會偷偷幫你開一個網路，讓這組服務可以用服務名稱互相連線（例如你的 App 直接連 sqlserver:1433）。→ ch07
4. 建立 volume 掛載點：把資料庫檔案放到容器外面，這樣容器砍掉重建資料還在。→ ch06
5. 用映像「造」出容器並啟動：建立隔離空間、換掉檔案系統視角、啟動裡面那個 process。→ ch02、ch05
6. 做 port mapping：讓你在自己電腦上連 localhost:1433 的流量，被轉進容器內部。→ ch07

技術細節可以慢慢學，但有個思維一定要先換過來，否則後面每一章都會覺得彆扭。

寵物 vs 牛群（Pets vs Cattle）

• 傳統伺服器像寵物：每台都有名字，生病了你要細心照顧、想辦法治好，因為牠獨一無二、死了就沒了。（伺服器出問題 → 遠端登入、慢慢查、手動修）
• 容器像牛群：只有編號，沒有名字。某一頭出問題？淘汰掉，從同一個範本再生一頭一模一樣的——因為牠們本來就該長得一樣，而且再生一頭只要幾秒鐘。

由此推導出三條實務原則

1. 不要進容器裡手動改東西。你 docker exec 進去裝了個套件、改了個設定，下次容器重建就全部消失。這不是 bug，是刻意的設計——它保證了「每次長出來的都一樣」。
2. 所有改動都要回寫到檔案裡：要多裝一個套件 → 寫進 Dockerfile；要改一個設定 → 寫進 docker-compose.yml 或環境變數。這種「把最終狀態寫成檔案，讓工具去實現它」的風格叫做宣告式（declarative），也是後面 Kubernetes（ch14）的靈魂。
3. 凡是要留下來的資料，都必須明確放到容器外面（volume）。沒放的東西，預設就是隨容器一起消失。→ ch06