长久以来，主流计算机 CPU 都是 Intel x86 构架， AMD 将之扩展为 64 位 x86\_64 架构，又称为 amd64 。 “x86 CPU 有哪些？” “i5 i7 i386 i686 等” 。但主流并非唯一，业界一直存在多种 CPU 架构，如 MOS6502 MIPS PowerPC ARM 等。 Linux 很早就开始支持 ARM 的 64 位架构，社区称为 aarch64 。近年来 ARM 市场份额逐渐扩大，主流为 64 位构架 (即 aarch64) ，一般又称为 arm64 。许多手机 CPU 都是 arm64 构架，MacBook 2021 年开始从 Intel CPU 切换到 arm64 CPU ，华为也在购买 ARM 授权后分别设计了用于手机和服务器的采用 arm64 构架的 CPU 。微软 Windows 11 也开始支持 arm64 构架。
x86\_64 是最流行的 CPU 构架，毫无疑问，这也是 docker 镜像率先重点支持的 CPU 构架。时光倒流到 2016 年，执行如下命令，默认拉取的即是 x86\_64 构架的镜像。
docker pull ubuntu:16.04很快， docker 必须考虑支持其他多种 CPU 构架。如何支持呢？
镜像命名区分 CPU 构架
早期 docker 想到一个土办法：添加 CPU 架构名作为镜像命名空间前缀。如使用如下命令可分别拉取 amd64 和 arm64 构架的 ubuntu 镜像。
docker pull amd64/ubuntu:16.04
docker pull arm64v8/ubuntu:16.04这个办法简单可用，但有一些问题。
CPU 构架 “规范” 名称
问题 1 ： 如何确定 docker 约定的 CPU 构架 “规范” 名称是什么 ？
- x86 64 位构架为什么不使用 “x86\_64” 而使用 “amd64” ？
- ARM 64 位构架为什么即不使用 “aarch64” 也不使用 “arm64” 而是 “arm64v8” ？
使用 Tag 后缀区分构架
问题 2 ： 许多镜像注册中心按命名空间进行权限管控，应用开发没有权限在其他命名空间下发布镜像，无法遵循使用 CPU 架构名作为命名空间前缀的约定。
变通办法是不使用命名空间前缀，改为使用镜像名或 Tag 前缀或后缀区分。个人偏向于添加 Tag 后缀的变通方案。如：
docker image pull hanyong/ubuntu:20.04-x86_64
docker image pull hanyong/ubuntu:20.04-aarch64增加了使用镜像的复杂度
问题 3 ： 不同的 CPU 构架下使用不同的镜像名，需要用户感知当前 CPU 构架对应的镜像名称 (或 Tag) ， 增加了编写和维护 Dockerfile 的复杂性。
使用清单列表 (Manifest List) 支持多构架镜像
我是一名 Java 开发，我的工作电脑从 x86\_64 换成了 arm64 ，对我有什么影响？几乎毫无影响。操作系统和高级编程语言运行时封装了 CPU 构架等底层细节，无论什么 CPU 架构，编写的代码，使用的工具命令都是一样的，不需要感知 CPU 架构。
多个 CPU 构架下的镜像，提供了相同的逻辑功能，为什么要使用不同的镜像名呢？徒劳增加了开发者的认知负担。
因此，容器社区提出了使用统一的镜像名支持多种 CPU 构架的方案。 2017-09-12 后， docker 使用清单列表 (Manifest List) 功能实现了这一方案。
拉取多构架镜像
支持多架构镜像后，docker 自动根据当前 CPU 构架拉取对应的原生镜像。普通应用通常不需要感知 CPU 构架，基础镜像提供了相同的逻辑功能，此时只需要编写一份 Dockerfile ，在不同的 CPU 构架环境下，即可构建出当前 CPU 构架下的原生镜像。
# docker 自动根据当前 CPU 构架拉取对应的原生镜像
docker pull ubuntu:20.04有时候我们可能需要处理跨 CPU 构架的镜像，如我是 arm64 的机器，但是想查看一个 x86\_64 构架的镜像，可以吗？可以，新版本 docker 的 pull 命令可使用 --platform 选项明确指定要拉取的具体镜像， platform 不仅可指定 CPU 构架信息，还可以指定操作系统信息。
- 前面提到一种 CPU 构架可能有多个惯用名，如 x86\_64 和 amd64 ，命名空间前缀只能使用 docker 镜像注册中心约定的 “规范” 构架名，但 platform 参数使用任意一个惯用名均可，这也减轻了记忆 “规范” 构架名的负担。
- ubuntu 等官方镜像仍然保留了使用 CPU 构架命名空间的单构架镜像，拉取单架构镜像时指定
--platform选项无效。 - 本机一个镜像名只能对应单个镜像，使用不同的
--platform参数多次拉取一个镜像后，本机镜像名对应的镜像是最后一次拉取的镜像。
如下命令以两种方式显式拉取 x86\_64 构架的 ubuntu:20.04 镜像，可看到最终拉取到的是同一个镜像。
# 拉取 amd64 命名空间下的单架构镜像
docker image pull amd64/ubuntu:20.0
# 拉取多架构镜像在 x86_64 构架下的镜像
docker image pull --platform x86_64 ubuntu:20.04创建多构架镜像
docker 使用清单列表 (Manifest List) 支持多构架镜像。
什么是清单？ 将一个 docker 镜像推送到镜像注册中心后，镜像注册中心会记录镜像的存储信息，称为镜像清单 (Image Manifest) 。而清单列表则记录了多个镜像清单及其对应的平台 platform 信息。所谓多构架镜像，或多平台镜像，就是清单列表及其关联的多个单构架镜像。
创建多构架 (多平台) 镜像的操作步骤为：
- 创建多个单构架镜像。
- 将所有镜像推送到镜像注册中心，自动生成镜像清单。
- 汇总多个镜像清单得到清单列表，同样将清单列表推送 (存储) 到镜像注册中心上。新版本 docker 可使用 docker manifest 命令创建和推送清单列表。
Linux 支持交叉构建，即在一套环境下构建多种 CPU 构架下的镜像。为了简单起见，暂不讨论这种方案，暂采用在多个构架环境下创建各自的原生镜像的土办法。我使用的 docker 版本为 20.10.12 。这里以创建多架构镜像 hanyong/ubuntu:20.04 为例，介绍创建 docker 多构架镜像的实践操作步骤。
- 基于官方多架构镜像 ubuntu:20.04 编写 Dockerfile 。
在 x86\_64 机器上构建原生镜像，推送到镜像注册中心。
docker build --pull表示每次构建前自动拉取最新的基础镜像，基础镜像是多架构镜像 (清单列表) 时，自动更新到当前架构的最新镜像。docker build --pull -t hanyong/ubuntu:20.04-x86_64 . docker push hanyong/ubuntu:20.04-x86_64同样，在 arm64 机器上构建原生镜像，推送到镜像注册中心。
docker build --pull -t hanyong/ubuntu:20.04-aarch64 . docker push hanyong/ubuntu:20.04-aarch64使用推送到镜像注册中心的多个镜像创建清单列表。注意，前面为每个单架构镜像添加了不同的 Tag 后缀，以方便区分引用。将清单列表推送到镜像注册中心，删除本地副本 (清单列表只有存储在镜像注册中心上才有意义) 。
docker manifest create hanyong/ubuntu:20.04 hanyong/ubuntu:20.04-x86_64 hanyong/ubuntu:20.04-aarch64 docker manifest push hanyong/ubuntu:20.04 docker manifest rm hanyong/ubuntu:20.04
