先来看最简单的单服务部署。假设我们用Node.js写了个WebSocket服务，监听8080端口。Dockerfile可以这样写：

构建镜像的命令没啥特别的：

但启动容器时要注意端口映射，很多人在这里栽跟头：

这里有个坑，如果只映射8080端口，有时候客户端会连不上。因为WebSocket在建立连接时先走HTTP协议，完成握手后才升级到WebSocket。有些负载均衡器或者代理服务器会把这个过程搞乱。解决办法是在服务端正确处理协议升级，同时确保Docker容器暴露正确的端口。

说到生产环境，单容器肯定不够用。得用Docker Compose来编排多个服务。下面是个实战用的docker-compose.yml：

这个配置有几个关键点：一是设置了restart策略，容器崩溃时自动重启；二是用Redis做消息持久化，避免服务重启丢数据；三是通过depends_on确保启动顺序。

在实际部署时，还遇到过连接数暴涨导致容器内存溢出的问题。后来发现是没配置资源限制，加上这几行就稳了：

内存限制一定要设，不然容器能把宿主机都搞崩。CPU限制倒是可以灵活点，根据实际负载调整。

还有个坑是WebSocket连接经常超时断开。排查发现是Nginx代理的默认配置有问题。正确的Nginx配置应该是这样的：

关键在proxy_read_timeout和proxy_send_timeout，默认值太短，WebSocket长连接撑不了多久就会断。

监控也是个大事。用这个命令可以实时查看容器状态：

如果要更详细的监控，可以在容器里装个轻量级探针，把指标推送到监控系统。

最后说说日志处理。Docker默认的日志驱动是json-file，时间长了很占磁盘。建议换成日志收集系统，比如这样配置：

这样可以限制单个日志文件大小，避免磁盘爆满。

折腾完这一套，WebSocket服务在Docker里跑得稳稳的。关键是要理解WebSocket的特殊性，正确处理协议升级、超时设置和资源限制。容器化确实能省很多事，但该踩的坑一个都不会少。建议大家先在测试环境充分验证，别直接上生产。