夜雨聆风做运维这些年，我见过太多团队在部署环境上栽跟头。有一次，一个新来的小伙子花了一整天在服务器上配Python环境，装了又卸、卸了又装，最后项目还是跑不起来。旁边一个运维老鸟走过去，甩了一句：「你怎么不用Docker？」五分钟后，容器跑起来了。
这就是Docker的魔力。它把「在我机器上能跑」这句话，变成了「在任何地方都能跑」。
今天这期，咱们从Docker的安装说起，一路聊到生产环境的配置调优和故障排查。不管你是刚接触容器的新手，还是已经在用但想深入理解的老手，这篇文章都应该能帮到你。
一、Docker到底是个啥
简单说，Docker就是一个容器化平台。它把应用和它需要的一切——代码、运行时、系统工具、库文件——全部打包到一个叫镜像（Image）的东西里。镜像跑起来之后，就是一个容器（Container）。
你可以把镜像理解成一个「只读模板」，容器就是根据这个模板创建出来的「运行实例」。就像面向对象编程里的类和对象一样——镜像是类，容器是对象实例。
容器和虚拟机不一样的地方在于：虚拟机要模拟一整套硬件，启动一个系统得几分钟，占几个G的内存。容器直接跑在宿主机的内核上，启动只要几秒，内存占用以MB计。这也是为什么大家说Docker轻量。
二、Docker安装（CentOS/Ubuntu/Debian）
安装Docker其实不难，但很多人在这一步就踩坑——装了个旧版本，结果缺少一些新特性。咱们用官方仓库装，保证拿到最新版。
CentOS/RHEL/Rocky Linux
# 1. 安装依赖
sudo yum install -y yum-utils
# 2. 添加Docker官方仓库
sudo yum-config-manager --add-repo \
https://download.docker.com/linux/centos/docker-ce.repo
# 3. 安装Docker Engine
sudo yum install -y docker-ce docker-ce-cli containerd.io
# 4. 启动并设置开机自启
sudo systemctl enable --now docker
# 5. 验证安装
docker --version
docker run --rm hello-world
这里有个细节：docker-ce是社区版，containerd.io是底层容器运行时。两个都要装。
Ubuntu/Debian
# 1. 安装依赖
sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg
# 2. 添加Docker官方GPG密钥
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
| sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg
# 3. 设置仓库
echo \
"deb [arch=$(dpkg --print-architecture) \
signed-by=/etc/apt/keyrings/docker.gpg] \
https://download.docker.com/linux/ubuntu \
$(. /etc/os-release && echo $VERSION_CODENAME) stable" \
| sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
# 4. 安装
sudo apt-get update
sudo apt-get install -y docker-ce docker-ce-cli containerd.io
sudo systemctl enable --now docker
安装完成后，建议把当前用户加到docker用户组，这样就不用每次都sudo了：
sudo usermod -aG docker $USER
# 重新登录生效，然后：
docker run --rm hello-world
看到「Hello from Docker!」就说明安装没问题了。我们来看下运行效果：
从输出可以看到，Docker版本27.5.1，存储驱动用的是overlay2，这是目前最推荐的驱动。内核版本、操作系统架构这些信息都在这儿，后面排查问题的时候会用到。
三、Docker vs 其他容器运行时
很多人以为Docker就是容器的代名词，其实不是。Docker只是一个容器平台，底层真正干活的是containerd这个运行时。而且市面上还有其他几个主流的容器工具，各有各的特点。
1. Docker
Docker的核心优势在于生态完整。它有Docker Hub（最大的镜像仓库）、Docker Compose（编排工具）、Dockerfile（镜像构建标准），加上最成熟的CLI体验。对于日常开发、测试、甚至中小型生产环境，Docker依然是首选。
不过Docker有个历史包袱：它默认用一个叫dockerd的守护进程来管理所有容器。这意味着所有容器都跑在同一个进程下——一个容器出问题，理论上可能影响其他容器。另外，dockerd默认以root权限运行，在安全敏感的场景下，这是个隐患。
2. Podman
Podman是Red Hat搞的，和Docker最大的区别是——不需要守护进程。每个容器是一个独立的进程，互不干扰。而且Podman支持rootless模式，普通用户就能跑容器，不用sudo。安全方面比Docker强一截。
命令层面，Podman基本兼容Docker CLI，很多场景下你把docker换成podman就能直接用。但在Docker Compose的兼容性上，Podman还在追赶。
3. containerd
containerd是Docker公司开源出来的底层容器运行时。它不负责构建镜像、不负责编排，只管一件事：跑容器。Kubernetes默认就用containerd作为CRI（容器运行时接口）的实现。
如果你的团队主要用K8s，那containerd是最佳选择——轻量、稳定、CNCF毕业项目。但它没有Docker那么好用的CLI，日常开发不太方便。
4. LXC/LXD
LXC和应用级容器（Docker/Podman/containerd）走的是不同的路线。LXC是系统级容器——它模拟的是一个完整的操作系统环境，有自己的init进程、systemd服务。你可以把它当成一个轻量级的虚拟机来用。
适合场景：你想在一台机器上跑多个完整的Linux系统，但不想承受虚拟机的性能开销。不适合场景：微服务部署、CI/CD流水线——这些是应用级容器的天下。
选哪个？
场景 推荐
─────────────────────────────────────────
日常开发/测试 Docker（生态最成熟）
安全敏感/无守护进程 Podman（rootless）
Kubernetes集群 containerd（K8s原生）
多系统隔离运行 LXC/LXD（系统级容器）
CI/CD流水线 Docker/Podman（速度快）
一句话总结：Docker依然是最通用的选择，但在特定场景下，其他工具可能更合适。了解它们的差异，才能做出正确的技术选型。
四、Docker日常操作
安装好之后，最常用的就是这几个命令了。我总结了一套日常操作的最小集合，够你80%的场景。
# 拉取镜像
docker pull nginx:latest
# 运行容器
docker run -d --name myweb -p 8080:80 nginx
# 查看运行中的容器
docker ps
# 查看所有容器（包括已停止的）
docker ps -a
# 查看容器日志
docker logs myweb --tail 50 -f
# 进入容器内部
docker exec -it myweb /bin/bash
# 停止/启动/重启容器
docker stop myweb
docker start myweb
docker restart myweb
# 删除容器
docker rm myweb
# 查看本地镜像
docker images
# 删除镜像
docker rmi nginx:latest
# 查看容器资源占用
docker stats --no-stream
# 一键清理（慎用！）
docker system prune -a
实际操作大概是这样：
docker stats这个命令特别实用。它能告诉你每个容器的CPU、内存、网络、磁盘IO使用情况。有一次一个Java应用内存泄漏，就是靠这个命令第一时间发现的——内存占用从500MB一路飙到3GB，容器眼看就要OOM了。
五、Dockerfile深度解析
Dockerfile是构建镜像的「配方文件」。它定义了一个镜像的每一层该怎么构建。理解Dockerfile，是理解Docker的核心。
5.1 一个实战Dockerfile
下面是一个生产可用的Python应用Dockerfile，我逐行解释为什么这么写：
# 基于官方Python精简镜像
FROM python:3.12-slim
# 设置工作目录
WORKDIR /app
# 先复制依赖文件，利用缓存层
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
# 再复制项目代码
COPY . .
# 创建非root用户运行
RUN useradd -m appuser && chown -R appuser:appuser /app
USER appuser
# 声明暴露端口
EXPOSE 8000
# 启动命令（exec格式）
CMD ["gunicorn", "--bind", "0.0.0.0:8000", "app:app"]
5.2 逐行拆解
FROM python:3.12-slim — 选基础镜像是第一步。slim版本去掉了不必要的系统工具，镜像体积比完整版小60%以上。更小 = 更快的拉取速度、更少的安全风险。如果是Go或Rust编译出来的静态二进制，可以直接用alpine，体积只有几MB。
WORKDIR /app — 设置工作目录。后续所有RUN、COPY、CMD命令都在这个目录下执行。不要用根目录，也不要用/tmp。
COPY requirements.txt 然后 RUN pip install — 这一步有个关键技巧：先复制依赖文件安装，再复制代码。为什么？因为Docker构建是分层的，每一层都有缓存。如果先COPY . .再install，那么代码改了就要重新安装所有依赖（缓存失效）。把requirements.txt单独COPY出来install，只要依赖没变，install这一层就直接用缓存，构建速度从几分钟缩短到几秒。
--no-cache-dir — pip默认会把下载的wheel包缓存下来，在容器里这完全没必要，加上这个参数能减少镜像体积。
RUN useradd ... USER appuser — 生产环境绝对不要用root跑容器。一旦容器被攻破，攻击者就直接拿到root权限。创建一个专门的非特权用户，是基本安全底线。
CMD用exec格式 — CMD有两种写法：CMD ["gunicorn", "..."]（exec格式）和CMD gunicorn ...（shell格式）。exec格式直接把应用作为PID 1运行，信号处理正常。shell格式会多一个/bin/sh中间层，导致Ctrl+C停不下来、优雅关闭失效。所以永远用exec格式。
5.3 多阶段构建
Dockerfile最强大的特性之一：多阶段构建。简单说就是：第一阶段用来编译，第二阶段只拿编译产物，把编译工具全扔掉。
# 第一阶段：编译
FROM golang:1.22 AS builder
WORKDIR /src
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o /myapp
# 第二阶段：运行
FROM alpine:3.19
RUN apk --no-cache add ca-certificates
COPY --from=builder /myapp /myapp
EXPOSE 8080
CMD ["/myapp"]
第一阶段的golang镜像有800MB+，加上编译工具和源代码，最终产物如果不用多阶段构建，镜像可能超过1GB。用多阶段之后，最终镜像只有10-20MB——一个alpine基础镜像加一个二进制文件。这个差距在生产环境中意义巨大：镜像仓库存储成本、网络传输时间、部署速度，全部大幅优化。
六、Docker文件系统——overlay2到底怎么回事
很多用Docker的人从来不看文件系统这一层。出了问题就一句「磁盘满了」完事。但如果理解了overlay2的原理，很多问题的排查思路会完全不同。
6.1 镜像是怎么存盘的
Docker的镜像是分层存储的。每一层都是一个只读的文件系统快照。比如说你拉了一个Ubuntu镜像，它可能由5个层组成：
• 第一层：基础的Linux文件系统
• 第二层：apt-get安装的基础包
• 第三层：你安装的应用
• 第四层：配置文件
• 第五层：启动脚本
当你用docker pull的时候，这些层被下载到/var/lib/docker/overlay2/目录下。每一个层是一个独立的目录。
6.2 overlay2的工作原理
overlay2利用了Linux内核的overlayfs技术。它把多个目录叠加成一个统一的视图。打个比方：你在透明的塑料片上分别画不同的东西，然后把这些塑料片叠在一起看，就合成了一幅完整的画。
具体到overlay2，它用三个目录来实现：
lowerdir（只读层）：就是镜像的各层。多个lowerdir从底向上叠加，上面层里的文件会覆盖下面层的同名文件。
upperdir（读写层）：容器启动时创建的。你在容器里新建、修改、删除文件，实际操作都在这一层。修改一个文件时，overlay2会把整个文件从lowerdir复制到upperdir，然后在upperdir里做修改——这叫「写时复制」（Copy-on-Write）。
merged（统一视图）：容器实际看到的文件系统。它是lowerdir和upperdir合并后的结果。
6.3 删除文件时发生了什么
这个比较反直觉。当你在容器里删一个来自镜像层的文件时，这个文件并没有真正被删除。overlay2会在upperdir里创建一个特殊的「白标记」文件（whiteout file），告诉系统「这个文件被隐藏了」。所以文件数据依然在磁盘上，只是被标记为不可见了。
这就是为什么在Dockerfile里用RUN apt-get clean或者rm -rf来减小镜像体积有时候不生效——删除操作本身也会增加一个层。正确的做法是在同一个RUN指令里安装和清理：
# 正确做法：安装和清理在同一个RUN里
RUN apt-get update && \
apt-get install -y package1 package2 && \
rm -rf /var/lib/apt/lists/*
# 错误做法：分成了多个层
RUN apt-get update
RUN apt-get install -y package1 package2
RUN rm -rf /var/lib/apt/lists/*
6.4 数据持久化——卷（Volume）
容器一删，里面的数据就没了（upperdir被清掉了）。如果数据需要持久化，就得用卷（Volume）或者绑定挂载（Bind Mount）。
# 方式1: Docker管理的卷（推荐）
docker volume create mydata
docker run -d -v mydata:/data myapp
# 方式2: 绑定挂载宿主机目录
docker run -d -v /host/path:/container/path myapp
# 查看卷
docker volume ls
docker volume inspect mydata
生产环境推荐用Docker管理的卷，而不是绑定挂载。卷由Docker统一管理，有备份、迁移等工具支持。绑定挂载更适合开发阶段——直接改宿主机上的代码文件，容器里实时生效。
七、Docker Compose——多容器编排
当一个项目需要多个服务协同工作的时候——比如Web应用需要Nginx做反向代理、Gunicorn跑应用代码、Redis做缓存、PostgreSQL做数据库——一个一个跑docker run命令就很痛苦了。Docker Compose就是来解决这个问题的。
一个docker-compose.yml文件，定义所有服务和它们的关系，一条命令全部启动。
7.1 安装Compose
新版Docker已经把Compose集成进来了，用的是docker compose（没有横杠）这个子命令。如果没有，手动安装：
# 安装Docker Compose插件
sudo apt-get install -y docker-compose-plugin
# 或者手动下载二进制
DOCKER_CONFIG=${DOCKER_CONFIG:-$HOME/.docker/cli-plugins}
mkdir -p $DOCKER_CONFIG/cli-plugins
curl -SL https://github.com/docker/compose/releases/latest/download/docker-compose-linux-x86_64 \
-o $DOCKER_CONFIG/cli-plugins/docker-compose
chmod +x $DOCKER_CONFIG/cli-plugins/docker-compose
# 验证
docker compose version
7.2 一个完整的compose文件
services:
web:
build: .
ports:
- "8080:8000"
environment:
- DB_HOST=db
- REDIS_URL=redis://cache:6379
depends_on:
- db
- cache
restart: unless-stopped
db:
image: postgres:16-alpine
environment:
- POSTGRES_DB=myapp
- POSTGRES_USER=appuser
- POSTGRES_PASSWORD=secret
volumes:
- pgdata:/var/lib/postgresql/data
restart: unless-stopped
cache:
image: redis:7-alpine
volumes:
- redisdata:/data
restart: unless-stopped
volumes:
pgdata:
redisdata:
7.3 常用命令
# 启动所有服务（后台运行）
docker compose up -d
# 查看服务状态
docker compose ps
# 查看日志
docker compose logs -f web
# 重新构建并启动
docker compose up -d --build
# 停止所有服务（保留数据卷）
docker compose stop
# 停止并删除所有服务+网络（保留数据卷）
docker compose down
# 停止并删除一切（包括数据卷，慎用！）
docker compose down -v
几个关键配置说明：
• depends_on：定义启动顺序。web服务会等db和cache启动后才启动。但要注意：它只等容器running，不等服务就绪（比如PostgreSQL还在初始化）。如果需要等数据库就绪，得用健康检查（healthcheck）配合。
• restart: unless-stopped：容器意外退出时自动重启，除非你手动stop它。生产环境必备。
• services之间用服务名互相访问：Compose会自动创建一个网络，所有服务在同一个网络内，直接用服务名当主机名访问。所以web里配DB_HOST=db就能直接连到PostgreSQL，不需要IP。
八、生产环境Docker配置
生产环境跑Docker，默认配置是远远不够的。这里是我一直在用的一套daemon.json配置，可以直接抄作业。
8.1 daemon.json配置
文件位置：/etc/docker/daemon.json
{
"log-driver": "json-file",
"log-opts": {
"max-size": "100m",
"max-file": "3"
},
"storage-driver": "overlay2",
"storage-opts": [
"overlay2.override_kernel_check=true"
],
"live-restore": true,
"no-new-privileges": true,
"userland-proxy": false,
"default-ulimits": {
"nofile": {
"Name": "nofile",
"Hard": 65536,
"Soft": 65536
}
}
}
8.2 逐项说明
日志轮转（log-driver + log-opts）：这是我最想强调的一条。Docker默认的日志策略是json-file，但不限制大小。结果就是——一个容器跑几个月，日志文件可能攒到几十个G，直接把宿主机磁盘撑爆。设置max-size=100m，max-file=3，意思是：单个日志文件不超过100MB，最多保留3个历史文件。这样日志占用永远不超过300MB。
live-restore: true：这个太重要了。Docker守护进程重启的时候，默认会把所有容器停掉。开启live-restore之后，dockerd重启期间容器继续运行。做维护升级的时候不用停业务。
no-new-privileges: true：禁止容器内的进程获取额外的权限。这是一个安全加固选项。
userland-proxy: false：默认情况下，Docker用用户态的docker-proxy进程来处理端口转发。关掉之后用iptables DNAT，性能更好，也减少进程数量。
8.3 镜像加速
国内拉Docker Hub镜像慢得令人发指。在daemon.json里加镜像加速器：
{
"registry-mirrors": [
"https://docker.1ms.run"
]
}
注意：镜像加速器经常变动。建议关注社区维护的最新可用列表。2026年初开始，很多传统加速器（阿里云、中科大等）陆续下线了，需要找新的替代方案。
8.4 资源限制
生产环境跑容器，一定要给资源限制。不然一个容器就能把整台机器的内存吃光：
# 限制内存1G，CPU最多用2个核心
docker run -d --name myapp \
--memory=1g \
--memory-swap=1g \
--cpus=2 \
--restart=unless-stopped \
myapp:latest
--memory-swap设为和--memory相同的值，就是完全禁用swap。容器内存不够就直接OOM，别让它把swap也吃了。这样问题暴露得更快，比拖到整台机器都卡死好处理得多。
九、故障排查实战
Docker出了问题怎么查？下面这几个场景，是我在实际运维中遇到过最频繁的。
9.1 容器启动后立即退出
最常见的现象：docker run之后容器马上退出，docker ps看不到，docker ps -a能看到状态是Exited。
排查步骤：
• 第一步：docker logs <容器名>。90%的问题日志里有答案。
• 第二步：检查退出码。docker inspect <容器名> --format '{{.State.ExitCode}}'。退出码0是正常退出，137是被OOM Killer杀了（内存不够），1通常是应用内部错误。
• 第三步：常见原因——配置文件路径不对、环境变量缺失、端口被占用、数据库连不上、应用代码有bug。
• 应急调试：用docker run -it --entrypoint /bin/sh myapp进容器手动排查。
9.2 容器之间网络不通
用docker run分别创建的两个容器，默认在各自的bridge网络里，互相访问不了。解决方案：创建一个自定义网络，把两个容器都加进来：
# 创建自定义网络
docker network create mynet
# 启动容器时指定网络
docker run -d --name web --network mynet nginx
docker run -d --name app --network mynet myapp
# 容器内直接用名字访问
docker exec app ping web
9.3 磁盘空间不足
这是Docker运维最经典的问题之一。容器跑久了，磁盘被撑满是必然的——镜像层、停止的容器、未使用的卷、日志文件，都在一点一点蚕食磁盘空间。
排查工具：
# 查看Docker磁盘占用概况
docker system df
# 清理所有未使用的镜像、容器、网络
docker system prune
# 加上 -a 会删除所有未被容器使用的镜像
# 更激进：docker system prune -a --volumes
# 找出最占空间的镜像
docker images --format "{{.Size}}\t{{.Repository}}:{{.Tag}}" \
| sort -rh | head -10
# 查看overlay2目录占用
du -sh /var/lib/docker/overlay2/
日常维护建议：在crontab里加一个每周清理任务，自动清理不用的镜像和停止的容器。加上之前daemon.json里的日志轮转配置，磁盘空间问题基本不会找上门。
9.4 端口冲突
新起的容器报「port is already allocated」，说明端口被占用了。可能是另一个容器在用，也可能是宿主机上某个服务在用。
# 查看哪个进程占用了端口
sudo lsof -i :8080
sudo ss -tlnp | grep 8080
# 查看Docker占用了哪些端口
docker ps --format "table {{.Names}}\t{{.Ports}}"
# 如果dockerd卡住了，端口没释放
docker network prune
systemctl restart docker
有时候dockerd自己出了问题，端口不会自动释放。这时候重启dockerd（记得开live-restore，这样容器不会停）能解决大部分「幽灵端口」问题。
9.5 综合排查流程
下面是一张我整理的常见故障排查速查表：
# 排查容器问题标准流程
# 1. 先看状态
docker ps -a --filter "status=exited"
# 2. 看日志
docker logs <容器名> --tail 50
# 3. 检查环境变量
docker inspect <容器名> | grep -A5 Env
# 4. 检查磁盘
df -h /var/lib/docker
docker system df
# 5. 检查网络
docker network ls
docker exec <容器> ping <目标容器>
# 6. 检查资源限制
docker stats --no-stream
dmesg | grep -i oom
dmesg | grep -i oom这个命令值得单独说。如果容器莫名其妙被杀了，退出码是137，很大概率是被Linux内核的OOM Killer干掉了。用dmesg能看到内核杀哪个进程、当时内存用了多少。这对定位内存泄漏极其有用。
总结一下
这期内容不少，咱们回顾几个核心要点：
• 安装：用官方仓库装，别用系统自带的旧版本
• 选型：Docker生态最全，Podman更安全，containerd适合K8s，LXC适合系统级隔离
• Dockerfile：分层缓存是核心技巧，多阶段构建能大幅减小镜像，永远用exec格式写CMD，永远不用root跑容器
• 文件系统：overlay2分层存储+写时复制，理解了这个就能理解镜像为什么小、删除为什么不释放空间
• Compose：多服务编排必备，用自定义网络实现服务间通信
• 生产配置：daemon.json里日志轮转和live-restore是必选项，资源限制不可少
• 故障排查：日志是第一步，磁盘空间是最高频问题，OOM Killer是隐形杀手
Docker这东西，上手不难，但想用好、用得稳，细节很多。希望这篇能帮你少走一些弯路。
下期预告：咱们来聊聊Docker在企业中的实际部署——镜像仓库搭建（Harbor）、CI/CD集成、容器监控告警方案。如果你正在用Docker管生产环境，那期会很实用。
#Docker #容器 #Linux #运维 #Dockerfile #DockerCompose #故障排查 #生产环境
