第25章部署与运维

课程目录第25章部署与运维

25、部署与运维：Docker容器化、Kubernetes部署、CI/CD、日志与监控

说实话，很多做WebRTC的同学，代码写得飞起，一到部署就头疼。

我自己早期也踩过这个坑。本地跑得挺好，一上服务器就各种玄学问题——端口不通、ICE连接失败、TURN服务器没起来……后来我学乖了，容器化+自动化部署才是王道。

这一章，咱们就聊聊怎么把WebRTC多人视频会议这套东西，稳稳当当地跑在线上。

  核心思路： 用Docker打包环境，用Kubernetes编排服务，用CI/CD自动化发布，用日志和监控保证可观测性。

一、Docker容器化：把环境“锁死”

为什么一定要用Docker？

你想想看，WebRTC依赖的东西太多了：Node.js、Coturn、Nginx、Redis、信令服务器、媒体服务器……每个人系统不一样，依赖版本不一样，很容易出问题。

Docker说白了就是把整个运行环境打包成一个镜像。我在项目中遇到过好几次，开发环境是Mac，测试环境是CentOS，生产环境是Ubuntu。如果没有容器化，光是调试环境差异就能耗掉半天。

1. 信令服务器的Dockerfile

先看一个最简单的信令服务器Dockerfile：

FROM node:18-alpine

WORKDIR /app

COPY package*.json ./
RUN npm ci --only=production

COPY . .

EXPOSE 3000

CMD ["node", "server.js"]

嗯，这里要注意：npm ci 比 npm install 更可靠。它会严格按照 package-lock.json 安装，不会因为版本浮动出问题。

2. 媒体服务器（SFU）的Dockerfile

SFU通常基于C++或Rust，编译依赖多。我建议用多阶段构建：

# 构建阶段
FROM node:18 AS builder
WORKDIR /app
COPY . .
RUN npm install && npm run build

# 运行阶段
FROM node:18-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
EXPOSE 4000
CMD ["node", "dist/index.js"]

这样最终镜像只有几十MB，而不是几百MB。我曾经见过有人直接把整个开发环境打包进生产镜像，结果镜像1.2GB……部署一次要等十分钟。

3. docker-compose.yml 编排

本地开发时，用docker-compose把多个服务串起来：

version: '3.8'
services:
  signaling:
    build: ./signaling
    ports:
      - "3000:3000"
    depends_on:
      - redis

  media-server:
    build: ./media-server
    ports:
      - "4000-4010:4000-4010/udp"
    environment:
      - REDIS_HOST=redis

  coturn:
    image: coturn/coturn
    ports:
      - "3478:3478"
      - "3478:3478/udp"

  redis:
    image: redis:7-alpine

注意媒体服务器的端口范围。WebRTC需要多个UDP端口做媒体传输，别只开一个端口。

避坑指南： 我曾经把Coturn的端口只映射了TCP，忘了UDP。结果ICE连接一直失败，查了两小时才发现。记住：WebRTC媒体走UDP，TURN也走UDP。

二、Kubernetes部署：让服务“自愈”

Docker解决了环境一致性问题，但服务挂了怎么办？流量大了怎么扩容？

这时候就需要Kubernetes了。说白了，K8s就是一个自动化的“管家”，帮你管理容器的生命周期。

1. 核心概念

Pod： 最小部署单元，里面跑一个或多个容器
Deployment： 管理Pod的副本数、滚动更新
Service： 提供稳定的网络入口
Ingress： 对外暴露HTTP/HTTPS服务
ConfigMap/Secret： 管理配置和密钥

2. 部署信令服务器

一个典型的Deployment配置：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: signaling-server
spec:
  replicas: 3
  selector:
    matchLabels:
      app: signaling
  template:
    metadata:
      labels:
        app: signaling
    spec:
      containers:
      - name: signaling
        image: myregistry/signaling:latest
        ports:
        - containerPort: 3000
        env:
        - name: REDIS_HOST
          value: "redis-service"
        livenessProbe:
          httpGet:
            path: /health
            port: 3000
          initialDelaySeconds: 10
          periodSeconds: 5

这里我特别加了 livenessProbe。为什么？因为WebRTC信令服务器如果内存泄漏，可能进程还在但服务已经不可用了。健康检查能自动重启挂掉的Pod。

3. 媒体服务器的特殊处理

媒体服务器需要UDP端口，而且每个Pod需要独占端口范围。我建议用 hostPort 或者 NodePort：

apiVersion: v1
kind: Service
metadata:
  name: media-server-service
spec:
  type: NodePort
  ports:
  - port: 4000
    targetPort: 4000
    protocol: UDP
    nodePort: 30400

嗯，这里有个坑：K8s默认Service只支持TCP。UDP需要显式声明 protocol: UDP。我刚开始部署时忘了写，结果媒体流一直不通。

4. 自动扩缩容

视频会议流量波动大，用HPA（Horizontal Pod Autoscaler）自动扩缩：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: media-server-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: media-server
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

当CPU使用率超过70%时，自动增加Pod。会议结束后流量下降，自动回收资源。省钱又省心。

注意： 媒体服务器扩缩容时，正在进行的会议怎么办？建议用“优雅关闭”——先停止接收新连接，等现有会议结束后再销毁Pod。否则用户会突然掉线。

