Docker镜像定制：从docker commit到Dockerfile的实战入门
1. 从“黑盒”到“白盒”：为什么Commit定制是Docker入门的必经之路
很多刚接触Docker的朋友，在学会了
docker pull
拉取镜像、
docker run
启动容器后，面对的第一个进阶困惑往往是：我该怎么做一个自己的镜像？网上的教程一上来就讲Dockerfile，各种
FROM
、
RUN
、
COPY
指令看得人头大，感觉门槛一下就上去了。其实，Docker官方提供了一条更符合人类直觉的学习路径，那就是
基于
docker commit
命令来定制镜像
。你可以把它理解为给一个现有的、运行中的系统“拍快照”。
想象一下这个场景：你从官方仓库拉了一个纯净的Ubuntu镜像，运行起来后，你就像登录进了一台全新的虚拟机。在这台“虚拟机”里，你安装了Nginx，修改了配置文件，部署了自己的网站代码，调整了系统参数。一顿操作之后，你希望把当前这个“完美状态”保存下来，以后直接就能用，而不是每次都重复这一系列安装配置步骤。
docker commit
干的就是这个事——它将一个容器的当前文件系统变更，连同它的运行历史，打包成一个新的、可复用的镜像。
虽然业界公认的最佳实践是使用
声明式
的Dockerfile来构建镜像（因为可追溯、可重复），但
commit
方式作为一种
命令式
的构建方法，对于新手理解Docker镜像的“层叠”本质和容器状态管理，有着不可替代的教学意义。它能让你直观地感受到“镜像即冻结的容器状态”这一核心概念。今天，我们就来手把手操作一遍，把这个“黑盒”过程彻底变成“白盒”。
2. 实战演练：从零开始Commit一个Nginx定制镜像
我们通过一个完整的例子，来演示如何将一个基础的Ubuntu容器，定制成一个包含我们特定网页的Nginx服务器镜像。
2.1 环境准备与基础容器启动
首先，我们需要一个起点。这里我们选择最常用的
ubuntu:22.04
作为基础镜像。
# 1. 拉取基础镜像（如果本地没有）
docker pull ubuntu:22.04
# 2. 以交互模式运行一个容器，并给它起个名字方便后续操作
docker run -it --name my_ubuntu_container ubuntu:22.04 /bin/bash
执行上面的命令后，你的终端会直接进入到这个新容器的bash shell中。注意，这时你看到的命令行提示符可能会变成类似
root@a1b2c3d4e5f6:/#
的样子，这表明你已经在容器内部了。这个
a1b2c3d4e5f6
就是容器的短ID。
注意 ：
-it是两个参数：-i（保持标准输入打开）和-t（分配一个伪终端）。它们通常一起使用，让你可以像使用普通Linux终端一样与容器交互。--name参数为容器指定一个易读的名称，否则Docker会随机分配一个，不便于后续管理。
2.2 在容器内部进行定制化操作
现在，我们在这个“纯净”的Ubuntu系统里开始我们的改造工作。请在容器内的shell中依次执行以下命令：
# 1. 更新软件包列表（Ubuntu的标准操作）
apt-get update
# 2. 安装Nginx服务器和用于编辑文件的vim（或nano）
apt-get install -y nginx vim
# 3. 安装完成后，Nginx服务默认不会自动启动。我们先启动它看看效果。
service nginx start
# 4. 创建一个我们自己的网页，覆盖Nginx的默认首页。
# 首先，进入Nginx默认的网站根目录
cd /var/www/html
# 5. 备份原来的默认首页（可选，但是个好习惯）
mv index.nginx-debian.html index.nginx-debian.html.bak
# 6. 使用vim创建我们自己的首页
vim index.html
在
vim
中，按
i
进入插入模式，输入以下简单的HTML内容：
<!DOCTYPE html>
<html>
<head>
<title>My Custom Docker Nginx</title>
</head>
<body>
<h1>Hello from my committed Docker Image!</h1>
<p>This page is served from a custom image built via `docker commit`.</p>
</body>
</html>
输入完毕后，按
ESC
键退出插入模式，然后输入
:wq
并按回车，保存文件并退出vim。
此时，如果你在容器内部使用
curl localhost
命令，应该能看到刚刚创建的HTML内容。我们的定制化操作就完成了，核心是：更新系统、安装软件、修改配置、添加自定义文件。
2.3 提交容器状态，生成新镜像
现在，我们想要保存这个容器的当前状态。 不要关闭或退出 当前容器的bash终端。你需要打开一个新的本地终端窗口（或者使用终端的分屏功能）。
在新的终端中，执行以下命令：
# 查看当前正在运行的容器，确认我们的容器ID或名称
docker ps
# 使用 docker commit 命令提交容器。格式：docker commit [容器名/ID] [新镜像名:标签]
docker commit my_ubuntu_container my_custom_nginx:v1
命令解析：
-
my_ubuntu_container：这是我们之前通过--name指定的容器名称。你也可以使用docker ps查看到的容器ID。 -
my_custom_nginx:v1：这是我们要创建的新镜像的名称和标签。名称可以自定义，标签v1常用于表示版本。
执行成功后，终端会输出新创建镜像的长ID（如
sha256:xxxx...
）。你可以用
docker images
命令查看，列表中应该会出现一个名为
my_custom_nginx
、标签为
v1
的镜像。
2.4 验证与运行定制镜像
提交完成后，原来的容器
my_ubuntu_container
任务就完成了。我们可以在原容器终端里输入
exit
退出并停止它。然后，用我们刚做好的新镜像来启动一个全新的容器。
# 1. 基于新镜像运行一个容器，并将容器的80端口映射到主机的8080端口
docker run -d -p 8080:80 --name my_nginx_test my_custom_nginx:v1 nginx -g "daemon off;"
命令解析：
-
-d：让容器在后台运行。 -
-p 8080:80：端口映射。将主机（你的电脑）的8080端口映射到容器的80端口（Nginx默认端口）。 -
--name my_nginx_test：为新容器命名。 -
nginx -g "daemon off;"：这是容器的启动命令。它以前台模式启动Nginx服务。这是运行Nginx等服务的常见做法，因为Docker容器需要有一个前台进程才能保持运行。
现在，打开你的浏览器，访问
http://localhost:8080
。你应该能看到之前编写的“Hello from my committed Docker Image!”页面。这说明我们的定制镜像完全成功了！
3. 深入原理：Commit到底做了什么？
表面上，
docker commit
只是保存了状态，但其背后体现了Docker镜像的核心设计思想——
联合文件系统（Union File System）
和
层（Layer）
。
3.1 镜像的层叠结构与Commit的实质
Docker镜像并非一个完整的、单一的文件包。它是由一系列只读层（Layer）叠加起来的，每一层代表文件系统的一次更改（比如添加一个文件、安装一个软件包）。当你运行一个容器时，Docker会在这些只读层之上，添加一个薄薄的可写层（容器层）。所有在容器内进行的文件创建、修改、删除都发生在这个可写层。
docker commit
命令所做的，正是
将当前容器的这个可写层，固化成一个新的、只读的镜像层
，并将这个新层叠加到原有镜像层之上，从而形成一个新的镜像。你可以用
docker history my_custom_nginx:v1
命令来验证这一点。这个命令会显示构建该镜像的每一层历史记录，你会看到最上面一层就是我们刚刚的提交操作，以及它大致的尺寸。
3.2 Commit与Dockerfile构建的本质区别
理解了这个，就能明白为什么
commit
方式虽然直观，但在生产环境中不被推荐：
-
可重复性（Reproducibility）差
：
commit构建的镜像是一个“黑箱”。别人（甚至未来的你自己）无法确切知道镜像里到底包含了哪些操作（是apt-get install了三个包还是三十个？修改了哪几个配置文件？）。而Dockerfile是一个文本文件，清晰地记录了每一步操作，构建过程完全透明、可重复。 -
镜像臃肿
：
commit会包含操作过程中产生的所有中间文件、缓存（如apt-get的缓存/var/cache/apt/archives/）、历史记录等。这会导致镜像体积无谓地增大。Dockerfile则可以通过精心设计，在一个RUN指令中串联多条命令并及时清理缓存，从而构建出更精简的镜像。 -
无法自动化与版本管理
：Dockerfile可以和代码一起放入版本控制系统（如Git），任何更改都有记录，并且可以集成到CI/CD流水线中自动构建。
commit是手动操作，难以融入自动化流程。
所以，
commit
是绝佳的
学习工具和调试工具
。当你不知道如何用Dockerfile实现某个复杂环境配置时，可以先用
commit
方式手动搭出来，再用
docker history
或
docker diff
命令反推步骤，最后写成Dockerfile。这才是它的正确打开方式。
4. Commit命令的进阶参数与实用技巧
docker commit
命令还有一些有用的参数，可以帮助我们创建更符合需求的镜像。
4.1 使用
-m
和
-a
添加元数据
就像Git提交一样，我们可以为这次镜像提交添加注释和作者信息，这对于后期维护非常重要。
docker commit -m "Initial version with Nginx and custom homepage" -a "Your Name" my_ubuntu_container my_custom_nginx:v1.1
-
-m “…”：提交信息，说明这次定制的主要内容。 -
-a “…”：作者信息。
添加了元数据后，使用
docker inspect my_custom_nginx:v1.1
命令，在输出的JSON信息中，你可以找到
Comment
和
Author
字段，里面就是我们刚才填写的信息。
4.2 使用
–change
或
-c
应用Dockerfile指令
这是
commit
命令一个非常强大但容易被忽略的功能。它允许你在提交的同时，直接对镜像应用一些Dockerfile指令。例如，我们想在提交时，就指定新镜像的默认启动命令：
docker commit --change='CMD ["nginx", "-g", "daemon off;"]' my_ubuntu_container my_custom_nginx:with-cmd
这样，生成的
my_custom_nginx:with-cmd
镜像在运行时就不需要再在
docker run
后面指定启动命令了，直接
docker run -d -p 8080:80 my_custom_nginx:with-cmd
即可。
--change
支持的指令包括
CMD
,
ENTRYPOINT
,
ENV
,
EXPOSE
,
USER
,
WORKDIR
,
VOLUME
等。这相当于在提交的瞬间，为镜像的顶层附加了一个微型的Dockerfile指令层。
4.3 排查与调试：
docker diff
的妙用
如果你对一个正在运行的容器做了很多修改，记不清到底改了哪些文件，可以使用
docker diff
命令。它列出容器层（可写层）相对于其基础镜像的所有变化。
# 在提交前，查看容器my_ubuntu_container的文件系统变化
docker diff my_ubuntu_container
输出通常由三种字符开头：
- A ：新增的文件（Added）
- D ：删除的文件（Deleted）
- C ：修改的文件（Changed）
这个命令是反推Dockerfile步骤的利器。通过查看变化列表，你可以清晰地知道安装软件创建了哪些目录、修改了哪些配置，从而更准确地编写Dockerfile中的
COPY
或
RUN
指令。
5. 从Commit到Dockerfile：最佳实践迁移指南
通过
commit
掌握了镜像定制的感性认识后，我们的最终目标是要将其转化为一个可维护的Dockerfile。以上面的Nginx定制为例，我们来还原并优化出一个标准的Dockerfile。
5.1 反推操作步骤，编写初始Dockerfile
回顾我们在容器内的操作：
-
apt-get update -
apt-get install -y nginx vim -
进入
/var/www/html目录 -
创建自定义的
index.html文件
对应的Dockerfile初版如下：
# 基于Ubuntu 22.04
FROM ubuntu:22.04
# 执行系统更新和软件安装
RUN apt-get update && apt-get install -y nginx
# 设置工作目录（不一定必要，但好习惯）
WORKDIR /var/www/html
# 将我们本地的网页文件复制到镜像中
COPY ./my-index.html /var/www/html/index.html
# 声明容器运行时暴露的端口
EXPOSE 80
# 设置容器启动时执行的命令
CMD ["nginx", "-g", "daemon off;"]
在同一目录下，创建一个
my-index.html
文件，内容就是我们之前写的HTML。
5.2 优化Dockerfile：缩小体积与提升构建效率
初版Dockerfile有两个明显问题：1. 没有清理apt缓存，镜像会很大；2. 使用了相对臃肿的Ubuntu作为基础镜像。优化后如下：
# 使用更精简的官方Nginx镜像作为基础，它本身基于Debian
FROM nginx:alpine
# 直接覆盖默认的首页文件
COPY ./my-index.html /usr/share/nginx/html/index.html
# 基于alpine的Nginx镜像已经暴露了80端口并设置了正确的CMD，所以这里可以省略EXPOSE和CMD。
# 但如果需要自定义，可以显式写出：
# EXPOSE 80
# CMD ["nginx", "-g", "daemon off;"]
这个优化版的优势极其明显：
-
体积
：
ubuntu:22.04镜像约70MB，安装Nginx后可能超过100MB。而nginx:alpine镜像只有约20MB。 -
效率
：省去了
apt-get update && install的漫长过程，构建速度飞快。 - 安全与维护 ：使用官方维护的镜像，减少了系统层面的依赖和潜在安全漏洞。
5.3 构建并验证优化后的镜像
使用优化后的Dockerfile进行构建和运行：
# 构建镜像（注意最后有一个点，表示当前上下文目录）
docker build -t my_nginx_dockerfile:latest .
# 运行容器
docker run -d -p 8081:80 --name nginx_from_dockerfile my_nginx_dockerfile:latest
# 访问验证
curl http://localhost:8081
你会发现，效果和之前用
commit
制作的镜像完全一样，但整个过程清晰、可重复、镜像更小。这就是Dockerfile的价值所在。
6. 常见问题与避坑指南
在实际操作
docker commit
时，新手很容易遇到以下几个坑：
6.1 提交后，容器内的服务没有自动启动
这是最常见的问题。很多人以为在容器里用
service nginx start
启动了服务，提交后的镜像就会自动运行它。
这是错误的
。
commit
只保存文件系统的状态（即安装了Nginx，配置文件也改了），但
不保存
容器的运行状态（进程列表、内存状态等）。
镜像的默认启动行为由两个指令决定：
CMD
和
ENTRYPOINT
。如果你从官方
ubuntu
镜像
commit
，它的默认
CMD
是
bash
。所以你直接运行新镜像，它只会启动一个bash shell，Nginx服务并不会启动。
解决方案 ：
-
在
docker run时直接指定启动命令，如我们之前做的：docker run ... nginx -g "daemon off;"。 -
在
commit时使用--change参数修改默认CMD，如上文4.2节所示。 -
更好的方式是，后续使用Dockerfile来构建，在文件中明确指定
CMD。
6.2 提交的镜像包含了敏感数据或临时文件
在容器内操作时，可能会无意中留下密码文件、缓存、日志等。
commit
会把这些全部打包进去，存在安全风险和导致镜像臃肿。
排查与解决 ：
-
提交前检查
：使用
docker diff <容器名>仔细查看即将被提交的变更列表。对于不需要的文件，可以在容器内手动删除后再提交。 -
使用
.dockerignore理念 ：虽然commit没有类似机制，但要有意识地在操作结束时清理临时文件，例如运行apt-get clean来清除安装包缓存。 -
终极方案
：还是使用Dockerfile，在
RUN指令中链式操作并即时清理，例如：RUN apt-get update && apt-get install -y nginx && apt-get clean && rm -rf /var/lib/apt/lists/*。
6.3 镜像的层级过多且混乱
频繁地对同一个容器进行修改并
commit
，会产生多个迭代的镜像版本。每个
commit
都会产生一个新层，导致镜像历史冗长、关系复杂。
管理建议 ：
-
为镜像使用有意义的标签，如
myapp:dev-20231027，而不是每次都打latest标签。 -
定期使用
docker image prune清理未被使用的中间镜像或悬虚镜像（dangling images，即没有标签的镜像层）。 -
明确
commit的定位：它是用于创建“一次性”基础模板或用于调试的过渡手段，而非正式的版本管理工具。定稿后应及时转化为Dockerfile。
走过
commit
定制的整个流程，你才能真正体会到Docker镜像“层”的概念不再是抽象的术语。它就像做蛋糕，每一层
commit
就是往上抹一层奶油或水果。虽然最终大家都会用食谱（Dockerfile）来高效、标准地做蛋糕，但亲手抹一遍奶油，才能深刻理解每一层对最终成品的影响。下次当你遇到一个复杂环境不知如何用Dockerfile描述时，不妨先
run
一个基础容器，进去手动把它调通，然后
commit
一下，再用
docker history
和
docker diff
看看你究竟做了什么——这往往是解开难题最快的一把钥匙。
更多推荐
10
0- 0
已为社区贡献41条内容
所有评论(0)