Docker 基础镜像与中间件镜像

一、基础镜像（如 JDK）：自动拉取 + 分层整合，无需单独启动

以 adoptopenjdk:11-jdk-hotspot 为例，完整流程涵盖 “本地检查→自动拉取→分层整合”，核心是 Docker 帮你搞定依赖，无需手动操作：

1. 第一步：构建项目镜像时，Docker 自动处理基础镜像依赖

当你执行 docker build（Dockerfile 含 FROM adoptopenjdk:11-jdk-hotspot），Docker 会按以下逻辑执行：

• 先查本地：扫描 docker images 列表，判断是否有 adoptopenjdk:11-jdk-hotspot；
  • ✅ 本地已存在：直接复用基础镜像，跳过拉取，节省时间；
  • ❌ 本地不存在：自动从配置的镜像源（默认 Docker Hub，国内源如 dockerproxy.cn）拉取，拉取过程会在控制台显示（如 Pulling from library/adoptopenjdk），无需你手动执行 docker pull。
• 拉取后状态：本地会新增 adoptopenjdk:11-jdk-hotspot 镜像（可通过 docker images 查看），但它仅作为 “基础模板”，不会单独启动（无容器实例）。

2. 第二步：基础镜像与项目镜像的 “分层整合”（不是合并文件）

Docker 采用 “分层存储” 机制，将基础镜像和项目代码叠加成独立的项目镜像，具体逻辑：

层级类型	包含内容	作用
基础镜像层	JDK 11、系统库（如 Alpine Linux）、环境变量	提供 Java 运行的基础环境
项目层	复制的项目 JAR（如 demo.jar）、启动命令（CMD）	叠加项目代码和运行逻辑
最终项目镜像	基础层 + 项目层的所有内容	独立完整，可直接启动为容器

• 举例：构建 springboot-app:v1 项目镜像后，docker images 会显示两个镜像：

1. adoptopenjdk:11-jdk-hotspot（基础镜像，仅作模板）；

2. springboot-app:v1（项目镜像，包含 JDK 环境 + 项目代码）。

3. 关键特性：项目镜像运行不依赖基础镜像的 “单独存在”

即使后续删除 adoptopenjdk:11-jdk-hotspot 基础镜像（docker rmi adoptopenjdk:11-jdk-hotspot）：

• ✅ 已启动的项目容器：正常运行（容器启动时已加载所有分层内容，脱离原始镜像）；

• ✅ 未启动的项目镜像：仍可通过 docker run springboot-app:v1 启动（项目镜像包含完整环境）；

• ⚠️ “重新构建项目镜像” 无实质性影响：若后续修改代码重新执行 docker build，Docker 会检测到本地无基础镜像，自动重新拉取（无需你手动操作），最终仍能正常构建出新的项目镜像 —— 仅多了 “自动拉取” 的耗时（取决于网络速度），但不影响构建结果和现有项目。

二、中间件镜像（Redis、MQ、Kafka）：必须启动为容器，否则无法用

中间件的核心是 “提供网络服务”（如 Redis 存数据、MQ 传消息），而 “服务” 需要进程运行，因此必须启动为容器：

1. 为什么必须启动？看 “镜像” 与 “容器” 的本质区别

状态	本质	能否提供服务？
中间件镜像	只读模板（含程序文件）	❌ 不能：无运行进程，无法监听端口、接收请求
中间件容器	镜像的可运行实例	✅ 能：启动中间件进程（如 redis-server），监听默认端口（Redis 6379）

• 举例：Redis 镜像 redis:6 下载后，若不执行 docker run，你无法用 redis-cli 连接 —— 因为没有 Redis 进程在运行；只有启动 my-redis 容器后，才能通过 localhost:6379 访问。

2. 完整操作流程（以 Redis 为例，通用所有中间件）

# 1. 拉取镜像（本地无则自动拉取，和基础镜像逻辑一致）
docker pull redis:6

# 2. 启动容器（关键！启动服务端进程）
docker run -d --name my-redis -p 6379:6379 redis:6
# -d：后台运行，避免占用命令行；
# -p 6379:6379：主机端口→容器端口，外部（如项目）可通过 localhost:6379 访问；
# --name my-redis：给容器命名，方便管理（如停止用 docker stop my-redis）

# 3. 验证服务：用客户端连接（如 redis-cli）
redis-cli -h localhost -p 6379
# 输入 ping，返回 PONG 表示服务正常

3. 项目如何使用中间件容器？通过网络连接

以容器化的 Spring Boot 项目为例：

• 确保项目和中间件在同一 Docker 网络（如自定义网络 spring-redis-network）；
• 项目配置文件中，中间件地址写 “容器名 / 网络别名”（而非 localhost）：

spring:
  redis:
    host: my-redis  # 容器名（或 --network-alias 设置的别名，如 redis）
    port: 6379

• 原理：同一网络内，容器可通过名称互相通信，无需记 IP 地址。

三、核心对比：基础镜像 vs 中间件镜像（避免混淆）

对比维度	基础镜像（如 JDK）	中间件镜像（如 Redis）
核心作用	提供项目运行的基础环境（如 JVM）	提供独立的网络服务（如缓存、消息）
是否需要拉取	是（Docker 自动处理，重新构建时也会自动拉取）	是（Docker 自动处理，或手动 docker pull）
是否需要启动为容器	否（仅作模板，随项目容器启动而生效）	是（必须启动，否则无服务进程）
项目依赖方式	内置在项目镜像中（分层叠加）	项目容器通过网络连接（如 IP / 容器名）
删除后影响	无实质性影响（现有项目正常，重新构建自动拉取）	容器停止，项目无法连接服务

四、一句话总结关键逻辑

1. 基础镜像（JDK）：Docker 全程自动拉取 + 整合，删了也不影响现有项目，重新构建时会自己补下，几乎无需你操心；

2. 中间件镜像（Redis）：必须手动启动为容器才能用，停容器 = 停服务，这是和基础镜像最核心的区别。