Docker 核心概念详解：从“会用”到“真正理解”
前言
很多人第一次接触 Docker，通常是从几条命令开始的：
docker pull nginx
docker run -d -p 8080:80 nginx
docker ps
命令跑起来很快，页面也能访问，于是我们会觉得：Docker 好像就是一个“更轻量的虚拟机”。这个说法能帮助入门，但如果停在这里，后面遇到镜像构建、容器网络、数据持久化、线上排障时，很容易陷入一堆看似相似、实则完全不同的概念里。
本文尝试用深入浅出的方式，把 Docker 的核心概念串起来：镜像是什么，容器是什么，Dockerfile 在做什么，端口映射和容器网络有什么区别，数据卷为什么重要，以及 Compose 解决了什么问题。读完之后，你不一定能记住所有命令，但应该能建立一张清晰的“Docker 心智地图”。
一、Docker 解决的到底是什么问题
在没有容器之前，开发和部署经常会遇到一个经典问题：在我电脑上明明是好的，为什么到服务器上就不行了？
原因通常不在代码本身，而在运行环境：
- 本地是 JDK 17，服务器是 JDK 11
- 本地 MySQL 字符集是
utf8mb4，服务器不是 - 本地安装了某个系统库，线上没有
- 本地端口、目录权限、环境变量和线上不一致
传统做法是写部署文档，让运维或开发照着安装依赖。但文档很容易过期，也很难保证每台机器完全一致。
Docker 的核心思路是：把应用和它运行所需的环境一起打包，用标准方式运行。
也就是说，Docker 不只是“启动一个进程”，它更像是在回答三个问题：
- 我的应用依赖什么环境？
- 这个环境如何可重复构建？
- 这个应用如何在不同机器上以一致方式运行？
这就是 Docker 的价值：让环境变成可描述、可复制、可交付的产物。
二、镜像：应用运行环境的“模板”
镜像（Image）可以理解为一个只读模板，里面包含了应用运行所需要的文件系统、依赖、配置和启动命令。
比如一个 Java 应用的镜像里可能包含：
- Linux 基础文件系统
- JRE 或 JDK
- 应用的 jar 包
- 启动命令
- 默认环境变量
一个 Nginx 镜像里可能包含：
- Nginx 程序
- 默认配置文件
- 静态资源目录
- 默认启动入口
可以把镜像想象成“菜谱 + 预处理好的食材包”。它本身不会运行，但它定义了运行时应该拥有什么。
2.1 镜像是分层的
Docker 镜像最重要的特点之一是：分层存储。
例如一个 Dockerfile：
FROM eclipse-temurin:17-jre
WORKDIR /app
COPY target/demo.jar app.jar
ENTRYPOINT ["java", "-jar", "app.jar"]
每一条构建指令大致都会形成一层：
FROM引入基础镜像层WORKDIR设置工作目录COPY复制应用文件ENTRYPOINT定义启动命令
分层带来两个好处。
第一是复用。多个镜像如果基于同一个基础镜像，它们可以共享底层数据，不需要每个镜像都完整复制一份。
第二是缓存。构建镜像时，如果前面的层没有变化，Docker 可以直接使用缓存，从而加快构建速度。
这也是为什么 Dockerfile 里通常会把“不经常变化的步骤”放前面，把“经常变化的业务代码”放后面。
2.2 镜像不是容器
镜像和容器最容易混淆。
一句话区分：
- 镜像是静态模板
- 容器是镜像运行起来之后的实例
就像类和对象的关系：
镜像 Image -> class
容器 Container -> object
同一个镜像可以启动多个容器，每个容器有自己的进程、网络、文件系统读写层和运行状态。
三、容器：被隔离的进程
容器（Container）本质上不是一台真正的虚拟机，而是一个被隔离起来的进程。
它和普通进程一样运行在宿主机操作系统之上，只是 Docker 借助 Linux 的能力，为它提供了隔离环境。
两个关键机制是：
- Namespace：隔离进程、网络、挂载点、用户等视图
- Cgroups：限制 CPU、内存、IO 等资源使用
所以容器看起来像一台独立机器：有自己的进程列表，有自己的网络地址，有自己的文件系统。但它并没有像虚拟机那样启动完整操作系统内核。
3.1 容器为什么轻量
虚拟机通常需要：
- 虚拟硬件
- 完整操作系统
- 独立内核
- 较长启动时间
容器通常只需要：
- 应用进程
- 必要依赖
- 与宿主机共享内核
因此容器启动很快，占用资源也更少。
不过也要注意：容器不是万能隔离。它共享宿主机内核，所以安全边界和虚拟机不同。生产环境中仍然需要控制权限、限制资源、避免使用过高权限运行容器。
3.2 容器的生命周期
一个容器通常会经历这些状态：
创建 -> 运行 -> 停止 -> 删除
常见命令：
docker create nginx
docker start <container>
docker stop <container>
docker rm <container>
而 docker run 其实是组合命令，大致等价于：
docker pull + docker create + docker start
这也是为什么初学时觉得 docker run 很神奇：它背后做了好几件事。
四、仓库：镜像的分发中心
仓库（Registry）用于存储和分发镜像。最常见的是 Docker Hub，也可以搭建企业内部私有仓库。
常见命令：
docker pull nginx:latest
docker push your-registry/demo-app:1.0.0
这里有三个容易混淆的词：
| 概念 | 说明 | 示例 |
|---|---|---|
| Registry | 镜像仓库服务 | Docker Hub、Harbor |
| Repository | 某一类镜像的集合 | nginx、mysql、demo-app |
| Tag | 镜像版本标识 | latest、1.0.0、jdk17 |
nginx:1.25 里的 nginx 是仓库名，1.25 是标签。
不要迷信 latest
latest 不是“最新版本”的严格保证，它只是一个普通标签。镜像维护者可以让它指向任意版本。
生产环境建议使用明确版本：
nginx:1.25.5
mysql:8.0.36
redis:7.2.4
这样部署结果更可控，也更容易回滚。
五、Dockerfile：把环境写成代码
Dockerfile 是构建镜像的说明书。它把“如何准备运行环境”写成可执行步骤。
一个典型 Java 应用 Dockerfile：
FROM eclipse-temurin:17-jreWORKDIR /appCOPY target/demo.jar app.jarEXPOSE 8080ENTRYPOINT ["java", "-jar", "app.jar"]
逐行解释：
FROM：选择基础镜像WORKDIR：设置工作目录COPY：把构建产物放进镜像EXPOSE：声明应用监听端口ENTRYPOINT：定义容器启动时执行的命令
5.1 CMD 和 ENTRYPOINT 的区别
CMD 和 ENTRYPOINT 都和容器启动命令有关，但语义不同。
ENTRYPOINT 更像“固定主程序”：
ENTRYPOINT ["java", "-jar", "app.jar"]
CMD 更像“默认参数”：
ENTRYPOINT ["java", "-jar", "app.jar"]
CMD ["--spring.profiles.active=prod"]
运行时可以覆盖 CMD：
docker run demo-app --spring.profiles.active=test
实践中，如果镜像就是为了运行某个固定应用，通常使用 ENTRYPOINT；如果希望用户很方便地替换默认命令，可以使用 CMD。
5.2 构建上下文
执行构建命令时：
docker build -t demo-app:1.0 .
最后的 . 代表构建上下文。Docker 只能访问上下文目录里的文件。
如果项目很大，构建上下文也会很大，上传给 Docker daemon 的时间会变长。因此要使用 .dockerignore 排除无关文件：
.git
target
logs
*.md
对 Java 项目来说，如果已经在宿主机完成构建，只需要把最终 jar 包复制进镜像，就不要把整个源码目录都塞进上下文。
六、端口映射：容器内外如何通信
容器有自己的网络命名空间。应用在容器内监听 8080，并不意味着宿主机的 8080 也能访问。
需要端口映射：
docker run -p 8080:80 nginx
含义是：
宿主机 8080 端口 -> 容器 80 端口
所以访问：
http://localhost:8080
实际请求会被转发到容器内的 80 端口。
6.1 EXPOSE 不等于发布端口
Dockerfile 里的：
EXPOSE 8080
只是声明容器内部应用默认监听哪个端口。它不会自动把端口暴露到宿主机。
真正发布端口需要 -p：
docker run -p 8080:8080 demo-app
可以这样理解：
EXPOSE是文档和元信息-p才是真正的端口映射
七、容器网络：服务之间如何互相找到
如果只有一个容器，端口映射就够了。但真实应用往往包含多个服务：
- Web 应用
- MySQL
- Redis
- MQ
容器之间不建议通过宿主机端口绕一圈访问，而应该加入同一个 Docker 网络，通过容器名或服务名访问。
创建网络：
docker network create app-net
启动 MySQL：
docker run -d --name mysql --network app-net mysql:8.0
启动应用：
docker run -d --name app --network app-net demo-app:1.0
此时应用里可以使用：
jdbc:mysql://mysql:3306/demo
这里的 mysql 是容器名，Docker 内置 DNS 会帮你解析。
7.1 常见网络模式
| 网络模式 | 说明 | 常见场景 |
|---|---|---|
| bridge | 默认桥接网络 | 单机多容器 |
| host | 直接使用宿主机网络 | 对网络性能或端口有特殊要求 |
| none | 不配置网络 | 极少数隔离场景 |
大多数普通应用使用 bridge 网络就够了。
八、数据卷：容器为什么不能当数据库硬盘
容器删除后，容器自身读写层里的数据也会一起消失。
这对无状态应用没问题，但对数据库、上传文件、日志等数据来说很危险。
错误示例：
docker run -d --name mysql mysql:8.0
这样 MySQL 数据默认写在容器内部。容器一旦删除，数据就没了。
正确做法是使用数据卷：
docker run -d \--name mysql \-v mysql-data:/var/lib/mysql \mysql:8.0
含义是：
Docker volume mysql-data -> 容器内 /var/lib/mysql
容器可以删除、重建，但数据卷仍然存在。
8.1 volume 和 bind mount
Docker 常见挂载方式有两种：
| 方式 | 示例 | 特点 |
|---|---|---|
| volume | -v mysql-data:/var/lib/mysql |
Docker 管理，适合持久化数据 |
| bind mount | -v /host/logs:/app/logs |
指定宿主机目录，适合开发调试或日志落盘 |
生产环境中，数据库数据更推荐使用 volume 或专业存储方案；开发环境中，bind mount 用起来更直观。
九、环境变量：配置不要写死在镜像里
镜像应该尽量保持通用，不要把环境相关配置写死进去。
比如数据库地址、用户名、密码、运行环境，最好通过环境变量传入：
docker run -d \-e SPRING_PROFILES_ACTIVE=prod \-e DB_HOST=mysql \demo-app:1.0
Spring Boot 中可以读取：
spring.datasource.url=jdbc:mysql://${DB_HOST}:3306/demo
这样同一个镜像可以部署到开发、测试、生产环境，只需要注入不同配置。
注意：环境变量虽然方便，但敏感信息仍然要谨慎管理。生产环境更推荐使用平台提供的 Secret 管理能力，而不是把密码明文写在命令行或脚本里。
十、Docker Compose：把多容器应用写成一份配置
当应用只有一个容器时，docker run 还算清晰。
但如果有应用、MySQL、Redis、Nginx，再加上网络、数据卷、环境变量，命令会变得很长，也很难维护。
Docker Compose 用一份 compose.yaml 描述多容器应用：
services:app:image: demo-app:1.0ports:- "8080:8080"environment:DB_HOST: mysqlREDIS_HOST: redisdepends_on:- mysql- redismysql:image: mysql:8.0environment:MYSQL_ROOT_PASSWORD: rootMYSQL_DATABASE: demovolumes:- mysql-data:/var/lib/mysqlredis:image: redis:7.2volumes:mysql-data:
启动：
docker compose up -d
停止：
docker compose down
Compose 解决的不是“单个容器怎么跑”，而是“一个小系统如何用可读、可维护的方式跑起来”。
depends_on 不等于服务就绪
depends_on 只能保证启动顺序，不能保证 MySQL 已经可以接收连接。
真实项目中，应用仍然应该具备重试能力，或者结合健康检查：
healthcheck:test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]interval: 5stimeout: 3sretries: 10
十一、Docker 的一条主线
到这里，核心概念可以串成一条主线：
Dockerfile 描述如何构建环境↓
docker build 生成镜像↓
镜像 push 到仓库↓
服务器 pull 镜像↓
docker run / compose up 启动容器↓
通过网络、端口、数据卷、环境变量完成真实运行
理解这条线，就不容易被命令细节绕晕。
十二、常见误区
误区 1：容器就是虚拟机
容器不是虚拟机。容器是被隔离和限制的进程，和宿主机共享内核。它更轻量，但安全边界也不同。
误区 2：镜像越大越好，反正能跑
镜像越大，构建、传输、扫描、启动都可能变慢。生产镜像应该尽量只包含运行所需内容。
对于 Java 应用，可以考虑使用 JRE 镜像而不是完整 JDK 镜像；对于 Go 应用，可以使用多阶段构建生成更小镜像。
误区 3：容器里改了文件，就等于镜像改了
容器运行后的修改只存在于容器读写层，不会反向修改镜像。
如果想固化变更，应该修改 Dockerfile 后重新构建镜像，而不是手工进入容器改文件。
误区 4：删除容器不会影响数据
如果数据写在容器内部，删除容器就会丢。数据库、上传文件、持久化日志要使用 volume 或挂载宿主机目录。
误区 5：能用 docker run 就不需要 Compose
单容器可以用 docker run，多容器系统建议使用 Compose。它能让环境、网络、数据卷和依赖关系变成可维护的配置。
十三、实战建议
1. 镜像使用明确版本
生产环境少用 latest，使用明确版本号，方便追踪和回滚。
2. Dockerfile 保持可重复构建
不要依赖手工进入容器修改。所有环境准备步骤都应该写进 Dockerfile 或构建流程。
3. 应用配置外置
镜像里放应用，环境变量或配置中心里放环境差异。这样同一个镜像可以跑在多个环境。
4. 数据必须明确持久化
数据库、对象存储模拟目录、上传文件目录，都要明确挂载。不要默认相信容器内部文件系统。
5. 容器只运行一个主要进程
一个容器最好只负责一个主要职责。Web、MySQL、Redis 应该是不同容器，而不是全部塞进一个容器里。
6. 日志输出到标准输出
容器化应用更推荐把日志输出到 stdout/stderr，由 Docker 或平台统一采集，而不是只写在容器内部文件里。
总结
Docker 的核心概念并不复杂，但它们之间的边界很重要：
- 镜像是只读模板
- 容器是运行中的实例，本质是被隔离的进程
- Dockerfile 用来描述镜像如何构建
- Registry 用来分发镜像
- 端口映射解决外部访问容器的问题
- Docker 网络解决容器之间互相访问的问题
- 数据卷解决数据持久化问题
- 环境变量解决配置外置问题
- Compose 解决多容器应用编排问题
如果只记一句话：Docker 的本质不是“把应用跑起来”，而是把应用运行环境标准化、镜像化、可复制化。
当你理解了镜像、容器、网络、数据卷这几个核心概念，再看各种 Docker 命令，就不再是一堆零散参数，而是围绕“构建、分发、运行、连接、持久化”展开的一套完整体系。