SQL Server 2022 Docker 容器化部署配置规范与注意事项

一、核心部署结论

SQL Server 2022 容器相较于2019版本核心变更：强制以普通mssql用户运行，禁止Root启动，固定UID/GID为10001:10001。所有目录权限拒绝报错，均为宿主机挂载目录归属权限不匹配导致。

生产标准部署方案：多目录独立挂载 + 10001精准授权 + 分级目录权限 + 标准化环境变量 + 内网网络隔离。

二、目录权限配置规范（必配）

1. 权限原理

容器内SQL进程固定运行用户为10001:10001，宿主机挂载目录必须匹配该属主属组，否则无法完成初始化、无法读写数据，服务启动失败。

2. 标准化授权命令

sudo chown -R 10001:10001 ./sqlserver
sudo chmod -R 700 ./sqlserver/data
sudo chmod -R 770 ./sqlserver/logs ./sqlserver/backup

3. 权限分级标准

• data目录700：仅10001用户读写，最高数据安全权限，防止数据篡改、泄露。

• logs、backup目录770：属主、属组可操作，兼顾日志写入、备份生成与日常运维。

• 生产环境禁止777全局权限，规避公开读写安全风险。

4. 授权生效规则

• 权限修改后必须重建容器，单纯重启容器权限不生效。

• 部署顺序：创建目录→执行授权→启动容器，顺序颠倒必报错。

• 服务器迁移、目录变更后，需重新执行全套授权操作。

三、挂载目录规范

生产强制多目录分离挂载，杜绝目录混挂，实现权限、故障、数据安全隔离：

• ./sqlserver/data:/var/opt/mssql：存储mdf、ldf核心数据文件

• ./sqlserver/logs:/var/log/mssql：存储数据库运行日志、错误日志

• ./sqlserver/backup:/var/opt/mssql/backup：存储数据库备份文件

• /etc/localtime:/etc/localtime:ro：只读挂载时区文件，统一软硬件时间

四、Docker Compose 核心配置规范

1. 基础约束规范

• 镜像规范：固定使用私有仓库mssql/server:2022-latest，禁止混用其他版本。

• 重启策略：生产强制restart: always，实现异常自动重启恢复。

• 网络规范：仅接入内网网桥，禁止直接对公网暴露1433端口。

• 启动约束：禁止自定义启动命令、禁止Root运行、禁止开启特权模式。

2. 环境变量规范

• ACCEPT_EULA=Y：必填项，接收微软许可协议，缺失无法启动服务。

• TZ=Asia/Shanghai：统一时区，避免业务数据、日志时间错乱。

• SA_PASSWORD：必须满足强密码策略（8位以上，包含大小写、数字、特殊符号）。

• MSSQL_MEMORY_LIMIT_MB：Express版本固定配置3072，对齐官方3G内存硬上限。

3. 健康检查规范

SQL Server 2022初始化耗时较长，采用进程检测替代接口检测，配置参数：start_period=40s、interval=15s、合理重试次数，避免Docker误判服务异常盲目重启。

五、容器性能调优规范

1. 容器资源配额

采用「保底预留+上限限制」双层资源管控，防止资源抢占与OOM崩溃，适配中小型生产业务：

• CPU：预留1核保底，最大限制2核，避免独占整机CPU资源。

• 内存：预留2G保底，最大限制4G，平衡缓存需求与整机内存资源。

2. 内存参数适配规则

• Express版本：强制配置3G内存限制，超配无效且易引发服务异常。

• Enterprise/Standard商业版：删除固定内存限制，依托容器上限动态调度性能。

3. 通用性能禁忌

• 容器内存上限不得低于数据库内存配置，否则启动失败、频繁重启。

• 整机禁止开启Swap交换分区，杜绝数据库读写卡顿、事务超时。

• 强制容器与宿主机时区一致，防止定时任务、数据统计异常。

4. 磁盘IO读写规范

• 挂载模式：所有业务目录采用rw绑定挂载，禁止只读、临时挂载，保障数据持久化与读写稳定。

• 磁盘选型：生产强制使用SSD/NVMe固态盘，禁止HDD机械盘，规避高并发IO延迟、事务阻塞问题。

• 部署原则：最优架构为数据文件、事务日志分盘存储，隔离随机IO与顺序IO，避免高峰期IO争抢。

• 挂载禁忌：禁止挂载系统目录、NFS网络共享目录，杜绝网络IO抖动引发写入超时、事务回滚。

六、版本授权规范

1. 授权机制

SQL Server容器版无激活码、无证书，仅通过MSSQL_PID环境变量声明版本，合规性以企业有效微软License为准。

2. 版本配置标准

• Express（当前生产使用）：免费商用，限制3G内存、单库10G、单CPU核心。

