version: '3.9'
services:
web:
image: nginx:alpine
container_name: web
restart: unless-stopped
networks:
- mynet
ports:
- '8080:80'
- '443:443'
environment:
DB_HOST: db
DB_USER: root
volumes:
- /data:/var/www
关于 docker run 转 compose
docker run 转 compose 工具把一条冗长的 docker run 命令行自动改写成结构清晰的 docker-compose.yml，把镜像、端口映射、环境变量、挂载卷与重启策略整理成 YAML 段落。再也不用手动对照参数去拼 YAML，粘贴命令即可拿到可直接使用的编排文件，并保留注释位置便于补充说明。转换在浏览器本地完成，命令内容不上传，适合处理含环境变量与挂载路径的配置。对把临时容器固化为可版本化服务的开发与运维很实用，也让团队成员能直接 review 容器的最终运行形态而不必解析长命令。生成后还能顺手补上 healthcheck 与依赖顺序，让容器编排在重启时更稳妥；转换在本地完成命令不上传，对把临时容器固化为可版本化服务的开发与运维很实用，也让团队成员能直接 review 容器最终运行形态，而不必去解析一条冗长难读的命令。
转换的核心是把一次性的启动参数变成一份可重复执行的声明，理解这一点才能判断哪些参数该保留。命令行里的端口映射、卷挂载、环境变量与重启策略都能直接对应到声明文件；而像「先执行某个脚本再启动」这类一次性动作，则更适合放在镜像构建里，而不是在声明文件里堆命令。因此转换过程也是一次结构梳理。
卷与端口的选择需要区分持久数据与临时数据，否则容易丢数据或留下垃圾。映射到宿主机的目录能在容器重建后保留内容，适合数据库与上传文件；而未映射的路径随容器删除而消失，适合缓存与临时产物。因此转换时应当逐项判断每个路径属于哪一类，而不是把命令行里的挂载原样搬过来。
依赖与启动顺序容易被误解，因为声明的依赖只表示「谁先启动」，不保证「谁已就绪」。数据库容器启动到能够接受连接之间还有一段时间，若应用在其就绪前就开始连接，仍会失败并重试。因此在实际部署里，配合健康检查与重试逻辑比单纯声明依赖顺序更可靠，声明只解决启动次序这一层。
环境变量的处理涉及凭据管理，这一层应当在转换时就规划好。把数据库口令直接写进声明文件会让它进入版本管理，任何有仓库权限的人都能看到；更稳妥的做法是从宿主环境或独立文件读取，并把含凭据的文件排除在版本管理之外。因此转换不只是语法翻译，也是一次凭据梳理。
网络设置决定了容器之间能否按名称互相访问。同一自定义网络内的容器可以用服务名互相解析，而默认网络下这种名称解析并不可靠；同时宿主机端口是否需要暴露给外部，也是一个独立决定——内部互相访问的容器不需要向宿主机开放端口。因此划清「内部通信」与「对外暴露」两条边界，能减少不必要的暴露面。
最后，它与更复杂的编排体系有明确分工，不必一开始就用最重的方案。单机多容器、开发环境与小型部署用声明文件已经足够；而当需要多节点调度、自动扩缩容与滚动升级时，才需要引入集群编排。因此在转换时应当想清楚当前处于哪个阶段，避免为尚未出现的问题引入过重的复杂度。
实现原理
转换把命令行选项映射到编排文件的字段。两者语义相近但并非一一对应：端口写法的先后顺序、挂载路径的基准目录、以及环境变量的列表形式与映射形式都有差别，其中「环境变量写成列表会丢掉含等号的值」最容易造成运行时才发现的问题。少数只有命令行才有的能力需要额外配置承载。
-p 8080:80 -v ./data:/app/data -e A=b=cports 写 "8080:80"（主机在前）；挂载以文件所在目录为基准；环境变量须用映射形式，否则 A=b=c 会被截断使用方法
- 打开「docker run 转 compose」
- 选择源格式与目标格式
- 根据需要调整输出选项
- 点击「转换」按钮，结果实时显示
- 复制或导出结果
使用场景
- 固化部署 — 把临时的 docker run 转成 compose 文件，纳入仓库做版本管理。
- 迁移环境 — 把开发机上的运行命令转成 compose，在测试或生产环境一键复现。
- 梳理参数 — 把堆叠的命令行参数结构化，看清端口、卷和环境变量映射。
- 多容器编排 — 把几条独立的 run 命令转成 compose 服务，统一管理依赖。
- 文档沉淀 — 把口口相传的启动命令转成可读 YAML，写进部署文档。
常见问题
支持哪些 docker run 参数？
常用的 -p 端口、-v 卷、-e 环境变量、--name、--network、--restart、-d 等都能识别并映射到 compose 对应字段。极少见或最新加入的参数可能需要手动补充。
生成的是哪个 compose 版本？
通常输出兼容性较好的 v3 结构。你可以根据自己的 Docker 环境微调 version 字段，或删除该字段使用 Compose 规范的默认行为。
多个 -e 环境变量会怎么处理？
每个 -e 都会被解析为 environment 列表中的一项；若值里含等号或空格，请确保原命令已正确引号包裹，工具按原样保留。
能反向把 compose 转回 run 吗？
本工具目前只做 run 到 compose 的单向转换。反向转换涉及多服务拆分，逻辑复杂，暂不支持。
转换后能直接 docker compose up 吗？
大多数情况可以，但建议生成后通读一遍 YAML，确认卷路径、镜像标签和网络名称符合目标环境，再启动。
转换后的 compose 文件启动报错，但 docker run 能正常跑？
常见差异有三处：端口写法在命令行里是主机端口在前，compose 里同样是「主机:容器」但顺序写反会变成监听在错误端口；挂载路径在命令行里常用相对路径，compose 会以文件所在目录为基准，相对路径含义不同；环境变量在命令行里是逐个传递，compose 若写成列表形式会丢掉含等号的值，应使用映射形式。逐项核对这三处基本能覆盖多数报错。
compose 能表达 docker run 的全部选项吗？
大部分能，但少数只有命令行才有的能力需要改写：一次性的网络与设备映射、依赖宿主内核参数的选项、以及调试用途的覆盖命令，都需要转成 compose 的对应字段或改用额外的配置文件。转换后应逐项确认那些在 compose 中没有直接对应的选项没有被静默丢弃，尤其是安全相关的能力与权限设置。
生成的 compose 文件里镜像标签丢了？
docker run 命令里若没写 tag（如 nginx 而非 nginx:1.25），compose 文件也只能给 image: nginx，拉取时会用 latest。显式补上标签再转换，避免「本地正常、CI 拉到新版挂掉」这类隐性故障。