上一篇 下一篇 分享链接 返回 返回顶部

Docker 生产落地全套方案:从镜像规范到 CI/CD、监控与安全配置

发布人:慈云数据-客服中心 发布时间:19小时前 阅读量:2

Docker 企业级实战方案|附配置文件

在企业级应用交付体系中,Docker 已经不再只是“把应用打包成镜像”的工具,而是贯穿研发、测试、发布、运维、安全与治理的基础能力。对于中大型企业而言,Docker 的价值主要体现在环境一致性、交付标准化、资源利用率提升、快速回滚、弹性扩展以及 DevOps 流程自动化等方面。

本文将从企业级落地视角出发,围绕 Docker 架构设计、镜像规范、网络与存储、日志监控、安全加固、CI/CD 集成、生产环境部署等方面进行系统说明,并提供可直接参考的配置文件示例。


一、企业为什么需要 Docker?

在传统部署模式下,应用通常直接运行在物理机或虚拟机上。随着业务规模扩大,企业会遇到以下问题:

  1. 环境不一致

    • 开发环境、测试环境、预生产环境、生产环境依赖版本不同;
    • “在我电脑上能跑”的问题频繁出现;
    • 运维人员需要手工安装 JDK、Nginx、Node.js、Python、数据库客户端等依赖。
  2. 发布效率低

    • 应用发布依赖大量手工操作;
    • 回滚复杂,容易遗漏文件或配置;
    • 多个应用部署在同一台服务器时,依赖冲突明显。
  3. 资源利用率低

    • 每个虚拟机都需要完整操作系统;
    • 虚拟机启动慢、占用资源多;
    • 部署密度受限。
  4. 扩容和迁移困难

    • 扩容需要重复安装环境;
    • 应用迁移到其他服务器时成本较高;
    • 不同云平台之间迁移复杂。

Docker 通过镜像、容器、仓库、网络、卷等机制,使应用可以以标准化方式构建、运行、分发和管理。企业可以将应用及依赖统一封装到镜像中,从而实现“一次构建,到处运行”。


二、企业级 Docker 总体架构设计

一个相对完整的企业级 Docker 实战方案,通常包含以下几个核心部分:

开发人员
   |
   | 提交代码
   v
Git 仓库
   |
   | 触发 CI/CD
   v
构建服务器 Jenkins / GitLab CI
   |
   | 构建镜像、执行测试、扫描漏洞
   v
私有镜像仓库 Harbor
   |
   | 拉取镜像
   v
测试环境 / 预生产环境 / 生产环境
   |
   | Docker Compose / Kubernetes / Swarm 部署
   v
日志监控平台 Prometheus + Grafana + ELK / Loki

在企业中,Docker 不应单独使用,而应与以下系统结合:

模块 推荐方案
代码管理 GitLab、GitHub Enterprise、Gitee 企业版
CI/CD Jenkins、GitLab CI、Argo CD
镜像仓库 Harbor、Nexus、JFrog Artifactory
编排平台 Docker Compose、Kubernetes、Docker Swarm
日志系统 ELK、EFK、Loki
监控系统 Prometheus、Grafana、Zabbix
安全扫描 Trivy、Clair、Harbor Scanner
配置中心 Nacos、Apollo、Consul
密钥管理 Vault、Kubernetes Secret

对于中小型企业,可以先采用 Docker Compose + Harbor + Jenkins 的组合。对于业务规模较大、需要自动扩缩容和高可用调度的企业,建议进一步引入 Kubernetes。


三、Docker 主机规划

生产环境中,不建议将所有容器都运行在一台服务器上。应根据业务类型和负载进行节点规划。

1. 推荐服务器角色划分

服务器角色 主要职责
构建节点 执行代码拉取、编译、镜像构建
镜像仓库节点 部署 Harbor 或 Nexus
应用节点 运行 Java、Go、Node.js、Python 等业务容器
数据库节点 运行 MySQL、PostgreSQL、Redis 等,生产建议优先使用专用主机或云数据库
日志监控节点 运行 Prometheus、Grafana、ELK、Loki 等组件
反向代理节点 Nginx、Traefik、HAProxy、负载均衡入口