• Enterprise：付费企业版，解锁高可用、分区表等全部高级功能，无硬件限制。

• Standard：付费标准版，适配中小型生产场景。

• 生产禁用：Developer开发版。

3. 版本切换规则

• Express升级企业版：替换PID参数、删除内存限制，重建容器生效，数据不丢失。

• 无商业授权禁止配置Enterprise，属于合规违规。

4. 版本验证SQL

SELECT @@VERSION;
SELECT SERVERPROPERTY('Edition');

七、生产禁用操作红线

• 禁止使用777全局权限、禁止Root用户运行SQL容器。

• 禁止使用非10001:10001UID授权数据目录。

• 禁止对公网暴露1433数据库端口。

• 禁止目录混挂、禁止手动修改容器内部文件权限。

• 禁止生产环境使用开发版、错误PID参数。

• 禁止不重建容器，直接热改权限、版本、核心参数。

八、多组件同机混部生产规范

SQLServer、Redis、RabbitMQ、ES、Kibana、MongoDB、InfluxDB、EMQX全组件支持单服务器容器混部，中小型生产环境稳定可用。核心管控重点：IO优先级隔离、全组件资源限额、UID目录独立、关闭Swap、日志管控。

1. 各组件资源压力特征

• SQL Server（最高优先级）：重度随机IO、高内存占用，对事务延迟极度敏感，所有组件需避让资源。

• InfluxDB（最大IO压力）：高频时序持续刷盘，是整机IO抖动、SQL超时的首要诱因。

• Elasticsearch：大内存常驻、段合并IO高，易抢占整机资源。

• RabbitMQ/EMQX：消息堆积、持久化刷盘会突发拉高磁盘IO。

• MongoDB：高频文档读写，持续产生磁盘压力。

• Redis：纯内存运行，对整机卡顿、Swap抖动高度敏感。

• Kibana：轻量可视化服务，无资源冲突风险。

2. 磁盘IO隔离规范

• 优先级：SQL Server IO优先级全局最高，禁止其他组件高峰期大批量写盘、索引重建、数据删除。

• 挂载隔离：所有组件目录完全独立，禁止共用父目录，避免文件锁、权限争抢。

• 硬件要求：整机统一使用SSD/NVMe固态盘，禁止HDD机械盘。

• 日志管控：各组件独立日志目录，禁止日志无限制输出，防止占满磁盘、阻塞IO。

3. UID权限隔离规范

• SQL Server：固定UID=10001，目录专属授权，不可变更。

• ES、InfluxDB：默认UID=1000。

• Redis、RabbitMQ、EMQX、MongoDB：默认UID=999。

• 核心规则：所有组件数据目录互不共享、互不挂载，独立授权，彻底杜绝权限冲突。

4. 资源管控规范（防雪崩）

• 所有组件必须配置CPU、内存资源限额，禁止无限制抢占整机资源。

• ES固定JVM内存，防止内存溢出挤占SQL缓存。

• InfluxDB配置数据过期策略（30天），避免数据无限膨胀。

• 整机严格关闭Swap，杜绝所有中间件、数据库延迟抖动问题。

5. 网络规范

• 所有服务统一接入internal-net内网网桥，内网互通、外网隔离。

• 所有组件端口天然无冲突，无需额外修改。

• 核心数据库、中间件端口禁止对公网暴露。

6. 混部生产禁忌

• 禁止高峰期执行InfluxDB批量读写、ES索引重建、大批量数据导入操作。

• 禁止MQ、EMQX无堆积阈值限制，海量消息持久化打爆磁盘IO。

• 禁止组件目录共用、权限混用、全局777授权。

• 禁止取消任意组件资源limit限制，引发整机资源雪崩。

九、最终零瑕疵生产 docker-compose.yml

本配置为项目最终上线版本，补齐所有组件资源配额，杜绝OOM与资源抢占，完全适配同机混部架构，保留全部原有业务配置。

version: "3.8"
networks:
  internal-net:
    external: true

