Docker on 纪伟的个人博客

Docker 学习笔记（五）：生产实践与安全

Fri, 30 Jan 2026 10:00:00 +0800

写在前面

本文是 Docker 系列收官篇。前面的内容让容器"能跑"，这篇讲让容器"在生产环境跑得稳、跑得安全"：日志、监控、健康检查、资源限制、优雅关闭、安全加固，以及 Docker vs K8s 的选择。

一、生产环境清单

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


一个生产级容器应用应该有：
 ✓ 健康检查（让编排器知道是否健康）
 ✓ 资源限制（防止单容器吃光资源）
 ✓ 日志方案（收集、聚合）
 ✓ 监控（指标、告警）
 ✓ 重启策略（崩溃自动恢复）
 ✓ 优雅关闭（处理完请求再停）
 ✓ 非 root 用户
 ✓ 镜像扫描（无漏洞）
 ✓ 密钥管理（密钥不进镜像）

二、健康检查

1
2
3


# Dockerfile 里定义健康检查
HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
 CMD curl -f http://localhost:8080/health || exit 1

1
2
3
4
5
6
7
8
9


# docker-compose.yml
services:
 app:
 healthcheck:
 test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
 interval: 30s
 timeout: 3s
 retries: 3
 start_period: 10s  # 启动宽限期

1
2
3
4
5


状态：starting → healthy → unhealthy
 健康检查失败 → unhealthy
 编排器（Docker Swarm / K8s）根据状态决定是否重启/摘流量

 应用要提供 /health 端点（检查自身 + 依赖）

三、资源限制

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# docker-compose.yml
services:
 app:
 deploy:
 resources:
 limits:
 cpus: "1.5" # 最多 1.5 核
 memory: 512M  # 最多 512M 内存
 reservations: # 保底
 cpus: "0.5"
 memory: 128M

1
2
3
4
5


# docker run 限制
docker run --cpus="1.5" --memory="512m" --memory-swap="1g" myapp

# OOM：容器内存超限会被内核 OOM Kill（重启）
# CPU 限流：超 cpu 配额会被节流（慢，但不杀）

1
2
3
4


为什么要限制：
 不限制 → 一个容器内存泄漏/死循环，吃光宿主机
 → 影响其他容器（"吵闹的邻居"）
 限制 → 隔离资源，单容器故障不扩散

四、重启策略

1
2
3
4
5


docker run --restart=no # 不重启（默认）
docker run --restart=on-failure # 非正常退出才重启
docker run --restart=on-failure:5 # 最多重启 5 次
docker run --restart=always # 总是重启（包括手动 stop？stop 例外）
docker run --restart=unless-stopped # 总是重启，除非手动停止（推荐）

1
2
3
4


unless-stopped 最常用：
 崩溃 → 自动重启
 手动 stop → 不重启
 宿主机重启 → 容器跟着起来

五、优雅关闭

容器收到停止信号（SIGTERM），应处理完当前请求再退出：

1
2


# 应用要监听 SIGTERM
# .NET/Java/Go 等运行时会处理，但要正确配置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


docker stop 默认：
 1. 发 SIGTERM
 2. 等待 10 秒（grace period）
 3. 没退出就 SIGKILL（强杀，可能丢数据）

docker stop -t 30 web # 等 30 秒

应用要做：
 ✓ 监听 SIGTERM
 ✓ 停止接收新请求
 ✓ 处理完已有请求
 ✓ 释放资源（关闭连接、刷盘）
 ✓ 退出

 否则：强杀 → 请求中断、数据丢失

六、日志管理

1
2
3
4
5
6
7


Docker 日志两种：
 1. 容器 stdout/stderr（应用日志）
 docker logs web
 日志驱动（logging driver）决定怎么处理

 2. 容器内文件日志
 要挂载出来或用 agent 收集

1
2
3
4
5
6
7
8


# 配置日志驱动 + 日志轮转（防日志撑爆磁盘）
services:
 app:
 logging:
 driver: json-file
 options:
 max-size: "10m" # 单文件最大 10M
 max-file: "3" # 保留 3 个

1
2
3
4
5
6
7
8


日志驱动：
 json-file（默认）— 存文件
 fluentd / syslog / journald — 转发到日志系统
 none — 不存

生产方案：
 应用日志输出到 stdout → Docker 收集 → 转发到 ELK/Loki
 （容器十二要素应用原则：日志当事件流，输出到 stdout）

七、监控

1
2
3


# 内置：实时资源占用
docker stats
# CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


生产监控栈：
 cAdvisor — 采集容器指标（CPU/内存/网络/磁盘）
 Prometheus — 存储时序指标
 Grafana — 可视化看板
 Node Exporter — 宿主机指标

 应用内部指标 → Prometheus client 暴露 /metrics
 容器指标 → cAdvisor
 日志 → ELK/Loki
 告警 → Alertmanager

八、安全加固

8.1 最小权限

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