2. 生产环境基础建议

  • 操作系统建议使用:Ubuntu Server LTS、Rocky Linux、AlmaLinux、Debian;
  • Docker 数据目录建议挂载到独立磁盘;
  • 生产环境开启日志轮转,避免容器日志撑爆磁盘;
  • 所有容器必须设置重启策略;
  • 业务容器应配置 CPU、内存限制;
  • 数据类容器必须使用 volume 或宿主机目录持久化;
  • 镜像版本必须使用明确 tag,不建议生产使用 latest
  • 镜像构建应采用多阶段构建,减少镜像体积;
  • 生产环境禁止容器使用 --privileged,除非有明确安全评估。

四、Docker 安装与基础配置

以下以 Linux 服务器为例。

1. 安装 Docker

Ubuntu / Debian:

sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg lsb-release

sudo mkdir -p /etc/apt/keyrings

curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
  | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" \
  | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update
sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

sudo systemctl enable docker
sudo systemctl start docker

CentOS / Rocky Linux / AlmaLinux:

sudo yum install -y yum-utils

sudo yum-config-manager \
  --add-repo \
  https://download.docker.com/linux/centos/docker-ce.repo

sudo yum install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

sudo systemctl enable docker
sudo systemctl start docker

五、Docker Daemon 企业级配置

生产环境中,Docker 默认配置并不完全适合企业场景,建议统一配置 /etc/docker/daemon.json

配置文件:/etc/docker/daemon.json

{
  "data-root": "/data/docker",
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "200m",
    "max-file": "5"
  },
  "storage-driver": "overlay2",
  "registry-mirrors": [
    "https://docker.m.daocloud.io"
  ],
  "insecure-registries": [
    "harbor.example.com"
  ],
  "exec-opts": [
    "native.cgroupdriver=systemd"
  ],
  "live-restore": true,
  "icc": false,
  "userland-proxy": false,
  "no-new-privileges": true
}

配置说明:

配置项 说明
data-root Docker 数据目录,建议放到独立磁盘
log-driver 日志驱动,默认使用 json-file
max-size 单个日志文件最大大小
max-file 日志保留文件数量
storage-driver 推荐使用 overlay2
registry-mirrors 镜像加速地址
insecure-registries 内网 Harbor 未配置 HTTPS 时使用
live-restore Docker daemon 重启时不影响已运行容器
icc 禁止默认 bridge 网络容器互通
no-new-privileges 阻止容器获得额外权限

修改后重启 Docker:

sudo systemctl daemon-reload
sudo systemctl restart docker

六、企业级镜像构建规范

镜像是 Docker 的交付核心。一个优秀的企业级镜像应具备以下特征:

  • 体积小;
  • 构建速度快;
  • 层级清晰;
  • 不包含敏感信息;
  • 有明确版本号;
  • 使用非 root 用户运行;
  • 支持健康检查;
  • 具备必要的启动参数。

1. Java Spring Boot 项目 Dockerfile

# 第一阶段:构建阶段
FROM maven:3.9.6-eclipse-temurin-17 AS builder

WORKDIR /build

COPY pom.xml .
RUN mvn dependency:go-offline -B

COPY src ./src
RUN mvn clean package -DskipTests

# 第二阶段:运行阶段
FROM eclipse-temurin:17-jre-jammy

LABEL maintainer="devops@example.com"
LABEL app="enterprise-service"

ENV TZ=Asia/Shanghai
ENV JAVA_OPTS="-Xms512m -Xmx512m -XX:+UseG1GC"
ENV APP_HOME=/app

WORKDIR ${APP_HOME}

RUN groupadd -r app && useradd -r -g app app \
    && mkdir -p /app/logs \
    && chown -R app:app /app

