容器镜像进阶

Dockerfile 编写注意事项：

选择合适的基础镜像，没必要追求镜像的绝对大小。
- alpine镜像不推荐，尤其是编译型业务，因为alpine镜像内置的musl libc库与标准的glibc不一样。
  - 如果就是想使用alpine镜像，推荐多阶段构建：第一阶段编译和第二阶段构建业务镜像都用alpine。
  - 另外一种就是在构建阶段指定静态链接的方式编译，或者直接关闭动态链接进行编译。(不推荐)
- scratch基础镜像构建出的镜像更小，但是没shell和日常运维工具，遇到问题都没法调试，因此不推荐使用。
固定基础镜像的tag，可以避免业务版本迭代因基础镜像版本变化导致版本依赖异常出现报错，也防止基础更新后引入了某些漏洞。
提前配置好时区，这样不用在创建容器时再挂载节点的/etc/localtime。
RUN 指定运行命令时，多个命令能一行就一行，可减少镜像层级。
尽量使用普通用户，提高安全性。(USER 尽量配置在RUN之后，避免提前指定普通用户后再执行RUN命令时没权限)
内容可变的命令尽量往后面写，充分利用 layer 缓存。比如业务迭代时，基础环境基本不变，而源代码文件变化，就需要将COPY动作尽量放在最后。
合理使用.dockerignore忽略特定目录，减少构建上下文，提高构建速度。

示例：
app.py

print("Hello World!")

Dockerfile