services:
 app:
 user: "1000:1000" # 非 root 运行
 read_only: true # 根文件系统只读
 tmpfs:
 - /tmp  # 需要写的目录用 tmpfs
 cap_drop:
 - ALL  # 丢弃所有 Linux capabilities
 cap_add:
 - NET_BIND_SERVICE  # 只加需要的
 security_opt:
 - no-new-privileges  # 禁止提权

8.2 镜像安全

1
2
3
4
5
6


✓ 用可信基础镜像（官方、固定版本 tag）
✓ 镜像扫描：docker scout / trivy / clair
 扫描已知漏洞（CVE）
✓ 用 distroless/scratch（减小攻击面）
✓ 多阶段构建（不带源码/构建工具）
✓ 不用 root

8.3 密钥管理

1
2
3
4
5
6
7


❌ 密钥写进镜像 / 环境变量明文（会泄露）
✓ Docker Secret（Swarm）/ K8s Secret
✓ 挂载文件（只读，不进镜像、不进 env）
✓ 外部密钥管理（Vault、云 KMS）

 环境变量也不安全（inspect 能看到、子进程能读）
 生产用 Secret 文件挂载或外部 KMS

8.4 更强的隔离

1
2
3
4
5
6
7


默认容器共享宿主机内核 → 内核漏洞可能逃逸
更强隔离方案：
 gVisor — 用户态内核，拦截系统调用（Google）
 Kata Containers — 轻量虚拟机跑容器（VM 级隔离）
 Firecracker — 微 VM（AWS，极快启动）

 多租户、高安全场景用这些替代默认 runc

九、Docker vs Kubernetes

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


Docker / Docker Compose：
 ✓ 单机
 ✓ 简单、上手快
 ✓ 本地开发、CI、小项目
 ✗ 不能跨机器、故障自愈弱、无滚动更新

Kubernetes：
 ✓ 多机集群、自动调度
 ✓ 自愈（容器挂了自动重启/迁移）
 ✓ 滚动更新、回滚
 ✓ 服务发现、负载均衡、扩缩容
 ✓ 配置/密钥管理
 ✗ 复杂、运维成本高

选择：
 单机 / 小项目 / 本地 → Docker Compose
 多机 / 生产 / 微服务 → Kubernetes
 中间过渡 → Docker Swarm（简单，但已式微）

 生产正规军：Docker 打镜像 → K8s 编排运行
 （Docker 是构建/打包工具，K8s 是运行/编排平台）

十、CI/CD 集成

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


典型流程（结合本站 GitHub Actions 自动部署文章）：

 开发者 push 代码
 → GitHub Actions 触发
 → docker build 构建镜像
 → docker push 到镜像仓库
 → 服务器 docker pull + docker compose up -d
 （或 K8s kubectl apply）

 Docker 让"构建一次，到处运行"成为可能
 是 CI/CD 流水线的核心组件

十一、小结

生产清单：健康检查、资源限制、重启策略、日志、监控、优雅关闭、安全
健康检查：HEALTHCHECK + /health 端点
资源限制：limits/reservations，防止"吵闹邻居"
优雅关闭：监听 SIGTERM，处理完请求再退出
日志：输出 stdout，日志驱动转发，轮转防爆盘
监控：cAdvisor + Prometheus + Grafana
安全：非 root、只读根、cap_drop、镜像扫描、密钥管理、gVisor
Docker vs K8s：Docker 打包构建，K8s 编排运行

系列总结

Docker 五篇完结：

基础与原理：容器 vs 虚拟机、namespace/cgroups/UnionFS
Dockerfile：多阶段构建、镜像瘦身、安全
Compose：多服务编排、服务发现、依赖管理
网络与存储：bridge 自定义网络、Volume/Bind/tmpfs、无状态原则
生产实践：健康检查、资源限制、日志监控、安全加固、Docker vs K8s

核心心法：容器让应用与运行环境解耦——一次构建，到处运行。Docker 负责打包和单机，K8s 负责多机编排。理解容器的隔离（namespace）、限制（cgroups）、分层（UnionFS），就理解了云原生的根基。

Docker 学习笔记（四）：网络与存储

Thu, 29 Jan 2026 10:00:00 +0800

写在前面

容器是隔离的——隔离进程、文件系统、网络。但应用需要对外通信（网络）和保存数据（存储）。本文讲 Docker 的网络模型和存储机制，这是把容器用到生产的关键。

一、Docker 网络模型

1.1 四种网络模式

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


bridge（默认）— 桥接
 容器连到虚拟网桥 docker0，通过 NAT 访问外部
 容器间用端口映射对外
 最常用

host — 主机网络
 容器直接用宿主机网络栈（无隔离）
 性能最好，但端口冲突
 适合对网络性能极致要求的场景

none — 无网络
 完全隔离，只有 lo 回环
 用于不需要网络的计算任务