COPY --from=builder /build/target/*.jar app.jar

USER app

EXPOSE 8080

HEALTHCHECK --interval=30s --timeout=5s --retries=3 \
  CMD curl -f http://localhost:8080/actuator/health || exit 1

ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -jar app.jar"]

2. Node.js 项目 Dockerfile

FROM node:20-alpine AS builder

WORKDIR /build

COPY package*.json ./
RUN npm ci

COPY . .
RUN npm run build

FROM nginx:1.25-alpine

LABEL maintainer="frontend@example.com"

COPY --from=builder /build/dist /usr/share/nginx/html
COPY nginx.conf /etc/nginx/conf.d/default.conf

EXPOSE 80

HEALTHCHECK --interval=30s --timeout=3s \
  CMD wget -qO- http://localhost/ || exit 1

3. .dockerignore 示例

.git
.gitignore
README.md
target
node_modules
logs
tmp
.env
*.log
Dockerfile
docker-compose.yml

.dockerignore 非常重要,它可以减少构建上下文体积,避免无关文件或敏感文件被打包进镜像。


七、Docker Compose 企业级部署方案

在没有引入 Kubernetes 的情况下,Docker Compose 是企业内部部署测试环境、预生产环境、小规模生产环境的常用方案。

下面以一个典型业务系统为例,包含:

  • Nginx 网关;
  • Spring Boot 后端服务;
  • MySQL 数据库;
  • Redis 缓存;
  • Prometheus 监控;
  • Grafana 可视化。

配置文件:docker-compose.yml

version: "3.9"

services:
  nginx:
    image: nginx:1.25-alpine
    container_name: enterprise-nginx
    restart: always
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx/conf.d:/etc/nginx/conf.d:ro
      - ./nginx/certs:/etc/nginx/certs:ro
      - ./nginx/logs:/var/log/nginx
    networks:
      - frontend
      - backend
    depends_on:
      - app

  app:
    image: harbor.example.com/prod/enterprise-service:1.0.0
    container_name: enterprise-app
    restart: always
    environment:
      SPRING_PROFILES_ACTIVE: prod
      JAVA_OPTS: "-Xms1024m -Xmx1024m -XX:+UseG1GC"
      MYSQL_HOST: mysql
      MYSQL_PORT: 3306
      MYSQL_DATABASE: enterprise
      MYSQL_USERNAME: enterprise_user
      MYSQL_PASSWORD: "ChangeMe_2026"
      REDIS_HOST: redis
      REDIS_PORT: 6379
    expose:
      - "8080"
    volumes:
      - ./app/logs:/app/logs
    networks:
      - backend
    depends_on:
      mysql:
        condition: service_healthy
      redis:
        condition: service_started
    deploy:
      resources:
        limits:
          cpus: "2.0"
          memory: 2G
        reservations:
          cpus: "0.5"
          memory: 512M

  mysql:
    image: mysql:8.0
    container_name: enterprise-mysql
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: "RootStrongPassword_2026"
      MYSQL_DATABASE: enterprise
      MYSQL_USER: enterprise_user
      MYSQL_PASSWORD: "ChangeMe_2026"
      TZ: Asia/Shanghai
    command:
      --default-authentication-plugin=mysql_native_password
      --character-set-server=utf8mb4
      --collation-server=utf8mb4_unicode_ci
      --max_connections=1000
      --innodb_buffer_pool_size=1G
    ports:
      - "3306:3306"
    volumes:
      - mysql-data:/var/lib/mysql
      - ./mysql/conf.d:/etc/mysql/conf.d
      - ./mysql/init:/docker-entrypoint-initdb.d
      - ./mysql/logs:/var/log/mysql
    networks:
      - backend
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-uroot", "-pRootStrongPassword_2026"]
      interval: 10s
      timeout: 5s
      retries: 5

  redis:
    image: redis:7.2-alpine
    container_name: enterprise-redis
    restart: always
    command: redis-server /usr/local/etc/redis/redis.conf
    ports:
      - "6379:6379"
    volumes:
      - redis-data:/data
      - ./redis/redis.conf:/usr/local/etc/redis/redis.conf
    networks:
      - backend

  prometheus:
    image: prom/prometheus:v2.49.1
    container_name: enterprise-prometheus
    restart: always
    volumes:
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus-data:/prometheus
    ports:
      - "9090:9090"
    networks:
      - backend

  grafana:
    image: grafana/grafana:10.2.3
    container_name: enterprise-grafana
    restart: always
    environment:
      GF_SECURITY_ADMIN_USER: admin
      GF_SECURITY_ADMIN_PASSWORD: "GrafanaStrongPassword_2026"
    volumes:
      - grafana-data:/var/lib/grafana
    ports:
      - "3000:3000"
    networks:
      - backend
    depends_on:
      - prometheus

networks:
  frontend:
    driver: bridge
  backend:
    driver: bridge

volumes:
  mysql-data:
  redis-data:
  prometheus-data:
  grafana-data:

注意:deploy.resources 在普通 docker compose 模式下部分配置可能不完全生效,如果需要严格资源限制,可以结合 docker run 参数或使用 Docker Swarm / Kubernetes。


八、Nginx 反向代理配置

Nginx 在企业级系统中通常作为统一入口,负责域名路由、HTTPS 终止、静态资源服务、负载均衡、限流等。

配置文件:nginx/conf.d/default.conf

upstream enterprise_backend {
    server app:8080 max_fails=3 fail_timeout=30s;
}

server {
    listen 80;
    server_name example.com;

    access_log /var/log/nginx/access.log;
    error_log  /var/log/nginx/error.log warn;

    client_max_body_size 50m;

    location / {
        proxy_pass http://enterprise_backend;
        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_connect_timeout 10s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;
    }

    location /health {
        access_log off;
        return 200 "ok\n";
    }
}

如果需要 HTTPS,可以增加如下配置:

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/nginx/certs/example.com.crt;
    ssl_certificate_key /etc/nginx/certs/example.com.key;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    location / {
        proxy_pass http://enterprise_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

九、Redis 企业级配置

配置文件:redis/redis.conf

bind 0.0.0.0
port 6379

protected-mode yes
requirepass RedisStrongPassword_2026

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec

save 900 1
save 300 10
save 60 10000

maxmemory 512mb
maxmemory-policy allkeys-lru

tcp-keepalive 300
timeout 0

loglevel notice

配置说明:

  • requirepass:设置 Redis 密码;
  • appendonly yes:开启 AOF 持久化;
  • maxmemory:限制最大内存;
  • maxmemory-policy:设置淘汰策略;
  • bind 0.0.0.0:允许容器网络访问,但必须结合防火墙与密码保护。

生产环境建议 Redis 不直接暴露公网端口。


十、MySQL 企业级配置

配置文件:mysql/conf.d/my.cnf

[mysqld]
server-id=1

character-set-server=utf8mb4
collation-server=utf8mb4_unicode_ci

default-time-zone='+8:00'

max_connections=1000
max_connect_errors=10000

innodb_buffer_pool_size=1G
innodb_log_file_size=256M
innodb_flush_log_at_trx_commit=1
innodb_file_per_table=1

slow_query_log=1
slow_query_log_file=/var/log/mysql/slow.log
long_query_time=1

log_bin=mysql-bin
binlog_format=ROW
expire_logs_days=7

skip-name-resolve

生产建议:

  • 关键业务数据库优先使用云数据库或专用数据库集群;
  • 如果必须容器化 MySQL,应将数据目录挂载到可靠磁盘;
  • 定期备份数据;
  • 开启慢查询日志;
  • 合理配置 buffer pool;
  • 不要让数据库端口暴露到公网。

十一、Prometheus 监控配置

Prometheus 可用于采集应用、主机、容器、数据库等指标。Spring Boot 应用可通过 Actuator 暴露 /actuator/prometheus

配置文件:prometheus/prometheus.yml

global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: "enterprise-app"
    metrics_path: "/actuator/prometheus"
    static_configs:
      - targets:
          - "app:8080"

  - job_name: "prometheus"
    static_configs:
      - targets:
          - "localhost:9090"

Spring Boot 项目需要引入依赖:


    org.springframework.boot
    spring-boot-starter-actuator



    io.micrometer
    micrometer-registry-prometheus

并在 application-prod.yml 中开启指标端点:

management:
  endpoints:
    web:
      exposure:
        include: health,info,prometheus,metrics
  endpoint:
    health:
      show-details: always

十二、日志治理方案

企业中常见的日志方式有三种:

1. 容器标准输出

应用日志直接输出到 stdout / stderr,由 Docker 日志驱动接管。这种方式简单,适合云原生环境。

优点:

  • 统一;
  • 易采集;
  • 不依赖容器内文件;
  • 符合十二要素应用原则。

缺点:

  • 如果不配置日志轮转,容易占满磁盘。

2. 挂载日志目录

应用将日志写到 /app/logs,宿主机挂载目录后由 Filebeat 或 Fluent Bit 采集。

优点:

  • 兼容传统日志系统;
  • 便于本地排查。

缺点:

  • 需要规划目录;
  • 容器迁移时日志路径要统一。

3. 集中式日志平台

推荐企业使用以下组合:

应用容器 -> Filebeat / Fluent Bit -> Elasticsearch / Loki -> Kibana / Grafana

如果追求轻量化,推荐使用 Loki + Promtail + Grafana。相比 ELK,Loki 对资源要求更低。


十三、CI/CD 流水线设计

企业级 Docker 落地的核心不只是部署,而是构建完整的自动化交付流程。

推荐流程

开发提交代码
   |
   v
触发流水线
   |
   v
代码检查
   |
   v
单元测试
   |
   v
构建应用
   |
   v
构建 Docker 镜像
   |
   v
镜像安全扫描
   |
   v
推送 Harbor
   |
   v
部署测试环境
   |
   v
人工审批
   |
   v
部署生产环境

Jenkins Pipeline 示例

配置文件:Jenkinsfile

pipeline {
    agent any

    environment {
        REGISTRY = "harbor.example.com"
        PROJECT = "prod"
        APP_NAME = "enterprise-service"
        IMAGE_TAG = "${BUILD_NUMBER}"
        IMAGE = "${REGISTRY}/${PROJECT}/${APP_NAME}:${IMAGE_TAG}"
    }

    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }

        stage('Unit Test') {
            steps {
                sh 'mvn test'
            }
        }

        stage('Build Jar') {
            steps {
                sh 'mvn clean package -DskipTests'
            }
        }

        stage('Build Docker Image') {
            steps {
                sh "docker build -t ${IMAGE} ."
            }
        }

        stage('Security Scan') {
            steps {
                sh "trivy image --severity HIGH,CRITICAL --exit-code 0 ${IMAGE}"
            }
        }

        stage('Push Image') {
            steps {
                withCredentials([usernamePassword(
                    credentialsId: 'harbor-credential',
                    usernameVariable: 'HARBOR_USER',
                    passwordVariable: 'HARBOR_PASS'
                )]) {
                    sh """
                    echo ${HARBOR_PASS} | docker login ${REGISTRY} -u ${HARBOR_USER} --password-stdin
                    docker push ${IMAGE}
                    """
                }
            }
        }

        stage('Deploy') {
            steps {
                sh """
                ssh deploy@prod-server '
                  cd /opt/enterprise &&
                  sed -i "s#image: .*enterprise-service:.*#image: ${IMAGE}#g" docker-compose.yml &&
                  docker compose pull app &&
                  docker compose up -d app
                '
                """
            }
        }
    }

    post {
        success {
            echo "Deployment success: ${IMAGE}"
        }
        failure {
            echo "Deployment failed"
        }
    }
}

生产环境建议在 Deploy 阶段增加人工审批,例如 Jenkins 的 input 步骤。


十四、Harbor 私有镜像仓库方案

企业不应长期依赖公共镜像仓库保存业务镜像,建议部署 Harbor。Harbor 提供:

  • 镜像存储;
  • 项目权限管理;
  • 镜像复制;
  • 漏洞扫描;
  • 镜像签名;
  • 镜像保留策略;
  • Web 管理界面。

Harbor 使用建议

  1. 按环境划分项目:

    • dev
    • test
    • stage
    • prod
  2. 按团队划分权限:

    • 开发人员可推送 dev/test;
    • 测试人员可拉取 test;
    • 运维人员可管理 stage/prod;
    • 生产镜像推送必须经过流水线。
  3. 开启镜像保留策略:

    • dev 环境保留最近 20 个版本;
    • test 环境保留最近 50 个版本;
    • prod 环境保留全部或最近 100 个稳定版本。
  4. 开启漏洞扫描:

    • 高危漏洞阻断生产发布;
    • 中危漏洞建立修复计划。

十五、生产环境发布与回滚策略

Docker 发布并不等于简单执行 docker compose up -d,企业应建立标准发布策略。

1. 蓝绿发布

准备两套环境:

  • Blue:当前生产环境;
  • Green:新版本环境。

发布时先将新版本部署到 Green,验证通过后切换流量。如果出现问题,再切回 Blue。

优点是回滚快,缺点是资源占用较高。

2. 灰度发布

先将少量用户流量切到新版本,例如 5%、10%、30%、50%,逐步扩大范围。适合用户量较大的业务。

3. 滚动发布

逐个替换服务实例,保证系统始终有可用实例。Docker Compose 对滚动发布支持有限,Kubernetes 更适合此类场景。

4. 快速回滚

如果使用 Docker Compose,可以通过镜像 tag 回滚:

docker compose down
sed -i 's/enterprise-service:1.0.1/enterprise-service:1.0.0/g' docker-compose.yml
docker compose pull
docker compose up -d

更推荐保留每次发布的 docker-compose.yml 文件副本:

releases/
  20260101-120000/docker-compose.yml
  20260105-210000/docker-compose.yml
  20260110-180000/docker-compose.yml

回滚时直接使用历史版本配置。


十六、安全加固实践

Docker 安全是企业级落地中非常重要的一环。建议从以下方面入手。

1. 镜像安全

  • 使用官方基础镜像或企业内部认证镜像;
  • 定期更新基础镜像;
  • 不在镜像中写入密码、Token、SSH Key;
  • 使用 Trivy 扫描镜像漏洞;
  • 使用多阶段构建减少攻击面;
  • 删除无用工具,例如 curl、wget、bash 等,视业务情况决定。

2. 容器运行安全

  • 使用非 root 用户运行容器;
  • 不使用 --privileged
  • 不挂载宿主机敏感目录,如 /etc/root/var/run/docker.sock
  • 限制 CPU 和内存;
  • 设置只读文件系统;
  • 禁止容器新增权限。

示例:

services:
  app:
    image: harbor.example.com/prod/enterprise-service:1.0.0
    read_only: true
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    tmpfs:
      - /tmp

3. 网络安全

  • 容器网络分层;
  • 数据库、缓存不暴露公网;
  • 仅 Nginx 或网关暴露外部端口;
  • 使用防火墙限制访问来源;
  • 内部服务通过 Docker 网络通信;
  • 生产环境使用 HTTPS。

4. 密码与配置管理

不建议在 docker-compose.yml 中明文写密码。更好的方式是使用 .env 文件或密钥管理系统。

.env 示例

MYSQL_ROOT_PASSWORD=RootStrongPassword_2026
MYSQL_DATABASE=enterprise
MYSQL_USER=enterprise_user
MYSQL_PASSWORD=ChangeMe_2026
REDIS_PASSWORD=RedisStrongPassword_2026
GRAFANA_ADMIN_PASSWORD=GrafanaStrongPassword_2026

Compose 中引用:

environment:
  MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
  MYSQL_DATABASE: ${MYSQL_DATABASE}
  MYSQL_USER: ${MYSQL_USER}
  MYSQL_PASSWORD: ${MYSQL_PASSWORD}

.env 文件必须加入 .gitignore,禁止提交到 Git 仓库。


十七、备份与灾备方案

企业生产系统必须具备备份与恢复能力,尤其是数据库、对象存储、配置文件和镜像仓库。

1. MySQL 备份脚本

配置文件:scripts/backup_mysql.sh

#!/bin/bash

set -e

BACKUP_DIR="/data/backup/mysql"
DATE=$(date +%F_%H-%M-%S)
CONTAINER_NAME="enterprise-mysql"
DB_NAME="enterprise"
DB_USER="root"
DB_PASSWORD="RootStrongPassword_2026"

mkdir -p ${BACKUP_DIR}

docker exec ${CONTAINER_NAME} mysqldump \
  -u${DB_USER} \
  -p${DB_PASSWORD} \
  --single-transaction \
  --routines \
  --triggers \
  ${DB_NAME} > ${BACKUP_DIR}/${DB_NAME}_${DATE}.sql

gzip ${BACKUP_DIR}/${DB_NAME}_${DATE}.sql

find ${BACKUP_DIR} -name "*.gz" -mtime +14 -delete

echo "Backup completed: ${BACKUP_DIR}/${DB_NAME}_${DATE}.sql.gz"

添加定时任务:

crontab -e
0 2 * * * /opt/enterprise/scripts/backup_mysql.sh >> /var/log/mysql_backup.log 2>&1

2. Redis 备份建议

如果 Redis 用于缓存,可以不做强一致备份;如果 Redis 承载业务状态,必须开启 AOF,并定期备份 /data 目录。

3. 配置文件备份

建议将以下内容纳入版本管理或配置备份:

docker-compose.yml
nginx/conf.d/
mysql/conf.d/
redis/redis.conf
prometheus/prometheus.yml
scripts/

但注意不要提交密码、证书私钥等敏感信息。


十八、常用运维命令

查看容器状态

docker ps
docker compose ps

查看日志

docker logs -f enterprise-app
docker compose logs -f app

重启服务

docker compose restart app

查看资源使用

docker stats

进入容器

docker exec -it enterprise-app sh

清理无用镜像

docker image prune -a

查看 Docker 磁盘占用

docker system df

清理停止容器、无用网络和构建缓存

docker system prune

生产环境执行清理命令前必须确认是否会删除仍需保留的镜像和缓存。


十九、目录结构推荐

企业项目建议采用统一目录结构,方便交付和维护。

/opt/enterprise/
├── docker-compose.yml
├── .env
├── app/
│   └── logs/
├── nginx/
│   ├── conf.d/
│   │   └── default.conf
│   ├── certs/
│   └── logs/
├── mysql/
│   ├── conf.d/
│   │   └── my.cnf
│   ├── init/
│   └── logs/
├── redis/
│   └── redis.conf
├── prometheus/
│   └── prometheus.yml
├── scripts/
│   └── backup_mysql.sh
└── releases/

这种结构具备以下优点:

  • 配置集中;
  • 日志清晰;
  • 便于备份;
  • 便于迁移;
  • 便于自动化脚本管理。

二十、企业级落地最佳实践清单

最后给出一份可执行的 Docker 企业级落地检查清单。

基础设施

  • [ ] Docker 安装版本统一;
  • [ ] Docker 数据目录放在独立磁盘;
  • [ ] 配置日志轮转;
  • [ ] 配置镜像加速或内部仓库;
  • [ ] 禁止生产直接使用 latest 标签;
  • [ ] 所有服务器开启时间同步。

镜像规范

  • [ ] 使用多阶段构建;
  • [ ] 镜像内不包含敏感信息;
  • [ ] 使用非 root 用户运行;
  • [ ] 镜像体积控制合理;
  • [ ] 镜像经过安全扫描;
  • [ ] 镜像 tag 与 Git Commit 或构建号关联。

部署规范

  • [ ] 使用 Docker Compose 或编排平台统一部署;
  • [ ] 容器配置 restart 策略;
  • [ ] 数据目录持久化;
  • [ ] 数据库和缓存不暴露公网;
  • [ ] 配置健康检查;
  • [ ] 配置资源限制;
  • [ ] 发布前有测试和审批流程。

安全规范

  • [ ] 禁止 privileged 容器;
  • [ ] 禁止挂载 Docker Socket;
  • [ ] 使用 HTTPS;
  • [ ] 密码不提交 Git;
  • [ ] 定期更新基础镜像;
  • [ ] 配置防火墙和访问控制。

运维规范

  • [ ] 接入日志平台;
  • [ ] 接入监控告警;
  • [ ] 定期备份数据库;
  • [ ] 定期演练恢复;
  • [ ] 发布支持回滚;
  • [ ] 建立故障处理流程。

总结

Docker 企业级实战并不是简单地编写一个 Dockerfile 或启动几个容器,而是要围绕“标准化交付、自动化部署、安全可控、稳定运行、可观测、可回滚”构建完整体系。

对于企业而言,推荐从以下路径逐步推进:

  1. 首先统一 Docker 安装和 daemon 配置;
  2. 制定镜像构建规范和 Dockerfile 模板;
  3. 引入 Harbor 作为私有镜像仓库;
  4. 使用 Docker Compose 管理测试和小规模生产环境;
  5. 接入 Jenkins 或 GitLab CI,实现自动构建和发布;
  6. 引入 Prometheus、Grafana、Loki 或 ELK,完善监控日志;
  7. 建立安全扫描、备份恢复、发布回滚机制;
  8. 当业务规模扩大后,再逐步迁移到 Kubernetes。

通过上述方案,企业可以显著提升应用交付效率,降低环境差异导致的问题,并为后续云原生架构演进打下坚实基础。

目录结构
全文