企业官网建设流程全解析

awesome-copilot Azure 资源命名规范（CAF）实战指南：让 GitHub Copilot 生成合规的 Bicep 与 Terraform 命名

【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot

导读

本文基于 awesome-copilot 仓库中的 azure-naming.instructions.md 指令文件，系统讲解基于 Microsoft CAF（Cloud Adoption Framework）的 Azure 资源命名约定：从通用命名模式、命名范围到各资源类型的官方缩写、长度限制与合法字符。读完本文，你将能够在使用 GitHub Copilot 编写、审查或建议 Azure 资源名称时，快速查证任意资源类型（从管理组到 AI 服务）的官方缩写与命名约束，避免因不合规命名导致的部署失败，并理解该指令如何与仓库中的 bicep-code-best-practices.instructions.md 和 terraform-azure.instructions.md 协同生效。

一、这是什么：一条内嵌于 Copilot 的 Azure 命名指令

在 awesome-copilot 仓库中，该指令以独立文件 instructions/azure-naming.instructions.md 的形式存在，其文件头声明了明确的适用范围与用途：

• applyTo：**/*.bicep,**/*.tf,**/*.tfvars,**/*.bicepparam,**/infra/**,**/infrastructure/**——即所有 Bicep、Terraform、tfvars、Bicep 参数文件以及 infra/infrastructure 目录下的文件都会被触发；
• description：基于 Microsoft CAF 的 Azure 资源命名约定，适用于创建、审查或建议 Azure 资源名称的场景。

按照 docs/README.instructions.md 中的说明，此类指令文件可通过 VS Code 一键安装，或手动放入工作区的.github/copilot-instructions.md以及.github/instructions/目录（例如.github/instructions/azure-naming.instructions.md）。安装后，Copilot 在涉及 Bicep/Terraform 的对话中会自动遵循这套命名规则，相当于把微软官方的命名最佳实践"内化"为 AI 助手的默认行为。

该指令的权威来源为微软官方文档"Define your naming convention"、"Abbreviations"与"Name rules"，本文以仓库文件内容为准进行整理，不再逐一给出外部链接。

二、通用命名模式与组件规则

2.1 通用模式

所有 Azure 资源名称应遵循以下统一格式：

<resource-type-abbr>-<workload>-<environment>-<region>-<instance>

五个组成段位的含义与规则如下：

⚠️注意：部分资源类型不遵循此模式（例如不允许连字符的资源），需要查阅下文 官方缩写与命名规则 中每个资源的具体模式与约束。

2.2 通用字符规则

• 优先使用小写字母与连字符（-）。除非资源类型强制要求，否则不使用空格、下划线；
• 部分资源不允许连字符——应改用小写字母与数字直接拼接（见下表）；
• 禁止使用以下字符：#、<、>、%、&、\、?、/以及控制字符；
• 不得在名称中编码敏感数据（如订阅 ID、租户 ID）；
• 大多数名称在 Azure 中不区分大小写——始终以不区分大小写的方式进行比较；
• 拥有公共端点的资源，其名称不能包含保留字或商标。

三、命名范围（Naming Scope）

Azure 资源名称的唯一性要求因范围而异，理解这一维度是避免"重名冲突"的基础：

例如存储账户（st）与容器注册表（cr）是 Global 范围，必须全局唯一；而子网（snet）仅在所属虚拟网络内唯一；Azure SQL 数据库（sqldb）仅在所属 SQL Server 内唯一。

四、官方缩写与命名规则

以下为各资源类别的官方缩写表，这是本指令的核心查证依据。在实际编写基础设施代码时，应逐资源核对"Scope（唯一性范围）、Length（长度限制）、Valid Characters（合法字符）"三列，再套用示例格式。

4.1 管理与治理（Management and Governance）

4.2 网络（Networking）

4.3 计算与 Web（Compute and Web）

4.4 容器（Containers）

4.5 数据库（Databases）

4.6 存储（Storage）

4.7 安全（Security）

4.8 集成（Integration）

4.9 AI 与机器学习（AI and Machine Learning）

4.10 分析与 IoT（Analytics and IoT）

4.11 开发者工具（Developer Tools）

五、不允许使用连字符的资源

以下资源要求使用小写字母与数字直接拼接（无任何分隔符），这是最容易踩坑的一类：

与此相关的还有几个特殊点：AKS 系统节点池（npsystem）与用户节点池（np）的长度极短（Linux 1-12、Windows 1-6），且只能使用小写字母与数字、不能以数字开头；VM 名称在 Windows 上最长 15 字符（受计算机名限制），需格外注意。

六、CAF 命名示例速查

以下为按类别整理的官方示例，可直接作为团队命名基线：

# Management rg-navigator-prod rg-webapp-database-dev # Networking vnet-shared-eastus2-001 snet-shared-eastus2-001 nsg-weballow-001 pip-dc1-shared-eastus2-001 lbe-navigator-prod-001 # Compute vm-sql-test-001 vm-sharepoint-dev-001 vmss-navigator-prod-001 asp-navigator-prod-001 app-navigator-prod-001 func-navigator-prod-001 # Containers aks-navigator-prod-001 ca-navigator-prod-001 cae-navigator-prod-001 crnavigatorprod001 # no hyphens! # Databases sql-navigator-prod-001 sqldb-navigator-prod cosmos-navigator-prod psql-navigator-prod-001 # Storage / Security stnavigatorprod001 # no hyphens! kv-navigator-prod-001 id-navigator-prod-001 # Integration apim-navigator-prod sbns-navigator-prod evhns-navigator-prod # Monitoring log-navigator-prod-001 appi-navigator-prod-001 # AI oai-navigator-prod srch-navigator-prod

七、禁止事项（Do NOT Do）

• 不要使用下划线，除非资源类型强制要求——一律使用连字符；
• 不要拼写出完整的资源类型单词（例如storageaccount-myapp应改为stmyapp001）；
• 不要使用大写字母（资源不区分大小写，小写是惯例）；
• 不要在名称中包含敏感数据（订阅 ID、租户 ID、密码等）；
• 不要省略环境段位——即使对于生产环境（如rg-navigator-prod而非rg-navigator）；
• 不要使用#——它会被 Azure Resource Manager 的 URL 解析破坏；
• 对于带公共端点的资源，不要在名称中使用保留字或商标；
• 不要使用超过两个连续的连字符（例如app--prod是无效的）。

八、与仓库内其他指令的协同：从"命名"到"落地"

该命名指令并非孤立存在，它在 awesome-copilot 的 Azure 基础设施指令体系中与以下文件形成互补：

8.1 Bicep：符号名与资源名的分工

bicep-code-best-practices.instructions.md 中明确了 Bicep 层面的命名纪律，与本指令形成"两层命名"体系：

• Bicep 中的**符号名（symbolic name）**使用 lowerCamelCase，且使用资源类型的描述性名称（如storageAccount而非storageAccountName），避免在符号名中出现name；
• 而实际部署的资源名则遵循本指令的 CAF 缩写模式；
• 该文件还要求使用uniqueString()生成有意义的唯一资源名，并为结果添加前缀——因为部分资源不允许名称以数字开头。这与本指令中"缩写必须放在名称第一位"的规则相呼应：先写st、kv等缩写，再接uniqueString()结果，可同时满足"前缀合法"与"全局唯一"。

8.2 Terraform：locals 集中管理与多区域一致

terraform-azure.instructions.md 在"Azure-Specific Best Practices"一节中明确要求遵循 Azure 命名约定，并提供了与之配合的工程手法：

locals { common_tags = { Environment = var.environment Project = var.project_name Owner = var.owner CreatedBy = "terraform" } resource_name_prefix = "${var.project_name}-${var.environment}" location_short = substr(var.location, 0, 3) }

从源码结构看，该指令建议通过locals集中计算resource_name_prefix（如${project}-${environment}）与location_short（区域短名），再以${local.resource_name_prefix}-001的方式拼接出符合 CAF 模式的资源名；同时强调"使用一致的区域命名与变量以支持多区域部署""使用描述性名称表明用途与环境"。在资源组策略上，它还规定"仅在被指定时使用现有资源组，仅在必要时并经确认后创建新资源组"——这与本指令中rg缩写规范配合，可避免资源组命名随意化。此外，azure-verified-modules-terraform.instructions.md 等 AVM 相关指令也延续了同一套命名基准。

8.3 工作流中的触发机制

凭借本指令文件头的applyTo通配规则，只要工作区中的文件是.bicep、.tf、.tfvars、.bicepparam，或位于infra/、infrastructure/目录下，Copilot 便会自动启用这套命名约束。对于使用 terraform-azure.instructions.md 建议的infra/目录结构的项目，命名规则会在 IaC 生成阶段自动生效，无需人工提醒。

九、结论与使用建议

本指令文件将 Microsoft CAF 的资源命名规范浓缩为可被 AI 直接执行的结构化规则：通用模式五段位（缩写-工作负载-环境-区域-实例）、三层命名范围（Global / Resource group / Resource）、十一大类资源的官方缩写与长度/字符约束，以及三类禁止连字符的特殊资源。建议团队将其作为代码评审清单与 IaC 生成基线，同时配合 Bicep 的符号名纪律与 Terraform 的locals命名前缀模式使用，即可在 CI 之前拦截绝大多数命名不合规问题。

实战要点回顾：

1. 始终以rg-navigator-prod这类"缩写-工作负载-环境"为最小完整形态，不要省略环境段；
2. 遇到存储账户、容器注册表、Data Explorer 集群时，立刻切换到"无连字符拼接"模式（stnavigatorprod001）；
3. 在 Copilot 中生成 Azure 基础设施代码前，确认工作区已安装本指令（见 docs/README.instructions.md），并让.github/instructions/目录包含本文件；
4. 用 Bicep 的uniqueString()+ 缩写前缀、Terraform 的locals前缀变量来生成动态实例段，兼顾唯一性与可读性。

【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot