WVP-PRO+ZLM Docker部署实战：端口映射与文件挂载的深度避坑指南

第一次尝试用Docker部署WVP-PRO和ZLM时，我对着满屏的端口冲突和配置文件错误整整折腾了两天。那些看似简单的 -p 和 -v 参数背后，藏着太多官方文档没写的魔鬼细节。本文将分享我从三次失败部署中总结出的实战经验，特别是UDP端口、配置文件双向同步和容器间通信这些最容易踩坑的环节。

1. 端口映射：不只是TCP那么简单

很多人以为Docker端口映射就是简单的 -p 8080:80 ，但在流媒体服务部署中，UDP端口的处理方式会让你大开眼界。

1.1 UDP端口的特殊处理

ZLM需要同时开放TCP和UDP端口，但Docker对两者的处理有本质区别：

# 正确做法：显式声明UDP端口
-p 10000:10000/udp  
-p 8000:8000/udp

常见错误案例：

• 只映射TCP端口导致媒体流无法传输
• 未指定 /udp 后缀造成端口冲突
• 宿主机的UDP端口被其他服务占用

排查技巧 ：

# 检查宿主机UDP端口占用
netstat -anp | grep udp | grep 10000

1.2 端口冲突的连锁反应

当多个容器都需要1935(RTMP)、554(RTSP)等标准端口时，最稳妥的方案是：

容器类型	默认端口	建议修改方案
ZLM	1935	1935→2935
WVP-PRO	5060	5060→6060

提示：修改端口后必须同步更新相关服务的配置文件，否则会出现"端口已绑定但服务不可用"的诡异现象

2. 配置文件挂载：容器内外同步的艺术

直接复制容器内配置文件到宿主机是最容易出错的环节，我推荐这个经过验证的工作流：

2.1 初始化配置的正确姿势

# 先创建临时容器获取原始配置
docker run -d --name zlm_temp zlmediakit/zlmediakit:master
docker cp zlm_temp:/opt/media/conf/config.ini ./zlm_conf/
docker rm -f zlm_temp

2.2 挂载目录的权限陷阱

当看到 Permission denied 错误时，99%是因为：

• 宿主机目录属主与容器内用户不匹配
• SELinux/AppArmor安全策略限制
• 配置文件被容器内服务运行时修改

解决方案 ：

# 查看容器内进程用户
docker exec -it zlm sh -c 'ps aux'

# 修改宿主机目录权限
chown -R 1000:1000 ./zlm_conf  # 假设容器内用户UID为1000

2.3 配置文件热更新的正确方式

修改宿主机配置后，重启容器不是唯一选择：

# 对ZLM发送配置重载信号
docker exec zlm kill -1 $(pidof MediaServer)

3. 容器间通信：看不见的网络拓扑

WVP-PRO需要连接Redis/MySQL时，典型错误是直接使用 localhost 。正确的跨容器访问方式：

3.1 创建自定义网络

docker network create wvp_net
docker run -d --network wvp_net --name redis redis:latest

3.2 配置文件的连接参数

# WVP-PRO配置示例
redis.host=redis  # 使用容器名作为主机名
redis.port=6379

3.3 端口暴露的抉择

是否需要 -p 6379:6379 取决于：

• 其他宿主机服务是否需要访问Redis
• 是否考虑通过Docker网关IP直接访问

注意：生产环境建议配合 --network-alias 使用更安全的服务发现机制

4. 部署后的关键检查清单

完成部署后，按这个顺序验证各组件：

1. 基础服务检查

   docker logs -f zlm  # 查看实时日志
   curl http://localhost:8080/index/api/getServerConfig
   

2. 媒体流测试

   ffmpeg -re -i test.mp4 -c copy -f flv rtmp://localhost:1935/live/stream
   

3. API接口验证

   curl -X POST http://wvp-pro:18080/api/v1/device/query
   

4. 跨容器通信诊断

   docker exec -it wvp-pro ping redis
   

5. 那些年我踩过的坑

• UDP端口幽灵占用 ：即使容器停止，UDP端口可能仍显示被占用，重启dockerd服务才能释放
• 配置文件编码问题 ：Windows编辑的配置文件在Linux容器中会出现 ^M 字符，导致解析失败
• 时区不同步 ：容器内日志时间与宿主机相差8小时，影响问题定位
• 内存泄漏 ：长时间运行后ZLM可能内存增长，建议配合 --memory 限制

记得第一次成功部署后，我在凌晨三点对着正常工作的监控画面傻笑了十分钟。现在每次看到 docker-compose up -d 顺利完成的提示，还是会想起那些调试的夜晚。最实用的建议是：在宿主机上建立完整的日志归档目录，把每个容器的日志都挂载出来，这样排查问题时就能像翻阅历史书一样清晰。