在當今快速變遷的軟體開發世界中，效率與自動化是成功的關鍵。傳統的Docker映像檔建構通常需要安裝Docker守護程序（Daemon），這過程在CI/CD管道中常顯得繁瑣且限制多，特別是需要靈活和隔離的情境下。本文探討了一些替代方法，消除了對Docker守護程序甚至Dockerfile的需求，簡化了映像檔建構的過程。我們將深入探討如Buildpack和Kaniko等工具，並比較它們的能力與需求，展示如何利用這些工具來簡化CI/CD工作流程，最終提升開發生產力。
簡介
在不斷發展的技術世界中，對於軟體開發人員來說，提升效率與自動化程度是一項關鍵挑戰。傳統建構Docker映像檔的方式需倚賴Docker-daemon，然而，這樣做會增加在CI/CD管道中執行的難度，因為需要特殊權限運行Docker。在本文，我們將介紹兩種解決方案：Buildpack和Kaniko，它們皆能顯著簡化這一過程，為開發團隊提供極具價值的工具。
無Daemon建構
建構Docker映像檔通常必須在你的機器上安裝Docker Daemon，這樣才能將專案轉化為Docker映像。然而，對於某些CI管道情境來說，提供Daemon是不易甚至是不可能的，因為Docker需要以privileged使用者身份運行在Linux機器上，這可能減少在隔離環境中建構映像檔的靈活性。項目如Buildpack和Kaniko試圖解決這個問題，降低Docker映像建構的難度。
無Dockerfile建構
當你想為專案建構Docker映像檔時，通常需要為每個專案撰寫Dockerfile。然而，如果有許多微服務專案，每個專案撰寫Dockerfile繁瑣且耗時。相反地，你可以使用Buildpack，它讓你無需自行撰寫Dockerfile。Buildpack會自動檢測專案的程式語言（如Java、JavaScript、Go、Ruby等）及所需的建構工具，然後自動生成構建指令並建構映像。如果想了解更多Buildpack的工作原理，可以參閱我的其他文章。
Buildpack與Kaniko的比較
工具/需求 │ Dockerfile │ Docker-daemon
─────────────┼────────────┼───────────────
Docker BuildKit │ 是 │ 是
─────────────┼────────────┼───────────────
Kaniko │ 是 │ 否
─────────────┼────────────┼───────────────
Buildpack │ 否 │ 否
如上表所示，Buildpack與Kaniko、Docker Buildkit進行比較。這是一個簡單的工具需求比較。可以看到，Buildpack在建構Docker映像檔時，無需Dockerfile與Docker Daemon，而Kaniko至少需要一個Dockerfile。Docker Buildkit為建構Docker映像檔的最老方法，需同時具備Dockerfile與Docker Daemon。
使用Buildpack建構映像
可以使用Buildpack建構映像檔而無需撰寫Dockerfile或使用Docker Daemon，這是CI/CD管道中常見的問題。假設我想為如下的簡單Spring Boot應用專案建構Docker映像，這個專案沒有Dockerfile。
mahdi / test-buildpack · GitLab
在這個專案中，我使用了GitLab作為建構管道的工具。以下是用於建構Docker映像檔的管道代碼：
``` variables: IMAGE_URL: mlkmhd/test-buildpack BP_JVM_VERSION: 17
stages: - build
build_image: stage: build image: paketobuildpacks/builder:full script: | set -xe mkdir ~/.docker cp ${DOCKER_AUTH_CONFIG} ~/.docker/config.json
/cnb/lifecycle/creator \
-app=${PWD} \
-uid=1000 \
-gid=1000 \
-platform=/platform \
-process-type=web \
-skip-restore=true \
-previous-image=${IMAGE_URL} \
${IMAGE_URL}
```
在上述管道中，我設置了一個名為
build_image
的階段，它使用
paketobuildpacks/builder
映像來建構這專案的Docker映像檔。以下是管道執行的輸出：
++ /cnb/lifecycle/creator -app=/builds/mallakimahdi/test-buildpack -uid=1000 -gid=1000 -platform=/platform -process-type=web -skip-restore=true -previous-image=mlkmhd/test-buildpack mlkmhd/test-buildpack
...
===> DETECTING
10 of 26 buildpacks participating
...
===> EXPORTING
...
Saving mlkmhd/test-buildpack...
如上輸出所示，Buildpack自動檢測了我專案的程式語言及其建構工具
gradle
，並成功建構出成像檔。
例子故事
-
小明的微服務專案 ：小明在公司負責一個大型微服務專案，需同時管理數十個服務的Docker化。他利用Buildpack大大簡化了每次版本更新時的Docker映像建構過程，只需簡單設定，無需重複撰寫繁多的Dockerfiles。
-
貼心的開源專案 ：某開源社群採用Kaniko在其CI過程中實現無Daemon的建構，驟降了資源需求，在GitHub Actions上執行更加流暢，使得開發者能夠更加專注於創意與功能。
-
初學者的Docker之旅 ：初學者阿文決心學習Docker技術，卻被Dockerfile的寫作搞得頭大。不過經過朋友的介紹，嘗試了Buildpack後順利完成了小型專案的容器化，大大增加了他的學習信心。
結論
總結來說，像Buildpack和Kaniko這樣的Docker映像建構工具的演進為尋求最佳化CI/CD管道的開發者提供了顯著的優勢。藉由消除對Docker Daemon及Dockerfile的需求，這些工具不僅簡化了建構過程，還增強了在隔離環境中的安全性與靈活性。自動檢測專案的依賴關係及建構配置的能力流暢了工作流程，使得團隊能更多地專注於編碼，而非基礎設施管理。如本文所示，使用這些現代工具，可以促成更有效、更具延展性及更易維護的軟體開發實踐。
希望這些資訊對你有所助益！