container:xxx — 共享容器网络
 新容器和某已有容器共享网络栈
 少用

 macvlan — 容器有独立 MAC/IP，像物理机（进阶）
 overlay — 跨主机容器网络（Docker Swarm / K8s 用）

1.2 bridge 网络详解

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


默认 bridge（docker0）：
 所有容器默认连这
 ✗ 容器间只能用 IP 互访（没有 DNS 名字解析）
 ✗ 旧，不推荐生产

自定义 bridge（推荐）：
 docker network create mynet
 ✓ 自带 DNS，容器间用「容器名」互访
 ✓ 更好的隔离
 ✓ 可配置子网、网关

 → 生产/开发都该用自定义网络，不用默认 bridge

1
2
3
4
5
6
7
8


# 创建网络
docker network create mynet

# 容器加入网络
docker run -d --name web --network mynet nginx
docker run -d --name app --network mynet myapp

# app 容器里：curl http://web ← 用容器名访问（DNS 自动解析）

1.3 端口映射

1
2
3
4
5
6
7
8


# 端口映射（宿主机:容器）
docker run -p 8080:80 nginx # 宿主机 8080 → 容器 80
docker run -p 127.0.0.1:8080:80 nginx # 只绑本地回环
docker run -p 8080:80 -p 8443:443 nginx # 多端口
docker run -P nginx # 随机映射宿主机高端口

# 查看端口映射
docker port web

二、跨主机网络（Overlay）

1
2
3
4
5
6
7
8
9


单机：bridge 够用
多机：容器跨机器通信需要 overlay 网络

 overlay 网络在多台机器间建虚拟二层网络
 容器像在同一局域网
 依赖：键值存储（etcd/consul）或 Docker Swarm

 实际多机方案多用 K8s（自己的网络模型 CNI：Calico/Flannel/Cilium）
 纯 Docker 多机用 Swarm（已式微）

三、Docker 存储

容器删除后，容器内的数据消失。要持久化，三种方式：

3.1 Volume（卷，推荐）

1
2
3
4
5
6


# 命名卷（Docker 管理）
docker volume create mydata
docker run -v mydata:/var/lib/mysql mysql

# 匿名卷
docker run -v /var/lib/mysql mysql

1
2
3
4
5
6
7
8


Volume：
 Docker 管理的存储（Linux 下 /var/lib/docker/volumes/）
 ✓ 跨容器共享
 ✓ 生命周期独立于容器（容器删了卷还在）
 ✓ 性能好（绕过联合文件系统）
 ✓ 支持 volume driver（NFS、云盘等）

 → 数据库数据、应用状态等持久化数据，首选 Volume

3.2 Bind Mount（绑定挂载）

1
2
3
4


# 宿主机目录/文件挂到容器
docker run -v /host/path:/container/path nginx
docker run -v /host/conf:/etc/nginx/conf.d:ro nginx # 只读
docker run --mount type=bind,source=/host,target=/container nginx # 新语法

1
2
3
4
5
6
7
8


Bind Mount：
 直接映射宿主机路径
 ✓ 开发时挂源码（改了立即生效，热重载）
 ✓ 挂配置文件
 ✗ 依赖宿主机路径（移植性差）
 ✗ 容器能改宿主机文件（小心）

 → 本地开发挂代码、挂配置，用 Bind Mount

3.3 tmpfs（内存挂载）

1
2
3


# 数据存在内存，不落盘
docker run --tmpfs /cache nginx
docker run --mount type=tmpfs,target=/cache,tmpfs-size=100m nginx

1
2
3
4
5
6
7


tmpfs：
 数据在内存，容器停了就没
 ✓ 极快
 ✓ 适合临时/敏感数据（不想落盘）
 ✗ 不持久

 → 临时缓存、密钥文件，用 tmpfs

四、三种存储对比

1
2
3
4
5
6
7


 Volume Bind Mount tmpfs
──────────────────────────────────────────────────────────────
位置 Docker 管理 宿主机路径 内存
移植性 好 差 好
持久化 是 是 否
管理命令 docker volume 文件系统 无
适合 持久数据（DB） 开发挂载/配置 临时数据

五、Volume 实战

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


# 创建/列出/删除
docker volume create pgdata
docker volume ls
docker volume rm pgdata

# 查看卷详情
docker volume inspect pgdata

# 备份卷
docker run --rm -v pgdata:/data -v $(pwd):/backup alpine \
 tar czf /backup/pgdata.tar.gz -C /data .

# 恢复卷
docker run --rm -v pgdata:/data -v $(pwd):/backup alpine \
 tar xzf /backup/pgdata.tar.gz -C /data

# 多容器共享卷
docker run -d --name app1 -v sharedata:/data myapp
docker run -d --name app2 -v sharedata:/data myapp # 共享同一卷

六、数据共享模式

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


1. 容器间共享：多个容器挂同一个命名卷
 docker run -v sharevol:/data ...
 docker run -v sharevol:/data ...