services:
  # Redis缓存服务
  redis:
    image: 10.31.20.103:8081/public-docker/redis:6.2.0
    container_name: redis6
    restart: always
    ports:
      - "6379:6379"
    volumes:
      - ./redis/redis.conf:/usr/local/etc/redis/redis.conf:ro
      - ./redis/data:/data:rw
      - ./redis/logs:/var/log/redis:rw
    environment:
      - TZ=Asia/Shanghai
    command: ["redis-server", "/usr/local/etc/redis/redis.conf"]
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 5s
      timeout: 3s
      retries: 3
    networks:
      - internal-net
    deploy:
      resources:
        limits:
          cpus: '0.5'
          memory: 512M
        reservations:
          cpus: '0.2'
          memory: 256M

  # RabbitMQ消息队列
  rabbitmq:
    image: 10.31.20.103:8081/public-docker/rabbitmq:3.13-management
    container_name: rabbitmq
    restart: always
    hostname: rabbitmq
    environment:
      - RABBITMQ_DEFAULT_VHOST=my_vhost
      - RABBITMQ_DEFAULT_USER=admin
      - RABBITMQ_DEFAULT_PASS=shhy123#
      - TZ=Asia/Shanghai
    volumes:
      - ./rabbitmq/data:/var/lib/rabbitmq:rw
      - ./rabbitmq/logs:/var/log/rabbitmq:rw
    ports:
      - "4369:4369"
      - "5672:5672"
      - "15672:15672"
      - "25672:25672"
    cap_add:
      - CAP_SYS_NICE
    networks:
      - internal-net
    healthcheck:
      test: ["CMD", "rabbitmq-diagnostics", "ping"]
      interval: 10s
      timeout: 5s
      retries: 3
    deploy:
      resources:
        limits:
          cpus: '1'
          memory: 1G
        reservations:
          cpus: '0.5'
          memory: 512M

  # Elasticsearch搜索引擎
  es:
    image: 10.31.20.103:8081/public-docker/elasticsearch:8.17.2
    container_name: es
    restart: always
    hostname: es
    environment:
      - "ES_JAVA_OPTS=-Xms2048m -Xmx2048m"
      - "discovery.type=single-node"
      - "cluster.name=elasticsearch-spc"
      - "ELASTIC_PASSWORD=shhy123#"
      - "TAKE_FILE_OWNERSHIP=true"
      - TZ=Asia/Shanghai
    volumes:
      - ./es-kibana/es/master/conf/elasticsearch.yml:/usr/share/elasticsearch/config/elasticsearch.yml:ro
      - ./es-kibana/es/master/data:/usr/share/elasticsearch/data:rw
      - ./es-kibana/es/master/logs:/usr/share/elasticsearch/logs:rw
      - ./es-kibana/es/master/plugins:/usr/share/elasticsearch/plugins:rw
    ports:
      - "9200:9200"
      - "9300:9300"
    networks:
      - internal-net
    healthcheck:
      test: ["CMD", "curl", "-s", "-u", "elastic:$$ELASTIC_PASSWORD", "http://localhost:9200/\_cluster/health"]
      interval: 15s
      timeout: 10s
      retries: 3
    deploy:
      resources:
        limits:
          cpus: '1.5'
          memory: 3G
        reservations:
          cpus: '0.8'
          memory: 2.2G

  # Kibana可视化面板
  kibana:
    image: 10.31.20.103:8081/public-docker/kibana:8.17.2
    container_name: kibana
    restart: always
    hostname: kibana
    environment:
      - TZ=Asia/Shanghai
      - "elasticsearch.hosts=http://es:9200"
      - "elasticsearch.username=kibana_system"
      - "elasticsearch.password=shhy123#"
      - "NODE_OPTIONS=--openssl-legacy-provider=false"
    volumes:
      - ./es-kibana/kibana/kibana.yml:/usr/share/kibana/config/kibana.yml:ro
    ports:
      - "5601:5601"
    networks:
      - internal-net
    depends_on:
      - es
    healthcheck:
      test: ["CMD", "curl", "-s", "http://localhost:5601/api/status"]
      interval: 15s
      timeout: 10s
      retries: 3
    deploy:
      resources:
        limits:
          cpus: '0.5'
          memory: 512M
        reservations:
          cpus: '0.2'
          memory: 256M

  # MongoDB文档数据库
  mongodb:
    image: 10.31.20.103:8081/public-docker/mongo:8.0.3
    container_name: mongodb
    restart: always
    hostname: mongodb
    environment:
      - TZ=Asia/Shanghai
      - MONGO_INITDB_ROOT_USERNAME=admin
      - MONGO_INITDB_ROOT_PASSWORD=shhy123#
    volumes:
      - ./mongodb/data:/data/db:rw
      - ./mongodb/logs:/var/log/mongodb:rw
    ports:
      - "27017:27017"
    networks:
      - internal-net
    healthcheck:
      test: ["CMD", "mongosh", "--eval", "db.adminCommand('ping')", "-u", "admin", "-p", "shhy123#", "--authenticationDatabase", "admin"]
      interval: 10s
      timeout: 5s
      retries: 3
    deploy:
      resources:
        limits:
          cpus: '1'
          memory: 1G
        reservations:
          cpus: '0.4'
          memory: 512M

  # InfluxDB时序数据库
  influxdb:
    image: 10.31.20.103:8081/public-docker/influxdb:2.7.10
    container_name: influxdb
    restart: always
    hostname: influxdb
    environment:
      - TZ=Asia/Shanghai
      - DOCKER_INFLUXDB_INIT_MODE=setup
      - DOCKER_INFLUXDB_INIT_USERNAME=admin
      - DOCKER_INFLUXDB_INIT_PASSWORD=shhy123#
      - DOCKER_INFLUXDB_INIT_ORG=my_org
      - DOCKER_INFLUXDB_INIT_BUCKET=default_bucket
      - DOCKER_INFLUXDB_INIT_RETENTION=30d
      - DOCKER_INFLUXDB_INIT_ADMIN_TOKEN=my_secret_token_123
    volumes:
      - ./influxdb/data:/var/lib/influxdb2:rw
      - ./influxdb/config:/etc/influxdb2:rw
      - ./influxdb/logs:/var/log/influxdb2:rw
    ports:
      - "8086:8086"
    networks:
      - internal-net
    healthcheck:
      test: ["CMD", "curl", "-s", "-o", "/dev/null", "http://localhost:8086/health"]
      interval: 10s
      timeout: 5s
      retries: 3
    deploy:
      resources:
        limits:
          cpus: '1'
          memory: 1G
        reservations:
          cpus: '0.5'
          memory: 512M

  # EMQX MQTT物联网网关
  emqx:
    image: 10.31.20.103:8081/public-docker/emqx/emqx:5.8.8
    container_name: emqx
    restart: always
    hostname: emqx
    environment:
      - TZ=Asia/Shanghai
      - EMQX_NODE_NAME=emqx@127.0.0.1
      - EMQX_CLUSTER__DISCOVERY_STRATEGY=static
      - EMQX_LISTENER_TCP_DEFAULT_BIND=0.0.0.0:1883
      - EMQX_LISTENER_WS_DEFAULT_BIND=0.0.0.0:8083
      - EMQX_LOG_LEVEL=info
      - EMQX_LOG_CONSOLE_ENABLE=true
      - EMQX_NODE_PROCESS_LIMIT=2097152
      - EMQX_NODE_MAX_PORTS=1048576
      - EMQX_NODE_COOKIE=emqx_secret_cookie_123
    volumes:
      - ./emqx/data:/opt/emqx/data:rw
      - ./emqx/log:/opt/emqx/log:rw
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "1883:1883"
      - "8083:8083"
      - "8084:8084"
      - "8883:8883"
      - "18083:18083"
    networks:
      - internal-net
    healthcheck:
      test: ["CMD", "/opt/emqx/bin/emqx", "ctl", "status"]
      interval: 20s
      timeout: 25s
      retries: 10
      start_period: 60s
    deploy:
      resources:
        limits:
          cpus: '1'
          memory: 1G
        reservations:
          cpus: '0.5'
          memory: 512M

  # SQL Server 2022 关系型数据库
  sqlserver:
    image: 10.31.20.103:8081/public-docker/mssql/server:2022-latest
    container_name: sqlserver2022
    restart: always
    hostname: sqlserver
    environment:
      - TZ=Asia/Shanghai
      - ACCEPT_EULA=Y
      - SA_PASSWORD=shhy123#
      - MSSQL_PID=Express
      - MSSQL_MEMORY_LIMIT_MB=3072
    volumes:
      - ./sqlserver/data:/var/opt/mssql:rw
      - ./sqlserver/logs:/var/log/mssql:rw
      - ./sqlserver/backup:/var/opt/mssql/backup:rw
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "1433:1433"
    networks:
      - internal-net
    deploy:
      resources:
        limits:
          cpus: '2'
          memory: 4g
        reservations:
          cpus: '1'
          memory: 2g
    healthcheck:
      test: ["CMD-SHELL", "pidof sqlservr"]
      interval: 15s
      timeout: 10s
      retries: 5
      start_period: 40s

十、终版配置说明

• 全组件资源防护：所有服务均配置CPU、内存上下限，无裸奔组件，彻底杜绝单组件资源溢出引发整机OOM、服务雪崩。

• 业务优先级适配：SQL Server、ES等高负载核心组件资源配额更高，优先保障数据库业务稳定运行，规避资源抢占。

• 完全兼容原有业务：仅新增资源限制，镜像、路径、账号密码、端口、网络、健康检查全部保留，可直接覆盖升级，无需改动业务配置。

• 合规适配混部规范：完全匹配权限、IO、网络、隔离生产规范，为整套集群最终归档上线版本。

十一、总结

SQL Server 2022容器化部署核心管控要点为目录权限适配、版本授权合规、磁盘IO与资源性能调优。整套多组件同机混部架构，严格遵循内网隔离、独立挂载、资源限额、IO优先级管控、关闭Swap等生产规范，可实现集群长期稳定运行，彻底规避启动报错、性能抖动、资源雪崩、授权违规等生产风险，完全满足中小型项目生产上线标准。