換鏡像)
Docker Compose Bridge Transformations 命令完全指南管理 compose 到 Kubernetes/Helm 的轉(zhuǎn)換鏡像【免費(fèi)下載鏈接】composeDefine and run multi-container applications with Docker項目地址: https://gitcode.com/GitHub_Trending/compose/compose導(dǎo)讀docker compose bridge transformations是 Docker Compose CLI 中負(fù)責(zé)管理轉(zhuǎn)換器鏡像transformation images的命令組它歸屬于 bridge 功能組支撐著docker compose bridge convert將 Compose 項目轉(zhuǎn)換為 Kubernetes manifests、Helm Chart 等其他部署模型的能力。讀完本文你將掌握 transformation 鏡像的工作原理、list與create兩個子命令的全部參數(shù)與用法以及如何從倉庫源碼與端到端測試中驗證這一機(jī)制的行為細(xì)節(jié)。transformations 命令組在 bridge 體系中的定位在 Compose 的 bridge 設(shè)計里把compose.yaml轉(zhuǎn)換成另一個模型的過程并不是寫死在 CLI 二進(jìn)制里的而是交給一個個獨(dú)立的轉(zhuǎn)換器鏡像去執(zhí)行。CLI 只負(fù)責(zé)把 Compose 項目模型序列化并喂給鏡像再由鏡像產(chǎn)出 Kubernetes/Helm 等目標(biāo)產(chǎn)物。transformations子命令組正是圍繞這批鏡像的生命周期管理而存在。從命令入口源碼可以看到transformations是一個僅用于歸組的父命令注冊了如下兩個子命令子命令用途list別名ls列出本地可用的 transformation 鏡像create基于已有 transformation 創(chuàng)建一份新的可定制副本官方參考文檔compose_bridge_transformations.md為命令組本身記錄了唯一的選項選項類型默認(rèn)說明--dry-runboolfalse以 dry-run 模式執(zhí)行命令其中--dry-run屬于從父命令繼承的選項詳見生成的 docker_compose_bridge_transformations.yaml后續(xù)小節(jié)中l(wèi)ist/create各自還能識別它。先理解 transformation 鏡像是什么標(biāo)簽 templates 目錄在動手執(zhí)行l(wèi)ist、create之前有必要先弄清 CLI 是如何識別一個鏡像是不是 transformation的。答案藏在pkg/bridge/transformers.go的常量定義里TransformerLabel com.docker.compose.bridge用于給鏡像打標(biāo)簽的鍵DefaultTransformerImage docker/compose-bridge-kubernetes默認(rèn)的轉(zhuǎn)換器鏡像templatesPath /templates轉(zhuǎn)換模板在鏡像內(nèi)的固定目錄。也就是說一個 transformation 鏡像需要滿足兩點(diǎn)約定帶有標(biāo)簽com.docker.compose.bridgetransformation鏡像內(nèi)包含/templates目錄里面存放轉(zhuǎn)換所用的模板文件。而鏡像真正被消費(fèi)的地方在pkg/bridge/convert.go的convert函數(shù)中CLI 會把序列化后的 Compose 項目臨時目錄中的compose.yaml以 bind mount 方式掛載為容器的/in把輸出目錄掛載為/out若用戶顯式傳了--templates則再掛載到/templates隨后以LICENSE_AGREEMENTtrue的環(huán)境變量啟動該鏡像并等待其運(yùn)行完成產(chǎn)物即被寫入/out。這解釋了為什么 transformation 鏡像必須自帶模板轉(zhuǎn)換邏輯本身運(yùn)行在容器里CLI 只負(fù)責(zé)把輸入與輸出目錄接好。列出已安裝的轉(zhuǎn)換器transformations listlist別名ls用于枚舉本機(jī) Docker 中所有已安裝的 transformation 鏡像。其 CLI 定義見 cmd/compose/bridge.go官方參數(shù)表如下文檔選項類型默認(rèn)說明--dry-runboolfalse以 dry-run 模式執(zhí)行--formatstringtable輸出格式可選table或json-q,--quietboolfalse僅顯示 transformer 名稱底層實(shí)現(xiàn)按標(biāo)簽過濾鏡像命令的完整形態(tài)有兩種寫法二者等價docker compose bridge transformations list docker compose bridge transformations ls底層調(diào)用ListTransformers其實(shí)質(zhì)就是對 Docker daemon 執(zhí)行一次帶 label 過濾的ImageList查詢docker image ls --filter labelcom.docker.compose.bridgetransformation因此凡是帶com.docker.compose.bridgetransformation標(biāo)簽的本地鏡像都會被列出無關(guān)鏡像不會出現(xiàn)——這也是可用 transformation的唯一定義。默認(rèn) table 輸出與列含義默認(rèn)--format table輸出包含四列格式化邏輯見 cmd/compose/bridge.goIMAGE ID鏡像 ID 的截斷形式REPO倉庫名從 RepoTags 解析出的熟悉名稱TAGS鏡像標(biāo)簽SIZE鏡像大小按人類可讀格式展示。-q/--quiet則會退化為純名稱輸出優(yōu)先打印RepoTags[0]無標(biāo)簽時才打印鏡像 ID。機(jī)器可讀輸出需要腳本消費(fèi)時可切換為 JSONdocker compose bridge transformations list --format json從 docker_compose_bridge_transformations_list.yaml 生成的默認(rèn)值可以看到format的默認(rèn)是table僅在顯式傳入json時才切換。一個典型的驗證場景倉庫的端到端測試 pkg/e2e/bridge_test.go 展示了list的實(shí)戰(zhàn)校驗在執(zhí)行過轉(zhuǎn)換后執(zhí)行l(wèi)s斷言標(biāo)準(zhǔn)輸出中同時包含docker/compose-bridge-helm與docker/compose-bridge-kubernetes兩個鏡像名。這提示了 list 的最常見用途——確認(rèn)本地是否已具備所需的轉(zhuǎn)換器鏡像避免bridge convert時因鏡像缺失觸發(fā)不必要的網(wǎng)絡(luò)拉取。派生一份自定義轉(zhuǎn)換器transformations createcreate用于復(fù)制一份現(xiàn)有的 transformation生成一個可以修改的本地工程便于你定制自己的轉(zhuǎn)換模板。命令入口見 cmd/compose/bridge.godocker compose bridge transformations create [OPTION] PATH其中PATH是必填的位置參數(shù)源碼中通過cli.ExactArgs(1)強(qiáng)制恰好一個參數(shù)它指向要生成的本地工程目錄。參數(shù)表如下文檔選項類型默認(rèn)說明--dry-runboolfalse以 dry-run 模式執(zhí)行-f,--fromstringdocker/compose-bridge-kubernetes要復(fù)制來源的已有 transformation 鏡像create 執(zhí)行時實(shí)際發(fā)生什么create的完整實(shí)現(xiàn)位于CreateTransformer其行為可歸納為四個階段解析來源鏡像若未傳--from自動使用默認(rèn)值docker/compose-bridge-kubernetes見 transformers.go校驗?zāi)繕?biāo)目錄目標(biāo)路徑會被轉(zhuǎn)為絕對路徑且該目錄必須不存在output folder %s already exists會直接報錯隨后創(chuàng)建templates/子目錄并校驗輸出路徑合法性從來源鏡像抽取模板以來源鏡像創(chuàng)建臨時容器結(jié)束后自動ContainerRemove(Force: true)清理再通過CopyFromContainer把容器內(nèi)的/templates目錄整體拷貝到本地目標(biāo)目錄生成 Dockerfile在目標(biāo)目錄寫入一個默認(rèn) Dockerfile內(nèi)容為FROM docker/compose-bridge-transformer LABEL com.docker.compose.bridgetransformation COPY templates /templates這個 Dockerfile 恰好回應(yīng)了前文所述的兩條約定基礎(chǔ)鏡像使用官方轉(zhuǎn)換器運(yùn)行時docker/compose-bridge-transformer打上com.docker.compose.bridgetransformation標(biāo)簽并把本地templates目錄復(fù)制回鏡像內(nèi)的/templates。create 之后你得到什么假設(shè)執(zhí)行docker compose bridge transformations create my-k8s-tweaks工作目錄my-k8s-tweaks/下會出現(xiàn)templates/從docker/compose-bridge-kubernetes拷貝來的模板目錄可在此按需修改Dockerfile上文展示的默認(rèn)構(gòu)建文件。之后用docker build構(gòu)建并打上標(biāo)簽一個新 transformation 鏡像便誕生了。不過要注意create 本身不會自動幫你 build 鏡像它只負(fù)責(zé)生成可構(gòu)建的工程骨架最終仍需自行docker build -t your-registry/name .。注意--dry-run需要 docker daemon 支持 dry-run 的客戶端能力。從 docker_compose_bridge_transformations_create.yaml 可以看到from僅有string類型且默認(rèn)值在幫助信息中說明未傳入時即回落到源碼中的默認(rèn)鏡像。把 transformations 接回完整的轉(zhuǎn)換工作流掌握了鏡像管理之后理解它們?nèi)绾伪皇褂貌磐暾ocker compose bridge convert的-t/--transformation選項用于指定要應(yīng)用的轉(zhuǎn)換器可重復(fù)傳入多個stringArray若完全不傳則默認(rèn)使用docker/compose-bridge-kubernetes默認(rèn)值見 convert.go 與 compose_bridge_convert.md。倉庫端到端測試 TestConvertAndTransformList 給出了一個完整可復(fù)現(xiàn)的工作流示例# 1. 轉(zhuǎn)換為 Kubernetes manifests docker compose -f fixtures/bridge/compose.yaml --project-name bridge \ bridge convert --output out/kubernetes \ --transformation docker/compose-bridge-kubernetes:v0.0.3 # 2. 轉(zhuǎn)換為 Helm chart docker compose -f fixtures/bridge/compose.yaml --project-name bridge \ bridge convert --output out/helm \ --transformation docker/compose-bridge-helm:v0.0.3 # 3. 核對本地已就緒的 transformation 鏡像 docker compose --project-name bridge bridge transformations ls與之對應(yīng)的樣例 Compose 文件是 fixtures/bridge/compose.yaml它同時使用了configs、secrets、internal網(wǎng)絡(luò)與多網(wǎng)絡(luò)服務(wù)用以驗證轉(zhuǎn)換器的覆蓋能力。轉(zhuǎn)換結(jié)果可在倉庫中直接比對Kubernetes 輸出fixtures/bridge/expected-kubernetes包含base/的 namespace、configs、secrets、NetworkPolicy、Deployment、Service 與kustomization.yaml以及overlays/desktop/覆蓋層Helm 輸出fixtures/bridge/expected-helmChart.yaml、values.yaml與templates/下的各資源模板。觀察這些預(yù)期產(chǎn)物可以看到命名空間、Secret/ConfigMap、網(wǎng)絡(luò)策略、Deployment、Service 等 Kubernetes 資源均由模板體系自動推導(dǎo)生成這也是默認(rèn) transformationdocker/compose-bridge-kubernetes的功能邊界。測試通過diff -r對轉(zhuǎn)換輸出與期望目錄做全量比對說明轉(zhuǎn)換結(jié)果是確定性的。使用注意事項與限制結(jié)合源碼使用本命令組時有幾點(diǎn)值得留意依賴本地 Docker daemonlist與create都直接調(diào)用dockerCli.Client()見 transformers.go因此環(huán)境必須能訪問 Docker Enginecreate還需要能拉取或已存在--from指定的來源鏡像。鏡像缺失時不會自動兜底create依賴本地鏡像執(zhí)行ContainerCreateCopyFromContainer來源鏡像不存在時命令會直接失敗需要先docker pull。目標(biāo)目錄必須不存在create PATH在目標(biāo)已存在時會報output folder ... already exists這是有意的保護(hù)避免覆蓋已有工程。Windows 與 Linux 行為差異在convert階段POSIX 系統(tǒng)會把容器以當(dāng)前用戶 UID 運(yùn)行以保證輸出文件歸屬正確而 Windows 上引擎無法管理 SID因此不會設(shè)置 User 字段見 convert.go。這一點(diǎn)對你編寫、測試自定義模板時同樣有影響。--dry-run在文檔與實(shí)現(xiàn)中的呈現(xiàn)--dry-run在參考文檔中作為父命令繼承的選項出現(xiàn)但本文所述三個命令的核心實(shí)現(xiàn)路徑并未針對 dry-run 額外分支處理它更接近 Compose CLI 對全局 dry-run 能力的統(tǒng)一標(biāo)注與 alpha dry-run 能力 對齊。實(shí)際批量腳本中建議以真實(shí)執(zhí)行 輸出校驗為準(zhǔn)。小結(jié)與延伸閱讀docker compose bridge transformations用鏡像即轉(zhuǎn)換器的方式把 Compose 到 Kubernetes/Helm 的轉(zhuǎn)換邏輯與 CLI 解耦list通過com.docker.compose.bridgetransformation標(biāo)簽發(fā)現(xiàn)已安裝的轉(zhuǎn)換器create則從已有鏡像抽取/templates生成可定制的轉(zhuǎn)換工程。整體機(jī)制由 pkg/bridge/transformers.go 與 pkg/bridge/convert.go 共同實(shí)現(xiàn)并被 pkg/e2e/bridge_test.go 端到端驗證。如果想繼續(xù)深入建議按以下順序閱讀倉庫內(nèi)容功能組總覽compose_bridge.md、compose_bridge_convert.mdCLI 注冊代碼cmd/compose/bridge.go轉(zhuǎn)換執(zhí)行與資源預(yù)加載測試pkg/bridge/convert_test.go端到端樣例工程fixtures/bridge/【免費(fèi)下載鏈接】composeDefine and run multi-container applications with Docker項目地址: https://gitcode.com/GitHub_Trending/compose/compose創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 Docker Compose Bridge Transformations 命令完全指南：管理 compose 到 Kubernetes/Helm 的轉(zhuǎn)換鏡像
Docker Compose Bridge Transformations 命令完全指南管理 compose 到 Kubernetes/Helm 的轉(zhuǎn)換鏡像【免費(fèi)下載鏈接】composeDefine and run multi-container applications with Docker項目地址: https://gitcode.com/GitHub_Trending/compose/compose導(dǎo)讀docker compose bridge transformations是 Docker Compose CLI 中負(fù)責(zé)管理轉(zhuǎn)換器鏡像transformation images的命令組它歸屬于 bridge 功能組支撐著docker compose bridge convert將 Compose 項目轉(zhuǎn)換為 Kubernetes manifests、Helm Chart 等其他部署模型的能力。讀完本文你將掌握 transformation 鏡像的工作原理、list與create兩個子命令的全部參數(shù)與用法以及如何從倉庫源碼與端到端測試中驗證這一機(jī)制的行為細(xì)節(jié)。transformations 命令組在 bridge 體系中的定位在 Compose 的 bridge 設(shè)計里把compose.yaml轉(zhuǎn)換成另一個模型的過程并不是寫死在 CLI 二進(jìn)制里的而是交給一個個獨(dú)立的轉(zhuǎn)換器鏡像去執(zhí)行。CLI 只負(fù)責(zé)把 Compose 項目模型序列化并喂給鏡像再由鏡像產(chǎn)出 Kubernetes/Helm 等目標(biāo)產(chǎn)物。transformations子命令組正是圍繞這批鏡像的生命周期管理而存在。從命令入口源碼可以看到transformations是一個僅用于歸組的父命令注冊了如下兩個子命令子命令用途list別名ls列出本地可用的 transformation 鏡像create基于已有 transformation 創(chuàng)建一份新的可定制副本官方參考文檔compose_bridge_transformations.md為命令組本身記錄了唯一的選項選項類型默認(rèn)說明--dry-runboolfalse以 dry-run 模式執(zhí)行命令其中--dry-run屬于從父命令繼承的選項詳見生成的 docker_compose_bridge_transformations.yaml后續(xù)小節(jié)中l(wèi)ist/create各自還能識別它。先理解 transformation 鏡像是什么標(biāo)簽 templates 目錄在動手執(zhí)行l(wèi)ist、create之前有必要先弄清 CLI 是如何識別一個鏡像是不是 transformation的。答案藏在pkg/bridge/transformers.go的常量定義里TransformerLabel com.docker.compose.bridge用于給鏡像打標(biāo)簽的鍵DefaultTransformerImage docker/compose-bridge-kubernetes默認(rèn)的轉(zhuǎn)換器鏡像templatesPath /templates轉(zhuǎn)換模板在鏡像內(nèi)的固定目錄。也就是說一個 transformation 鏡像需要滿足兩點(diǎn)約定帶有標(biāo)簽com.docker.compose.bridgetransformation鏡像內(nèi)包含/templates目錄里面存放轉(zhuǎn)換所用的模板文件。而鏡像真正被消費(fèi)的地方在pkg/bridge/convert.go的convert函數(shù)中CLI 會把序列化后的 Compose 項目臨時目錄中的compose.yaml以 bind mount 方式掛載為容器的/in把輸出目錄掛載為/out若用戶顯式傳了--templates則再掛載到/templates隨后以LICENSE_AGREEMENTtrue的環(huán)境變量啟動該鏡像并等待其運(yùn)行完成產(chǎn)物即被寫入/out。這解釋了為什么 transformation 鏡像必須自帶模板轉(zhuǎn)換邏輯本身運(yùn)行在容器里CLI 只負(fù)責(zé)把輸入與輸出目錄接好。列出已安裝的轉(zhuǎn)換器transformations listlist別名ls用于枚舉本機(jī) Docker 中所有已安裝的 transformation 鏡像。其 CLI 定義見 cmd/compose/bridge.go官方參數(shù)表如下文檔選項類型默認(rèn)說明--dry-runboolfalse以 dry-run 模式執(zhí)行--formatstringtable輸出格式可選table或json-q,--quietboolfalse僅顯示 transformer 名稱底層實(shí)現(xiàn)按標(biāo)簽過濾鏡像命令的完整形態(tài)有兩種寫法二者等價docker compose bridge transformations list docker compose bridge transformations ls底層調(diào)用ListTransformers其實(shí)質(zhì)就是對 Docker daemon 執(zhí)行一次帶 label 過濾的ImageList查詢docker image ls --filter labelcom.docker.compose.bridgetransformation因此凡是帶com.docker.compose.bridgetransformation標(biāo)簽的本地鏡像都會被列出無關(guān)鏡像不會出現(xiàn)——這也是可用 transformation的唯一定義。默認(rèn) table 輸出與列含義默認(rèn)--format table輸出包含四列格式化邏輯見 cmd/compose/bridge.goIMAGE ID鏡像 ID 的截斷形式REPO倉庫名從 RepoTags 解析出的熟悉名稱TAGS鏡像標(biāo)簽SIZE鏡像大小按人類可讀格式展示。-q/--quiet則會退化為純名稱輸出優(yōu)先打印RepoTags[0]無標(biāo)簽時才打印鏡像 ID。機(jī)器可讀輸出需要腳本消費(fèi)時可切換為 JSONdocker compose bridge transformations list --format json從 docker_compose_bridge_transformations_list.yaml 生成的默認(rèn)值可以看到format的默認(rèn)是table僅在顯式傳入json時才切換。一個典型的驗證場景倉庫的端到端測試 pkg/e2e/bridge_test.go 展示了list的實(shí)戰(zhàn)校驗在執(zhí)行過轉(zhuǎn)換后執(zhí)行l(wèi)s斷言標(biāo)準(zhǔn)輸出中同時包含docker/compose-bridge-helm與docker/compose-bridge-kubernetes兩個鏡像名。這提示了 list 的最常見用途——確認(rèn)本地是否已具備所需的轉(zhuǎn)換器鏡像避免bridge convert時因鏡像缺失觸發(fā)不必要的網(wǎng)絡(luò)拉取。派生一份自定義轉(zhuǎn)換器transformations createcreate用于復(fù)制一份現(xiàn)有的 transformation生成一個可以修改的本地工程便于你定制自己的轉(zhuǎn)換模板。命令入口見 cmd/compose/bridge.godocker compose bridge transformations create [OPTION] PATH其中PATH是必填的位置參數(shù)源碼中通過cli.ExactArgs(1)強(qiáng)制恰好一個參數(shù)它指向要生成的本地工程目錄。參數(shù)表如下文檔選項類型默認(rèn)說明--dry-runboolfalse以 dry-run 模式執(zhí)行-f,--fromstringdocker/compose-bridge-kubernetes要復(fù)制來源的已有 transformation 鏡像create 執(zhí)行時實(shí)際發(fā)生什么create的完整實(shí)現(xiàn)位于CreateTransformer其行為可歸納為四個階段解析來源鏡像若未傳--from自動使用默認(rèn)值docker/compose-bridge-kubernetes見 transformers.go校驗?zāi)繕?biāo)目錄目標(biāo)路徑會被轉(zhuǎn)為絕對路徑且該目錄必須不存在output folder %s already exists會直接報錯隨后創(chuàng)建templates/子目錄并校驗輸出路徑合法性從來源鏡像抽取模板以來源鏡像創(chuàng)建臨時容器結(jié)束后自動ContainerRemove(Force: true)清理再通過CopyFromContainer把容器內(nèi)的/templates目錄整體拷貝到本地目標(biāo)目錄生成 Dockerfile在目標(biāo)目錄寫入一個默認(rèn) Dockerfile內(nèi)容為FROM docker/compose-bridge-transformer LABEL com.docker.compose.bridgetransformation COPY templates /templates這個 Dockerfile 恰好回應(yīng)了前文所述的兩條約定基礎(chǔ)鏡像使用官方轉(zhuǎn)換器運(yùn)行時docker/compose-bridge-transformer打上com.docker.compose.bridgetransformation標(biāo)簽并把本地templates目錄復(fù)制回鏡像內(nèi)的/templates。create 之后你得到什么假設(shè)執(zhí)行docker compose bridge transformations create my-k8s-tweaks工作目錄my-k8s-tweaks/下會出現(xiàn)templates/從docker/compose-bridge-kubernetes拷貝來的模板目錄可在此按需修改Dockerfile上文展示的默認(rèn)構(gòu)建文件。之后用docker build構(gòu)建并打上標(biāo)簽一個新 transformation 鏡像便誕生了。不過要注意create 本身不會自動幫你 build 鏡像它只負(fù)責(zé)生成可構(gòu)建的工程骨架最終仍需自行docker build -t your-registry/name .。注意--dry-run需要 docker daemon 支持 dry-run 的客戶端能力。從 docker_compose_bridge_transformations_create.yaml 可以看到from僅有string類型且默認(rèn)值在幫助信息中說明未傳入時即回落到源碼中的默認(rèn)鏡像。把 transformations 接回完整的轉(zhuǎn)換工作流掌握了鏡像管理之后理解它們?nèi)绾伪皇褂貌磐暾ocker compose bridge convert的-t/--transformation選項用于指定要應(yīng)用的轉(zhuǎn)換器可重復(fù)傳入多個stringArray若完全不傳則默認(rèn)使用docker/compose-bridge-kubernetes默認(rèn)值見 convert.go 與 compose_bridge_convert.md。倉庫端到端測試 TestConvertAndTransformList 給出了一個完整可復(fù)現(xiàn)的工作流示例# 1. 轉(zhuǎn)換為 Kubernetes manifests docker compose -f fixtures/bridge/compose.yaml --project-name bridge \ bridge convert --output out/kubernetes \ --transformation docker/compose-bridge-kubernetes:v0.0.3 # 2. 轉(zhuǎn)換為 Helm chart docker compose -f fixtures/bridge/compose.yaml --project-name bridge \ bridge convert --output out/helm \ --transformation docker/compose-bridge-helm:v0.0.3 # 3. 核對本地已就緒的 transformation 鏡像 docker compose --project-name bridge bridge transformations ls與之對應(yīng)的樣例 Compose 文件是 fixtures/bridge/compose.yaml它同時使用了configs、secrets、internal網(wǎng)絡(luò)與多網(wǎng)絡(luò)服務(wù)用以驗證轉(zhuǎn)換器的覆蓋能力。轉(zhuǎn)換結(jié)果可在倉庫中直接比對Kubernetes 輸出fixtures/bridge/expected-kubernetes包含base/的 namespace、configs、secrets、NetworkPolicy、Deployment、Service 與kustomization.yaml以及overlays/desktop/覆蓋層Helm 輸出fixtures/bridge/expected-helmChart.yaml、values.yaml與templates/下的各資源模板。觀察這些預(yù)期產(chǎn)物可以看到命名空間、Secret/ConfigMap、網(wǎng)絡(luò)策略、Deployment、Service 等 Kubernetes 資源均由模板體系自動推導(dǎo)生成這也是默認(rèn) transformationdocker/compose-bridge-kubernetes的功能邊界。測試通過diff -r對轉(zhuǎn)換輸出與期望目錄做全量比對說明轉(zhuǎn)換結(jié)果是確定性的。使用注意事項與限制結(jié)合源碼使用本命令組時有幾點(diǎn)值得留意依賴本地 Docker daemonlist與create都直接調(diào)用dockerCli.Client()見 transformers.go因此環(huán)境必須能訪問 Docker Enginecreate還需要能拉取或已存在--from指定的來源鏡像。鏡像缺失時不會自動兜底create依賴本地鏡像執(zhí)行ContainerCreateCopyFromContainer來源鏡像不存在時命令會直接失敗需要先docker pull。目標(biāo)目錄必須不存在create PATH在目標(biāo)已存在時會報output folder ... already exists這是有意的保護(hù)避免覆蓋已有工程。Windows 與 Linux 行為差異在convert階段POSIX 系統(tǒng)會把容器以當(dāng)前用戶 UID 運(yùn)行以保證輸出文件歸屬正確而 Windows 上引擎無法管理 SID因此不會設(shè)置 User 字段見 convert.go。這一點(diǎn)對你編寫、測試自定義模板時同樣有影響。--dry-run在文檔與實(shí)現(xiàn)中的呈現(xiàn)--dry-run在參考文檔中作為父命令繼承的選項出現(xiàn)但本文所述三個命令的核心實(shí)現(xiàn)路徑并未針對 dry-run 額外分支處理它更接近 Compose CLI 對全局 dry-run 能力的統(tǒng)一標(biāo)注與 alpha dry-run 能力 對齊。實(shí)際批量腳本中建議以真實(shí)執(zhí)行 輸出校驗為準(zhǔn)。小結(jié)與延伸閱讀docker compose bridge transformations用鏡像即轉(zhuǎn)換器的方式把 Compose 到 Kubernetes/Helm 的轉(zhuǎn)換邏輯與 CLI 解耦list通過com.docker.compose.bridgetransformation標(biāo)簽發(fā)現(xiàn)已安裝的轉(zhuǎn)換器create則從已有鏡像抽取/templates生成可定制的轉(zhuǎn)換工程。整體機(jī)制由 pkg/bridge/transformers.go 與 pkg/bridge/convert.go 共同實(shí)現(xiàn)并被 pkg/e2e/bridge_test.go 端到端驗證。如果想繼續(xù)深入建議按以下順序閱讀倉庫內(nèi)容功能組總覽compose_bridge.md、compose_bridge_convert.mdCLI 注冊代碼cmd/compose/bridge.go轉(zhuǎn)換執(zhí)行與資源預(yù)加載測試pkg/bridge/convert_test.go端到端樣例工程fixtures/bridge/【免費(fèi)下載鏈接】composeDefine and run multi-container applications with Docker項目地址: https://gitcode.com/GitHub_Trending/compose/compose創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考