企业官网建设流程全解析

Docker 用了这么多年，被问得最多的往往不是“怎么安装”，而是“装完了，下一步敲什么”。说实话，Docker 的单条指令并不难，难的是脑子里缺一张命令地图：什么时候该拉镜像，什么时候该起容器，容器起来之后怎么进去改配置、怎么拷贝文件、怎么把玩坏的容器删掉重来。这篇 Docker 常用指令速查手册，就是按这个思路整理的。不管你是在 Windows 上刚把 Docker Desktop 装起来的新手，还是从微服务、K8s 方向转过来想补容器基础的同学，把这套指令捋顺了，至少能少走七八成弯路。

先说明一下，这份手册不是照搬官方文档，而是我这些年实际操作中“用得多、踩过坑、回头查”的命令集合。每条命令我都会交代它为什么存在、什么时候用、有什么容易翻车的地方。毕竟容器这东西，真正降低心智负担的不是命令本身，而是你对“镜像、容器、网络、数据卷”这几个概念的理解方式。

1. 先建立一张 Docker 命令心智图

1.1 镜像、容器、仓库到底在说什么

很多人一开始学 Docker 就被这三个词绕晕。我习惯用一个比方：镜像就像是装系统的安装光盘或者模板，它只负责定义“这个环境里预装了什么、默认执行什么”；容器就是拿这张光盘启动出来的“正在运行的机器”，同一个光盘可以启动多台机器，每台机器的运行时状态互不影响；仓库就是专门放光盘的公共货架，你要用哪个镜像，就从货架上取下来（pull），用完了还可以把改动重新打包成新镜像（push）放上去。

把这三个概念区分开，Docker 的指令其实就分成了三条线：管镜像的、管容器的、管仓库的。再加上数据卷、网络、Compose 编排这几条辅助线，整张命令地图就清晰了。

1.2 命令格式与帮助信息是最后的救命稻草

任何命令吃不准时，最先该敲的不是搜索引擎，而是帮助信息：

docker --help docker run --help docker compose --help

docker --help会列出所有一级子命令，docker run --help则告诉你某个具体命令支持哪些参数。我这些年养成的习惯是：想不起来参数，先--help；连不上服务，先docker version和docker info。这两个命令能很快定位是客户端问题还是服务端问题。比如 Windows 上 Docker Desktop 启动失败时，docker version通常会出现“客户端正常、服务端连不上”的提示，问题基本就锁定在后台引擎没起来，而不是你命令敲错了。

另外，docker info能看到 Docker 的存储驱动、镜像数量、容器数量、是否开启了 Swarm 模式等信息，排查环境问题时的价值很高。

2. 镜像管理：先有好料，才能做好菜

2.1 拉取镜像：从仓库拿东西的几种姿势

最常用的三条命令：

docker search mysql docker pull mysql:8.0 docker pull mysql

docker search用于在镜像仓库里搜索可用镜像，适合不确定有没有官方镜像时快速确认。docker pull则是把指定镜像拉到本地。这里必须提醒一句：默认的latest标签是个“移动靶”。同一个latest，今天拉的版本和一个月后拉的版本可能完全不同。凡是用于生产环境或有明确版本依赖的场景，都建议显式指定版本号，比如mysql:8.0.40、redis:7.4、ubuntu:22.04，这样后续排障能复现、能回溯。

再补一个细节：如果你的机器是 ARM 架构（比如苹果的 M 系列芯片、树莓派），或者反过来是 x86 架构，默认拉取的是当前平台对应的镜像。万一在 ARM 机器上拉了一个只有 x86 的镜像，运行时会报exec format error。遇到这种情况，可以用docker manifest inspect查看镜像支持的平台列表，然后按需加--platform参数，例如：

docker pull --platform linux/amd64 openjdk:17

2.2 查看与清理本地镜像

docker images docker image ls -a docker inspect 镜像ID docker rmi 镜像ID或镜像名

docker images是最常用的列出本地镜像的命令，能看到仓库名、标签、镜像ID、创建时间和大小。docker image ls -a会额外显示中间层镜像，排查磁盘占用时很有用。docker inspect用于查看镜像或容器的底层 JSON 配置，包括环境变量、EntryPoint、暴露端口等，这个命令排障时经常用到。

