Docker 上服务器前必须知道的影响与配置清单

发布人：慈云数据-客服中心发布时间：7小时前阅读量：0

Docker 对服务器有什么影响｜附配置文件

在现代软件交付体系中，Docker 已经成为服务器部署、应用交付、环境隔离和 DevOps 自动化的重要基础设施。无论是个人开发者部署博客、企业上线微服务，还是运维团队管理测试环境与生产环境，Docker 都能显著提升效率。

不过，Docker 并不是“装上就万事大吉”的万能工具。它对服务器的 CPU、内存、磁盘、网络、安全、运维方式都会产生影响。合理使用 Docker 可以让服务器更稳定、更易维护；使用不当则可能导致资源被吃满、磁盘爆炸、安全风险增加，甚至影响宿主机正常运行。

本文将系统分析 Docker 对服务器的影响，并附上常用配置文件示例，帮助你更好地理解和落地 Docker 环境。

一、Docker 是什么？它在服务器中扮演什么角色？

Docker 是一种容器化技术，它可以将应用程序及其运行依赖打包到一个相对独立的环境中运行。这个环境被称为“容器”。

与传统部署方式相比，Docker 最大的特点是：

应用与依赖一起打包；
环境一致，减少“我本地能跑，服务器不能跑”的问题；
启动速度快；
资源占用比虚拟机更低；
便于自动化部署和弹性扩展。

在服务器上，Docker 通常扮演以下角色：

应用运行环境管理器
例如运行 Nginx、MySQL、Redis、Java、Node.js、Python 服务等。
环境隔离工具
不同应用可以使用不同版本的运行环境，互不干扰。
自动化部署基础设施
配合 Docker Compose、CI/CD，可以实现一键构建、一键发布。
微服务运行载体
每个服务一个容器，服务之间通过网络通信。
开发、测试、生产环境一致性保障工具
同一镜像可以在多台服务器或多个环境中运行。

二、Docker 对服务器 CPU 的影响

Docker 容器本身不是虚拟机，它不需要模拟完整操作系统，因此容器启动和运行的额外 CPU 开销通常较小。应用在容器中运行，本质上仍然是在宿主机 Linux 内核上运行进程。

1. 正常情况下 CPU 开销较低

如果你在服务器上用 Docker 运行 Nginx、Redis、Web 服务等，Docker 本身产生的 CPU 额外消耗通常很小。真正消耗 CPU 的，仍然是容器内部运行的应用。

例如：

Java 服务 CPU 高，主要是 JVM 或业务逻辑导致；
MySQL CPU 高，可能是慢查询、索引不足；
Node.js CPU 高，可能是计算密集任务或事件循环阻塞；
Nginx CPU 高，可能是连接数过多或日志过于频繁。

Docker 只是在资源隔离和进程管理层面增加了一层控制。

2. 容器过多可能增加调度成本

虽然单个容器开销不大，但如果服务器上运行大量容器，例如几十个、上百个容器，宿主机需要调度更多进程、网络命名空间、日志输出和文件系统层。这时整体 CPU 调度压力会增加。

尤其是以下场景：

每个容器都有后台守护进程；
日志输出非常频繁；
容器不断重启；
多个容器同时构建镜像；
容器内运行高并发服务。

这类情况下，Docker 对 CPU 的影响会明显上升。

3. 建议设置 CPU 限制

为了避免某个容器把服务器 CPU 打满，可以为容器设置 CPU 限制。

例如使用 docker run：

docker run -d \
  --name my-app \
  --cpus="1.5" \
  nginx:latest

表示该容器最多使用约 1.5 个 CPU 核心。

在 Docker Compose 中可以这样配置：

services:
  app:
    image: nginx:latest
    container_name: my-app
    cpus: 1.5

对于生产环境，建议对关键服务设置合理的 CPU 上限，防止单个异常服务拖垮整台服务器。

三、Docker 对服务器内存的影响

内存是 Docker 对服务器影响最明显的资源之一。容器本身很轻量，但容器内的应用并不会因为使用 Docker 而减少内存消耗。

1. 容器共享宿主机内核，但进程仍然占用内存

Docker 容器不像虚拟机那样每个都运行完整操作系统，因此系统级开销较少。但是容器中的应用进程需要多少内存，依旧取决于应用本身。

