Docker 基础命令速查：容器、镜像与数据卷运维实战

结论先行：Docker 把应用与运行依赖打包成不可变镜像，一条 docker run 即可在任意 Linux 服务器秒级拉起，彻底终结「本地能跑、线上崩溃」的环境灾难。独立开发者生产运维盯死四条铁律：数据必须通过命名卷持久化（-v data:/path）、对外服务明确绑定端口（-p host:port）、镜像必须固定语义化版本标签严禁使用 latest、单机两个以上关联容器直接使用 Docker Compose 声明。

0、写在前面

做海外项目或部署自托管服务，最让人头疼的往往不是写业务代码，而是环境不一致：

本地开发机运行正常，搬上 VPS 部署就报错；
服务器升级 Python 或 Node.js 系统版本，顺带把其他项目的依赖全搞崩；
同一台小内存 VPS 想同时跑多个服务，端口与共享库频频冲突。

Docker 是解决这类环境污染的最直接方案。它把应用代码、运行时依赖、系统环境打包进统一的「镜像」，以轻量级隔离的「容器」形式在宿主机上运行。

1
2
3

[ 镜像 (Image) ]  ── 实例化 (docker run) ──>  [ 容器 (Container) ]
    ↑ 打包 (docker build)                        ↓ 数据持久化
[ Dockerfile / 源码 ]                         [ 数据卷 (Volume) ]

镜像 (Image)：只读的静态运行模板，包含应用运行所需的一切代码与依赖。
容器 (Container)：镜像运行后的隔离实例，拥有自己独立的文件系统和进程空间。
数据卷 (Volume)：独立于容器生命周期的宿主机目录，保障容器销毁后数据库数据依旧留存。

本文整理海外独立开发者日常必须用到的 Docker 核心命令，涵盖安装基线、镜像处理、容器运维、持久化备份与生产排障。

1、期望目标

阅读并实操本文后，你将达成以下目标：

[ ] 按照生产级安全与防爆盘规范，在 VPS 上完成 Docker 引擎基线安装；
[ ] 熟练运用镜像拉取、标记（Tag）、版本锁定与悬空镜像清理命令；
[ ] 掌握容器后台运行、端口映射、实时日志监听、终端接入与资源限制；
[ ] 建立命名数据卷（Volume）持久化机制，掌握数据备份与跨机迁移方法；
[ ] 掌握 docker system 资源分析，避免磁盘被历史镜像与日志填满；
[ ] 掌握容器秒退、端口无法访问、数据卷权限冲突等常见故障排查路径。

2、技术架构与机制对比

Docker vs 传统虚拟机 (KVM / VMware)

理解 Docker 的轻量特性，关键在于理解它与传统虚拟机的底层差异：

评估维度	传统虚拟机 (VM)	Docker 容器 (Container)
内核架构	运行完整的 Guest OS，虚拟化硬件层	共享宿主机 Linux 内核，基于 cgroups/namespaces 隔离
冷启动耗时	30 秒至 3 分钟（经历整套 OS 引导）	100 毫秒至 2 秒（拉起进程即可就绪）
内存额外开销	每台虚机独占 500MB 至 2GB 内存底噪	单容器内存底噪仅 10MB 至 50MB
磁盘镜像体积	几 GB 到数十 GB（含整套操作系统）	几十 MB（Alpine 镜像仅 5MB，精简 Node 约 150MB）
部署密度	1GB 内存 VPS 最多塞 1 台虚机	1GB 内存 VPS 可轻松并发运行 5 至 8 个业务容器

Docker 核心工作拓扑

3、实操步骤

3.1 生产级 Docker 安装与配置

直接运行官方提供的 get.docker.com 脚本虽然能安装成功，但在长期运行中存在严重隐患：

日志打爆硬盘：Docker 默认不对容器标准输出日志做体积限制，半年后单个 access.log 容器日志能吞噬数十 GB 磁盘空间，导致系统崩溃；
重载守护进程杀掉业务：默认配置下，重启或升级 Docker 服务会直接终止全部运行中的业务容器；
权限繁琐：每次操作都必须输入 sudo，极易与自动化部署脚本产生权限阻碍。

一键安装生产基线配置（推荐）

推荐使用 ITTinker 开源的生产环境安装脚本，内置日志限额（单容器 50MB、最多保留 3 个归档）、开启 live-restore（守护进程升级不杀容器）以及当前非 root 用户自动入组：