清理镜像用docker rmi，但要注意：如果某个镜像还有容器在用（即使是已停止的容器），直接删会报错。解决方案是先找到关联容器，删掉或清理掉容器后再删镜像。批量清理悬空镜像（没有标签且没有被容器引用的镜像）可以用：

docker image prune

加-a会删除所有未被使用的镜像，清理效果更强，但要把本地重要镜像先确认一遍，别误删。

2.3 构建与导入导出：让镜像能复现、能迁移

docker build -t myapp:1.0 . docker commit 容器ID myapp:1.0 docker save -o myapp.tar myapp:1.0 docker load -i myapp.tar

docker build是基于 Dockerfile 构建镜像，这是推荐方式，因为 Dockerfile 记录了构建步骤，别人拿到就能复现。docker commit是把一个正在运行的容器的当前状态打包成新镜像，应急时有用，但不推荐作为日常构建手段——它相当于把“手工改过的系统”直接做成了镜像，后期根本说不清里面改了什么。

docker save和docker load是“打包镜像文件 + 导入镜像”的组合，适用于内网环境离线迁移，比如你在测试机上构建好镜像，拷到生产机上load进去。

3. 容器生命周期：跑起来、看状态、清理掉

3.1 用 docker run 起一个容器：参数是你和 Docker 的“合同”

docker run -d --name mysql8 -p 3306:3306 -e MYSQL_ROOT_PASSWORD=123456 -v /data/mysql:/var/lib/mysql mysql:8.0

这条命令是上手最常用的组合式命令。拆开看：

• -d：后台运行，而不是卡在前台刷日志。不加-d的话，Ctrl+C 退出时容器也会被终止。
• --name：给容器起个固定名字，后续操作都免去查容器ID的麻烦。
• -p 宿主机端口:容器端口：把容器内端口映射到宿主机。外部访问3306时，实际连的是宿主机端口，再由 Docker 转发给容器。
• -e：传入环境变量。MySQL 镜像正是靠MYSQL_ROOT_PASSWORD来初始化 root 密码的，不同镜像的-e参数差异很大，用之前先看镜像文档。
• -v 宿主机目录:容器目录：挂载数据卷。这是容器数据持久化的核心，我把数据卷单独放在后一章节细讲。

排障时还有一个常用参数--rm：容器停止后自动删除，适合临时跑测试命令或调试工具。

docker run --rm -it ubuntu:22.04 bash

这条命令启动一个 Ubuntu 容器并直接进入交互式 shell，退出后容器自动删掉，不留垃圾。对只想“临时体验下某个镜像”的场景非常好用。

3.2 查看容器状态：docker ps 不只是列列表

docker ps docker ps -a docker stats

docker ps只看正在运行的容器，docker ps -a连已退出的也显示。已停止的容器不会自动消失，会一直占用磁盘空间，这也是为什么很多人用了一阵 Docker，磁盘莫名被占满。docker stats实时显示每个容器的 CPU、内存、网络和磁盘 IO 占用，排查“哪只容器拖垮了宿主机”时非常直观。

有一类常见误区是：容器状态是 Exited 但不明白为什么退出。这时要看退出码和日志，而不是反复docker start。退出码 0 表示正常结束，137 多半是被 OOM Kill 或手动 Kill，1 或非 0 要看应用日志。

3.3 进入容器内部：exec 和 attach 的区别

docker exec -it 容器名 bash docker attach 容器名

docker exec是在运行中的容器里额外启动一个进程，比如启动一个 bash。它的特点是：在 bash 里敲exit，只是退出这个交互进程，不会影响容器本身。而docker attach是连接到容器的主进程，直接看主进程的标准输入输出，按 Ctrl+C 很可能会把容器主进程也杀掉。日常调试我基本只用exec，不太碰attach。容器里没装 bash 的，可以试试sh：

docker exec -it nginx sh

另外，调试前建议先看日志：

docker logs -f 容器名

