docker镜像构建

基本的构建命令为： docker build -t name:tag -f Dockerfile .
-t: 表示构建出来的镜像名称
-f: 表示构建使用的dockerfile文件名称
.: 表示构建使用当前路径作为上下文（contex），如果你是在根目录/下面构建，不建议使用.（不建议使用根路径作为上下文），因为根路径下面有虚拟文件系统，如/proc之类的，构建的时候会报找不到文件的错误。

contextpath和dockerfile

镜像构建流程为首先将指定的上下文（contextpath）路径下的文件打包，发送到服务端。服务端再将收到的文件解压，然后以解压后的路径作为上下文，进行镜像构建。

docker构建命令中如果没有以-f指定Dockerfile，则以上下文中的Dockerfile文件作为构建文件；如果通过-f指定了Dockerfile文件路径及名称，则在构建上下文中寻找指定的文件。

构建缓存

docker build的时候，如果某一层无法使用上一次的构建缓存，则后续层均无法使用，故若大多数层均未改变，建议将未改动的层放在前面。如RUN apt get install -y tmux命令，如果tmux版本有变化，则无法继续使用构建缓存，建议将该语句放到后面。
参考：https://blog.orenoid.com/2019/12/17/docker-build-optimize/。
--no-cache=true可以不使用缓存，不知道能否解决构建时提示缓存不足的问题。

多阶段构建

FROM golang:alpine as builder  // 使用该镜像作为编译镜像并编译
...
go build -o /go/src/github.com/go/helloworld/app

FROM alpine:latest as prod    // 使用该镜像作为最终镜像的base镜像
...
COPY --from=builder /go/src/github.com/go/helloworld/app .   // 拷贝上一步编译得到的二进制。
...
CMD [""./app"]

可以直接编译得到最终镜像：docker build -t go/helloworld:3 .

也可以只构建builder阶段的镜像： docker build --target builder -t username/imagename:tag .

构建时，可以复制上一阶段的镜像中的文件，也可以复制任意镜像中的文件。

COPY --from=nginx:latest /etc/nginx/nginx.conf /nginx.conf

as后面的名字可以任意填写，主要作用是作为一个标识，方便单独构建其中一个镜像，或者是其他镜像从中获取部分文件。

参考： https://yeasy.gitbook.io/docker_practice/image/multistage-builds/laravel

构建多架构支持的镜像

• 原理：当用户获取一个镜像时，Docker 引擎会首先查找该镜像是否有 manifest 列表，如果有的话 Docker 引擎会按照 Docker 运行环境（系统及架构）查找出对应镜像。如果没有的话会直接获取镜像。

• 查看：docker manifest inspect golang:alpine查看镜像的manifest。需要开启实验特性才能查看manifest，开启方法为：

  export DOCKER_CLI_EXPERIMENTAL=enabled

• 构建方法：(注：下面省略了tag，默认为latest)

  1. 分别构建不同架构的镜像，如username/x8664-test, username/arm64v8-test，并推送到dockerhub。

  2. 然后创建manifest列表，docker manifest create username/test username/x8664-test username/arm64v8-test。
     如果要修改可以使用-a， --amend。如docker manifest create -a username/test username/x86_64-test username/arm64_v8-test

  3. 设置manifest列表 docker manifest annotate username/test username/x8664-test --os linux --arch x86_64, docker manifest annotate username/test username/arm64v8-test --os linux --arch arm64 --variant v8
     注意：此处的os， arch要和docker inspect命令中得到的一致。

  4. 推送到dockerhub。docker manifest push username/test

  5. 使用： docker pull username/test在不同架构的操作系统下执行会拉取到各自架构的镜像。当然，也可以手动指定架构来拉取，如在x86机器下拉取arm镜像，可以通过docker pull --platform=arm64 nginx:latest拉取。

其他构建工具

buildah

没有守护进程，不需要 root 特权，而且生成的是符合 OCI 的镜像，因此你的镜像的运行方式与使用 Docker 构建的镜像完全相同。它还能使用 Dockerfile 或 Containerfile 构建镜像， Dockerfile 与 Containerfile 实际上是同一个东西，只是叫法不同罢了。除此之外，Buildah 还提供了对镜像层更精细的控制，支持提交大量的变更到单个层。我认为，它与 Docker 之间有一个出乎意料的区别（但这个区别是好事），那就是使用 Buildah 构建的镜像特定于用户，因此你可以只列出自己构建的镜像。

Kaniko

Google 发布了“ Kaniko ”，一种用于在未授权容器或 Kubernetes 集群中构建容器镜像的开源工具。虽然 Kaniko 也是根据用户给定的 Dockerfile 构建镜像，但是并不依赖于 Docker 守护进程，而是在用户空间中完全执行每个命令，并对所导致的文件系统更改做快照。一般多用于在流水线中执行的编译构建。它与 Buildah 的主要区别在于，Kaniko 更加侧重于 Kubernetes 中的镜像构建。

另外需要制定镜像仓库名字，从而自动推送到目标仓库。

--context：指定构建上下文（可以挂载本地目录，也可以指定git地址，如git://github.com/mycorp/my-app.git），

--destination：指定要推送的仓库地址，

--dockerfile：指定dockerfile文件。存在一个问题是，tag是写死的，每次得到的镜像会覆盖。

k8s中使用：https://segmentfault.com/a/1190000039713484

buildkit

并行构建、跳过未使用的阶段、更好的增量构建以及不需要 root 权限等构建。但是，它仍然需要运行守护进程 (buildkitd)。因此，如果你不想摆脱 Docker，同时又想要一些新的功能和改进，那么可以考虑一下 buildkit。