Dockerfile 打包应用和使用 `docker commit` 生成镜像 区别

Dockerfile 依赖网络，国内不适合，香港服务器可以

-虽然灵活，但网络以外搞，境内不好用

docker commit 生成镜像 避免了网络的影响

• 不方便修改，但固定了，不依赖网络，拷贝可以使用。
• 问题少。 版本不经常变，可以

使用 Dockerfile 打包应用和使用 docker commit 生成镜像，虽然最终都能生成一个 Docker 镜像，但它们在实现方式、灵活性、可维护性和最佳实践方面存在显著区别。以下是两者的详细对比：

1. Dockerfile 打包

定义

Dockerfile 是一个文本文件，包含了一系列的指令，用于定义如何构建 Docker 镜像。通过这些指令，Docker 可以逐步构建出一个包含应用程序及其依赖的镜像。

示例

假设你有一个 app.jar 文件，可以通过以下 Dockerfile 打包：

# 基础镜像
FROM openjdk:11-jre-slim

# 将 app.jar 复制到镜像中
COPY app.jar /app.jar

# 指定容器启动时运行的命令
CMD ["java", "-jar", "/app.jar"]

构建镜像的命令：

docker build -t myapp:v1.0 .

优点

1. 可重复性：Dockerfile 明确记录了构建镜像的每一步，确保每次构建的结果一致。
2. 可维护性：Dockerfile 是一个文本文件，可以版本控制（如 Git），便于团队协作和历史回溯。
3. 透明性：任何人都可以通过 Dockerfile 了解镜像的构建过程。
4. 灵活性：可以通过修改 Dockerfile 中的指令，轻松调整镜像的内容和配置。
5. 最佳实践：符合 Docker 的设计哲学，推荐用于生产环境。

缺点

1. 学习成本：需要了解 Dockerfile 的语法和常用指令。
2. 构建时间：每次修改 Dockerfile 后需要重新构建镜像，可能需要一定时间。

2. docker commit 打包

定义

docker commit 是一个命令，用于将一个运行中的容器的当前状态提交为一个新的镜像。它会捕获容器的所有更改，包括文件系统的变化、环境变量等。

示例

假设你有一个运行中的容器 mynginx，修改了其中的 index.html 文件，可以通过以下命令提交为新镜像：

# 提交容器变化打成一个新的镜像
docker commit -m "update index.html" mynginx mynginx:v1.0

# 保存镜像为指定文件
docker save -o mynginx.tar mynginx:v1.0

# 加载镜像
docker load -i mynginx.tar

优点

1. 快速：直接将容器的当前状态打包，无需重新构建，速度较快。
2. 简单：操作简单，无需编写 Dockerfile。

缺点

1. 不可重复性：docker commit 打包的是容器的当前状态，无法记录构建过程，难以保证每次打包的结果一致。
2. 不可维护性：无法通过版本控制管理，难以回溯历史变更。
3. 不透明：无法直观了解镜像的构建过程，其他人难以理解镜像的来源。
4. 不推荐用于生产：不符合 Docker 的最佳实践，不推荐用于生产环境。

3. docker save 和 docker load

定义

docker save 和 docker load 是用于保存和加载镜像的命令。docker save 将镜像保存为 .tar 文件，docker load 将 .tar 文件加载为镜像。

示例

# 保存镜像为指定文件
docker save -o mynginx.tar mynginx:v1.0

# 加载镜像
docker load -i mynginx.tar

优点

1. 便于迁移：可以将镜像保存为 .tar 文件，便于在不同机器之间迁移。
2. 离线使用：适合在没有网络的环境中使用。

缺点

1. 仅用于迁移：不涉及镜像的构建过程，无法替代 Dockerfile 或 docker commit。

总结

特性	Dockerfile 打包	docker commit 打包	docker save 和 docker load
可重复性	高，每次构建结果一致	低，依赖容器的当前状态	不涉及构建过程
可维护性	高，支持版本控制	低，无法回溯历史变更	不涉及构建过程
透明性	高，通过 Dockerfile 可以了解构建过程	低，无法直观了解镜像的构建过程	不涉及构建过程
灵活性	高，可以通过修改 Dockerfile 调整镜像	低，只能捕获容器的当前状态	不涉及构建过程
最佳实践	符合 Docker 设计哲学，推荐用于生产	不推荐用于生产	仅用于镜像迁移
操作复杂度	需要编写 Dockerfile，有一定学习成本	操作简单，无需编写 Dockerfile	操作简单，仅用于迁移

推荐使用场景

1. Dockerfile 打包：

   • 推荐用于生产环境。
   • 需要确保镜像的可重复性、可维护性和透明性。
   • 适合团队协作和持续集成/持续部署（CI/CD）。

2. docker commit 打包：

   • 适合快速测试和开发环境。
   • 临时修改容器状态并需要快速保存。

3. docker save 和 docker load：

   • 用于镜像的迁移和离线使用。
   • 适合在不同机器之间传输镜像。

根据你的具体需求选择合适的方式。如果需要构建一个可维护、可重复的生产环境镜像，推荐使用 Dockerfile。

 

 

 

 

 

sudo tee /etc/docker/daemon.json <<-'EOF' 
{ 
"registry-mirrors": ["https:// .mirror.aliyuncs.com", 
"https://docker.m.daocloud.io"] 
} 
EOF 

sudo systemctl daemon-reload

sudo systemctl restart docker