官方下一代Docker鏡像構建神器 -- BuildKit

cover.png

BuildKit是Docker官方社區推出的下一代鏡像構建神器--能夠更加快速,有效,安全地構建docker 鏡像。Docker v18.06已經集成了該組件。BuildKit可用於多種導出格式(例如OCI或Docker)以及前端支持(Dockerfile),並提供高效緩存和運行並行構建操做等功能。BuildKit僅須要容器運行時就能執行,當前受支持的運行時包括containerd和runc。前端

構建步驟優化

Docker提供的原始構建最使人沮喪的問題之一是Dockerfile指令執行構建步驟的順序性。在引入多階段構建以後,能夠將構建步驟分組爲單獨的邏輯構建任務在同一個Dockerfile中。linux

有時,這些構建階段是彼此徹底獨立的,這意味着它們能夠並行執行-或根本不須要執行。遺憾的是,傳統的Docker鏡像構建沒法知足這種靈活性。這意味着構建時間一般會比絕對必要的時間更長。git

相比之下,BuildKit會建立一個構建步驟之間的依賴關係圖,並使用該圖來肯定能夠忽略構建的哪些元素;能夠並行執行的元素;須要順序執行的元素。這能夠更有效地執行構建,這對開發人員來講頗有價值,由於他們能夠迭代其應用程序的鏡像構建。github

高效靈活的緩存

雖然在舊版Docker鏡像構建中緩存構建步驟很是有用,但效率卻不如預期。做爲對構建後端的重寫,BuildKit在此方面進行了改進,並提供了更快,更準確的緩存機制。使用爲構建生成的依賴關係圖,而且基於指令定義和構建步驟內容。docker

BuildKit提供的另外一個巨大好處是以構建緩存導入和導出的形式出現,正如Kaniko和Makisu容許將構建緩存推送到遠程註冊表同樣,BuildKit也是如此,可是BuildKit使您能夠靈活地將緩存嵌入到內部註冊表中。鏡像(內聯)並將它們放在一塊兒(雖然不是每一個註冊表都支持),或者將它們分開導入。也能夠將緩存導出到本地目錄以供之後使用。windows

當從頭開始創建構建環境而沒有任何先前的構建歷史時,導入構建緩存的能力就發揮了本身的做用:導入「預熱」緩存,對於臨時CI/CD環境特別有用。後端

工件

當使用舊版Docker鏡像構建器構建鏡像時,將生成的鏡像添加到Docker守護進程管理的本地鏡像的緩存中。須要單獨的docker push將該鏡像上載到遠程容器鏡像註冊表。新的工件構建工具經過容許您在構建調用時指定鏡像推送來加強體驗,BuildKit也不例外,它還容許以幾種不一樣格式輸出鏡像;本地目錄中的文件,本地tarball,一個本地OCI鏡像tarball,一個Docker鏡像tarball,一個存儲在本地緩存中的Docker鏡像以及一個推送到註冊表的Docker鏡像,有不少格式!緩存

擴展語法

對於docker構建體驗而言,常常重複出現的衆多功能請求之一就是安全處理鏡像構建過程當中所需的機密信息。Moby項目抵制了這一要求不少年了,可是,藉助BuildKit靈活的「前端」定義,爲Buildkit提供了一個實驗性前端,它擴展了Dockerfile語法。擴展後的語法爲RUN Dockerfile指令提供了有用的補充,其中包括安全性功能。安全

RUN --mount=type=secret,id=top-secret-passwd my_command

引用實驗性前端的Dockerfile能夠爲RUN指令臨時掛載祕鑰。使用 --secret 標誌將祕鑰提供給構建,用於docker build。使用ssh mount類型能夠轉發SSH代理鏈接以實現安全SSH身份驗證。框架

BuildKit使用場景

BuildKit還有許多其餘功能,能夠極大地改善構建容器鏡像的技巧。若是它是適用於許多不一樣環境的通用工具,那麼如何使用它呢?

根據您工做的環境,這個問題的答案是多種多樣的。讓咱們來看看。

Docker

儘管目前BuildKit不是Docker的默認構建工具,可是徹底能夠考慮將其做爲Docker(v18.09 +)的首選構建工具。固然目前在windows平臺是不支持的。

臨時方案是設置環境變量DOCKER_BUILDKIT=1

若是是想永久生效的話,將"features":{"buildkit": true} 添加到docker守護進程的配置文件中。

在此配置中,因爲Docker守護程序中的當前限制,Docker並未充分展示BuildKit的所有功能。所以,Docker客戶端CLI已擴展爲提供插件框架,該框架容許使用插件擴展提供了可用的CLI功能。一個名爲Buildx的實驗性插件會繞過守護程序中的舊版構建函數,並使用BuildKit後端進行全部構建,它提供全部熟悉的鏡像構建命令和功能,但經過一些特定於BuildKit的附加功能對其進行了擴充。

BuildKit以及Buildx的都支持多個構建器實例,這是一項重要功能,這實際上意味着能夠共享一個構建器實例場以進行構建;也許是一個項目被分配了一組構建器實例。

$ docker buildx ls  
NAME/NODE DRIVER/ENDPOINT STATUS PLATFORMS  
default * docker  
  default default running linux/amd64, linux/386

默認狀況下,Buildx插件以docker驅動程序爲目標,該驅動程序使用Docker守護程序提供的BuildKit庫具備其固有的侷限性。另外一個驅動程序是docker-container,它能夠透明地在容器內啓動BuildKit以執行構建。 BuildKit中提供的功能CLI:這是不是理想的工做流程,徹底取決於我的或公司的選擇。

Kubernetes

愈來愈多的組織將構建放到Kubernetes當中,一般將容器鏡像構建做爲CI/CD工做流的一部分出如今pod中。在Kubernetes中運行BuildKit實例時,有一個每種部署策略都有其優缺點,每種策略都適合不一樣的目的。

build.jpg

除了使用Docker CLI爲BuildKit啓動面向開發人員的構建以外,構建還能夠經過多種CI/CD工具觸發。使用BuildKit進行的容器鏡像構建能夠做爲Tekton Pipeline Task執行。

結論

本文主要講了BuildKit諸多特性和使用場景。

目前相似的工具很多,如Redhat的Buildah,Google的Kaniko或Docker的BuildKit。

不過BuildKit是官方提供,和docker自己結合比較好。

相關文章
相關標籤/搜索