2. 只读配置共享：宿主机配置挂成只读
 docker run -v /host/nginx.conf:/etc/nginx/nginx.conf:ro nginx

3. 数据容器模式（旧，已少用）：专门一个容器持有卷，其他 --volumes-from

4. 开发热重载：源码 bind mount，代码改了容器内即时生效
 docker run -v $(pwd)/src:/app/src myapp

七、生产实践

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


网络：
 ✓ 用自定义 bridge，不用默认 docker0
 ✓ 服务名做 DNS 互访
 ✓ 对外端口收敛（只暴露必要端口）
 ✓ 生产用反向代理（Nginx）收口

存储：
 ✓ 数据库数据用命名 Volume（独立于容器）
 ✓ 配置用 Bind Mount（方便修改）
 ✓ 敏感文件用 tmpfs 或 Docker Secret
 ✓ 定期备份重要 Volume
 ✓ 不要把数据存在容器内（容器是无状态的，随时可删）

容器无状态原则：
 应用代码 → 进镜像
 配置 → 环境变量 / 挂载
 数据 → Volume（容器外）
 → 容器本身随时可删可重建，数据不丢

八、小结

网络模式：bridge（默认，用自定义）、host（高性能）、none、overlay（跨机）
自定义 bridge：自带 DNS，容器间用服务名互访（推荐）
端口映射：-p 宿主机:容器
存储三种：
- Volume（Docker 管理，持久数据首选）
- Bind Mount（宿主机路径，开发/配置）
- tmpfs（内存，临时数据）
无状态原则：数据放 Volume，容器随时可删可重建

下一篇讲 Docker 生产实践与安全。

Docker 学习笔记（三）：Docker Compose 多服务编排

Wed, 28 Jan 2026 10:00:00 +0800

写在前面

一个应用往往不止一个容器（Web + 数据库 + 缓存 + 反向代理）。docker run 一个个敲很痛苦。Docker Compose 用一个 YAML 文件定义和运行多容器应用——本地开发、测试环境、CI 的利器。

一、什么是 Docker Compose

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


Docker Compose = 多容器编排工具
 用一个 docker-compose.yml 描述所有服务
 一条命令启动/停止整个应用栈

 docker compose up -d # 一键启动所有服务
 docker compose down # 一键停止并清理

适合：
 ✓ 本地开发环境（一键拉起 Web+DB+Redis）
 ✓ CI/CD 流水线
 ✓ 测试环境
 ✓ 单机部署（小型项目）

不适合：
 ✗ 大规模生产（那是 K8s 的事）
 ✗ 跨机器部署（单机工具）

二、docker-compose.yml 结构

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40


version: "3.8" # compose 文件版本（新版可省略）

services: # 定义所有服务
 web:
 image: nginx:1.25
 ports:
 - "8080:80"
 volumes:
 - ./html:/usr/share/nginx/html
 depends_on:
 - app

 app:
 build: ./myapp  # 从 Dockerfile 构建
 environment:
 - DB_HOST=db
 - REDIS_HOST=redis
 depends_on:
 db:
 condition: service_healthy
 redis:
 condition: service_started

 db:
 image: postgres:16
 environment:
 POSTGRES_PASSWORD: secret
 POSTGRES_DB: myapp
 volumes:
 - dbdata:/var/lib/postgresql/data
 healthcheck:
 test: ["CMD", "pg_isready", "-U", "postgres"]
 interval: 5s
 retries: 5

 redis:
 image: redis:7

volumes: # 命名卷（持久化）
 dbdata:

三、核心配置

3.1 服务定义

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


services:
 app:
 image: myapp:1.0  # 用现有镜像
 build: # 或从 Dockerfile 构建
 context: ./app
 dockerfile: Dockerfile.prod
 args:
 VERSION: 1.0 # 构建参数
 container_name: myapp  # 容器名
 restart: unless-stopped  # 重启策略
 working_dir: /app
 user: "1000:1000"
 stdin_open: true # -i
 tty: true # -t

3.2 端口与网络

1
2
3
4
5
6
7
8
9


 ports:
 - "8080:80" # 宿主机:容器
 - "443:443"
 expose:
 - "9000" # 只暴露给其他服务（不映射到宿主机）

 networks: # 加入自定义网络
 - frontend
 - backend

3.3 数据卷

1
2
3
4


 volumes:
 - ./code:/app  # 绑定挂载（宿主机目录）
 - dbdata:/var/lib/mysql  # 命名卷
 - /etc/localtime:/etc/localtime:ro  # 只读

3.4 环境变量

1
2
3
4
5
6
7


 environment:
 - DB_HOST=db  # 方式1
 - DB_PORT=5432
 env_file: # 方式2：从文件读
 - .env
 environment: # 方式3：map
 DB_HOST: ${DB_HOST}  # 引用宿主机环境变量

1
2
3


