容器编排开发工具CLI【免费下载链接】podman-composea script to run docker-compose.yml using podman项目地址https://gitcode.com/gh_mirrors/po/podman-compose点击查看免费下载本文基于 podman-compose 仓库的 docs/Changelog-1.3.0.md 整理围绕 2025-01-07 发布的 1.3.0 版本系统梳理其 6 项 Bug 修复、13 项新特性与 1 项兼容性声明并结合 podman_compose.py 源码与仓库内集成测试深入解读每一项变更的底层实现与真实使用场景。读完本文你将掌握 1.3.0 中x-podman.no_hosts、default_net_behavior_compat、default_net_name_compat等关键扩展的配置方法理解depends_on.condition、build 属性labels/platform/ssh/cache_from/cache_to的正确用法并能立即在现有 compose 项目上验证这些能力。版本概览1.3.0 的定位podman-compose 1.3.0 于 2025-01-07 发布这是一个以兼容性收敛 构建链路补全为主题的版本。它同时面向两类用户从 docker compose 迁移的用户通过default_net_behavior_compat、default_net_name_compat两个开关消除了默认网络创建行为与命名规则上的差异重度使用 BuildKit 式构建特性的用户补齐了platform、ssh、cache_from、cache_to、build labels 等构建参数。此外该版本还宣布正式兼容 Python 3.13为使用最新 Python 运行环境的用户提供了明确的支撑。Bug 修复稳定性与错误检测的收敛1. 支持事实标准备选 Dockerfile 文件名如Containerfile在 1.3.0 之前未显式指定dockerfile时podman-compose 对构建文件的探测能力有限。本次修复后当服务构建块中未给出dockerfile字段时container_to_build_args 会按以下顺序在构建上下文目录中探测候选文件名dockerfile_alts [ Containerfile, ContainerFile, containerfile, Dockerfile, DockerFile, dockerfile, ]即大小写敏感的Containerfile/ContainerFile/containerfile与Dockerfile/DockerFile/dockerfile共六种命名都会自动识别而显式指定dockerfile:字段含大小写变体的路径也会被正常拼接并校验。对应的windows_custom_dockerfile_name.bugfix新闻片段也印证了这一修复方向。2. 不再重复创建已存在的 Pod此前在特定场景下podman-compose up会对同一个 Pod 发起多次创建尝试导致报错或状态错乱。1.3.0 修复了该问题使得 Pod 创建具备幂等性。从 compose_down 中可以看到Pod 的清理同样以逐个删除的方式与容器生命周期严格配对保证up/down往返过程中 Pod 的创建与销毁次数一致。3. 对 docker-compose.yml 符号链接的处理对齐 docker compose当docker-compose.yml本身是符号链接时docker compose 与 podman-compose 对项目目录project directory的判定存在差异。1.3.0 修复了这一行为差异使基于符号链接引入 compose 文件时卷绑定、相对路径解析等项目目录相关逻辑与 docker compose 保持一致。仓库中的 tests/integration/filesystem 目录含compose_symlink与compose_symlink_dest两个用例即为该行为的回归测试场景。4. 修复超长无换行日志导致的卡死当容器输出超长且不带换行符的日志行时1.3.0 之前的版本可能因缓冲逻辑缺陷而冻结。该修复确保日志流式输出在极端输入下依然可用与 tests/integration/longlog 中的多字节长日志测试docker-compose-multibyte.yml、test_long_log.py相互印证。5. 支持network_mode: none1.3.0 使服务声明network_mode: none时可以正确生效。在 container_to_podman_args 中网络模式解析分支显式处理net none同时 network 参数构造 也把none列入不触发额外网络参数的模式白名单从而避免为none模式错误创建网络。6. 拒绝network_mode与networks同时出现的非法定义Compose 规范中服务级network_mode如host、none、bridge与networks列表是互斥的。1.3.0 加强了错误检测若服务定义同时包含这两个键将直接报错而不是静默忽略其一把配置错误提前暴露在config/up阶段。相关校验逻辑体现在 网络参数构造分支 对模式与冒号语法的解析中。新特性构建、网络与依赖编排1. 构建链路补全platform、ssh、cache_from、cache_to、build labels1.3.0 一次性补齐了构建阶段的多项 BuildKit 风格能力全部实现在 container_to_build_args 中特性配置字段build 下生成的 podman 参数源码位置构建标签labels字典或列表--label kvpodman_compose.py目标平台platform--platform 值podman_compose.pySSH 转发ssh如default、key/path--ssh 值podman_compose.py缓存来源cache_from列表--cache-from 镜像podman_compose.py缓存导出cache_to列表--cache-to 镜像podman_compose.py典型配置示例services: app: build: context: . platform: linux/amd64 ssh: - default labels: - org.example.labelmy-app cache_from: - myapp:cache cache_to: - myapp:cache需要说明ssh中如果引用的是本机密钥文件podman-compose 会通过adjust_build_ssh_key_paths对路径进行适配这些能力与仓库中的 tests/integration/build_labels、tests/integration/build_ssh含id_ed25519_dummy测试密钥用例一一对应。2.depends_on.condition条件依赖正式生效1.3.0 之前depends_on只按服务已启动的朴素语义执行本次更新后若服务声明了条件podman-compose 会真正遵循它。核心实现位于 ServiceDependencyCondition 枚举class ServiceDependencyCondition(Enum): HEALTHY healthy RUNNING running SERVICE_COMPLETED_SUCCESSFULLY service_completed_successfully # 以及 configured/created/exited/initialized/paused/removing/stopped/stopping/unhealthy ...同时提供了 docker compose 语义到 podman 语义的映射表podman_compose.pydocker_to_podman_cond { service_healthy: ServiceDependencyCondition.HEALTHY, service_started: ServiceDependencyCondition.RUNNING, service_completed_successfully: ServiceDependencyCondition.SERVICE_COMPLETED_SUCCESSFULLY, }因此你可以直接沿用 docker compose 的条件依赖写法services: web: depends_on: db: condition: service_healthy migrate: condition: service_completed_successfully单元测试 tests/unit/test_service_dependency_condition.py 与 tests/unit/test_depends_on.py 覆盖了这些条件的解析与递归展开逻辑。同时注意条件依赖的等待依赖容器进入指定状态的能力与仓库中 wait_for_container_running_healthy 的--conditionhealthy实现配合使用。3.x-podman.no_hosts关闭容器 hosts 注入1.3.0 新增x-podman.no_hosts设置用于向podman run传递--no-hosts。在 容器参数构造 中if cnt.get(x-podman.no_hosts, False): podman_args.extend([--no-hosts])同时 CLI 层面也提供了同名的--no-hosts全局开关podman_compose.py 与 参数解析器两者都会把该标记写入服务配置。配置方式services: app: image: busybox x-podman.no_hosts: true或者命令行podman-compose --no-hosts up。仓库提供了对应集成测试 tests/integration/no_hosts/compose.yaml。4. 默认网络行为与命名的 docker compose 兼容开关这是 1.3.0 网络侧最重要的两个特性均为通过x-podman全局字典配置的特性开关枚举定义见 XPodmanSettingKey。default_net_behavior_compat默认网络创建行为对齐 docker compose开启前若 compose 文件未声明任何networkspodman-compose 按自身逻辑选定默认网络podman_compose.py开启后无论文件是否声明网络都保证存在名为default的默认网络与 docker compose 的行为一致podman_compose.py。x-podman: default_net_behavior_compat: true services: app: image: busyboxdefault_net_name_compat默认网络命名对齐 docker compose关闭默认时默认网络按 podman-compose 的format_name规则命名开启后网络名改为项目名去除-后拼接网络名的 docker compose 风格podman_compose.pyif default_net_name_compat is True: return compose.join_name_parts(compose.project_name.replace(-, ), net)配置示例x-podman: default_net_name_compat: true对应集成测试见 tests/integration/default_net_behavior覆盖no_nets、one_net、two_nets、with_default及其_compat变体与 tests/integration/name_separator_compat。5.device_cgroup_rules设备 cgroup 规则服务级新增device_cgroup_rules属性支持用于为容器声明设备 cgroup 规则。源码中该列表被逐条转换为 podman 的设备参数podman_compose.py。配置示例services: app: image: busybox device_cgroup_rules: - c 1:* rmw该能力让需要精细控制设备访问权限如 USB、字符设备的场景可以脱离手工podman run参数完成声明式配置。6.podman-compose down清理自定义网络1.3.0 让down命令在停止并移除容器、Pod 之后一并删除本次启动所创建的网络compose_downfor pod in compose.pods: await compose.podman.run([], pod, [rm, pod[name]]) for network in await compose.podman.network_ls(): await compose.podman.run([], network, [rm, network])注意该行为会作用于当前项目名下创建的网络配合--volumes、--rmi等参数可实现完整的栈级清理。相关行为测试见 tests/integration/compose_down_behavior。7. 网络作用域服务别名network scoped aliases新增对网络作用域别名的支持即不同网络中的服务可以拥有各自独立的别名避免别名在多个网络间冲突。这一能力与 tests/integration/network_scoped_aliases/docker-compose.yaml 的集成测试对应配置方式延续 compose 规范services: app: image: busybox networks: net-a: aliases: - app-alias net-b: aliases: - backend-alias8. 网络级mac_address属性1.3.0 支持在 network 映射级指定mac_address。源码在 网络参数构造 中做了完整的冲突检测若服务级与网络级同时指定mac_address且取值不一致会明确报错若仅服务级指定则自动应用到第一个网络。配置示例services: app: image: busybox networks: net-a: mac_address: 02:42:ac:11:00:029. 用服务环境变量完成变量替换本次更新允许在服务解析阶段使用该服务自身的environment进行变量替换使配置可以引用服务内部注入的环境值提升了extends、env_file与environment组合场景下的表达力。兼容性声明Python 3.13Misc 部分宣布 podman-compose 1.3.0 兼容 Python 3.13。仓库工程配置 pyproject.toml 与 setup.cfg 中维护了对应的元数据与依赖声明结合 requirements.txt 可确认运行 1.3.0 所需的最小依赖集。使用 Python 3.13 虚拟环境的用户可以直接pip install .或按 README.md 指引安装。小结与升级建议综合来看1.3.0 是一次迁移友好型升级从 docker compose 迁移建议开启default_net_behavior_compat: true与default_net_name_compat: true并可直接使用condition: service_healthy/service_completed_successfully的条件依赖追求构建效率在 build 块中组合使用cache_from/cache_to、platform、ssh并借助 build labels 做镜像元数据标注追求严格配置校验享受network_mode与networks互斥检查带来的早期报错避免运行时才发现网络配置冲突。相关变更细节与后续演进可继续查阅 docs/Mappings.mdcompose 属性到 podman 参数的映射总表、docs/Extensions.mdx-podman扩展约定以及 docs/Changelog-1.4.0.md 等后续版本记录。赞分享容器编排开发工具CLI【免费下载链接】podman-composea script to run docker-compose.yml using podman项目地址https://gitcode.com/gh_mirrors/po/podman-compose点击查看免费下载相关推荐podman-compose 1.5.0 版本特性详解兼容性、系统服务、密钥与网络增强实战指南podman compose 1.5.0 版本特性详解兼容性、系统服务、密钥与网络增强实战指南 本文以 podman compose 1.5.0 的官方变更日容器编排开发工具CLIPodman Compose 多网络容器测试解析验证容器同时接入多个 Compose 网络Podman Compose 多网络容器测试解析验证容器同时接入多个 Compose 网络 容器接入多个网络是 Compose 工作负载中常见的拓扑需求例如容器运行时云原生CLIpodman-compose 扩展字段x-podman完全指南从容器管理到网络模式与 Docker Compose 兼容性podman compose 扩展字段x podman完全指南从容器管理到网络模式与 Docker Compose 兼容性 导读 本文聚焦 podman容器编排开发工具CLI上一篇RSuite Sidenav 侧边导航组件基础用法与实践指南下一篇在 VSCode 状态栏里看小说摸鱼插件 Thief-Book 三分钟上手创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/10 14:13:31 · 阅读 1.2k podman-compose 1.3.0 发布详解：构建增强、网络兼容与依赖条件解析
容器编排开发工具CLI【免费下载链接】podman-composea script to run docker-compose.yml using podman项目地址https://gitcode.com/gh_mirrors/po/podman-compose点击查看免费下载本文基于 podman-compose 仓库的 docs/Changelog-1.3.0.md 整理围绕 2025-01-07 发布的 1.3.0 版本系统梳理其 6 项 Bug 修复、13 项新特性与 1 项兼容性声明并结合 podman_compose.py 源码与仓库内集成测试深入解读每一项变更的底层实现与真实使用场景。读完本文你将掌握 1.3.0 中x-podman.no_hosts、default_net_behavior_compat、default_net_name_compat等关键扩展的配置方法理解depends_on.condition、build 属性labels/platform/ssh/cache_from/cache_to的正确用法并能立即在现有 compose 项目上验证这些能力。版本概览1.3.0 的定位podman-compose 1.3.0 于 2025-01-07 发布这是一个以兼容性收敛 构建链路补全为主题的版本。它同时面向两类用户从 docker compose 迁移的用户通过default_net_behavior_compat、default_net_name_compat两个开关消除了默认网络创建行为与命名规则上的差异重度使用 BuildKit 式构建特性的用户补齐了platform、ssh、cache_from、cache_to、build labels 等构建参数。此外该版本还宣布正式兼容 Python 3.13为使用最新 Python 运行环境的用户提供了明确的支撑。Bug 修复稳定性与错误检测的收敛1. 支持事实标准备选 Dockerfile 文件名如Containerfile在 1.3.0 之前未显式指定dockerfile时podman-compose 对构建文件的探测能力有限。本次修复后当服务构建块中未给出dockerfile字段时container_to_build_args 会按以下顺序在构建上下文目录中探测候选文件名dockerfile_alts [ Containerfile, ContainerFile, containerfile, Dockerfile, DockerFile, dockerfile, ]即大小写敏感的Containerfile/ContainerFile/containerfile与Dockerfile/DockerFile/dockerfile共六种命名都会自动识别而显式指定dockerfile:字段含大小写变体的路径也会被正常拼接并校验。对应的windows_custom_dockerfile_name.bugfix新闻片段也印证了这一修复方向。2. 不再重复创建已存在的 Pod此前在特定场景下podman-compose up会对同一个 Pod 发起多次创建尝试导致报错或状态错乱。1.3.0 修复了该问题使得 Pod 创建具备幂等性。从 compose_down 中可以看到Pod 的清理同样以逐个删除的方式与容器生命周期严格配对保证up/down往返过程中 Pod 的创建与销毁次数一致。3. 对 docker-compose.yml 符号链接的处理对齐 docker compose当docker-compose.yml本身是符号链接时docker compose 与 podman-compose 对项目目录project directory的判定存在差异。1.3.0 修复了这一行为差异使基于符号链接引入 compose 文件时卷绑定、相对路径解析等项目目录相关逻辑与 docker compose 保持一致。仓库中的 tests/integration/filesystem 目录含compose_symlink与compose_symlink_dest两个用例即为该行为的回归测试场景。4. 修复超长无换行日志导致的卡死当容器输出超长且不带换行符的日志行时1.3.0 之前的版本可能因缓冲逻辑缺陷而冻结。该修复确保日志流式输出在极端输入下依然可用与 tests/integration/longlog 中的多字节长日志测试docker-compose-multibyte.yml、test_long_log.py相互印证。5. 支持network_mode: none1.3.0 使服务声明network_mode: none时可以正确生效。在 container_to_podman_args 中网络模式解析分支显式处理net none同时 network 参数构造 也把none列入不触发额外网络参数的模式白名单从而避免为none模式错误创建网络。6. 拒绝network_mode与networks同时出现的非法定义Compose 规范中服务级network_mode如host、none、bridge与networks列表是互斥的。1.3.0 加强了错误检测若服务定义同时包含这两个键将直接报错而不是静默忽略其一把配置错误提前暴露在config/up阶段。相关校验逻辑体现在 网络参数构造分支 对模式与冒号语法的解析中。新特性构建、网络与依赖编排1. 构建链路补全platform、ssh、cache_from、cache_to、build labels1.3.0 一次性补齐了构建阶段的多项 BuildKit 风格能力全部实现在 container_to_build_args 中特性配置字段build 下生成的 podman 参数源码位置构建标签labels字典或列表--label kvpodman_compose.py目标平台platform--platform 值podman_compose.pySSH 转发ssh如default、key/path--ssh 值podman_compose.py缓存来源cache_from列表--cache-from 镜像podman_compose.py缓存导出cache_to列表--cache-to 镜像podman_compose.py典型配置示例services: app: build: context: . platform: linux/amd64 ssh: - default labels: - org.example.labelmy-app cache_from: - myapp:cache cache_to: - myapp:cache需要说明ssh中如果引用的是本机密钥文件podman-compose 会通过adjust_build_ssh_key_paths对路径进行适配这些能力与仓库中的 tests/integration/build_labels、tests/integration/build_ssh含id_ed25519_dummy测试密钥用例一一对应。2.depends_on.condition条件依赖正式生效1.3.0 之前depends_on只按服务已启动的朴素语义执行本次更新后若服务声明了条件podman-compose 会真正遵循它。核心实现位于 ServiceDependencyCondition 枚举class ServiceDependencyCondition(Enum): HEALTHY healthy RUNNING running SERVICE_COMPLETED_SUCCESSFULLY service_completed_successfully # 以及 configured/created/exited/initialized/paused/removing/stopped/stopping/unhealthy ...同时提供了 docker compose 语义到 podman 语义的映射表podman_compose.pydocker_to_podman_cond { service_healthy: ServiceDependencyCondition.HEALTHY, service_started: ServiceDependencyCondition.RUNNING, service_completed_successfully: ServiceDependencyCondition.SERVICE_COMPLETED_SUCCESSFULLY, }因此你可以直接沿用 docker compose 的条件依赖写法services: web: depends_on: db: condition: service_healthy migrate: condition: service_completed_successfully单元测试 tests/unit/test_service_dependency_condition.py 与 tests/unit/test_depends_on.py 覆盖了这些条件的解析与递归展开逻辑。同时注意条件依赖的等待依赖容器进入指定状态的能力与仓库中 wait_for_container_running_healthy 的--conditionhealthy实现配合使用。3.x-podman.no_hosts关闭容器 hosts 注入1.3.0 新增x-podman.no_hosts设置用于向podman run传递--no-hosts。在 容器参数构造 中if cnt.get(x-podman.no_hosts, False): podman_args.extend([--no-hosts])同时 CLI 层面也提供了同名的--no-hosts全局开关podman_compose.py 与 参数解析器两者都会把该标记写入服务配置。配置方式services: app: image: busybox x-podman.no_hosts: true或者命令行podman-compose --no-hosts up。仓库提供了对应集成测试 tests/integration/no_hosts/compose.yaml。4. 默认网络行为与命名的 docker compose 兼容开关这是 1.3.0 网络侧最重要的两个特性均为通过x-podman全局字典配置的特性开关枚举定义见 XPodmanSettingKey。default_net_behavior_compat默认网络创建行为对齐 docker compose开启前若 compose 文件未声明任何networkspodman-compose 按自身逻辑选定默认网络podman_compose.py开启后无论文件是否声明网络都保证存在名为default的默认网络与 docker compose 的行为一致podman_compose.py。x-podman: default_net_behavior_compat: true services: app: image: busyboxdefault_net_name_compat默认网络命名对齐 docker compose关闭默认时默认网络按 podman-compose 的format_name规则命名开启后网络名改为项目名去除-后拼接网络名的 docker compose 风格podman_compose.pyif default_net_name_compat is True: return compose.join_name_parts(compose.project_name.replace(-, ), net)配置示例x-podman: default_net_name_compat: true对应集成测试见 tests/integration/default_net_behavior覆盖no_nets、one_net、two_nets、with_default及其_compat变体与 tests/integration/name_separator_compat。5.device_cgroup_rules设备 cgroup 规则服务级新增device_cgroup_rules属性支持用于为容器声明设备 cgroup 规则。源码中该列表被逐条转换为 podman 的设备参数podman_compose.py。配置示例services: app: image: busybox device_cgroup_rules: - c 1:* rmw该能力让需要精细控制设备访问权限如 USB、字符设备的场景可以脱离手工podman run参数完成声明式配置。6.podman-compose down清理自定义网络1.3.0 让down命令在停止并移除容器、Pod 之后一并删除本次启动所创建的网络compose_downfor pod in compose.pods: await compose.podman.run([], pod, [rm, pod[name]]) for network in await compose.podman.network_ls(): await compose.podman.run([], network, [rm, network])注意该行为会作用于当前项目名下创建的网络配合--volumes、--rmi等参数可实现完整的栈级清理。相关行为测试见 tests/integration/compose_down_behavior。7. 网络作用域服务别名network scoped aliases新增对网络作用域别名的支持即不同网络中的服务可以拥有各自独立的别名避免别名在多个网络间冲突。这一能力与 tests/integration/network_scoped_aliases/docker-compose.yaml 的集成测试对应配置方式延续 compose 规范services: app: image: busybox networks: net-a: aliases: - app-alias net-b: aliases: - backend-alias8. 网络级mac_address属性1.3.0 支持在 network 映射级指定mac_address。源码在 网络参数构造 中做了完整的冲突检测若服务级与网络级同时指定mac_address且取值不一致会明确报错若仅服务级指定则自动应用到第一个网络。配置示例services: app: image: busybox networks: net-a: mac_address: 02:42:ac:11:00:029. 用服务环境变量完成变量替换本次更新允许在服务解析阶段使用该服务自身的environment进行变量替换使配置可以引用服务内部注入的环境值提升了extends、env_file与environment组合场景下的表达力。兼容性声明Python 3.13Misc 部分宣布 podman-compose 1.3.0 兼容 Python 3.13。仓库工程配置 pyproject.toml 与 setup.cfg 中维护了对应的元数据与依赖声明结合 requirements.txt 可确认运行 1.3.0 所需的最小依赖集。使用 Python 3.13 虚拟环境的用户可以直接pip install .或按 README.md 指引安装。小结与升级建议综合来看1.3.0 是一次迁移友好型升级从 docker compose 迁移建议开启default_net_behavior_compat: true与default_net_name_compat: true并可直接使用condition: service_healthy/service_completed_successfully的条件依赖追求构建效率在 build 块中组合使用cache_from/cache_to、platform、ssh并借助 build labels 做镜像元数据标注追求严格配置校验享受network_mode与networks互斥检查带来的早期报错避免运行时才发现网络配置冲突。相关变更细节与后续演进可继续查阅 docs/Mappings.mdcompose 属性到 podman 参数的映射总表、docs/Extensions.mdx-podman扩展约定以及 docs/Changelog-1.4.0.md 等后续版本记录。赞分享容器编排开发工具CLI【免费下载链接】podman-composea script to run docker-compose.yml using podman项目地址https://gitcode.com/gh_mirrors/po/podman-compose点击查看免费下载相关推荐podman-compose 1.5.0 版本特性详解兼容性、系统服务、密钥与网络增强实战指南podman compose 1.5.0 版本特性详解兼容性、系统服务、密钥与网络增强实战指南 本文以 podman compose 1.5.0 的官方变更日容器编排开发工具CLIPodman Compose 多网络容器测试解析验证容器同时接入多个 Compose 网络Podman Compose 多网络容器测试解析验证容器同时接入多个 Compose 网络 容器接入多个网络是 Compose 工作负载中常见的拓扑需求例如容器运行时云原生CLIpodman-compose 扩展字段x-podman完全指南从容器管理到网络模式与 Docker Compose 兼容性podman compose 扩展字段x podman完全指南从容器管理到网络模式与 Docker Compose 兼容性 导读 本文聚焦 podman容器编排开发工具CLI上一篇RSuite Sidenav 侧边导航组件基础用法与实践指南下一篇在 VSCode 状态栏里看小说摸鱼插件 Thief-Book 三分钟上手创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考