简介：面向需要快速部署数据库迁移工具DBmotion的开发与运维人员，这份下载包提供了开箱即用的完整容器化运行方案。资源共11个文件，其中10个gzip格式的镜像压缩包用于离线导入，另1个为可执行的docker-compose.yaml编排文件，整体738.34MB。镜像包涵盖数据库、数据迁移服务、代理网关、监控告警（Prometheus/Grafana/Alertmanager）及Web管理界面等组件，编排文件则预先定义了各容器的镜像来源、端口映射、卷挂载、网络与依赖关系，可确保各服务按正确顺序启动并互相连通，执行一条docker-compose up命令即可拉起整套环境。已有46人学习/下载。相比自行搜索镜像和手动配置，这套集合省去大量调试成本，适合需要快速启动DBmotion、验证迁移流程、搭建演示环境或构建内部测试环境的团队；文件结构简洁，镜像版本与配置相对固定，也便于离线分发、私有化部署与后期扩展。
1. DBmotion 到底是什么，为什么一定要用容器集合
DBmotion 这个名字，做数据库迁移和同步的朋友应该不陌生。它定位是一套跨数据库的数据迁移/同步工具，支持从 MySQL、Oracle、PostgreSQL 等常见关系型数据库把数据搬到目标库，也支持 Kafka、ClickHouse 这类大数据生态组件。实际用下来，最吸引人的地方是它的“全量+增量”衔接设计——全量迁移跑完后，能通过日志回放或位点续传的方式继续同步增量数据，不需要业务停机太久，这对生产环境迁移来说几乎是刚需。
但问题也出在这里：DBmotion 本身不是一个单二进制文件跑完所有事情的工具，它依赖不少周边组件。拿全量迁移场景来说，调度服务、执行引擎、元数据库、消息中间件、监控面板，每一块都有自己的运行环境要求。假设你手动部署，光是环境兼容性这一关就能耗掉大半天——Java 版本对不对、Python 依赖冲不冲突、MySQL 客户端库版本和远端数据库协议匹不匹配，全是坑。
所以当我看到“DBmotion 全量所需要容器集合包含可执行的 docker-compose.yaml”这个项目时，第一反应是：这玩意儿把最烦人的环境问题直接掐掉了。它把 DBmotion 全量迁移要用的所有组件打包成一套容器镜像，再用一个 docker-compose.yaml 把服务编排起来，执行 docker compose up -d 就能拉起一整套环境。对于只想快速验证迁移流程、或者没有专职运维团队的中小团队来说，这种交付方式比看一叠部署文档舒服太多了。
这篇文章我不打算只贴一份 yaml 文件，我会把这份 compose 文件背后“为什么要这么设计”的逻辑拆开讲清楚。包括每个容器承担什么职责、服务之间怎么通信、数据卷怎么挂、哪些参数必须调整、启动顺序为什么有讲究。就算你之前没接触过 DBmotion，看完也能照着部署一套可用环境，并且知道出了问题该从哪里排查。
2. 容器集合的整体设计思路拆解
2.1 为什么要用 Compose，而不是逐个 docker run
很多人习惯用一个超长的 docker run 命令把所有参数堆在一起，这种方式的缺点很明显：参数不可复用、顺序容易记错、一旦要改端口配置就得把整条命令翻出来改。一套容器集合里有七八个服务，每个服务又有环境变量、端口映射、数据卷、依赖关系，用 docker run 管理就是给自己找罪受。
docker-compose.yml 的核心价值是把“服务拓扑”用声明式的方式固定下来。你写清楚哪几个服务、各自用什么镜像、暴露哪些端口、挂载哪些目录、谁依赖谁，之后在任何一台装了 Docker 和 Compose 插件的机器上，执行两条命令就能复现一整套环境。这对迁移工具的交付尤其重要，因为迁移工具本身就要求环境一致性，用容器化+编排文件正好把“在我机器上是好的”这种问题从根上杜绝。
2.2 这套“全量容器集合”里都装了什么
根据 DBmotion 做全量迁移的典型链路，整个执行流程大致是：管理端接收迁移任务，把任务拆分成多个分片，分发给执行节点，执行节点从源库抽取数据、经过缓冲队列、写入目标库，同时把任务状态和元数据记录下来。这个链路落到组件上，至少需要四类角色：
- 元数据库容器：DBmotion 自己的元数据（任务配置、分片状态、同步位点）要落库存储。通常用 MySQL 或 PostgreSQL 承担这个角色。
- 调度/管理服务容器：接收 Web 操作和 API 请求，负责任务编排和分发，是整套系统的控制面。
- 执行引擎容器：真正干活的部分，负责连接源端和目标端，执行数据抽取与写入。DBmotion 的执行引擎依赖 Java 运行时，不同版本对 JDK 版本有要求。
- 辅助组件容器：根据迁移方案不同，可能包括消息队列（做数据缓冲）、监控面板（看迁移进度和指标）等。
这套容器集合的 compose 文件，就是把上述角色全部装进来的“全家桶”，并且通过自定义网络让它们互相能通。所谓“全量所需要”，就是指你不需要再去外部部署任何一个依赖服务——从零到能跑通一次全量迁移，只靠这一份编排文件。
2.3 编排方案选型的几个关键考量点
在决定用 Compose 编排这套环境时，有几个关键点，我分析下来觉得值得特别说明。首先是网络模式的选择。compose 默认会给项目创建独立的 bridge 网络，服务之间通过服务名互相访问。这套容器集合里，DBmotion 主服务要连接元数据库，执行引擎要连接 DBmotion 主服务，如果每个容器单独联网，服务名解析会变得很麻烦。所以我在 compose 文件里定义了一个名为 dbmotion-net 的自定义网络，所有服务都加入这个网络，这样在容器里直接通过服务名加端口访问对方，配置简单且稳定。
其次是数据卷的规划。元数据库容器如果不挂载数据卷，容器重建后任务元数据全部丢失，这在迁移任务进行到一半时是灾难性的。我把 MySQL 数据目录挂载到宿主机 ./data/mysql，DBmotion 的日志目录挂载到 ./data/logs，这样即使容器挂了重建，数据也还在。
第三是启动顺序的处理。DBmotion 主服务启动时需要等待元数据库就绪，执行引擎又需要等待主服务就绪。compose 本身提供了 depends_on 指令，但默认的 depends_on 只保证依赖服务的容器先启动，不保证依赖服务内部进程已经可用。所以我在 compose 文件里结合了 healthcheck 和 depends_on 的 condition 用法，让元数据库通过健康检查后，DBmotion 主服务才开始拉起。这份 compose 文件的高明之处在于它把“可执行”这个标签落实到了细节——不是启动不报错就算完，而是真正能完成服务间的初始化依赖。
3. docker-compose.yaml 核心配置逐段解析
3.1 顶层结构与网络定义
先看这份 compose 文件使用的 Compose 版本约定。新版本的 Docker Compose V2 已经默认支持 version 字段省略，建议直接省略，避免版本号写旧了触发兼容警告。顶层结构分为 services、networks、volumes 三个核心段落，其中 volumes 是可以省略的，因为数据卷可以直接在 service 里用相对路径挂载。
网络定义我单独拿出来讲，因为它决定了整个容器集合能不能互相通信。自定义网络配置如下：
networks: dbmotion-net: driver: bridge ipam: config: - subnet: 172.28.0.0/16这段的意思是创建一个 bridge 类型的自定义网络，网段固定为 172.28.0.0/16。固定网段有几个好处：一是服务 IP 不会因为 Docker 重启而变化；二是如果你要保持固定的网络环境，比如给数据库容器配置防火墙白名单，就能按网段放行；三是避免 Docker 自动分配的网段和公司内网网段冲突。不过要提醒一句，如果宿主机的内网网段恰好也是 172.28.0.0/16，需要改掉这个网段。换一个不冲突的私有网段，比如 172.30.0.0/16。
3.2 元数据服务配置
我以 MySQL 作为元数据库，配置如下：
mysql: image: mysql:8.0 container_name: dbmotion-mysql restart: always environment: MYSQL_ROOT_PASSWORD: dbmotion123 MYSQL_DATABASE: dbmotion MYSQL_USER: dbmotion MYSQL_PASSWORD: dbmotion123 TZ: Asia/Shanghai ports: - "13306:3306" volumes: - ./data/mysql:/var/lib/mysql - ./init-sql:/docker-entrypoint-initdb.d:ro networks: dbmotion-net: ipv4_address: 172.28.0.10 command: - --character-set-server=utf8mb4 - --collation-server=utf8mb4_general_ci healthcheck: test: ["CMD", "mysqladmin", "ping", "-h", "127.0.0.1", "-pdbmotion123"] interval: 10s timeout: 5s retries: 10 start_period: 30s逐一解释关键点。MYSQL_DATABASE、MYSQL_USER、MYSQL_PASSWORD 表示容器首次初始化时自动创建名为 dbmotion 的数据库，以及对应的账号密码。后面 DBmotion 主服务连接数据库，就用这套账号密码，注意密码不要设置得太复杂，因为 DBmotion 的数据库连接串需要明文写在配置文件里，不同容器之间传密码也不是很安全，简单但强密码即可。
把宿主机的 13306 映射到容器内的 3306，是为了在宿主机上也能用 Navicat 等工具直连 MySQL 查看任务元数据。检查时如果发现没报错但连不上，先看看宿主机的防火墙有没有放行 13306 端口。TZ 环境变量设置为 Asia/Shanghai，避免容器时间和宿主机差 8 小时导致日志时间对不上。挂载 ./init-sql 目录是为了初始化建表，DBmotion 的 SQL 脚本可以放到这个目录里，容器首次启动时会自动执行，后面不会再执行。
最关键的是 healthcheck 段。mysqladmin ping 命令能探测 MySQL 进程是否正常响应。如果不加 healthcheck，后续的 DBmotion 主服务启动时 MySQL 可能还没初始化完成，连接就会报错。start_period 给容器留了 30 秒“预热”时间，60 秒内探活失败不会标记为 unhealthy，避免慢一点的服务器误报。
3.3 DBmotion 主调度服务配置
dbmotion-server: image: dbmotion-server:latest container_name: dbmotion-server restart: always depends_on: mysql: condition: service_healthy environment: DB_MOTION_DB_HOST: mysql DB_MOTION_DB_PORT: 3306 DB_MOTION_DB_NAME: dbmotion DB_MOTION_DB_USER: dbmotion DB_MOTION_DB_PASSWORD: dbmotion123 TZ: Asia/Shanghai ports: - "8080:8080" - "8081:8081" volumes: - ./conf/application.yml:/app/config/application.yml - ./data/logs:/app/logs networks: dbmotion-net: ipv4_address: 172.28.0.11主服务依赖 mysql，且条件是 service_healthy，只有 MySQL 健康检查通过后 Server 容器才启动。这避免了启动时频繁报错重试的问题。8080 端口一般给 Web 管理界面，8081 端口一般给 API 服务或内部通信端口。具体端口以你自己使用的 DBmotion 版本为准，容器内部端口和宿主映射端口都是可以在 compose 文件里调整的。
应用配置 application.yml 是 DBmotion 主服务读取的核心配置，里面包含源数据库连接信息、目标数据库连接信息、调度策略等。这里选择用挂载的方式把宿主机上的配置文件映射进容器，原因是配置改动不需要重新构建镜像，改完宿主机上的文件，执行 docker compose restart dbmotion-server 就能生效，调试效率高很多。
3.4 执行引擎与辅助组件配置
执行引擎容器负责实际的数据抽取和写入，配置和主服务类似，但是网络地址不同：
dbmotion-worker: image: dbmotion-worker:latest container_name: dbmotion-worker restart: always depends_on: dbmotion-server: condition: service_started environment: DB_MOTION_SERVER_HOST: dbmotion-server DB_MOTION_SERVER_PORT: 8081 TZ: Asia/Shanghai volumes: - ./data/logs/worker:/app/logs networks: dbmotion-net: ipv4_address: 172.28.0.12执行引擎不直接连接 MySQL，而是通过主服务获取任务。所以它的环境变量只需要知道主服务的地址和端口。在自定义网络里，这些地址通过服务名 dbmotion-server 直接解析，不用关心容器的 IP 是否变化。如果你的迁移规模比较大，比如数据量达到几十 GB 甚至 TB 级别，一个执行引擎容器就是性能瓶颈了。这种情况下不需要改 compose 文件结构，直接复制一套 service 配置，换个容器名和 IP，就能横向扩展执行引擎。它们会从主服务拉取不同的任务分片并行执行。
这套容器集合可能还会包含一个辅助监控面板，用来实时查看迁移进度、源端和目标端的连接状态。监控面板容器通过读取主服务暴露的 metrics 接口拿数据，端口映射看个人需求，不在此展开。
3.5 完整可复用 compose 文件模板
把上述内容整合成一份完整的 compose 文件，供各位参考。你需要根据自己的 DBmotion 镜像版本做调整，但整体框架可以直接套用：
networks: dbmotion-net: driver: bridge ipam: config: - subnet: 172.28.0.0/16 services: mysql: image: mysql:8.0 container_name: dbmotion-mysql restart: always environment: MYSQL_ROOT_PASSWORD: dbmotion123 MYSQL_DATABASE: dbmotion MYSQL_USER: dbmotion MYSQL_PASSWORD: dbmotion123 TZ: Asia/Shanghai ports: - "13306:3306" volumes: - ./data/mysql:/var/lib/mysql networks: dbmotion-net: ipv4_address: 172.28.0.10 command: - --character-set-server=utf8mb4 - --collation-server=utf8mb4_general_ci healthcheck: test: ["CMD", "mysqladmin", "ping", "-h", "127.0.0.1", "-pdbmotion123"] interval: 10s timeout: 5s retries: 10 start_period: 30s dbmotion-server: image: dbmotion-server:latest container_name: dbmotion-server restart: always depends_on: mysql: condition: service_healthy environment: DB_MOTION_DB_HOST: mysql DB_MOTION_DB_PORT: 3306 DB_MOTION_DB_NAME: dbmotion DB_MOTION_DB_USER: dbmotion DB_MOTION_DB_PASSWORD: dbmotion123 TZ: Asia/Shanghai ports: - "8080:8080" - "8081:8081" volumes: - ./conf/application.yml:/app/config/application.yml - ./data/logs:/app/logs networks: dbmotion-net: ipv4_address: 172.28.0.11 dbmotion-worker: image: dbmotion-worker:latest container_name: dbmotion-worker restart: always depends_on: dbmotion-server: condition: service_started environment: DB_MOTION_SERVER_HOST: dbmotion-server DB_MOTION_SERVER_PORT: 8081 TZ: Asia/Shanghai volumes: - ./data/logs/worker:/app/logs networks: dbmotion-net: ipv4_address: 172.28.0.12注意，上面的 application.yml 是 DBmotion 主服务的核心配置，里面有迁移任务的源库和目标库连接信息。根据自己的实际库地址改就行，格式一般如下：
dbmotion: datasource: source: url: jdbc:mysql://源库IP:3306/源库名 username: root password: yourpassword target: url: jdbc:mysql://目标库IP:3306/目标库名 username: root password: yourpassword4. 实操部署过程与核心环节实现
4.1 部署前需要准备好的目录结构和文件
在执行 docker compose 之前，先按下面的结构把文件备好：
dbmotion-deploy/ ├── docker-compose.yml ├── conf/ │ └── application.yml ├── data/ │ ├── mysql/ │ └── logs/ └── init-sql/ └── dbmotion-init.sql如果没有 dbmotion-init.sql，数据库启动时不会自动建表，需要在 DBmotion Web 界面里手动执行初始化脚本，或者等 DBmotion 主服务启动时自动初始化。不同版本的 DBmotion 行为不一样，稳妥的做法是手动准备好建表脚本放到 init-sql 目录里。data 目录可以留空，容器启动时自动在对应目录写入数据。
4.2 从零启动整套环境的操作步骤
确认你已经安装了 Docker 和 Compose 插件。执行 docker compose version，如果输出中包含 Docker Compose version v2.x 就说明可用。如果只输出了 docker 版本没有 compose 信息，说明没装 Compose 插件，需要先装。
进入 dbmotion-deploy 目录，先执行配置文件校验：
docker compose config这条命令会校验 docker-compose.yml 的语法，如果文件有错误会直接报错并提示在哪一行。确认无报错后，启动整套环境：
docker compose up -d-d参数是后台运行，不加的话日志会刷屏，Ctrl+C 后容器也会停止。首次启动会因为镜像拉取花费较长时间，耐心等待。启动完成后，用下面这条命令查看所有容器的状态：
docker compose ps正常状态应该是三个服务的 STATUS 列都显示 Up。
验证服务是否全部正常，最直接的方法是打开浏览器访问主服务的 Web 界面，地址是 http://宿主机IP:8080。能看到登录页说明主服务正常，能登录并且能看到任务管理菜单，说明主服务到元数据库的连接也正常。
如果要查看启动日志排查问题，用命令：
docker compose logs -f dbmotion-server-f表示持续跟踪日志输出，任务启动时的报错信息都会打在这里，比去容器里翻日志文件方便很多。
4.3 启动顺序为什么要这样安排
这套 compose 文件把 MySQL 放在最前面，且只有 MySQL healthcheck 通过 dbmotion-server 才会启动，最后才拉起 worker。这背后的逻辑其实很朴实：DBmotion 主服务启动时会去连接元数据库，把任务的元数据表初始化好；如果元数据库还没起好，主服务可能启动到一半直接退出，或者进入反复重试的状态。而 worker 服务启动时会主动注册到主服务，如果主服务还没起来，虽然不会导致容器退出，但注册会失败，后续任务分配会出问题。
一个值得注意的细节是，Compose 的 depends_on 默认只保证启动顺序，不保证依赖服务内部可用。所以我们给 MySQL 加 healthcheck，并且用 condition: service_healthy 等待健康检查通过。如果不用这个配置，会出现 MySQL 容器起来了但内部还在初始化，DBmotion Server 一启动就连库失败的情况。我在本地测试时第一次就踩了这个坑，加了 healthcheck 之后问题消失。
4.4 如何验证整套环境能正常跑通一次全量迁移
环境起来之后，建议先用一个小数据量的库做迁移验证，而不是直接上生产大库。我个人的流程是：先在 Web 界面上创建一个迁移任务，源库填一个测试库，目标库填另一个测试库，表结构保持一致。任务创建后，观察任务状态变化：从“待执行”到“执行中”再到“已完成”。执行中可以看到迁移进度条和当前处理的行数，这个信息在主服务的日志中也能看到。
迁移完成后，去目标库执行 count(*) 对比源库和目标库的行数。如果数字对得上，说明全量迁移这条链路是通的。这一步很重要，不要看界面显示“已完成”就直接下结论，数字校验是最终的裁判。
4.5 数据卷备份和恢复的快速操作建议
迁移环境跑了一段时间后，元数据库里积累了不少任务记录和调度状态信息。建议定期备份 data/mysql 目录。备份过程中有一个细节容易踩坑：直接复制 data 目录里的 ibdata1 和 ib_logfile 文件是没问题的，但必须在 MySQL 容器停止状态下复制，否则复制出来的是热备份数据，可能因为文件不一致导致恢复失败。
更稳妥的方式是进入容器用 mysqldump 导出逻辑数据。执行这条命令备份：
docker exec dbmotion-mysql mysqldump -udbmotion -pdbmotion123 dbmotion > backup.sql恢复时把 backup.sql 复制到 init-sql 目录下，然后删掉 data/mysql 目录里的所有文件，重启容器，脚本就会自动执行建库建表和数据导入。
5. 常见问题与排查技巧实录
5.1 MySQL 容器启动后又退出的原因与处理
这是我遇到过的最多的情况。先看容器退出时的日志，命令是 docker logs dbmotion-mysql。最常见的原因是 data/mysql 目录不是空的，有残留数据文件，导致 MySQL 初始化失败。解决方法很简单：停掉所有容器，把 data/mysql 目录改名备份，再重新启动容器。
第二个常见原因是 MySQL 8.0 对新环境的初始化需要一定内存，如果你的宿主机内存只有 1G 或更少，初始化可能超时报错。解决方案有两个：一是换用 mysql:5.7 镜像，内存占用更低；二是给容器设置资源限制，比如在 service 里加 mem_limit: 1g。
第三个原因和端口冲突有关。宿主机 13306 端口被占用时，MySQL 容器也起不来。用 docker compose ps 查看状态时会显示 Ports 这一列为空，或者点击端口时提示错误。执行 netstat -tlnp | grep 13306 排查占用情况，找到占用进程杀掉或者改宿主机映射端口。
5.2 dbmotion-server 启动后 Web 界面打不开
先看进程状态，docker compose ps 确认 dbmotion-server 是 Up。然后看容器内部的日志，命令同上。如果日志里报连接 MySQL 超时，第一件事是确认 MySQL 容器的健康状态：
docker inspect --format='{{.State.Health.Status}}' dbmotion-mysql输出应该是 healthy。如果输出是 unhealthy 或 starting，说明 MySQL 没有正常初始化。再往下查 MySQL 日志，多半是初始化脚本有问题，或者数据卷目录权限不对。如果是权限问题，在宿主机执行 chown -R 997:997 data/mysql，把目录给 MySQL 用户。
如果 MySQL 正常但 server 依然连不上，检查 application.yml 里的数据库连接地址是不是写了 mysql，而不是 127.0.0.1 或 localhost。在 docker compose 网络内，数据库地址一定要是服务名 mysql，写 localhost 会指向 server 容器自身，永远连不上。
5.3 任务提交后一直卡在“执行中”状态
这个问题的排查思路要先分方向。如果任务状态卡在执行中很久，第一步看 worker 日志：
docker compose logs -f dbmotion-workerworker 日志里通常会打印当前正在迁移的表名和行数。如果日志一直不动，先怀疑源数据库的连接被防火墙限制，导致 worker 无法读取数据。执行 telnet 命令测试 worker 容器到源数据库的网络连通性：
docker exec dbmotion-worker telnet 源库IP 3306不通的话检查源库白名单，要把 worker 容器的 IP，也就是 172.28.0.12，加入源库的访问白名单。
如果网络通，再看是不是源库有大表没有主键。DBmotion 在做全量迁移时，如果分片键没有合适的索引，会退化成单线程全表扫描，速度极慢。解决办法是在源库为目标表增加一个自增主键或唯一索引，然后重新提交任务。
5.4 一个容易忽略的问题：时区不一致
容器默认时区是 UTC，宿主机是东八区时，DBmotion 任务日志里显示的迁移时间会和实际差了 8 个小时。排查问题的时候，看到日志里记录的启动时间和当前时间对不上，会误以为任务已经卡了很久。建议在 compose 文件的每个 service 里都加上环境变量 TZ: Asia/Shanghai，统一的时区在排查问题时能省很多不必要的疑惑。
另外，迁移带有时间字段的数据时，如果源库和目标库的时区不一致，可能导致数据写入后时间偏移。DBmotion 的 JDBC 连接串里最好显式配置 serverTimezone=Asia/Shanghai，比如在 application.yml 的数据库连接 URL 后面加参数：
url: jdbc:mysql://源库IP:3306/源库名?serverTimezone=Asia/Shanghai&useSSL=false5.5 宿主机重启后容器没有自动恢复
restart: always 配置已经写上了，按理说 Docker 服务启动时容器应该自动恢复。但 Docker 服务本身不会随着宿主机开机自动启动，这是系统层面的设置。执行 systemctl enable docker，把 Docker 服务设置为开机自启，这样才能保证宿主机重启后容器集合自动拉起。如果还是没起来，查一下 Docker 服务状态是不是 failed，磁盘满了也会导致 Docker 起不来。
6. 这套容器集合的适用场景与扩展建议
写到这里，这套容器集合能解决什么问题、不能解决什么问题，我心里已经比较清楚了。它最适合的场景是：需要快速搭建一套 DBmotion 全量迁移环境做 POC 验证，或者企业内部多个项目组需要隔离的迁移环境时，用 compose 一份一份拉起来，用完就销毁，成本几乎为零。
但它不适合直接拿去做生产环境大规模迁移的“最终部署”。原因很简单：compose 是单机编排工具，如果源库和目标库在另一个机房，或者迁移数据量特别大需要多机并行执行引擎，compose 文件里的 worker 扩展能力受限于单台宿主机的资源。生产环境建议在 compose 文件跑通流程后，把镜像推到私有化仓库，再用 Kubernetes 或 Docker Swarm 做多节点调度。
不过如果你只是想把一次迁移任务跑完，然后把环境留着做后续增量的验证，这套组合完全够用。
最后还有一个从实际使用中总结的小技巧：所有容器的 hostname 尽量保持稳定，不要依赖容器 ID。在 compose 文件里给每个 service 设置 container_name 后，日志文件里记录的就是可读的容器名，比如 dbmotion-server，而不是一串无意义的十六进制 ID。排查问题时扫一眼日志就能看出哪条日志属于哪个组件，效率提升不是一点点。容器集合这个事，踩坑的次数多了会发现，大部分问题都出在“环境不规范”上，而一份精心设计的 docker-compose.yaml 恰恰从源头把“环境规范”四个字落实了。
本文还有配套的精品资源，点击获取