-f是 follow 模式，持续跟踪日志输出，和tail -f效果差不多。

3.4 停止、启动、删除：别让容器堆积成山

docker stop 容器名 docker start 容器名 docker restart 容器名 docker rm 容器名 docker rm -f 容器名

停止和删除是两个动作。docker stop给容器发停止信号，容器可以安全收尾；docker rm是删除容器文件，已停止的容器也会占磁盘空间。docker rm -f是强制停止并删除，慎用。批量清理场景比较常用的一组命令：

docker stop $(docker ps -q) # 停止所有容器 docker rm $(docker ps -aq) # 删除所有容器（包括已退出）

把命令组合嵌套在$( )里是 Shell 基本功，初次接触的读者可以理解成“先执行括号里的，把结果当参数传给外层命令”。

3.5 资源限制：别让一只容器吃掉整台机器

docker run -d --name app --cpus 1.5 -m 1g nginx

--cpus限制容器最多使用几个 CPU 核心，-m限制最大内存。在很多小主机或旧机器上（比如 N100 这种低功耗平台），同时跑十几个容器时，资源限制就特别重要。不限制的话，任何一个容器内存泄漏都可能把宿主机拖到 SSH 都连不上。经验值：每个容器先给-m 512m或-m 1g，看监控再调整，而不是一开始就放开跑。

4. 数据卷与网络：容器最容易被忽略的两块

4.1 数据卷：容器删了，数据不能跟着没

容器的文件系统是“临时”的。容器被删除后，内部产生的文件默认会跟着容器一起消失。所以凡是数据库、日志、配置、上传文件这一类需要长期保存的数据，都要通过数据卷挂载到宿主机目录。

docker run -d --name mysql8 -v /data/mysql:/var/lib/mysql mysql:8.0

/data/mysql是宿主机目录，/var/lib/mysql是容器内 MySQL 的数据目录。容器删了重建，只要挂载同一个宿主机目录，数据就还在。这就是“删容器不删数据”的机制。除了刚才用的绝对路径挂载方式，Docker 还提供“具名卷”：

docker volume create mysql-data docker run -d --name mysql8 -v mysql-data:/var/lib/mysql mysql:8.0

具名卷的好处是目录由 Docker 统一管理，不用关心宿主机上的具体路径，备份和迁移也方便。两个容器需要共享数据时，可以同时挂载同一个卷或同一个宿主机目录。日常我建议：临时测试用绝对路径挂载，正式项目用具名卷，因为具名卷配合docker compose管理更顺手。

4.2 自定义网络：容器之间通信的正确姿势

默认情况下，Docker 创建一个叫bridge的桥接网络，所有容器都在这个网络里，可以互相访问，但依赖动态分配的 IP，容器重启后 IP 可能变化。跨主机或需要稳定访问时，更好的做法是创建自定义网络：

docker network create app-net docker run -d --name redis --network app-net redis:7.4 docker run -d --name app --network app-net myapp:1.0

在同一个自定义网络里，容器可以直接用“容器名”作为主机名互相访问。app 容器访问 redis 时，直接连redis:6379即可，不再依赖动态 IP。这个特性在搭建 Redis 主从、微服务集群等场景下非常实用。另外，--network host模式会让容器直接使用宿主机网络，没有独立 IP，通常不建议，除非你对网络性能有极端要求或者容器本身需要监听大量随机端口。

4.3 端口映射与网络排查常用命令

docker port 容器名 docker network inspect app-net

docker port查看容器的端口映射关系，docker network inspect查看网络里所有容器的 IP、网关等信息，排查网络问题时这两条命令很有用。进入容器后，优先用curl或wget测试连通性，因为很多精简镜像里连ping都没装，第一反应是ping不通就判定网络有问题，往往会把排查方向带偏。

5. 编排与运维：从单容器走向一整套服务

5.1 Docker Compose：用一份 YAML 管一整套服务

单容器用docker run足够，但一个项目往往要同时跑 MySQL、Redis、后端应用、前端等多个容器。逐条敲docker run不仅容易漏参数，且没法统一管理。Docker Compose 就是干这个的：把服务定义写在一个docker-compose.yml里，一条命令拉起所有服务。

