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