1 2	# 引用 ITTinker 开源运维工具快速完成生产级配置 curl -fsSL https://raw.githubusercontent.com/ittinker-team/ittinker-scripts/main/docker-quick-deploy/deploy.sh \| sudo bash

若无法直连 GitHub，可进入服务器本地克隆仓库执行：

1
2
3

git clone https://github.com/ittinker-team/ittinker-scripts.git
cd ittinker-scripts/docker-quick-deploy
sudo bash deploy.sh

手动配置验证与免 Sudo 设置

安装完成后，确保 /etc/docker/daemon.json 包含以下生产配置：

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "50m",
    "max-file": "3"
  },
  "live-restore": true
}

将当前普通开发运维用户加入 docker 组，避免后续反复敲 sudo：

# 将当前用户追加至 docker 组
sudo usermod -aG docker $USER

# 立即刷新当前终端的用户组（无需重新登录 SSH）
newgrp docker

# 验证免 sudo 是否生效
docker ps

3.2 镜像管理核心命令

镜像由一系列只读图层堆叠而成。掌握镜像的拉取、标记与分发是容器化运维的基本功。

# 1. 查找镜像：建议直接在 hub.docker.com 查阅官方镜像 (Official Image)
# 命令行搜索仅作辅助：
docker search --filter "is-official=true" nginx

# 2. 拉取镜像：生产环境严禁不加 tag 直接拉取，必须锁定版本
docker pull nginx:1.24-alpine
docker pull postgres:16-alpine
docker pull redis:7.2-alpine

# 3. 查看本地已下载镜像
docker images

# 4. 给镜像打上自定义标签（用于推送到私有仓库如 GitHub Packages 或 Docker Hub）
docker tag nginx:1.24-alpine myrepo/nginx:1.24

# 5. 查看镜像的分层构建细节与体积占比
docker history nginx:1.24-alpine

# 6. 删除本地无用的指定镜像
docker rmi nginx:1.24-alpine

# 7. 清理虚悬镜像（Dangling Images，即更新镜像后被冲掉 Tag 的 <none> 镜像）
docker image prune

3.3 容器全生命周期管理

容器是镜像的一个独立进程。生产环境中几乎所有操作都在围绕 docker run 与容器状态排查展开。

`docker run` 核心参数解析

参数	作用与规范	示例
`-d`	后台静默运行（Detached 模式），不占用当前终端会话	`docker run -d nginx`
`--name`	强制指定容器名称，杜绝系统随机生成无序别名	`--name web-server`
`-p`	端口映射 `宿主机端口:容器内监听端口`	`-p 8080:80`
`-v`	数据卷或主机目录挂载 `宿主目录:容器目录`	`-v db_data:/var/lib/mysql`
`-e`	注入运行时环境变量	`-e NODE_ENV=production`
`--restart`	重启策略：生产环境标准选 `unless-stopped`	`--restart unless-stopped`
`--memory`	内存上限限额，防止内存泄漏搞崩整台 VPS	`--memory 512m`
`--cpus`	CPU 核数上限限制	`--cpus 1.0`
`--rm`	容器停止后立即自动销毁，适合执行一次性迁移任务	`docker run --rm alpine ls`

常用容器管控指令

# 启动一个带有重启保护、内存限制的 Nginx 容器
docker run -d \
  --name web-app \
  -p 8080:80 \
  --memory 256m \
  --restart unless-stopped \
  nginx:1.24-alpine

# 查看当前运行中的容器
docker ps

# 查看全部容器（包含已退出、异常停止的容器）
docker ps -a

# 优雅停止容器（发送 SIGTERM 信号，默认给 10 秒处理收尾任务）
docker stop web-app

# 紧急强制终止容器（直接发送 SIGKILL 信号）
docker kill web-app

# 重新启动已存在的容器
docker start web-app

# 删除已停止的容器
docker rm web-app

# 强制删除正在运行中的容器（谨慎使用）
docker rm -f web-app

3.4 容器排查、进入与动态调试

当服务启动失败或响应异常时，必须通过日志与进程调试快速定位。

# 1. 实时跟踪容器输出的标准日志（类似 tail -f）
docker logs -f web-app

# 2. 只查看最后 100 行日志，并带上时间戳
docker logs --tail 100 -t web-app