# syntax=docker/dockerfile:1
FROM debian:11.9-slim# time zone
ENV TZ=Asia/Shanghai \DEBIAN_FRONTEND=noninteractiveRUN ln -fs /usr/share/zoneinfo/${TZ} /etc/localtime \&& echo ${TZ} > /etc/timezone \&& dpkg-reconfigure --frontend noninteractive tzdata \&& rm -rf /var/lib/apt/lists/*# install python3
RUN apt-get update && apt-get install python3 -y# create user
RUN useradd -ms /bin/bash app
USER app# 
WORKDIR /app
COPY ./app.py .CMD ["python3", "app.py"]

PS：Apline 镜像设置时区。

ENV TZ Asia/Shanghai
RUN apk add tzdata && cp /usr/share/zoneinfo/${TZ} /etc/localtime \&& echo ${TZ} > /etc/timezone \&& apk del tzdata

了解镜像的本质

OCI(Open Container Initiative) 定义了镜像规范，一个镜像包含mainfest、config和layer，以前面 Dockerfile 构建的镜像为例：

$ docker save app:v1.1.0 -o app.tar.gz
$ tar -xf app.tar.gz  -C /app/
$ tree /app/
/app/
├── 497849218290a94cb34b80362259608372291b4a627ebe1df31e10c4ba31542a.json
├── 4bb5a4f3796061d36102ab2a02496b6743d7466aba6990ba688f829a9e8339e4
│   ├── json
│   ├── layer.tar
│   └── VERSION
├── 5000c6cdfdc56cf0cd09ec29875b1595f2c2da52675275b4318536102cb513cb
│   ├── json
│   ├── layer.tar
│   └── VERSION
├── 5b8017498a1df453e50796084f1653f97a3c04ace677d1162242a26e8330dc48
│   ├── json
│   ├── layer.tar
│   └── VERSION
├── 5d0dcfe38cafda7547115d0bbe4588ea00dd24f1218fb057274d58c247129dd0
│   ├── json
│   ├── layer.tar
│   └── VERSION
├── 8bd937ecf07b05d37d564be434b754155a76eacafeca1d0a17a1af57c868c1db
│   ├── json
│   ├── layer.tar
│   └── VERSION
├── c311739e92e5fa7e89abbe7a40650842d4122df07f505b4213b8d0110bc3896b
│   ├── json
│   ├── layer.tar
│   └── VERSION
└── manifest.json

其中 layer.tar 也可以解压，解压后的内容就是 Dockerfile 中指令对镜像所产生的变更，以上面最后一个 layer 为例：

# tar xf layer.tar -C test/
root@VM-0-4-ubuntu:/app/4bb5a4f3796061d36102ab2a02496b6743d7466aba6990ba688f829a9e8339e4# tree test/
test/
└── app└── app.py

到这里可以看出，容器镜像其实就是多层 layer 的堆叠，通过 Dockerfile 构建镜像时，Dockerfile 中的 RUN、COPY、ADD 等指令，会生成一个镜像层(layer)，每个镜像层的名称以它内容的 hash 命名，在对容器镜像进行更新操作(build或pull)时，会判断每个镜像层的 hash，当节点中已经存在相同的镜像层时就会跳过这一镜像层的步骤，从而实现增量更新，这里用到的一项技术就是联合文件系统(Union FS)，下面通过一个简单的示例来理解下。

联合文件系统示例(OverlayFS)

1 创建模拟目录，并为各个目录添加文件并写入数据

$ mkdir upper lower merged work
$ echo "from lower" > lower/in_lower.txt
$ echo "from upper" > upper/in_upper.txt
$ echo "from lower" > lower/in_both.txt
$ echo "from upper" > upper/in_both.txt

2 指定挂载类型为 overlay2

$ mount -t overlay -o lowerdir=`pwd`/lower,upperdir=`pwd`/upper,workdir=`pwd`/work none `pwd`/merged

3 查看 merged 挂载点的内容

$ ls merged/
in_both.txt  in_lower.txt  in_upper.txt$ cat merged/in_both.txt 
from upper     # 到这里可以看出上层 Layer 会覆盖下层 Layer 的同名文件

4 修改合并层(merged)文件展示

# 修改 overlay 合并层中位于 lowerdir 的 in_lower.txt 文件
$ echo 111 >> in_lower.txt # 不会对 lower_dir 产生修改
$ cat ../lower/in_lower.txt 
from lower# 但在 upperdir 里新增加了之前没有的 in_lower.txt 文件，这就是“写时复制”的功能
$ ls ../upper/
in_both.txt  in_lower.txt  in_upper.txt
$ cat ../upper/in_lower.txt 
from lower
111

5 删除合并层(merged)文件展示

# 删除 in_lower.txt 和 in_both.txt
$ rm -f in_lower.txt in_both.txt# 在 lowerdir 的文件并没有被删除
$ ls -l ../lower/
total 8
-rw-r--r-- 1 root root 11 Apr 13 19:43 in_both.txt
-rw-r--r-- 1 root root 11 Apr 13 19:43 in_lower.txt# 而在 upperdir 中被标记为了 C，代表该文件已删除
$ ls -l ../upper/
total 4
c--------- 3 root root 0, 0 Apr 13 19:57 in_both.txt
c--------- 3 root root 0, 0 Apr 13 19:57 in_lower.txt
-rw-r--r-- 1 root root   11 Apr 13 19:43 in_upper.txt

构建多平台镜像

docker 镜像一次构建，到处运行的概念只适用于同架构平台下，不同架构平台下是无法运行的，比如会遇到报错：standard_init_linux.go:211: exec user process caused “exec format error”。

而默认情况下，某个架构平台上构建的镜像只支持当前架构(比如amd64)，这时就需要使用 buildkit 多平台构建的能力，不过不用担心它有多复杂，一条命令就可以实现：

前提：与 Docker 一起使用 buildx 需要 Docker 引擎 19.03 或更高版本，推荐直接使用 20.10 及以上版本，不然还得安装 docker-buildx-plugin。

# 创建新的 docker-container 驱动程序，它支持使用 QEMU（用户模式）构建非本机平台。
$ docker buildx create --name=container --driver=docker-container --use --bootstrap# 查看驱动程序。(以容器方式运行，当然还有其他方式：https://docs.docker.com/build/drivers/)
$ docker buildx ls
NAME/NODE        DRIVER/ENDPOINT                   STATUS    BUILDKIT               PLATFORMS
container*       docker-container                                                   \_ container0    \_ unix:///var/run/docker.sock   running   v0.13.1                linux/amd64, linux/amd64/v2, linux/amd64/v3, linux/amd64/v4, linux/386
default          docker                                                             \_ default       \_ default                       running   v0.11.6+0a15675913b7   linux/amd64, linux/amd64/v2, linux/amd64/v3, linux/amd64/v4, linux/386# 使用 --platform 构建多平台镜像。
$ docker buildx build --platform linux/amd64,linux/arm64 -t hkccr.ccs.tencentyun.com/panbuhei/app:v2.0.0 --push .

PS1：注意 Dockerfile 中 FROM 指定的基础镜像要支持多平台，不然也是不行的。
PS2：指定 --platform 后构建的镜像时 OCI 类型的，直接 docker build 构建的是 Docker 类型，使用上没什么区别，只是有的仓库不支持 OCI 类型的镜像，比如华为云的SWR。

怎么查看镜像是哪种类型，可以使用 crane 镜像调试工具查看镜像的 manifest ，其中 mediaType 就可以看出，如下：

这时有人可能就会有疑问，为什么我不同架构平台拉取 dockerhub 上相同的镜像版本运行就是正常的？这是因为 docker 把不同架构的镜像都写在了 manifest 里，拉取镜像时会自动拉取和当前架构相同的镜像。

下面是 dockerhub 上 debian 镜像某一个版本的所有平台信息( OS 类型)。

我们可以使用 crane 镜像调试工具查看 dockehub 上的某个镜像的 manifest。

$ crane manifest debian:11.9-slim | jq .
{"manifests": [{"digest": "sha256:d1268324d1e3a3350098ac69d9628f162105355dfe8f48260caed6a7c001d3ad","mediaType": "application/vnd.docker.distribution.manifest.v2+json","platform": {"architecture": "amd64","os": "linux"},"size": 529},{"digest": "sha256:1ed5e23dcc59f130aa095b70e8fdbc422c6b9bba947df1ec48e606f2ecc3569e","mediaType": "application/vnd.docker.distribution.manifest.v2+json","platform": {"architecture": "arm","os": "linux","variant": "v5"},"size": 529},{"digest": "sha256:2786611dfd6c17bcc0225794e875cdbf2faf7ebf943bd88fcde8baea61a4b673","mediaType": "application/vnd.docker.distribution.manifest.v2+json","platform": {"architecture": "arm","os": "linux","variant": "v7"},"size": 529},{"digest": "sha256:5e3e0f1da7c83ffee19a476630222cff8cffc3680523bafd564e98622add32f5","mediaType": "application/vnd.docker.distribution.manifest.v2+json","platform": {"architecture": "arm64","os": "linux","variant": "v8"},"size": 529},{"digest": "sha256:e5ce0b22ac2110605753e8e6eab2d5bfce1790caaecaa13649fa07dcfad25001","mediaType": "application/vnd.docker.distribution.manifest.v2+json","platform": {"architecture": "386","os": "linux"},"size": 529},{"digest": "sha256:73321ba66eb2f5243a389c411825615b8568b09b22d1843b59a7c1eb7fc1e6a3","mediaType": "application/vnd.docker.distribution.manifest.v2+json","platform": {"architecture": "mips64le","os": "linux"},"size": 529},{"digest": "sha256:f2ada486b4250c51599b6b0bbfeef5caa5a6862b5f2aa4620af2989e39228ad9","mediaType": "application/vnd.docker.distribution.manifest.v2+json","platform": {"architecture": "ppc64le","os": "linux"},"size": 529},{"digest": "sha256:881f31801aa86d64bbfb066b1fe8e7a26b7dd4e867bb33dc7dfc316565f3ed6b","mediaType": "application/vnd.docker.distribution.manifest.v2+json","platform": {"architecture": "s390x","os": "linux"},"size": 529}],"mediaType": "application/vnd.docker.distribution.manifest.list.v2+json","schemaVersion": 2
}

接着再使用 crane export -v 大概看下拉取镜像的整个请求过程来理解。

$ crane export -v debian:11.9-slim - | tar -Oxf - etc/passwd
2024/04/13 13:20:31 --> GET https://index.docker.io/v2/
2024/04/13 13:20:31 GET /v2/ HTTP/1.1
Host: index.docker.io
User-Agent: crane/0.19.1 go-containerregistry/0.19.1
Accept-Encoding: gzip##### 从下面的请求返回可以看出，先请求了镜像的 manifest 接口。2024/04/13 13:20:32 <-- 200 https://index.docker.io/v2/library/debian/manifests/11.9-slim (297.534463ms)
...
...{"manifests":[{"digest":"sha256:d1268324d1e3a3350098ac69d9628f162105355dfe8f48260caed6a7c001d3ad","mediaType":"application\/vnd.docker.distribution.manifest.v2+json","platform":{"architecture":"amd64","os":"linux"},"size":529},{"digest":"sha256:1ed5e23dcc59f130aa095b70e8fdbc422c6b9bba947df1ec48e606f2ecc3569e","mediaType":"application\/vnd.docker.distribution.manifest.v2+json","platform":{"architecture":"arm","os":"linux","variant":"v5"},"size":529},{"digest":"sha256:2786611dfd6c17bcc0225794e875cdbf2faf7ebf943bd88fcde8baea61a4b673","mediaType":"application\/vnd.docker.distribution.manifest.v2+json","platform":{"architecture":"arm","os":"linux","variant":"v7"},"size":529},{"digest":"sha256:5e3e0f1da7c83ffee19a476630222cff8cffc3680523bafd564e98622add32f5","mediaType":"application\/vnd.docker.distribution.manifest.v2+json","platform":{"architecture":"arm64","os":"linux","variant":"v8"},"size":529},{"digest":"sha256:e5ce0b22ac2110605753e8e6eab2d5bfce1790caaecaa13649fa07dcfad25001","mediaType":"application\/vnd.docker.distribution.manifest.v2+json","platform":{"architecture":"386","os":"linux"},"size":529},{"digest":"sha256:73321ba66eb2f5243a389c411825615b8568b09b22d1843b59a7c1eb7fc1e6a3","mediaType":"application\/vnd.docker.distribution.manifest.v2+json","platform":{"architecture":"mips64le","os":"linux"},"size":529},{"digest":"sha256:f2ada486b4250c51599b6b0bbfeef5caa5a6862b5f2aa4620af2989e39228ad9","mediaType":"application\/vnd.docker.distribution.manifest.v2+json","platform":{"architecture":"ppc64le","os":"linux"},"size":529},{"digest":"sha256:881f31801aa86d64bbfb066b1fe8e7a26b7dd4e867bb33dc7dfc316565f3ed6b","mediaType":"application\/vnd.docker.distribution.manifest.v2+json","platform":{"architecture":"s390x","os":"linux"},"size":529}],"mediaType":"application\/vnd.docker.distribution.manifest.list.v2+json","schemaVersion":2}##### 找到当前架构平台的 digest，并发起 GET 请求获取它的 manifest。(这个信息使用crane manifest指定具体版本同样也能获取到)2024/04/13 13:20:33 <-- 200 https://index.docker.io/v2/library/debian/manifests/sha256:d1268324d1e3a3350098ac69d9628f162105355dfe8f48260caed6a7c001d3ad (240.775982ms)
...
...{"schemaVersion": 2,"mediaType": "application/vnd.docker.distribution.manifest.v2+json","config": {"mediaType": "application/vnd.docker.container.image.v1+json","size": 1463,"digest": "sha256:500fb7ca53f527bb47b74171f664818c6721286edbfc32afd14e3fdc3f3f82be"},"layers": [{"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip","size": 31427738,"digest": "sha256:04e7578caeaa5a84ad5d534aabbb307a37c85f9444b94949d37544a1c69c8f15"}]
}##### 最后才是真正的拉取镜像的 layer
2024/04/13 13:20:33 --> GET https://index.docker.io/v2/library/debian/blobs/sha256:04e7578caeaa5a84ad5d534aabbb307a37c85f9444b94949d37544a1c69c8f15 [body redacted: omitting binary blobs from logs]
...
...

PS：再介绍两个常用的 crane 命令。

# 查看镜像的所有 tag
$ crane ls debian# 复制所有平台的镜像到指定的仓库
$ crane cp debian:11.9-slim hkccr.ccs.tencentyun.com/panbuhei/debian:11.9-slim