# .env 文件（compose 自动读取）
DB_HOST=db
DB_PASSWORD=secret

四、服务间依赖

1
2
3
4
5
6
7


services:
 app:
 depends_on: # 依赖关系
 db:
 condition: service_healthy  # 等 db 健康检查通过
 redis:
 condition: service_started  # 等 redis 启动即可

1
2
3
4
5
6
7


注意：
 depends_on 只控制「启动顺序」
 不等「服务就绪」（除非用 healthcheck + service_healthy）
 
 例：db 容器启动了，但 MySQL 还没接受连接
 → app 连不上 → 应用启动失败
 → 用 healthcheck 让 app 等 db 真正就绪

五、网络与服务发现

1
2
3
4
5
6
7
8
9


services:
 web:
 networks: [appnet]
 db:
 networks: [appnet]

networks:
 appnet:
 driver: bridge

1
2
3
4
5


同一 Compose 项目、同一网络的容器，可以用「服务名」互相访问：
 web 容器里访问 db → 连接 db:5432（不用 IP）
 DNS 自动解析服务名

 这就是 Compose 内置的服务发现（简单版）

六、常用命令

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


# 启动（后台）
docker compose up -d

# 启动并强制重新构建镜像
docker compose up -d --build

# 查看运行状态
docker compose ps

# 查看日志
docker compose logs
docker compose logs -f app # 跟踪某个服务
docker compose logs -f # 跟踪所有

# 停止并删除容器/网络（保留卷）
docker compose down

# 停止并删除卷（彻底清理）
docker compose down -v

# 单独操作某服务
docker compose start app
docker compose stop app
docker compose restart app

# 在运行的服务里执行命令
docker compose exec app bash

# 重新拉镜像后更新
docker compose pull
docker compose up -d

七、实战：完整应用栈

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40


# docker-compose.yml — 一个 .NET + PostgreSQL + Redis + Nginx 栈
version: "3.8"
services:
 nginx:
 image: nginx:1.25
 ports: ["80:80", "443:443"]
 volumes:
 - ./nginx.conf:/etc/nginx/nginx.conf:ro
 - ./certs:/etc/nginx/certs:ro
 depends_on: [web]

 web:
 build: ./src
 environment:
 ConnectionStrings__Db: "Host=db;Database=myapp;Username=postgres;Password=secret"
 Redis__Configuration: "redis:6379"
 depends_on:
 db: { condition: service_healthy }
 redis: { condition: service_started }
 restart: unless-stopped

 db:
 image: postgres:16
 environment:
 POSTGRES_PASSWORD: secret
 POSTGRES_DB: myapp
 volumes:
 - dbdata:/var/lib/postgresql/data
 healthcheck:
 test: ["CMD-SHELL", "pg_isready -U postgres"]
 interval: 5s
 timeout: 3s
 retries: 5

 redis:
 image: redis:7-alpine
 command: redis-server --maxmemory 256mb --maxmemory-policy allkeys-lru

volumes:
 dbdata:

1
2
3


# 一键启动整个环境
docker compose up -d
# → Nginx + Web + PostgreSQL + Redis 全部拉起，互相连通

八、进阶

8.1 多环境（profiles / override）

1
2
3
4
5
6
7


# 用 profiles 区分环境
services:
 app:
 image: myapp
 debug-tools:
 image: busybox
 profiles: ["debug"] # 只在 --profile debug 时启动

1
2


docker compose up -d # 不含 debug-tools
docker compose --profile debug up -d # 含 debug-tools

1
2
3
4


# override 文件（docker-compose.override.yml 自动叠加）
# docker-compose.yml（基础）
# docker-compose.override.yml（本地覆盖：加调试端口、挂源码）
# docker compose up 自动合并

8.2 资源限制

1
2
3
4
5
6
7
8
9


services:
 app:
 deploy:
 resources:
 limits:
 cpus: "1.0"
 memory: 512M
 reservations:
 memory: 256M

九、小结

Compose：一个 YAML 定义多容器，一条命令管理
适合：本地开发、CI、测试、单机小型生产
核心：services（服务）/ volumes（持久化）/ networks（网络）
服务发现：同网络容器用服务名互访（DNS）
依赖：depends_on + healthcheck 控制启动与就绪顺序
命令：up/down/logs/exec/ps

下一篇讲 Docker 网络与存储——容器的隔离与持久化细节。

Docker 学习笔记（二）：Dockerfile 与镜像最佳实践

Tue, 27 Jan 2026 10:00:00 +0800

写在前面

本文讲 Dockerfile——如何把应用打包成镜像。重点讲多阶段构建和镜像瘦身，这是写出生产级镜像的关键。一个臃肿的镜像（2GB）和一个精简的镜像（50MB），在拉取、部署、安全上差距巨大。

一、Dockerfile 指令

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


# 基础镜像
FROM nginx:1.25

# 维护者（已弃用，用 LABEL）
LABEL maintainer="jiwei"