例如：

一个 Nginx 容器可能只占几十 MB；
一个 Redis 容器可能占用几百 MB 到数 GB；
一个 Java 容器可能占用 512MB、1GB 甚至更多；
一个 MySQL 容器可能占用数 GB 内存。

如果不加限制，容器可以使用宿主机上可用的全部内存。一旦某个容器发生内存泄漏，可能导致宿主机 OOM，进而影响其他服务。

2. OOM 风险

OOM 是 Out Of Memory 的缩写，即内存不足。当服务器内存耗尽时，Linux 内核会触发 OOM Killer，强制杀掉部分进程。

如果 Docker 容器没有限制内存，可能出现以下问题：

容器内应用占用过多内存；
宿主机服务被误杀；
Docker daemon 异常；
SSH 登录缓慢甚至失败；
服务器整体不可用。

因此，在生产环境中，不建议让所有容器无限制使用内存。

3. 建议设置内存限制

使用 docker run 设置内存限制：

docker run -d \
  --name my-app \
  --memory=512m \
  --memory-swap=1g \
  nginx:latest

含义：

--memory=512m：限制容器最多使用 512MB 内存；
--memory-swap=1g：内存加 swap 总量最多 1GB。

Docker Compose 示例：

services:
  app:
    image: nginx:latest
    container_name: my-app
    mem_limit: 512m
    memswap_limit: 1g

对于 Java 应用，还应结合 JVM 参数控制堆内存，例如：

JAVA_OPTS="-Xms512m -Xmx512m"

否则容器限制和 JVM 内存策略不匹配，也可能导致应用异常退出。

四、Docker 对服务器磁盘的影响

磁盘是使用 Docker 时最容易被忽视的问题。很多服务器 Docker 用着用着突然磁盘满了，最终发现是镜像、容器日志、构建缓存和数据卷占用了大量空间。

1. Docker 会占用哪些磁盘空间？

Docker 主要会占用以下几类磁盘空间：

类型	说明
镜像 Images	拉取的基础镜像和业务镜像
容器 Containers	容器运行时产生的可写层
数据卷 Volumes	持久化存储，例如数据库数据
日志 Logs	容器标准输出日志
构建缓存 Build Cache	构建镜像时产生的缓存层

默认情况下，Docker 数据目录通常位于：

/var/lib/docker

可以通过以下命令查看 Docker 磁盘占用：

docker system df

查看详细信息：

docker system df -v

2. 容器日志可能快速撑满磁盘

Docker 默认使用 json-file 日志驱动，如果应用持续向标准输出打印大量日志，日志文件会不断增长。

容器日志路径一般类似：

/var/lib/docker/containers//-json.log

如果没有配置日志轮转，一个高频日志容器可能在几天内写满几十 GB 磁盘。

3. 配置 Docker 日志轮转

建议在 Docker daemon 配置文件中设置日志限制。

配置文件路径：

/etc/docker/daemon.json

示例配置：

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m",
    "max-file": "3"
  }
}

含义：

单个日志文件最大 100MB；
最多保留 3 个日志文件；
单个容器最多约占 300MB 日志空间。

修改后重启 Docker：

sudo systemctl daemon-reload
sudo systemctl restart docker

注意：此配置通常只对新创建的容器生效，已有容器可能需要重建。

4. 清理无用 Docker 资源

清理停止的容器、未使用镜像、无用网络和构建缓存：

docker system prune

如果要连未使用的数据卷也清理：

docker system prune -a --volumes

但要注意，--volumes 可能删除数据库等持久化数据，生产环境务必谨慎。

建议先查看卷：

docker volume ls

查看具体卷信息：

docker volume inspect volume_name

五、Docker 对服务器网络的影响

Docker 会在服务器上创建虚拟网络，用于容器之间通信，以及容器与外部网络通信。

1. Docker 默认网络

安装 Docker 后，通常会出现一个 docker0 网桥。容器默认连接到 bridge 网络，通过 NAT 访问外部网络。

查看网络：

docker network ls

常见网络类型包括：

网络类型	说明
bridge	默认桥接网络，适合单机容器通信
host	容器直接使用宿主机网络
none	不配置网络
overlay	多主机容器网络，常用于 Swarm
macvlan	容器拥有类似物理网络中的独立 IP

