云命名约定

一致的命名策略很重要，应该是 anycloud 工作的重要组成部分。遗憾的是，它经常被忽视。当您拥有几台“宠物”服务器时，这似乎是一种奢侈，但随着托管资源数量的增加，它很快变得至关重要。这是实现基本一致性水平的第一步，也是建立任何类型的云治理的先决条件。后者会很快告诉我们我们正在处理什么类型的资源，它们属于哪个项目和环境，它们位于何处以及它们在功能上是否彼此等效。减少理解代码的努力，并允许开发人员专注于更重要的方面，而不是争论命名标准。我不太确定我第一次看到这句话是什么时候，但它后来成了我的最爱之一。 Martin Fowler 将其归功于 PhilKarlton。我们将重点关注云级资源的命名约定应该如何。我们的示例中使用了 GCP，但概念和策略是通用的，可以轻松适应其他云提供商。在设计命名约定时，您应该考虑云提供商施加的限制。每个资源都带有一组命名限制。经验法则是保持简短和简单（仅对各个组件使用字母和数字，保留 - 作为分隔符）。 GCP 将大多数资源的名称长度限制为 62 或 63 个字符，项目 ID 限制为 30。资源必须具有唯一的名称，无论是在全球范围内还是在给定范围内。一些资源有额外的限制需要考虑（例如 GCP 项目不能立即删除）。

首先我们建立所有直接管理的资源都应该遵循的命名模式——全局命名模式。这是用于所有资源的固定值前缀。通常是组织名称的某种形式的缩写。这与 GCP 项目不同。通常一个项目将有多个 GCP 项目。我们使用扁平层次结构，项目作为将资源组织成组的主要机制。我喜欢使用扁平层次结构，因为它非常通用且灵活，几乎可以适应任何组织结构。您可能会考虑用某种其他形式的团队（例如团队、产品）来代替它，但根据我的经验，从长远来看，它永远不会奏效。资源属于部署环境。建立一个在整个组织中使用的通用名称集是有益的。随着时间的推移，我尝试了各种机制来构建资源的缩写——如果名称基于 API 资源名称，则可以获得最一致的结果。给定资源类型的缩写。在 GCP 中，我倾向于使用三个字母。对于更大和更频繁使用的 API（例如 Compute、Kubernetes），API 的第一个字母代表，资源类型的其余两个字母代表。对于资源较少的 API，情况正好相反。我知道这不是一个完全确定的规则，但这将始终是对其简短和可用的妥协。当有可能在不同位置创建给定资源时需要位置。

区域 - 五个字母的首字母缩略词（两个字母代表大陆，两个代表基本方向，1 位数字） Multi-Dual-regional - 遵循 GCP 自己的命名（两个字母代表多，四个字母代表双区域） 用于区分资源的描述同类型但不同的角色。例如，一组具有不同用途的服务器 - 前端和后端。这不应该用于区分同一用途资源的多个实例，而是使用后缀。当没有更好、更具体的术语可用时，就用于描述的通用关键字达成一致也是有益的。这避免了许多不同的名称，如 main、core、common、this 和 similar。通常好的策略是使用拉丁序数序列，即一级、二级、三级等。可读性好，并且可以使用 Terraform random_idresource 轻松生成。当有多个实例时，或者当需要唯一性时，使用后缀将资源与其对等资源区分开来。让我们回顾几个完整的示例，说明如何根据上述既定模式命名资源。出于此命名约定的目的，项目（和文件夹）被视为资源容器，因此省略名称的资源部分。

您可以注意到 GCP 默认为通过控制台创建的项目执行此操作 - 例如 Rapid-depot-253717。GCP 中的项目 ID 必须全局唯一且不能立即删除。这对于自动化来说是不幸的，因为您无法使用删除后的同名。这就是我们包含独特的随机后缀部分的原因。文件夹：我们不使用 GCP 文件夹来组织项目。我普遍认为，保持简单和扁平往往是有益的。但是，如果您想进一步构建您的资源，请考虑在您的命名模式中添加一个额外的组件，例如 [org_group]。 Folderscan 然后遵循 [prefix]-[org-group] 模式。GCP 还允许配置项目名称。我建议将其设置为与项目 ID 相同的值并忘记它。出于所有实际目的，您将通过 ID 引用项目。总会有一些例外，即无法遵循全局命名模式（例如资源不允许 - 在名称中）或者它根本没有意义。如果可能，应使用完整模式的子集，并记录所有异常。服务账号只遵循[资源]-[描述]模式，因为项目已经包含在@之后的部分，因此不需要重复这一点，这是一个复杂的话题，也许是另一篇文章，但你应该建立命名约定组和如何分配权限的策略。根据经验，永远不要将权限直接分配给个人，而应仅分配给组。您还应该介绍标签（或标签）的使用。一个好的方法是添加信息以进一步对您的资源进行分类，例如成本中心。当您无法直接管理资源名称时，标签也很有用，但您可以管理一组传播到子资源（例如 GKE 集群标签或实例组）的标签。不要复制命名约定中已经包含的信息（例如项目）或使用可从对象本身获取的信息（例如创建时间戳）创建大量唯一标签。

跨基础架构的 DNS 命名约定再次成为一个更大的主题，但您绝对应该拥有一个。一个简单的策略可以是以 [project]-[env].<common_dns_domain> 形式为每个 GCP 项目创建一个子域。为给定资源创建的 DNS 记录应遵循 GlobalNaming 模式的 [resource]-[resource_location]-[description]-[suffix] 部分，因此镜像资源名称。当您开始使用云或新项目时，您应该首先建立一致的命名约定。这是一开始很容易做的事情之一，但后来很难解决。您每天都会从中受益。命名约定成功的关键是尽早建立命名约定，并在整个基础架构中无情地遵循命名约定。自动化有很大帮助。像往常一样，没有灵丹妙药，实际的命名约定应该始终适合您的环境。重点是有一个！我希望这篇文章能给你一个良好的开端。感谢您一路走到这里。如果你现在认为我有严重的强迫症（我可能会），我不会责怪你，但是尝试在一个有 120 个 Kubernetes 集群的环境中工作，并且其中的每一个都只是集群！祝你的云之旅好运，我很想听听你命名事物的经验。你可以在@stepanstipl 上关注我。