# 运行命令（构建时执行）
RUN apt-get update && apt-get install -y curl

# 设置工作目录
WORKDIR /app

# 复制文件（推荐用 COPY 而非 ADD）
COPY . .
COPY package.json ./

# ADD：能解压 tar、能下 URL（但少用）
ADD https://example.com/app.tar.gz /tmp/

# 环境变量
ENV NODE_ENV=production
ENV PATH="/app/node_modules/.bin:$PATH"

# 构建参数（构建时可变）
ARG VERSION=1.0

# 暴露端口（文档作用，实际映射要 -p）
EXPOSE 8080

# 启动命令
CMD ["node", "server.js"]

# 入口点（和 CMD 配合）
ENTRYPOINT ["docker-entrypoint.sh"]

CMD vs ENTRYPOINT

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


CMD：容器默认启动命令，可被 docker run 后的参数覆盖
 CMD ["nginx", "-g", "daemon off;"]
 docker run myimage command → 用 command 替换 CMD

ENTRYPOINT：固定入口，docker run 的参数追加在后面
 ENTRYPOINT ["nginx"]
 docker run myimage -v → 实际执行 nginx -v

最佳实践：ENTRYPOINT（固定）+ CMD（默认参数）
 ENTRYPOINT ["node"]
 CMD ["server.js"]

二、一个典型 Web 应用镜像

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# .NET 应用示例
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY MyApp.csproj .
RUN dotnet restore
COPY . .
RUN dotnet publish -c Release -o /app

FROM mcr.microsoft.com/dotnet/aspnet:8.0
WORKDIR /app
COPY --from=build /app .
EXPOSE 8080
ENTRYPOINT ["dotnet", "MyApp.dll"]

1
2
3
4
5
6
7
8


# Node.js 应用示例
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --production
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

三、多阶段构建（重要）

多阶段构建是镜像瘦身的核心——用大镜像构建，把产物拷到小镜像。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# 阶段1：构建（大镜像，含 SDK/编译器）
FROM golang:1.22 AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp . # 编译出二进制

# 阶段2：运行（极小镜像）
FROM alpine:3.19
COPY --from=builder /app/myapp /usr/local/bin/
CMD ["myapp"]

# 效果：
# builder 阶段镜像 ~800MB（含 Go 工具链）
# 最终镜像 ~15MB（只有 alpine + 二进制）
# SDK/源码/中间产物都不进最终镜像

1
2
3
4
5
6
7


为什么重要：
 不用多阶段：镜像含 SDK（GB 级）、源码、构建工具 → 大、不安全
 多阶段：最终镜像只含运行时 + 产物 → 小、安全、快

 Go/Rust：最终镜像可到几 MB（静态二进制 + scratch/alpine）
 .NET/Java：用 runtime 镜像（不含 SDK）
 Node/Python：用 alpine 变体

四、镜像瘦身最佳实践

4.1 选小基础镜像

1
2
3
4
5
6
7


基础镜像大小对比（Node 为例）：
 node:20 ~1GB （完整 Debian）
 node:20-slim ~250MB （精简 Debian）
 node:20-alpine ~150MB （Alpine，最小）

 生产优先 alpine 或 slim
 注意：alpine 用 musl libc，少数库不兼容（要测试）

4.2 合并 RUN、清理缓存

1
2
3
4
5
6
7
8
9


# ❌ 多个 RUN，每层都大，缓存残留
RUN apt-get update
RUN apt-get install -y curl
RUN apt-get install -y git

