为什么大多数 Azure 命名约定在名称中包含资源类型？

Azure 的大多数命名约定将资源类型和其他元数据放在资源名称中。

对我来说，这感觉像是很多不必要的重复，并导致难以阅读充满缩写的神秘名称。

我使用的大多数视图或工具已经显示了重要的元数据，例如资源类型、位置或资源组。例如，“所有资源”视图有一个类型列，并且资源名称旁边还有一个特定于类型的图标。将类型添加到名称感觉像是不必要的重复，并且使名称更难以阅读。

我们还尝试通过基础设施即代码 100% 管理我们的资源。在 terraform 中，当我指定资源时，我已经必须包含类型（例如“azurerm_storage_account.my_account_name”）。

当我使用 cli 命令时，它们还包括类型（“az storage ...”、“az vm ...”）。

那么我错过了什么？将类型放在名称中有什么好处？

其他元数据也是如此。为什么要在我已经定义为标签的名称中重复内容？例如，如果我想查看团队名称或应用程序，那么我将它们定义为标签并将它们作为列添加到我的资源视图中。这比从一些神秘的长资源名称的中间读取要容易得多。

实际上是否有充分的理由在资源名称中复制所有这些信息，或者每个人都这样做只是因为微软推荐它？将所有这些元数据放入标签并制定明确的标签策略不是更有意义吗？

0
投票

您的观察是正确的，Azure 门户在单独的列中并通过使用标签提供了详细的元数据，这可能会使某些命名约定显得多余。在资源名称中包含资源类型在很大程度上是一种传统做法，早于 Azure 目前提供的全面标记和筛选功能。

但是，以下是这种做法持续存在的一些原因。

遗留系统和实践：旧系统和实践没有相同级别的元数据标记和过滤。在名称中包含元数据可确保关键信息始终可见，无论使用什么系统来查看资源。

非 Azure 工具和上下文：当您使用 Azure 门户之外的工具（例如本地脚本、CLI 工具、第三方系统）时，或者在文档中引用资源时，具有描述性名称可以提供即时信息上下文，无需访问 Azure 标签或其他元数据。

快速参考：对于某些人来说，通过名称而不是标签来识别资源更容易，特别是当它们经常直接使用模板、脚本或 CLI 命令中的资源名称时。

可搜索性：资源名称的索引方式与标签不同，有时更容易搜索，特别是在使用 CLI 命令或在门户或其他工具中进行快速过滤时。

标记限制：可以应用于资源的标签数量有限制，并且某些资源根本不支持标记。命名约定可以为此类情况提供额外的元数据层。

虽然这些是继续这种做法的原因，但您是否需要遵循此约定取决于您的个人选择或您组织的特定工作流程、工具和策略。借助强大的标记策略，并且如果您的所有工具和流程都支持 Azure 标记，您可能会选择放弃冗长的命名约定。

参考：