Docker Run 转 Compose

这个 Docker 页面解决什么问题

在容器化部署初期，很多人习惯用 docker run 一条长命令启动服务。但随着项目复杂度增长，这条命令会越来越长：端口、卷、环境变量、重启策略、网络、资源限制……手写和记忆这些参数极易出错，且难以在团队中复现。

本工具将冗长的 docker run 命令自动转换为声明式的 docker-compose.yml 格式。YAML 文件天然适合版本控制、团队协作和跨环境复现，彻底告别“在我机器上能跑”的问题。

典型应用场景包括：本地开发环境一键启动（数据库 + 后端 + 前端）、CI/CD 流水线中的标准化容器编排、测试环境的快速重建、以及从单容器试水向多容器架构迁移的过渡阶段。

需要注意：本转换器覆盖绝大多数日常参数，但部分高级运行时选项（如 GPU 访问、特权模式、高级卷挂载语法）可能需要你在生成结果的基础上手动补充。

为什么使用 Docker Compose

Compose 使用声明式 YAML 文件定义整个容器栈，这意味着你的基础设施配置可以像代码一样纳入版本控制。团队成员只需 docker compose up 就能获得完全一致的运行环境，无需记忆和传播冗长的命令行参数。

此外，Compose 支持服务依赖声明（depends_on）、健康检查、自动重启策略、环境变量隔离等高级功能，这些在纯 docker run 模式下要么无法表达，要么需要额外的脚本逻辑才能实现。

如何使用此工具

将完整的 docker run 命令（包含 docker run 开头或仅包含参数和镜像名）粘贴到右侧输入区域。点击”转换为 Compose”，左侧面板即刻显示生成的 docker-compose.yml。点击”复制 YAML”存入剪贴板，随后在项目目录保存为文件，运行 docker compose up -d 即可启动。

对于多容器场景，请分别转换每个服务，然后手动合并到单个 Compose 文件的 services: 键下。建议为每个服务命名清晰的 service 名称，方便后续通过 docker compose logs 查看日志。

在生产环境部署前，请仔细核对生成的卷路径、环境变量及网络配置。建议先用 docker compose config 命令验证 YAML 语法，确认无误后再执行 docker compose up -d。

上线前注意事项

• 卷路径核对：转换器会原样保留 docker run 中的 -v 路径，请确认宿主机路径存在且 Docker 进程有读写权限。生产环境建议尽量使用命名卷（volumes: 而非绑定挂载），避免宿主机路径耦合。
• 网络模式选择：docker run 的 --network 会被映射为 network_mode。若多服务需要相互通信，建议使用 Compose 默认网络或自定义 bridge 网络，而非 host 模式。
• 敏感信息处理：转换器会将 -e 环境变量原样写入 YAML，这意味着密码、密钥等敏感信息可能暴露在文件中。生产环境请改用 .env 文件、Docker secrets 或外部配置中心。
• Compose 版本兼容性：生成结果使用 version: "3.8" 格式。请确认目标环境的 Docker Engine 和 docker compose 插件版本支持此格式，旧版 Docker 可能需要降级为 "3.3"。
• 单端口写法：-p 80（只写容器端口）会原样转换为 ports: - "80"，含义是宿主机随机分配端口映射到容器 80，而非固定 80:80。若需要固定宿主机端口，请在原命令中写完整的 宿主机:容器 形式（如 -p 80:80）。
• 健康检查缺失：docker run 命令通常不包含健康检查定义，转换结果也不会自动添加。建议在生产部署前手动为关键服务配置 healthcheck，配合 depends_on 实现启动顺序控制。
• 镜像与构建上下文：转换器假设您使用已有镜像（image）。如果项目需要从 Dockerfile 构建，请将 image 替换为 build: ./ 并确保构建上下文路径正确。