容器化革命——從 Docker 入門到網站架構銜接

當網站從單體架構逐步拆分成多個微服務後，開發與部署會面臨新的挑戰。不同服務可能使用不同的程式語言、函式庫版本與系統設定，開發環境可以正常執行，到了測試環境或正式伺服器卻可能因環境不一致而發生錯誤。服務數量增加後，安裝、設定、更新與回復也會變得更加複雜，這就是常說的部署地獄。

本篇將從 Docker 基礎開始，說明容器如何協助網站架構建立一致、可移植和容易管理的執行環境。內容分成兩個部分，第一部分介紹 Docker 容器技術與實際部署，第二部分則說明容器網路、資料儲存，以及單機容器在規模擴大後所遇到的限制。

首先會比較虛擬機與容器的本質差異。虛擬機通常包含完整的作業系統，隔離程度較高，但需要消耗較多 CPU、記憶體與磁碟資源。容器則共用主機的核心，透過程序、檔案系統與資源限制，讓多個服務能在同一台主機上彼此隔離。容器啟動速度較快、使用資源較少，因此非常適合微服務和網站應用的快速部署。

接著會介紹 Docker 的三個核心概念：Image、Container 和 Repository。Image 是包含應用程式與執行環境的映像模板，Container 是由 Image 啟動的實際服務，Repository 則負責儲存與分享映像檔。理解這三個概念後，就能使用 Dockerfile 將微服務、相依套件與啟動指令封裝成標準化單元，避免服務因為環境不同而無法執行。

在網站實作部分，會使用 Docker Compose 同時啟動微服務、Redis、MySQL 和 Nginx。微服務負責處理網站邏輯，Redis 提供快取或暫存資料，MySQL 儲存主要資料，Nginx 則作為反向代理與對外入口。透過一份 Compose 設定檔，就能建立服務之間的依賴關係、網路連線、環境變數和啟動順序，讓開發者可以用一致的方式快速建立完整網站環境。

第二部分將說明 Docker 的網路模型，包括 Bridge、Host 和 Overlay。Bridge 適合一般單機容器互聯，Host 可以讓容器直接使用主機網路，Overlay 則適合跨主機或叢集環境。正確理解網路模式，才能處理網站入口、服務發現、容器互連與對外提供服務等問題。

資料儲存方面，容器本身適合執行服務，但不適合直接保存重要資料。當容器被刪除或重新建立時，容器內的資料可能會消失，因此需要使用 Volume 或 Bind Mount 保存 MySQL 資料、Redis 設定、網站上傳檔案與日誌。最後，本篇也會討論單機 Docker 的極限。當容器數量增加到數十、數百甚至更多時，人工管理啟動、更新、故障轉移與資源分配將變得困難，這時就需要進一步銜接容器編排平台。

透過本篇，讀者可以從 Docker 基礎一路理解到網站實際部署，掌握容器如何改善微服務的開發與維運，也能看見 Docker 從單機工具走向大型容器平台之前，必須面對的網路、儲存與管理問題。