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两个子命令的全部参数与用法以及如何从仓库源码与端到端测试中验证这一机制的行为细节。transformations 命令组在 bridge 体系中的定位在 Compose 的 bridge 设计里把compose.yaml转换成另一个模型的过程并不是写死在 CLI 二进制里的而是交给一个个独立的转换器镜像去执行。CLI 只负责把 Compose 项目模型序列化并喂给镜像再由镜像产出 Kubernetes/Helm 等目标产物。transformations子命令组正是围绕这批镜像的生命周期管理而存在。从命令入口源码可以看到transformations是一个仅用于归组的父命令注册了如下两个子命令子命令用途list别名ls列出本地可用的 transformation 镜像create基于已有 transformation 创建一份新的可定制副本官方参考文档compose_bridge_transformations.md为命令组本身记录了唯一的选项选项类型默认说明--dry-runboolfalse以 dry-run 模式执行命令其中--dry-run属于从父命令继承的选项详见生成的 docker_compose_bridge_transformations.yaml后续小节中list/create各自还能识别它。先理解 transformation 镜像是什么标签 templates 目录在动手执行list、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的环境变量启动该镜像并等待其运行完成产物即被写入/out。这解释了为什么 transformation 镜像必须自带模板转换逻辑本身运行在容器里CLI 只负责把输入与输出目录接好。列出已安装的转换器transformations listlist别名ls用于枚举本机 Docker 中所有已安装的 transformation 镜像。其 CLI 定义见 cmd/compose/bridge.go官方参数表如下文档选项类型默认说明--dry-runboolfalse以 dry-run 模式执行--formatstringtable输出格式可选table或json-q,--quietboolfalse仅显示 transformer 名称底层实现按标签过滤镜像命令的完整形态有两种写法二者等价docker compose bridge transformations list docker compose bridge transformations ls底层调用ListTransformers其实质就是对 Docker daemon 执行一次带 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则会退化为纯名称输出优先打印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的实战校验在执行过转换后执行ls断言标准输出中同时包含docker/compose-bridge-helm与docker/compose-bridge-kubernetes两个镜像名。这提示了 list 的最常见用途——确认本地是否已具备所需的转换器镜像避免bridge convert时因镜像缺失触发不必要的网络拉取。派生一份自定义转换器transformations createcreate用于复制一份现有的 transformation生成一个可以修改的本地工程便于你定制自己的转换模板。命令入口见 cmd/compose/bridge.godocker compose bridge transformations create [OPTION] PATH其中PATH是必填的位置参数源码中通过cli.ExactArgs(1)强制恰好一个参数它指向要生成的本地工程目录。参数表如下文档选项类型默认说明--dry-runboolfalse以 dry-run 模式执行-f,--fromstringdocker/compose-bridge-kubernetes要复制来源的已有 transformation 镜像create 执行时实际发生什么create的完整实现位于CreateTransformer其行为可归纳为四个阶段解析来源镜像若未传--from自动使用默认值docker/compose-bridge-kubernetes见 transformers.go校验目标目录目标路径会被转为绝对路径且该目录必须不存在output folder %s already exists会直接报错随后创建templates/子目录并校验输出路径合法性从来源镜像抽取模板以来源镜像创建临时容器结束后自动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 之后你得到什么假设执行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因此环境必须能访问 Docker Enginecreate还需要能拉取或已存在--from指定的来源镜像。镜像缺失时不会自动兜底create依赖本地镜像执行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 能力对齐。实际批量脚本中建议以真实执行输出校验为准。小结与延伸阅读docker compose bridge transformations用镜像即转换器的方式把 Compose 到 Kubernetes/Helm 的转换逻辑与 CLI 解耦list通过com.docker.compose.bridgetransformation标签发现已安装的转换器create则从已有镜像抽取/templates生成可定制的转换工程。整体机制由 pkg/bridge/transformers.go 与 pkg/bridge/convert.go 共同实现并被 pkg/e2e/bridge_test.go 端到端验证。如果想继续深入建议按以下顺序阅读仓库内容功能组总览compose_bridge.md、compose_bridge_convert.mdCLI 注册代码cmd/compose/bridge.go转换执行与资源预加载测试pkg/bridge/convert_test.go端到端样例工程fixtures/bridge/【免费下载链接】composeDefine and run multi-container applications with Docker项目地址: https://gitcode.com/GitHub_Trending/compose/compose创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

Docker Compose Bridge Transformations 命令完全指南：管理 compose 到 Kubernetes/Helm 的转换镜像

相关推荐

Apache SeaTunnel实战：从数据同步到分布式架构的全面解析

GEO优化系统怎么选？火星GEO实测与2026年选型指南

微信小程序吉他商城毕设开题：Spring Boot+MySQL与微信支付实战指南

更多资讯

猫抓：5分钟把网页里的视频资源抓下来

C#与汇川PLC通信实战：Modbus TCP从配置到代码全解析

HC32系列Cortex-M0+远程IAP升级方案与Bootloader跳转踩坑详解

三端MMC直流电网中自适应下垂控制与MPC协同策略

如何用 create-astro 命令行参数非交互地创建 Astro 项目（指定模板、跳过依赖安装与 dry-run）

AgentSkills生态体系与跨平台支持：从技能声明到运行时适配的工程实践

今日更新

在S3C2410上移植Nucleus RTOS：启动、驱动与实时性调优实战

2026年Turnitin降重降AI二合一红黑榜：能过和别碰

2026期刊投稿AI写作工具实测：6款打分谁更值得用

本周精选

超人会飞不算本事：系统稳定依赖清晰规则与边界设计

超人VS蜘蛛侠：拆解超级IP的影响力与传播方法论

基于CNN的调制信号识别：MATLAB实现时频图分类实战

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？