文章目录
- [Docker 镜像的两种创建方式](#Docker 镜像的两种创建方式)
-
- [一、快捷创建镜像方式一：docker commit](#一、快捷创建镜像方式一：docker commit)
-
- [1. 语法](#1. 语法)
- [2. 参数](#2. 参数)
- [3. 示例](#3. 示例)
- [4. 特点](#4. 特点)
- [二、标准创建镜像方式二：docker build](#二、标准创建镜像方式二：docker build)
-
- [1. 语法](#1. 语法)
- [Dockerfile 常用指令表格](#Dockerfile 常用指令表格)
-
- [补充：CMD 和 ENTRYPOINT 的区别](#补充：CMD 和 ENTRYPOINT 的区别)
- [补充：RUN 和 CMD 的区别](#补充：RUN 和 CMD 的区别)
- [2. 示例](#2. 示例)
- [3. 特点](#3. 特点)
- [三、docker commit 和 docker build 的区别](#三、docker commit 和 docker build 的区别)
- 四、总结
Docker 镜像的两种创建方式
一、快捷创建镜像方式一：docker commit
直接使用 docker commit 将容器的文件系统变更保存为一个新的镜像。
1. 语法
bash
docker commit [OPTIONS] CONTAINER [REPOSITORY[:TAG]]2. 参数
-a：指定提交的镜像作者。-c：使用类似 Dockerfile 的指令修改镜像配置，例如CMD、ENV等，不需要依赖实际的 Dockerfile 文件。-m：指定提交时的说明文字。-p：提交时暂停容器，减少提交过程中发生文件修改的可能性。
3. 示例
bash
docker commit -a "maxhou" -m "修改 Nginx 配置" mynginx maxhou/mynginx:v01其中：
mynginx：需要提交的容器名称或容器 ID。maxhou/mynginx:v01：创建的新镜像名称及标签。-a：指定作者。-m：添加本次提交的说明。
创建成功后，可以通过以下命令查看镜像：
bash
docker images也可以使用新镜像创建容器：
bash
docker run -d --name mynginx2 maxhou/mynginx:v014. 特点
优点：
- 操作简单，不需要编写 Dockerfile。
- 可以快速保存容器文件系统中的修改。
- 适合临时调试和快速制作镜像。
缺点：
- 构建过程不够直观，不容易还原镜像的创建步骤。
- 不方便团队协作和后续维护。
- 不适合需要重复构建的生产环境。
注意：docker commit 主要保存容器文件系统的变更，并保留原镜像的大部分配置。挂载卷中的数据不会自动打包进新镜像。
二、标准创建镜像方式二：docker build
docker build 通过执行 Dockerfile 中的构建指令来创建镜像。
与 docker commit 不同，docker build 不需要预先创建一个容器作为提交对象，只需要准备 Dockerfile、基础镜像以及相应的构建文件即可。
1. 语法
bash
docker build [OPTIONS] PATH常用写法：
bash
docker build -t 镜像名称:标签 .其中：
-t：指定镜像名称和标签。.：指定当前目录为构建上下文。Dockerfile：默认读取构建上下文中的Dockerfile文件。
Dockerfile 常用指令表格
| 指令 | 功能 | 备注 |
|---|---|---|
FROM |
指定构建镜像所使用的基础镜像 | 必须掌握，通常是 Dockerfile 的第一条指令 |
MAINTAINER |
指定镜像维护者 | 已过时，推荐使用 LABEL |
LABEL |
为镜像添加元数据 | 可以设置作者、版本、描述等信息 |
COPY |
将构建上下文中的文件或目录复制到镜像中 | 必须掌握，不会自动下载 URL 文件，也不会自动解压压缩包 |
ADD |
将文件或目录添加到镜像中 | 类似 COPY，但还支持 URL 和自动解压本地 tar 压缩包；一般优先使用 COPY |
WORKDIR |
设置后续指令的工作目录 | 目录不存在时会自动创建，必须掌握 |
RUN |
在构建镜像时执行命令 | 必须掌握，例如安装软件、创建目录 |
VOLUME |
声明容器的数据卷挂载点 | 用于持久化或共享数据，具体挂载方式可由运行容器时配置 |
EXPOSE |
声明容器预期监听的端口 | 仅作声明，不会自动发布端口；需要通过 docker run -p 等方式映射 |
ENV |
设置环境变量 | 必须掌握，变量会保留在镜像中，并在容器运行时可用 |
CMD |
指定容器启动时默认执行的命令或参数 | 必须掌握，可被 docker run 后面提供的命令参数覆盖 |
ENTRYPOINT |
指定容器启动时执行的程序 | 必须掌握，常用于设置容器的固定启动入口 |
ARG |
定义构建时参数 | 可以通过 docker build --build-arg 传入，通常不直接作为运行时环境变量使用 |
SHELL |
指定 shell 格式指令使用的 shell | 使用较少，可用于调整 RUN 等指令的 shell 执行方式 |
USER |
指定后续构建指令及容器运行时使用的用户 | 应了解，常用于避免容器以 root 身份运行 |
HEALTHCHECK |
设置容器健康检查 | 用于检测容器中的服务是否正常运行 |
ONBUILD |
设置在当前镜像被其他 Dockerfile 作为基础镜像构建时触发的指令 | 使用较少，适合制作基础镜像 |
STOPSIGNAL |
指定停止容器时发送给容器主进程的信号 | 使用较少，默认停止信号通常为 SIGTERM |
补充：CMD 和 ENTRYPOINT 的区别
CMD：指定默认启动命令或默认参数，通常可以被运行容器时提供的命令覆盖。ENTRYPOINT：指定容器启动时执行的程序，通常用于固定启动入口。- 两者配合使用时，
CMD可以为ENTRYPOINT提供默认参数。
例如：
dockerfile
FROM eclipse-temurin:17-jre
WORKDIR /app
COPY app.jar app.jar
ENTRYPOINT ["java", "-jar", "app.jar"]构建镜像：
bash
docker build -t myapp:v1 .启动容器：
bash
docker run -d --name myapp myapp:v1此时容器会执行：
bash
java -jar app.jar补充：RUN 和 CMD 的区别
RUN：在docker build构建镜像的过程中执行，执行结果可以保存在镜像文件系统中。CMD：指定容器启动时的默认执行命令或参数。
简单记忆：
RUN 是构建时执行，CMD 和 ENTRYPOINT 是容器启动时执行。
2. 示例
假设当前项目目录如下：
text
nginx-project/
├── Dockerfile
└── nginx.confDockerfile 内容：
dockerfile
FROM nginx:alpine
COPY nginx.conf /etc/nginx/nginx.conf其中：
FROM：指定基础镜像。COPY：将构建上下文中的文件复制到镜像内。
进入 nginx-project 目录，执行：
bash
docker build -t mynginx:v01 .Docker 会读取 Dockerfile，按照其中的指令逐步构建镜像。
构建完成后，可以使用以下命令查看镜像：
bash
docker images然后基于新镜像启动容器：
bash
docker run -d --name mynginx mynginx:v013. 特点
优点：
- 使用 Dockerfile 明确记录构建步骤。
- 更容易重复构建和维护镜像。
- 适合团队协作、持续集成和自动化部署。
- 便于进行版本管理。
缺点：
- 需要编写和维护 Dockerfile。
- 需要准备基础镜像及相关构建文件。
- 需要了解常见的 Dockerfile 指令。
三、docker commit 和 docker build 的区别
| 对比项 | docker commit | docker build |
|---|---|---|
| 创建依据 | 已有容器的文件系统变更 | Dockerfile 和构建上下文 |
| 是否需要已有容器 | 需要 | 不需要 |
| 是否需要 Dockerfile | 不需要 | 通常需要 |
| 是否可以修改镜像配置 | 可以通过 -c 等参数修改部分配置 |
可以通过 Dockerfile 指令配置 |
| 可重复构建性 | 较差，依赖容器当前状态 | 较好，构建步骤有明确记录 |
| 适用场景 | 临时调试、快速保存修改 | 正式项目、团队协作、自动化部署 |
需要注意：docker commit 并不是把容器的所有内容完整打包。它主要保存容器文件系统的变更，挂载卷中的数据不会自动进入新镜像。
四、总结
Docker 提供了两种创建镜像的思路：
方式一：docker commit
直接将已有容器的文件系统变更保存为镜像，操作简单，适合快速保存修改。
方式二：docker build
通过 Dockerfile 描述镜像的构建步骤，不需要预先创建一个待提交的容器，更适合规范化开发和部署。
在实际项目中，例如部署 Spring Boot 应用时，通常推荐使用 Dockerfile，将基础运行环境、JAR 包和启动命令明确写入构建流程中，便于后续维护和自动化部署。