docker compose bridge transformations create 命令详解从零创建自定义 Compose 转换模板【免费下载链接】composeDefine and run multi-container applications with Docker项目地址: https://gitcode.com/GitHub_Trending/compose/compose本指南聚焦 Docker Compose 的bridge扩展命令族中的docker compose bridge transformations create讲解如何使用该命令基于既有“转换器镜像transformation image”生成一套可编辑的转换模板目录为把 Compose 应用模型转换为 Kubernetes 清单、Helm Chart 或其他目标模型奠定基础。读完本文你将掌握该命令的完整语法、参数含义、底层容器化实现机制以及如何把生成的模板再次交还给bridge convert使用。命令定位transformations 管理子命令的一员在 Docker Compose 中docker compose bridge是“将 Compose 文件转换为另一种模型Convert compose files into another model”的命令族由 bridge.go 注册包含两个子命令docker compose bridge convert把 Compose 文件转换为 Kubernetes 清单、Helm Chart 或其他模型docker compose bridge transformations管理“转换器镜像”。而docker compose bridge transformations下又管理着两类操作见 compose_bridge_transformations.md子命令说明create创建一个新的转换模板transformationlist别名ls列出当前可用的转换器其中create解决的是这样一个问题convert执行转换时依赖一组镜像中的模板文件若你想自定义目标输出的生成规则就需要先有一份属于自己的模板骨架。create正是把某个现成转换器镜像内置的/templates目录“复制”到本地目录并顺带生成对应的Dockerfile让你可以在此基础上修改并重新构建为自有转换器镜像。命令语法与必选参数根据命令的 usage 定义见 docker_compose_bridge_transformations_create.yamldocker compose bridge transformations create [OPTION] PATHPATH是唯一的位置参数、且必须恰好提供一个它是新转换模板的输出目录。代码中使用cobra.ExactArgs(1)强约束参数个数见 bridge.go一旦缺失或传入多余参数命令都会报错并提示requires 1 argument该行为有测试用例覆盖见 bridge_test.go。未带任何子命令时transformations/bridge会直接输出帮助信息传入未知子命令则报错并返回退出码 1。PATH会被os.Stat检查若该目录已经存在命令会直接失败并返回错误output folder PATH already exists见 transformers.go这是刻意的“防覆盖”设计——它保证你不会误覆盖已有模板。选项详解该命令的选项在本参考文档中登记如下核心来自 compose_bridge_transformations_create.mdNameTypeDefaultDescription--dry-runboolfalseExecute command in dry run mode-f,--fromstringdocker/compose-bridge-kubernetesExisting transformation to copy-f, --from指定要复制的源转换器镜像该选项声明为字符串类型语义是“从哪个已存在的转换器镜像复制模板”。当未显式传入时CreateTransformer内部会将From置为常量DefaultTransformerImage docker/compose-bridge-kubernetes见 transformers.go。也就是说默认情况下你会基于官方 Kubernetes 转换器镜像派生一份模板。传入自定义值时你既可以指向本地已构建的镜像名也可以指向远端仓库的镜像——dockerCli.Client().ContainerCreate会按镜像名直接创建容器若镜像尚不存在则会触发拉取流程。--dry-run继承自根命令的全局开关--dry-run并非create独有而是docker compose根命令注册的持久化标志persistent flag默认值为false在所有子命令上可见注册位置见 compose.go因此参考文档中把它归类为 inherited option。就其本身含义而言该开关用于“以预演模式执行命令不产生实际变更”。注意create命令体本身并没有再次声明或读取该开关的逻辑其实际生效范围取决于具体命令实现。底层实现一条“镜像 → 容器 → 本地目录”的复制链create命令的入口CreateTransformer见 transformers.go并不像普通文件复制那么简单而是借助 Docker 引擎完成一次容器化模板抽取其关键步骤可拆解如下规范化目标路径将PATH转换为绝对路径并先用os.MkdirAll创建PATH/templates子目录权限0744。创建临时容器用源镜像From调用ContainerCreate创建一个容器实例。注意此容器无需任何命令参数——它的存在只是为了暴露镜像内预置的模板目录。延迟清理通过defer确保无论后续成功与否都会用ContainerRemove(Force: true)强制删除这个临时容器。拷贝模板目录调用CopyFromContainer把容器内固定路径/templates源码常量templatesPath整体以 tar 流方式读回再通过archive.CopyTo解包写入本地目标目录。这里解释了为什么输出目录中会得到与镜像内一致的templates/结构。生成配套 Dockerfile在目标目录中写一个固定内容的DockerfileFROM docker/compose-bridge-transformer LABEL com.docker.compose.bridgetransformation COPY templates /templates输出提示最后向标准输出打印成功消息形如Transformer created in abs path。从镜像标签看“转换器”的识别机制生成的Dockerfile中有两处非常关键LABEL com.docker.compose.bridgetransformation这正是本仓库用来识别“转换器镜像”的约定标签。常量TransformerLabel com.docker.compose.bridge见 transformers.go。COPY templates /templates保证最终镜像在容器内仍然遵循/templates这一约定路径。docker compose bridge transformations list正是基于该标签做筛选它对 Docker 引擎上的全部镜像执行ImageList并用 label 过滤器com.docker.compose.bridgetransformation找出所有转换器镜像见 transformers.go。因此你基于create产出物重新docker build的镜像只要保留上述 LABEL就会被list识别并纳入管理。使用新模板从 create 到 convert 的完整闭环create产出的本地目录本身是编辑用的“工作区”要让自定义模板真正参与转换需要经历构建再消费的过程在PATH/templates中修改或新增模板文件使其符合你对目标输出例如 Kubernetes 清单的期望在PATH目录下执行docker build得到自定义转换器镜像记得继承模板中的 LABEL使用docker compose bridge convert消费它。该命令的-t, --transformation选项是 stringArray 类型允许指定一个或多个转换器镜像未指定时同样默认使用docker/compose-bridge-kubernetes见 convert.go 与 compose_bridge_convert.md。从源码看convert在真正执行转换时的工作方式convert.go恰好是create的“逆向过程”它把解析出的 Compose 模型以 YAML 挂载为容器内/in/compose.yaml把--output目录挂载为容器内/out若有--templates目录还会挂载到/templates随后以LICENSE_AGREEMENTtrue环境变量、当前用户 UID非 Windows 平台启动转换器容器并阻塞等待其运行完成让转换器镜像内的程序把/in的模型渲染到/out。convert会把默认输出目录设为out对应-o的默认值其产出结构与转换器中的模板编排直接相关——你可以在仓库的 e2e 夹具目录中看到转换后生成的清单形态例如 bridge/expected-helm13 个 YAML与 bridge/expected-kubernetes15 个 YAML对应的输入样例在 bridge/compose.yaml包含两个服务、configs、secrets 与内外网 network 的典型 compose 模型。这些可作为你调整自有模板时的对照基准。常见问题与使用提示目标目录已存在怎么办create出于防误覆盖考虑会直接报错请更换新的输出PATH或先自行处理掉旧目录后再执行。依赖镜像没有本地副本ContainerCreate依赖的是本机 Docker 引擎若From镜像未在本机会先经历拉取环节因此请保证网络可达或已提前docker pull。想给create指定源镜像但不确定名称可以通过docker compose bridge transformations list查看本机已识别带正确 LABEL的转换器镜像再把这些名字作为-f的取值。命令不是全局可用的bridge系列命令位于docker compose下请确认当前环境使用的 Compose 版本包含了该命令族若直接执行子命令不带任何子命令会输出帮助而非报错见 bridge.go。延伸阅读命令参考文档docker compose bridge、transformations、transformations create、transformations list、convert相关源码命令行定义 cmd/compose/bridge.go、转换器实现 pkg/bridge/transformers.go、转换主流程 pkg/bridge/convert.go测试用例cmd/compose/bridge_test.go含参数校验、未知子命令拒绝等场景转换产物样例pkg/e2e/fixtures/bridge/ 下的 compose 输入与 expected-helm / expected-kubernetes 输出目录【免费下载链接】composeDefine and run multi-container applications with Docker项目地址: https://gitcode.com/GitHub_Trending/compose/compose创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
docker compose bridge transformations create 命令详解：从零创建自定义 Compose 转换模板
docker compose bridge transformations create 命令详解从零创建自定义 Compose 转换模板【免费下载链接】composeDefine and run multi-container applications with Docker项目地址: https://gitcode.com/GitHub_Trending/compose/compose本指南聚焦 Docker Compose 的bridge扩展命令族中的docker compose bridge transformations create讲解如何使用该命令基于既有“转换器镜像transformation image”生成一套可编辑的转换模板目录为把 Compose 应用模型转换为 Kubernetes 清单、Helm Chart 或其他目标模型奠定基础。读完本文你将掌握该命令的完整语法、参数含义、底层容器化实现机制以及如何把生成的模板再次交还给bridge convert使用。命令定位transformations 管理子命令的一员在 Docker Compose 中docker compose bridge是“将 Compose 文件转换为另一种模型Convert compose files into another model”的命令族由 bridge.go 注册包含两个子命令docker compose bridge convert把 Compose 文件转换为 Kubernetes 清单、Helm Chart 或其他模型docker compose bridge transformations管理“转换器镜像”。而docker compose bridge transformations下又管理着两类操作见 compose_bridge_transformations.md子命令说明create创建一个新的转换模板transformationlist别名ls列出当前可用的转换器其中create解决的是这样一个问题convert执行转换时依赖一组镜像中的模板文件若你想自定义目标输出的生成规则就需要先有一份属于自己的模板骨架。create正是把某个现成转换器镜像内置的/templates目录“复制”到本地目录并顺带生成对应的Dockerfile让你可以在此基础上修改并重新构建为自有转换器镜像。命令语法与必选参数根据命令的 usage 定义见 docker_compose_bridge_transformations_create.yamldocker compose bridge transformations create [OPTION] PATHPATH是唯一的位置参数、且必须恰好提供一个它是新转换模板的输出目录。代码中使用cobra.ExactArgs(1)强约束参数个数见 bridge.go一旦缺失或传入多余参数命令都会报错并提示requires 1 argument该行为有测试用例覆盖见 bridge_test.go。未带任何子命令时transformations/bridge会直接输出帮助信息传入未知子命令则报错并返回退出码 1。PATH会被os.Stat检查若该目录已经存在命令会直接失败并返回错误output folder PATH already exists见 transformers.go这是刻意的“防覆盖”设计——它保证你不会误覆盖已有模板。选项详解该命令的选项在本参考文档中登记如下核心来自 compose_bridge_transformations_create.mdNameTypeDefaultDescription--dry-runboolfalseExecute command in dry run mode-f,--fromstringdocker/compose-bridge-kubernetesExisting transformation to copy-f, --from指定要复制的源转换器镜像该选项声明为字符串类型语义是“从哪个已存在的转换器镜像复制模板”。当未显式传入时CreateTransformer内部会将From置为常量DefaultTransformerImage docker/compose-bridge-kubernetes见 transformers.go。也就是说默认情况下你会基于官方 Kubernetes 转换器镜像派生一份模板。传入自定义值时你既可以指向本地已构建的镜像名也可以指向远端仓库的镜像——dockerCli.Client().ContainerCreate会按镜像名直接创建容器若镜像尚不存在则会触发拉取流程。--dry-run继承自根命令的全局开关--dry-run并非create独有而是docker compose根命令注册的持久化标志persistent flag默认值为false在所有子命令上可见注册位置见 compose.go因此参考文档中把它归类为 inherited option。就其本身含义而言该开关用于“以预演模式执行命令不产生实际变更”。注意create命令体本身并没有再次声明或读取该开关的逻辑其实际生效范围取决于具体命令实现。底层实现一条“镜像 → 容器 → 本地目录”的复制链create命令的入口CreateTransformer见 transformers.go并不像普通文件复制那么简单而是借助 Docker 引擎完成一次容器化模板抽取其关键步骤可拆解如下规范化目标路径将PATH转换为绝对路径并先用os.MkdirAll创建PATH/templates子目录权限0744。创建临时容器用源镜像From调用ContainerCreate创建一个容器实例。注意此容器无需任何命令参数——它的存在只是为了暴露镜像内预置的模板目录。延迟清理通过defer确保无论后续成功与否都会用ContainerRemove(Force: true)强制删除这个临时容器。拷贝模板目录调用CopyFromContainer把容器内固定路径/templates源码常量templatesPath整体以 tar 流方式读回再通过archive.CopyTo解包写入本地目标目录。这里解释了为什么输出目录中会得到与镜像内一致的templates/结构。生成配套 Dockerfile在目标目录中写一个固定内容的DockerfileFROM docker/compose-bridge-transformer LABEL com.docker.compose.bridgetransformation COPY templates /templates输出提示最后向标准输出打印成功消息形如Transformer created in abs path。从镜像标签看“转换器”的识别机制生成的Dockerfile中有两处非常关键LABEL com.docker.compose.bridgetransformation这正是本仓库用来识别“转换器镜像”的约定标签。常量TransformerLabel com.docker.compose.bridge见 transformers.go。COPY templates /templates保证最终镜像在容器内仍然遵循/templates这一约定路径。docker compose bridge transformations list正是基于该标签做筛选它对 Docker 引擎上的全部镜像执行ImageList并用 label 过滤器com.docker.compose.bridgetransformation找出所有转换器镜像见 transformers.go。因此你基于create产出物重新docker build的镜像只要保留上述 LABEL就会被list识别并纳入管理。使用新模板从 create 到 convert 的完整闭环create产出的本地目录本身是编辑用的“工作区”要让自定义模板真正参与转换需要经历构建再消费的过程在PATH/templates中修改或新增模板文件使其符合你对目标输出例如 Kubernetes 清单的期望在PATH目录下执行docker build得到自定义转换器镜像记得继承模板中的 LABEL使用docker compose bridge convert消费它。该命令的-t, --transformation选项是 stringArray 类型允许指定一个或多个转换器镜像未指定时同样默认使用docker/compose-bridge-kubernetes见 convert.go 与 compose_bridge_convert.md。从源码看convert在真正执行转换时的工作方式convert.go恰好是create的“逆向过程”它把解析出的 Compose 模型以 YAML 挂载为容器内/in/compose.yaml把--output目录挂载为容器内/out若有--templates目录还会挂载到/templates随后以LICENSE_AGREEMENTtrue环境变量、当前用户 UID非 Windows 平台启动转换器容器并阻塞等待其运行完成让转换器镜像内的程序把/in的模型渲染到/out。convert会把默认输出目录设为out对应-o的默认值其产出结构与转换器中的模板编排直接相关——你可以在仓库的 e2e 夹具目录中看到转换后生成的清单形态例如 bridge/expected-helm13 个 YAML与 bridge/expected-kubernetes15 个 YAML对应的输入样例在 bridge/compose.yaml包含两个服务、configs、secrets 与内外网 network 的典型 compose 模型。这些可作为你调整自有模板时的对照基准。常见问题与使用提示目标目录已存在怎么办create出于防误覆盖考虑会直接报错请更换新的输出PATH或先自行处理掉旧目录后再执行。依赖镜像没有本地副本ContainerCreate依赖的是本机 Docker 引擎若From镜像未在本机会先经历拉取环节因此请保证网络可达或已提前docker pull。想给create指定源镜像但不确定名称可以通过docker compose bridge transformations list查看本机已识别带正确 LABEL的转换器镜像再把这些名字作为-f的取值。命令不是全局可用的bridge系列命令位于docker compose下请确认当前环境使用的 Compose 版本包含了该命令族若直接执行子命令不带任何子命令会输出帮助而非报错见 bridge.go。延伸阅读命令参考文档docker compose bridge、transformations、transformations create、transformations list、convert相关源码命令行定义 cmd/compose/bridge.go、转换器实现 pkg/bridge/transformers.go、转换主流程 pkg/bridge/convert.go测试用例cmd/compose/bridge_test.go含参数校验、未知子命令拒绝等场景转换产物样例pkg/e2e/fixtures/bridge/ 下的 compose 输入与 expected-helm / expected-kubernetes 输出目录【免费下载链接】composeDefine and run multi-container applications with Docker项目地址: https://gitcode.com/GitHub_Trending/compose/compose创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考