文章目录
- 前言
-
- [Docker 的技术边界](#Docker 的技术边界)
- [Docker 与虚拟机的区别](#Docker 与虚拟机的区别)
- 同一个镜像是可以运行成多个不同的容器，做不同的事情
- [打包 Docker 镜像](#打包 Docker 镜像)
-
- [前端程序的 Dockerfile](#前端程序的 Dockerfile)
- [后端程序的 Dockerfile](#后端程序的 Dockerfile)
- [近距离的观察 Docker 镜象](#近距离的观察 Docker 镜象)
- 镜像里面包含容器运行时的信息
-
- [`UpperDir` 的作用](#
UpperDir的作用) - [`WorkDir` 的作用（处理文件操作的事务性）](#
WorkDir的作用（处理文件操作的事务性）)
- [`UpperDir` 的作用](#
- 想象图景
- [运行镜像，将其变成 Docker 容器运行时](#运行镜像，将其变成 Docker 容器运行时)
-
- [近距离观察 Docker 容器](#近距离观察 Docker 容器)
- 结尾：先删除镜像，后删除容器
推荐一个零声教育学习教程，个人觉得老师讲得不错，分享给大家：[Linux，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK等技术内容，点击立即学习: https://github.com/0voice 链接。
前言
我们在上一篇文章 《先从 Go 对与云原生的依赖关系讲起，再讲讲 一个简单的 Go 项目热热身》 中介绍了一个零声教育的商品信息服务项目案例，由于在代码中使用了 GRPC 框架，我们把项目变成了一个前后端分离、信息流紧凑结构化的程序。这个 go 程序是可以通过 docker 打包成镜像以达到脱离其操作系统环境的目的，而且极其之简单，因为 go 程序真不像 C/C++ 程序那样每次启动都需要程序员主动去连接动态库，它是一次过把所有的依赖都打包进了同一个程序之中。
因此，我想说明 C/C++ 程序的 Docker 镜像打包，完全可以做。但是需要程序员对库依赖文件具有高度敏锐的识别，程序员需要把所有依赖文件都找齐，比如我们使用了 Linux 的 epoll 事件驱动库，那就需要把这个文件找出来... 。这是一个非常费力的过程，要求程序员对操作系统有很高水平的认知和理解。
进入正题，我们在本篇文章要把之前做的商品信息服务系统打包成 Docker 镜像，然后运行成一个容器。通过一个具体的案例，我们是可以深刻领会 Docker 寂静是一个什么样的软件了。另外，docker 的下载请自行解决。
Docker 的技术边界
docker是容器化技术，针对的是应用及应用所依赖的环境做容器化。遵循单一原则，一个容器只运行一个主进程。多个进程都部署在一个容器中，弊端很多。比如更新某个进程的镜像时，其他进程也会被迫重启，如果一个进程出问题导致容器挂了，所有进程都将无法访问。再根据官网的提倡的原则而言，容器 = 应用 + 依赖的执行环境，而不是像虚拟机一样，把一堆进程都部署在一起。
docker解决了什么问题：
- 解决了应用程序本地运行环境与生产运行环境不一致的问题
- 解决了应用程序资源使用的问题，docker会一开始就为每个程序指定内存分配和CPU分配
- 让快速扩展、弹性伸缩变得简单
Docker 与虚拟机的区别
我们虚拟机是需要在配置的时候通过光盘映像文件安装操作系统（比如 Ubuntu，Centos 等），但是 Docker 只需要把所有依赖文件安装好了就行，整个 docker 容器就只运行一个程序即可，但虚拟机操作系统需要做到 "面面俱到"，因而整体规模很大。
Hypervisor（虚拟机监控器，Virtual Machine Monitor，简称 VMM）是一种软件、硬件或固件，用于创建和运行虚拟机（VM）。它允许多个操作系统共享单一的物理主机，通过将主机的硬件资源（如 CPU、内存、存储和网络）虚拟化，使每个虚拟机都能独立运行，仿佛它们各自拥有独立的物理机。
对于 Docker 来说，它有 Docker 引擎管理镜像、存储数据持久化、网络区隔、容器运行时的资源分配。这个倒是和 Hypervisor 区别不大。Docker 容器镜像之内，就是一个小型王国，它有操作系统的一些性质，比如 "域名解析"、环境变量、路径、终端等等。
同一个镜像是可以运行成多个不同的容器，做不同的事情
镜像构建只创建只读的 LowerDir 层，每次运行容器时才会创建新的 UpperDir 和 WorkDir，同一个镜像的多个容器实例有各自独立的 UpperDir。
打包 Docker 镜像
将 Go 程序打包成 Docker 镜像，并不是那么难，因为 go 程序并没有那么的以来操作系统，也可以说是与操作系统生殖隔离（不同操作系统的差别并不大），实在是上手学习云原生部署的好对象。这点远远优于 C/C++ 程序，因为 c/c++ 是高度依赖于操作系统的各个架构与底层源代码的，比如 epoll 和 io-uring 等库文件都是 Linux 的底层代码，因而盘根错节，剪不断理还乱。
另外，我会先介绍 Dockerfile 的语法
| Docker 语法命令 | 作用 |
|---|---|
| FROM | 设置镜像使用的基础镜像 |
| MAINTAINER | 设置镜像的作者 |
| RUN | 编译镜像时运行的脚步 |
| CMD | 设置容器的启动命令 |
| LABEL | 设置镜像标签 |
| EXPOSE | 设置镜像暴露的端口 |
| ENV | 设置容器的环境变量 |
| ADD | 编译镜像时复制上下文中文件到镜像中 |
| COPY | 编译镜像时复制上下文中文件到镜像中 |
| ENTRYPOINT | 设置容器的入口程序 |
| VOLUME | 设置容器的挂载卷 |
| USER | 设置运行 RUN CMD ENTRYPOINT的用户名 |
| WORKDIR | 设置 RUN CMD ENTRYPOINT COPY ADD 指令的工作目录 |
| ARG | 设置编译镜像时加入的参数 |
| ONBUILD | 设置镜像的ONBUILD 指令 |
| STOPSIGNAL | 设置容器的退出信号量 |
前端程序的 Dockerfile
我们先来看我们为前端程序准备的 Dockerfile
我们发现这个 Dockerfile 里面有两段文字两个 FROM，实质上该镜像的构建过程分成两个阶段 stage，我们查看上面那个 Dockerfile 文件语法表，便可以解读
第一阶段
1、（基础）下载镜像 golang:1.20，本地没有的话，就远程拉取，就此进入第一阶段，记作 stage0。
2、（运行）设置 Docker 镜像容器内的环境变量 GOPROXY=https://proxy.golang.com.cn,https://goproxy.cn,direct
3、（复制）把当前路径下的所有文件都复制到容器的 /src/0voiceGateway 路径上
4、（进入某个容器镜像的某个目录）进入某个容器镜像的 /src/0voiceGateway 目录
5、（运行）编译 go 程序，跟我们上一篇文章类似， CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o 0voiceGateway .
第二阶段
1、（基础）下载镜像 alpine:3.18，本地没有的话，就远程拉取，就此进入第二阶段，记作 stage1。
2、（复制）把当前文件夹下的 ./curl-amd64 可执行文件复制到容器里面，并且指定路径与文件名 /usr/bin/curl
3、（运行）将容器内的文件 /usr/bin/curl 设置可执行权限
4、（进入某个容器镜像的某个目录）进入某个容器镜像的 /app 目录
5、（复制）把当前路径下的 config.yaml 文件都复制到容器的 /app/config.yaml 路径上
6、（复制）把第一个阶段的编译成型文件 /src/0voiceGateway/0voiceGateway 移动到当前镜像的 /app 目录下
7、（入口程序）当我们把这个镜像启动成 docker 容器运行时的时候，第一步就是要执行这个文件打包前端程序的镜像需要用到这个命令，docker build 是 docker 的镜像构架命令，-t 是 --tag 的简写，用来给即将构建出的镜像取"名字＋标签"（name:tag）。后面的 0voice-gateway:v0.5.0 就是镜像+标签，. 就是当前文件路径下的 Dockerfile。
bash
docker build -t 0voice-gateway:v0.5.0 .
第一阶段生成镜像就是中间镜像，如果这个命令没有指明生成哪一个，就一定是最后一个阶段的镜像作为最终镜像
如果我们运行下面这个命令，那就不会再是默认的最后一个阶段变成最终镜像
$ docker build -t [输出镜像名字];[标签] --target [阶段名字] [Dockerfile的文件名]于是，终端输出会显示整个构建过程，他是分阶段构建的，我们从 [stage0 3/5] ADD ./ /src/0voiceGateway 和 [stage1 6/6] COPY --from=stage0 /src/0voiceGateway/0voiceGateway ./ 等等可以看出是分阶段构建，因为它有阶段名字与该阶段下的命令，还介绍了该阶段下运行的命令运行了多长时间。
bash
qiming@k8s-master1:~/share/CTASK/docker/code/0voice-crm/0voiceGateway$ docker build -t 0voice-gateway:v0.5.0 .
[+] Building 351.7s (17/17) FINISHED docker:default
=> [internal] load build definition from Dockerfile 0.2s
=> => transferring dockerfile: 1.29kB 0.2s
=> WARN: FromAsCasing: 'as' and 'FROM' keywords' casing do not match (line 1) 0.2s
=> WARN: FromAsCasing: 'as' and 'FROM' keywords' casing do not match (line 7) 0.2s
=> [internal] load metadata for docker.io/library/alpine:3.18 0.0s
=> [internal] load metadata for docker.io/library/golang:1.20 46.5s
=> [internal] load .dockerignore 0.1s
=> => transferring context: 2B 0.0s
=> [stage0 1/5] FROM docker.io/library/golang:1.20@sha256:8f9af7094d0cb27cc783c697ac5ba25efdc4da35f8526db21f7aebb0b0b4f18a 0.0s
=> [stage1 1/6] FROM docker.io/library/alpine:3.18 0.0s
=> CACHED [stage0 2/5] RUN go env -w GOPROXY=https://proxy.golang.com.cn,https://goproxy.cn,direct 0.0s
=> [internal] load build context 18.3s
=> => transferring context: 20.67MB 18.2s
=> [stage0 3/5] ADD ./ /src/0voiceGateway 1.7s
=> CACHED [stage1 2/6] ADD ./curl-amd64 /usr/bin/curl 0.0s
=> CACHED [stage1 3/6] RUN chmod +x /usr/bin/curl 0.0s
=> CACHED [stage1 4/6] WORKDIR /app/ 0.0s
=> [stage1 5/6] ADD ./config.yaml /app/config.yaml 0.5s
=> [stage0 4/5] WORKDIR /src/0voiceGateway 0.0s
=> [stage0 5/5] RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o 0voiceGateway . 284.1s
=> [stage1 6/6] COPY --from=stage0 /src/0voiceGateway/0voiceGateway ./ 0.2s
=> exporting to image 0.2s
=> => exporting layers 0.2s
=> => writing image sha256:d5542708ce1bf33c6ddc8fa5da784ae957306de83cf263b0a597084a4016f8f1 0.0s
=> => naming to docker.io/library/0voice-gateway:v0.5.0 0.0s
2 warnings found (use docker --debug to expand):
- FromAsCasing: 'as' and 'FROM' keywords' casing do not match (line 1)
- FromAsCasing: 'as' and 'FROM' keywords' casing do not match (line 7)后端程序的 Dockerfile
我们先来看我们为后端程序准备的 Dockerfile（这个文件的解读也和上面的一样，大家跟着我的步骤来就行了）
打包前端程序的镜像需要用到这个命令
bash
docker build -t goods:v0.5.0 .于是，终端输出会显示整个构建过程（解读过程也跟前面的一样）
bash
qiming@k8s-master1:~/share/CTASK/docker/code/0voice-crm/Goods$ docker build -t goods:v0.5.0 .
[+] Building 344.4s (17/17) FINISHED docker:default
=> [internal] load build definition from Dockerfile 0.9s
=> => transferring dockerfile: 498B 0.4s
=> [internal] load metadata for docker.io/library/alpine:3.18 0.0s
=> [internal] load metadata for docker.io/library/golang:1.20 50.1s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [stage0 1/5] FROM docker.io/library/golang:1.20@sha256:8f9af7094d0cb27cc783c697ac5ba25efdc4da35f8526db21f7aebb0b0b4f18a 0.0s
=> [internal] load build context 0.6s
=> => transferring context: 14.94MB 0.6s
=> [stage1 1/6] FROM docker.io/library/alpine:3.18 0.0s
=> CACHED [stage0 2/5] RUN go env -w GOPROXY=https://proxy.golang.com.cn,https://goproxy.cn,direct 0.0s
=> [stage0 3/5] ADD ./ /src/goods 9.8s
=> [stage0 4/5] WORKDIR /src/goods 0.0s
=> [stage0 5/5] RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o goods . 277.7s
=> CACHED [stage1 2/6] ADD ./grpc_health_probe-linux-amd64 /usr/bin/grpc_health_probe 0.0s
=> CACHED [stage1 3/6] RUN chmod +x /usr/bin/grpc_health_probe 0.0s
=> CACHED [stage1 4/6] WORKDIR /app/ 0.0s
=> CACHED [stage1 5/6] ADD ./config.yaml /app/config.yaml 0.0s
=> [stage1 6/6] COPY --from=stage0 /src/goods/goods ./ 0.2s
=> exporting to image 2.1s
=> => exporting layers 1.7s
=> => writing image sha256:714feb39b527f08ebb24816e1ce9901dd97ecf42e7d5418da45aed48afbc162e 0.1s
=> => naming to docker.io/library/goods:v0.5.0 0.1s
3 warnings found (use docker --debug to expand):
- FromAsCasing: 'as' and 'FROM' keywords' casing do not match (line 1)
- FromAsCasing: 'as' and 'FROM' keywords' casing do not match (line 7)
- MaintainerDeprecated: Maintainer instruction is deprecated in favor of using label (line 10)近距离的观察 Docker 镜象
构建完镜像后，我们就可以通过 docker inspect 去近距离观察一个镜像，发现它的信息真的很多，但也无须着急，因为真正重要的也就是 GraphDriver 和 RootFS 两个字段的内容。
bash
qiming@k8s-master1:~$ docker inspect 0voice-gateway:v0.5.0
[
{
"Id": "sha256:d5542708ce1bf33c6ddc8fa5da784ae957306de83cf263b0a597084a4016f8f1",
"RepoTags": [
"0voice-gateway:v0.5.0"
],
"RepoDigests": [],
"Parent": "",
"Comment": "buildkit.dockerfile.v0",
"Created": "2025-11-08T18:53:43.29937097Z",
"DockerVersion": "",
"Author": "",
"Architecture": "amd64",
"Os": "linux",
"Size": 34735574,
"GraphDriver": {
"Data": {
"LowerDir": "/var/lib/docker/165536.165536/overlay2/r20wlwiybeqx425ote1slwbiu/diff:/var/lib/docker/165536.165536/overlay2/5o0xzo91v6dhwrrcf00m9r749/diff:/var/lib/docker/165536.165536/overlay2/t82x15extk3uuxhlrb8raiyya/diff:/var/lib/docker/165536.165536/overlay2/p645ylzduapfzr0yvm48k956s/diff:/var/lib/docker/165536.165536/overlay2/b9c3d4bf2bafc80dbf6081405bc051132bdbc6ab82eb989646a5777426c3c22e/diff",
"MergedDir": "/var/lib/docker/165536.165536/overlay2/73wyqndlla6e3d7dd0gwuw0eq/merged",
"UpperDir": "/var/lib/docker/165536.165536/overlay2/73wyqndlla6e3d7dd0gwuw0eq/diff",
"WorkDir": "/var/lib/docker/165536.165536/overlay2/73wyqndlla6e3d7dd0gwuw0eq/work"
},
"Name": "overlay2"
},
"RootFS": {
"Type": "layers",
"Layers": [
"sha256:f44f286046d9443b2aeb895c0e1f4e688698247427bca4d15112c8e3432a803e",
"sha256:aaf1c64fc2a8e5857597d97ede0eb18beedc86d05b6e2bdda3b62571ea9d3af7",
"sha256:fe695ece85edd2ab4d1c0c6115d8febce80f51d2cab1d1b656440b5754c16678",
"sha256:be4ad4a66fe7c00a1c5d51ad3915879114f774399a111d4db5971659d11959b6",
"sha256:6e819136eca5d4fa602bd1e8476786cdd429715c74c33b8536f5d25e554abad0",
"sha256:b4cc20de0a7c46f6ca41cc8f3579f56291936d90dd70735608b967b26d6eb76f"
]
},
"Metadata": {
"LastTagTime": "2025-11-08T18:53:43.50436954Z"
},
"Config": {
"Cmd": null,
"Entrypoint": [
"./0voiceGateway"
],
"Env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
],
"Labels": null,
"OnBuild": null,
"User": "",
"Volumes": null,
"WorkingDir": "/app/"
}
}
]我们需要注意到 GraphDriver 字段的子字段 Data 的 LowerDir 字段，即 GraphDriver.Data.LowerDir 字段，它里面有 5 个路径。这 5 个路径对应 Dockerfile 中的以下构建步骤：
LowerDir[0]: /var/lib/docker/.../r20wlwiybeqx425ote1slwbiu/diff
↓
LowerDir[1]: /var/lib/docker/.../5o0xzo91v6dhwrrcf00m9r749/diff
↓
LowerDir[2]: /var/lib/docker/.../t82x15extk3uuxhlrb8raiyya/diff
↓
LowerDir[3]: /var/lib/docker/.../p645ylzduapfzr0yvm48k956s/diff
↓
LowerDir[4]: /var/lib/docker/.../b9c3d4bf2bafc80dbf6081405bc051132bdbc6ab82eb989646a5777426c3c22e/diff需要明确，任何镜像构建命令，没有指定哪一个阶段作为最终镜像，那就一定是最后一个阶段作为构建镜像的依据，即这个镜像的 5 个 LowerDir 就是仅由红色框的命令生成的
第1层（最底层）：alpine:3.18 基础镜像
bash
# LowerDir[4] - 基础操作系统层
/var/lib/docker/.../b9c3d4bf2bafc80dbf6081405bc051132bdbc6ab82eb989646a5777426c3c22e/diff
# 内容：Alpine Linux 3.18 的最小文件系统
/bin, /etc, /lib, /usr, /var, ...第2层：添加 curl 二进制文件
bash
# LowerDir[3] - 对应 Dockerfile 第8行
ADD ./curl-amd64 /usr/bin/curl
# 内容：/usr/bin/curl 文件
# 这创建了一个新层，包含您添加的 curl 二进制文件第3层：设置 curl 权限
bash
# LowerDir[2] - 对应 Dockerfile 第9行
RUN chmod +x /usr/bin/curl
# 内容：/usr/bin/curl 文件的权限元数据变化
# 虽然看起来是"修改"，但在分层文件系统中这会创建新层第4层：设置工作目录和添加配置文件
bash
# LowerDir[1] - 对应 Dockerfile 第10-11行
WORKDIR /app/
ADD ./config.yaml /app/config.yaml
# 内容：
# - 工作目录元数据
# - /app/config.yaml 配置文件第5层：从 stage0 复制构建结果
bash
# LowerDir[0] - 对应 Dockerfile 第12行
COPY --from=stage0 /src/0voiceGateway/0voiceGateway ./
# 内容：/app/0voiceGateway 可执行文件
# 这是从第一阶段构建的 Go 二进制文件被优化的指令：
- FROM golang:1.20 as stage0 - 这是第一阶段，不包含在最终镜像中
- ENTRYPOINT ["./0voiceGateway"] - 元数据指令，不创建文件系统层
完整的镜像结构就是 GraphDriver.Data.MergedDir 字段下的那个
+------------------------------------------------+
| 最终镜像（stage1）的 Merged View |
+------------------------------------------------+
| UpperDir (可写层，如果有容器修改) |
+------------------------------------------------+
| LowerDir[0]: 0voiceGateway 二进制文件 | ← COPY --from=stage0
+------------------------------------------------+
| LowerDir[1]: /app/config.yaml + WORKDIR | ← ADD config.yaml
+------------------------------------------------+
| LowerDir[2]: curl 文件权限设置 | ← RUN chmod +x
+------------------------------------------------+
| LowerDir[3]: curl 二进制文件 | ← ADD curl-amd64
+------------------------------------------------+
| LowerDir[4]: alpine:3.18 基础系统 | ← FROM alpine:3.18
+------------------------------------------------+另外，RootFS 字段也很有意思
bash
"RootFS": {
"Type": "layers",
"Layers": [
"sha256:f44f286046d9443b2aeb895c0e1f4e688698247427bca4d15112c8e3432a803e",
"sha256:aaf1c64fc2a8e5857597d97ede0eb18beedc86d05b6e2bdda3b62571ea9d3af7",
"sha256:fe695ece85edd2ab4d1c0c6115d8febce80f51d2cab1d1b656440b5754c16678",
"sha256:be4ad4a66fe7c00a1c5d51ad3915879114f774399a111d4db5971659d11959b6",
"sha256:6e819136eca5d4fa602bd1e8476786cdd429715c74c33b8536f5d25e554abad0",
"sha256:b4cc20de0a7c46f6ca41cc8f3579f56291936d90dd70735608b967b26d6eb76f"
]
}核心区别
GraphDriver.Data.LowerDir：显示的是实际磁盘上的分层目录结构（Overlay2 驱动视角）RootFS.Layers：显示的是镜像的链式层级关系（镜像元数据视角）
第1-2层：来自 golang:1.20 基础镜像
bash
# golang:1.20 本身就是一个多层的镜像
Layers[0]: "sha256:f44f286046d9443b2aeb895c0e1f4e688698247427bca4d15112c8e3432a803e"
Layers[1]: "sha256:aaf1c64fc2a8e5857597d97ede0eb18beedc86d05b6e2bdda3b62571ea9d3af7"
# 这些是 golang:1.20 基础镜像的层，虽然最终镜像不包含文件内容，
# 但镜像元数据中保留了这些层的引用第3-6层：来自 Dockerfile 构建
bash
# 对应您的 Dockerfile 指令
Layers[2]: "sha256:fe695ece85edd2ab4d1c0c6115d8febce80f51d2cab1d1b656440b5754c16678"
# FROM alpine:3.18 基础层
Layers[3]: "sha256:be4ad4a66fe7c00a1c5d51ad3915879114f774399a111d4db5971659d11959b6"
# ADD ./curl-amd64 /usr/bin/curl
Layers[4]: "sha256:6e819136eca5d4fa602bd1e8476786cdd429715c74c33b8536f5d25e554abad0"
# RUN chmod +x /usr/bin/curl + WORKDIR /app/ + ADD ./config.yaml /app/config.yaml
Layers[5]: "sha256:b4cc20de0a7c46f6ca41cc8f3579f56291936d90dd70735608b967b26d6eb76f"
# COPY --from=stage0 /src/0voiceGateway/0voiceGateway ./虽然最终镜像（stage1）不包含 stage0 的文件内容，但镜像元数据中仍然保留了这些层的引用：
go
// 镜像元数据结构
type ImageConfig struct {
RootFS struct {
Type string `json:"type"`
Layers []string `json:"layers"` // 所有引用到的层，包括构建阶段的引用
} `json:"rootfs"`
History []History `json:"history"` // 构建历史记录
}您可以通过以下命令验证：
bash
# 查看镜像的历史记录，会显示所有层的创建信息
docker history your-image-name终端输出可以看到
bash
qiming@k8s-master1:~$ docker history 0voice-gateway:v0.5.0
IMAGE CREATED CREATED BY SIZE COMMENT
d5542708ce1b 13 hours ago ENTRYPOINT ["./0voiceGateway"] 0B buildkit.dockerfile.v0
<missing> 13 hours ago COPY /src/0voiceGateway/0voiceGateway ./ # b... 20.2MB buildkit.dockerfile.v0
<missing> 13 hours ago ADD ./config.yaml /app/config.yaml # buildkit 356B buildkit.dockerfile.v0
<missing> 4 weeks ago WORKDIR /app/ 0B buildkit.dockerfile.v0
<missing> 4 weeks ago RUN /bin/sh -c chmod +x /usr/bin/curl # buil... 3.58MB buildkit.dockerfile.v0
<missing> 4 weeks ago ADD ./curl-amd64 /usr/bin/curl # buildkit 3.58MB buildkit.dockerfile.v0
<missing> 8 months ago CMD ["/bin/sh"] 0B buildkit.dockerfile.v0
<missing> 8 months ago ADD alpine-minirootfs-3.18.12-x86_64.tar.gz ... 7.36MB buildkit.dockerfile.v0RootFS.Layers 有 6 个层的原因是：
- 包含了多阶段构建的所有层引用，包括构建阶段（stage0）的层
- 镜像元数据记录了完整的构建历史和层依赖关系
- 内容寻址存储机制要求记录所有被引用的层哈希
而 GraphDriver.Data.LowerDir 只有 5 个路径是因为：
- 只包含实际的文件系统层（最终镜像中存在的文件）
- 反映了 Overlay2 存储驱动的实际磁盘结构
这种设计确保了：
- 层的高效共享（多个镜像可以引用相同的底层）
- 构建历史的完整性（可以追溯完整的构建过程）
- 存储的空间效率（实际只存储需要的文件数据）
镜像里面包含容器运行时的信息
我补充说明，GraphDriver.Data 字段的 UpperDir 和 WorkDir 是容器运行时的概念。镜像构建只创建只读的 LowerDir 层，每次运行容器时才会创建新的 UpperDir 和 WorkDir，同一个镜像的多个容器实例有各自独立的 UpperDir。
UpperDir 的作用
1、容器的可写层（比如我们在容器里面编译一个文件，那这个文件就会放在这个文件夹下）
bash
# 当您运行容器时：
docker run -it your-image /bin/sh
# Docker 会为这个容器实例创建一个 UpperDir
# 所有在容器内的修改都存储在这里2.、写时复制（Copy-on-Write）
bash
// 当容器修改文件时的流程：
func handleFileModification(filename string) {
// 1. 检查文件是否在 UpperDir 中已存在
if !existsInUpperDir(filename) {
// 2. 如果不存在，从 LowerDir 复制到 UpperDir
copyFromLowerToUpper(filename)
}
// 3. 在 UpperDir 中进行修改
modifyFileInUpperDir(filename)
}WorkDir 的作用（处理文件操作的事务性）
当容器进行文件操作时，WorkDir 用于：
- 文件重命名的原子操作
- 文件删除的标记处理
- 硬链接的临时处理
- 确保文件系统操作的一致性
类似于我们所理解的 C/C++ 原子操作，确保文件一致性不会被打破。实际工作流程是
bash
# 当删除文件时：
1. 在 WorkDir 中创建 "whiteout" 文件（标记删除）
2. 在 MergedDir 中隐藏原文件
3. 确保操作是原子的和一致的完整的 Overlay2 运行时结构
bash
+------------------------------------------------+
| MergedDir (合并视图) |
| 容器看到的统一文件系统，包含所有修改 |
+------------------------------------------------+
| UpperDir (可写层) |
| - 新建的文件: /app/test.txt |
| - 修改的文件: /app/config.yaml (复制后修改) |
| - 删除标记: /etc/nginx/nginx.conf.wh..wh..opq |
+------------------------------------------------+
| WorkDir (工作目录) |
| - 临时文件操作 |
| - 原子操作准备 |
+------------------------------------------------+
| LowerDir[0-4] (只读镜像层) |
| - 基础镜像文件 |
| - 构建时添加的文件 |
+------------------------------------------------+想象图景
Docker 的文件系统可以这样想像
运行镜像，将其变成 Docker 容器运行时
上文，我们构建完镜像之后，通过 docker inspect 观察到了镜像的多层构建细节，从而理解了 Docker 的文件系统架构，最终理解了它的运行规律。接下来，我们通过这段命令
bash
docker run -d --name [容器命名] -p [监听宿主机的端口]:[容器内网络条件的端口] [镜像名字]:[标签]来运行我们生成的两个镜像，生成容器运行时。
bash
qiming@k8s-master1:~$ docker run -d --name qiming-goods -p 50051:50051 goods:v0.5.0
f0d04556bb8baffa6cf8ba09367998d7490264e47c2bf41ef057d0d51ba5e740
qiming@k8s-master1:~$ docker run -d --name qiming-0voice-gateway -p 8081:8081 0voice-gateway:v0.5.0
ee891850ff17a063f48c409e8842b9b11ca4237fc4bedbbc0ec36980158eafd7--name qiming-0voice-gateway 是命名。-p 是端口映射，它非常之关键，因为没有它，就不能正常的监听宿主机的端口，他只会监听自己容器小空间内的端口，换言之是默认与容器内的程序通信，而非与宿主机通信。-d 是让容器以守护进程的方式运行。守护进程是在后台运行的计算机程序，它的特点是：
- 不直接与用户交互
- 没有控制终端
- 长期运行提供服务
- 通常在系统启动时自动运行
在上面的命令行中的一长串字符是 Docker 容器的完整 ID。
现在我们来检验一下，是否在正常运行，可以通过 docker ps 命令现实 docker 引擎正在管理的容器进程，注意 CONTAINER ID 只是显示了前面那一段，意思意思而已，ID 是同一个的。
bash
qiming@k8s-master1:~$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ee891850ff17 0voice-gateway:v0.5.0 "./0voiceGateway" 6 seconds ago Up 5 seconds 0.0.0.0:8081->8081/tcp, [::]:8081->8081/tcp qiming-0voice-gateway
f0d04556bb8b goods:v0.5.0 "./goods" About a minute ago Up About a minute 0.0.0.0:50051->50051/tcp, [::]:50051->50051/tcp qiming-goods而且事实上，他也是可以运行的
近距离观察 Docker 容器
我们可以通过这段命令
bash
docker exec -it [容器名] [容器内的可执行文件]进入容器这个小型的文件系统
bash
qiming@k8s-master1:~$ docker exec -it qiming-0voice-gateway sh
/app # ls
0voiceGateway config.yaml
/app # docker exec 命令的选项 -it 实质可分为 -i 和 -t
-i即--interactive：保持标准输入流（STDIN）打开，也就是不会立刻退出，保持交互性-t即--tty：分配一个伪终端（pseudo-TTY），也就是我们看到的终端
这个 docker 容器真的就是一个小型文件系统，他有很多的操作系统小工具（就是那个 alpine 镜像引进的），大家跟着我实验就好了
bash
/app # cd ..
/ # ls
app bin dev etc home lib media mnt opt proc root run sbin srv sys tmp usr var
/ #结尾：先删除镜像，后删除容器
退出容器，使用 exit 命令
bash
/ # exit
qiming@k8s-master1:~$停止容器 docker stop [容器名]
bash
qiming@k8s-master1:~$ docker stop qiming-goods
qiming-goods
qiming@k8s-master1:~$ docker stop qiming-0voice-gateway
qiming-0voice-gateway关掉容器 docker rm [容器名]
bash
qiming@k8s-master1:~$ docker rm qiming-goods
qiming-goods
qiming@k8s-master1:~$ docker rm qiming-0voice-gateway
qiming-0voice-gateway删除镜像 docker rmi [镜像名]:[标签]
bash
qiming@k8s-master1:~$ docker rmi 0voice-gateway:v0.5.0
Untagged: 0voice-gateway:v0.5.0
Deleted: sha256:d5542708ce1bf33c6ddc8fa5da784ae957306de83cf263b0a597084a4016f8f1
qiming@k8s-master1:~$ docker rmi goods:v0.5.0
Untagged: goods:v0.5.0
Deleted: sha256:714feb39b527f08ebb24816e1ce9901dd97ecf42e7d5418da45aed48afbc162e检查容器情况、镜像的删除情况情况分别用 docker ps 和 docker images，都删干净了
bash
qiming@k8s-master1:~$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
qiming@k8s-master1:~$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
ghcr.io/flannel-io/flannel v0.27.4 e83704a17731 5 weeks ago 91.4MB
ghcr.io/flannel-io/flannel-cni-plugin v1.8.0-flannel1 bb28ded63816 5 weeks ago 10.8MB
alpine 3.18 802c91d52981 8 months ago 7.36MB
golang 1.22.12 2fce09cfad57 9 months ago 823MB
registry.aliyuncs.com/google_containers/kube-apiserver v1.28.2 cdcab12b2dd1 2 years ago 126MB
registry.aliyuncs.com/google_containers/kube-scheduler v1.28.2 7a5d9d67a13f 2 years ago 60.1MB
registry.aliyuncs.com/google_containers/kube-controller-manager v1.28.2 55f13c92defb 2 years ago 122MB
registry.aliyuncs.com/google_containers/kube-proxy v1.28.2 c120fed2beb8 2 years ago 73.1MB
busybox latest a416a98b71e2 2 years ago 4.26MB
quay.io/jetstack/cert-manager-webhook v1.12.0 5059a762fd74 2 years ago 48.9MB
quay.io/jetstack/cert-manager-controller v1.12.0 eb0fa758c994 2 years ago 63.7MB
quay.io/jetstack/cert-manager-cainjector v1.12.0 8ec112cada1b 2 years ago 41.6MB
registry.aliyuncs.com/google_containers/etcd 3.5.9-0 73deb9a3f702 2 years ago 294MB
gcr.io/kubebuilder/kube-rbac-proxy v0.14.1 1da78bf35ce7 2 years ago 55.6MB
nginx 1.22.1 0f8498f13f3a 2 years ago 142MB
registry.aliyuncs.com/google_containers/coredns v1.10.1 ead0a4a53df8 2 years ago 53.6MB
registry.aliyuncs.com/google_containers/pause 3.9 e6f181688397 3 years ago 744kB
gcr.io/distroless/static nonroot ea2dc773e32d N/A 2.45MB