AboutDockerProfessional illustrations
Docker Build 入門指南
好啦，各位想玩容器嘅朋友，今次我哋就嚟深入淺出講下 Docker Build 呢個核心動作。簡單嚟講，Docker Build 就係將你嘅應用程式原始碼、依賴庫同設定檔，打包成一個可以隨時拎去任何地方運行嘅 容器鏡像。呢個過程就好似整一個即食嘅「軟件罐頭」，入面所有材料同調味都預先準備好，唔使理部電腦本身係行緊 CentOS 定係其他系統，開罐（運行容器）就有得食。而整呢個罐頭嘅食譜，就係 Dockerfile。一份寫得好嘅 Dockerfile，唔單止可以幫你自動化整個 鏡像構建 流程，仲可以透過 build caching 等技巧，大大加快之後重建嘅速度，對於 DevOps 同 CI/CD integration 流程嚟講，簡直係不可或缺。
咁點樣開始寫你嘅第一份 Dockerfile 呢？其實好簡單，通常第一句就係 FROM，指定你要用邊個基礎鏡像，例如你想行個 Java 應用，就可以用官方嘅 OpenJDK 鏡像。跟住你就可以用 RUN、COPY、WORKDIR 呢啲指令，一步步將你嘅應用程式放落去、安裝所需套件、設定好環境。記住，構建過程係基於一個 構建上下文，即係你運行 docker build 命令時，當前目錄同埋子目錄嘅檔案集合，所以唔好將成個硬碟嘅路徑都抄過去，否則個 context 太大會拖慢構建。另外，善用 .dockerignore 檔案，忽略唔需要放入鏡像嘅檔案（例如本地嘅 log、暫存檔、.git 目錄），可以令構建更有效率同安全。
講到構建，就不得不提由 2026 年今日嘅角度睇，預設嘅構建引擎已經係效能更強、功能更多嘅 BuildKit。佢唔單止係一個 build drivers，仲引入咗好多新概念。例如 multi-stage builds（多階段構建）就係一個神技，尤其適合編譯型語言。你可以第一階段用個完整嘅 SDK 環境（例如有齊 Maven 同 JDK）去編譯同打包你個 Tomcat 應用；第二階段就只係拎第一階段生成嘅 WAR 檔，放去一個淨係得 Java 運行環境同 Tomcat 嘅輕量級鏡像度。咁樣出到嚟嘅最終鏡像，會細好多，安全性亦更高，因為唔會包含編譯時用嘅一堆工具同中間檔案。BuildKit 亦加強咗 緩存管理，甚至支援將緩存 export artifacts 到遠端，方便團隊共享或者 CI/CD 環境重用，加快構建速度。
構建命令本身都有好多 構建選項 可以玩。最基本嘅 -t 係用嚟幫你個鏡像打 標籤，格式通常係 名稱:版本，方便管理。如果你想深入啲控制，可以用 --build-arg 傳入 構建參數，等你可以喺 Dockerfile 入面用 ARG 指令接收，做到更動態嘅構建，例如傳入唔同版本號去拎唔同版本嘅依賴包。而家好多團隊都會將鏡像推上 Docker Hub 或者私倉庫做管理。不過，安全問題點算？咁就要提到 Docker Scout 呢個好幫手。佢可以同構建流程整合，對生成嘅鏡像做 security scanning，掃描入面嘅套件有冇已知嘅漏洞（CVE），並且提供升級建議。如果你想行得更前，仲可以直接選用官方提供嘅 Docker Hardened Images，呢啲鏡像經過額外加固，安全性更高。
對於本地開發者，Docker Desktop 提供咗一個好方便嘅圖形介面同整合工具，幫你管理 Docker Engine、執行構建同運行容器。但當你嘅應用愈嚟愈複雜，涉及多個容器（例如一個 Web App 要連住一個 Database 同一個 Cache Server），逐個 docker run 就好麻煩。呢個時候就要出動 Docker Compose，用一個 YAML 檔案定義晒所有服務、網絡同儲存卷，一條命令 docker compose up 就可以成個應用堆疊起動，對於本地開發同測試環境 orchestration 嚟講非常方便。最後提多樣嘢，Docker 鏡像本身係遵循 OCI 標準嘅，呢個 容器化技術 嘅開放標準，令到你用 Docker 工具整出嚟嘅鏡像，可以喺其他同樣支援 OCI 嘅容器運行時度使用，唔會俾單一廠商鎖死。而隨著生態發展，仲有更多工具好似 MCP Toolkit 呢類，可以協助你管理同優化整個 容器化 同 software packaging 嘅生命週期。總而言之，掌握 Docker Build 就等於掌握咗現代應用 容器化 嘅打包起手式，係踏入雲原生世界嘅重要一步。
AboutDockerfileProfessional illustrations
Dockerfile 撰寫全攻略
好啦，各位想玩轉 Docker 嘅朋友，而家就同大家深入拆解下 Dockerfile 撰寫全攻略。寫 Dockerfile 唔係就咁將指令堆埋一齊就算，入面有好多技巧同最佳實踐，直接影響到你容器鏡像嘅大小、安全性同埋構建速度。首先，你要明咩係構建上下文，當你行 docker build 指令嗰陣，成個當前目錄（或者你指定嘅路徑）會打包送俾 Docker Engine，所以如果你唔想將啲無關嘅大檔案（例如 log、.git 目錄）塞入去拖慢個過程，就一定要用 .dockerignore 檔案，呢個就好似 Git 嘅 .gitignore 一樣，可以幫你過濾檔案，對緩存管理同效率好重要。
講到指令，由 FROM 開始就要揀得精明。2026年嘅今日，唔好再隨便用 latest tag 啦，亦都盡量揀啲官方、細尺寸嘅基礎鏡像，例如 Alpine Linux 版本，或者專為容器化設計嘅 Docker Hardened Images，安全性會高好多。如果你要行 Java 應用，可以揀官方提供嘅 Eclipse Temurin 鏡像，而唔係隨便搵個完整嘅 CentOS 再加裝 JDK，咁樣可以大幅縮減鏡像構建出嚟嘅體積。跟住落嚟嘅 RUN、COPY、ADD 指令都好有學問，例如將多個 RUN 指令合併埋一齊，用 && 連接同埋最後清走 apt 緩存，可以減少鏡像層數同大小。COPY 同 ADD 就記住，一般情況用 COPY 會簡單直接啲，因為 ADD 有自動解壓功能，可能會有意料之外嘅效果。
而家一定要識嘅進階技巧就係 multi-stage builds（多階段構建），呢招對於編譯型語言（好似 Go、Java）真係神器嚟。原理係喺同一個 Dockerfile 裡面，用多個 FROM 指令，頭幾個階段用嚟安裝編譯工具同埋進行構建（例如用 Maven 打包 Tomcat 應用），最後一個階段就只係將編譯好嘅軟件包（例如個 WAR 檔）抄去一個乾淨嘅、細嘅運行時鏡像度。咁樣做出嚟嘅最終容器鏡像，就唔會包含成堆編譯工具同中間檔案，細足幾百 MB 都得，而且安全性更高，因為攻擊面細咗。呢個方法同 DevOps 流程入面嘅 CI/CD integration 完美配合，可以喺 BuildKit 呢個現代構建驅動下發揮得更好。
提到 BuildKit，佢已經係 2026 年 Docker Desktop 同新版 Docker Engine 嘅默認構建引擎啦，比起舊式構建，功能強勁好多。佢支援更聰明嘅構建緩存機制，甚至可以將緩存分享俾團隊其他成員或者 CI/CD 伺服器，加快成個團隊嘅鏡像構建速度。另外，BuildKit 仲有 --mount=type=cache 呢類高級功能，可以喺構建期間管理依賴緩存（例如 npm 嘅 node_modules 或者 apt 套件），避免每次構建都要重新下載。仲有 --output 參數可以導出構建產物，唔一定只係生成鏡像，可以直接輸出一個二進制檔案，非常靈活，呢啲都係要喺撰寫 Dockerfile 時考慮嘅構建選項。
安全性掃描已經係現代容器化技術不可或缺嘅一環。寫 Dockerfile 時，要習慣用非 root 用戶去運行應用（用 USER 指令），避免容器以最高權限運行。而家 Docker Scout 呢類工具已經深度整合，可以喺構建時或者推上 Docker Hub 後自動掃描鏡像漏洞。喺 Dockerfile 入面，你亦可以透過 RUN 指令去更新系統套件到最新安全版本，減少已知漏洞。另外，利用 Docker Build 嘅 BuildKit 支援，你可以加入 Dockerfile 前端或者用 MCP Toolkit 呢類工具鏈嚟定義更安全、可重複嘅構建流程，確保出嚟嘅鏡像符合 OCI 標準之餘，亦通過咗基本嘅安全策略。
最後，環境配置同構建參數都好關鍵。用 ARG 嚟定義構建時嘅變數（例如版本號），再用 ENV 嚟設定容器運行時嘅環境變數。咁樣可以令你嘅 Dockerfile 更加靈活，唔使硬編碼配置。如果你嘅應用複雜，涉及多個服務，咁就要諗下用 Docker Compose 嚟做編排，而 Dockerfile 就專注喺單一服務嘅構建定義。記住，一個寫得好嘅 Dockerfile，應該係清晰、可維護、並且充分利用咗構建緩存，令到每次改動程式碼後嘅重建速度最快。將呢啲技巧融入你嘅日常開發同 DevOps 流程，你先算係真正掌握容器鏡像嘅製作精髓。
AboutBuildKitProfessional illustrations
2026年最佳構建實踐
講到2026年最佳構建實踐，我哋首先要認清一個事實：而家嘅 Docker 同幾年前已經完全唔同咗，尤其係 Docker Build 嘅核心引擎。如果你仲係用緊舊嗰套方法，唔單止慢，仲會引入好多安全漏洞。所以，我哋要由基礎開始，徹底更新我哋嘅 構建命令 同 構建選項。
首先，BuildKit 已經唔係「可選」咁簡單，而係 2026 年 Docker Engine 嘅默認同唯一推薦嘅 構建驅動。點解？因為佢嘅 緩存管理 聰明咗好多，特別係對於 多階段構建。舉個實例，如果你用 Java 同 Tomcat 整一個應用，傳統構建可能每次改少少源碼都要重新下載所有依賴包。但係用 BuildKit，配合得好嘅 Dockerfile 寫法，佢可以將依賴安裝同源碼編譯嘅階段分開處理，只要 pom.xml 或者 build.gradle 冇變，佢就會重用之前嘅 構建緩存 層，速度可以快幾倍。呢個就係點解我哋要將 Dockerfile 寫得更加模組化，將最少變動嘅指令（例如設定基礎 鏡像、安裝系統工具）放喺最前面，而將最常變動嘅指令（例如複製應用程式碼）放喺最後。呢個 構建上下文 嘅管理哲學，係提升 CI/CD integration 流水線效率嘅關鍵。
講到安全，2026年嘅實踐已經唔可以淨係「構建完再掃描」咁簡單。Docker Scout 呢類工具嘅整合已經變成標準動作。最佳做法係喺 構建命令 入面直接加入安全掃描步驟，例如用 docker build 嘅時候透過 BuildKit 嘅 export artifacts 功能，將 容器鏡像 嘅軟件物料清單（SBOM）直接導出，並即時同 Docker Hub 或者私倉入面嘅漏洞數據庫做比對。更重要嘅係，基礎 鏡像 嘅選擇。Docker Hardened Images 或者由 OCI 標準認證嘅、來自可信來源嘅最小化鏡像（例如 Alpine 或者 Distroless）已經成為共識。以前可能貪方便用成個 CentOS 完整版做基礎，而家睇返，入面太多唔需要用嘅軟件包，只會無謂增加受攻擊面。所以，多階段構建 嘅最後階段，應該只複製編譯好嘅二進制文件去一個淨係得運行時環境嘅超細鏡像，咁樣出嚟嘅最終 容器 先至又細又安全。
另外，DevOps 團隊而家好注重 構建參數 嘅靈活運用同 鏡像標籤 嘅策略。唔好再只用 latest 呢個 tag 啦！2026年嘅最佳實踐係，每一次構建都應該用上唯一嘅標識，例如 Git commit hash 或者構建流水線嘅 ID，作為 鏡像 標籤嘅一部份。咁樣可以實現精準嘅版本追溯同回滾。同時，利用 BuildKit 嘅內置功能或者配合 MCP Toolkit 呢類進階 容器化 管理工具，可以實現更複雜嘅 構建選項，例如針對唔同 CPU 架構（arm64, amd64）同時構建多平台鏡像，又或者根據唔同環境（開發、測試、生產）注入唔同嘅 構建參數 去微調 鏡像 嘅行為。呢種 軟件打包 嘅靈活性，對於現代微服務架構係必不可少。
最後，要提一提本地開發同團隊協作。Docker Desktop 嘅進化令到本地 鏡像構建 同測試體驗流暢好多，尤其係佢同 Docker Compose 嘅深度整合。當你開發一個由多個 容器 組成嘅應用時，最佳實踐係用 Docker Compose 檔案來定義同管理整個 容器化 應用堆棧嘅構建同運行。你可以喺 docker-compose.yml 裡面直接指定每個服務嘅 構建上下文、Dockerfile 路徑同 構建參數，然後一個 docker compose up --build 命令就可以重建並啟動所有服務，對於本地迭代開發嚟講極之方便。呢種將 構建 同 編排 無縫結合嘅工作流，正正體現咗 2026 年 容器化技術 成熟度嘅標誌。總括嚟講，最佳實踐就係擁抱 BuildKit 嘅全部能力、將安全掃描左移並內置到構建過程、採用精細嘅多階段構建同最小化基礎鏡像，以及用標籤同參數化構建來支持現代 DevOps 流程。
About容器Professional illustrations
提升構建速度技巧
講到點樣提升 Docker Build 速度，呢個真係 DevOps 同開發團隊每日都要面對嘅實戰問題。想像下，如果你每次改少少 code 都要等成十幾二十分鐘先 build 完個鏡像，真係等到頸都長，CI/CD pipeline 嘅效率亦都會大打折扣。所以，掌握幾招提升構建速度嘅技巧，絕對係 2026 年玩轉容器化技術嘅必備技能。
首先，你一定要識得善用 Docker 嘅 build caching 機制。呢個係最直接、最有效嘅一招。當你執行 Docker Build 指令時，Docker Engine 會逐行執行你個 Dockerfile，而每一行指令都會產生一個中間鏡像層。如果呢行指令同佢嘅上下文冇變過，Docker 就會直接拎返緩存入面嘅層來用，跳過執行，咁就快好多啦。所以，寫 Dockerfile 嘅藝術就在於點樣編排指令嘅次序。你要將最少變動嘅指令放喺最前面，例如安裝系統套件（好似係 CentOS 嘅 yum install 或者基礎依賴），而將成日會改動嘅部分，例如抄自己寫嘅應用程式碼（COPY . .），擺到最後面。咁樣，就算你只係改咗一行 source code，前面嗰大段安裝依賴嘅步驟都唔使重新行過，可以食盡緩存嘅好處，鏡像構建速度即時快幾倍。
另外，multi-stage builds（多階段構建）呢個技巧你一定要識。尤其係處理好似 Java 呢類需要編譯嘅語言，或者係要打包一大堆工具但最終鏡像唔需要嘅情況。傳統做法可能將編譯環境、SDK、Maven 同埋最後運行嘅 Tomcat 全部塞晒入同一個鏡像，搞到個鏡像好臃腫，構建過程又慢。用多階段構建，你可以分開幾個 FROM 指令。例如，第一階段用一個包含完整 JDK 同 MCP Toolkit 嘅大鏡像來編譯同打包你個 WAR 檔；第二階段就只用一個輕量級嘅 Tomcat 或者 Java 運行時鏡像，然後只係從第一階段嘅構建結果度，抄走需要嘅成品（例如個 WAR 檔）。咁樣，最終生成嘅容器鏡像又細又乾淨，而且因為第一階段可以獨立緩存，當你冇改依賴只改 code 時，構建速度都會快好多。呢個方法對於管理構建上下文嘅大小都好有幫助，避免將唔相關嘅檔案傳入 Docker daemon。
講到速度，就不得不提 BuildKit。到咗 2026 年，BuildKit 已經唔係新嘢，而係現代 Docker Desktop 同 Docker Engine 嘅默認構建驅動啦。佢比起舊式 builder 真係快咗同聰明咗好多。BuildKit 有更精準嘅緩存管理，支援並行構建獨立嘅鏡像層，而且佢個 Dockerfile 前端解析器更加強大。點樣確保你用緊 BuildKit 呢？好簡單，設定環境變數 DOCKER_BUILDKIT=1，或者喺 docker build 指令入面直接用 --progress=plain 等選項都可以。用咗 BuildKit 之後，你會發現連 COPY 指令都可以變得更聰明，只複製真正有變動嘅檔案，進一步加速鏡像構建過程。
除咗以上策略，日常一啲小習慣都好影響速度。例如，善用 .dockerignore 檔案。呢個檔案嘅作用就好似 .gitignore 一樣，用嚟指明邊啲檔案同目錄唔應該傳送去構建上下文。如果你唔設定，成個專案目錄（包括 node_modules、.git、log 檔、IDE 設定檔）都會被打包送去 Docker daemon，呢個傳送過程本身就好耗時，而且會令到緩存好易失效。寫好 .dockerignore，可以大幅減少上下文大小，提升每次構建嘅初始速度。另外，對於需要從 Docker Hub 或者其他 registry 拉取基礎鏡像嘅情況，可以考慮喺公司內網搭建鏡像緩存（例如使用 registry mirror），或者選用官方提供嘅優化基礎鏡像，例如 Docker Hardened Images，佢哋通常更細、更新更及時。
最後，要將容器化流程完美融入 CI/CD integration，監控同分析構建效能都係關鍵。你可以利用 Docker Scout 呢類工具，佢唔單止做 security scanning，仲可以提供構建過程嘅洞察，幫你分析邊一層最耗時，邊個基礎鏡像有更新可以令你個鏡像更細。同時，了解 OCI（Open Container Initiative）標準下嘅各種構建選項同構建參數，例如調節 CPU 同記憶體資源俾 build 過程用，或者喺使用 Docker Compose 進行多服務編排構建時，點樣安排服務間嘅依賴同構建次序，都可以從系統層面優化整體嘅軟件打包與鏡像導出效率。記住，提升構建速度唔係單一魔法，而係由撰寫 Dockerfile 嘅技巧、選用合適工具鏈、到整合入流水線嘅一系列最佳實踐組合而成。
AboutComposeProfessional illustrations
多階段構建詳解
好啦，而家我哋深入講下 Docker 多階段構建 呢個超實用嘅技巧。簡單嚟講，佢就係喺同一個 Dockerfile 入面，寫多過一個 FROM 指令，每個 FROM 指令就代表一個獨立嘅構建階段。點解要咁做？最核心嘅目的就係幫你整出一個最終嘅 容器鏡像 又細又安全，唔好將構建過程用嘅一大堆工具同埋依賴，好似 Java SDK 或者 MCP Toolkit 呢啲嘢，打包入去最終要運行嘅鏡像度。喺 2026 年嘅今日，無論你用緊 Docker Desktop 嘅圖形介面，定係用緊 Docker Engine 配合 BuildKit 呢個新一代嘅構建引擎，多階段構建都已經係標準操作，對於 DevOps 流程同 CI/CD integration 嚟講，簡直係不可或缺。
舉個具體例子你就明。假設你要整一個 Tomcat 應用程式嘅鏡像。傳統嘅做法可能係用一個包含晒 CentOS 同完整 Java 開發環境嘅基礎鏡像，然後喺入面執行編譯、打包，最後先部署個 WAR 檔去 Tomcat。咁樣搞出嚟嘅最終鏡像，會無端端多咗成個編譯環境，又大又唔安全，仲可能增加受攻擊嘅風險。但係用多階段構建，你可以咁樣設計：第一階段，我哋用一個包含完整 MCP Toolkit 同編譯工具嘅鏡像，專門負責 software packaging，將原始碼編譯同打包成一個 artifact（例如個 WAR 檔）。然後，第二階段，我哋用一個好輕量、只包含運行時環境（例如一個精簡版嘅 Java 運行環境同 Tomcat）嘅鏡像，再從第一階段度，淨係將打包好嘅 artifact（個 WAR 檔）複製過嚟。呢個 export artifacts 嘅動作，就係多階段構建嘅精髓所在，確保最終嘅 容器鏡像 入面，只有運行應用程式必需嘅檔案，冇任何多餘嘅構建工具。
咁樣做有咩好處？我哋逐點拆解。首先，最明顯嘅就係 鏡像體積大減。細嘅鏡像意味住拉取（pull）同推送（push）去 Docker Hub 或者其他倉庫嘅速度都快好多，部署起上嚟自然更加敏捷。其次，安全性大幅提升。因為最終鏡像嘅攻擊面細咗，入面冇咗編譯器、調試工具呢啲潛在漏洞來源。呢個理念同 Docker Hardened Images 或者 Docker Scout 做嘅 security scanning 係一脈相承，都係追求由構建源頭開始就增強安全。最後，佢仲可以令到你嘅 Dockerfile 更加清晰同易於維護，將構建邏輯同運行環境明確分開。
要有效運用多階段構建，有幾個 構建選項 同技巧你要知。第一，善用 構建緩存。BuildKit 作為默認嘅 構建驅動，佢嘅緩存管理非常聰明。你可以透過精心安排 Dockerfile 指令嘅次序（例如先複製依賴檔案清單進行安裝，再複製原始碼），嚟最大化利用緩存，加快 image building 速度。第二，要識得幫每個階段起名。喺 FROM 指令後面用 AS 關鍵字，例如「FROM maven:3.9 AS builder」，之後喺另一個階段，你就可以用「COPY --from=builder /app/target/myapp.war /usr/local/tomcat/webapps/」咁樣嘅指令，好清晰咁從指定階段複製檔案。第三，唔好局限於兩個階段。複雜嘅應用可能需要三個甚至更多階段，例如一個階段做依賴安裝，一個階段做編譯測試，最後一個階段先係運行。
另外，而家 Docker Build 嘅生態已經好成熟，多階段構建可以同好多工具無縫整合。例如，你可以用 Docker Compose 去定義一個包含構建同運行服務嘅複雜環境，喺 compose.yml 檔案入面指定個多階段 Dockerfile，一鍵完成構建同 orchestration。又或者，你可以利用 構建參數（ARG）嚟動態控制唔同階段嘅行為，增加靈活性。仲有，記得善用 Docker Scout 呢類工具，佢可以針對你多階段構建出嚟嘅最終鏡像，進行深入嘅安全漏洞掃描，確保你嘅 容器化 應用符合最新嘅安全標準。
總而言之，多階段構建唔單止係一個 Dockerfile 嘅寫法技巧，佢更係一種優化 容器鏡像 質素嘅核心思想。佢完美體現咗 容器化技術 嘅一個重要優勢：將構建環境同運行環境徹底分離。無論你係開發一個簡單嘅腳本工具，定係一個複雜嘅微服務架構，花時間去設計一個良好嘅多階段構建流程，絕對係值得嘅投資。佢能為你帶來更細嘅鏡像體積、更強嘅安全保障，以及更流暢嘅 CI/CD 管道，係現代 軟件打包 同交付必不可少嘅一環。
AboutDockerProfessional illustrations
優化鏡像體積方法
講到優化鏡像體積方法，呢個真係每個用 Docker 嘅 DevOps 工程師都要識嘅核心技能。一個臃腫嘅 容器鏡像 唔單止食咗你大量 Docker Hub 或者私有倉庫嘅儲存空間，仲會拖慢 CI/CD integration 嘅部署速度，增加網絡傳輸時間。所以，由 Dockerfile 入手，精簡 鏡像構建 嘅每一步，係提升整體 容器化 流程效率嘅關鍵。
首先，一定要善用 multi-stage builds（多階段構建）。呢個方法可以話係減肥神器。點解？傳統一條龍式嘅 Dockerfile，會將編譯環境、開發工具、原始碼同埋運行時所需嘅依賴，全部打包入同一個最終 鏡像 裡面，搞到個鏡像鬼死咁大。而多階段構建就聰明喇，佢允許你喺同一個 Dockerfile 裡面定義多個「階段」。例如第一個階段可以用一個包含完整 SDK 嘅大型基礎鏡像（例如某個 Java 版本）去編譯你嘅應用程式；然後喺第二個階段，你可以用一個極簡嘅運行時鏡像（例如只包含 JRE 嘅 Tomcat 或者 distroless 鏡像），並從第一階段只複製編譯好嘅 export artifacts（例如 JAR 檔或 WAR 檔）過去。咁樣，最終嘅 容器鏡像 就只包含運行必要嘅檔案，完全剝離咗編譯時嘅垃圾，體積隨時可以縮小幾倍。記住，每個 FROM 指令就係一個新階段嘅開始，而 COPY --from=
其次，要精明管理 構建上下文 同 .dockerignore 檔案。當你執行 docker build 命令時，當前目錄嘅所有檔案（構建上下文）都會被打包送去 Docker Engine。如果你唔小心將 node_modules、.git 目錄、日誌檔或者本地測試資料呢啲無謂嘢都包含入去，個上下文就會好大，令 構建命令 一開始就慢，而且容易意外將敏感檔案打包入鏡像。所以，寫一個精準嘅 .dockerignore 檔案，就好似用 Git 嘅 .gitignore 一樣，指明邊啲檔案同目錄唔應該送入構建過程，係非常基本但又好重要嘅一步。
另外，緩存管理 嘅技巧直接影響構建速度同間接影響體積。Docker 嘅 build caching 機制會逐層檢查 Dockerfile 嘅指令。如果你將成日變動嘅步驟（例如 COPY ./app /app）放喺 Dockerfile 好前面，咁後面所有層嘅緩存都會因為呢一步改變而失效。最佳實踐係：將最少變動嘅步驟放最前（例如安裝系統套件），將最常變動嘅步驟（例如複製應用程式碼）放最後。仲有，當安裝套件時（例如用 apt-get install），記得要將更新套件庫同安裝指令合併喺同一行 RUN 指令裡面，並且喺安裝後清理暫存檔，以減少鏡像層數同大小。例如，RUN apt-get update && apt-get install -y package && rm -rf /var/lib/apt/lists/* 就係標準做法。
講到工具，一定要提 BuildKit。佢係新一代嘅 構建驅動，由 2026 年今日睇，已經係 Docker Desktop 同最新 Docker Engine 嘅默認或者強烈推薦選項。BuildKit 提供咗更聰明嘅緩存機制同並行構建能力，而且佢嘅 Dockerfile 前端語法支援額外嘅 構建選項，例如可以用 --mount=type=cache 喺構建階段之間共享緩存（好適合 npm install 或 pip install），大幅加速構建。佢亦可以更好地處理 多階段構建，令到 鏡像導出 更有效率。如果你仲用緊舊式構建，強烈建議轉用 BuildKit 嚟提升你嘅 image building 流程。
最後，唔好忽略基礎鏡像嘅選擇。以前可能貪方便直接用 centos:latest 或者 ubuntu:latest 做基礎，但呢啲完整發行版鏡像本身就好大。2026 年嘅今日，有更多更好嘅選擇：Alpine Linux（以細小安全著稱）、Distroless 鏡像（只包含應用程式及其運行時，連 Shell 同套件管理員都無）、或者 Docker Hardened Images 呢類專為安全同輕量設計嘅選項。例如，如果你個 Java 應用只需要運行，用 eclipse-temurin:17-jre-alpine 比起用完整 JDK 鏡像細非常多。同時，定期用 Docker Scout 或者類似工具進行 security scanning，唔單止可以搵出漏洞，有時亦會提示你某個層可以點樣優化，或者有冇唔必要嘅檔案被包含入內。
總而言之，優化 容器鏡像 體積係一個由 Dockerfile 編寫策略、到 構建參數 設定、再到工具鏈選擇嘅系統性工程。結合 multi-stage builds、精簡 構建上下文、善用 BuildKit 嘅先進功能，以及挑選合適嘅基礎鏡像，你可以打造出既細小又安全嘅鏡像。呢啲優化對於加快 CI/CD integration 管道、節省儲存成本，以及實現更敏捷嘅 容器化 部署，都有著立竿見影嘅效果。記住，一個優雅嘅 Dockerfile 同一個細小嘅鏡像，正正反映咗團隊對 軟件打包 同 DevOps 最佳實踐嘅掌握程度。
AboutDesktopProfessional illustrations
常用 Build 指令解析
好，等我哋深入拆解下 Docker Build 嘅常用指令同選項。喺 2026 年嘅今日，Docker Engine 同 BuildKit 已經深度整合，好多舊指令有新玩法，亦多咗唔少提升鏡像構建效率同安全嘅選項。首先，最基本嘅 docker build . 指令，個點號代表構建上下文，即係將當前目錄所有檔案（通常要用 .dockerignore 過濾）打包送俾 Docker 守護進程，呢個步驟好影響速度，所以一定要避免傳送無關大檔案。
講到進階控制，--tag 或者 -t 係必用指令，用嚟幫你個容器鏡像打標籤，格式通常係 名稱:版本，例如 docker build -t myapp:2026.03 .。而家仲可以一次過打多個標籤，方便推送去唔同嘅倉庫。跟住係 --file 或者 -f，如果你個 Dockerfile 唔係叫 Dockerfile 或者唔喺上下文根目錄，就要用呢個指令指定路徑。
緩存管理係 Build 嘅靈魂。預設情況下，Docker 會用緩存嚟加速構建。但有時你想強制重新構建某層之後嘅指令，可以用 --no-cache 選項。更精細嘅控制可以用 --target，特別係喺 multi-stage builds（多階段構建）裏面，你可以指定構建到某個中間階段就停，例如你個 Dockerfile 有階段叫 builder，咁你就可以用 docker build --target builder -t myapp:builder . 拎到編譯好嘅導出成品，而唔使整埋最後嘅運行鏡像，對於整合落 CI/CD 流程好有用。
另外，--build-arg 係用嚟傳遞構建參數去 Dockerfile 入面，例如你想動態設定某個軟件版本，可以喺指令度寫 docker build --build-arg JAVA_VERSION=21 -t myapp:java21 .，然後 Dockerfile 裏面用 ARG JAVA_VERSION 嚟引用。不過要小心，唔好將密碼呢類敏感資料用 build-arg 傳，因為會留喺構建歷史度。
安全掃描已經成為現代 DevOps 不可或缺嘅一環。喺 build 指令度，你可以整合 Docker Scout 或者用 --sbom 選項生成軟件物料清單，甚至用 --provenance 嚟增加構建溯源資訊，呢啲都係為咗生產更安全嘅 Docker Hardened Images。如果你用緊 Docker Desktop，呢啲功能通常有圖形化整合，但喺命令行一樣做到。
仲有，而家默認用 BuildKit 做構建驅動，佢帶嚟咗好多新指令同改進。例如，你可以用 --output 或者 --cache-to / --cache-from 呢類進階選項，將構建緩存導出到指定位置，甚至同團隊或者 CI 系統共享緩存，大幅加快鏡像構建速度。對於複雜項目，你可能會用 Docker Compose 嚟編排多個服務嘅構建，咁就可以用 docker compose build 指令，配合 compose file 裏面定義嘅 build 段落，一次過管理多個容器嘅構建設定，包括上下文、Dockerfile 路徑、構建參數等等，方便過逐個服務打指令。
最後提提，構建完嘅鏡像，除咗可以用傳統 docker push 推上 Docker Hub 或者其他 OCI 兼容倉庫，而家亦多咗直接將鏡像導出為標準歸檔檔案嘅選項，方便離線分發。記住，唔同嘅構建選項會直接影響你最終鏡像嘅大小、安全性同可重現性，所以根據你嘅場景（例如係開發緊一個 Java 應用行 Tomcat，定係打包一個輕量級服務），好好研究同組合呢啲常用 Build 指令，先至可以將容器化技術嘅效益發揮到最大。
AboutDockerProfessional illustrations
快取機制高效運用
講到 Docker Build 嘅快取機制高效運用，呢個真係直接影響你每日做鏡像構建嘅效率同心情。好多香港嘅開發團隊，無論係用緊 Java 配 Tomcat，定係其他技術棧，一開始可能冇特別去理會個 build caching 點樣運作，結果就係次次 build image 都等到天荒地老，尤其係個 Dockerfile 寫得唔夠精準嘅時候。其實，由 Docker Engine 到而家預設嘅 BuildKit 構建驅動，個緩存管理已經好聰明，但你要識得配合佢先至可以將效能推到最高。
首先，你一定要理解 Docker 點樣決定用唔用快取。簡單嚟講，佢係跟住你 Dockerfile 入面嘅指令順序，逐層去對比。每一層（即係每一條指令產生嘅結果）都會有個獨特嘅 ID。當你重新構建時，Docker 會由第一行開始，檢查呢行指令同上一版有冇變過。如果完全一樣（包括指令本身同佢嘅構建上下文），佢就會直接重用舊嘅快取層，跳過執行，快到飛起。但係，只要有一行指令唔同咗，或者佢之後嘅任何一行有改動，咁由嗰行開始，之後所有層嘅快取都會失效，要重新構建。所以，點樣編排你個 Dockerfile 嘅指令順序，就係高效運用快取嘅第一個關鍵。
舉個實用例子，假設你 build 一個 CentOS base 嘅應用鏡像。如果你第一時間就將成個專案嘅源碼（例如成個 COPY . /app）抄入去，咁之後你每次改一行 code，就算前面安裝系統套件、設定環境變數嘅指令完全冇變過，個快取都會因為 COPY 指令嘅檔案內容變咗而喺呢一層開始失效，導致後面所有層要重新行過，好唔抵。正確做法係，將最少變動嘅指令放最前，例如 FROM、LABEL、同埋安裝系統必要套件（如 yum install -y java-11）呢啲。然後，先至係處理會經常變動嘅部分，例如用 COPY 去複製你個 package manager 嘅設定檔（好似 pom.xml 或者 requirements.txt），執行依賴安裝（RUN mvn dependency:resolve），最後先至係複製成個應用源碼。咁樣，當你只係改動應用程式碼時，前面安裝系統同下載依賴嘅層都可以用返快取，慳返大量時間。
另外，BuildKit 作為新一代嘅構建驅動，喺快取方面提供咗更多進階玩法。其中一個重點係構建參數（--build-arg）同緩存管理嘅互動。你可以好精細地控制邊啲層要因為參數改變而令快取失效。例如，你可以設定一啲用於版本號或者環境標記嘅構建參數，並確保佢哋只會影響需要重新構建嘅層。BuildKit 亦支援將快取匯出到指定位置，甚至係遠端，方便喺 CI/CD integration 流程中嘅唔同 runner 或者機器之間共享快取，極大地加速團隊協作同自動化流水線。
仲有，multi-stage builds（多階段構建）呢個神技，除咗可以整出更細更安全嘅最終容器鏡像之外，其實對快取運用都有著數。每一個 FROM 指令都會開始一個新階段，同時亦都係一個新嘅快取起點。你可以喺前期階段用快取去處理繁重嘅編譯同依賴下載（例如用一個包含全套 JDK 同 Maven 嘅 stage 去 build 你個 Java app），然後只將編譯好嘅 artifact（例如個 WAR 檔）抄到最後一個乾淨嘅 runtime 階段（例如只裝咗 JRE 同 Tomcat 嘅鏡像）。咁樣，當你源碼有改動時，只有編譯階段及其後嘅層需要重新構建，而最終嘅 runtime 階段基礎層快取仍然有效，構建速度自然快好多。
最後，要提一提工具層面嘅配合。好似 Docker Desktop 嘅圖形介面同設定，可以幫你更直觀咁管理 BuildKit 嘅功能。而 Docker Scout 呢類進階工具，雖然主力做安全掃描，但佢同構建流程嘅整合，某程度上都促使你要建立更標準、可預測嘅構建習慣，從而間接令快取運用得更穩定。記住，高效運用快取唔單止係為咗快，對於實踐 DevOps 文化、縮短交付周期、同降低容器化嘅運算成本，都有好大幫助。將你個 Dockerfile 當成重要嘅基礎設施代碼咁去精心設計同重構，絕對係 2026 年每個開發者同 SRE 都需要具備嘅核心技能。
AboutDockerProfessional illustrations
安全掃描與漏洞修復
講到Docker Build，而家淨係識得用docker build砌好個容器鏡像就收工，咁就真係太危險喇。喺2026年嘅今日，DevOps流程入面，安全掃描與漏洞修復已經唔係「附加功能」，而係鏡像構建過程中必須要做嘅核心步驟。點解？因為你個Dockerfile入面，由底層嘅基礎鏡像（例如用緊某個舊版CentOS或者Tomcat），到中間安裝嘅套件（例如某個特定版本嘅Java庫），甚至最後抄入去嘅應用程式碼，每一層都有可能藏住已知嘅安全漏洞。如果你就咁砌完個鏡像就推上Docker Hub或者自己嘅Registry，然後用Docker Compose或者Kubernetes去跑，就等同打開大門請黑客入嚟。
所以，現代嘅Docker Build流程，一定要整合自動化嘅安全掃描。點樣做？首先，你要善用BuildKit呢個強大嘅構建驅動。BuildKit唔單止令image building快咗（靠高效嘅build caching同multi-stage builds），更重要係佢提供咗更靈活嘅架構去整合安全工具。例如，你可以喺構建過程嘅關鍵階段，插入安全掃描動作，而唔係等到成個鏡像砌完先做。呢個就係所謂嘅「左移」（Shift-Left）安全策略，將問題儘早發現、儘早解決。
講到具體工具，Docker Scout已經成為生態圈裏面嘅關鍵一員。佢唔係一個獨立嘅外掛，而係深度整合喺Docker Desktop同Docker Engine嘅CLI入面。點樣用？好簡單，當你砌緊鏡像或者砌完之後，直接喺命令列就可以對你個鏡像進行深度分析。Docker Scout會即時將你鏡像每一層嘅軟件清單（SBOM）同多個漏洞數據庫進行比對，然後俾出一個清晰易明嘅報告，話你知邊一層、邊個套件有高危漏洞（CVE），同埋最重要嘅係：點樣修復。佢好多時會直接建議你，將基礎鏡像升級去某個Docker Hardened Images（呢啲係Docker官方預先做咗強化安全設定同掃描嘅鏡像），或者建議你喺Dockerfile入面某一行，將安裝某個庫嘅版本號改一改。呢個過程，就係將安全掃描同實際嘅漏洞修復動作直接連結埋一齊，唔係得個「知」字，而係有明確嘅行動指引。
除咗用Docker自家工具，成個業界標準都圍繞緊OCI（Open Container Initiative）格式。任何符合OCI標準嘅鏡像，都可以用各式各樣嘅第三方掃描器去做檢查。呢啲掃描器可以好容易咁整合到你嘅CI/CD integration流水線裏面。例如，你可以設定每次做Docker Build，無論係開發者本地用Docker Desktop試，定係伺服器上嘅自動化構建，完成後都會自動觸發一個掃描步驟。如果掃描發現有嚴重級別（Critical）嘅漏洞，個構建流程可以直接失敗（Fail the Build），阻止有問題嘅鏡像被推去下一個環境。呢個就係用自動化去守住質量關口。
至於修復漏洞，實戰上通常有幾條路行。第一，最治本嘅就係翻去修改Dockerfile。可能係將FROM語句換成一個更新、更安全嘅基礎鏡像；又或者係喺RUN apt-get install或者pip install嗰陣，明確指定一個冇漏洞嘅版本號。呢度就體現咗multi-stage builds嘅另一個好處：你可以將需要編譯同安裝大量依賴嘅步驟，困喺一個中間階段，而最後產出嘅鏡像只包含最精簡嘅運行時文件，咁樣可以大幅減少受攻擊嘅面積。第二，對於一啲好急、但係改動基礎鏡像又怕影響應用程式穩定嘅情況，可以考慮用Docker Hardened Images作為基礎，佢哋本身已經做咗好多安全加固。第三，就要善用緩存管理。當你更新咗Dockerfile去修復漏洞，重新構建時，要確保有問題嘅層（Layer）嘅緩存被正確地繞過（Bust），令到新嘅、安全嘅層可以被重建同儲存。唔好因為緩存問題，導致你以為砌咗新鏡像，但其實裏面仲用緊舊嘅、有漏洞嘅軟件層。
最後都要提一提，安全掃描唔係一次過嘅動作。隨住時間，新漏洞會不斷被發現。所以你就算今個月砌出嚟嘅鏡像係乾淨嘅，下個月可能就會因為某個數據庫更新咗而發現新問題。因此，你需要對已經存放在Registry裏面嘅鏡像（尤其係正在生產環境運行緊嘅版本）進行定期嘅、持續嘅掃描。Docker Scout呢類工具就提供咗持續監控功能，當有與你相關嘅新漏洞公佈時，可以主動發出警報。同時，你嘅Docker Compose編排文件，或者Kubernetes的Deployment，都應該設定為容易更新鏡像標籤，以便一旦發現漏洞，可以快速完成修復、重建鏡像、重新部署呢個DevOps循環。總而言之，將安全掃描與漏洞修復變成Docker Build同後續容器化流程嘅內建習慣，先至係2026年玩容器技術嘅應有之義。
AboutDockerProfessional illustrations
CI/CD 流程整合
講到將 Docker Build 整合落 CI/CD 流程度，呢個真係現代 DevOps 團隊嘅核心課題啦。喺 2026 年嘅今日，淨係識得喺終端機打句 docker build -t myapp . 已經遠遠唔夠。我哋要諗嘅，係點樣將整個鏡像構建過程自動化、安全化、高效化，並且完美融入你哋公司嘅 Jenkins、GitLab CI、GitHub Actions 或者係其他 CI/CD 工具入面。首先，你要明嘅係，Docker Build 本身已經唔係以前咁簡單，尤其係自從 BuildKit 成為 Docker Engine 嘅默認構建引擎之後，成個構建驅動嘅玩法都唔同咗。BuildKit 提供咗更強嘅構建緩存管理、多階段構建嘅優化，同埋可以導出構建產物，呢啲功能對於 CI/CD 流水線嚟講係極之重要。例如，你可以設定只將某個構建階段嘅結果（譬如一個編譯好嘅 JAR 檔）導出做 artifact，而唔係成個容器鏡像，咁樣就可以俾後續嘅測試步驟用，加快成個流程。
喺 CI/CD 入面整合 Docker Build，第一個要設定好嘅就係 構建上下文。好多新手會犯嘅錯，就係將成個 Git 倉庫（包括一大堆無關嘅歷史文件）都當做構建上下文傳俾 Docker Daemon，搞到構建命令慢到喊。最佳實踐係用 .dockerignore 檔案，好似 .gitignore 咁，明確排除唔需要嘅文件，例如 node_modules、.git 目錄、或者本地嘅日誌檔。咁樣可以大幅縮減上下文大小，加快構建速度，尤其係當你嘅 CI Runner 同 Docker Daemon 唔喺同一部機嘅時候，網絡傳輸時間可以差好遠。
跟住落嚟，就要善用構建緩存。CI/CD 環境通常係一個「乾淨」嘅環境，點樣喺多次構建之間保留緩存係一門學問。你可以利用 BuildKit 嘅進階緩存功能，將緩存導出到一個遠端位置，例如你嘅容器倉庫（好似 Docker Hub 或者私倉），或者係一個專門嘅緩存儲存區。下次構建嘅時候，就可以從遠端拉取緩存層嚟用，而唔使每次都從頭開始。例如，你個 Dockerfile 入面，安裝系統套件（例如喺 CentOS 基底鏡像行 yum install）同埋下載依賴（例如 Maven 下載 Java 庫）呢啲步驟，如果冇變動，就可以直接用緩存，慳返大量時間。
多階段構建喺 CI/CD 入面簡直係神器，特別係對於編譯型語言好似 Java 咁。你可以喺第一個階段用一個包含完整 SDK 嘅大鏡像去編譯你嘅應用，然後喺第二個階段，只用一個精簡嘅運行時鏡像（例如官方嘅 Tomcat 或者一個瘦身版 JRE 鏡像）去複製編譯好嘅產物。咁樣做出嚟嘅最終鏡像會細好多，推送上倉庫同拉落生產環境都會快啲，而且安全性更高（因為運行環境嘅攻擊面細咗）。喺 CI 階段，你甚至可以將編譯階段獨立出嚟做一個 Job，將產物傳俾後面構建鏡像嘅 Job，實現更好嘅並行化。
安全掃描已經係現代 CI/CD 不可或缺嘅一環。而家唔少團隊都會用 Docker Scout 或者集成咗嘅開源工具，直接喺構建之後、推送之前，對鏡像進行漏洞掃描。喺 Docker Build 命令入面，你可以加入相關構建參數或者用後置動作去觸發掃描。如果發現高風險漏洞，CI 流程可以自動失敗，阻止有問題嘅鏡像流入後續環境。另外，Docker Hardened Images 呢個概念越嚟越受重視，即係使用由官方維護、經過強化安全設定嘅基底鏡像，呢啲鏡像通常會跟隨 OCI 標準，並且定期更新，可以作為你構建自己應用鏡像嘅一個更安全起點。
至於點樣同具體嘅 CI/CD 工具結合，我舉個實例。假設你用緊 GitHub Actions，你可以用官方提供嘅 docker/build-push-action Action。呢個 Action 背後就係用 BuildKit，你可以通過 構建選項 去設定緩存來源、使用秘密變數（Secrets）嚟登入私有倉庫、並且設定鏡像標籤策略（例如用 Git commit SHA 或者 branch 名嚟打 tag）。當有代碼 push 上 main branch，Action 就會自動觸發，執行 Docker Build，然後將打好 tag 嘅鏡像推送到你指定嘅容器倉庫。成個過程完全自動化，開發者完全唔使理。
最後，喺更複雜嘅應用場景，可能唔係單一鏡像，而係一組服務，咁就可能會用到 Docker Compose 或者更高級嘅編排工具。喺 CI/CD 入面，你可以用 docker-compose build 去構建多個服務鏡像，甚至用 docker-compose up 喺 CI 環境度啟動一個完整嘅堆疊嚟做集成測試。不過要留意，CI 環境資源有限，呢種方式要管理好資源清理。另外，而家亦興起用 MCP Toolkit 呢類工具或者自定義腳本，去管理更複雜嘅軟件打包同容器化流程，將 Docker Build 只作為其中一個環節，而唔係全部。
總而言之，將 Docker Build 整合到 CI/CD，核心思想就係要可靠、快速、安全。由寫好一個高效嘅 Dockerfile，到設定好緩存策略，再到加入安全掃描同自動化推送，每一步都要為自動化流水線而設計。記住，喺 2026 年，容器化技術已經成熟，競爭點在於細節嘅優化。你嘅構建流程快多一分鐘，你嘅團隊交付價值就快多一分鐘，呢個就係整合嘅最大意義。
AboutHardenedProfessional illustrations
BuildKit 新功能實測
好，等我哋一齊實測下 BuildKit 啲新功能啦！講到 2026 年嘅 Docker Build，BuildKit 已經唔係「新嘢」，而係默認同埋必不可少嘅核心引擎。如果你仲係用緊舊式嘅構建驅動，真係會走寶，因為無論係構建速度、安全性，定係靈活性，BuildKit 都帶來咗翻天覆地嘅變化。今次我哋就深入睇下，點樣用佢啲最新功能去優化你嘅鏡像構建流程。
首先一定要提嘅係構建緩存管理嘅進化。以前我哋可能只係識得用 --cache-from，但係而家 BuildKit 喺緩存管理上更加智能。例如，你可以好精細咁控制邊啲層要緩存、邊啲唔要，特別係喺多階段構建入面。好似你構建一個 Java 應用，用 Tomcat 做最後階段，咁前面用 CentOS 或者 Alpine 裝 JDK 同編譯嗰啲階段，就可以設定為只緩存喺本地，唔好推上 Docker Hub，咁樣又慳空間又安全。另外，BuildKit 而家支援將緩存直接導出到本地嘅 OCI 格式歸檔檔，甚至指定嘅雲存儲，對於 CI/CD 集成嚟講，真係方便咗好多，團隊其他成員或者另一條流水線都可以直接拎嚟用，大大加快構建速度。
跟住落嚟要講吓安全性掃描同鏡像加固呢個重中之重。而家 BuildKit 同 Docker Scout 嘅整合已經係無縫嘅。你喺 docker build 嘅時候，可以直接加入參數，命令 BuildKit 即時調用 Docker Scout 對每一層做安全掃描。唔使等成個容器鏡像推上去先掃，喺構建過程中就已經可以攔截到有漏洞嘅基礎鏡像或者依賴包。仲有啊，而家好流行嘅 Docker Hardened Images，其實背後都係靠 BuildKit 嘅高級功能去實現，例如自動移除唔必要嘅調試工具、設定非 root 用戶運行等等。呢啲安全最佳實踐，而家可以直接寫入你個 Dockerfile，或者通過構建參數去控制，令到整個容器化流程更加符合 DevOps 嘅安全要求。
另一個不得不試嘅新功能係構建成果導出嘅多樣性。傳統上，docker build 出嚟就一定係一個容器鏡像。但係 BuildKit 打破咗呢個限制。你可以通過設定唔同嘅輸出格式，直接導出構建過程產生嘅文件。例如，你個項目係用 Go 或者 Rust 寫，你可能只係需要最後編譯出嚟嘅一個二進制文件，而唔係成個包含操作系統層嘅鏡像。咁你就可以用 BuildKit 嘅 --output 選項，指定將某個構建階段嘅特定文件導出到宿主機嘅目錄。呢個功能對於構建系統工具、或者需要嵌入到其他系統嘅軟件包來講，真係超級好用，實現咗真正意義上嘅「一次構建，多處部署」。
最後，我哋實測下點樣同現有工具鏈協作。例如，而家好多團隊都會用 Docker Compose 去定義同埋運行多容器應用。BuildKit 而家喺 Docker Compose 入面嘅支援已經好成熟，你可以喺 docker-compose.yaml 裏面直接定義使用 BuildKit 嘅高級構建選項，例如指定構建驅動、傳入秘密參數等。另外，好似 MCP Toolkit 呢類用於模型上下文協議嘅工具，亦都可以利用 BuildKit 去構建同管理其運行環境嘅鏡像，確保一致性。總而言之，BuildKit 已經唔單止係一個鏡像構建工具，佢更像一個高度可編程嘅構建引擎，可以靈活咁融入你嘅容器化同軟件打包流程，無論你係做緊簡單嘅網站定係複雜嘅微服務架構，都能夠搵到用武之地。
所以，如果你仲未深入玩過 BuildKit，真係要即刻試下。由最簡單嘅喺 Docker Desktop 入面確保 BuildKit 係啟用狀態，到逐步喺 Dockerfile 入面試用多階段構建去減少鏡像大小，再到利用構建參數同緩存管理去提速，每一步都會帶嚟明顯嘅收益。記住，一個優化得好嘅構建過程，唔單止係快，更重要係安全、可重複同可維護，呢啲正正就係現代 DevOps 同容器化技術成功嘅關鍵。
AboutOCIProfessional illustrations
構建參數進階設定
好啦，講完基本嘢，係時候同大家深入啲，玩下Docker Build嘅構建參數進階設定。好多師兄可能仲係停留喺docker build -t myimage .就算，其實Docker Engine同BuildKit背後有大量參數可以微調，直接影響你鏡像構建嘅效率、安全性同埋最終容器鏡像嘅質素。呢啲進階設定，尤其喺DevOps流程同CI/CD integration入面，真係可以幫你慳返唔少時間同避免踩坑。
首先一定要提嘅係BuildKit，佢基本上已經成為現代Docker Desktop同Docker Engine嘅默認構建驅動。用咗BuildKit，你喺構建命令上就可以解鎖好多新玩法。例如，你可以用--build-arg嚟傳遞構建參數，呢個唔單止可以用嚟設定環境變數，仲可以配合Dockerfile入面嘅ARG指令，做條件化構建。譬如你個應用要針對唔同環境（例如測試同生產），你可以透過構建參數嚟決定安裝邊套軟件包，或者從邊個Docker Hub倉庫拉取基礎鏡像。不過要小心，--build-arg傳入嘅值如果係敏感資料，可能會留喺鏡像歷史度，所以密碼、API Key呢啲嘢，強烈建議用Docker嘅Secret功能或者用多階段構建嚟處理。
跟住落嚟，緩存管理係提升構建速度嘅關鍵。默認情況下，Docker會利用分層構建快取，但係有時你明明更新咗個檔案，佢都仲用緊舊緩存，點算？呢個時候就要識得用--no-cache嚟強制重新構建，或者更精準啲，用--target喺多階段構建入面，只重建某個特定階段之後嘅步驟。另外，BuildKit仲支援將緩存導出工件到本地或者遠端倉庫，呢個對於團隊協作或者CI/CD pipeline嚟講好有用，大家可以共享緩存層，大大加快構建速度。你可以用--cache-from同--cache-to呢對參數嚟控制，例如將緩存推送到一個Registry，等其他人構建時可以拉過嚟用，唔使由零開始。
安全掃描同鏡像優化呢部分，Docker Scout同Docker Hardened Images嘅整合已經成為標準動作。而家喺構建時，你可以直接加入相關參數，等構建完成後自動進行漏洞掃描。雖然詳細設定可能喺CI流程或者Docker Desktop圖形介面做多啲，但喺命令層面，你都可以透過策略去控制。同時，利用多階段構建，你可以好輕易咁將最終鏡像瘦身。例如你構建一個Java應用，第一階段可以用完整嘅CentOS或者有齊SDK嘅鏡像去編譯同打包你個WAR檔，然後第二階段只係用一個淨係裝咗Tomcat嘅精簡基礎鏡像，將第一階段生成嘅工件COPY過去。咁樣出嚟嘅最終容器，唔會包含編譯工具同中間文件，細好多之餘，受攻擊面亦都細咗，更加符合容器化安全最佳實踐。
最後講下啲實用但易被忽略嘅構建選項。例如--output (或者-o) 參數，佢唔係用嚟產生一個傳統鏡像，而係可以將構建結果直接導出工件到你指定嘅目錄，可能係一個二進制文件、一個壓縮包，或者一堆依賴庫。呢個功能對於構建非容器化嘅軟件交付物，或者同其他編排工具整合時好方便。另外，--platform參數可以讓你喺AMD64嘅機器上，構建出ARM64架構嘅鏡像，對於要支援多平台嘅團隊係必備技能。仲有--label，可以幫你嘅鏡像加上一大堆元數據標籤，例如版本、維護者、構建日期等，呢啲標籤對於後期用Docker Compose編排或者用MCP Toolkit之類嘅工具去管理鏡像資產，會非常有幫助。
總而言之，掌握呢啲構建參數進階設定，就等於將你嘅Docker Build過程從「自動波」升級到「手動波」，你可以更精細地控制容器化技術嘅每一個環節，從軟件打包、安全掃描到緩存管理同多平台支援。記住，一個優化得好嘅構建流程，唔單止係為咗快，更重要係為咗產出更安全、更標準化、更易於管理嘅OCI兼容鏡像，呢啲先係現代DevOps文化入面，持續交付嘅堅實基礎。
AboutDevOpsProfessional illustrations
驗證與測試鏡像
好啦，講到鏡像構建咗出嚟，唔係話 docker build 完就大功告成㗎！「驗證與測試鏡像」呢一步，其實係確保你打包出嚟嘅容器鏡像安全、穩定同埋符合預期嘅關鍵動作，尤其喺2026年嘅 DevOps 環境，更加係不可或缺。
點樣驗證先叫全面？首先，最基本就係用 Docker 本身嘅命令去檢查鏡像係咪完整。例如，用 docker images 睇下個鏡像嘅大小、標籤係咪正確，有時 BuildKit 嘅緩存管理做得唔好，或者構建上下文有殘留檔案，都會令到個鏡像無端端大咗。跟住，可以 docker run -it 你個鏡像名 /bin/bash（如果係 Linux 基礎鏡像）入去行個圈，睇下入面嘅檔案結構、軟件版本（例如你個 Java 或者 Tomcat 係咪指定版本）、環境變數有冇 set 錯。呢個手動檢查對於用多階段構建（multi-stage builds）出嚟嘅輕量鏡像特別有用，可以確認係咪真係只係抄咗需要嘅 artifact（例如編譯好嘅 JAR 包）去最後階段，而冇唔小心留低咗成個開發工具鏈，搞到個鏡像臃腫不堪。
不過，齋靠人手驗證當然唔夠快同埋唔夠系統化啦。所以，安全掃描 呢個環節就一定要做。Docker 自家嘅 Docker Scout 喺2026年已經整合得更加深入，你喺用 Docker Desktop 或者直接喺 CI/CD pipeline 入面，都可以好方便咁對構建好嘅鏡像進行漏洞掃描。佢會同 Docker Hardened Images 呢類安全基準做比對，列出所有已知嘅 CVE 漏洞，話你知邊個層（Layer）嘅邊個套件出事。例如你個鏡像用咗某個舊版 CentOS 流出來嘅基礎鏡像，Scout 就會即刻標紅。咁你就可以決定係要更新基礎鏡像，定係打 patch。呢種將安全測試左移（Shift-Left）到構建後即時做嘅做法，好過等到部署上生產環境先至發現問題。
講到自動化測試，就不得不提將鏡像測試整合到你嘅 CI/CD 流程入面。例如，你可以寫一啲簡單嘅測試腳本，用 Docker Engine 自動拉起你剛構建嘅鏡像，執行一啲健康檢查或者冒煙測試。譬如，如果你構建嘅係一個 Web 應用鏡像，可以喺容器啟動後，用 curl 或者專門嘅測試工具去訪問內部端口，睇下個應用（例如 Tomcat 上面個 app）有冇成功啟動同埋返回預期嘅回應。Docker Compose 喺呢度可以幫到手，特別係當你個應用涉及多個容器服務嘅時候，你可以寫一個 docker-compose.test.yml 專門用嚟做整合測試，模擬真實環境去驗證鏡像之間嘅協同工作係咪正常。
另外，鏡像嘅內容驗證都好重要。除咗安全漏洞，仲要確保冇敏感資訊（例如私鑰、密碼）唔小心跟咗構建上下文一齊打包入鏡像。你可以用一啲靜態分析工具，或者 MCP Toolkit 入面嘅相關組件，去掃描鏡像層，檢查有冇出現不應該存在嘅檔案模式。同時，亦要驗證鏡像是否符合 OCI（Open Container Initiative）標準，確保佢可以喺不同嘅容器運行時之間順利移植，唔會因為某啲 Docker Engine 特有嘅構建選項而令到個鏡像喺其他平台行唔到。
最後，仲有一個好實際嘅步驟：就係將測試用嘅鏡像推上一個臨時嘅倉庫（例如你私人嘅 Docker Hub 空間或者公司內部倉庫）做最後驗收。咁做可以模擬真實嘅拉取（Pull）同部署過程，有時喺本地構建同測試冇問題，但係經過網絡推送、再喺另一部乾淨嘅主機上拉取運行時，可能會因為網絡或者緩存問題而出錯。完成所有驗證同測試之後，先至打上正式版本標籤（例如 :v1.0-production）推送到正式倉庫。記住，整個驗證與測試過程嘅目標，係要建立對容器鏡像質量嘅信心，確保每一次 Docker Build 出來嘅成果，都係一個可以隨時、隨地、安全可靠地交付去任何環境嘅軟件包，真正做到容器化技術所承諾嘅「一次構建，處處運行」。
AboutCentOSProfessional illustrations
疑難排解常見錯誤
好啦，各位開發同 DevOps 嘅朋友，講到 Docker Build，無論你係用緊 Docker Desktop 定係命令行，實試過遇到一啲古靈精怪嘅錯誤，搞到個 鏡像構建 卡住咗。呢個段落就同大家深入傾下點樣疑難排解常見錯誤，特別係 2026 年嘅今日，工具同生態又有啲唔同，我哋要識得用新方法去拆解。
首先，最常見又最蝦人嘅問題，肯定係 構建上下文 (Build Context) 過大導致 build 極都唔完，或者成個 Docker daemon 都 hang 埋。好多新手會成個 project 根目錄就咁做 context，入面可能有幾 GB 嘅 node_modules、log 檔、甚至 .git 歷史，令到 Docker Engine 喺開始執行 Dockerfile 指令前，已經要花大量時間同資源去打包同傳送呢啲檔案。解決方法好直接：整一個細緻嘅 .dockerignore 檔案，當係 Docker 版嘅 .gitignore，明確忽略唔需要放入 容器鏡像 嘅檔案同目錄，例如測試數據、暫存檔、版本控制資料夾。另外，亦可以考慮將個 Dockerfile 搬去一個乾淨啲嘅子目錄，減少 context 嘅範圍。記住，構建命令 入面個 “.” 就係指構建上下文，一定要諗清楚入面有咩。
跟住落嚟，講下 Dockerfile 語法同指令引起嘅錯誤。例如 RUN 指令太長一串，又或者用錯 shell 格式導致層層疊加，令到個鏡像大得無謂。2026 年嘅最佳實踐，強烈推薦用 multi-stage builds (多階段構建) 去解決呢個問題。你可以喺第一個階段用完整嘅 CentOS 或者有齊 Java SDK 嘅基礎鏡像去編譯你嘅應用（例如打包個 WAR 檔比 Tomcat），然後喺第二個階段，換成一個輕量級嘅 runtime 鏡像，只係將第一階段編譯好嘅成品 COPY 過去。咁樣出嚟嘅最終鏡像會細好多，安全性亦高啲，因為唔包含編譯時用嘅工具同中間檔案。另外，記得善用 構建參數 (ARG) 同 緩存管理，將最少變動嘅指令（例如安裝系統套件）放喺 Dockerfile 較前位置，而將成日變嘅源碼 COPY 同構建步驟放最後，咁就可以充分利用 build caching，加快之後重建嘅速度。
另一個頭痛位係網絡問題，特別係構建過程中需要從外網下載套件（例如 apt-get update、npm install、或者從 Docker Hub pull 基礎鏡像）。如果公司有防火牆或者用緊內部鏡像倉庫，就要確保 Docker Engine 嘅代理設定（proxy configuration）正確，又或者將 Docker 嘅 registry mirror 設定指向內部可信嘅源。呢啲設定喺 Docker Desktop 嘅設定介面可以好容易搵到，而喺 Linux 上就要改 /etc/docker/daemon.json 檔案。如果 build 到一半因為網絡超時失敗，除咗檢查網絡，亦可以考慮將一啲大型嘅依賴預先下載好，放入構建上下文，用 COPY 指令代替 RUN 指令去線上獲取。
安全性掃描同政策合規引起嘅 build 失敗，喺近年越嚟越普遍。好彩而家 Docker 生態有 Docker Scout 呢類工具整合咗落 Docker Build 流程度。當你構建鏡像時，佢會自動對每一層進行 security scanning，如果發現用緊嘅基礎鏡像或者安裝嘅套件有嚴重漏洞（CVE），個 build 過程可能會被設定為失敗，強制你更新。遇到呢類錯誤，唔好就咁閂咗個掃描功能，而係應該根據報告去升級基礎鏡像嘅版本（例如由一個舊版 Java 換成官方提供嘅更新版本），或者改用 Docker Hardened Images 呢類經過強化同安全審計嘅鏡像。呢個係現代 DevOps 同 CI/CD integration 裡面非常重要嘅一環。
最後，不得不提 BuildKit 呢個新一代嘅構建引擎。由 2026 年嘅角度睇，BuildKit 已經係默認選項，佢速度快好多，功能亦強大，例如支援 export artifacts（將構建中間產物導出到本地，而唔一定整成鏡像），同更靈活嘅 構建驅動 (build drivers)。但有時由舊式引擎轉過去，或者喺某啲 CI/CD 環境設定不當，都會出錯。如果遇到一啲莫名奇妙的錯誤，例如 “failed to solve with frontend dockerfile.v0”，可以嘗試明確設定使用 BuildKit：喺執行 docker build 命令前，設定環境變數 DOCKER_BUILDKIT=1。另外，BuildKit 嘅緩存機制更高級，但如果你需要徹底清除緩存嚟解決一些依賴問題，就要用 docker builder prune 命令，而唔係普通嘅 docker system prune。
總而言之，Docker Build 嘅疑難排解離不開幾個核心：理解構建上下文嘅範圍、優化 Dockerfile 指令同利用多階段構建、處理好網絡同安全策略、以及熟識新工具如 BuildKit 同 Docker Scout 嘅特性。當你將呢啲概念融入日常嘅軟件打包同容器化流程，自然可以大大減少構建失敗，令你嘅鏡像構建過程更加順暢同可靠。
AboutJavaProfessional illustrations
實戰案例完整教學
好，而家就等我哋一齊嚟睇個實戰案例完整教學，由零開始，用一個貼近真實 DevOps 工作流嘅例子，完整行一次 Docker Build 嘅過程。我會用一個經典組合做示範：喺 CentOS 基礎鏡像上面，部署一個 Java 應用，並且用 Tomcat 嚟運行。呢個案例會涵蓋晒從編寫 Dockerfile、利用 BuildKit 嘅進階功能、到最後安全掃描同推送嘅完整步驟，等你明白整個 容器鏡像構建 嘅生命週期。
首先，我哋要設定好個 構建上下文 同埋 Dockerfile。假設我哋有個簡單嘅 Java Web Application (一個 WAR 檔)，需要放喺 Tomcat 嘅 webapps 目錄入面。為咗提升最終鏡像嘅安全性同減細體積，我會採用 multi-stage builds 呢個強力技巧。第一階段，我哋可以用一個完整嘅 Maven 同 JDK 鏡像嚟編譯同打包個應用；第二階段，先至用一個精簡嘅 CentOS 加上 Tomcat 嘅環境，只係將第一階段打包好嘅 WAR 檔複製過去。咁樣做，最終生成嘅容器鏡像就唔會包含編譯工具同埋一堆唔需要嘅中介文件，大大減細體積，亦都減少咗攻擊面，呢個正正係現代 軟件打包 同 容器化 嘅最佳實踐。
跟住落嚟，我哋要善用 BuildKit (即係新一代默認嘅構建驅動) 嘅威力。喺執行 docker build 命令嗰陣，我哋可以透過 構建參數 嚟做更多控制。例如，我哋可以設定 build-time 嘅變數，好似應用版本號。另外，BuildKit 嘅構建緩存管理更加智能，佢可以精準到只係重建有改動嘅層，對於依賴好多層嘅鏡像嚟講，構建速度可以快好多。我哋亦都可以利用佢嘅 export artifacts 功能，喺構建過程中將某啲階段生成嘅文件 (例如測試報告) 導出到本地，方便整合到 CI/CD 流程入面。記住，要完全發揮 BuildKit 效能，可能喺 Dockerfile 開頭就要用特定語法聲明，同埋確保你嘅 Docker Engine 或者 Docker Desktop 已經啟用咗佢。
構建命令本身都有好多構建選項要留意。例如，點樣打鏡像標籤先至符合團隊規範？通常會包含應用名、版本號同埋構建環境 (例如 dev, prod)。我哋可以用 -t 參數嚟打多個標籤。另外，為咗避免緩存干擾，有時我哋需要 --no-cache 嚟強制重新構建；又或者用 --pull 確保每次都拉取最新嘅基礎鏡像。對於呢個 Java Tomcat 案例，我哋嘅完整構建命令可能係一連串動作，由 build、到打 tag、再到測試。
鏡像構建好之後，唔好急住推上 Docker Hub 或者私倉。安全檢查係必不可少嘅一步。呢度就要提到 Docker Scout 呢個強大工具 (以前可能叫其他名，但到2026年呢個已經係主流)。佢可以對你剛建好嘅鏡像進行深度安全掃描，檢查入面嘅軟件套件有冇已知嘅漏洞 (CVE)，並且同 Docker Hardened Images 嘅基準做比對，畀出改善建議。你可能會發現，你從官方倉庫拉落嚟嘅某個基礎鏡像版本，其實有高風險漏洞，咁你就要考慮升級或者改用其他更安全嘅基礎鏡像。呢個步驟對於合規同埋保障生產環境安全至關重要。
最後，我哋可以將安全掃描合格嘅鏡像推送到倉庫。如果呢個應用只係一個更大系統嘅一部分，我哋仲需要用到 Docker Compose 呢類編排工具，去定義點樣同數據庫、緩存服務等其他容器一齊協作運行。喺整個 CI/CD 流程入面，以上所有步驟——編寫 Dockerfile、用 BuildKit 構建、用 Scout 掃描——都可以自動化，成為流水線嘅一部分。另外，提多樣嘢，而家好多先進工具鏈，好似 MCP Toolkit 或者圍繞 OCI (Open Container Initiative) 標準嘅生態工具，都可以同 Docker 工具鏈無縫整合，用嚟處理更複雜嘅軟件打包同部署場景。總而言之，一個完整嘅實戰案例，唔單止係寫幾行 Dockerfile 咁簡單，由開發、構建、安全到部署，每一個環節嘅選項同最佳實踐，都值得我哋深入理解同埋應用。