三、CI/CD：自动化发布流程

手动部署太累了。每次改一行代码，都要：打包镜像、推送到仓库、更新K8s配置……

CI/CD就是把这些步骤自动化。我常用的流程是：

开发者推送代码到GitHub
自动触发构建（GitHub Actions / GitLab CI）
运行单元测试和集成测试
构建Docker镜像并推送到镜像仓库
自动更新K8s Deployment

1. GitHub Actions 示例

name: Deploy to K8s

on:
  push:
    branches: [main]

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3

    - name: Build Docker image
      run: docker build -t myregistry/signaling:${{ github.sha }} .

    - name: Push to registry
      run: docker push myregistry/signaling:${{ github.sha }}

    - name: Update K8s deployment
      run: |
        kubectl set image deployment/signaling-server \
          signaling=myregistry/signaling:${{ github.sha }}

每次提交都会自动构建并部署。我个人习惯用commit SHA作为镜像标签，这样能精确追溯每个版本对应的代码。

2. 蓝绿部署

对于视频会议这种实时服务，停机更新是不可接受的。我推荐蓝绿部署：

蓝环境： 当前生产环境
绿环境： 新版本环境
验证绿环境没问题后，切换流量
如果出问题，立刻切回蓝环境

在K8s里，可以用两个Deployment + 一个Service来实现。切换时只需要改Service的selector标签。

我的经验： 有一次我部署了新版本，结果ICE连接成功率从99%降到了80%。因为蓝绿部署，我立刻切回了旧版本，用户几乎无感知。如果是滚动更新，可能已经影响到所有用户了。

四、日志与监控：让问题无处遁形

服务跑起来了，但你怎么知道它健康不健康？

日志和监控就是你的“眼睛”。没有它们，出问题了只能靠猜。

1. 日志收集

容器里的日志默认输出到stdout。用EFK（Elasticsearch + Fluentd + Kibana）或Loki + Grafana收集：

# Fluentd配置示例
<source>
  @type tail
  path /var/log/containers/*.log
  tag kubernetes.*
  format json
</source>

<match kubernetes.**>
  @type elasticsearch
  host elasticsearch-service
  port 9200
  logstash_format true
</match>

这样所有Pod的日志都集中到Elasticsearch，可以在Kibana里搜索、过滤、可视化。

2. 关键监控指标

对于WebRTC视频会议，我重点关注：

指标	说明	告警阈值
ICE连接成功率	用户能否成功建立P2P连接	< 95% 告警
媒体延迟	端到端的音视频延迟	> 500ms 告警
丢包率	网络传输中的丢包比例	> 5% 告警
CPU/内存使用率	媒体服务器的资源消耗	> 80% 告警
活跃房间数	当前正在进行的会议数量	用于容量规划

3. Prometheus + Grafana

我习惯用Prometheus采集指标，Grafana做可视化面板：

# Prometheus配置
scrape_configs:
  - job_name: 'media-server'
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_label_app]
        regex: media-server
        action: keep

然后在Grafana里建一个仪表盘，实时显示：

当前在线用户数
ICE连接成功率趋势
各Pod的CPU/内存使用
丢包率和延迟分布

重要： 别忘了监控TURN服务器！我曾经遇到过TURN服务器带宽被打满，导致所有用户都走中继，延迟飙升。加一个“TURN带宽使用率”的指标，超过80%就告警。

五、整体架构图

下面这张图展示了完整的部署与运维体系：

从开发者推送代码开始，经过CI/CD构建镜像，推送到仓库，然后自动部署到K8s集群。集群里的各个服务通过Prometheus暴露指标，Grafana展示仪表盘，Elasticsearch收集日志。一旦指标异常，立刻告警通知。

六、总结

部署与运维这件事，说白了就是“让服务稳定运行，出问题能快速定位”。

Docker解决了环境一致性问题，Kubernetes解决了服务编排和自愈问题，CI/CD解决了发布效率问题，日志和监控解决了可观测性问题。

我个人觉得，对于WebRTC视频会议这种实时性要求高的系统，监控和告警是最容易被忽视但又最重要的环节。没有监控，你都不知道用户为什么卡顿、为什么掉线。

嗯，这一章的内容就到这里。记住：好的部署方案，能让你的服务7x24小时稳定运行，而你只需要在告警响起时看一眼手机。

  一句话总结： 容器化保证环境一致，K8s保证服务可靠，CI/CD保证发布高效，监控保证问题可见。四者缺一不可。

📚 课程目录

25、部署与运维：Docker容器化、Kubernetes部署、CI/CD、日志与监控

一、Docker容器化：把环境“锁死”

1. 信令服务器的Dockerfile

2. 媒体服务器（SFU）的Dockerfile

3. docker-compose.yml 编排

二、Kubernetes部署：让服务“自愈”

1. 核心概念

2. 部署信令服务器

3. 媒体服务器的特殊处理

4. 自动扩缩容

三、CI/CD：自动化发布流程

1. GitHub Actions 示例

2. 蓝绿部署

四、日志与监控：让问题无处遁形

1. 日志收集

2. 关键监控指标

3. Prometheus + Grafana

五、整体架构图

六、总结