Skip to main content

实体参考

实体通常需要引用其他实体。 例如，一个组件本文将介绍如何在 yaml 实体声明文件中编写这些引用。

目录中的每个实体都由其一种,命名空间和名字但是，手动键入的工作量很大，而且在很多情况下，种类和命名空间都是固定的，或者可以推导出来，或者有合理的默认值。 因此，为了帮助编写者，目录有一些小技巧。

每个引用可以用两种方式之一表示：紧凑的字符串或复合引用结构。

字符串引用​

这是最常见的替代方案，几乎适用于所有情况。

字符串的格式为[<kind>:][<namespace>/]<name>也就是说，它是由一到三个部分按特定顺序组成的，没有任何额外的编码：

  • 可选择种类，后面跟一个冒号 * 可选择命名空间，后面跟一个斜线 * 名称

名称始终是必填项。 根据上下文，可以省略种类和/或命名空间。 如果省略，将根据上下文使用哪些值，相关文档应说明哪条规则适用于哪些情况。 所有字符串都不区分大小写。

# Example:
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: petstore
  namespace: external-systems
  description: Petstore
spec:
  type: service
  lifecycle: experimental
  owner: group:pet-managers
  providesApis:
    - petstore
    - internal/streetlights
    - hello-world

实地spec.owner在这种情况下，字符串group:pet-managers这意味着该种是Group，名称空间被省略，名称为pet-managers在这种情况下，命名空间被选择回退到值default因此，最终结果是我们希望在目录中找到另一个实体，其类型为Group，命名空间default(实际上也可以在自己的 yaml 文件中不使用，因为这也是默认值)，并将其命名为pet-managers.

中的条目providesApis也是引用。 在这种情况下，它们都不需要指定类型，因为我们从上下文中知道，这是这里唯一支持的类型。 第二个条目指定了名称空间，但其他条目没有指定，在这种情况下，默认情况下是引用与源实体相同的名称空间(例如："......")。external-systems因此，这三个参考文献基本上扩展为api:external-systems/petstore,api:internal/streetlights和api:external-systems/hello-world我们预计目录中会有三个 API 类型实体与这些引用相匹配。

请注意，上文关于缩短(省略种类和/或命名空间)的说明只在协议、存储系统或外部引用实体时，实体 ref 总是由这三个部分组成。

复合物参考文献​

这是引用的一个更冗长的版本，其中种类-命名空间-名称三元组的每一部分都表示为对象中的一个字段。 您可能会在Backstage代码中看到这种结构，但它通常不应在任何形式的协议或插件和/或外部系统之间使用。 在这些情况下，我们更倾向于使用字符串形式，因为它的语义更清晰，而且由于只是一个字符串，可以更方便地传输。