一个非常典型的最小示例：

services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: 123456 volumes: - mysql-data:/var/lib/mysql ports: - "3306:3306" backend: build: ./backend ports: - "8080:8080" depends_on: - mysql volumes: mysql-data:

核心命令：

docker compose up -d docker compose down docker compose ps docker compose logs -f docker compose config

up -d按 YAML 定义创建并启动服务，down停止并删除容器和网络。config用于校验 YAML 语法和最终解析结果，改动配置后建议先跑一遍，能省不少启动报错的排查时间。depends_on只控制启动顺序，不保证依赖服务“已就绪”，比如 MySQL 容器起来了但初始化还没完成，后端可能连接失败。生产环境需要更可靠的等待逻辑，比如健康检查。

新版 Docker 已经内置 Compose 插件，所以直接docker compose，不需要单独安装docker-compose。

5.2 日常运维：日志、监控、磁盘清理

docker logs -f 服务名 docker stats docker system df docker system prune -a

docker system df能统计镜像、容器、数据卷和构建缓存各占了多少磁盘空间，是我排查“磁盘满了”问题的第一站。docker system prune -a会清理所有未使用的镜像、容器、网络和构建缓存，清理效果非常明显，但前提是你确认不再需要这些内容。注意，清理不包含“正在使用”的镜像和容器，所以相对安全，但构建缓存删了之后下次构建会变慢，需要权衡。

顺手提醒一个在 Windows 上很常见的问题：Docker Desktop 的磁盘占用会越来越大，因为 WSL2 的虚拟磁盘文件（ext4.vhdx）只会膨胀不会自动收缩。即使你各种prune，磁盘占用可能还是高。这时候需要手动压缩 vhdx 文件，方法是在 PowerShell 里执行wsl --shutdown，然后用diskpart或Optimize-VHD压缩。这类操作建议搜一下当前版本的具体步骤，但核心思路是“先停 WSL，再收缩磁盘”。

5.3 进阶场景：GPU 容器与构建辅助

需要跑深度学习或大模型推理镜像时，常在docker run里加：

docker run --gpus all --ipc=host --name vllm-server vllm/vllm-openai:v0.27.1

--gpus all让容器访问宿主机所有 GPU 设备。前提是宿主机已经装好 NVIDIA 驱动以及 nvidia-container-toolkit，否则会报找不到 GPU 设备。--ipc=host在部分 PyTorch 推理场景下能避免共享内存不足的报错。这类镜像通常体积很大，首次拉取建议预留足够磁盘空间。

打包镜像时，除了命令行docker build，在 IntelliJ IDEA 里可以借助 Docker 插件直接在 IDE 中构建和推送镜像，适合 Java 项目。但底线一样：最终绕不开 Dockerfile 的编写质量。

6. 常见问题排查与避坑速查

6.1 Docker Desktop 启动失败：virtualization support not detected

Windows 上启动 Docker Desktop 最常见的报错是 “Docker Desktop failed to start because virtualisation support wasn‘t detected”。这通常不是 Docker 本身的问题，而是虚拟化能力没开或没生效。排查路径按顺序来：

1. 进 BIOS/UEFI，确认 CPU 虚拟化（Intel VT-x 或 AMD SVM）已开启。
2. 检查“启用或关闭 Windows 功能”里，Hyper-V和适用于 Linux 的 Windows 子系统（WSL2）是否勾选。
3. 确认默认版本是 WSL2，可在 PowerShell 执行wsl --set-default-version 2。
4. 如果电脑里装了 VMware 或 VirtualBox，注意它们和 Hyper-V 可能冲突，必要时按官方文档调整。

大部分“启动 Docker 失败”的报错，按这个顺序排查基本都能解决。如果你机器上确实关着 Hyper-V，那docker version会提示连接不上服务端，问题同样指向这里。

6.2 Permission denied while trying to connect to the Docker API

Linux 上不加sudo执行docker ps报权限错误，原因是一般用户不在docker用户组内。解决办法：