2. 端口映射会影响服务器端口管理

使用 Docker 部署服务时，经常需要端口映射：

docker run -d \
  -p 8080:80 \
  nginx:latest

表示将宿主机 8080 端口映射到容器 80 端口。

如果端口管理混乱，可能出现：

端口冲突；
服务暴露到公网；
防火墙规则失效；
容器服务被误访问；
安全风险增加。

因此，生产环境中应明确规划端口，避免随意暴露数据库、缓存等敏感服务。

3. 不建议将数据库端口直接暴露公网

例如 MySQL、Redis、MongoDB 等服务，如果直接使用：

ports:
  - "6379:6379"

并且服务器安全组开放了 6379，就可能导致 Redis 暴露到公网，引发严重安全风险。

更推荐的方式是只在 Docker 内部网络通信：

services:
  redis:
    image: redis:7
    networks:
      - app-net

  app:
    image: my-app:latest
    networks:
      - app-net

networks:
  app-net:
    driver: bridge

这样应用容器可以通过服务名 redis 访问 Redis，而无需将 Redis 端口暴露到公网。

六、Docker 对服务器安全的影响

Docker 带来了便利，也引入了新的安全边界问题。容器不是虚拟机，容器共享宿主机内核，因此不能把容器隔离能力理解为绝对安全。

1. 镜像安全风险

很多人直接从公共镜像仓库拉取镜像，例如：

docker pull nginx
docker pull mysql

官方镜像通常比较可靠，但一些第三方镜像可能存在：

后门程序；
过期依赖；
漏洞组件；
恶意脚本；
暴露敏感信息。

建议：

优先使用官方镜像；
固定镜像版本，不要总是使用 latest；
定期扫描镜像漏洞；
自建镜像时减少不必要依赖；
不要把密码、密钥写进镜像。

2. 容器权限过高的风险

如果容器以特权模式运行：

docker run --privileged ...

容器将获得非常高的宿主机权限。一旦容器被攻破，攻击者可能进一步影响宿主机。

除非确有必要，例如运行某些底层系统服务，否则生产环境应避免使用 --privileged。

3. 避免挂载敏感宿主机目录

下面这些挂载方式非常危险：

-v /:/host
-v /var/run/docker.sock:/var/run/docker.sock

尤其是挂载 Docker socket：

/var/run/docker.sock

如果容器内进程可以访问 Docker socket，它几乎等同于拥有宿主机 Docker 管理权限，可以创建特权容器、挂载宿主机目录，从而造成严重安全问题。

4. 使用非 root 用户运行容器

Docker 容器默认很多是 root 用户运行。建议在 Dockerfile 中指定普通用户。

示例 Dockerfile：

FROM node:20-alpine

WORKDIR /app

COPY package*.json ./
RUN npm install --production

COPY . .

RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser

EXPOSE 3000

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

这样即使应用被攻击，攻击者获得的权限也会受到一定限制。

七、Docker 对服务器运维方式的影响

Docker 改变的不只是运行方式，还改变了运维思路。

1. 从“进服务器改配置”变成“改镜像和配置文件”

传统部署中，运维人员可能直接登录服务器修改文件、安装依赖、重启服务。时间久了，服务器环境会变得难以复现。

Docker 更推荐：

用 Dockerfile 描述镜像；
用 Compose 文件描述服务；
用环境变量管理配置；
用版本控制管理部署文件；
用 CI/CD 自动构建与发布。

这样可以减少人工操作，提高可追溯性。

2. 应用迁移更方便

有了 Docker 后，迁移服务器通常只需：

安装 Docker；
拷贝配置文件；
拷贝数据卷或数据库备份；
执行 docker compose up -d。

相比传统部署，迁移成本大幅降低。

3. 回滚更简单

如果新版本应用有问题，可以直接切回旧镜像版本：

services:
  app:
    image: my-app:1.0.3

更新为：

services:
  app:
    image: my-app:1.0.2

然后执行：

docker compose up -d

即可回滚。

八、Docker 对服务器性能的影响

Docker 的性能损耗通常低于虚拟机，但仍然存在一些需要注意的地方。

1. CPU 性能损耗较小

容器使用宿主机内核，CPU 执行效率接近原生进程。对于大多数 Web 服务、API 服务、后台任务来说，Docker 带来的 CPU 性能损耗可以忽略。

2. 磁盘 I/O 可能受影响

Docker 镜像采用分层文件系统，例如 overlay2。在频繁写入大量小文件的场景下，容器可写层可能带来额外开销。

例如：

数据库；
日志系统；
文件上传服务；
高频缓存写入。

对于这类服务，建议使用 volume 或 bind mount 持久化数据，而不是直接写入容器可写层。

示例：

services:
  mysql:
    image: mysql:8.0
    volumes:
      - mysql-data:/var/lib/mysql

volumes:
  mysql-data:

这样数据库数据会写入 Docker volume，性能和可靠性更好。

3. 网络性能通常可接受

默认 bridge 网络会经过 NAT，理论上有一定性能损耗。但对绝大多数业务系统来说，这种损耗很小。

如果对网络性能要求极高，可以考虑：

使用 host 网络模式；
优化内核网络参数；
减少不必要的代理层；
使用更合适的网络插件。

host 网络示例：

docker run -d \
  --network host \
  nginx:latest

但 host 模式会降低网络隔离性，端口也直接使用宿主机端口，需要谨慎使用。

九、推荐的 Docker daemon 配置文件

下面是一个较适合普通服务器使用的 /etc/docker/daemon.json 示例。

{
  "data-root": "/var/lib/docker",
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m",
    "max-file": "3"
  },
  "storage-driver": "overlay2",
  "exec-opts": ["native.cgroupdriver=systemd"],
  "live-restore": true,
  "icc": true,
  "userland-proxy": false,
  "default-address-pools": [
    {
      "base": "172.30.0.0/16",
      "size": 24
    }
  ]
}

配置说明

配置项	作用
data-root	Docker 数据存储目录
log-driver	日志驱动
max-size	单个日志文件最大大小
max-file	日志文件保留数量
storage-driver	存储驱动，常用 overlay2
cgroupdriver	使用 systemd 管理 cgroup
live-restore	Docker daemon 重启时尽量保持容器运行
userland-proxy	关闭用户态代理，减少部分端口转发开销
default-address-pools	设置默认 Docker 网络地址池，避免与内网冲突

修改配置后执行：

sudo systemctl daemon-reload
sudo systemctl restart docker

验证配置：

docker info

十、推荐的 Docker Compose 配置文件

下面是一个较完整的 Web 应用部署示例，包含 Nginx、应用服务、MySQL、Redis，并且对资源、日志、网络和数据卷做了基本配置。

version: "3.9"

services:
  nginx:
    image: nginx:1.25-alpine
    container_name: demo-nginx
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx/conf.d:/etc/nginx/conf.d:ro
      - ./nginx/certs:/etc/nginx/certs:ro
      - ./logs/nginx:/var/log/nginx
    depends_on:
      - app
    networks:
      - frontend
    mem_limit: 256m
    cpus: 0.5
    logging:
      driver: json-file
      options:
        max-size: "50m"
        max-file: "3"

  app:
    image: demo-app:1.0.0
    container_name: demo-app
    restart: unless-stopped
    environment:
      APP_ENV: production
      APP_PORT: 3000
      DB_HOST: mysql
      DB_PORT: 3306
      DB_NAME: demo
      DB_USER: demo_user
      DB_PASSWORD: "change_this_password"
      REDIS_HOST: redis
      REDIS_PORT: 6379
    expose:
      - "3000"
    depends_on:
      - mysql
      - redis
    networks:
      - frontend
      - backend
    mem_limit: 1024m
    memswap_limit: 1024m
    cpus: 1.5
    logging:
      driver: json-file
      options:
        max-size: "100m"
        max-file: "3"

  mysql:
    image: mysql:8.0
    container_name: demo-mysql
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: "change_root_password"
      MYSQL_DATABASE: demo
      MYSQL_USER: demo_user
      MYSQL_PASSWORD: "change_this_password"
      TZ: Asia/Shanghai
    volumes:
      - mysql-data:/var/lib/mysql
      - ./mysql/conf.d:/etc/mysql/conf.d:ro
      - ./backup/mysql:/backup
    networks:
      - backend
    expose:
      - "3306"
    mem_limit: 2048m
    cpus: 2
    command:
      --default-authentication-plugin=mysql_native_password
      --character-set-server=utf8mb4
      --collation-server=utf8mb4_unicode_ci
    logging:
      driver: json-file
      options:
        max-size: "100m"
        max-file: "5"

  redis:
    image: redis:7-alpine
    container_name: demo-redis
    restart: unless-stopped
    command: redis-server /usr/local/etc/redis/redis.conf
    volumes:
      - redis-data:/data
      - ./redis/redis.conf:/usr/local/etc/redis/redis.conf:ro
    networks:
      - backend
    expose:
      - "6379"
    mem_limit: 512m
    cpus: 0.5
    logging:
      driver: json-file
      options:
        max-size: "50m"
        max-file: "3"

