🐳 docker-compose.yml 生成器

通过表单生成完整的 docker-compose.yml。支持多服务、端口、卷、环境变量、依赖、网络。

完全免费无需注册浏览器内完成 5 种语言深色模式

🔒 关于隐私

・所有输入仅在浏览器中处理
・无服务器上传、无存储日志、无数据库

预设

compose 文件 version 固定为 3.9

🌐 顶级定义

Volumes (每行一个)

Networks (每行一个)

Secrets (NAME=path)

📄 docker-compose.yml

📖 常见的坑

在表单里指定服务、端口、卷、环境变量、依赖关系、网络与 secrets，即可组装出可直接使用的 docker-compose.yml。处理全部在浏览器内完成，输入不会被传输。这个工具保证的只有 YAML 的语法与结构——它无法验证镜像是否存在、其中的应用能否启动、服务之间能否正确连通。docker compose up 失败的原因大多不在 YAML 格式，而在其后的「顺序」「路径」「权限」这三件事上。下面讲的就是这三件。

情形	会发生什么	怎么处理
`depends_on` 只等到「已启动」，不等「可用」	`depends_on` 保证的只是容器的启动顺序，它并不查看容器内的进程是否已经能接受连接。数据库从启动到完成初始化与恢复要花数秒到数十秒，于是应用侧去连一个还没开始监听的端口，然后挂掉。症状很有特征——只有第一次 `up` 失败，再 `up` 一次就好了，因为第二次数据库已经热起来了。正因为这种「偶尔失败」的性质，它在本地被漏掉，到 CI 才第一次暴露。这不是无法复现的 bug，而是竞态条件。	请在被依赖的服务上写 `healthcheck`，并在依赖方指定 `condition: service_healthy`。PostgreSQL 的话，`test: ["CMD-SHELL", "pg_isready -U postgres"]` 配合 `interval: 5s`、`retries: 10`、`start_period: 10s` 是实用的起点。但即便如此也并不完备——运行途中数据库若重启，应用照样会断开连接。真正的答案是在应用内加入连接重试。做成不依赖启动顺序的设计，无论在 compose、Kubernetes 还是托管数据库上都表现一致。healthcheck 请当作改善开发体验的辅助手段。
把 `ports` 与 `volumes` 的左右写反	两者都是左边为宿主机、右边为容器（`"8080:80"` 是把宿主机 8080 映射到容器 80）。由此派生出三种事故。其一，`ports` 默认发布在所有网络接口上——写成 `"3306:3306"`，同一局域网内的任何人都能连到你的数据库。其二，同一 compose 网络内的服务之间，不发布端口也能用服务名互相通信；`db:5432` 就能解析，所以为自家应用写 `ports` 本来是不必要的。其三，绑定挂载会遮住镜像里的内容——写下 `./:/app`，镜像在构建时生成的 `/app/node_modules` 就不可见了，于是出现只在 compose 下才报的「找不到模块」。	只把确实需要从外部访问的写进 `ports`，其余一律不写。若想从本机连数据库，请写成 `"127.0.0.1:3306:3306"` 限定在回环地址。node_modules 问题的常规解法是「用匿名卷覆盖」：在 `volumes:` 下并列写两行，`./:/app` 和 `/app/node_modules`——后者叠在绑定挂载之上，镜像里的内容得以存活。权限错位（宿主机 UID 与容器 UID 不同，导致写不进去或生成 root 所有的文件）可以用 `user: "${UID}:${GID}"` 对齐，但这只在 Linux 上咬人——macOS 与 Windows 的 Docker Desktop 由虚拟化层吸收，不会复现。
搞不清环境变量到底来自哪里	compose 里有三个名字相近却职能不同的机制，混淆正源于此。(1) `environment:` 是传给容器的值。(2) `env_file:` 是从文件做同一件事。(3) YAML 中的 `${VAR}` 则是 compose 自己在读取文件时做的替换，其取值只能来自宿主机的 shell 或项目根目录下的 `.env`。这里就是最大的陷阱——写在 `env_file:` 里的值不会用于解析 `${VAR}`。而且未定义的 `${VAR}` 只会变成空字符串而不报错，于是 `image: myapp:${TAG}` 悄悄变成 `myapp:`，拉到的是 `latest`。	不要靠猜，去读 `docker compose config`。它输出的是把所有替换都解析完毕的最终 YAML——这是唯一能看到实际传入了什么的地方。凡是显示为空的值，那里就是未定义的 `${VAR}`。机密的处理也要定下方针：直接写在 `environment:` 里的值任何人都能用 `docker inspect` 读到，而且会进 Git。`env_file:` 好在文件可以列入 `.gitignore`，但在容器内部它依旧只是普通环境变量。生产环境请使用 compose 的 `secrets:` 或密钥管理服务——前者以文件形式挂载，因此不会像环境变量那样被子进程自动继承。

本工具输出的 version: '3.9' 在当前的 Compose V2 中会被跳过。你会看到 the attribute version is obsolete 的警告，但不影响行为——觉得碍眼就删掉那一行。版本号是 Compose V1 时代用来选择功能集的，V2 一律按最新规范解释。再点出两个运维上常踩的坑。restart: always 会把启动即崩溃的容器无限重启——日志被重复内容塞满，真正的报错只留在第一轮里，反而更难找到。排查期间请先去掉它。另一个是，docker compose down 不会删除具名卷。当数据库初始化脚本「不起作用」时，多半是旧卷还在——因为大多数镜像只在数据目录为空时才执行初始化。要重建就需要 docker compose down -v，而这条命令是真的会销毁数据的。

📖 使用方法

1

选择预设或添加服务

从 LAMP、Next.js、Laravel 等 6 种预设开始,或添加空服务卡片。
2

填写服务字段

输入 image、ports、volumes、environment、depends_on、restart、networks。实时更新。
3

复制或下载

一键复制生成的 YAML 或下载为 docker-compose.yml。

❓ 常见问题

生成的 compose 版本是?

生成 version: 3.9,现代 docker compose v2 默认。需要 Docker Engine 19.03+。

密码和 API 密钥会上传吗?

不会。所有处理均在浏览器中完成,无网络传输。

生成的 YAML 可直接 docker compose up 吗?

可以。预设使用官方镜像和默认设置,可直接启动。生产环境请将变量移至 .env 或 secrets。

🔗 相关工具

🐛 此工具出现问题了吗？

免费、无需注册。仅提供复现步骤也有帮助。报告将直接发送给运营者并用于改进。