# ✅ 合并 RUN，同一层内清理
RUN apt-get update && apt-get install -y --no-install-recommends \
 curl git \
 && rm -rf /var/lib/apt/lists/*

4.3 利用构建缓存

1
2
3
4
5
6
7
8


# ❌ 先 COPY 全部，依赖没变也重建
COPY . .
RUN npm ci

# ✅ 先 COPY 依赖描述，依赖没变就用缓存
COPY package*.json ./
RUN npm ci # 缓存命中（除非 package.json 变）
COPY . . # 代码变只重新 COPY

1
2
3
4


Dockerfile 指令顺序影响构建速度：
 把"变化少的"放前面（依赖、系统包）
 把"变化多的"放后面（源代码）
 → 充分利用缓存，加快构建

4.4 .dockerignore

1
2
3
4
5
6
7
8
9


# .dockerignore（类似 .gitignore）
node_modules
.git
*.log
.env
dist
build

 避免 COPY . . 把无用文件打进镜像（减小体积、加速构建、防泄密）

4.5 用 distroless / scratch

1
2
3
4
5
6
7


distroless：Google 出品，只有运行时，没有 shell/包管理器
 → 极小、极安全（攻击面小）
 gcr.io/distroless/nodejs20-debian12

scratch：空镜像，只放静态二进制
 → 最小（几 MB）
 适合 Go/Rust 静态编译的程序

五、安全实践

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# ❌ 默认用 root 运行（危险）
FROM node:20
CMD ["node", "server.js"]

# ✅ 创建非 root 用户
FROM node:20
RUN groupadd -r app && useradd -r -g app appuser
USER appuser # 切换用户
CMD ["node", "server.js"]

# 或用基础镜像自带的非 root 用户
FROM node:20
USER node # node 镜像自带 node 用户

1
2
3
4
5
6
7


其他安全要点：
 ✓ 用非 root 用户（USER 指令）
 ✓ 最小权限（只装需要的）
 ✓ 用特定版本 tag（node:20.11），别用 latest（不可控）
 ✓ 扫描漏洞（docker scout / trivy）
 ✓ 不把密钥/密码写进镜像（用环境变量/secret）
 ✓ 多阶段构建（不暴露源码和构建工具）

六、构建与推送

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# 构建（注意最后的 . 表示上下文目录）
docker build -t myapp:1.0 .
docker build -t myapp:1.0 -f Dockerfile.prod . # 指定 Dockerfile

# 多架构构建（ARM/x86）
docker buildx build --platform linux/amd64,linux/arm64 -t myapp:1.0 .

# 打标签
docker tag myapp:1.0 registry.example.com/myapp:1.0

# 登录仓库
docker login registry.example.com

# 推送
docker push registry.example.com/myapp:1.0

七、常见问题

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


镜像太大？
 → 多阶段构建 + alpine/slim + .dockerignore + 合并 RUN

构建慢？
 → 调整指令顺序利用缓存（依赖在前，代码在后）

CMD 不生效？
 → docker run 后的参数会覆盖 CMD；用 ENTRYPOINT 固定

apt-get 卡住？
 → 配国内镜像源，或用 alpine（apk add）

时区不对？
 → RUN ln -snf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
 或设 TZ 环境变量

八、小结

Dockerfile 指令：FROM/RUN/COPY/WORKDIR/ENV/CMD/ENTRYPOINT/EXPOSE
CMD vs ENTRYPOINT：CMD 可覆盖，ENTRYPOINT 固定；推荐 ENTRYPOINT + CMD
多阶段构建：大镜像构建 → 产物拷到小镜像，瘦身核心
瘦身：alpine/slim 基础镜像、合并 RUN 清理、利用缓存、.dockerignore、distroless/scratch
安全：非 root 用户、固定版本 tag、漏洞扫描、密钥不入镜像
缓存优化：变化少的指令在前，变化多的在后

下一篇讲 Docker Compose——本地多容器编排。

Docker 学习笔记（一）：基础与核心原理

Mon, 26 Jan 2026 10:00:00 +0800

写在前面

本文是 Docker 系列第一篇。容器化是云原生的基石，K8s、微服务、CI/CD 都建立在它之上。本文讲清楚 Docker 是什么、容器的底层原理（namespace/cgroups）、核心概念和基本用法。

系列定位：本系列已有 K8s 系列，Docker 是它的前置基础。K8s 系列里提到的容器概念，这里能找到根源。

一、Docker 是什么

1.1 定义

1
2
3
4
5
6


Docker = 容器化平台
 把应用 + 依赖（库、环境、配置）打包成一个「容器」
 容器在任何装了 Docker 的机器上都能一致运行

解决的核心问题：
 "在我机器上能跑啊！" → 容器保证了环境一致

1.2 容器 vs 虚拟机

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


虚拟机（VM）：
 硬件级虚拟化
 每个 VM 完整操作系统（内核 + 用户空间）
 重、慢、占资源（GB 级）

容器（Container）：
 操作系统级虚拟化
 共享宿主机内核，只隔离进程
 轻、快、省资源（MB 级）

 虚拟机 容器
 ┌──────────────┐ ┌──────────────┐
 │ App │ App │ │ App │ App │
 │ 库 │ 库 │ │ 库 │ 库 │
 │ 完整OS │完整OS │ │ 容器运行时 │
 │ Hypervisor │ │ 宿主机OS内核 │
 │ 物理硬件 │ │ 物理硬件 │
 └──────────────┘ └──────────────┘
 启动分钟级、GB 启动秒级、MB

二、核心概念

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


镜像（Image）
 只读模板，包含应用 + 依赖 + 环境
 分层存储（Layer）
 类比：面向对象的「类」、程序的「安装包」

容器（Container）
 镜像的运行实例
 可读写（在镜像层上加一层）
 类比：「对象」、安装包「运行起来」

仓库（Registry）
 存放镜像的地方
 Docker Hub（公共）、Harbor（私有）、阿里云/腾讯云镜像服务
 类比：代码的 GitHub、npm registry

Dockerfile
 描述如何构建镜像的文本文件
 一系列指令（FROM/RUN/COPY...）

三、容器底层原理

容器不是凭空实现的，它依赖 Linux 内核三个特性：

3.1 Namespace（隔离）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


Namespace 让容器"以为"自己独占系统

 PID Namespace — 进程隔离（容器内 PID 从 1 开始，看不到宿主机进程）
 NET Namespace — 网络隔离（独立的网卡、IP、端口、路由）
 IPC Namespace — 进程间通信隔离
 MOUNT Namespace — 文件系统挂载点隔离
 UTS Namespace — 主机名隔离
 USER Namespace — 用户隔离（容器内 root ≠ 宿主机 root）
 Cgroup Namespace — cgroup 视图隔离

 → 容器 = 一个被 namespace 包裹的进程

3.2 Cgroups（资源限制）

1
2
3
4
5
6
7
8


Cgroups（Control Groups）限制容器能用多少资源

 CPU — 限制 CPU 核数/份额
 内存 — 限制内存上限（超了 OOM Kill）
 磁盘IO — 限制读写速率
 网络 — 限速

 → 防止一个容器吃光宿主机资源

3.3 联合文件系统（UnionFS）

1
2
3
4
5
6
7


镜像分层存储的基础

 镜像由多个只读层叠加
 容器在镜像上加一个可写层（Copy-on-Write）
 多个容器共享相同的镜像层（省空间）

 例：基础镜像层 + 安装依赖层 + 应用代码层 + 容器可写层

1
2
3


一句话总结容器本质：
 容器 = Namespace（隔离）+ Cgroups（限制）+ UnionFS（分层镜像）
 它不是虚拟机，是一个被特殊隔离和限制的进程

四、安装

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# Linux（Ubuntu/Debian）
curl -fsSL https://get.docker.com | sh
sudo systemctl enable --now docker

# 将当前用户加入 docker 组（免 sudo）
sudo usermod -aG docker $USER
# 重新登录生效

# 验证
docker version
docker run hello-world

1
2
3
4
5
6


macOS / Windows：
 安装 Docker Desktop（图形化，内置 Docker Engine）
 Windows 用 WSL2 后端性能更好

国内加速（镜像仓库）：
 配置 registry-mirrors 指向国内镜像源

五、基本命令

5.1 镜像命令

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# 搜索镜像
docker search nginx

# 拉取镜像（默认 Docker Hub）
docker pull nginx
docker pull nginx:1.25 # 指定版本
docker pull nginx:latest

# 列出本地镜像
docker images

# 删除镜像
docker rmi nginx

# 构建镜像（见 Dockerfile 篇）
docker build -t myapp:1.0 .

5.2 容器命令

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


# 运行容器
docker run -d --name web -p 8080:80 nginx
# -d 后台运行
# --name web 容器名
# -p 8080:80 端口映射（宿主机:容器）
# nginx 镜像名

# 列出运行中的容器
docker ps
docker ps -a # 包括已停止的

# 启动/停止/重启
docker start web
docker stop web
docker restart web

# 进入容器
docker exec -it web bash # 开个终端进去

# 查看日志
docker logs web
docker logs -f web # 跟踪输出

# 删除容器
docker rm web
docker rm -f web # 强制删除运行中的

# 查看容器详情/资源占用
docker inspect web
docker stats # 实时资源（CPU/内存）

六、第一个容器

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# 跑一个 Nginx
docker run -d --name mynginx -p 8080:80 nginx

# 访问 http://localhost:8080 → 看到 Nginx 欢迎页
# 这个 Nginx 跑在容器里，和宿主机隔离

# 进入容器看
docker exec -it mynginx bash
ls /usr/share/nginx/html # 网站文件
exit

# 查看日志
docker logs mynginx

# 停止并删除
docker stop mynginx && docker rm mynginx

1
2
3
4
5


发生了什么：
 1. docker pull nginx（拉镜像）
 2. 创建容器（隔离 namespace、限制 cgroups、挂载镜像层）
 3. 端口映射（宿主机 8080 → 容器 80）
 4. Nginx 进程在容器内跑（PID 1）

七、端口、数据、环境

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# 端口映射（-p 宿主机:容器）
docker run -p 8080:80 -p 8443:443 nginx

# 数据卷（持久化，容器删了数据还在）
docker run -v /host/data:/container/data nginx
docker run -v mydata:/var/lib/mysql mysql # 命名卷

# 环境变量
docker run -e MYSQL_ROOT_PASSWORD=123456 mysql

# 工作目录、用户
docker run -w /app -u appuser myimage

# 重启策略
docker run --restart=always nginx # 总是自动重启

八、小结

Docker：容器化平台，解决环境一致性问题
容器 vs 虚拟机：容器共享内核、轻量（MB）、秒启动；VM 完整 OS、重（GB）
核心概念：镜像（模板）、容器（实例）、仓库（存储）、Dockerfile（构建脚本）
底层原理：Namespace（隔离）+ Cgroups（限制）+ UnionFS（分层）
基本命令：pull/run/ps/exec/logs/build

下一篇讲 Dockerfile——如何把你的应用打包成镜像。