尧图网页设计 
Dapr Docker 镜像 Tag 命名规范全解析从 ENG-001 决策记录到构建流水线的落地实现【免费下载链接】daprDapr is a portable runtime for building distributed applications across cloud and edge, combining event-driven architecture with workflow orchestration.项目地址: https://gitcode.com/GitHub_Trending/da/dapr本篇指南围绕 Dapr 官方仓库中的架构决策记录 ENG-001: Image Tagging 展开解读 Dapr 在采用 Docker 镜像仓库存储制品后为镜像与 Tag 制定的统一命名规范namespace/repository:tag与version-architecture两种 tag 形态并结合仓库中的构建脚本 docker/docker.mk、Makefile 与发布流水线 .github/workflows/dapr.yml 的源码级实现说明该规范如何在多仓库、多版本、多架构Linux/ARM/Windows场景下真正落地。读完本文你将掌握 Dapr 镜像的完整命名规则、tag 后缀的生成逻辑、多架构 manifest 的合并方式以及在实际构建与发布中如何设置DAPR_REGISTRY、DAPR_TAG等关键变量。一、决策背景为什么需要一套统一的镜像命名规范当 Dapr 开始全面使用 Docker 镜像仓库来存放运行时制品时面临三个客观约束多仓库项目需要同时支持多个镜像仓库registry例如私有 ACR 与公共 daprio ACR多版本同一份代码需要产出正式版如v1.16.0与预发布版如v0.1.0-alpha等不同版本的镜像多架构镜像需要覆盖 Linux amd64、Linux arm/v7、Linux arm64/v8乃至 Windows 1809 / ltsc2022 等不同 CPU 架构与操作系统组合。在这样的前提下如果每次构建都临时起意地取名很快会出现 tag 冲突、镜像难以定位、CI/CD 无法自动化拉取等问题。因此 Dapr 需要一个公认且恒定accepted and constant的镜像命名方式这正是 ENG-001 决策记录产生的直接动机。该记录当前状态为Accepted意味着它已成为 Dapr 后续所有镜像制品命名的强制约定。二、核心规范Decisions两条不可违反的命名规则决策记录给出了两条规则它们是整套命名体系的地基规则一镜像必须符合三段式格式一个镜像遵循如下格式namespace/repository:tagnamespace镜像仓库的命名空间/主机名例如actionscore.azurecr.io决策记录撰写时的 ACR 地址或当前 Makefile 中默认的daprio.azurecr.iorepository镜像仓库名例如dapr整体系统镜像或daprd、placement、sentry、operator、injector、scheduler各组件独立镜像tag镜像版本标签遵循下一条规则。规则二Tag 必须是版本号或版本号-架构一个合法的 tag 遵循如下格式version-architecture或仅version此时架构默认为 Linux即省略架构后缀时默认代表 Linux 架构的镜像。这一默认 Linux的约定在仓库的构建脚本中也有对应体现Makefile 中TARGET_OS ? linux、TARGET_ARCH ? amd64默认构建目标就是 Linux amd64。三、规范落地docker.mk 中的源码级实现仅停留在决策层面还不够关键在于构建脚本是否严格遵循了这两条规则。阅读 docker/docker.mk 可以发现规范被精确地翻译成了 Make 变量与构建目标。3.1 镜像名namespace/repository的拼装# docker/docker.mk L27-L33 DAPR_SYSTEM_IMAGE_NAME?$(RELEASE_NAME) # 默认 dapr DAPR_RUNTIME_IMAGE_NAME?daprd DAPR_PLACEMENT_IMAGE_NAME?placement DAPR_SENTRY_IMAGE_NAME?sentry DAPR_OPERATOR_IMAGE_NAME?operator DAPR_INJECTOR_IMAGE_NAME?injector DAPR_SCHEDULER_IMAGE_NAME?scheduler ... # docker/docker.mk L93-L99 DOCKER_IMAGE$(DAPR_REGISTRY)/$(DAPR_SYSTEM_IMAGE_NAME) DAPR_RUNTIME_DOCKER_IMAGE$(DAPR_REGISTRY)/$(DAPR_RUNTIME_IMAGE_NAME)其中DAPR_REGISTRY即namespace部分而RELEASE_NAME在 Makefile 中默认值为dapr也就是repository部分。最终拼出的完整镜像引用形如daprio.azurecr.io/dapr、daprio.azurecr.io/daprd与决策记录中的示例actionscore.azurecr.io/dapr:latest结构完全一致只是 registry 地址从当年的actionscore.azurecr.io演进到了当前的daprio.azurecr.io见 Makefile 的HELM_REGISTRY?daprio.azurecr.io。3.2 Tagversion-architecture的拼装# docker/docker.mk L73-L81 # 若设置 WINDOWS_VERSION则 tag 中嵌入 Windows 版本号 ifneq ($(WINDOWS_VERSION),) BUILD_ARGS--build-arg WINDOWS_VERSION$(WINDOWS_VERSION) DOCKER_IMAGE_VARIANT$(TARGET_OS)-$(WINDOWS_VERSION)-$(TARGET_ARCH) else DOCKER_IMAGE_VARIANT$(TARGET_OS)-$(TARGET_ARCH) endif ... # docker/docker.mk L100 BUILD_TAG$(DAPR_TAG)-$(DOCKER_IMAGE_VARIANT)这里把决策记录中的version-architecture落地为更精确的DAPR_TAG-os-arch如1.16.0-linux-amd64并针对 Windows 增加了版本维度如1.10.0-rc.2-windows-ltsc2022-amd64这是对决策规则的自然细化——因为实际发布需要区分操作系统而不仅仅是 CPU 架构。关键变量含义如下变量默认值/来源作用DAPR_TAG必须显式设置见check-docker-env版本号主体如1.16.0、0.1.0-alphaTARGET_OSlinuxMakefile目标操作系统如 linux / windows / darwinTARGET_ARCHamd64Makefile目标 CPU 架构如 amd64 / arm / arm64WINDOWS_VERSION未设置Windows 专属版本号如 ltsc2022设置后嵌入 tag构建脚本通过check-docker-env目标强制校验前提条件未设置DAPR_REGISTRY或DAPR_TAG时直接报错docker/docker.mk从机制上保证任何产出的镜像都必然符合规范。3.3 架构别名与平台映射决策记录中的architecture在实现里有一套归一化映射防止出现命名歧义# docker/docker.mk L56-L64 DOCKER_IMAGE_ARCH:amd64 ifeq ($(TARGET_ARCH),arm) DOCKER_IMAGE_ARCH:arm/v7 else ifeq ($(TARGET_ARCH),arm64) DOCKER_IMAGE_ARCH:arm64/v8 endif DOCKER_IMAGE_PLATFORM$(TARGET_OS)/$(DOCKER_IMAGE_ARCH) DOCKER_BUILDX_PLATFORMS$(TARGET_OS)/arm/v7,$(TARGET_OS)/arm64/v8,$(TARGET_OS)/amd64可见tag 中的arm对应 Docker 平台的linux/arm/v7arm64对应linux/arm64/v8而amd64对应linux/amd64。同时 Makefile 会依据本机 CPU 自动探测TARGET_ARCH_LOCALarmv8→arm64、armv7→arm等用于判断是否需要走跨架构模拟构建。四、多架构支持单个 tag 背后是 manifest 列表决策记录强调支持不同架构的诉求落地方案是每个不可变版本 tag 之下实际发布一组带架构后缀的镜像再合并成多架构 manifest。4.1 支持的架构矩阵# docker/docker.mk L67 DOCKER_MULTI_ARCH?linux-amd64 linux-arm linux-arm64 windows-1809-amd64 windows-ltsc2022-amd64这组字符串同时就是 tag 后缀的枚举1.16.0-linux-amd64、1.16.0-linux-arm、1.16.0-linux-arm64、1.16.0-windows-1809-amd64、1.16.0-windows-ltsc2022-amd64。4.2 manifest 合并docker-manifest-create# docker/docker.mk L282-L284节选 $(DOCKER) manifest create --amend $(DOCKER_IMAGE):$(DAPR_TAG) $(DOCKER_MULTI_ARCH:%$(DOCKER_IMAGE):$(MANIFEST_TAG)-%) $(DOCKER) manifest push --purge $(DOCKER_IMAGE):$(DAPR_TAG)该目标把各架构的独立镜像通过docker manifest create --amend聚合到不带架构后缀的DAPR_TAG如daprio.azurecr.io/dapr:1.16.0之下使用户只拉取一个 tagDocker 便会按运行平台自动选择对应架构的镜像。4.3latest的语义指向不可变版本值得注意的是构建脚本对latest的处理刻意保持不可变语义# docker/docker.mk L83-L90 ifeq ($(MANIFEST_TAG),) MANIFEST_TAG$(DAPR_TAG) endif ifeq ($(MANIFEST_LATEST_TAG),) # latest manifest tag 会指向不可变版本 tag # 例如latest - 1.11.0-linux-amd64 1.11.0-linux-arm 1.11.0-linux-arm64 ... MANIFEST_LATEST_TAG$(DAPR_TAG) endif即latest这个浮动标签最终指向的是具体的、不可变的版本架构镜像docker/docker.mk 在LATEST_RELEASEtrue时执行该合并而不是被反复覆盖的可变内容——这保证了生产环境拉取latest时行为的确定性。五、CI/CD 中的实际应用DAPR_TAG 如何被注入命名规范最终要服务发布流程。在 .github/workflows/dapr.yml 中可以看到规范的实际使用方式# Linux amd64 / arm64 等常规架构 DAPR_TAG${{ env.REL_VERSION }} make docker-push # MarinerCBL-Mariner 基础镜像变体追加 -mariner 后缀 DOCKERFILEDockerfile-mariner DAPR_TAG${{ env.REL_VERSION }}-mariner make docker-push # Windows 镜像tag 追加 -windows-amd64 DAPR_TAG${{ env.REL_VERSION }}-windows-amd64 \ make docker-publish见 .github/workflows/dapr.yml、.github/workflows/dapr.yml这里体现了两个规范细节REL_VERSION版本号与架构后缀由不同环节负责版本号由 CI 环境变量注入DAPR_TAG架构后缀则由docker.mk根据TARGET_OS/TARGET_ARCH自动拼接二者解耦特殊基础镜像使用显式后缀基于 docker/Dockerfile-mariner 构建的镜像使用-mariner后缀、Windows 使用-windows-amd64均是对version-suffix约定的扩展保持可读性与可追溯性。此外发布流程末尾会执行docker-publish即docker-manifest-create将各架构镜像合并为多架构 manifest 后再交付.github/workflows/dapr.yml与 4.2 节描述完全对应。六、后果与实战遵循规范构建自己的 Dapr 镜像决策记录的 Consequences 部分指出该规范与业界广泛接受的 Docker 命名惯例保持一致并为未来所有镜像命名提供了清晰指引。落到实践层面这意味着6.1 本地构建示例克隆仓库后你可以通过环境变量完全掌控镜像命名# 构建 Linux amd64 的 dapr 系统镜像tag 为 1.16.0-linux-amd64 make DAPR_REGISTRYdaprio.azurecr.io DAPR_TAG1.16.0 \ TARGET_OSlinux TARGET_ARCHamd64 docker-build # 交叉构建 ARM64 镜像自动走 buildx qemu 模拟见 docker.mk L149-L176 make DAPR_REGISTRYdaprio.azurecr.io DAPR_TAG1.16.0 \ TARGET_OSlinux TARGET_ARCHarm64 docker-build # 构建并推送然后合并为多架构 manifestdocker-publish docker-manifest-create make DAPR_REGISTRYdaprio.azurecr.io DAPR_TAG1.16.0 docker-publish其中TARGET_ARCHarm64与本地架构不一致时脚本会自动安装tonistiigi/binfmt模拟器并创建名为daprbuild_multi的 buildx 构建器docker/docker.mk这正是多架构镜像得以产出的底层机制。6.2 解读镜像 tag 的三个要点看 tag 即可判断平台-linux-amd64/-linux-arm/-linux-arm64/-windows-ltsc2022-amd64一目了然无后缀即 Linux决策记录明确省略架构时默认 Linuxdapr:latest即 Linux 多架构 manifest版本号保持不可变每个REL_VERSION对应的架构镜像一经发布即为不可变制品latest只做指向不做覆盖docker/docker.mk。6.3 与 Helm 部署的衔接同样的命名变量还会透传到 Helm 部署环节Makefile 在生成部署清单时执行--set-string global.tag$(DAPR_TAG) --set-string global.registry$(DAPR_REGISTRY)也就是说你在构建阶段设置的DAPR_TAG/DAPR_REGISTRY与集群中实际拉取的镜像 tag 是同一套值从而保证构建什么、部署什么完全一致。七、总结ENG-001 是一份短小但影响深远的架构决策它用两条规则镜像三段式格式、tag 的版本-架构形态统一了 Dapr 全部镜像制品的命名而其思想在 docker/docker.mk 中得到了忠实且更精细的落地——通过BUILD_TAG$(DAPR_TAG)-$(TARGET_OS)-$(TARGET_ARCH)的变量组合、架构别名映射、多架构 manifest 合并以及 CI 中DAPR_TAG的注入最终形成了一套版本不可变、平台可区分、latest 可确定的镜像治理体系。对于任何需要为多架构、多仓库项目设计镜像命名规范的团队这份决策记录及其实现都是一个值得直接复用的范本。进一步阅读完整的决策记录索引见 docs/decision_records/decision_records.md其余工程类决策记录位于 docs/decision_records/engineering/ 目录下。【免费下载链接】daprDapr is a portable runtime for building distributed applications across cloud and edge, combining event-driven architecture with workflow orchestration.项目地址: https://gitcode.com/GitHub_Trending/da/dapr创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Dapr Docker 镜像 Tag 命名规范全解析：从 ENG-001 决策记录到构建流水线的落地实现
Dapr Docker 镜像 Tag 命名规范全解析从 ENG-001 决策记录到构建流水线的落地实现【免费下载链接】daprDapr is a portable runtime for building distributed applications across cloud and edge, combining event-driven architecture with workflow orchestration.项目地址: https://gitcode.com/GitHub_Trending/da/dapr本篇指南围绕 Dapr 官方仓库中的架构决策记录 ENG-001: Image Tagging 展开解读 Dapr 在采用 Docker 镜像仓库存储制品后为镜像与 Tag 制定的统一命名规范namespace/repository:tag与version-architecture两种 tag 形态并结合仓库中的构建脚本 docker/docker.mk、Makefile 与发布流水线 .github/workflows/dapr.yml 的源码级实现说明该规范如何在多仓库、多版本、多架构Linux/ARM/Windows场景下真正落地。读完本文你将掌握 Dapr 镜像的完整命名规则、tag 后缀的生成逻辑、多架构 manifest 的合并方式以及在实际构建与发布中如何设置DAPR_REGISTRY、DAPR_TAG等关键变量。一、决策背景为什么需要一套统一的镜像命名规范当 Dapr 开始全面使用 Docker 镜像仓库来存放运行时制品时面临三个客观约束多仓库项目需要同时支持多个镜像仓库registry例如私有 ACR 与公共 daprio ACR多版本同一份代码需要产出正式版如v1.16.0与预发布版如v0.1.0-alpha等不同版本的镜像多架构镜像需要覆盖 Linux amd64、Linux arm/v7、Linux arm64/v8乃至 Windows 1809 / ltsc2022 等不同 CPU 架构与操作系统组合。在这样的前提下如果每次构建都临时起意地取名很快会出现 tag 冲突、镜像难以定位、CI/CD 无法自动化拉取等问题。因此 Dapr 需要一个公认且恒定accepted and constant的镜像命名方式这正是 ENG-001 决策记录产生的直接动机。该记录当前状态为Accepted意味着它已成为 Dapr 后续所有镜像制品命名的强制约定。二、核心规范Decisions两条不可违反的命名规则决策记录给出了两条规则它们是整套命名体系的地基规则一镜像必须符合三段式格式一个镜像遵循如下格式namespace/repository:tagnamespace镜像仓库的命名空间/主机名例如actionscore.azurecr.io决策记录撰写时的 ACR 地址或当前 Makefile 中默认的daprio.azurecr.iorepository镜像仓库名例如dapr整体系统镜像或daprd、placement、sentry、operator、injector、scheduler各组件独立镜像tag镜像版本标签遵循下一条规则。规则二Tag 必须是版本号或版本号-架构一个合法的 tag 遵循如下格式version-architecture或仅version此时架构默认为 Linux即省略架构后缀时默认代表 Linux 架构的镜像。这一默认 Linux的约定在仓库的构建脚本中也有对应体现Makefile 中TARGET_OS ? linux、TARGET_ARCH ? amd64默认构建目标就是 Linux amd64。三、规范落地docker.mk 中的源码级实现仅停留在决策层面还不够关键在于构建脚本是否严格遵循了这两条规则。阅读 docker/docker.mk 可以发现规范被精确地翻译成了 Make 变量与构建目标。3.1 镜像名namespace/repository的拼装# docker/docker.mk L27-L33 DAPR_SYSTEM_IMAGE_NAME?$(RELEASE_NAME) # 默认 dapr DAPR_RUNTIME_IMAGE_NAME?daprd DAPR_PLACEMENT_IMAGE_NAME?placement DAPR_SENTRY_IMAGE_NAME?sentry DAPR_OPERATOR_IMAGE_NAME?operator DAPR_INJECTOR_IMAGE_NAME?injector DAPR_SCHEDULER_IMAGE_NAME?scheduler ... # docker/docker.mk L93-L99 DOCKER_IMAGE$(DAPR_REGISTRY)/$(DAPR_SYSTEM_IMAGE_NAME) DAPR_RUNTIME_DOCKER_IMAGE$(DAPR_REGISTRY)/$(DAPR_RUNTIME_IMAGE_NAME)其中DAPR_REGISTRY即namespace部分而RELEASE_NAME在 Makefile 中默认值为dapr也就是repository部分。最终拼出的完整镜像引用形如daprio.azurecr.io/dapr、daprio.azurecr.io/daprd与决策记录中的示例actionscore.azurecr.io/dapr:latest结构完全一致只是 registry 地址从当年的actionscore.azurecr.io演进到了当前的daprio.azurecr.io见 Makefile 的HELM_REGISTRY?daprio.azurecr.io。3.2 Tagversion-architecture的拼装# docker/docker.mk L73-L81 # 若设置 WINDOWS_VERSION则 tag 中嵌入 Windows 版本号 ifneq ($(WINDOWS_VERSION),) BUILD_ARGS--build-arg WINDOWS_VERSION$(WINDOWS_VERSION) DOCKER_IMAGE_VARIANT$(TARGET_OS)-$(WINDOWS_VERSION)-$(TARGET_ARCH) else DOCKER_IMAGE_VARIANT$(TARGET_OS)-$(TARGET_ARCH) endif ... # docker/docker.mk L100 BUILD_TAG$(DAPR_TAG)-$(DOCKER_IMAGE_VARIANT)这里把决策记录中的version-architecture落地为更精确的DAPR_TAG-os-arch如1.16.0-linux-amd64并针对 Windows 增加了版本维度如1.10.0-rc.2-windows-ltsc2022-amd64这是对决策规则的自然细化——因为实际发布需要区分操作系统而不仅仅是 CPU 架构。关键变量含义如下变量默认值/来源作用DAPR_TAG必须显式设置见check-docker-env版本号主体如1.16.0、0.1.0-alphaTARGET_OSlinuxMakefile目标操作系统如 linux / windows / darwinTARGET_ARCHamd64Makefile目标 CPU 架构如 amd64 / arm / arm64WINDOWS_VERSION未设置Windows 专属版本号如 ltsc2022设置后嵌入 tag构建脚本通过check-docker-env目标强制校验前提条件未设置DAPR_REGISTRY或DAPR_TAG时直接报错docker/docker.mk从机制上保证任何产出的镜像都必然符合规范。3.3 架构别名与平台映射决策记录中的architecture在实现里有一套归一化映射防止出现命名歧义# docker/docker.mk L56-L64 DOCKER_IMAGE_ARCH:amd64 ifeq ($(TARGET_ARCH),arm) DOCKER_IMAGE_ARCH:arm/v7 else ifeq ($(TARGET_ARCH),arm64) DOCKER_IMAGE_ARCH:arm64/v8 endif DOCKER_IMAGE_PLATFORM$(TARGET_OS)/$(DOCKER_IMAGE_ARCH) DOCKER_BUILDX_PLATFORMS$(TARGET_OS)/arm/v7,$(TARGET_OS)/arm64/v8,$(TARGET_OS)/amd64可见tag 中的arm对应 Docker 平台的linux/arm/v7arm64对应linux/arm64/v8而amd64对应linux/amd64。同时 Makefile 会依据本机 CPU 自动探测TARGET_ARCH_LOCALarmv8→arm64、armv7→arm等用于判断是否需要走跨架构模拟构建。四、多架构支持单个 tag 背后是 manifest 列表决策记录强调支持不同架构的诉求落地方案是每个不可变版本 tag 之下实际发布一组带架构后缀的镜像再合并成多架构 manifest。4.1 支持的架构矩阵# docker/docker.mk L67 DOCKER_MULTI_ARCH?linux-amd64 linux-arm linux-arm64 windows-1809-amd64 windows-ltsc2022-amd64这组字符串同时就是 tag 后缀的枚举1.16.0-linux-amd64、1.16.0-linux-arm、1.16.0-linux-arm64、1.16.0-windows-1809-amd64、1.16.0-windows-ltsc2022-amd64。4.2 manifest 合并docker-manifest-create# docker/docker.mk L282-L284节选 $(DOCKER) manifest create --amend $(DOCKER_IMAGE):$(DAPR_TAG) $(DOCKER_MULTI_ARCH:%$(DOCKER_IMAGE):$(MANIFEST_TAG)-%) $(DOCKER) manifest push --purge $(DOCKER_IMAGE):$(DAPR_TAG)该目标把各架构的独立镜像通过docker manifest create --amend聚合到不带架构后缀的DAPR_TAG如daprio.azurecr.io/dapr:1.16.0之下使用户只拉取一个 tagDocker 便会按运行平台自动选择对应架构的镜像。4.3latest的语义指向不可变版本值得注意的是构建脚本对latest的处理刻意保持不可变语义# docker/docker.mk L83-L90 ifeq ($(MANIFEST_TAG),) MANIFEST_TAG$(DAPR_TAG) endif ifeq ($(MANIFEST_LATEST_TAG),) # latest manifest tag 会指向不可变版本 tag # 例如latest - 1.11.0-linux-amd64 1.11.0-linux-arm 1.11.0-linux-arm64 ... MANIFEST_LATEST_TAG$(DAPR_TAG) endif即latest这个浮动标签最终指向的是具体的、不可变的版本架构镜像docker/docker.mk 在LATEST_RELEASEtrue时执行该合并而不是被反复覆盖的可变内容——这保证了生产环境拉取latest时行为的确定性。五、CI/CD 中的实际应用DAPR_TAG 如何被注入命名规范最终要服务发布流程。在 .github/workflows/dapr.yml 中可以看到规范的实际使用方式# Linux amd64 / arm64 等常规架构 DAPR_TAG${{ env.REL_VERSION }} make docker-push # MarinerCBL-Mariner 基础镜像变体追加 -mariner 后缀 DOCKERFILEDockerfile-mariner DAPR_TAG${{ env.REL_VERSION }}-mariner make docker-push # Windows 镜像tag 追加 -windows-amd64 DAPR_TAG${{ env.REL_VERSION }}-windows-amd64 \ make docker-publish见 .github/workflows/dapr.yml、.github/workflows/dapr.yml这里体现了两个规范细节REL_VERSION版本号与架构后缀由不同环节负责版本号由 CI 环境变量注入DAPR_TAG架构后缀则由docker.mk根据TARGET_OS/TARGET_ARCH自动拼接二者解耦特殊基础镜像使用显式后缀基于 docker/Dockerfile-mariner 构建的镜像使用-mariner后缀、Windows 使用-windows-amd64均是对version-suffix约定的扩展保持可读性与可追溯性。此外发布流程末尾会执行docker-publish即docker-manifest-create将各架构镜像合并为多架构 manifest 后再交付.github/workflows/dapr.yml与 4.2 节描述完全对应。六、后果与实战遵循规范构建自己的 Dapr 镜像决策记录的 Consequences 部分指出该规范与业界广泛接受的 Docker 命名惯例保持一致并为未来所有镜像命名提供了清晰指引。落到实践层面这意味着6.1 本地构建示例克隆仓库后你可以通过环境变量完全掌控镜像命名# 构建 Linux amd64 的 dapr 系统镜像tag 为 1.16.0-linux-amd64 make DAPR_REGISTRYdaprio.azurecr.io DAPR_TAG1.16.0 \ TARGET_OSlinux TARGET_ARCHamd64 docker-build # 交叉构建 ARM64 镜像自动走 buildx qemu 模拟见 docker.mk L149-L176 make DAPR_REGISTRYdaprio.azurecr.io DAPR_TAG1.16.0 \ TARGET_OSlinux TARGET_ARCHarm64 docker-build # 构建并推送然后合并为多架构 manifestdocker-publish docker-manifest-create make DAPR_REGISTRYdaprio.azurecr.io DAPR_TAG1.16.0 docker-publish其中TARGET_ARCHarm64与本地架构不一致时脚本会自动安装tonistiigi/binfmt模拟器并创建名为daprbuild_multi的 buildx 构建器docker/docker.mk这正是多架构镜像得以产出的底层机制。6.2 解读镜像 tag 的三个要点看 tag 即可判断平台-linux-amd64/-linux-arm/-linux-arm64/-windows-ltsc2022-amd64一目了然无后缀即 Linux决策记录明确省略架构时默认 Linuxdapr:latest即 Linux 多架构 manifest版本号保持不可变每个REL_VERSION对应的架构镜像一经发布即为不可变制品latest只做指向不做覆盖docker/docker.mk。6.3 与 Helm 部署的衔接同样的命名变量还会透传到 Helm 部署环节Makefile 在生成部署清单时执行--set-string global.tag$(DAPR_TAG) --set-string global.registry$(DAPR_REGISTRY)也就是说你在构建阶段设置的DAPR_TAG/DAPR_REGISTRY与集群中实际拉取的镜像 tag 是同一套值从而保证构建什么、部署什么完全一致。七、总结ENG-001 是一份短小但影响深远的架构决策它用两条规则镜像三段式格式、tag 的版本-架构形态统一了 Dapr 全部镜像制品的命名而其思想在 docker/docker.mk 中得到了忠实且更精细的落地——通过BUILD_TAG$(DAPR_TAG)-$(TARGET_OS)-$(TARGET_ARCH)的变量组合、架构别名映射、多架构 manifest 合并以及 CI 中DAPR_TAG的注入最终形成了一套版本不可变、平台可区分、latest 可确定的镜像治理体系。对于任何需要为多架构、多仓库项目设计镜像命名规范的团队这份决策记录及其实现都是一个值得直接复用的范本。进一步阅读完整的决策记录索引见 docs/decision_records/decision_records.md其余工程类决策记录位于 docs/decision_records/engineering/ 目录下。【免费下载链接】daprDapr is a portable runtime for building distributed applications across cloud and edge, combining event-driven architecture with workflow orchestration.项目地址: https://gitcode.com/GitHub_Trending/da/dapr创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考