# 3. 登录进入运行中的容器内部终端
# 首选 bash，若基于 alpine 等精简镜像则回退至 sh
docker exec -it web-app /bin/sh

# 4. 在容器外直接调用容器内命令（适合检查环境配置文件）
docker exec web-app cat /etc/nginx/conf.d/default.conf

# 5. 实时监控宿主机上全部容器的 CPU、内存、网络 IO 开销
docker stats

# 6. 查看容器的详细底层 JSON 元数据（IP、网关、挂载路径、环境变量）
docker inspect web-app

# 7. 过滤提取容器分配到的内网 IP 地址
docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' web-app

# 8. 宿主机与容器之间双向复制文件
# 将宿主机的配置文件拷进容器
docker cp ./my-site.conf web-app:/etc/nginx/conf.d/
# 将容器内的错误日志拉回宿主机
docker cp web-app:/var/log/nginx/error.log ./nginx-error.log

3.5 数据卷持久化：MySQL 8.0 生产级实战

容器本身是无状态、易失的。一旦执行 docker rm，写入容器读写层的文件将彻底丢失。数据库等有状态服务必须通过**数据卷（Volume）**隔离保存。

挂载方式对比

1
2
3

1. 命名卷 (Named Volume)  : -v mysql_data:/var/lib/mysql   -> 由 Docker 统一纳管，生产推荐
2. 绑定挂载 (Bind Mount)   : -v /opt/data:/var/lib/mysql    -> 直连宿主绝对路径，权限需自行调理
3. 匿名卷 (Anonymous)     : -v /var/lib/mysql              -> 易误删，无标识，强烈不推荐

实战演练：验证数据持久化

# 1. 创建命名的独立持久化卷
docker volume create mysql_data

# 2. 启动 MySQL 8.0 容器并挂载数据卷
docker run -d \
  --name prod-db \
  -p 3306:3306 \
  -e MYSQL_ROOT_PASSWORD=InitSecretPassword2026 \
  -e MYSQL_DATABASE=app_production \
  -v mysql_data:/var/lib/mysql \
  --restart unless-stopped \
  mysql:8.0

# 3. 等待启动完成后，进入数据库写入一条持久化测试数据
docker exec -i prod-db mysql -uroot -pInitSecretPassword2026 app_production <<'EOF'
CREATE TABLE test_log (id INT PRIMARY KEY AUTO_INCREMENT, note VARCHAR(50));
INSERT INTO test_log (note) VALUES ('Docker Volume Persistence Test');
EOF

# 4. 彻底销毁这个容器（模拟容器崩溃或版本升级）
docker rm -f prod-db

# 5. 重新启动一个全新的容器，再次挂载原有数据卷
docker run -d \
  --name prod-db-new \
  -p 3306:3306 \
  -e MYSQL_ROOT_PASSWORD=InitSecretPassword2026 \
  -v mysql_data:/var/lib/mysql \
  mysql:8.0

# 6. 查询验证数据是否存在
sleep 5
docker exec -i prod-db-new mysql -uroot -pInitSecretPassword2026 app_production -e "SELECT * FROM test_log;"

输出显示 Docker Volume Persistence Test，证明即便原容器被物理删除，业务数据毫发无伤。

数据卷备份与导出

把命名卷打包成压缩包备份到本地或异地对象存储：

# 利用临时 Alpine 容器挂载命名卷并打包输出到当前目录
docker run --rm \
  -v mysql_data:/volume_source:ro \
  -v $(pwd):/backup \
  alpine tar -czvf /backup/mysql_data_backup_$(date +%Y%m%d).tar.gz -C /volume_source .

3.6 磁盘空间清理防爆盘策略

长期迭代或持续构建的服务器，旧镜像和废弃构建缓存容易堆积。执行清理时必须区分安全命令与高危命令。

# 1. 检查 Docker 资源占用明细
docker system df

# 2. 安全清理：仅删除已经停止的容器、未被任何容器使用的网络、虚悬（dangling）镜像
docker system prune

# 3. 深度清理镜像：删除所有未被运行容器引用的镜像（慎用，会清空备用离线镜像）
docker image prune -a

# 4. 清理废弃数据卷（绝对高危！严禁在未确认的生产环境下直接执行）
# 如果未挂载的数据卷属于备份库，执行该命令会导致数据被永久物理删除
docker volume prune

4、生产命令速查表

