雲原生打包工具-Buildpacks

未来代码研究所發表於2024-06-17
UI

雲原生正在吞併軟體世界，容器改變了傳統的應用開發模式，如今研發人員不僅要構建應用，還要使用 Dockerfile 來完成應用的容器化，將應用及其依賴關係打包，從而獲得更可靠的產品，提高研發效率。

隨著專案的迭代，達到一定的規模後，就需要運維團隊和研發團隊之間相互協作。運維團隊的視角與研發團隊不同，他們對映象的需求是安全和標準化。比如：

不同的應用應該選擇哪種基礎映象？
應用的依賴有哪些版本？
應用需要暴露的埠有哪些？
為了最佳化運維效率，提高應用安全性，研發人員需要不斷更新 Dockerfile 來實現上述目標。同時運維團隊也會干預映象的構建，如果基礎映象中有 CVE 被修復了，運維團隊就需要更新 Dockerfile，使用較新版本的基礎映象。總之，運維與研發都需要干預 Dockerfile，無法實現解耦。

為了解決這一系列的問題，湧現出了更加優秀的產品來構建映象，其中就包括 Cloud Native Buildpacks (СNB)。CNB 基於模組化提供了一種更加快速、安全、可靠的方式來構建符合 OCI 規範的映象，實現了研發與運維團隊之間的解耦。

Buildpacks是一款對標Docker的映象打包工具，雖然在CNCF中作為核心專案，但在目前的主流開發場景中用到的並不多。

什麼是Buildpacks

Buildpacks簡介

Buildpack位於CNCF全景圖的應用定義和映象構建這一層，可以看出這個東西是用來構建映象的

Buildpacks 是一個專案，最早由 Heroku 在 2011 年發起，被以 Cloud Foundry 為代表的 PaaS 平臺廣泛採用。Buildpacks 的目標是實現統一的應用打包生態系統，支援廣泛的程式語言，支援各種 CI/CD 工具，支援各種擴充套件外掛。

在 2018 年 1 月，Pivotal 和 Heroku 發起了一個專案 Cloud Native Buildpacks (簡稱 CNB)，並在同年十月份加入 CNCF。CNB 提供了一種更加快速、安全、可靠的方式來構建符合 OCI 規範的映象，實現了研發與運維團隊之間的解耦。

總的來說，Buildpacks 提供了一種高階別的抽象，使得開發者可以專注於程式碼邏輯，而不需要關心應用的構建和部署的細節。這使得 Buildpacks 成為了構建和部署應用的強大工具。

舉個例子：當我們構建docker映象時，往往需要編寫一個dockerfile，指定使用的基礎映象和一些引數。如果是構建springboot的映象時，有時候還需要配置jvm引數，這樣還是太麻煩了。如果使用buildpacks的話，以上的步驟就可以減免，buildpacks會自動幫你選擇最適合的基礎映象和引數給你構建最佳的映象，同時還可以自動修復映象中存在的安全問題，並且不需要dockerfile。

更多就不說了，可以自行去官網學習：https://buildpacks.io/

Buildpacks的優點

  • 不需要寫 Dockerfile
  • 打包成映象只需要一行命令
  • 支援多語言
  • 可以把注意力集中在程式碼邏輯上
  • 容器映象的安全性由 builder 處理
  • 透過rebase可以快速增量更新映象

Buildpacks適合哪些人

Cloud Native Buildpacks 非常適合需要頻繁打包應用的場景, 而且應用的種類比較多。

aPaaS 平臺
aPaaS 是提供執行時的平臺, 經常需要部署各類應用。使用 Cloud Native Buildpacks 能規範打包流程, 快速將原始碼轉換為映象。

FaaS 平臺
FaaS 平臺提供函式的執行環境。在以容器為核心的基礎設施上, FaaS 將使用者程式碼打包為映象, 再建立容器執行。而 Cloud Native Buildpacks 既能探測使用者程式碼的程式語言、框架, 還能快速編譯成 OCI 映象, 正是 FaaS 之所需。Google Cloud Platform 的 FaaS 採用的就是 Buildpacks。

開發者
並不是每個開發者都適合使用 Cloud Native Buildpacks, 學習和維護也需要成本。如果你有很多應用需要維護和釋出, 那麼 Cloud Native Buildpacks 將拯救你, 起碼可以少寫很多 Dockerfile。

有哪些開源的buildpacks

其實現在有很多開源的 buildpack 可以用，沒有特定定製的情況下無需自己手動編寫。比如下面的幾個大廠開源並維護的 Buildpacks。

  • Heroku Buildpacks[https://devcenter.heroku.com/articles/buildpacks#using-a-third-party-buildpack]

  • Google Buildpacks[https://cloud.google.com/docs/buildpacks?hl=zh-cn]

  • Paketo[https://paketo.io/]（一般常用這個廠商的，聽說是spring的親兒子）
    和其他工具對比如下：

Buildpacks的使用

安裝

前提：你的電腦需要有docker，不支援其他容器

docker安裝不羅嗦，看官網：https://docker.p2hp.com/get-started/index.html

windows

winget install buildpacks.pack

Linux/Mac OS

我沒有蘋果電腦，安裝清看這裡：https://buildpacks.io/docs/tools/pack/

使用方法（入門）

pack-cli
以我的cloud-events-demo為例，這個應用是基於springboot3.2.1和java21來開發的
1-顯示建議的builders

pack suggest-builders


2-構建映象
pack cli會自動幫我們構建映象，不需要dockerfile

pack build images.midea.com/cloud-enents-demo:latest --builder paketobuildpacks/builder-jammy-base


有趣的事情發生了，cloud-events-demo是使用java21的，但是它自動給我推薦的java是17的版本，顯然還不夠智慧

不出意外的話，應該是出了意外，使用java 17無法構建java21的專案

指定java 21映象，可以看到上圖是透過變數BP_JVM_VERSION來指定JDK版本的

pack build images.midea.com/cloud-enents-demo:latest --builder paketobuildpacks/builder-jammy-base --env BP_JVM_VERSION=21


可以看到真的使用java21來進行映象構建了，我們先等待它構建完成看看

映象構建完成了，awesome,先看看打出來的映象大小以及裡面有什麼東西

讓我們進入容器內看看buildpacks幫我們配置的jvm引數

spring boot的maven外掛

<plugin>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-maven-plugin</artifactId>
 <executions>
<execution>
 <goals>
<goal>build-image-no-fork</goal>
 </goals>
  </execution>
</executions>
</plugin>

參考

Modern Build Systems for Containers: https://fosdem.org/2024/events/attachments/fosdem-2024-3398-modern-build-systems-for-containers/slides/22454/Modern_Build_Systems_for_Containers_gR4dSaa.pdf
Safer Image Builds with Cloud Native Buildpacks and Wolfi: https://thenewstack.io/safer-image-builds-with-cloud-native-buildpacks-and-wolfi/

相關文章