sudo usermod -aG docker $USER newgrp docker

newgrp docker让当前会话立即生效，免去重新登录。这里提醒一句：加入 docker 组相当于获得近似 root 的权限，因为 Docker 可以挂载宿主机目录，所以只给可信用户加组，别图省事给所有人都放进去。

6.3 服务启动失败：failed to start docker application container engine

这类报错往往出现在 Docker 引擎启动阶段。先说排查思路：先看引擎日志。Linux 上通常是

systemctl status docker journalctl -u docker -n 100

常见原因包括：磁盘空间不足、iptables 规则冲突、之前异常退出导致的数据损坏。如果日志里出现bridge-nf-call-iptables相关问题，通常是防火墙或内核网络参数配置导致，需要检查宿主机的/etc/sysctl.conf和 iptables 规则。这类问题环境相关性强，日志是关键，别靠猜。

6.4 镜像拉取慢或下载失败

拉镜像卡在等待输出时，大概率是网络到默认镜像仓库的链路不够顺畅。常见优化手段：

1. 在 Docker Desktop 的 Settings 或/etc/docker/daemon.json里配置可用的镜像加速地址，Windows 上直接修改配置文件后重启引擎。
2. 拉取时加--platform参数，避免拉取到不需要的多架构镜像，减少传输量。
3. 检查下Docker Desktop是不是处于运行状态，以及本地 DNS 是否正常。DNS 解析异常也会导致拉取超时。

注意，改daemon.json后必须重启 Docker 引擎才生效。Linux 上执行systemctl restart docker，Windows 上重启 Docker Desktop 即可。

6.5 容器内网络不通

一条典型排查路径：

1. docker ps确认容器状态是 Up。
2. docker exec -it 容器名 sh进入容器，curl目标地址。
3. 如果目标在另一个容器里，确认两个容器是否在同一个自定义网络内。默认 bridge 里也可以用 IP 访问，但 IP 重启后会变化。
4. docker inspect 容器名查看网络信息，确认 IP、网关、网络模式。

有个特别容易踩的坑：默认 bridge 网络里的容器，可以通过--link相互访问，但--link是老机制，新项目一律建议用自定义网络。我见过很多 redis 主从搭不起来，最后发现是容器在不同网络里，互相连不上。

6.6 容器频繁重启或退出码异常

容器一直重启，最有效的工具是日志：

docker logs 容器名

退出码 137 大概率是内存超限被系统杀掉，先在docker stats看实际占用，再调整-m限制。应用本身报错的，比如数据库初始化失败、配置文件路径不对，日志里会直接显示，之后修正配置重建容器即可。容器如果配置了--restart=always但本身一直报错，会产生高频重启，建议先去掉该参数调试，稳定后再加。

6.7 磁盘占用突然异常上升

docker system df看哪些对象占空间，通常是这三类：悬空镜像、构建缓存、旧容器可写层。处理方式：

docker image prune -a docker builder prune docker container prune

以上都属于清理类命令，执行前确认容器和数据卷都被正确挂载和备份。数据卷占用的空间通过prune不会清理，需要手动删卷，比如docker volume prune。但删卷等于彻底删数据，务必先备份。

最后，分享一点我自己的日常习惯

用了几年 Docker，我慢慢形成的纪律是：构建镜像一律走 Dockerfile，绝不用docker commit做“快照镜像”；凡是有状态的服务，一律挂数据卷，绝不依赖容器可写层；多容器项目无论多简单都上 Compose，哪怕只是两个服务。这样做的最大好处是“可重来”——删掉重建、换机器部署，都只是一条命令的事，不会因为某个容器的临时状态被绑死。

另外，我习惯在 Shell 里加几条 alias，日常操作会顺手很多：

alias dps='docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"' alias dlogs='docker logs -f --tail 100' alias dprune='docker system prune -a --volumes'

这几条别名看着简单，但每天能省下很多重复输入的时间。如果你刚开始接触 Docker，建议先把pull/run/ps/exec/logs/rm这六条命令练熟，再慢慢扩展；等遇到真实项目时，Compose、网络、数据卷这些内容自然会串起来。