操作领域	常用命令	核心功能说明
镜像操作	`docker pull <image>:<tag>`	从仓库拉取指定版本的镜像
	`docker images`	列出本地所有镜像与大小
	`docker rmi <image_id>`	删除指定本地镜像
	`docker image prune`	批量删除无标签悬空镜像
容器管控	`docker run -d --name <name> -p 80:80 <img:tag>`	后台创建并运行容器
	`docker ps`	列出当前正在运行的容器
	`docker ps -a`	列出所有状态的容器（含 Exit 状态）
	`docker stop <name>`	发送 SIGTERM 优雅停机
	`docker start <name>`	重新唤醒已停止容器
	`docker rm -f <name>`	强制停止并删除容器
排障调试	`docker logs -f --tail 100 <name>`	跟踪最近 100 行容器日志
	`docker exec -it <name> sh`	打开容器内部交互式终端
	`docker inspect <name>`	查看容器网络与存储等详细 JSON
	`docker stats`	监控各容器实时 CPU/内存利用率
数据与系统	`docker volume ls`	列出所有命名数据卷
	`docker cp <host_path> <name>:<container_path>`	宿主机与容器文件拷贝
	`docker system df`	分析容器、镜像占用的磁盘分布
	`docker system prune`	清除退出的容器与废弃缓存

5、生产避坑指南与排错清单

避坑 1：容器内应用仅绑定到 127.0.0.1 导致外部无法访问

现象：容器成功启动，docker ps 显示 0.0.0.0:8080->80/tcp，但从浏览器访问 http://<服务器IP>:8080 始终连接超时。
原因：容器内部的应用服务（如 Fastify、Flask、Django、Express）默认监听地址配置为了 127.0.0.1。在容器的网络命名空间下，这代表仅接受容器内部回环请求，宿主机网桥转发进来的包会被直接拒绝。
解法：修改应用监听配置，显式绑定到全零地址 0.0.0.0。

避坑 2：容器启动瞬间退出 (Exit 0 或 Exit 1)

原因：Docker 容器的生命周期与它的主进程（PID 1）严格绑定。若启动命令执行的是瞬时脚本（例如 echo "done"），主进程跑完容器立刻退出。

排查路径：

1 2	# 第一时间查看退出容器的最终输出 docker logs <container_id>

解法：如果是自定义镜像测试，确保前台有一个常驻进程（例如 Web 服务器前台运行、tail -f /dev/null 或 sleep infinity）。

避坑 3：挂载宿主机目录后出现 Permission Denied

原因：容器内通常使用特定低权限用户（例如 node 用户的 UID 为 1000，nginx UID 为 101）运行，若宿主机挂载的目录属主为 root 且权限为 755，容器进程无法写入数据。
解法：在宿主机上将挂载目录的属主赋予对应 UID，或者调整为容器需要的用户组：
1
sudo chown -R 1000:1000 ./data_folder

避坑 4：生产部署使用 `latest` 标签导致版本回滚灾难

原因：latest 不是动态指针，而是一个随时会被上游覆盖的临时别名。某天服务器重启拉取镜像，可能直接被升级到了存在破坏性更新的大版本。
解法：永远使用确定的小版本或 Git commit SHA 标签，例如 postgres:16.2-alpine、node:20.11-slim。

6、FAQ（高频疑难解答）

Q1：服务器重启后，如何确保容器自动恢复运行？

必须在创建容器时加上 --restart unless-stopped。Docker 守护进程会在开机自启后，自动恢复所有非手动停止的容器。若遗漏了该参数，可用更新命令补救：

1	docker update --restart unless-stopped <container_name>

Q2：Docker Compose 与单独运行 `docker run` 命令怎么选？

单个简单工具容器（如运行一次 Certbot 或跑一个临时的测试 Nginx）直接使用 docker run；只要涉及到「Web 服务 + 数据库 + 反代」等多容器依赖关系，或者需要持久化归档部署参数，一律编写 docker-compose.yml 统一部署。

Q3：在海外小配置 VPS 上，Docker 内存容易爆掉怎么防护？

在运行命令中设置 --memory 512m 硬限制；
为 VPS 创建 2GB 到 4GB 的物理 Swap 交换分区，避免被 Linux 内核 OOM Killer 强行抹杀主进程；
容器基础镜像优先选 alpine 或 slim 版本，避免使用体积庞大的全量 Ubuntu 底包。