networks:
  frontend:
    driver: bridge
  backend:
    driver: bridge
    internal: true

volumes:
  mysql-data:
  redis-data:

这个 Compose 文件有几个关键点：

Nginx 只连接前端网络；
MySQL 和 Redis 不暴露公网端口；
后端网络设置为 internal: true，减少外部访问风险；
每个服务配置日志大小限制；
为主要服务设置 CPU 和内存限制；
数据库和 Redis 使用 volume 持久化数据；
镜像版本固定，避免使用不确定的 latest。

十一、Nginx 配置文件示例

假设应用容器服务名为 app，端口为 3000，可以使用如下 Nginx 配置。

文件路径：

./nginx/conf.d/app.conf

配置内容：

server {
    listen 80;
    server_name example.com;

    client_max_body_size 20m;

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

    location / {
        proxy_pass http://app:3000;
        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_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

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

如果使用 HTTPS，可进一步配置证书路径和 443 监听。

十二、Redis 配置文件示例

文件路径：

./redis/redis.conf

示例内容：

bind 0.0.0.0
port 6379

protected-mode yes

appendonly yes
appendfsync everysec

maxmemory 384mb
maxmemory-policy allkeys-lru

timeout 300
tcp-keepalive 60

dir /data

说明：

appendonly yes 开启 AOF 持久化；
maxmemory 限制 Redis 使用内存；
allkeys-lru 表示内存不足时淘汰最近最少使用的 key；
Redis 不对公网开放，只在 Docker 后端网络中使用。

十三、MySQL 配置文件示例

文件路径：

./mysql/conf.d/my.cnf

示例内容：

[mysqld]
default-time-zone = '+08:00'

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

max_connections = 300
table_open_cache = 2000

innodb_buffer_pool_size = 1G
innodb_log_file_size = 256M
innodb_flush_log_at_trx_commit = 1

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

skip-name-resolve

说明：

innodb_buffer_pool_size 应根据服务器内存合理设置；
slow_query_log 用于分析慢 SQL；
skip-name-resolve 可减少 DNS 解析带来的连接延迟；
不建议把 MySQL 端口直接暴露到公网。

十四、Docker 使用中的常见问题

1. Docker 会不会拖慢服务器？

一般不会。Docker 的额外性能损耗较低，真正拖慢服务器的通常是容器内应用、数据库、日志、磁盘 I/O 或资源限制不合理。

2. Docker 会不会让服务器更不安全？

Docker 本身不是不安全，但错误使用会增加风险。例如：

使用不可信镜像；
容器使用特权模式；
暴露数据库端口；
挂载 Docker socket；
密码写入镜像；
不做日志和资源限制。

只要遵循安全规范，Docker 可以成为较安全、可控的部署方式。

3. Docker 适合部署数据库吗？

可以，但需要谨慎。数据库容器化适合中小型业务、测试环境、内部系统等场景。生产核心数据库要重点关注：

数据持久化；
备份恢复；
磁盘性能；
内存配置；
监控告警；
版本升级；
容器重启策略。

4. 是否所有服务都应该放进 Docker？

不一定。Docker 适合大多数应用服务，但并非所有场景都必须容器化。例如底层网络组件、特殊硬件驱动、高性能存储服务等，可能更适合直接运行在宿主机。

十五、服务器使用 Docker 的最佳实践

综合来看，建议遵循以下原则：

镜像版本固定，不滥用 latest
例如使用 nginx:1.25-alpine，而不是 nginx:latest。
容器资源要有限制
给关键服务配置 CPU 和内存上限，避免异常容器拖垮服务器。
日志必须设置轮转
防止容器日志持续增长导致磁盘写满。
数据库和缓存不要直接暴露公网
使用 Docker 内部网络通信。
数据必须持久化
数据库、上传文件、缓存数据应使用 volume 或宿主机目录挂载。
配置文件纳入版本管理
Dockerfile、Compose 文件、Nginx 配置等都应进入 Git 管理。
定期清理无用资源
清理无用镜像、停止容器和构建缓存。
做好监控和告警
监控 CPU、内存、磁盘、网络、容器状态和日志。
避免使用高危权限
不随意使用 --privileged，不随意挂载宿主机敏感目录。
定期备份数据
Docker 方便重建服务，但不能替代数据备份。

十六、总结

Docker 对服务器的影响是多方面的。

从积极角度看，Docker 可以提升部署效率、统一运行环境、降低迁移成本、增强服务隔离、简化回滚流程，并且非常适合现代 DevOps 和微服务架构。

从风险角度看，Docker 会带来资源管理、磁盘日志、安全隔离、网络暴露、数据持久化等问题。如果不设置资源限制、不控制日志、不规划网络、不备份数据，Docker 也可能成为服务器故障的来源。

因此，Docker 对服务器不是简单的“好”或“坏”，关键在于是否合理配置和规范使用。对于大多数 Web 应用、后台服务、中小型系统来说，Docker 是非常值得使用的部署方案。但在生产环境中，应把 Docker 当作基础设施认真管理，而不是只把它当成一个方便启动应用的命令工具。

一套可靠的 Docker 服务器环境，至少应该具备：

合理的 daemon 配置；
完整的 Compose 编排文件；
明确的网络隔离；
必要的资源限制；
日志轮转策略；
数据持久化方案；
备份与恢复机制；
监控与告警体系；
安全权限控制。

只有这样，Docker 才能真正帮助服务器变得更高效、更稳定、更容易维护。

文章标签： Docker 服务器资源管理容器安全配置优化

上一篇：Docker 上服务器后会占多少资源？一文讲透性能影响与部署源码

下一篇：Docker 会让服务器变快吗？新手必须搞懂的影响与坑

更多栏目

新闻动态

文档中心

下载中心

目录结构

全文

产品与服务

新闻帮助

生态合作

了解我们

Docker 上服务器前必须知道的影响与配置清单

Docker 对服务器有什么影响｜附配置文件

一、Docker 是什么？它在服务器中扮演什么角色？

二、Docker 对服务器 CPU 的影响

1. 正常情况下 CPU 开销较低

2. 容器过多可能增加调度成本

3. 建议设置 CPU 限制

三、Docker 对服务器内存的影响

1. 容器共享宿主机内核，但进程仍然占用内存

2. OOM 风险

3. 建议设置内存限制

四、Docker 对服务器磁盘的影响

1. Docker 会占用哪些磁盘空间？

2. 容器日志可能快速撑满磁盘

3. 配置 Docker 日志轮转

4. 清理无用 Docker 资源

五、Docker 对服务器网络的影响

1. Docker 默认网络

2. 端口映射会影响服务器端口管理

3. 不建议将数据库端口直接暴露公网

六、Docker 对服务器安全的影响

1. 镜像安全风险

2. 容器权限过高的风险

3. 避免挂载敏感宿主机目录

4. 使用非 root 用户运行容器

七、Docker 对服务器运维方式的影响

1. 从“进服务器改配置”变成“改镜像和配置文件”

2. 应用迁移更方便

3. 回滚更简单

八、Docker 对服务器性能的影响

1. CPU 性能损耗较小

2. 磁盘 I/O 可能受影响

3. 网络性能通常可接受

九、推荐的 Docker daemon 配置文件

配置说明

十、推荐的 Docker Compose 配置文件

十一、Nginx 配置文件示例

十二、Redis 配置文件示例

十三、MySQL 配置文件示例

十四、Docker 使用中的常见问题

1. Docker 会不会拖慢服务器？

2. Docker 会不会让服务器更不安全？

3. Docker 适合部署数据库吗？

4. 是否所有服务都应该放进 Docker？

十五、服务器使用 Docker 的最佳实践

十六、总结