建體系詳解：Docker、S2I 與自定義構(gòu)建策略實戰(zhàn)指南)
測試云原生質(zhì)量保障【免費下載鏈接】originConformance test suite for OpenShift項目地址https://gitcode.com/gh_mirrors/or/origin點擊查看免費下載本文以 docs/builds.md 為核心脈絡系統(tǒng)講解 OpenShift即 origin 項目中鏡像構(gòu)建 API 的設計動機、三種默認構(gòu)建策略Docker、Source-to-Image、Custom的原理與配置方法并結(jié)合本倉庫的 e2e 測試與真實 YAML/JSON 配置樣例幫助讀者掌握如何通過構(gòu)建 API 讓 OpenShift 成為可調(diào)度、可限制資源、可被第三方 CI 編排的容器鏡像構(gòu)建后端。背景與動機為什么 Kubernetes 需要構(gòu)建能力Kubernetes 本身只負責運行容器它從鏡像倉庫拉取已經(jīng)構(gòu)建好的鏡像再以 Pod 的形式調(diào)度運行。鏡像的構(gòu)建環(huán)節(jié)并不在 Kubernetes 的核心能力范圍內(nèi)——按照原文檔 docs/builds.md 的論述在沒有構(gòu)建支持的情況下系統(tǒng)管理員若想獲得鏡像構(gòu)建能力只能自行挑選一套既有構(gòu)建系統(tǒng)或從零編寫一套并自行解決如何在 Kubernetes 之上或之外部署、維護它。然而大多數(shù)運維人員更希望復用 Kubernetes 的任務調(diào)度能力把構(gòu)建任務作為可調(diào)度的任務塞進現(xiàn)有的資源池中而不是另起爐灶。這正是 OpenShift 構(gòu)建 API 存在的根本理由構(gòu)建 API 讓 OpenShift 成為第三方容器鏡像構(gòu)建系統(tǒng)的可用后端這類系統(tǒng)通常需要資源約束與調(diào)度能力組織可以從既有的持續(xù)集成CI流程中編排 Docker 構(gòu)建形成圍繞容器鏡像的 CI/CD 流水線絕大多數(shù)構(gòu)建任務都具有共同特征一組構(gòu)建輸入、一個必須運行到完成的構(gòu)建過程、構(gòu)建過程日志的捕獲、成功構(gòu)建產(chǎn)物的發(fā)布以及最終的構(gòu)建狀態(tài)Kubernetes 倡導的鏡像驅(qū)動部署image-driven deployment流程也依賴鏡像的持續(xù)可用。原文檔特別強調(diào)兩個設計原則構(gòu)建應利用資源限制機制如 CPU 用量、內(nèi)存用量、構(gòu)建 Pod 執(zhí)行時間上限待 Kubernetes 原生支持后即可生效并且構(gòu)建應當可重復、結(jié)果一致相同的輸入 相同的輸出。典型用戶場景原文檔給出了四類核心場景構(gòu)成了構(gòu)建 API 的驗收視角從源碼 URL 構(gòu)建鏡像并推送至倉庫最終在 OpenShift 中部署從二進制輸入Docker context、產(chǎn)物構(gòu)建鏡像并推送至倉庫作為提供鏡像構(gòu)建服務的廠商把資源分配、調(diào)度、垃圾回收等負擔轉(zhuǎn)嫁給 OpenShift而不是自己解決作為構(gòu)建系統(tǒng)開發(fā)者借助 OpenShift 執(zhí)行構(gòu)建但仍從現(xiàn)有 CI 側(cè)編排以契合組織的 DevOps SOP。兩個示例用例云 IDE 場景Company X一家提供 Docker 化云 IDE 服務的公司需要為客戶托管項目大規(guī)模構(gòu)建鏡像希望獲得一套開箱即用的方案能處理調(diào)度、資源分配與垃圾回收。通過構(gòu)建 APICompany X 可以將構(gòu)建工作交給 OpenShift集中精力解決核心業(yè)務問題。企業(yè) DevOps 場景Company YCompany Y 希望用 OpenShift 構(gòu)建鏡像但其 SOP 強制要求使用第三方 CI 服務器來觸發(fā)構(gòu)建如上游項目構(gòu)建成功后觸發(fā)和推進構(gòu)建CI 中簽收通過后晉升。借助構(gòu)建 APICompany Y 在 CI 服務器中實現(xiàn)編排 OpenShift 構(gòu)建的工作流從而與其組織 SOP 集成。構(gòu)建策略總覽OpenShift 構(gòu)建系統(tǒng)基于構(gòu)建 API 中可選類型type提供可擴展的構(gòu)建策略支持。默認提供三種策略策略類型用途DockerDockerStrategy基于 Docker context / Dockerfile 執(zhí)行docker buildSource / S2ISourceStrategy基于 Source-to-Image 工具將源碼注入基礎鏡像并組裝新鏡像CustomCustomStrategy使用用戶自定義的 builder 鏡像來執(zhí)行構(gòu)建擴展構(gòu)建過程Docker 構(gòu)建策略使用 Docker 策略時用戶可以提供一個 Docker context 的 URL 作為 Docker 構(gòu)建的基礎。工作原理OpenShift 讓構(gòu)建容器直接訪問節(jié)點上的 Docker daemon。構(gòu)建期間會創(chuàng)建一個只含單個容器build container的 Pod節(jié)點上的 Docker socket 以 bind mount 方式掛載進構(gòu)建容器構(gòu)建容器隨后執(zhí)行docker build所有與 Docker 的交互都經(jīng)由節(jié)點的 Docker daemon 完成。優(yōu)勢允許在非特權(quán)容器中執(zhí)行 Docker 構(gòu)建最小化鏡像存儲需求減少所需 Docker daemon 的數(shù)量。劣勢按用戶約束資源變得更困難構(gòu)建期間創(chuàng)建的容器處于 kubelet 管理范圍之外構(gòu)建期間創(chuàng)建的容器進程是遠端 Docker 進程的子進程使容器清理更加困難。原文檔指出這些問題都有可行的緩解路徑該機制被認定為 work in progress。為什么不用 Docker-in-Docker理論上可以用容器內(nèi)嵌套 Docker daemonDocker-in-Docker實現(xiàn)構(gòu)建表面上有誘人優(yōu)勢構(gòu)建進程資源可自然地被限制在用戶可接受范圍內(nèi)cgroups且構(gòu)建期間創(chuàng)建的容器以構(gòu)建容器為父進程、清理簡單。但實踐中存在無法接受的嚴重問題需要特權(quán)容器——這是無法解決的、一票否決的安全問題同時它也抵消了 cgroups 隔離的理論收益因為進程可能逃逸出容器使用 devicemapper 時極易在宿主機上泄漏 loopback 設備與存儲構(gòu)建容器之間難以共享鏡像/層存儲每個 Docker-in-Docker 實例都必須保存構(gòu)建期間下載鏡像的完整獨立副本節(jié)點上的緩存代理至多能減少從遠端倉庫拉取鏡像的次數(shù)無法消除每容器獨立副本的需求。因此Docker-in-Docker 不被視為安全多租戶生產(chǎn)環(huán)境下的可行構(gòu)建策略。S2ISource-to-Image構(gòu)建策略S2I 是一個用于構(gòu)建可復現(xiàn)容器鏡像的工具通過把用戶源碼注入容器鏡像并組裝出新的鏡像產(chǎn)生可直接docker run的即用鏡像。S2I 支持增量構(gòu)建可復用之前下載的依賴、之前構(gòu)建的產(chǎn)物等。從本倉庫的 e2e 測試可以看到 S2I 策略的完整落地驗證test/extended/builds/s2i_incremental.go 驗證了增量 s2i 構(gòu)建連續(xù)兩次構(gòu)建同一 BuildConfig第二次構(gòu)建復用第一次構(gòu)建產(chǎn)物隨后用生成鏡像實例化 Pod 與服務并curl驗證容器內(nèi)保存了上次構(gòu)建的 artifacts響應包含artifacts existtest/extended/builds/s2i_env.go 驗證源碼中的環(huán)境文件.s2i/environment能正確注入應用響應包含successtest/extended/testdata/builds/test-build.yaml 中的sample-build展示了 Source 策略的標準寫法source.type: Git指向https://github.com/openshift/ruby-hello-world.gitstrategy.type: Source并在sourceStrategy.env中注入FOO、BAR、BUILD_LOGLEVEL等環(huán)境變量from指向image-registry.openshift-image-registry.svc:5000/openshift/ruby:3.3-ubi8作為 s2i 基礎鏡像。結(jié)合 CLI 的 S2I 實操路徑來自 test/extended/builds/start.gooc new-app https://github.com/openshift/ruby-hello-world#config從帶分支引用的倉庫創(chuàng)建應用并觸發(fā) s2i 構(gòu)建測試驗證會正確檢出config分支而不是同名目錄oc start-build sample-build --wait啟動構(gòu)建并等待完成配合--commitfffffff等錯誤引用時--wait會檢測到status is Failedoc start-build sample-build -e FOObar -e VARtest覆蓋環(huán)境變量構(gòu)建日志中會同時出現(xiàn)新增變量與 BuildConfig 中繼承的變量如BARtestoc start-build sample-verbose-build --build-loglevel1可覆蓋 BuildConfig 中的BUILD_LOGLEVEL。自定義Custom構(gòu)建策略自定義構(gòu)建策略與 Docker 構(gòu)建策略非常相似區(qū)別在于用戶可以自定義用于執(zhí)行構(gòu)建的 builder 鏡像。Docker 構(gòu)建默認使用openshift/origin-docker-builder鏡像使用自定義 builder 鏡像則可以完全定制構(gòu)建過程。原文檔給出的自定義構(gòu)建策略 JSON 示例strategy: { type: Custom, customStrategy: { image: my-custom-builder-image, exposeDockerSocket: true, env: [ { name: EXPOSE_PORT, value: 8080 } ] } }exposeDockerSocket把宿主機 Docker socket 掛載進 builder 容器允許在其中執(zhí)行docker build與docker push。原文檔特別提示該能力未來可能被管理員限制。env向 builder 容器環(huán)境傳入額外環(huán)境變量。默認注入 builder 容器的環(huán)境變量原文檔明確列出以下默認傳遞的環(huán)境變量變量含義$BUILD當前 Build 的 JSON 表示$OUTPUT_IMAGEBuild 中配置的輸出容器鏡像名$OUTPUT_REGISTRYBuild 中配置的輸出容器鏡像倉庫$SOURCE_URI源代碼倉庫的 URL$SOURCE_REF源代碼倉庫的分支、tag 或 ref$DOCKER_SOCKETDocker socket 的完整路徑倉庫中的 Custom 策略實戰(zhàn)樣例本倉庫 e2e 測試提供了比文檔示例更完整的 Custom 策略 YAML 配置test/extended/testdata/builds/test-custom-build.yamlkind: BuildConfig apiVersion: build.openshift.io/v1 metadata: name: sample-custom-build spec: strategy: type: Custom customStrategy: env: - name: BUILD_LOGLEVEL value: 2 forcePull: true from: kind: ImageStreamTag name: custom-builder-image:latest output: to: kind: ImageStreamTag name: sample-custom:latest可以看到 Custom 策略除env外還支持forcePull強制每次拉取最新 builder 鏡像與from通過 ImageStreamTag 指定 builder 鏡像來源構(gòu)建產(chǎn)物通過output.to寫入名為sample-custom:latest的 ImageStreamTag。配套的 builder 鏡像定義位于 test/extended/testdata/builds/custom-build/Dockerfile它基于registry.redhat.io/rhel8/buildah:latest將待構(gòu)建的 Dockerfile 樣例Dockerfile.sample內(nèi)容為FROM image-registry.openshift-image-registry.svc:5000/openshift/tools:latestRUN touch /tmp/built放入/tmp/input/并將真正的構(gòu)建邏輯腳本build.sh設為 ENTRYPOINT——即builder 鏡像運行時執(zhí)行的就是自定義構(gòu)建邏輯。對應的 e2e 測試見 test/extended/builds/custom_build.go完整演練了自定義構(gòu)建鏈路# 1. 用二進制方式先構(gòu)建出自定義 builder 鏡像 oc new-build --binary --strategydocker --namecustom-builder-image oc start-build custom-builder-image --from-dirtest/extended/testdata/builds/custom-build # 2. 應用 Custom 策略的 BuildConfig 并啟動構(gòu)建 oc create -f test/extended/testdata/builds/test-custom-build.yaml oc start-build sample-custom-build # 3. 等待名為 sample-custom-build-1 的構(gòu)建成功完成構(gòu)建輸入與 CLI 實操從倉庫測試看完整命令鏈原文檔把構(gòu)建輸入列為構(gòu)建任務的公共特征之一。結(jié)合 test/extended/builds/start.go 與 test/extended/testdata/builds/test-build.yaml可梳理出 OpenShift 支持的多種輸入方式與對應命令二進制輸入Binary構(gòu)建對應 BuildConfig 中source.type: Binary的配置例如sample-build-binarysource: type: Binary binary: {} strategy: type: Docker dockerStrategy: from: kind: DockerImage name: image-registry.openshift-image-registry.svc:5000/openshift/ruby:3.3-ubi8oc start-build支持以下二進制輸入形態(tài)命令參數(shù)說明測試驗證點--from-filefile以單個文件作為構(gòu)建輸入也支持 HTTPS URL輸出Uploading file ... as binary input for the build--from-dirdir以目錄Docker context作為輸入輸出Uploading directory ... as binary input for the build--from-reporepo以本地 Git 倉庫作為輸入可配合--commitsha指定提交輸出at commit HEAD--from-archiveurl以遠程歸檔zip作為輸入配合contextDir處理歸檔內(nèi)的頂層目錄輸出Uploading archive from ... as binary input for the build此外構(gòu)建日志中會出現(xiàn)Build complete表示成功若 BuildConfig 無有效輸入oc start-build會報錯has no valid source inputs。Git 源碼輸入與 Dockerfile 輸入Git 源碼輸入source.type: Gitsource.git.uri如sample-build使用https://github.com/openshift/ruby-hello-world.gitDockerfile 輸入source.type: Dockerfilesource.dockerfile內(nèi)聯(lián)內(nèi)容測試 test/extended/builds/dockerfile.go 用oc new-build -D -從 stdin 傳入 Dockerfile 創(chuàng)建構(gòu)建并驗證生成的 BuildConfig 中spec.source.git為空、Dockerfile 內(nèi)容被完整保存最終鏡像的Config.User為 Dockerfile 中聲明的USER 1001還覆蓋了FROM scratch、輸出 tag 推斷ruby:latest、以及非法 Dockerfile 內(nèi)容導致構(gòu)建失敗并在日志中報no such file or directory等場景。構(gòu)建參數(shù)Build Args對于 Docker 策略可在dockerStrategy.buildArgs中預設參數(shù)也可用 CLI 覆蓋dockerStrategy: buildArgs: - name: foofoo value: default測試驗證test/extended/builds/start.go預設的 build arg 會傳入構(gòu)建日志輸出其值defaultoc start-build ... --build-argfoofoobar可覆蓋日志輸出新值bar傳入 Dockerfile 未聲明的 arg如--build-argbarfoo構(gòu)建仍成功但日志出現(xiàn)警告one or more build args were not consumed: [bar]。觸發(fā)與取消構(gòu)建sample-build的觸發(fā)配置示例triggers: - type: ImageChange imageChange: {} - type: Generic generic: secret: mysecret secretReference: name: webhooksecret對應 Generic Webhook 的調(diào)用端點是POST /apis/build.openshift.io/v1/namespaces/ns/buildconfigs/sample-build/webhooks/secret/generic測試驗證了用內(nèi)聯(lián) secretmysecret與引用的 Secretsecretvalue1都能成功觸發(fā)構(gòu)建而錯誤 secretinvalid則不會產(chǎn)生任何構(gòu)建。取消構(gòu)建使用oc cancel-build buildName配合oc start-build --wait時--wait會檢測到status is Cancelled對于因 nodeSelector 無法匹配而無法調(diào)度的構(gòu)建系統(tǒng)會自動取消并在事件中記錄取消原因BuildCancelledEventReason。構(gòu)建的運行模型Pod、調(diào)度與資源限制從構(gòu)建 API 的設計目標與當前實現(xiàn)看每次構(gòu)建都以 Pod 形式承載。以 test/extended/builds/start.go 中的verifyBuildPod為例可以確認構(gòu)建 Pod 的實際形態(tài)構(gòu)建 Pod 名形如buildName-buildPod 會顯式選擇 linux 節(jié)點kubernetes.io/oslinuxnodeSelector源碼克隆通過名為git-clone的 init container 完成出于 CVE-2024-45496.gitconfig 可能被利用執(zhí)行任意命令的考慮該 init container 必須是非特權(quán)、僅保留CHOWN/DAC_OVERRIDE能力、并 drop ALL 其余能力、使用 runtime-default seccomp profile 的加固配置構(gòu)建容器與 Docker daemon 的交互、日志捕獲、產(chǎn)物發(fā)布均由 OpenShift 構(gòu)建控制器協(xié)調(diào)。資源限制方面原文檔強調(diào)構(gòu)建應當能夠限定 CPU、內(nèi)存與 Pod 執(zhí)行時間在倉庫的 BuildConfig 樣例中可以通過resources與nodeSelector字段如sample-build-binary-invalidnodeselector中的nodelabelkey: nodelabelvalue進行配置構(gòu)建系統(tǒng)會根據(jù)這些約束調(diào)度構(gòu)建 Pod。構(gòu)建 API 的定位面向第三方構(gòu)建系統(tǒng)與 CI/CD 編排回到原文檔的核心理念為構(gòu)建提供 API使 OpenShift 成為任意第三方容器鏡像構(gòu)建系統(tǒng)的可行后端。這意味著資源約束與調(diào)度能力由 OpenShift 統(tǒng)一提供第三方系統(tǒng)無需自行解決資源分配、調(diào)度與垃圾回收對應云 IDE 場景組織現(xiàn)有的 CI 流程Jenkins 等可以通過構(gòu)建 API 觸發(fā)、監(jiān)控、晉升構(gòu)建將 OpenShift 構(gòu)建無縫嵌入既有 DevOps SOP對應企業(yè) DevOps 場景構(gòu)建輸出進入 ImageStream/ImageStreamTag如sample-custom:latest為后續(xù)鏡像驅(qū)動部署提供輸入。本倉庫 test/extended/builds/ 下的數(shù)十個 e2e 測試涵蓋構(gòu)建觸發(fā)、Webhook、二進制輸入、增量構(gòu)建、環(huán)境變量、配額 s2i_quota.go、機密注入 secrets.go、構(gòu)建清理 build_pruning.go 等從實踐層面印證了構(gòu)建 API 的完整能力面可作為深入理解構(gòu)建系統(tǒng)行為與邊界條件的參考起點。贊分享測試云原生質(zhì)量保障【免費下載鏈接】originConformance test suite for OpenShift項目地址https://gitcode.com/gh_mirrors/or/origin點擊查看免費下載相關推薦一次配好大麥自動搶票腳本從原理到啟動的完整教程一次配好大麥自動搶票腳本從原理到啟動的完整教程 本文以開源項目 ticket purchase 為例講清這個大麥自動搶票工具怎么用。它解決的事情很明確你只GUI 自動化RPAHandsontable 自定義構(gòu)建Custom Builds完全指南Monorepo 構(gòu)建流程與各包構(gòu)建命令詳解Handsontable 自定義構(gòu)建Custom Builds完全指南Monorepo 構(gòu)建流程與各包構(gòu)建命令詳解 Handsontable 的構(gòu)建流程前端UI組件如何快速構(gòu)建Apache Airflow自定義Docker鏡像完整實戰(zhàn)指南如何快速構(gòu)建Apache Airflow自定義Docker鏡像完整實戰(zhàn)指南 Apache Airflow作為業(yè)界領先的工作流編排平臺其Docker鏡像構(gòu)建是后端任務調(diào)度工作流自動化數(shù)據(jù)編排批處理數(shù)據(jù)工程流程編排上一篇Imba樣式修飾符為什么你需要掌握這3類核心功能下一篇PowerInfer終極指南嵌入式設備上實現(xiàn)快速LLM推理的完整解決方案創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 OpenShift Builds 構(gòu)建體系詳解：Docker、S2I 與自定義構(gòu)建策略實戰(zhàn)指南
測試云原生質(zhì)量保障【免費下載鏈接】originConformance test suite for OpenShift項目地址https://gitcode.com/gh_mirrors/or/origin點擊查看免費下載本文以 docs/builds.md 為核心脈絡系統(tǒng)講解 OpenShift即 origin 項目中鏡像構(gòu)建 API 的設計動機、三種默認構(gòu)建策略Docker、Source-to-Image、Custom的原理與配置方法并結(jié)合本倉庫的 e2e 測試與真實 YAML/JSON 配置樣例幫助讀者掌握如何通過構(gòu)建 API 讓 OpenShift 成為可調(diào)度、可限制資源、可被第三方 CI 編排的容器鏡像構(gòu)建后端。背景與動機為什么 Kubernetes 需要構(gòu)建能力Kubernetes 本身只負責運行容器它從鏡像倉庫拉取已經(jīng)構(gòu)建好的鏡像再以 Pod 的形式調(diào)度運行。鏡像的構(gòu)建環(huán)節(jié)并不在 Kubernetes 的核心能力范圍內(nèi)——按照原文檔 docs/builds.md 的論述在沒有構(gòu)建支持的情況下系統(tǒng)管理員若想獲得鏡像構(gòu)建能力只能自行挑選一套既有構(gòu)建系統(tǒng)或從零編寫一套并自行解決如何在 Kubernetes 之上或之外部署、維護它。然而大多數(shù)運維人員更希望復用 Kubernetes 的任務調(diào)度能力把構(gòu)建任務作為可調(diào)度的任務塞進現(xiàn)有的資源池中而不是另起爐灶。這正是 OpenShift 構(gòu)建 API 存在的根本理由構(gòu)建 API 讓 OpenShift 成為第三方容器鏡像構(gòu)建系統(tǒng)的可用后端這類系統(tǒng)通常需要資源約束與調(diào)度能力組織可以從既有的持續(xù)集成CI流程中編排 Docker 構(gòu)建形成圍繞容器鏡像的 CI/CD 流水線絕大多數(shù)構(gòu)建任務都具有共同特征一組構(gòu)建輸入、一個必須運行到完成的構(gòu)建過程、構(gòu)建過程日志的捕獲、成功構(gòu)建產(chǎn)物的發(fā)布以及最終的構(gòu)建狀態(tài)Kubernetes 倡導的鏡像驅(qū)動部署image-driven deployment流程也依賴鏡像的持續(xù)可用。原文檔特別強調(diào)兩個設計原則構(gòu)建應利用資源限制機制如 CPU 用量、內(nèi)存用量、構(gòu)建 Pod 執(zhí)行時間上限待 Kubernetes 原生支持后即可生效并且構(gòu)建應當可重復、結(jié)果一致相同的輸入 相同的輸出。典型用戶場景原文檔給出了四類核心場景構(gòu)成了構(gòu)建 API 的驗收視角從源碼 URL 構(gòu)建鏡像并推送至倉庫最終在 OpenShift 中部署從二進制輸入Docker context、產(chǎn)物構(gòu)建鏡像并推送至倉庫作為提供鏡像構(gòu)建服務的廠商把資源分配、調(diào)度、垃圾回收等負擔轉(zhuǎn)嫁給 OpenShift而不是自己解決作為構(gòu)建系統(tǒng)開發(fā)者借助 OpenShift 執(zhí)行構(gòu)建但仍從現(xiàn)有 CI 側(cè)編排以契合組織的 DevOps SOP。兩個示例用例云 IDE 場景Company X一家提供 Docker 化云 IDE 服務的公司需要為客戶托管項目大規(guī)模構(gòu)建鏡像希望獲得一套開箱即用的方案能處理調(diào)度、資源分配與垃圾回收。通過構(gòu)建 APICompany X 可以將構(gòu)建工作交給 OpenShift集中精力解決核心業(yè)務問題。企業(yè) DevOps 場景Company YCompany Y 希望用 OpenShift 構(gòu)建鏡像但其 SOP 強制要求使用第三方 CI 服務器來觸發(fā)構(gòu)建如上游項目構(gòu)建成功后觸發(fā)和推進構(gòu)建CI 中簽收通過后晉升。借助構(gòu)建 APICompany Y 在 CI 服務器中實現(xiàn)編排 OpenShift 構(gòu)建的工作流從而與其組織 SOP 集成。構(gòu)建策略總覽OpenShift 構(gòu)建系統(tǒng)基于構(gòu)建 API 中可選類型type提供可擴展的構(gòu)建策略支持。默認提供三種策略策略類型用途DockerDockerStrategy基于 Docker context / Dockerfile 執(zhí)行docker buildSource / S2ISourceStrategy基于 Source-to-Image 工具將源碼注入基礎鏡像并組裝新鏡像CustomCustomStrategy使用用戶自定義的 builder 鏡像來執(zhí)行構(gòu)建擴展構(gòu)建過程Docker 構(gòu)建策略使用 Docker 策略時用戶可以提供一個 Docker context 的 URL 作為 Docker 構(gòu)建的基礎。工作原理OpenShift 讓構(gòu)建容器直接訪問節(jié)點上的 Docker daemon。構(gòu)建期間會創(chuàng)建一個只含單個容器build container的 Pod節(jié)點上的 Docker socket 以 bind mount 方式掛載進構(gòu)建容器構(gòu)建容器隨后執(zhí)行docker build所有與 Docker 的交互都經(jīng)由節(jié)點的 Docker daemon 完成。優(yōu)勢允許在非特權(quán)容器中執(zhí)行 Docker 構(gòu)建最小化鏡像存儲需求減少所需 Docker daemon 的數(shù)量。劣勢按用戶約束資源變得更困難構(gòu)建期間創(chuàng)建的容器處于 kubelet 管理范圍之外構(gòu)建期間創(chuàng)建的容器進程是遠端 Docker 進程的子進程使容器清理更加困難。原文檔指出這些問題都有可行的緩解路徑該機制被認定為 work in progress。為什么不用 Docker-in-Docker理論上可以用容器內(nèi)嵌套 Docker daemonDocker-in-Docker實現(xiàn)構(gòu)建表面上有誘人優(yōu)勢構(gòu)建進程資源可自然地被限制在用戶可接受范圍內(nèi)cgroups且構(gòu)建期間創(chuàng)建的容器以構(gòu)建容器為父進程、清理簡單。但實踐中存在無法接受的嚴重問題需要特權(quán)容器——這是無法解決的、一票否決的安全問題同時它也抵消了 cgroups 隔離的理論收益因為進程可能逃逸出容器使用 devicemapper 時極易在宿主機上泄漏 loopback 設備與存儲構(gòu)建容器之間難以共享鏡像/層存儲每個 Docker-in-Docker 實例都必須保存構(gòu)建期間下載鏡像的完整獨立副本節(jié)點上的緩存代理至多能減少從遠端倉庫拉取鏡像的次數(shù)無法消除每容器獨立副本的需求。因此Docker-in-Docker 不被視為安全多租戶生產(chǎn)環(huán)境下的可行構(gòu)建策略。S2ISource-to-Image構(gòu)建策略S2I 是一個用于構(gòu)建可復現(xiàn)容器鏡像的工具通過把用戶源碼注入容器鏡像并組裝出新的鏡像產(chǎn)生可直接docker run的即用鏡像。S2I 支持增量構(gòu)建可復用之前下載的依賴、之前構(gòu)建的產(chǎn)物等。從本倉庫的 e2e 測試可以看到 S2I 策略的完整落地驗證test/extended/builds/s2i_incremental.go 驗證了增量 s2i 構(gòu)建連續(xù)兩次構(gòu)建同一 BuildConfig第二次構(gòu)建復用第一次構(gòu)建產(chǎn)物隨后用生成鏡像實例化 Pod 與服務并curl驗證容器內(nèi)保存了上次構(gòu)建的 artifacts響應包含artifacts existtest/extended/builds/s2i_env.go 驗證源碼中的環(huán)境文件.s2i/environment能正確注入應用響應包含successtest/extended/testdata/builds/test-build.yaml 中的sample-build展示了 Source 策略的標準寫法source.type: Git指向https://github.com/openshift/ruby-hello-world.gitstrategy.type: Source并在sourceStrategy.env中注入FOO、BAR、BUILD_LOGLEVEL等環(huán)境變量from指向image-registry.openshift-image-registry.svc:5000/openshift/ruby:3.3-ubi8作為 s2i 基礎鏡像。結(jié)合 CLI 的 S2I 實操路徑來自 test/extended/builds/start.gooc new-app https://github.com/openshift/ruby-hello-world#config從帶分支引用的倉庫創(chuàng)建應用并觸發(fā) s2i 構(gòu)建測試驗證會正確檢出config分支而不是同名目錄oc start-build sample-build --wait啟動構(gòu)建并等待完成配合--commitfffffff等錯誤引用時--wait會檢測到status is Failedoc start-build sample-build -e FOObar -e VARtest覆蓋環(huán)境變量構(gòu)建日志中會同時出現(xiàn)新增變量與 BuildConfig 中繼承的變量如BARtestoc start-build sample-verbose-build --build-loglevel1可覆蓋 BuildConfig 中的BUILD_LOGLEVEL。自定義Custom構(gòu)建策略自定義構(gòu)建策略與 Docker 構(gòu)建策略非常相似區(qū)別在于用戶可以自定義用于執(zhí)行構(gòu)建的 builder 鏡像。Docker 構(gòu)建默認使用openshift/origin-docker-builder鏡像使用自定義 builder 鏡像則可以完全定制構(gòu)建過程。原文檔給出的自定義構(gòu)建策略 JSON 示例strategy: { type: Custom, customStrategy: { image: my-custom-builder-image, exposeDockerSocket: true, env: [ { name: EXPOSE_PORT, value: 8080 } ] } }exposeDockerSocket把宿主機 Docker socket 掛載進 builder 容器允許在其中執(zhí)行docker build與docker push。原文檔特別提示該能力未來可能被管理員限制。env向 builder 容器環(huán)境傳入額外環(huán)境變量。默認注入 builder 容器的環(huán)境變量原文檔明確列出以下默認傳遞的環(huán)境變量變量含義$BUILD當前 Build 的 JSON 表示$OUTPUT_IMAGEBuild 中配置的輸出容器鏡像名$OUTPUT_REGISTRYBuild 中配置的輸出容器鏡像倉庫$SOURCE_URI源代碼倉庫的 URL$SOURCE_REF源代碼倉庫的分支、tag 或 ref$DOCKER_SOCKETDocker socket 的完整路徑倉庫中的 Custom 策略實戰(zhàn)樣例本倉庫 e2e 測試提供了比文檔示例更完整的 Custom 策略 YAML 配置test/extended/testdata/builds/test-custom-build.yamlkind: BuildConfig apiVersion: build.openshift.io/v1 metadata: name: sample-custom-build spec: strategy: type: Custom customStrategy: env: - name: BUILD_LOGLEVEL value: 2 forcePull: true from: kind: ImageStreamTag name: custom-builder-image:latest output: to: kind: ImageStreamTag name: sample-custom:latest可以看到 Custom 策略除env外還支持forcePull強制每次拉取最新 builder 鏡像與from通過 ImageStreamTag 指定 builder 鏡像來源構(gòu)建產(chǎn)物通過output.to寫入名為sample-custom:latest的 ImageStreamTag。配套的 builder 鏡像定義位于 test/extended/testdata/builds/custom-build/Dockerfile它基于registry.redhat.io/rhel8/buildah:latest將待構(gòu)建的 Dockerfile 樣例Dockerfile.sample內(nèi)容為FROM image-registry.openshift-image-registry.svc:5000/openshift/tools:latestRUN touch /tmp/built放入/tmp/input/并將真正的構(gòu)建邏輯腳本build.sh設為 ENTRYPOINT——即builder 鏡像運行時執(zhí)行的就是自定義構(gòu)建邏輯。對應的 e2e 測試見 test/extended/builds/custom_build.go完整演練了自定義構(gòu)建鏈路# 1. 用二進制方式先構(gòu)建出自定義 builder 鏡像 oc new-build --binary --strategydocker --namecustom-builder-image oc start-build custom-builder-image --from-dirtest/extended/testdata/builds/custom-build # 2. 應用 Custom 策略的 BuildConfig 并啟動構(gòu)建 oc create -f test/extended/testdata/builds/test-custom-build.yaml oc start-build sample-custom-build # 3. 等待名為 sample-custom-build-1 的構(gòu)建成功完成構(gòu)建輸入與 CLI 實操從倉庫測試看完整命令鏈原文檔把構(gòu)建輸入列為構(gòu)建任務的公共特征之一。結(jié)合 test/extended/builds/start.go 與 test/extended/testdata/builds/test-build.yaml可梳理出 OpenShift 支持的多種輸入方式與對應命令二進制輸入Binary構(gòu)建對應 BuildConfig 中source.type: Binary的配置例如sample-build-binarysource: type: Binary binary: {} strategy: type: Docker dockerStrategy: from: kind: DockerImage name: image-registry.openshift-image-registry.svc:5000/openshift/ruby:3.3-ubi8oc start-build支持以下二進制輸入形態(tài)命令參數(shù)說明測試驗證點--from-filefile以單個文件作為構(gòu)建輸入也支持 HTTPS URL輸出Uploading file ... as binary input for the build--from-dirdir以目錄Docker context作為輸入輸出Uploading directory ... as binary input for the build--from-reporepo以本地 Git 倉庫作為輸入可配合--commitsha指定提交輸出at commit HEAD--from-archiveurl以遠程歸檔zip作為輸入配合contextDir處理歸檔內(nèi)的頂層目錄輸出Uploading archive from ... as binary input for the build此外構(gòu)建日志中會出現(xiàn)Build complete表示成功若 BuildConfig 無有效輸入oc start-build會報錯has no valid source inputs。Git 源碼輸入與 Dockerfile 輸入Git 源碼輸入source.type: Gitsource.git.uri如sample-build使用https://github.com/openshift/ruby-hello-world.gitDockerfile 輸入source.type: Dockerfilesource.dockerfile內(nèi)聯(lián)內(nèi)容測試 test/extended/builds/dockerfile.go 用oc new-build -D -從 stdin 傳入 Dockerfile 創(chuàng)建構(gòu)建并驗證生成的 BuildConfig 中spec.source.git為空、Dockerfile 內(nèi)容被完整保存最終鏡像的Config.User為 Dockerfile 中聲明的USER 1001還覆蓋了FROM scratch、輸出 tag 推斷ruby:latest、以及非法 Dockerfile 內(nèi)容導致構(gòu)建失敗并在日志中報no such file or directory等場景。構(gòu)建參數(shù)Build Args對于 Docker 策略可在dockerStrategy.buildArgs中預設參數(shù)也可用 CLI 覆蓋dockerStrategy: buildArgs: - name: foofoo value: default測試驗證test/extended/builds/start.go預設的 build arg 會傳入構(gòu)建日志輸出其值defaultoc start-build ... --build-argfoofoobar可覆蓋日志輸出新值bar傳入 Dockerfile 未聲明的 arg如--build-argbarfoo構(gòu)建仍成功但日志出現(xiàn)警告one or more build args were not consumed: [bar]。觸發(fā)與取消構(gòu)建sample-build的觸發(fā)配置示例triggers: - type: ImageChange imageChange: {} - type: Generic generic: secret: mysecret secretReference: name: webhooksecret對應 Generic Webhook 的調(diào)用端點是POST /apis/build.openshift.io/v1/namespaces/ns/buildconfigs/sample-build/webhooks/secret/generic測試驗證了用內(nèi)聯(lián) secretmysecret與引用的 Secretsecretvalue1都能成功觸發(fā)構(gòu)建而錯誤 secretinvalid則不會產(chǎn)生任何構(gòu)建。取消構(gòu)建使用oc cancel-build buildName配合oc start-build --wait時--wait會檢測到status is Cancelled對于因 nodeSelector 無法匹配而無法調(diào)度的構(gòu)建系統(tǒng)會自動取消并在事件中記錄取消原因BuildCancelledEventReason。構(gòu)建的運行模型Pod、調(diào)度與資源限制從構(gòu)建 API 的設計目標與當前實現(xiàn)看每次構(gòu)建都以 Pod 形式承載。以 test/extended/builds/start.go 中的verifyBuildPod為例可以確認構(gòu)建 Pod 的實際形態(tài)構(gòu)建 Pod 名形如buildName-buildPod 會顯式選擇 linux 節(jié)點kubernetes.io/oslinuxnodeSelector源碼克隆通過名為git-clone的 init container 完成出于 CVE-2024-45496.gitconfig 可能被利用執(zhí)行任意命令的考慮該 init container 必須是非特權(quán)、僅保留CHOWN/DAC_OVERRIDE能力、并 drop ALL 其余能力、使用 runtime-default seccomp profile 的加固配置構(gòu)建容器與 Docker daemon 的交互、日志捕獲、產(chǎn)物發(fā)布均由 OpenShift 構(gòu)建控制器協(xié)調(diào)。資源限制方面原文檔強調(diào)構(gòu)建應當能夠限定 CPU、內(nèi)存與 Pod 執(zhí)行時間在倉庫的 BuildConfig 樣例中可以通過resources與nodeSelector字段如sample-build-binary-invalidnodeselector中的nodelabelkey: nodelabelvalue進行配置構(gòu)建系統(tǒng)會根據(jù)這些約束調(diào)度構(gòu)建 Pod。構(gòu)建 API 的定位面向第三方構(gòu)建系統(tǒng)與 CI/CD 編排回到原文檔的核心理念為構(gòu)建提供 API使 OpenShift 成為任意第三方容器鏡像構(gòu)建系統(tǒng)的可行后端。這意味著資源約束與調(diào)度能力由 OpenShift 統(tǒng)一提供第三方系統(tǒng)無需自行解決資源分配、調(diào)度與垃圾回收對應云 IDE 場景組織現(xiàn)有的 CI 流程Jenkins 等可以通過構(gòu)建 API 觸發(fā)、監(jiān)控、晉升構(gòu)建將 OpenShift 構(gòu)建無縫嵌入既有 DevOps SOP對應企業(yè) DevOps 場景構(gòu)建輸出進入 ImageStream/ImageStreamTag如sample-custom:latest為后續(xù)鏡像驅(qū)動部署提供輸入。本倉庫 test/extended/builds/ 下的數(shù)十個 e2e 測試涵蓋構(gòu)建觸發(fā)、Webhook、二進制輸入、增量構(gòu)建、環(huán)境變量、配額 s2i_quota.go、機密注入 secrets.go、構(gòu)建清理 build_pruning.go 等從實踐層面印證了構(gòu)建 API 的完整能力面可作為深入理解構(gòu)建系統(tǒng)行為與邊界條件的參考起點。贊分享測試云原生質(zhì)量保障【免費下載鏈接】originConformance test suite for OpenShift項目地址https://gitcode.com/gh_mirrors/or/origin點擊查看免費下載相關推薦一次配好大麥自動搶票腳本從原理到啟動的完整教程一次配好大麥自動搶票腳本從原理到啟動的完整教程 本文以開源項目 ticket purchase 為例講清這個大麥自動搶票工具怎么用。它解決的事情很明確你只GUI 自動化RPAHandsontable 自定義構(gòu)建Custom Builds完全指南Monorepo 構(gòu)建流程與各包構(gòu)建命令詳解Handsontable 自定義構(gòu)建Custom Builds完全指南Monorepo 構(gòu)建流程與各包構(gòu)建命令詳解 Handsontable 的構(gòu)建流程前端UI組件如何快速構(gòu)建Apache Airflow自定義Docker鏡像完整實戰(zhàn)指南如何快速構(gòu)建Apache Airflow自定義Docker鏡像完整實戰(zhàn)指南 Apache Airflow作為業(yè)界領先的工作流編排平臺其Docker鏡像構(gòu)建是后端任務調(diào)度工作流自動化數(shù)據(jù)編排批處理數(shù)據(jù)工程流程編排上一篇Imba樣式修飾符為什么你需要掌握這3類核心功能下一篇PowerInfer終極指南嵌入式設備上實現(xiàn)快速LLM推理的完整解決方案創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考