构建命名与多标签
构建时给产物起名并打标签，是镜像能否被正确引用与推送的前提。可以一次打多个标签，指向同一份镜像数据。命名不是随意的字符串：完整引用由仓库地址、命名空间、名称与标签四段组成，缺了仓库段时会按公共仓库的规则解析。
基本信息
| 写法 | 构建命令后跟命名参数，可重复出现 |
|---|---|
| 默认标签 | 不写标签时使用最新标识 |
| 命名规则 | 仓库路径全部小写，不能含空格 |
| 多标签效果 | 指向同一镜像数据，只多占标签记录 |
| 适用平台 | 所有使用镜像构建的工作流 |
典型使用场景
- 发布版本：用语义化版本号打标签，便于追溯与回滚
- 多环境共用：同一镜像打上不同环境的仓库路径，便于权限管理
- 本地验证后转正式命名：先临时命名试跑，确认后再打正式标签推送
- 流水线构建：用提交号或构建号做标签，保证每次构建可定位
- 同时维护浮动标签：版本标签加最新标识，兼顾可追溯与方便取用
常用示例
常用示例
docker build -t app/web:1.0 -t app/web:latest . # 一次打两个标签
docker build -t registry.example.com/team/app-web:1.0 . # 带上仓库地址
docker images app/web # 核对标签
docker image inspect app/web:1.0 --format '{{.Id}}' # 确认多标签指向同一镜像
docker push registry.example.com/team/app-web:1.0 # 推送完整引用命名各段的作用
| 片段 | 作用 | 遗漏后果 |
|---|---|---|
| 仓库地址 | 指定推送到哪个镜像仓库 | 省略时按公共仓库解析，内部镜像可能被推到错误位置 |
| 命名空间 | 组织或项目维度 | 通常与权限绑定，写错会推送失败 |
| 镜像名称 | 服务标识 | 命名混乱会导致部署引用困难 |
| 标签 | 版本或环境标识 | 省略时用最新标识，语义模糊 |
| 内容摘要 | 不可变引用 | 需要严格复现时才有意义，构建后推送才能获得 |
标签策略建议
- 发布用不可变版本标签，浮动标签只作为方便取用的别名
- 流水线里用提交号做标签，出问题能快速定位到代码版本
- 多架构构建时为每个架构与合并清单分别规划标签
- 标签命名规则写进团队约定，避免同一项目出现两套风格
- 历史标签按保留策略清理，减少误用旧版本的可能
多个标签指向同一镜像数据，体积不会成倍增加，但删除时要留意引用关系：删掉一个标签只摘掉一个名字，镜像本体还在。
不带仓库地址的名称会按公共仓库规则解析。要在内部仓库使用，构建或打标签时就把地址写全，省掉推送前临时改名的步骤。