跳至内容

数据模型

本节将介绍 Pulp 生态系统中最重要的模型。这不是 Galaxy NG 中所有数据模型的全面概述。为此，最好的选择是阅读 pulpcore 及其插件中的模型文件。

通用 Pulp 对象

Pulpcore 提供以下通用数据模型，插件旨在扩展这些模型以提供对特定内容类型的支持。例如，Pulp Ansible 插件扩展 Content 以创建 CollectionVersions，并扩展 Repository 以创建 AnsibleRepository（Pulp Ansible 部分将对此进行详细介绍）。虽然这些通用模型从未直接使用，但了解它们的功能及其局限性对于理解 Pulp 插件的工作方式至关重要。

工件 (Artifact)

客户端下载的二进制对象。这是 Pulp 存储的实际软件（集合 tar 包、角色 tar 包、容器镜像二进制文件、Python wheel 包）。

内容 (Content)

这表示存储在 Pulp 中的软件（Ansible 集合、容器镜像层、Python 包、RPM 包等）。此模型存储从内容工件中提取的内容元数据，并且是不可变的。

Content 最终引用一个或多个工件，但是工件可能实际上并不存在于系统上。Pulp 支持按需同步，这意味着只有在实际需要时才会从远程下载内容。

示例

Content/Artifact Relationship

仓库 (Repository)

一大堆内容。可以将其想象成一个包含一组集合（或任何其他 Pulp 内容）的文件夹。仓库存储指向内容的指针，而不是实际内容本身。

仓库是版本化的，仓库版本是不可变的。这意味着，每当向仓库添加或从中删除内容时，都会创建一个新的仓库版本，该版本引用对仓库发生更改的列表。这类似于 Git 的工作方式，其中 Git 仓库中的代码是引用随时间对代码所做的更改的长列表提交。版本允许将仓库回滚到以前的状态。

数据库中的仓库对象指向最新的仓库版本；但是，可以在仓库的任何版本中引用内容，而不仅仅是最新版本。

示例

Repository/Content Relationship

分发 (Distribution)

指向仓库的指针。每当客户端从 Pulp 使用内容时，它们都会通过分发访问仓库中的内容。每个分发指向一个仓库，但仓库可以有多个分发。可以将其想象成仓库的 URL。这就是引用仓库中内容的方式。如果没有分发，Pulp 中的内容将无法被客户端访问（例如 ansible-galaxy 和 podman）。

在大多数情况下，分发仅指向仓库的最新版本，但是可以将其更新为指向特定版本。

用于引用分发的实际 URL/路径是 `base_path`。

示例

分发 1 和 2 指向最新版本，其中包含内容 1 和 2，因此这组内容将可用于从这两个分发的 `base_path` 中提取内容的任何客户端。

内容 2、3、4 将可从分发 3 的 `base_path` 获取，因为它指向版本 2。

Distribution/Content Relationship

远程 (Remote)

这定义了连接到远程服务器以将一组内容下载到 Pulp 所需的信息。这包括服务器 URL、登录服务器的身份验证凭据、要从服务器同步的一组内容以及连接到服务器的其他杂项信息。

示例

Remote/Repository Relationship

整合在一起

示例系统可能如下所示（注意，为简便起见，已省略仓库版本和工件）。在此示例中：

  • 远程 1 将内容同步到仓库 1 和 2。
  • 仓库 1 中的内容将无法被客户端访问，因为它没有附加任何分发。
  • 仓库 3 中的内容可以通过分发 2 和 3 访问，但由于没有远程连接到该仓库，因此只能通过手动上传来向仓库添加内容。

Example system

Pulp Ansible 内容模型

Pulp Ansible 提供以下模型：

  • 内容 (Content)
    • 角色 (Role)：Ansible 角色。目前 Galaxy NG 不支持这些角色。
    • 集合版本 (CollectionVersion)：集合可以有多个版本，客户端实际安装的内容是集合版本。
    • 集合版本签名 (CollectionVersionSignature)：可以选择附加到集合的签名。
    • 已弃用的 Ansible 集合 (AnsibleCollectionDeprecated)：指示集合是否已弃用。
  • 远程 (Remote)
    • 角色远程 (RoleRemote)：支持 v1 Galaxy API 的服务器。目前未使用。
    • 集合远程 (CollectionRemote)：支持 v2 或 v3 Galaxy API 的服务器。
    • Git 远程 (GitRemote)：包含集合作为 Git 仓库的 Git 服务器。目前未使用。
  • 仓库 (Repository)
    • Ansible 仓库 (AnsibleRepository)：包含上面列出的所有 Ansible 内容类型。
  • 分发 (Distribution)
    • Ansible 分发 (AnsibleDistrbution)

此外，Pulp Ansible 定义了以下不扩展任何 Pulp 基类的模型：

  • 集合 (Collection)：用于按命名空间和名称对 CollectionVersions 进行分组。
  • 命名空间 (Namespace)：包含有关集合发布者的信息。这也定义了谁可以在给定命名空间内发布集合。

示例

Pulp Ansible Example

Pulp 容器内容模型

Pulp 容器数据模型有点违反直觉，需要进一步解释。对于此示例，让我们假设我们在 my-registry.example.com 上运行一个容器注册表，其中包含以下容器：

  • container1:latest
  • container1:v1
  • my-namespace/container2:latest
  • my-namespace/container3:latest

人们可能会认为 Pulp 容器使用与 Pulp Ansible 类似的数据模型，其中容器标签（container1:latest、container1:v1 等）被建模为链接到容器（container1、container2 等）的内容，这些容器又链接到容器命名空间（my-namespace）。但这**并非** Pulp 容器的工作方式。在幕后，容器比集合复杂一些。

首先，容器不像集合那样由单个工件组成。相反，它们是一组彼此叠加以形成镜像的镜像层。容器镜像以这种方式设置是因为它们可能非常大，并且分层允许在容器之间重用二进制文件。回到我们的示例，container1:latest 可能具有以下层：

  • 001
  • 002
  • 003

而 container1:v2 可能具有：

  • 001
  • 002
  • 004

通过这种设置，latest 和 v1 可以通过共享层 001 和 002 来节省大量空间。

考虑到所有这些，Pulp 容器定义了以下模型（注意，为简便起见，省略了一些内容类型）：

  • 内容 (Content)
    • Blob：容器镜像层
    • Manifest：容器的镜像层列表
    • Tag：指向 Manifest 的人类可读指针
  • 远程 (Remote)
    • ContainerRemote
  • 仓库 (Repository)
    • ContainerRepository：从远程同步的容器的仓库。
    • ContainerPushRepository：使用 podman 或 docker push 本地推送的容器的仓库。
  • 分发 (Distribution)
    • ContainerDistrbution

通过这种设置，我们前面示例中的容器将如下所示：

Pulp Ansible Example