使用 Red Hat Quay
前言
Red Hat Quay 容器镜像 registry 可让您将容器镜像存储在中央位置。作为 Red Hat Quay registry 的普通用户,您可以创建存储库来组织您的镜像,并选择性地添加读取(pull)和写入(push)访问您控制的存储库。具有管理特权的用户可以执行更广泛的任务,例如添加用户和控制默认设置。
本指南假定您已部署 Red Hat Quay,并准备好开始设置并使用它。
第 1 章 Red Hat Quay 中的用户和机构
在开始创建存储库以将容器镜像保存在 Red Hat Quay 之前,您应该考虑如何组织这些存储库。Red Hat Quay 实例中的每个存储库都必须与机构或用户关联。
1.1. Red Hat Quay 租期模型
- 机构 提供了一种方式,可以在一个不属于单个用户的通用命名空间中共享存储库,而不是共享设置(如公司)中的许多用户。
- 团队 为组织提供了一种方式,将权限(全局和特定存储库)委派给设置或用户组。
-
用户可以通过 Red Hat Quay Web UI 或客户端(如
podman login)登录到 registry。每个用户会自动获得用户命名空间,如quay-server.example.com/user/<username>。 - 超级用户 通过在用户界面中通过 Super User Admin Panel 和 Super User API 调用增强了访问权限和特权,这些调用无法被普通用户可见或访问。
- 机器人帐户 提供对非挂起用户(如管道工具)的仓库的自动访问,并与 OpenShift 服务帐户类似。与任何其他用户或团队一样添加该帐户,可以将权限授予存储库中的机器人帐户。
1.2. 创建用户帐户
为您的 Red Hat Quay 实例创建新用户:
- 以超级用户身份(默认为quay)登录到 Red Hat Quay。
- 从主页右上角选择您的帐户名称,然后选择 Super User Admin Panel。
- 从左列中选择 Users 图标。
- 选择创建用户按钮。
- 输入新用户的用户名和电子邮件地址,然后选择创建用户按钮。
返回到 Users 页面,选择新用户名右侧的 Options 图标。此时会出现下拉菜单,如下图所示:
- 从菜单中选择 Change Password。
- 添加新密码并验证它,然后选择 Change User Password 按钮。
新用户现在可以使用该用户名和密码通过 web ui 或某些容器客户端登录。
1.3. 从命令行删除 Red Hat Quay 用户
在 Red Hat Quay UI 的 Superuser Admin 面板中访问 Users 选项卡时,您可能会遇到没有列出用户的情况。相反,会显示一条消息,表示 Red Hat Quay 被配置为使用外部身份验证,用户只能在该系统中创建。
这个错误由以下两个原因之一:
- 加载用户时,Web UI 会超时。发生这种情况时,用户无法对其执行任何操作。
- 在 LDAP 身份验证中。当更改 userID 时,但关联的电子邮件不是。目前,Red Hat Quay 不允许创建具有旧电子邮件地址的新用户。
在出现这个问题时,使用以下步骤从 Red Hat Quay 中删除用户。
流程
输入以下
curl命令从命令行删除用户:$ curl -X DELETE -H "Authorization: Bearer <insert token here>" https://<quay_hostname>/api/v1/superuser/users/<name_of_user>
注意删除用户后,此用户在其专用帐户中具有的任何存储库都不可用。
1.4. 创建机构帐户
任何用户都可以创建自己的机构来共享容器镜像的存储库。要创建新机构,请执行以下操作:
- 以任何用户身份登录时,从主页右上角选择加号,然后选择 New Organization。
- 键入机构的名称。名称必须是字母数字、所有小写,以及 2 到 255 个字符之间的长度
选择 Create Organization。此时会出现新机构,供您从左列的图标开始添加存储库、团队、机器人帐户和其他功能。下图显示了新机构页面的示例,其中选择了设置选项卡。
第 2 章 创建软件仓库
存储库为存储一组相关容器镜像提供了一个中央位置。在 Red Hat Quay 中创建存储库的方法有两种:通过推送(来自 docker 或 podman)或通过 Red Hat Quay UI。无论您使用 Quay.io 还是您自己的 Red Hat Quay 实例,它们基本上相同。
2.1. 通过 UI 创建镜像存储库
要在 Red Hat Quay UI 中的用户帐户下创建存储库:通过 Web UI 登录用户帐户。点击主页上标头右上角的 + 图标(或与用户相关的其他页面),然后选择 New Repository,如下图所示:
+
在出现的 Create New Repository 页面中
- 在您的用户名中添加新存储库名称
- 单击 Repository Description,再输入存储库的描述
- 在 Repository Visibility 中,选择是否希望存储库是公共还是私有
- 点 Create Repository 按钮。
新存储库已创建为空。在此存储库中拉取镜像的 docker pull 命令(包含镜像名称)会出现在屏幕上。
在机构的 Red Hat Quay UI 中创建存储库:
- 以具有该机构的 Admin 或 Write 权限的用户身份登录。
- 在 Repositories 视图中,从 Users 和 Organizations 下的右侧列中选择机构名称。机构页面会出现,类似于图形 2.x 中显示的页面:
- 单击页面右上角的 +Create New Repository。
在出现的 Create New Repository 页面中:
- 将新存储库名称添加到机构名称
- 单击 Repository Description,再输入存储库的描述
- 在 Repository Visibility 中,选择是否希望存储库是公共还是私有
- 点 Create Repository 按钮。
新存储库已创建为空。在此存储库中拉取镜像的 docker pull 命令(包含镜像名称)会出现在屏幕上。
2.2. 通过 docker 或 podman 创建镜像存储库
假设您有正确的凭证,将镜像推送到 Red Hat Quay 实例中不存在的存储库将创建该存储库,因为它将镜像推送到该存储库。docker 或 podman 命令可用于这些示例。
使用本地系统上
docker或podman提供的镜像标记镜像,使用新存储库名称和镜像名称标记该镜像。以下是将镜像推送到 Quay.io 或您自己的 Red Hat Quay 设置(如 reg.example.com)的示例。例如,将 namespace 替换为您的 Red Hat Quay 用户名或机构,将 repo_name 替换为您要创建的仓库的名称:# sudo podman tag myubi-minimal quay.io/namespace/repo_name # sudo podman tag myubi-standard reg.example.com/namespace/repo_name
推送到适当的 registry。例如:
# sudo podman push quay.io/namespace/repo_name # sudo podman push reg.example.com/namespace/repo_name
要创建应用程序存储库,请按照您创建容器镜像存储库的步骤进行操作。
第 3 章 管理对软件仓库的访问
作为 Red Hat Quay 用户,您可以创建自己的存储库,并使其可以被 Red Hat Quay 实例上的其他用户访问。另外,您可以创建组织来允许基于团队访问存储库。在用户和机构存储库中,您可以通过创建与机器帐户关联的凭证来允许访问这些存储库。通过机器人帐户,可以轻松使用各种容器客户端(如 docker 或 podman)访问您的仓库,而无需客户端具有 Red Hat Quay 用户帐户。
3.1. 允许访问用户存储库
当您在 user 命名空间中创建存储库时,您可以向用户帐户或通过机器帐户添加对该存储库的访问权限。
3.1.1. 允许用户访问用户存储库
要允许访问与用户帐户关联的存储库,请执行以下操作:
- 登录您的 Red Hat Quay 用户帐户。
- 在您要共享访问权限的用户命名空间下选择一个存储库。
- 从左列中选择 Settings 图标。
键入您要授予访问权限的用户的名称。用户名应该在您输入时出现,如下图所示:
在权限框中,选择以下之一:
- Read - 允许用户查看存储库并从中提取。
- Write - 允许用户查看存储库,以及拉取镜像或将镜像推送到存储库。
- admin - 允许对存储库的所有管理设置,以及所有读和写权限。
- 选择 Add Permission 按钮。用户现在具有分配的权限。
要删除对存储库的用户权限,请选择用户条目右侧的 Options 图标,然后选择 Delete Permission。
3.2. 允许机器人访问用户存储库
机器人帐户用于设置对 Red Hat Quay registry 中的软件仓库的自动访问权限。它们与 OpenShift 服务帐户类似。设置机器机器帐户时,您可以:
- 生成与 robot 帐户关联的凭证
- 识别机器可从中推送镜像的存储库和镜像
- 复制并粘贴生成的凭证,以用于不同的容器客户端(如 Docker、podman、Kubernetes、Memos 等)以访问每个定义的存储库
请记住,每个机器人帐户都仅限于单个用户命名空间或机构。例如,机器人可以访问用户 jsmith 可访问的所有存储库,但不能提供给不在用户存储库列表中的任何存储库。
以下流程介绍了设置机器人帐户以允许访问存储库的步骤。
- 选择 slirpot 图标:从 Repositories 视图中,从左列中选择立即选择图标。
- 创建 Crot 帐户 :选择 Createöot Account 按钮。
- 设置 Robot 名:输入名称和描述,然后选择 Create robot account 按钮。robot 名称成为用户名的组合,以及您设置的机器名称(例如:jsmith+myrobot)
为 robot 帐户添加权限:在 robot 帐户的 Add permissions 屏幕中,定义您希望机器人访问的存储库,如下所示:
- 在机器人可以访问的每个存储库旁边放置一个复选标记
对于每个软件仓库,选择以下一个,然后点 Add permissions:
- None - Robot 对存储库没有权限
- Read - Robot 可以从存储库查看和拉取
- write - Iceot 可以从存储库读取和写入(推送)到存储库
- admin - 从存储库拉取和推送到存储库的完整访问权限,还能够执行与存储库关联的管理任务
- 选择 Add permissions 按钮以应用设置
- 在 robotot Accounts 页面中获取用于访问存储库的凭证:在 robotot Accounts 页面中,选择 robotot 帐户名称来查看该机器的凭证信息。
Get the token: Select the Token (如下图所示),以查看为机器机器生成的令牌。如果要重置令牌,请选择 Regenerate Token。
注意务必要理解,重新生成令牌使之前的任何令牌都无效。
获取凭证 :在满足生成的令牌后,使用以下方法获取生成的凭证:
- Kubernetes Secret :选择此项以 Kubernetes pull secret yaml 文件的形式下载凭证。
- rkt Configuration:选择此项以 json 文件的形式下载 rkt 容器运行时的凭证。
-
docker Login :选择此项以复制包含凭据的完整
docker login命令行。 - Docker 配置 :选择此项以下载用作 Docker config.json 文件的文件,将凭据永久存储在您的客户端系统上。
- Mesos Credentials:选择此项以下载 tarball,它提供可在 Mesos 配置文件的 uris 字段中标识的凭证。
3.3. 允许访问机构存储库
创建机构后,您可以将一组存储库直接关联到该机构。要添加对该机构中存储库的访问权限,您可以添加团队(具有相同权限的用户组)和单独的用户。基本上,组织能够创建与用户执行的存储库和机器人帐户,但组织旨在通过用户组(团队或单独)设置共享存储库。
要了解相关机构的其他事项:
- 您不能在另一个机构中拥有机构。要划分一个机构,您可以使用团队。
- 机构不能直接包含用户。您必须首先添加一个团队,然后为每个团队添加一个或多个用户。
- 团队可以在机构中设置为使用存储库和相关镜像的成员,或者作为具有特殊特权来管理该机构的成员
3.3.1. 在机构中添加团队
当您为您的机构创建团队时,您可以选择团队名称,选择要提供给团队的存储库,并决定团队的访问权限级别。
- 在 Organization 视图中,从 left 列中选择 Team 和 Membership 图标。您将看到所有者团队存在具有创建该机构的用户的管理员特权。
- 选择 Create New Team。系统将提示您输入与机构关联的新团队名称。键入团队名称(必须以小写字母开头),其他团队名称作为小写字母和数字的任意组合(不允许使用大写字母或特殊字符)。
- 选择 Create team 按钮。此时会出现 Add permissions 窗口,显示机构中的存储库列表。
检查您希望团队能够访问的每个存储库。然后为每个权限选择以下权限之一:
- Read - 团队成员可以查看和拉取镜像
- Write - 团队成员可以查看、拉取和推送镜像
- admin - 团队成员具有完全的读/写特权,还能够执行与存储库相关的管理任务
- 选择 Add permissions 为团队保存存储库权限。
3.3.2. 设置团队角色
添加团队后,您可以在机构中设置该组的角色。在机构的 Team and Membership 屏幕中,选择 TEAM ROLE 下拉菜单,如下图所示:
对于所选团队,请选择以下角色之一:
- member - 继承为团队设置的所有权限
- 创建者 - 所有成员权限,以及创建新存储库的功能
- admin - 对机构进行完全管理访问权限,包括创建团队、添加成员和设置权限的能力。
3.3.3. 在团队中添加用户
作为具有管理特权的人员,您可以为团队添加用户和机器人。当您添加用户时,它会向该用户发送电子邮件。用户会一直处于待处理状态,直到用户接受邀请。
要将用户或机器机器添加到团队,请从机构的屏幕开始,并执行以下操作:
- 选择您要将用户添加到的团队或机器人。
在团队成员框中,输入以下之一:
- Red Hat Quay registry 中的帐户的用户名
- registry 上用户帐户的电子邮件地址
- robot 帐户的名称。名称必须采用 orgname+robotname 的形式
- 如果是 robot 帐户,它将立即添加到团队中。对于用户帐户,加入的邀请将发送给用户。用户接受该邀请前,用户一直处于 INVITED TO JOIN 状态。
接下来,用户接受电子邮件邀请加入团队。用户下次登录到 Red Hat Quay 实例时,用户从 INVITED TO JOIN 列表移到机构的 MEMBERS 列表。
第 4 章 使用标签
标签提供了一种方式来标识镜像的版本,并提供以不同方式命名同一镜像的方法。除了镜像版本外,镜像标签可以识别其用途(如 devel、test 或 prod),或者它是最新版本(最新)。
在镜像存储库的 Tags 选项卡中,您可以查看、修改、添加、移动、删除和查看标签历史记录。您还可以使用不同的命令获取用于下载(拉取)特定镜像(基于名称和标签)的命令行。
4.1. 查看和修改标签
仓库的标签可以在存储库页面的 tags 面板中查看和修改,点 Tags 选项卡找到。
4.1.1. 在标记的镜像中添加新标签
单击标签旁边的齿轮图标并选择 Add New Tag,来向标记的镜像添加新标签。Red Hat Quay 将确认向镜像添加新标签。
4.1.2. 移动标签
将标签移动到其他镜像可以通过执行与添加新标签相同的操作来实现,但给出现有的标签名称。Red Hat Quay 将确认您希望标签移动,而不是添加。
4.1.3. 删除标签
单击标签的 gear 图标并选择 Delete Tag,可以删除特定标签及其所有镜像。这将删除标签以及它唯一的任何镜像。在没有标签直接或通过父子关系间接引用它们之前,才会删除镜像。
4.1.4. 查看标签历史记录并返回时间
4.1.4.1. 查看标签历史记录
要查看标签的镜像历史记录,请单击 Actions 菜单下的 View Tags History 菜单项。显示页面将显示过去指向以及指向该镜像的每个镜像。
4.1.4.2. 返回时间
要将标签恢复到以前的镜像,请找到覆盖所需镜像的历史行,然后点击 Restore 链接。
4.1.5. 通过标签或摘要获取镜像
在 Tags 选项卡中,您可以查看从就绪使用这些镜像的客户端拉取镜像的不同方法。
- 选择特定的存储库/镜像
- 在左列中选择 Tags
- 选择特定镜像/标签组合的 Fetch Tag 图标
- 出现 Fetch Tag 弹出窗口中,选择 Image Format 复选框来查看一个下拉菜单,它显示了可用于拉取镜像的不同方法。选择提供将特定容器镜像拉取到本地系统的完整命令行:
您可以选择通过标签名称或使用 docker 命令摘要名称来拉取镜像的常规。选择您想要的拉取类型,然后选择 Copy Command。完整的命令行被复制到您的剪贴板中。这两个命令显示 docker pull by tag 和 digest:
docker pull quay.io/cnegus/whatever:latest docker pull quay.io/cnegus/whatever@sha256:e02231a6aa8ba7f5da3859a359f99d77e371cb47e643ce78e101958782581fb9
将命令粘贴到具有 docker 命令和服务的系统中的命令行 shell 中,然后按 Enter 键。此时,容器镜像已准备好在本地系统上运行。
在 RHEL 和 Fedora 系统中,您可以使用 podman 替换 docker 来拉取并运行所选镜像。
4.2. 标签过期
可以使用名为 tag expiration 的功能,将镜像设置为从 Red Hat Quay 存储库中过期。对于标签过期,需要了解以下内容:
- 当标签过期时,标签会从存储库中删除。如果它是特定镜像的最后一个标签,则会将镜像设置为已删除。
- 过期时间以每个标签为基础设置,而不是针对整个存储库设置。
- 当标签过期或被删除时,它不会立即从 registry 中删除。Time Machine 的值(在 User settings 中)定义何时删除的标签以及垃圾回收垃圾。默认情况下,该值为 14 天。直到该时间之前,标签可以重新指向已过期或删除的镜像。
- Red Hat Quay 超级用户没有与从用户存储库中删除已过期的镜像相关的特殊权限。超级用户没有中央机制来收集信息并对用户存储库执行操作。最多每个存储库的所有者来管理过期并最终删除其镜像。
标签过期可以以不同的方式设置:
-
在创建镜像时,通过在 Dockerfile 中设置
quay.expires-after=LABEL。这会将一个时间设置为在构建镜像时过期。 - 通过从存储库标签的 EXPIRES 列中选择过期日期并选择要到期的特定日期和时间。
下图显示了更改标签过期的 Options 条目,以及标签过期时 EXPIRES 字段。将鼠标悬停在 EXPIRES 字段上,以查看当前设置的过期日期和时间。
4.2.1. 从 Dockerfile 设置标签过期
通过 Dockerfile LABEL 命令添加类似 quay.expires-after=20h 的标签将导致标签在指示的时间后自动过期。时间值可以类似 1h, 2d, 3w,分别代表小时、天和星期(自镜像构建的时间)。
4.2.2. 从存储库设置标签过期
在 Repository Tag 页面中,有一个名为 EXPIRES 的 UI 列,它指示标签何时过期。用户可以通过单击右侧的设置时间或单击右侧的 Settings 按钮(齿轮图标),然后选择 Change Expiration 来设置此设置。
选择提示时的日期和时间,然后选择 Change Expiration。当达到过期时间时,标签将从存储库中删除。
4.3. 安全扫描
单击选项卡旁边的漏洞或可修复数,您可以跳至该标签的安全扫描信息。您可以发现您的镜像存在哪些 CVE,以及您可能可用的补救选项。
请记住,镜像扫描只列出 Clair 镜像扫描程序发现的漏洞。每个用户对未恢复的漏洞执行的操作对于该用户完全有什么。Red Hat Quay 超级用户不处理发现的漏洞。
第 5 章 查看和导出日志
为 Red Hat Quay 中的所有存储库和命名空间(用户和机构)收集活动日志。可以通过多种方式访问日志文件,包括:
- 通过 Web UI 查看日志
- 导出日志以便可以在外部保存日志。
- 通过 API 访问日志条目
要访问日志,您必须具有所选存储库或命名空间的 Admin 权限。
通过 API 一次提供最多 100 个日志结果。要收集更多结果,您必须使用本章中描述的日志导出器功能。
5.1. 查看日志
要从 Web UI 查看存储库或命名空间的日志条目,请执行以下操作:
- 选择具有管理员特权的存储库或命名空间(机构或用户)。
从左列中选择 Usage Logs 图标。此时会出现 Usage Logs 屏幕,如下图所示:
在 Usage Logs 页面中,您可以:
- 通过在 From 和 to 框中添加日期来设置查看日志条目的日期范围。默认情况下,最近一周的日志条目会显示。
- 在 Filter Logs 框中输入一个字符串,以显示容器给定字符串的日志条目。
- 将箭头切换到任何日志条目的左侧,以查看与该日志条目关联的一个或多个文本。
5.2. 导出存储库日志
要获取大量日志文件,并将它们保存到 Red Hat Quay 数据库之外,您可以使用 Export Logs 功能。您应该了解有关使用导出日志的一些内容:
- 您可以为您要从存储库收集的日志选择一系列日期。
- 您可以通过电子邮件附加请求日志发送到您,或定向到回调 URL。
- 您需要对存储库或命名空间的管理特权导出日志
- 一次导出最多 30 天日志数据
- 导出日志只收集之前生成的日志数据。它不会流传输日志数据。
- 必须为这个功能配置外部存储(本地存储无法正常工作)。
- 收集日志并可用后,如果您要保存该数据,则应立即复制这些数据。默认情况下,数据在一小时内过期。
使用 Export Logs 功能:
- 选择具有 Admin 权限的存储库。
- 从左列中选择 Usage Logs 图标。此时会出现 Usage Logs 屏幕。
- 选择您要收集的日志条目的 From 和 to date 范围。
选择 Export Logs 按钮。此时会出现 Export Usage Logs 弹出窗口,如下所示
- 输入您要接收导出的日志的电子邮件地址或回调 URL。对于回调 URL,您可以使用 URL 作为位置,如 webhook.site。
- 选择 Start Logs Export。这会导致 Red Hat Quay 开始收集所选日志条目。根据所收集的日志数据量,这可能需要从一分钟到一小时完成的时间。
日志导出完成后,您将:
- 收到电子邮件,提醒您所请求导出的日志条目的可用性。
- 请参阅来自 Webhook URL 的日志导出请求的成功状态。您可以选择下载日志的导出的数据链接。
请记住,URL 指向 Red Hat Quay 外部存储中的一个位置,并在一小时内过期。因此,如果您打算保留这些日志,请确保在过期时间前复制导出的日志。
第 6 章 使用构建 worker 自动构建 Dockerfile
Red Hat Quay 支持使用 OpenShift 或 Kubernetes 上的一组 worker 节点构建 Dockerfile。构建触发器(如 GitHub Webhook)可以配置为在新代码提交时自动构建新版本的存储库。本文档将指导您使用 Red Hat Quay 安装启用构建,并设置一个或多个 OpenShift/K8s 集群,以接受来自 Red Hat Quay 的构建。使用 Red Hat Quay 3.4 时,底层构建管理器已作为 Red Hat Quay 2 从 Python 2 迁移到 Python 3 的一部分进行了彻底重写。现在,构建程序节点会动态创建为 Kubernetes 作业与在 Red Hat Quay 3.3 及更早版本中持续运行的构建器节点。这大大简化了 Red Hat Quay 如何管理构建,并提供相同的机制 quay.io,用于每天处理数千个容器镜像构建。目前在 Red Hat Quay 3.3 下运行静态("企业"构建器的客户,则需要迁移到基于 Kubernetes 的构建机制。
6.1. 架构概述
Red Hat Quay 构建系统专为可扩展性而设计(因为它用于在 quay.io 上托管所有构建)。Red Hat Quay 的 Build Manager 组件提供了一个编配层,用于跟踪构建请求,并确保 Build Executor (OpenShift/K8s 集群)将执行每个请求。每个构建都由 Kubernetes 作业处理,它启动一个小虚拟机来完全隔离和包含镜像构建过程。这样可确保容器构建不会相互或底层构建系统的影响。可以配置多个可执行文件,以确保在基础架构失败时执行构建。Red Hat Quay 将自动将构建发送到不同的执行者(如果其检测到一个执行者有困难)。
Red Hat Quay 的上游版本提供了如何配置基于 AWS/EC2 的可执行文件的说明。Red Hat Quay 客户不支持此配置。
6.1.1. 构建管理器
构建管理器负责调度的构建的生命周期。需要更新构建队列、构建阶段和运行作业状态的操作由构建管理器处理。
6.1.2. 构建 worker 的 control plane
构建作业在不同的 worker 节点上运行,并调度到单独的 control plane (executor)上。目前,Red Hat Quay 支持在 AWS 和 Kubernetes 上运行作业。使用 quay.io/quay/quay-builder 执行构建。在 AWS 上,构建调度到 EC2 实例。在 k8s 上,构建被调度为作业资源。
6.1.3. Orchestrator
编配器用于存储当前运行的构建作业的状态,并发布构建管理器要使用的事件。例如,到期事件。目前,支持的编配器后端是 Redis。
6.2. OpenShift 要求
Red Hat Quay 构建在 Kubernetes 和 OpenShift 4.5 及更高版本中被支持。需要裸机(非虚拟化)worker 节点,因为构建 pod 需要能够运行 kvm 虚拟化。每个构建在临时虚拟机中完成,确保在构建运行时确保完全隔离和安全性。另外,您的 OpenShift 集群应该允许与 Red Hat Quay 构建关联的 ServiceAccount 使用必要的 SecurityContextConstraint 运行来支持特权容器。
6.3. Orchestrator 要求
Red Hat Quay 构建需要访问 Redis 实例来跟踪构建状态信息。可以接受使用与 Red Hat Quay 安装一起部署的相同 Redis 实例。所有构建队列都在 Red Hat Quay 数据库中管理,因此不需要高可用性 Redis 实例。
6.4. 使用 OpenShift 设置 Red Hat Quay Builder
6.4.1. OpenShift TLS 组件
tls 组件允许您控制 TLS 配置。
当 TLS 组件由 Operator 管理时,Red Hat Quay 3.7 不支持构建器。
如果将 tls 设置为 unmanaged,则提供自己的 ssl.cert 和 ssl.key 文件。在本实例中,如果希望集群支持构建器,您必须将 Quay 路由和构建器路由名称添加到证书中的 SAN 列表中,也可以使用通配符。要添加构建器路由,请使用以下格式:
[quayregistry-cr-name]-quay-builder-[ocp-namespace].[ocp-domain-name]
6.4.2. 为 Red Hat Quay 构建准备 OpenShift
OpenShift 集群上需要一些操作,然后才能接受来自 Red Hat Quay 的构建。
创建一个运行构建的项目(如 'builder')
$ oc new-project builder
在此
项目中创建一个ServiceAccount,它将用于运行构建。确保它有足够的权限来创建作业和Pod。复制ServiceAccount的令牌以供以后使用。$ oc create sa -n builder quay-builder $ oc policy add-role-to-user -n builder edit system:serviceaccount:builder:quay-builder $ oc sa get-token -n builder quay-builder
- 识别 OpenShift 集群 API 服务器的 URL。这可以从 OpenShift 控制台找到。
-
识别在调度构建作业时要使用的 worker
节点标签。由于构建 pod 需要在裸机 worker 节点上运行,因此通常使用特定的标签来标识它们。与集群管理员进行检查,以确定应使用哪个节点标签。 如果集群使用自签名证书,请获取 kube apiserver 的 CA 被添加到 Red Hat Quay 的额外证书中。
获取包含 CA 的 secret 名称:
$ oc get sa openshift-apiserver-sa --namespace=openshift-apiserver -o json | jq '.secrets[] | select(.name | contains("openshift-apiserver-sa-token"))'.name-
从 Openshift 控制台中的 secret 获取
ca.crt键值。该值应该以 "-----BEGIN CERTIFICATE-----" 开头 -
使用 ConfigTool 在 Red Hat Quay 中导入 CA。确保此文件的名称与
K8S_API_TLS_CA匹配。
-
为
ServiceAccount创建所需的安全上下文/角色绑定:
apiVersion: security.openshift.io/v1 kind: SecurityContextConstraints metadata: name: quay-builder priority: null readOnlyRootFilesystem: false requiredDropCapabilities: null runAsUser: type: RunAsAny seLinuxContext: type: RunAsAny seccompProfiles: - '*' supplementalGroups: type: RunAsAny volumes: - '*' allowHostDirVolumePlugin: true allowHostIPC: true allowHostNetwork: true allowHostPID: true allowHostPorts: true allowPrivilegeEscalation: true allowPrivilegedContainer: true allowedCapabilities: - '*' allowedUnsafeSysctls: - '*' defaultAddCapabilities: null fsGroup: type: RunAsAny --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: quay-builder-scc namespace: builder rules: - apiGroups: - security.openshift.io resourceNames: - quay-builder resources: - securitycontextconstraints verbs: - use --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: quay-builder-scc namespace: builder subjects: - kind: ServiceAccount name: quay-builder roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: quay-builder-scc
6.4.3. 启用构建器并在 Red Hat Quay 的配置捆绑包中添加构建配置
- 确保您已在 Red Hat Quay 配置中启用了构建。
FEATURE_BUILD_SUPPORT: True
- 在 Red Hat Quay 配置捆绑包中添加以下内容,将每个值替换为特定于安装的值。
目前,只有构建功能本身可以通过 Red Hat Quay Config Tool 启用。Build Manager 和 Executors 的实际配置必须在 config.yaml 文件中手动完成。
BUILD_MANAGER:
- ephemeral
- ALLOWED_WORKER_COUNT: 1
ORCHESTRATOR_PREFIX: buildman/production/
ORCHESTRATOR:
REDIS_HOST: quay-redis-host
REDIS_PASSWORD: quay-redis-password
REDIS_SSL: true
REDIS_SKIP_KEYSPACE_EVENT_SETUP: false
EXECUTORS:
- EXECUTOR: kubernetes
BUILDER_NAMESPACE: builder
K8S_API_SERVER: api.openshift.somehost.org:6443
K8S_API_TLS_CA: /conf/stack/extra_ca_certs/build_cluster.crt
VOLUME_SIZE: 8G
KUBERNETES_DISTRIBUTION: openshift
CONTAINER_MEMORY_LIMITS: 5120Mi
CONTAINER_CPU_LIMITS: 1000m
CONTAINER_MEMORY_REQUEST: 3968Mi
CONTAINER_CPU_REQUEST: 500m
NODE_SELECTOR_LABEL_KEY: beta.kubernetes.io/instance-type
NODE_SELECTOR_LABEL_VALUE: n1-standard-4
CONTAINER_RUNTIME: podman
SERVICE_ACCOUNT_NAME: *****
SERVICE_ACCOUNT_TOKEN: *****
QUAY_USERNAME: quay-username
QUAY_PASSWORD: quay-password
WORKER_IMAGE: <registry>/quay-quay-builder
WORKER_TAG: some_tag
BUILDER_VM_CONTAINER_IMAGE: <registry>/quay-quay-builder-qemu-rhcos:v3.4.0
SETUP_TIME: 180
MINIMUM_RETRY_THRESHOLD: 0
SSH_AUTHORIZED_KEYS:
- ssh-rsa 12345 someuser@email.com
- ssh-rsa 67890 someuser2@email.com下面解释每个配置字段。
- ALLOWED_WORKER_COUNT
- 定义每个 Red Hat Quay Pod 实例化多少个构建工作程序。通常这是 '1'。
- ORCHESTRATOR_PREFIX
- 定义要添加到所有 Redis 密钥的唯一前缀(用于将 Orchestrator 值与其他 Redis 键隔离)。
- REDIS_HOST
- Redis 服务的主机名。
- REDIS_PASSWORD
- 在 Redis 服务中进行身份验证的密码。
- REDIS_SSL
- 定义 Redis 连接是否使用 SSL。
- REDIS_SKIP_KEYSPACE_EVENT_SETUP
-
默认情况下,Red Hat Quay 不会设置运行时密钥事件所需的键空间事件。为此,请将 REDIS_SKIP_KEYSPACE_EVENT_SETUP 设置为
false。 - EXECUTOR
- 启动此类型的执行者的定义。有效值为 'kubernetes' 和 'ec2'
- BUILDER_NAMESPACE
- Red Hat Quay 构建要放置的 Kubernetes 命名空间
- K8S_API_SERVER
- 构建将放置的 OpenShift 集群的主机名
- K8S_API_TLS_CA
-
构建集群的 CA 证书的
Quay容器中文件路径,供 Quay 应用在发出 API 调用时信任。 - KUBERNETES_DISTRIBUTION
- 指明正在使用的 Kubernetes 类型。有效值为 'openshift' 和 'k8s'。
- CONTAINER_*
- 定义每个构建 pod 的资源请求和限值。
- NODE_SELECTOR_*
- 定义应当调度构建 Pod 的节点选择器标签名称/值对。
- CONTAINER_RUNTIME
-
指定构建器是否应该运行
docker还是podman。使用红帽的quay-builder镜像的客户应将其设置为podman。 - SERVICE_ACCOUNT_NAME/SERVICE_ACCOUNT_TOKEN
- 定义构建 Pod 将要使用的服务帐户名称/令牌。
- QUAY_USERNAME/QUAY_PASSWORD
- 定义拉取 WORKER_IMAGE 字段中指定的 Red Hat Quay 构建 worker 镜像所需的 registry 凭证。客户应提供一个 Red Hat Service Account 凭证,如 https://access.redhat.com/RegistryAuthentication 文章中的针对 registry.redhat.io 的"创建 Registry 服务账户"部分。
- WORKER_IMAGE
- Red Hat Quay 构建器镜像的镜像引用。registry.redhat.io/quay/quay-builder
- WORKER_TAG
- 所需构建器镜像的标签。最新版本为 v3.4.0。
- BUILDER_VM_CONTAINER_IMAGE
-
对包含运行每个 Red Hat Quay 构建(
registry.redhat.io/quay/quay-builder-qemu-rhcos:v3.4.0)所需的内部虚拟机的完整引用。 - SETUP_TIME
- 指定构建程序(如果构建管理器尚未注册)时构建超时的秒数(默认为 500 秒)。超时的构建将尝试重新启动三次。如果构建在三次尝试后没有注册自己,则被视为失败。
- MINIMUM_RETRY_THRESHOLD
-
此设置用于多个执行者;它指示在选择不同的可执行文件前尝试启动构建的次数。设置为 0 表示构建作业需要多少个尝试。这个值应该保持特小(三个或更少),以确保在基础架构故障时快速进行故障转移。您必须为此设置指定一个值。例如,g Kubernetes 设置为第一个 executor,EC2 作为第二个 executor。如果我们希望最终试图运行的作业总在 EC2 上而不是在 Kubernetes 上运行时,应该将 Kubernetes executor 的
MINIMUM_RETRY_THRESHOLD设置为 1,EC2 的MINIMUM_RETRY_THRESHOLD设置为 0 (如果没有设置,默认为 0)。在这种情况下,kubernetes 的MINIMUM_RETRY_THRESHOLD> retries_remaining (1)将评估为 False,因此回退到配置的第二个 executor - SSH_AUTHORIZED_KEYS
- 在 ignition 配置中引导的 ssh 密钥列表。这允许使用其他密钥 ssh 到 EC2 实例或 QEMU 虚拟机
6.5. OpenShift 路由限制
本节只有在 OpenShift 中使用带有受管 路由 组件的 Quay Operator 时才适用。
由于 OpenShift 路由 的限制只能为单个端口提供流量,需要额外的步骤来设置构建。确保 kubectl 或 oc CLI 工具被配置为与安装 Quay Operator 的集群以及您的 QuayRegistry 存在的集群一起使用(不一定与运行构建器的裸机集群相同)。
- 按照以下步骤,确保 OpenShift 集群上启用了 HTTP/2 入口。
Quay Operator 将创建一个路由,它将 gRPC 流量定向到在现有 Quay pod 内运行的构建管理器服务器。
如果要使用自定义主机名(如builder.registry.example.com),请确保创建一个带有 DNS 供应商的 CNAME 记录,指向所创建路由的status.ingress[0].host:$ kubectl get -n <namespace> route <quayregistry-name>-quay-builder -o jsonpath={.status.ingress[0].host}通过 OpenShift UI 或 CLI,使用构建集群 CA 证书(密钥
extra_ca_cert_build_cluster.cert)更新QuayRegistry的spec.configBundleSecret引用的Secret, 使用上面的构建程序配置(取决于您的构建 executor))中引用的正确的值以及BUILDMAN_HOSTNAME字段更新config.yaml条目:BUILDMAN_HOSTNAME: <build-manager-hostname> BUILD_MANAGER: - ephemeral - ALLOWED_WORKER_COUNT: 1 ORCHESTRATOR_PREFIX: buildman/production/ JOB_REGISTRATION_TIMEOUT: 600 ORCHESTRATOR: REDIS_HOST: quay-redis-host REDIS_PASSWORD: quay-redis-password REDIS_SSL: true REDIS_SKIP_KEYSPACE_EVENT_SETUP: false EXECUTORS: - EXECUTOR: kubernetes BUILDER_NAMESPACE: builder ...
下面解释了额外的配置字段:
- BUILDMAN_HOSTNAME
-
构建任务用来与构建管理器通信的外部可访问服务器主机名。默认与
SERVER_HOSTNAME相同。对于 OpenShiftRoute,如果使用自定义主机名,它是status.ingress[0].host或 CNAME 条目。BUILDMAN_HOSTNAME需要包含 端口号,如 Openshift Route 的somehost:443,因为用于与构建管理器通信的 gRPC 客户端不会推断任何端口(如果省略)。
6.6. 构建故障排除
构建管理器启动的构建器实例是临时的。这意味着,它们将在超时/故障时由 Red Hat Quay} 关闭,或者 control plane (EC2/K8s)收集的垃圾箱。这意味着,为了获取构建器日志,在构建 运行时 需要这样做。
6.6.1. DEBUG 配置标志
可以设置 DEBUG 标志,以防止在完成/失败后清理构建器实例。要做到这一点,在所需的 executor 配置中,将 DEBUG 设置为 true。例如:
EXECUTORS:
- EXECUTOR: ec2
DEBUG: true
...
- EXECUTOR: kubernetes
DEBUG: true
...当设置为 true 时,DEBUG 会在 quay-builder 服务完成后防止构建节点关闭,并阻止构建管理器清理实例(确定 EC2 实例或删除 k8s 作业)。这将允许调试构建器节点问题,不应在生产环境中 设置。生命周期服务仍然存在。例如,实例仍然会在大约 2 小时后(EC2 实例终止,k8s 作业将完成)设置 DEBUG 将影响 ALLOWED_WORKER_COUNT,因为未终止的实例/作业仍会计算到正在运行的 worker 总数。这意味着,如果达到 ALLOWED_WORKER_COUNT,则需要手动删除现有的构建器 worker,才能调度新的构建。
使用以下步骤:
客户机虚拟机将其 SSH 端口(22)转发到其主机的(容器集)端口 2222。端口将构建器 pod 的端口 2222 转发到 localhost 上的端口。例如
$ kubectl port-forward <builder pod> 9999:2222
使用 SSH_AUTHORIZED_KEYS 中的一个密钥,通过 SSH 连接到容器中运行的虚拟机:
$ ssh -i /path/to/ssh/key/set/in/ssh_authorized_keys -p 9999 core@localhost
获取 quay-builder 服务日志:
$ systemctl status quay-builder $ journalctl -f -u quay-builder
第 2-3 步也可以在单一 SSH 命令中完成:
$ ssh -i /path/to/ssh/key/set/in/ssh_authorized_keys -p 9999 core@localhost ‘systemctl status quay-builder’ $ ssh -i /path/to/ssh/key/set/in/ssh_authorized_keys -p 9999 core@localhost ‘journalctl -f -u quay-builder’
6.7. 设置 GitHub 构建(可选)
如果您的组织计划通过推送到 GitHub (或 GitHub Enterprise)进行构建,请在 GitHub 中创建 OAuth 应用程序。
第 7 章 构建 Dockerfile
Red Hat Quay 支持在我们的构建团队上构建 Dockerfile,并将生成的镜像推送到存储库。
7.1. 查看和管理构建
单击 Repository View 中的 Builds 选项卡可以查看和管理存储库构建。
7.2. 手动启动构建
若要手动启动存储库构建,请单击任何存储库页面上标头右上角的 + 图标,然后选择 New Dockerfile Build。上传的 Dockerfile、.tar.gz 或用于构建的 HTTP URL。
在手动启动构建时,您将无法指定 Docker 构建上下文。
7.3. 构建触发器
存储库构建也可以由事件(如推送到 SCM、BitBucket 或 GitLab)或 调用 webhook 自动触发。
7.3.1. 创建新构建触发器
要设置构建触发器,请点击 Builds 视图 页面中的 Create Build Trigger 按钮,并按照对话框的说明进行操作。您需要授予 Red Hat Quay 对存储库的访问权限,才能设置触发器,并且您的帐户 需要对 SCM 存储库的管理员访问权限。
7.3.2. 手动触发构建触发器
要手动触发构建触发器,请单击构建触发器旁边的图标,然后选择 Run Now。
7.3.3. 构建上下文
使用 Docker 构建镜像时,将指定一个目录来成为构建上下文。这在手动构建和构建触发器中都为 true,因为由 Red Hat Quay 执行的构建与在您自己的计算机上运行 docker build 不同。
如果未指定,Red Hat Quay 构建上下文始终是来自构建设置所指定的子目录,并将回退到构建源的根目录。触发构建后,Red Hat Quay 构建 worker 会将 git 存储库克隆到 worker 机器,并在执行构建前输入构建上下文。
对于基于 tar 归档的构建,构建 worker 会提取存档并输入构建上下文。例如:
example
├── .git
├── Dockerfile
├── file
└── subdir
└── Dockerfile假设您的例子是名为"example"的 GitHub 存储库的目录结构。如果在构建触发器设置或手动启动构建时没有指定子目录,则构建将在 example 目录中操作。
如果将 subdir 指定为构建触发器设置中的子目录,则只有其内的 Dockerfile 才能在构建中看到。这意味着您无法使用 Dockerfile 中的 ADD 命令来添加 文件,因为它位于构建上下文之外。
与 Docker Hub 不同,Dockerfile 是 Red Hat Quay 上的构建上下文的一部分。因此,它不能出现在 .dockerignore 文件中。
第 8 章 设置自定义 Git 触发器
Custom Git Trigger 是任何 git 服务器充当构建触发器的通用方法。它只依赖于 SSH 密钥和 Webhook 端点;其他部分都保留给用户实施。
8.1. 创建触发器
创建自定义 Git 触发器与创建任何其他触发器类似,但有以下几个细微差异:
- Red Hat Quay 无法自动检测要与触发器搭配使用的正确机器帐户。这必须在创建过程中手动完成。
- 创建触发器后,必须执行额外的步骤才能使用触发器。这些步骤的详情如下。
8.2. 创建后触发设置
创建触发器后,在使用触发器前需要两个额外的步骤 :
- 提供对创建触发器时生成的 SSH 公钥 的读取访问。
- 设置 POST 到 Red Hat Quay 端点以触发构建的 webhook。
密钥和 URL 都可以通过从触发器列表中的 gear 中选择 View Credentials。
8.2.1. SSH 公钥访问
根据 Git 服务器设置,可以通过各种方法为自定义 git 触发器安装 Red Hat Quay 生成的 SSH 公钥。例如,Git 文档描述了一个小型服务器设置,只需将密钥添加到 $HOME/.ssh/authorize_keys 中即可提供对构建器克隆存储库的访问权限。对于任何未正式支持的 git 存储库管理软件,通常有一个位置来输入通常标记为 Deploy Keys 的密钥。
8.2.2. Webhook
要自动触发构建,必须通过以下格式将 JSON 有效负载 POST 到 webhook URL:
{
"commit": "1c002dd", // required
"ref": "refs/heads/master", // required
"default_branch": "master", // required
"commit_info": { // optional
"url": "gitsoftware.com/repository/commits/1234567", // required
"message": "initial commit", // required
"date": "timestamp", // required
"author": { // optional
"username": "user", // required
"avatar_url": "gravatar.com/user.png", // required
"url": "gitsoftware.com/users/user" // required
},
"committer": { // optional
"username": "user", // required
"avatar_url": "gravatar.com/user.png", // required
"url": "gitsoftware.com/users/user" // required
}
}
}
此请求需要一个 Content-Type 标头,其中包含 application/json 才能有效。
同样,这可以通过各种方式完成,具体取决于服务器设置,但在大多数情况下,可以通过 post-receive git hook 来完成。
第 9 章 跳过源控制构建
要指定 Red Hat Quay 构建系统应忽略提交,请在提交消息中的任何位置添加文本 [skip build] 或 [build skip]。
第 10 章 设置 GitHub 构建触发器标签
Red Hat Quay 支持使用 GitHub 或 GitHub Enterprise 作为构建镜像的触发器。如果您还没有这样做,请提前在 Red Hat Quay 中启用构建支持。
10.1. 了解构建触发器的标签命名
在 Red Hat Quay 3.3 之前,从构建触发器创建的镜像是如何被限制的。由构建触发器构建的镜像被命名为:
- 使用更改调用触发器的分支或标签
-
使用使用默认分支的镜像的
latest标签
从 Red Hat Quay 3.3 及更高版本开始,您可以具有更大的灵活性来如何设置镜像标签。首先,您可以输入自定义标签,使任意字符串分配为每个构建镜像的标签。但是,作为替代方案,您可以使用以下标签模板使用每个提交的信息标记镜像:
- ${commit_info.short_sha}: 提交的短 SHA
- ${commit_info.date} :提交的时间戳
- ${commit_info.author} :提交的作者
- ${commit_info.committer} :提交的提交者
- ${parsed_ref.branch}: 分支名称
以下流程描述了如何为构建触发器设置标记。
10.2. 为构建触发器设置标签名称
按照以下步骤为构建触发器配置自定义标签:
- 从存储库视图中,从左侧导航中选择 Builds 图标。
选择 Create Build Trigger 菜单,然后选择您想要的存储库推送类型(GitHub、Bitbucket、GitLab 或 Custom Git repository push)。在本例中,选择了 GitHub Repository Push,如下图所示。
- 当出现 Setup Build Trigger 页面时,选择您要在其中设置触发器的存储库和命名空间。
在 Configure Trigger 下,选择 Trigger for all branches and tags 或 Trigger only on branches and tags matching a regular expression。然后选择 Continue。此时会出现 Configure Tagging 部分,如下图所示:
向下滚动到 Configure Tagging 并从以下选项中选择:
- 带有分支或标签名称的标签清单 :选中此框,以使用提交作为镜像上使用标签的分支或标签的名称。这默认是启用的。
-
如果在默认分支上,请添加
latest标签:选中此框,如果镜像位于存储库的默认分支上,则使用 latest 标签。这默认是启用的。 - 添加自定义标记模板 :在 Enter a tag template 框中输入自定义标签或模板。您可以在此处输入多个标签模板,如本节前面所述。它们包括使用简短 SHA、时间戳、作者名称、提交者和分支名称的方法,作为标签。
- 选择 Continue。系统会提示您为 Docker 构建选择目录构建上下文。构建上下文目录标识包含 Dockerfile 的目录位置,以及触发构建时所需的其他文件。如果 Dockerfile 位于 git 存储库的根目录中,请输入 "/"。
- 选择 Continue。此时会提示您输入一个可选的 Robot 帐户。如果要在构建过程中拉取私有基础镜像。robot 帐户需要访问构建。
- 选择 Continue 来完成构建触发器的设置。
如果您要返回存储库的 Repository Builds 页面,则您设置的构建触发器将列在 Build Triggers 标题下。
第 11 章 在 GitHub 中创建 OAuth 应用程序
您可以通过将 registry 注册为 GitHub OAuth 应用程序来授权 registry 访问 GitHub 帐户及其存储库。
11.1. 创建新 GitHub 应用程序
- 登录 GitHub (Enterprise)
- 访问您组织的设置下的 Applications 页面。
-
点 Register New Application。此时会显示
Register a new OAuth 应用程序配置屏幕:
设置主页 URL:输入 Quay Enterprise URL 作为
主页 URL注意如果使用公共 GitHub,则输入的 Homepage URL 必须可以被您的用户访问。它可以是内部 URL。
- 设置 Authorization callback URL: 输入 https://{$RED_HAT_QUAY_URL}/oauth2/github/callback 作为授权回调 URL。
- 点 Register application 按钮保存您的设置。此时会显示新的新应用程序概述:
- 记录为新应用程序显示的客户端 ID 和客户端 Secret。
第 12 章 仓库通知
Quay 支持在存储库中为在存储库的生命周期中发生的各种事件添加通知。要添加通知,请在查看存储库时单击 Settings 选项卡,然后选择 Create Notification。在 when this event occurred 字段中,选择要接收通知的项目:
选择事件后,通过添加如何通知该事件来进一步进行配置。
添加通知需要 存储库管理员权限。
以下是存储库事件的示例。
12.1. 仓库事件
12.1.1. Repository Push
成功推送一个或多个镜像被推送到存储库:
{
"name": "repository",
"repository": "dgangaia/test",
"namespace": "dgangaia",
"docker_url": "quay.io/dgangaia/test",
"homepage": "https://quay.io/repository/dgangaia/repository",
"updated_tags": [
"latest"
]
}12.1.2. Dockerfile 构建队列
以下是 Dockerfile 构建的示例响应排队到构建系统中。响应可能会根据可选属性的使用而有所不同。
{
"build_id": "296ec063-5f86-4706-a469-f0a400bf9df2",
"trigger_kind": "github", //Optional
"name": "test",
"repository": "dgangaia/test",
"namespace": "dgangaia",
"docker_url": "quay.io/dgangaia/test",
"trigger_id": "38b6e180-9521-4ff7-9844-acf371340b9e", //Optional
"docker_tags": [
"master",
"latest"
],
"repo": "test",
"trigger_metadata": {
"default_branch": "master",
"commit": "b7f7d2b948aacbe844ee465122a85a9368b2b735",
"ref": "refs/heads/master",
"git_url": "git@github.com:dgangaia/test.git",
"commit_info": { //Optional
"url": "https://github.com/dgangaia/test/commit/b7f7d2b948aacbe844ee465122a85a9368b2b735",
"date": "2019-03-06T12:48:24+11:00",
"message": "adding 5",
"author": { //Optional
"username": "dgangaia",
"url": "https://github.com/dgangaia", //Optional
"avatar_url": "https://avatars1.githubusercontent.com/u/43594254?v=4" //Optional
},
"committer": {
"username": "web-flow",
"url": "https://github.com/web-flow",
"avatar_url": "https://avatars3.githubusercontent.com/u/19864447?v=4"
}
}
},
"is_manual": false,
"manual_user": null,
"homepage": "https://quay.io/repository/dgangaia/test/build/296ec063-5f86-4706-a469-f0a400bf9df2"
}12.1.3. Dockerfile 构建已启动
下面是构建系统启动的 Dockerfile 构建示例。响应可能会因某些属性是可选的而有所不同。
{
"build_id": "a8cc247a-a662-4fee-8dcb-7d7e822b71ba",
"trigger_kind": "github", //Optional
"name": "test",
"repository": "dgangaia/test",
"namespace": "dgangaia",
"docker_url": "quay.io/dgangaia/test",
"trigger_id": "38b6e180-9521-4ff7-9844-acf371340b9e", //Optional
"docker_tags": [
"master",
"latest"
],
"build_name": "50bc599",
"trigger_metadata": { //Optional
"commit": "50bc5996d4587fd4b2d8edc4af652d4cec293c42",
"ref": "refs/heads/master",
"default_branch": "master",
"git_url": "git@github.com:dgangaia/test.git",
"commit_info": { //Optional
"url": "https://github.com/dgangaia/test/commit/50bc5996d4587fd4b2d8edc4af652d4cec293c42",
"date": "2019-03-06T14:10:14+11:00",
"message": "test build",
"committer": { //Optional
"username": "web-flow",
"url": "https://github.com/web-flow", //Optional
"avatar_url": "https://avatars3.githubusercontent.com/u/19864447?v=4" //Optional
},
"author": { //Optional
"username": "dgangaia",
"url": "https://github.com/dgangaia", //Optional
"avatar_url": "https://avatars1.githubusercontent.com/u/43594254?v=4" //Optional
}
}
},
"homepage": "https://quay.io/repository/dgangaia/test/build/a8cc247a-a662-4fee-8dcb-7d7e822b71ba"
}12.1.4. Dockerfile 构建成功完成
以下是 Dockerfile 构建的示例响应,它由构建系统成功完成。
此事件会同时 发生,带有一个构建镜像的 Repository Push 事件。
{
"build_id": "296ec063-5f86-4706-a469-f0a400bf9df2",
"trigger_kind": "github", //Optional
"name": "test",
"repository": "dgangaia/test",
"namespace": "dgangaia",
"docker_url": "quay.io/dgangaia/test",
"trigger_id": "38b6e180-9521-4ff7-9844-acf371340b9e", //Optional
"docker_tags": [
"master",
"latest"
],
"build_name": "b7f7d2b",
"image_id": "sha256:0339f178f26ae24930e9ad32751d6839015109eabdf1c25b3b0f2abf8934f6cb",
"trigger_metadata": {
"commit": "b7f7d2b948aacbe844ee465122a85a9368b2b735",
"ref": "refs/heads/master",
"default_branch": "master",
"git_url": "git@github.com:dgangaia/test.git",
"commit_info": { //Optional
"url": "https://github.com/dgangaia/test/commit/b7f7d2b948aacbe844ee465122a85a9368b2b735",
"date": "2019-03-06T12:48:24+11:00",
"message": "adding 5",
"committer": { //Optional
"username": "web-flow",
"url": "https://github.com/web-flow", //Optional
"avatar_url": "https://avatars3.githubusercontent.com/u/19864447?v=4" //Optional
},
"author": { //Optional
"username": "dgangaia",
"url": "https://github.com/dgangaia", //Optional
"avatar_url": "https://avatars1.githubusercontent.com/u/43594254?v=4" //Optional
}
}
},
"homepage": "https://quay.io/repository/dgangaia/test/build/296ec063-5f86-4706-a469-f0a400bf9df2",
"manifest_digests": [
"quay.io/dgangaia/test@sha256:2a7af5265344cc3704d5d47c4604b1efcbd227a7a6a6ff73d6e4e08a27fd7d99",
"quay.io/dgangaia/test@sha256:569e7db1a867069835e8e97d50c96eccafde65f08ea3e0d5debaf16e2545d9d1"
]
}12.1.5. Dockerfile 构建失败
Dockerfile 构建失败
{
"build_id": "5346a21d-3434-4764-85be-5be1296f293c",
"trigger_kind": "github", //Optional
"name": "test",
"repository": "dgangaia/test",
"docker_url": "quay.io/dgangaia/test",
"error_message": "Could not find or parse Dockerfile: unknown instruction: GIT",
"namespace": "dgangaia",
"trigger_id": "38b6e180-9521-4ff7-9844-acf371340b9e", //Optional
"docker_tags": [
"master",
"latest"
],
"build_name": "6ae9a86",
"trigger_metadata": { //Optional
"commit": "6ae9a86930fc73dd07b02e4c5bf63ee60be180ad",
"ref": "refs/heads/master",
"default_branch": "master",
"git_url": "git@github.com:dgangaia/test.git",
"commit_info": { //Optional
"url": "https://github.com/dgangaia/test/commit/6ae9a86930fc73dd07b02e4c5bf63ee60be180ad",
"date": "2019-03-06T14:18:16+11:00",
"message": "failed build test",
"committer": { //Optional
"username": "web-flow",
"url": "https://github.com/web-flow", //Optional
"avatar_url": "https://avatars3.githubusercontent.com/u/19864447?v=4" //Optional
},
"author": { //Optional
"username": "dgangaia",
"url": "https://github.com/dgangaia", //Optional
"avatar_url": "https://avatars1.githubusercontent.com/u/43594254?v=4" //Optional
}
}
},
"homepage": "https://quay.io/repository/dgangaia/test/build/5346a21d-3434-4764-85be-5be1296f293c"
}12.1.6. Dockerfile 构建已取消
已取消 Dockerfile 构建
{
"build_id": "cbd534c5-f1c0-4816-b4e3-55446b851e70",
"trigger_kind": "github",
"name": "test",
"repository": "dgangaia/test",
"namespace": "dgangaia",
"docker_url": "quay.io/dgangaia/test",
"trigger_id": "38b6e180-9521-4ff7-9844-acf371340b9e",
"docker_tags": [
"master",
"latest"
],
"build_name": "cbce83c",
"trigger_metadata": {
"commit": "cbce83c04bfb59734fc42a83aab738704ba7ec41",
"ref": "refs/heads/master",
"default_branch": "master",
"git_url": "git@github.com:dgangaia/test.git",
"commit_info": {
"url": "https://github.com/dgangaia/test/commit/cbce83c04bfb59734fc42a83aab738704ba7ec41",
"date": "2019-03-06T14:27:53+11:00",
"message": "testing cancel build",
"committer": {
"username": "web-flow",
"url": "https://github.com/web-flow",
"avatar_url": "https://avatars3.githubusercontent.com/u/19864447?v=4"
},
"author": {
"username": "dgangaia",
"url": "https://github.com/dgangaia",
"avatar_url": "https://avatars1.githubusercontent.com/u/43594254?v=4"
}
}
},
"homepage": "https://quay.io/repository/dgangaia/test/build/cbd534c5-f1c0-4816-b4e3-55446b851e70"
}12.1.7. 安全漏洞已受影响
在存储库中检测到了一个漏洞
{
"repository": "dgangaia/repository",
"namespace": "dgangaia",
"name": "repository",
"docker_url": "quay.io/dgangaia/repository",
"homepage": "https://quay.io/repository/dgangaia/repository",
"tags": ["latest", "othertag"],
"vulnerability": {
"id": "CVE-1234-5678",
"description": "This is a bad vulnerability",
"link": "http://url/to/vuln/info",
"priority": "Critical",
"has_fix": true
}
}12.2. 通知操作
12.2.1. Quay 通知
通知将添加到 Quay.io 通知区域。通过单击任何 Quay.io 页面右上角的 bell 图标,可以找到通知区域。
Quay.io 通知可以设置为作为一个整体发送 User, Team, 或 organization。
12.2.2. e-mail
电子邮件将发送到描述所发生事件的指定地址。
所有电子邮件地址都必须 基于每个存储库 进行验证
12.2.3. Webhook POST
HTTP POST 调用将使用事件的数据对指定的 URL 发出(请参阅上述每个事件数据格式)。
当 URL 为 HTTPS 时,调用将从 Quay.io 设置 SSL 客户端证书。验证此证书验证将证明来自 Quay.io 的调用。在 2xx 范围内带有状态代码的响应被视为成功。带有任何其他状态代码的响应都将被视为失败,并导致重试 webhook 通知。
12.2.4. Flowdock 通知
向 Flowdock 发送一条消息。
12.2.5. HipChat 通知
将消息发布到 HipChat。
12.2.6. Slack 通知
向 Slack 发送一条消息。
第 13 章 开放容器项目支持和 Red Hat Quay
Red Hat Quay 等容器 registry 最初设计为支持 Docker 镜像格式的容器镜像。为提升使用 Docker 以外的其他运行时,创建了开放容器项目(OCI)来提供由容器运行时和镜像格式组成的技术。大多数容器 registry 支持 OCI 标准化,因为它基于 Docker 镜像清单 V2、Schema 2 格式。
除了容器镜像外,还出现各种工件,它们不仅支持单独的应用程序,还存在 Kubernetes 平台作为一个整体的支持。这些范围包括用于安全性和监管的 Open Policy Agent (OPA)策略到 Helm chart 和 Operator,以帮助应用程序部署。
Red Hat Quay 是一个私有容器 registry,它不仅存储容器镜像,但支持整个工具生态系统来协助容器管理。在版本 3.6 之前,Red Hat Quay 只支持 Helm,它被视为 Kubernetes 的事实 软件包管理器。
Helm 简化了应用程序的打包和部署方式。Helm 使用名为 Charts 的打包格式,其中包含代表应用程序的 Kubernetes 资源。可以对仓库中的常规发行和使用提供图表。Helm 仓库是一个 HTTP 服务器,它提供 index.yaml 元数据文件,也可以选择一组打包的 chart。从 Helm 版本 3 开始,支持在 OCI registry 中分发 chart 作为传统仓库的替代选择。
作为对 Helm 支持的增强,Red Hat Quay 引入了从版本 3.6 中对基于 OCI 的工件的支持,使其包含对 cosign、ZStandard 压缩方案和其他 OCI 介质类型的支持。现在,在 FEATURE_GENERAL_OCI_SUPPORT 配置字段中默认启用 Helm 和其他 OCI 工件的支持,并使用 ALLOWED_OCI_ARTIFACT_TYPES 和 IGNORE_UNKNOWN_MEDIATYPES 字段扩展到其他工件类型。
由于增加了 FEATURE_GENERAL_OCI_SUPPORT、ALLOWED_OCI_ARTIFACT_TYPES 和 IGNORE_UNKNOWN_MEDIATYPES,FEATURE_HELM_OCI_SUPPORT 配置字段已弃用。此配置字段不再被支持,并将在以后的 Red Hat Quay 版本中删除。
13.1. Helm 和 OCI 的先决条件
在启用 Helm 和其他开放容器项目(OCI)工件类型之前,您必须满足以下条件:
13.1.1. 安装 Helm
使用以下步骤安装 Helm 客户端。
流程
- 从 Helm 发行版本页面下载最新版本的 Helm。
输入以下命令解包 Helm 二进制文件:
$ tar -zxvf helm-v3.8.2-linux-amd64.tar.gz
将 Helm 二进制文件移到所需位置:
$ mv linux-amd64/helm /usr/local/bin/helm
有关安装 Helm 的更多信息,请参阅安装 Helm 文档。
13.1.2. 升级到 Helm 3.8
对 OCI registry chart 的支持要求 Helm 已升级到至少 3.8。如果您已经下载了 Helm,且需要升级到 Helm 3.8,请参阅 Helm 升级 文档。
13.1.3. 启用您的系统信任 Red Hat Quay 使用的 SSL/TLS 证书
通过 HTTPS 促进 Helm 客户端和 Red Hat Quay 之间的通信。从 Helm 3.5 开始,支持仅适用于通过 HTTPS 与可信证书通信的 registry。另外,操作系统必须信任 registry 公开的证书。您必须确保您的操作系统已配置为信任 Red Hat Quay 使用的证书。使用以下步骤使您的系统信任自定义证书。
流程
输入以下命令将
rootCA.pem文件复制到/etc/pki/ca-trust/source/anchors/文件夹:$ sudo cp rootCA.pem /etc/pki/ca-trust/source/anchors/
输入以下命令更新 CA 信任存储:
$ sudo update-ca-trust extract
13.1.4. 在 Red Hat Quay 中为 Helm 创建机构
建议您在下载 Helm 客户端后创建一个新机构,以便在 Red Hat Quay 中存储 Helm chart。使用以下步骤,使用 Red Hat Quay UI 创建新机构。
流程
- 登录到您的 Red Hat Quay 部署。
- 单击 Create New Organization。
- 输入机构的名称,如 helm。然后,单击 Create Organization。
13.2. 在 Red Hat Quay 中使用 Helm chart
使用以下示例,从 Red Hat 社区(CoP)存储库下载并推送 etherpad 图。
流程
作为 Red Hat Quay 管理员,通过在
config.yaml文件中将FEATURE_GENERAL_OCI_SUPPORT设置为true来启用对 Helm 的支持:FEATURE_GENERAL_OCI_SUPPORT: true
添加 chart 存储库:
$ helm repo add redhat-cop https://redhat-cop.github.io/helm-charts
从 chart 存储库本地更新可用 chart 的信息:
$ helm repo update
从存储库下载 chart:
$ helm pull redhat-cop/etherpad --version=0.0.4 --untar
将 chart 打包到一个 chart 归档中:
$ helm package ./etherpad
输出示例
Successfully packaged chart and saved it to: /home/user/linux-amd64/etherpad-0.0.4.tgz
使用
helm registry 登录登录到您的 Quay 存储库:$ helm registry login quay370.apps.quayperf370.perfscale.devcluster.openshift.com
使用
helm push命令将 chart 推送到 Quay 存储库:$ helm push etherpad-0.0.4.tgz oci://quay370.apps.quayperf370.perfscale.devcluster.openshift.com
输出示例:
Pushed: quay370.apps.quayperf370.perfscale.devcluster.openshift.com/etherpad:0.0.4 Digest: sha256:a6667ff2a0e2bd7aa4813db9ac854b5124ff1c458d170b70c2d2375325f2451b
通过删除本地副本来确保推送正常工作,然后从存储库拉取 chart:
$ rm -rf etherpad-0.0.4.tgz
$ helm pull oci://quay370.apps.quayperf370.perfscale.devcluster.openshift.com/etherpad --version 0.0.4
输出示例:
Pulled: quay370.apps.quayperf370.perfscale.devcluster.openshift.com/etherpad:0.0.4 Digest: sha256:4f627399685880daf30cf77b6026dc129034d68c7676c7e07020b70cf7130902
13.3. Red Hat Quay 支持 Cosign OCI
Cosign 是一个可用于签名和验证容器镜像的工具。它使用 ECDSA-P256 签名算法和红帽的简单签名有效负载格式来创建存储在 PKIX 文件中的公钥。私钥存储为加密的 PEM 文件。
Cosign 目前支持以下内容:
- 硬件和 KMS 签名
- 自带的 PKI
- OIDC PKI
- 内置二进制透明和时间戳服务
13.4. 为 Red Hat Quay 安装和使用 Cosign
使用以下步骤直接安装 Cosign。
前提条件
- 已安装 Go 版本 1.16 或更高版本。
-
您已在
config.yaml文件中将FEATURE_GENERAL_OCI_SUPPORT设置为true。
流程
输入以下
go命令直接安装 Cosign:$ go install github.com/sigstore/cosign/cmd/cosign@v1.0.0
输出示例
go: downloading github.com/sigstore/cosign v1.0.0 go: downloading github.com/peterbourgon/ff/v3 v3.1.0
输入以下命令为 Cosign 生成密钥对:
$ cosign generate-key-pair
输出示例
Enter password for private key: Enter again: Private key written to cosign.key Public key written to cosign.pub
输入以下命令为密钥对签名:
$ cosign sign -key cosign.key quay-server.example.com/user1/busybox:test
输出示例
Enter password for private key: Pushing signature to: quay-server.example.com/user1/busybox:sha256-ff13b8f6f289b92ec2913fa57c5dd0a874c3a7f8f149aabee50e3d01546473e3.sig
如果您遇到
错误: signing quay-server.example.com/user1/busybox:test: getting remote image: GET https://quay-server.example.com/v2/user1/busybox/manifests/test: UNAUTHORIZED: access to the requested resource is not authorized; map[]error,因为 Cosign 依赖于~./docker/config.json用于授权,您可能需要执行以下命令:$ podman login --authfile ~/.docker/config.json quay-server.example.com
输出示例
Username: Password: Login Succeeded!
输入以下命令查看更新的授权配置:
$ cat ~/.docker/config.json { "auths": { "quay-server.example.com": { "auth": "cXVheWFkbWluOnBhc3N3b3Jk" } }
13.5. 在 Red Hat Quay 中使用其他工件类型
默认不支持的其他工件类型可使用 ALLOWED_OCI_ARTIFACT_TYPES 配置字段添加到您的 Red Hat Quay 部署中。
使用以下采购来添加额外的 OCI 介质类型。
前提条件
-
您已在
config.yaml文件中将FEATURE_GENERAL_OCI_SUPPORT设置为true。
流程
在
config.yaml文件中,添加ALLOWED_OCI_ARTIFACT_TYPES配置字段。例如:FEATURE_GENERAL_OCI_SUPPORT: true ALLOWED_OCI_ARTIFACT_TYPES: <oci config type 1>: - <oci layer type 1> - <oci layer type 2> <oci config type 2>: - <oci layer type 3> - <oci layer type 4>
通过将以下内容添加到
config.yaml文件中,添加对所需工件类型的支持,例如 Singularity Image Format (SIF):ALLOWED_OCI_ARTIFACT_TYPES: application/vnd.oci.image.config.v1+json: - application/vnd.dev.cosign.simplesigning.v1+json application/vnd.cncf.helm.config.v1+json: - application/tar+gzip application/vnd.sylabs.sif.config.v1+json: - application/vnd.sylabs.sif.layer.v1+tar
重要当添加默认情况下不配置的工件类型时,Red Hat Quay 管理员还需要手动添加对 Cosign 和 Helm 的支持。
现在,用户可以为其 Red Hat Quay registry 标记 SIF 镜像。
13.6. 在 Red Hat Quay 中禁用 OCI 工件
使用以下步骤禁用对 OCI 工件的支持。
流程
通过在
config.yaml文件中将FEATURE_GENERAL_OCI_SUPPORT设置为false来禁用 OCI 工件支持。例如:FEATURE_GENERAL_OCI_SUPPORT = false
第 14 章 Red Hat Quay 配额管理和强制概述
使用 Red Hat Quay,用户可以通过建立配置的存储配额限制来报告存储消耗并包含 registry 增长。内部 Red Hat Quay 用户现在带有以下功能来管理其环境的容量限制:
- 配额报告: 有了此功能,超级用户可以跟踪其所有组织的存储消耗。另外,用户可以跟踪其分配的机构的存储消耗。
- 配额管理: 有了此功能,超级用户可以为 Red Hat Quay 用户定义软和硬检查。软检查告知用户是否有机构的存储消耗达到其配置的阈值。硬检查可防止用户在存储消耗达到配置的限制时推送到 registry。
这些功能一起允许 Red Hat Quay registry 的服务所有者定义服务级别协议并支持健康的资源预算。
14.1. 配额管理架构
启用配额管理功能后,单独的 blob 大小在存储库和命名空间级别总和。例如,如果同一存储库中的两个标签引用同一 blob,则该 Blob 的大小仅计算为仓库总计一次。另外,清单列表总数计算为存储库总计。
因为清单列表总数被计算为仓库总计,所以从以前的 Red Hat Quay 版本升级时消耗的总配额可能会在 Red Hat Quay 3.9 中被报告不同。在某些情况下,新总数可能会超过存储库的之前设置的限制。Red Hat Quay 管理员可能需要调整存储库所分配的配额,以考虑这些更改。
配额管理功能的工作原理是,使用回填 worker 计算现有存储库和命名空间的大小,然后从总镜像添加或减去,这些镜像被推送或垃圾收集到每个镜像。另外,在收集清单时,从总的减法中减去。
因为减法发生在清单垃圾回收时的总数,所以大小计算会有一个延迟,直到它能够收集垃圾回收为止。有关垃圾回收的更多信息,请参阅 Red Hat Quay 垃圾回收。
以下数据库表包含机构中 Red Hat Quay 仓库的配额存储库大小、配额命名空间大小和配额 registry 大小(以字节为单位):
-
QuotaRepositorySize -
QuotaNameSpaceSize -
QuotaRegistrySize
组织大小由回填 worker 计算,以确保不会重复。初始化镜像推送时,用户的机构存储会被验证,以检查它是否超过配置的配额限制。如果镜像推送超过定义的配额限制,则会出现软或硬检查:
- 对于软检查,会通知用户。
- 对于硬检查,会停止推送。
如果存储消耗在配置的配额限制中,则允许推送继续进行。
镜像标签删除遵循类似的流,其中删除关联的镜像标签和清单之间的链接。另外,在镜像清单被删除后,会在 QuotaRepositorySize、QuotaNameSpaceSize 和 QuotaRegistrySize 表中重新计算和更新存储库大小。
14.2. 配额管理限制
配额管理可帮助组织维护资源消耗。配额管理的一个限制是计算对推送结果的资源消耗,导致计算成为推送的关键路径的一部分。如果没有这种情况,使用数据可能会偏移。
最大存储配额大小取决于所选的数据库:
表 14.1. worker 计数环境变量
| 变量 | Description |
|---|---|
| Postgres | 8388608 TB |
| MySQL | 8388608 TB |
| SQL Server | 16777216 TB |
14.3. 配额管理配置字段
表 14.2. 配额管理配置
| 字段 | 类型 | 描述 |
|---|---|---|
| FEATURE_QUOTA_MANAGEMENT | 布尔值 | 为配额管理功能启用配置、缓存和验证。 **Default:** `False` |
| DEFAULT_SYSTEM_REJECT_QUOTA_BYTES | 字符串 | 为所有机构启用系统默认配额拒绝字节允许。 默认情况下,不会设置限制。 |
| QUOTA_BACKFILL | 布尔值 | 启用配额回填工作程序来计算预先存在的 Blob 的大小。
默认: |
| QUOTA_TOTAL_DELAY_SECONDS | 字符串 | 启动配额回填的时间延迟。滚动部署可能会导致总部署不正确。此字段 必须设置为 超过滚动部署完成所需的时间。
默认 :1 |
| PERMANENTLY_DELETE_TAGS | 布尔值 | 启用与从时间窗中删除标签相关的功能。
默认 : |
| RESET_CHILD_MANIFEST_EXPIRATION | 布尔值 |
重置以子清单为目标的临时标签的过期。将这个功能设置为
默认 : |
14.3.1. 配额管理配置示例
以下 YAML 是启用配额管理时推荐的配置。
配额管理 YAML 配置
FEATURE_QUOTA_MANAGEMENT: true FEATURE_GARBAGE_COLLECTION: true PERMANENTLY_DELETE_TAGS: true QUOTA_TOTAL_DELAY_SECONDS: 1800 RESET_CHILD_MANIFEST_EXPIRATION: true
14.4. 使用 Red Hat Quay API 建立配额
首次创建机构时,它不会应用配额。使用 /api/v1/organization/{organization}/quota 端点:
示例命令
$ curl -k -X GET -H "Authorization: Bearer <token>" -H 'Content-Type: application/json' https://example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org/api/v1/organization/testorg/quota | jq
输出示例
[]
14.4.1. 设置配额
要为机构设置配额,请将数据 POST 到 /api/v1/organization/{orgname}/quota endpoint: .Sample 命令
$ curl -k -X POST -H "Authorization: Bearer <token>" -H 'Content-Type: application/json' -d '{"limit_bytes": 10485760}' https://example-registry-quay-quay-enterprise.apps.docs.quayteam.org/api/v1/organization/testorg/quota | jq输出示例
"Created"
14.4.2. 查看配额
要查看应用的配额,GET 数据来自 /api/v1/organization/{orgname}/quota 端点:
示例命令
$ curl -k -X GET -H "Authorization: Bearer <token>" -H 'Content-Type: application/json' https://example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org/api/v1/organization/testorg/quota | jq
输出示例
[
{
"id": 1,
"limit_bytes": 10485760,
"default_config": false,
"limits": [],
"default_config_exists": false
}
]
14.4.3. 修改配额
要修改现有的配额(在这个实例中从 10 MB 改为 100 MB),使用到 /api/v1/organization/{orgname}/quota/{quota_id} 端点的 PUT 数据:
示例命令
$ curl -k -X PUT -H "Authorization: Bearer <token>" -H 'Content-Type: application/json' -d '{"limit_bytes": 104857600}' https://example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org/api/v1/organization/testorg/quota/1 | jq
输出示例
{
"id": 1,
"limit_bytes": 104857600,
"default_config": false,
"limits": [],
"default_config_exists": false
}
14.4.4. 推送镜像
要查看消耗的存储,请将各种镜像推送到机构。
14.4.4.1. Pushing ubuntu:18.04
从命令行将 ubuntu:18.04 推送到机构:
示例命令
$ podman pull ubuntu:18.04 $ podman tag docker.io/library/ubuntu:18.04 example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org/testorg/ubuntu:18.04 $ podman push --tls-verify=false example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org/testorg/ubuntu:18.04
14.4.4.2. 使用 API 查看配额使用情况
要查看消耗的存储,针对 /api/v1/repository 端点使用 GET 数据:
示例命令
$ curl -k -X GET -H "Authorization: Bearer <token>" -H 'Content-Type: application/json' 'https://example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org/api/v1/repository?last_modified=true&namespace=testorg&popularity=true&public=true"a=true' | jq
输出示例
{
"repositories": [
{
"namespace": "testorg",
"name": "ubuntu",
"description": null,
"is_public": false,
"kind": "image",
"state": "NORMAL",
"quota_report": {
"quota_bytes": 27959066,
"configured_quota": 104857600
},
"last_modified": 1651225630,
"popularity": 0,
"is_starred": false
}
]
}
14.4.4.3. 推送另一个镜像
拉取、标签和推送第二个镜像,如
nginx:示例命令
$ podman pull nginx $ podman tag docker.io/library/nginx example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org/testorg/nginx $ podman push --tls-verify=false example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org/testorg/nginx
要查看机构中存储库的配额报告,请使用 /api/v1/repository 端点:
示例命令
$ curl -k -X GET -H "Authorization: Bearer <token>" -H 'Content-Type: application/json' 'https://example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org/api/v1/repository?last_modified=true&namespace=testorg&popularity=true&public=true"a=true'
输出示例
{ "repositories": [ { "namespace": "testorg", "name": "ubuntu", "description": null, "is_public": false, "kind": "image", "state": "NORMAL", "quota_report": { "quota_bytes": 27959066, "configured_quota": 104857600 }, "last_modified": 1651225630, "popularity": 0, "is_starred": false }, { "namespace": "testorg", "name": "nginx", "description": null, "is_public": false, "kind": "image", "state": "NORMAL", "quota_report": { "quota_bytes": 59231659, "configured_quota": 104857600 }, "last_modified": 1651229507, "popularity": 0, "is_starred": false } ] }要查看机构详情中的配额信息,请使用 /api/v1/organization/{orgname} 端点:
示例命令
$ curl -k -X GET -H "Authorization: Bearer <token>" -H 'Content-Type: application/json' 'https://example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org/api/v1/organization/testorg' | jq
输出示例
{ "name": "testorg", ... "quotas": [ { "id": 1, "limit_bytes": 104857600, "limits": [] } ], "quota_report": { "quota_bytes": 87190725, "configured_quota": 104857600 } }
14.4.5. 使用配额限制拒绝推送
如果镜像推送超过定义的配额限制,则会出现软或硬检查:
- 对于软检查,或警告,用户会收到通知。
- 对于硬检查 或拒绝,推送将被终止。
14.4.5.1. 设置拒绝和警告限制
要设置 拒绝和警告 限制,请将数据 POST 到 /api/v1/organization/{orgname}/quota/{quota_id}/limit 端点:
reject limit 命令示例
$ curl -k -X POST -H "Authorization: Bearer <token>" -H 'Content-Type: application/json' -d '{"type":"Reject","threshold_percent":80}' https://example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org/api/v1/organization/testorg/quota/1/limit
警告限制命令示例
$ curl -k -X POST -H "Authorization: Bearer <token>" -H 'Content-Type: application/json' -d '{"type":"Warning","threshold_percent":50}' https://example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org/api/v1/organization/testorg/quota/1/limit
14.4.5.2. 查看拒绝和警告限制
要查看 拒绝和警告 限制,请使用 /api/v1/organization/{orgname}/quota 端点:
查看配额限制
$ curl -k -X GET -H "Authorization: Bearer <token>" -H 'Content-Type: application/json' https://example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org/api/v1/organization/testorg/quota | jq
配额限制的输出示例
[
{
"id": 1,
"limit_bytes": 104857600,
"default_config": false,
"limits": [
{
"id": 2,
"type": "Warning",
"limit_percent": 50
},
{
"id": 1,
"type": "Reject",
"limit_percent": 80
}
],
"default_config_exists": false
}
]
14.4.5.3. 超过拒绝限制时推送镜像
在本例中,拒绝限制(80%)已被设置为当前存储库大小(~83%),因此下一个推送会自动被拒绝。
从命令行将示例镜像推送到机构:
镜像拉取示例
$ podman pull ubuntu:20.04 $ podman tag docker.io/library/ubuntu:20.04 example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org/testorg/ubuntu:20.04 $ podman push --tls-verify=false example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org/testorg/ubuntu:20.04
超过配额时的输出示例
Getting image source signatures Copying blob d4dfaa212623 [--------------------------------------] 8.0b / 3.5KiB Copying blob cba97cc5811c [--------------------------------------] 8.0b / 15.0KiB Copying blob 0c78fac124da [--------------------------------------] 8.0b / 71.8MiB WARN[0002] failed, retrying in 1s ... (1/3). Error: Error writing blob: Error initiating layer upload to /v2/testorg/ubuntu/blobs/uploads/ in example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org: denied: Quota has been exceeded on namespace Getting image source signatures Copying blob d4dfaa212623 [--------------------------------------] 8.0b / 3.5KiB Copying blob cba97cc5811c [--------------------------------------] 8.0b / 15.0KiB Copying blob 0c78fac124da [--------------------------------------] 8.0b / 71.8MiB WARN[0005] failed, retrying in 1s ... (2/3). Error: Error writing blob: Error initiating layer upload to /v2/testorg/ubuntu/blobs/uploads/ in example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org: denied: Quota has been exceeded on namespace Getting image source signatures Copying blob d4dfaa212623 [--------------------------------------] 8.0b / 3.5KiB Copying blob cba97cc5811c [--------------------------------------] 8.0b / 15.0KiB Copying blob 0c78fac124da [--------------------------------------] 8.0b / 71.8MiB WARN[0009] failed, retrying in 1s ... (3/3). Error: Error writing blob: Error initiating layer upload to /v2/testorg/ubuntu/blobs/uploads/ in example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org: denied: Quota has been exceeded on namespace Getting image source signatures Copying blob d4dfaa212623 [--------------------------------------] 8.0b / 3.5KiB Copying blob cba97cc5811c [--------------------------------------] 8.0b / 15.0KiB Copying blob 0c78fac124da [--------------------------------------] 8.0b / 71.8MiB Error: Error writing blob: Error initiating layer upload to /v2/testorg/ubuntu/blobs/uploads/ in example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org: denied: Quota has been exceeded on namespace
14.4.5.4. 超过限制的通知
超过限制时,会出现通知:
配额通知
第 15 章 Red Hat Quay 作为上游 registry 的代理缓存
随着容器开发的复杂程度,客户往往依赖于来自上游 registry (如 Docker 或 Google Cloud Platform)的容器镜像来启动并运行服务。现在,registry 对用户可以从这些 registry 中拉取的次数具有速率限制和节流。
通过此功能,Red Hat Quay 将充当代理缓存,以绕过上游 registry 的 pull-rate 限制。添加缓存功能也会加快拉取性能,因为镜像是从缓存中拉取的,而不是上游依赖项。只有在上游镜像摘要与缓存的镜像不同时,才会更新缓存的镜像,从而减少速率限值和潜在的节流。
在 Red Hat Quay 缓存代理中,提供了以下功能:
- 特定的机构可以定义为上游 registry 的缓存。
配置作为特定上游 registry 的缓存的 Quay 组织。此存储库可以使用 Quay UI 来定义,并提供以下配置:
- 用于私有存储库或增加速率限制的上游 registry 凭证。
- 过期计时器以避免绕过缓存机构大小。
- 通过配置应用程序配置全局 on/off。
-
整个上游 registry 或单个命名空间缓存,例如,所有
docker.io或docker.io/library。 - 所有缓存拉取的日志记录。
- Clair 缓存的镜像可扫描。
15.1. 代理缓存架构
下图显示了代理缓存功能的预期设计流和架构。
当用户从 Red Hat Quay 上的上游存储库拉取镜像(如 postgres:14 )时,存储库会检查是否存在镜像。如果镜像不存在,则会启动新的拉取。拉取后,镜像层将保存到缓存和服务器并行用户。下图描述了此场景的架构概述:
如果缓存中的镜像存在,用户可以依赖 Quay 的缓存来与上游源保持最新状态,以便自动拉取缓存中的更新镜像。当在上游 registry 中覆盖了原始镜像的标签时会出现这种情况。下图描述了当上游镜像和镜像的缓存版本不同时会发生什么的架构概述:
如果上游镜像和缓存的版本相同,则不会拉取任何层,并将缓存的镜像传送到用户。
在某些情况下,用户在上游 registry 停机时启动拉取。如果使用配置的过时的周期发生这种情况,则会发送存储在缓存中的镜像。如果在配置的 staleness 到期后拉取发生,则错误会被传播到用户。以下镜像描述了在配置的过时周期后拉取时的架构概述:
Quay 管理员可以利用组织的可配置大小限制来限制缓存大小,以便后端存储消耗保持可预测的。这可以通过根据使用镜像的频率从缓存中丢弃镜像来实现。下图描述了此场景的架构概述:
15.2. 代理缓存限制
使用 Red Hat Quay 的代理缓存有以下限制:
- 您的代理缓存的大小限值必须大于或等于您要缓存的镜像。例如,如果您的代理缓存机构最大大小为 500 MB,并且用户想要拉取的镜像为 700 MB,则镜像将被缓存,并在配置的限制之外溢出。
- 缓存的镜像必须具有 Quay 存储库中的镜像必须具有相同的属性。
15.3. 使用 Red Hat Quay 代理远程 registry
以下流程描述了如何使用 Red Hat Quay 代理远程 registry。此流程被设置为代理 quay.io,用户可以使用 podman 从 quay.io 上的任何命名空间中拉取任何公共镜像。
前提条件
-
config.yaml 中的
FEATURE_PROXY_CACHE设置为true。 - 分配 Member 团队角色。有关团队角色的更多信息,请参阅 Red Hat Quay 中的用户和团队。
流程
-
在 UI 上的 Quay 机构中,如
cache-quayio,单击左侧窗格的 Organization Settings。 可选:点 Add Storage Quota 为您的机构配置配额管理。有关配额管理的更多信息,请参阅配额管理。
注意在某些情况下,当拉取过程中达到配额限制时,使用 Podman 拉取镜像可能会返回以下错误: Error resolve
image configuration: Error fetching blob: invalid status code from registry 403 (Forbidden)。错误403不准确,并且发生,因为 Podman 隐藏了正确的 API 错误:Quota has been exceeded on namespace。在以后的 Podman 更新中会解决这个问题。在 Remote Registry 中输入要缓存的远程 registry 的名称,如
quay.io,然后点 Save。注意通过在 Remote Registry 中添加命名空间,如
quay.io/<namespace>,您的机构中的用户只能从该命名空间中代理。可选:添加 远程 Registry 用户名和 远程 Registry 密码。
注意如果您没有设置 Remote Registry Username 和 Remote Registry Password,则无法在不删除代理缓存并创建新 registry 的情况下添加一个。
可选:在 Expiration 字段中设置一个时间。
注意- 代理机构中缓存的镜像的默认标签 Expiration 字段设置为 86400 秒。在代理机构中,每次拉取标签时,标签过期会被刷新为 UI 的 Expiration 字段中设置的值。此功能与 Quay 的默认 独立标签过期 功能不同。在代理机构中,可以覆盖单独的标签功能。当发生这种情况时,会根据代理机构的 Expiration 字段重置各个标签的过期时间。
- 已过期的镜像将在分配时间后消失,但仍存储在 Quay 中。镜像被完全删除或收集的时间取决于您的机构的 Time Machine 设置。除非另有指定,垃圾回收的默认时间为 14 天。
- 点击 Save。
在 CLI 上,从 registry 中拉取公共镜像,如 quay.io,充当代理缓存:
$ podman pull <registry_url>/<organization_name>/<quayio_namespace>/<image_name>
重要如果您的机构设置为从远程 registry 中的单个命名空间中拉取,则必须从 URL 中省略远程 registry 命名空间。例如,
podman pull <registry_url>/<organization_name>/<image_name>。
15.3.1. 在代理机构中利用存储配额限制
在 Red Hat Quay 3.8 中,代理缓存功能已被改进,并带有标记镜像的自动运行功能。只有代理命名空间配置了配额限制时,才会自动运行镜像标签。目前,如果镜像大小大于机构的配额,则会跳过镜像上传,直到管理员创建必要的空间。现在,当推送镜像超过分配的空间时,自动运行增强标记最近用于删除的标签。因此,新镜像标签会被存储,而最早使用的镜像标签标记为删除。
- 作为自动运行功能的一部分,标记为删除的标签最终由垃圾收集器(gc) worker 进程收集。因此,在此期间不会完全强制实施配额大小限制。
- 目前,命名空间配额大小计算不会考虑清单子的大小。这是一个已知问题,并将在以后的 Red Hat Quay 版本中解决。
15.3.1.1. 测试代理机构中的存储配额限制功能
使用以下步骤测试启用了代理缓存和存储配额限制的机构的自动修剪功能。
先决条件
- 您的机构配置为充当代理机构。以下示例来自 quay.io 的代理。
-
在
config.yaml文件中,FEATURE_PROXY_CACHE设置为true。 -
在
config.yaml文件中,FEATURE_QUOTA_MANAGEMENT设置为true。 -
您的机构配置了配额限制,例如
150 MB。
流程
从代理机构中拉取镜像到您的存储库,例如:
$ podman pull quay-server.example.com/proxytest/projectquay/quay:3.7.9
根据存储库中保留的空间,您可能需要从代理机构中拉取其他镜像,例如:
$ podman pull quay-server.example.com/proxytest/projectquay/quay:3.6.2
在 Red Hat Quay registry UI 中,点存储库的名称。
-
点导航窗格中的标签,并确保
quay:3.7.9和quay:3.6.2已标记。
-
点导航窗格中的标签,并确保
拉取将导致存储库超过分配的配额的最后镜像,例如:
$ podman pull quay-server.example.com/proxytest/projectquay/quay:3.5.1
-
刷新 Red Hat Quay registry 的 Tags 页面。您推送的第一个镜像,例如
quay:3.7.9应该已被自动修剪。Tags 页面现在应该显示quay:3.6.2和quay:3.5.1。
第 16 章 Red Hat Quay 构建增强
Red Hat Quay 构建可以在虚拟平台上运行。也可以使用向后兼容来运行以前的构建配置。
16.1. Red Hat Quay 增强的构建架构
下图显示了增强功能的预期设计流和架构:
在这个版本中,构建管理器首先会创建作业对象。然后,作业对象 使用 quay-builder-image 创建容器集。quay-builder-image 将包含 quay-builder 二进制文件 和 Podman 服务。创建的 pod 作为非特权 运行。然后,quay-builder 二进制文件 在通信状态和从构建管理器检索构建信息的同时构建镜像。
16.2. Red Hat Quay 构建限制
在非特权上下文中在 Red Hat Quay 中运行构建可能会导致一些在以前的构建策略下工作的命令失败。尝试更改构建策略可能会导致构建出现性能问题和可靠性。
直接在容器中运行构建与使用虚拟机的隔离没有相同的隔离。更改构建环境也可能会导致之前工作的构建失败。
16.3. 使用 OpenShift Container Platform 创建 Red Hat Quay 构建器环境
本节中的步骤解释了如何使用 OpenShift Container Platform 创建 Red Hat Quay 虚拟构建器环境。
16.3.1. OpenShift Container Platform TLS 组件
tls 组件允许您控制 TLS 配置。
当 TLS 组件由 Operator 管理时,Red Hat Quay 3.9 不支持构建器。
如果将 tls 设置为 unmanaged,则提供自己的 ssl.cert 和 ssl.key 文件。在本实例中,如果希望集群支持构建器,您必须将 Quay 路由和构建器路由名称添加到证书中的 SAN 列表中,或使用通配符。
要添加构建器路由,请使用以下格式:
[quayregistry-cr-name]-quay-builder-[ocp-namespace].[ocp-domain-name]:443
16.3.2. 将 OpenShift Container Platform 用于 Red Hat Quay 构建器
构建器需要 SSL/TLS 证书。有关 SSL/TLS 证书的更多信息,请参阅 向 Red Hat Quay 容器添加 TLS 证书。
如果使用 Amazon Web Service (AWS) S3 存储,您必须在运行构建器前修改 AWS 控制台中的存储桶。如需所需参数,请参阅以下部分的"修改 AWS S3 存储桶"。
16.3.2.1. 为虚拟构建器准备 OpenShift Container Platform
使用以下步骤为 Red Hat Quay 虚拟构建器准备 OpenShift Container Platform。
- 此流程假设您已置备集群并运行 Quay Operator。
- 此流程是在 OpenShift Container Platform 上设置虚拟命名空间。
流程
- 使用集群管理员帐户登录到您的 Red Hat Quay 集群。
运行以下命令,创建一个新项目,其中将运行您的虚拟构建器(如
virtual-builders):$ oc new-project virtual-builders
输入以下命令,在将用于运行构建的项目中创建一个
ServiceAccount:$ oc create sa -n virtual-builders quay-builder
为创建的服务帐户提供编辑权限,以便它可以运行构建:
$ oc adm policy -n virtual-builders add-role-to-user edit system:serviceaccount:virtual-builders:quay-builder
输入以下命令授予 Quay builder
anyuid scc权限:$ oc adm policy -n virtual-builders add-scc-to-user anyuid -z quay-builder
注意此操作需要集群管理员特权。这是必要的,因为构建器必须以 Podman 用户身份运行,才能使非特权或无根构建正常工作。
获取 Quay builder 服务帐户的令牌。
如果使用 OpenShift Container Platform 4.10 或更早的版本,请输入以下命令:
oc sa get-token -n virtual-builders quay-builder
如果使用 OpenShift Container Platform 4.11 或更高版本,请输入以下命令:
$ oc create token quay-builder -n virtual-builders
输出示例
eyJhbGciOiJSUzI1NiIsImtpZCI6IldfQUJkaDVmb3ltTHZ0dGZMYjhIWnYxZTQzN2dJVEJxcDJscldSdEUtYWsifQ...
输入以下命令确定构建器路由:
$ oc get route -n quay-enterprise
输出示例
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD ... example-registry-quay-builder example-registry-quay-builder-quay-enterprise.apps.docs.quayteam.org example-registry-quay-app grpc edge/Redirect None ...
输入以下命令使用 .crt 扩展生成自签名 SSL/TlS 证书:
$ oc extract cm/kube-root-ca.crt -n openshift-apiserver
输出示例
ca.crt
输入以下命令将
ca.crt文件重命名为extra_ca_cert_build_cluster.crt:$ mv ca.crt extra_ca_cert_build_cluster.crt
在控制台中找到配置捆绑包的 secret,然后选择 Actions → Edit Secret 并添加适当的构建程序配置:
FEATURE_USER_INITIALIZE: true BROWSER_API_CALLS_XHR_ONLY: false SUPER_USERS: - <superusername> FEATURE_USER_CREATION: false FEATURE_QUOTA_MANAGEMENT: true FEATURE_BUILD_SUPPORT: True BUILDMAN_HOSTNAME: <sample_build_route> 1 BUILD_MANAGER: - ephemeral - ALLOWED_WORKER_COUNT: 1 ORCHESTRATOR_PREFIX: buildman/production/ JOB_REGISTRATION_TIMEOUT: 3600 2 ORCHESTRATOR: REDIS_HOST: <sample_redis_hostname> 3 REDIS_PASSWORD: "" REDIS_SSL: false REDIS_SKIP_KEYSPACE_EVENT_SETUP: false EXECUTORS: - EXECUTOR: kubernetesPodman NAME: openshift BUILDER_NAMESPACE: <sample_builder_namespace> 4 SETUP_TIME: 180 MINIMUM_RETRY_THRESHOLD: 0 BUILDER_CONTAINER_IMAGE: <sample_builder_container_image> 5 # Kubernetes resource options K8S_API_SERVER: <sample_k8s_api_server> 6 K8S_API_TLS_CA: <sample_crt_file> 7 VOLUME_SIZE: 8G KUBERNETES_DISTRIBUTION: openshift CONTAINER_MEMORY_LIMITS: 300m 8 CONTAINER_CPU_LIMITS: 1G 9 CONTAINER_MEMORY_REQUEST: 300m 10 CONTAINER_CPU_REQUEST: 1G 11 NODE_SELECTOR_LABEL_KEY: "" NODE_SELECTOR_LABEL_VALUE: "" SERVICE_ACCOUNT_NAME: <sample_service_account_name> SERVICE_ACCOUNT_TOKEN: <sample_account_token> 12
- 1
- 构建路由是通过使用 OpenShift Operator 命名空间的名称运行
oc get route -n获取的。在路由末尾必须提供一个端口,它应使用以下格式:[quayregistry-cr-name]-quay-builder-[ocp-namespace].[ocp-domain-name]:443。 - 2
- 如果 设置了 job
_REGISTRATION_TIMEOUT参数过低,您可能会收到以下错误:failed to register job to build manager: rpc error: code = Unauthenticated desc = Invalid build token: Signature has expired。建议将此参数设置为至少 240。 - 3
- 如果您的 Redis 主机有密码或 SSL/TLS 证书,您必须相应地更新。
- 4
- 设置为与虚拟构建器命名空间的名称匹配,如
virtual-builders。 - 5
- 对于早期访问,
BUILDER_CONTAINER_IMAGE目前为quay.io/projectquay/quay-builder:3.7.0-rc.2。请注意,这可能会在早期访问窗口内有所变化。如果发生这种情况,则会提醒客户。 - 6
K8S_API_SERVER通过运行oc cluster-info获取。- 7
- 您必须手动创建并添加自定义 CA 证书,如
K8S_API_TLS_CA: /conf/stack/extra_ca_certs/build_cluster.crt。 - 8
- 如果未指定,则默认为
5120Mi。 - 9
- 对于虚拟构建,您必须确保集群中有足够的资源。如果未指定,则默认为
1000m。 - 10
- 如果未指定,则默认为
3968Mi。 - 11
- 如果未指定,则默认为
500m。 - 12
- 运行
oc create sa时获取。
配置示例
FEATURE_USER_INITIALIZE: true BROWSER_API_CALLS_XHR_ONLY: false SUPER_USERS: - quayadmin FEATURE_USER_CREATION: false FEATURE_QUOTA_MANAGEMENT: true FEATURE_BUILD_SUPPORT: True BUILDMAN_HOSTNAME: example-registry-quay-builder-quay-enterprise.apps.docs.quayteam.org:443 BUILD_MANAGER: - ephemeral - ALLOWED_WORKER_COUNT: 1 ORCHESTRATOR_PREFIX: buildman/production/ JOB_REGISTRATION_TIMEOUT: 3600 ORCHESTRATOR: REDIS_HOST: example-registry-quay-redis REDIS_PASSWORD: "" REDIS_SSL: false REDIS_SKIP_KEYSPACE_EVENT_SETUP: false EXECUTORS: - EXECUTOR: kubernetesPodman NAME: openshift BUILDER_NAMESPACE: virtual-builders SETUP_TIME: 180 MINIMUM_RETRY_THRESHOLD: 0 BUILDER_CONTAINER_IMAGE: quay.io/projectquay/quay-builder:3.7.0-rc.2 # Kubernetes resource options K8S_API_SERVER: api.docs.quayteam.org:6443 K8S_API_TLS_CA: /conf/stack/extra_ca_certs/build_cluster.crt VOLUME_SIZE: 8G KUBERNETES_DISTRIBUTION: openshift CONTAINER_MEMORY_LIMITS: 1G CONTAINER_CPU_LIMITS: 1080m CONTAINER_MEMORY_REQUEST: 1G CONTAINER_CPU_REQUEST: 580m NODE_SELECTOR_LABEL_KEY: "" NODE_SELECTOR_LABEL_VALUE: "" SERVICE_ACCOUNT_NAME: quay-builder SERVICE_ACCOUNT_TOKEN: "eyJhbGciOiJSUzI1NiIsImtpZCI6IldfQUJkaDVmb3ltTHZ0dGZMYjhIWnYxZTQzN2dJVEJxcDJscldSdEUtYWsifQ"
16.3.2.2. 手动添加 SSL/TLS 证书
由于配置工具的已知问题,您必须手动添加自定义 SSL/TLS 证书来正确运行构建器。使用以下步骤手动添加自定义 SSL/TLS 证书。
有关创建 SSL/TLS 证书的更多信息,请参阅在 Red Hat Quay 容器中添加 TLS 证书。
16.3.2.2.1. 创建和签名的证书
使用以下步骤创建和签署 SSL/TLS 证书。
流程
创建证书颁发机构并签署证书。如需更多信息,请参阅创建证书颁发机构和签署证书。
openssl.cnf
[req] req_extensions = v3_req distinguished_name = req_distinguished_name [req_distinguished_name] [ v3_req ] basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment subjectAltName = @alt_names [alt_names] DNS.1 = example-registry-quay-quay-enterprise.apps.docs.quayteam.org 1 DNS.2 = example-registry-quay-builder-quay-enterprise.apps.docs.quayteam.org 2
示例命令
$ openssl genrsa -out rootCA.key 2048 $ openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.pem $ openssl genrsa -out ssl.key 2048 $ openssl req -new -key ssl.key -out ssl.csr $ openssl x509 -req -in ssl.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out ssl.cert -days 356 -extensions v3_req -extfile openssl.cnf
16.3.2.2.2. 将 TLS 设置为非受管
使用以下步骤将 king:tls 设置为 unmanaged。
流程
在 Red Hat Quay Registry YAML 中,将
kind: tls设置为managed: false:- kind: tls managed: false在 Events 页面中,更改会被阻断,直到您设置适当的
config.yaml文件。例如:- lastTransitionTime: '2022-03-28T12:56:49Z' lastUpdateTime: '2022-03-28T12:56:49Z' message: >- required component `tls` marked as unmanaged, but `configBundleSecret` is missing necessary fields reason: ConfigInvalid status: 'True'
16.3.2.2.3. 创建临时 secret
使用以下步骤为 CA 证书创建临时 secret。
流程
在默认命名空间中为 CA 证书创建一个 secret:
$ oc create secret generic -n quay-enterprise temp-crt --from-file extra_ca_cert_build_cluster.crt
在 default 命名空间中为
ssl.key和ssl.cert文件创建一个 secret:$ oc create secret generic -n quay-enterprise quay-config-ssl --from-file ssl.cert --from-file ssl.key
16.3.2.2.4. 将 secret 数据复制到配置 YAML 中
使用以下步骤将 secret 数据复制到 config.yaml 文件中。
流程
- 在控制台 UI 中找到位于 Workloads → Secrets 的新 secret。
对于每个 secret,找到 YAML 视图:
kind: Secret apiVersion: v1 metadata: name: temp-crt namespace: quay-enterprise uid: a4818adb-8e21-443a-a8db-f334ace9f6d0 resourceVersion: '9087855' creationTimestamp: '2022-03-28T13:05:30Z' ... data: extra_ca_cert_build_cluster.crt: >- LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURNakNDQWhxZ0F3SUJBZ0l.... type: Opaquekind: Secret apiVersion: v1 metadata: name: quay-config-ssl namespace: quay-enterprise uid: 4f5ae352-17d8-4e2d-89a2-143a3280783c resourceVersion: '9090567' creationTimestamp: '2022-03-28T13:10:34Z' ... data: ssl.cert: >- LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUVaakNDQTA2Z0F3SUJBZ0lVT... ssl.key: >- LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFcFFJQkFBS0NBUUVBc... type: Opaque在 UI 中找到 Red Hat Quay registry 配置捆绑包的 secret,或运行以下命令从命令行:
$ oc get quayregistries.quay.redhat.com -o jsonpath="{.items[0].spec.configBundleSecret}{'\n'}" -n quay-enterprise在 OpenShift Container Platform 控制台中,选择配置捆绑包 secret 的 YAML 选项卡,并从您创建的两个 secret 中添加数据:
kind: Secret apiVersion: v1 metadata: name: init-config-bundle-secret namespace: quay-enterprise uid: 4724aca5-bff0-406a-9162-ccb1972a27c1 resourceVersion: '4383160' creationTimestamp: '2022-03-22T12:35:59Z' ... data: config.yaml: >- RkVBVFVSRV9VU0VSX0lOSVRJQUxJWkU6IHRydWUKQlJ... extra_ca_cert_build_cluster.crt: >- LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURNakNDQWhxZ0F3SUJBZ0ldw.... ssl.cert: >- LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUVaakNDQTA2Z0F3SUJBZ0lVT... ssl.key: >- LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFcFFJQkFBS0NBUUVBc... type: Opaque- 点击 Save。
输入以下命令查看 pod 是否重启:
$ oc get pods -n quay-enterprise
输出示例
NAME READY STATUS RESTARTS AGE ... example-registry-quay-app-6786987b99-vgg2v 0/1 ContainerCreating 0 2s example-registry-quay-app-7975d4889f-q7tvl 1/1 Running 0 5d21h example-registry-quay-app-7975d4889f-zn8bb 1/1 Running 0 5d21h example-registry-quay-app-upgrade-lswsn 0/1 Completed 0 6d1h example-registry-quay-config-editor-77847fc4f5-nsbbv 0/1 ContainerCreating 0 2s example-registry-quay-config-editor-c6c4d9ccd-2mwg2 1/1 Running 0 5d21h example-registry-quay-database-66969cd859-n2ssm 1/1 Running 0 6d1h example-registry-quay-mirror-764d7b68d9-jmlkk 1/1 Terminating 0 5d21h example-registry-quay-mirror-764d7b68d9-jqzwg 1/1 Terminating 0 5d21h example-registry-quay-redis-7cc5f6c977-956g8 1/1 Running 0 5d21h
重新配置 Red Hat Quay registry 后,输入以下命令检查 Red Hat Quay app pod 是否在运行:
$ oc get pods -n quay-enterprise
输出示例
example-registry-quay-app-6786987b99-sz6kb 1/1 Running 0 7m45s example-registry-quay-app-6786987b99-vgg2v 1/1 Running 0 9m1s example-registry-quay-app-upgrade-lswsn 0/1 Completed 0 6d1h example-registry-quay-config-editor-77847fc4f5-nsbbv 1/1 Running 0 9m1s example-registry-quay-database-66969cd859-n2ssm 1/1 Running 0 6d1h example-registry-quay-mirror-758fc68ff7-5wxlp 1/1 Running 0 8m29s example-registry-quay-mirror-758fc68ff7-lbl82 1/1 Running 0 8m29s example-registry-quay-redis-7cc5f6c977-956g8 1/1 Running 0 5d21h
在浏览器中,访问 registry 端点并验证证书是否已正确更新。例如:
Common Name (CN) example-registry-quay-quay-enterprise.apps.docs.quayteam.org Organisation (O) DOCS Organisational Unit (OU) QUAY
16.3.2.3. 使用 UI 创建构建触发器
使用以下步骤使用 UI 创建构建触发器。
流程
- 登录您的 Red Hat Quay 存储库。
-
单击 Create New Repository 并创建新 registry,如
testrepo。 在 Repositories 页面中,点导航窗格中的 Builds 选项卡。或者,直接使用对应的 URL:
https://example-registry-quay-quay-enterprise.apps.docs.quayteam.org/repository/quayadmin/testrepo?tab=builds
重要在某些情况下,构建器可能会遇到解析主机名的问题。此问题可能与作业对象上的
dnsPolicy设置为default相关。目前,这个问题还没有临时解决方案。它将在以后的 Red Hat Quay 版本中解决。- 点 Create Build Trigger → Custom Git Repository Push。
输入用于克隆 Git 存储库的 HTTPS 或 SSH 风格 URL,然后单击 Continue。例如:
https://github.com/gabriel-rh/actions_test.git
- 使用分支或标签名称检查 Tag 清单,然后单击 Continue。
-
在调用触发器时输入要构建的 Dockerfile 位置,例如
/Dockerfile并点 Continue。 -
输入 Docker 构建的上下文位置,如
/,然后单击 Continue。 - 如果保证,请创建一个受限帐户。否则,点 Continue。
- 点 Continue 验证参数。
- 在 Builds 页面中,点 Trigger Name 的 Options 图标,然后点 Run Trigger Now。
- 从 Git 存储库输入提交 SHA,然后单击 Start Build。
您可以通过单击 Build History 页面中的提交或运行
oc get pods -n virtual-builders来检查构建的状态。例如:$ oc get pods -n virtual-builders
输出示例
NAME READY STATUS RESTARTS AGE f192fe4a-c802-4275-bcce-d2031e635126-9l2b5-25lg2 1/1 Running 0 7s
$ oc get pods -n virtual-builders
输出示例
NAME READY STATUS RESTARTS AGE f192fe4a-c802-4275-bcce-d2031e635126-9l2b5-25lg2 1/1 Terminating 0 9s
$ oc get pods -n virtual-builders
输出示例
No resources found in virtual-builders namespace.
构建完成后,您可以在导航窗格中的 Tags 下检查标签的状态。
注意使用早期访问权限时,构建的完整构建日志和时间戳当前不可用。
16.3.2.4. 修改 AWS S3 存储桶
如果使用 AWS S3 存储,则必须在运行构建器前在 AWS 控制台中更改存储桶。
流程
- 登录到位于 s3.console.aws.com 的 AWS 控制台。
-
在搜索栏中,搜索
S3,然后单击 S3。 -
点存储桶的名称,如
myawsbucket。 - 单击权限选项卡。
在跨原始资源共享(CORS) 下,包括以下参数:
[ { "AllowedHeaders": [ "Authorization" ], "AllowedMethods": [ "GET" ], "AllowedOrigins": [ "*" ], "ExposeHeaders": [], "MaxAgeSeconds": 3000 }, { "AllowedHeaders": [ "Content-Type", "x-amz-acl", "origin" ], "AllowedMethods": [ "PUT" ], "AllowedOrigins": [ "*" ], "ExposeHeaders": [], "MaxAgeSeconds": 3000 } ]
16.3.2.5. 修改 Google Cloud Platform 对象存储桶
使用以下步骤为虚拟构建器配置跨原始资源共享(CORS)。
如果没有 CORS 配置,上传构建 Dockerfile 会失败。
流程
使用以下引用来创建 JSON 文件,以满足您的特定 CORS 需求。例如:
$ cat gcp_cors.json
输出示例
[ { "origin": ["*"], "method": ["GET"], "responseHeader": ["Authorization"], "maxAgeSeconds": 3600 }, { "origin": ["*"], "method": ["PUT"], "responseHeader": [ "Content-Type", "x-goog-acl", "origin"], "maxAgeSeconds": 3600 } ]输入以下命令更新 GCP 存储桶:
$ gcloud storage buckets update gs://<bucket_name> --cors-file=./gcp_cors.json
输出示例
Updating Completed 1
您可以运行以下命令来显示 GCP 存储桶的更新 CORS 配置:
$ gcloud storage buckets describe gs://<bucket_name> --format="default(cors)"
输出示例
cors: - maxAgeSeconds: 3600 method: - GET origin: - '*' responseHeader: - Authorization - maxAgeSeconds: 3600 method: - PUT origin: - '*' responseHeader: - Content-Type - x-goog-acl - origin
第 17 章 使用 Red Hat Quay v2 UI
使用以下步骤配置和使用 Red Hat Quay v2 UI。
17.1. v2 用户界面配置
启用 FEATURE_UI_V2 后,您可以在用户界面和用户界面的新版本间切换。
- 这个 UI 目前处于 beta 阶段,可能会有变化。在当前状态下,用户只能创建、查看和删除组织、存储库和镜像标签。
- 在旧 UI 中运行 Red Hat Quay 时,超时会话要求用户在弹出窗口中再次输入密码。使用新的 UI 时,用户返回到主页面,需要输入其用户名和密码凭证。这是一个已知问题,并将在以后的 UI 版本中解决。
- 在旧 UI 和新 UI 之间如何报告镜像清单大小有一个差异。在传统的 UI 中,以兆字节为单位报告镜像清单。在新的 UI 中,Red Hat Quay 使用 MB (MB)的标准定义来报告镜像清单大小。
流程
在部署的
config.yaml文件中,添加FEATURE_UI_V2参数并将其设置为true,例如:--- FEATURE_TEAM_SYNCING: false FEATURE_UI_V2: true FEATURE_USER_CREATION: true ---
- 登录到您的 Red Hat Quay 部署。
在 Red Hat Quay 部署的导航窗格中,会给一个可以在 Current UI 和 New UI 之间切换的选项。点切换按钮将其设置为新的 UI,然后点 Use Beta Environment,例如:
17.1.1. 在 Red Hat Quay v2 UI 中创建新机构
先决条件
- 您已切换了 Red Hat Quay 部署以使用 v2 UI。
使用以下步骤使用 Red Hat Quay v2 UI 创建机构。
流程
- 在导航窗格中点 Organization。
- 点 Create Organization。
-
输入 机构名称,如
testorg。 - 点 Create。
现在,您的示例机构应该在 Organizations 页面下填充。
17.1.2. 使用 Red Hat Quay v2 UI 删除机构
使用以下步骤通过 Red Hat Quay v2 UI 删除机构。
流程
-
在 Organizations 页面上,选择您要删除的机构的名称,例如
testorg。 - 点 More Actions 下拉菜单。
点 Delete。
注意在 Delete 页面中,有一个 搜索 输入框。有了此框,用户可以搜索特定的组织,以确保它们被正确地安排删除。例如,如果用户删除 10 个机构,并希望确保删除了特定的机构,他们可以使用 搜索 输入框确认上述机构标记为要删除的。
- 通过在框中输入 confirm 来确认您要永久删除机构。
点 Delete。
删除后,您将返回到 Organizations 页面。
注意您可以通过选择多个机构,然后点 More Actions → Delete 来删除多个机构。
17.1.3. 使用 Red Hat Quay v2 UI 创建新存储库
使用以下步骤使用 Red Hat Quay v2 UI 创建存储库。
流程
- 单击导航窗格中的 Repositories。
- 单击 Create Repository。
-
选择一个命名空间,如 quayadmin,然后输入 Repository 名称,如
testrepo。 点 Create。
现在,您的示例存储库应该在 Repositories 页面下填充。
17.1.4. 使用 Red Hat Quay v2 UI 删除存储库
先决条件
- 您已创建了存储库。
流程
-
在 Red Hat Quay v2 UI 的 Repositories 页面中,单击您要删除的镜像的名称,如
quay/admin/busybox。 - 点 More Actions 下拉菜单。
点 Delete。
注意如果需要,您可以点击 Make Public 或 Make Private。
- 在框中键入 confirm,然后单击 Delete。
- 删除后,您将返回到 Repositories 页面。
17.1.5. 将镜像推送到 Red Hat Quay v2 UI
使用以下步骤将镜像推送到 Red Hat Quay v2 UI。
流程
从外部 registry 拉取示例镜像:
$ podman pull busybox
标记镜像:
$ podman tag docker.io/library/busybox quay-server.example.com/quayadmin/busybox:test
将镜像推送到 Red Hat Quay registry:
$ podman push quay-server.example.com/quayadmin/busybox:test
- 导航到 Red Hat Quay UI 上的 Repositories 页面,并确保您的镜像已正确推送。
- 您可以通过选择镜像标签来查看安全详情,然后进入 Security Report 页面。
17.1.6. 使用 Red Hat Quay v2 UI 删除镜像
使用以下步骤通过 Red Hat Quay v2 UI 删除镜像。
先决条件
- 您已将镜像推送到 Red Hat Quay registry。
流程
-
在 Red Hat Quay v2 UI 的 Repositories 页面中,单击您要删除的镜像的名称,如
quay/admin/busybox。 - 点 More Actions 下拉菜单。
点 Delete。
注意如果需要,您可以点击 Make Public 或 Make Private。
- 在框中键入 confirm,然后单击 Delete。
- 删除后,您将返回到 Repositories 页面。
17.1.7. 使用 Red Hat Quay v2 UI 创建机器人帐户
使用以下步骤,使用 Red Hat Quay v2 UI 创建机器人帐户。
流程
- 在 Red Hat Quay v2 UI 上,单击 Organizations。
-
单击您要为其创建机器人帐户的组织名称,如
test-org。 - 点 Robot accounts 选项卡 → Create robot account。
-
在 Provide a name for your robot account 框中,输入名称,如
robot1。 可选。如果需要,可以使用以下选项:
- 将机器人添加到团队。
- 将机器人添加到存储库。
- 调整机器人的权限。
- 在 Review and finish 页面中,查看您提供的信息,然后点 Review and finish。
- 可选。您可以单击 Expand 或 Collapse 以显示有关机器人帐户的描述性信息。
- 可选。您可以点 kebab 菜单 → Set repository 权限来更改机器人帐户的权限。
- 可选。要删除您的机器人帐户,请选中机器人帐户的复选框,然后单击回收站图标。此时会出现弹出窗口。在文本框中键入 confirm,然后单击 Delete。或者,您可以点 kebab 菜单 → Delete。
17.1.8. Red Hat Quay v2 UI 的机构设置
使用以下步骤通过 Red Hat Quay v2 UI 更改您的机构设置。
流程
- 在 Red Hat Quay v2 UI 上,单击 Organizations。
-
单击您要为其创建机器人帐户的组织名称,如
test-org。 - 点 Settings 选项卡。
- 可选。输入与机构关联的电子邮件地址。
可选。将 Time Machine 功能的分配时间设置为以下之一:
- 1 周
- 1 个月
- 1 年
- Never
- 点击 Save。
17.1.9. 使用 Red Hat Quay v2 UI 查看镜像标签信息
使用以下步骤通过 Red Hat Quay v2 UI 查看镜像标签信息。
流程
- 在 Red Hat Quay v2 UI 上,单击 Repositories。
-
点存储库的名称,例如
quayadmin/busybox。 单击标签的名称,例如
test。您会进入标签的 Details 页面。该页面显示以下信息:- Name
- 软件仓库
- 摘要
- 安全漏洞
- 创建
- modified
- Size
- 标签
- 如何获取镜像标签
- 可选。点 Security Report 查看标签的漏洞。您可以扩展公告列以打开 CVE 数据。
- 可选。点 Packages 查看标签的软件包。
-
单击存储库的名称,如
busybox,以返回到 Tags 页面。 - 可选。将鼠标悬停在 Pull 图标上,以显示获取标签的方法。
- 选中标签框或多个标签,单击 Actions 下拉菜单,然后单击 Delete 以删除该标签。在弹出框中单击 Delete 来确认删除。
17.1.10. 使用 Red Hat Quay v2 UI 调整存储库设置
使用以下步骤使用 Red Hat Quay v2 UI 调整存储库的各种设置。
流程
- 在 Red Hat Quay v2 UI 上,单击 Repositories。
-
点存储库的名称,例如
quayadmin/busybox。 - 点 Settings 选项卡。
- 可选。单击 User and robot permissions。您可以通过单击 权限 下的下拉菜单选项来调整用户或机器人帐户的设置。您可以将设置更改为 Read、Write 或 Admin。
可选。单击 Events 和 notification。您可以通过单击 Create Notification 来创建事件和通知。可用的事件选项如下:
- 推送到存储库
- 发现软件包漏洞
- 镜像构建失败
- 镜像构建已排队
- 镜像构建已启动
- 镜像构建成功
镜像构建已取消
然后,发出通知。可用的选项如下:
- 电子邮件通知
- Flowdock 团队通知
- HipChat Room 通知
- Slack 通知
Webhook POST
选择事件选项和通知方法后,包括一个 Room ID #, a Room Notification Token,然后点 Submit。
- 可选。单击 Repository visibility。您可以通过单击 Make Public 使存储库为私有或公共存储库。
- 可选。单击 Delete repository。您可以通过单击 Delete Repository 来删除存储库。
17.2. 启用 Red Hat Quay 旧 UI
在 Red Hat Quay 部署的导航窗格中,会给一个可以在 Current UI 和 New UI 之间切换的选项。点击切换按钮,来将它设为 Current UI。
第 18 章 使用 Red Hat Quay API
Red Hat Quay 提供完整的 OAuth 2, RESTful API,它:
- 可从 URL https://<yourquayhost>/api/v1中每个 Red Hat Quay 实例的端点获得
- 允许您通过浏览器连接到端点,通过启用 Swagger UI 来获取、删除、发布和放置 Red Hat Quay 设置
- 可以通过发出 API 调用和使用 OAuth 令牌的应用程序访问
- 以 JSON 形式发送和接收数据
以下文本描述了如何访问 Red Hat Quay API,并使用它来查看和修改 Red Hat Quay 集群中的设置。下一部分列出了和描述 API 端点。
18.1. 从 Quay.io 访问 Quay API
如果您没有运行自己的 Red Hat Quay 集群,您可以从 Web 浏览器浏览 Quay.io 中提供的 Red Hat Quay API:
https://docs.quay.io/api/swagger/
出现的 API Explorer 显示 Quay.io API 端点。您没有看到 Quay.io 上未启用的 Red Hat Quay 功能的超级用户 API 端点或端点(如存储库镜像)。
在 API Explorer 中,您可以获取、有时更改的信息:
- 账单、订阅和计划
- 仓库构建和构建触发器
- 错误消息和全局信息
- 存储库镜像、清单、权限、通知、漏洞和镜像签名
- 使用日志
- 机构、成员和 OAuth 应用程序
- 用户和机器人帐户
- 更多
选择以打开端点,以查看端点的每个部分的 Model Schema。打开端点,输入任何所需的参数(如存储库名称或镜像),然后选择 Try it out! 按钮来查询或更改与 Quay.io 端点关联的设置。
18.2. 创建 OAuth 访问令牌
要创建 OAuth 访问令牌,以便您可以访问机构的 API:
- 登录 Red Hat Quay 并选择您的机构(或创建新机构)。
- 从左侧导航中选择 Applications 图标。
- 选择 Create New Application 并在系统提示时为新应用指定名称。
- 选择新应用程序。
- 从左侧导航中选择 Generate Token。
- 选中复选框来设置令牌范围,然后选择 Generate Access Token。
- 查看您要允许的权限并选择 Authorize Application 批准它。
- 复制新生成的令牌,用于访问 API。
18.3. 从 Web 浏览器访问 Quay API
通过启用 Swagger,您可以通过 Web 浏览器访问您自己的 Red Hat Quay 实例的 API。此 URL 通过 Swagger UI 和这个 URL 公开 Red Hat Quay API 探索器:
https://<yourquayhost>/api/v1/discovery.
这样,访问 API 的方法不包括 Red Hat Quay 安装中提供的超级用户端点。以下是通过运行 swagger-ui 容器镜像来访问在本地系统上运行的 Red Hat Quay API 接口的示例:
# export SERVER_HOSTNAME=<yourhostname> # sudo podman run -p 8888:8080 -e API_URL=https://$SERVER_HOSTNAME:8443/api/v1/discovery docker.io/swaggerapi/swagger-ui
运行 swagger-ui 容器后,打开 Web 浏览器到 localhost 端口 8888,以通过 swagger-ui 容器查看 API 端点。
为了避免日志中的错误,如 "API 调用必须通过 X-Requested-With 标头调用,如果从浏览器中调用,请将以下行添加到 config.yaml 中,并重启 Red Hat Quay:
BROWSER_API_CALLS_XHR_ONLY: false
18.4. 从命令行访问 Red Hat Quay API
您可以通过 Red Hat Quay 集群的 API 使用 curl 命令 GET、PUT、POST 或 DELETE 设置。将 <token> 替换为之前创建的 OAuth 访问令牌,以便在以下示例中获取或更改设置。
18.4.1. 获取超级用户信息
$ curl -X GET -H "Authorization: Bearer <token_here>" \
"https://<yourquayhost>/api/v1/superuser/users/"例如:
$ curl -X GET -H "Authorization: Bearer mFCdgS7SAIoMcnTsHCGx23vcNsTgziAa4CmmHIsg" http://quay-server:8080/api/v1/superuser/users/ | jq
{
"users": [
{
"kind": "user",
"name": "quayadmin",
"username": "quayadmin",
"email": "quayadmin@example.com",
"verified": true,
"avatar": {
"name": "quayadmin",
"hash": "357a20e8c56e69d6f9734d23ef9517e8",
"color": "#5254a3",
"kind": "user"
},
"super_user": true,
"enabled": true
}
]
}18.4.2. 使用 API 创建超级用户
配置超级用户名称,如 Deploy Quay 书中所述:
- 使用配置编辑器 UI 或
-
使用配置 API 验证(并下载)更新的配置捆绑包,直接编辑
config.yaml文件
为超级用户名称创建用户帐户:
获取上述授权令牌,并使用
curl创建用户:$ curl -H "Content-Type: application/json" -H "Authorization: Bearer Fava2kV9C92p1eXnMawBZx9vTqVnksvwNm0ckFKZ" -X POST --data '{ "username": "quaysuper", "email": "quaysuper@example.com" }' http://quay-server:8080/api/v1/superuser/users/ | jq返回的内容包括为新用户帐户生成的密码:
{ "username": "quaysuper", "email": "quaysuper@example.com", "password": "EH67NB3Y6PTBED8H0HC6UVHGGGA3ODSE", "encrypted_password": "fn37AZAUQH0PTsU+vlO9lS0QxPW9A/boXL4ovZjIFtlUPrBz9i4j9UDOqMjuxQ/0HTfy38goKEpG8zYXVeQh3lOFzuOjSvKic2Vq7xdtQsU=" }
现在,当您请求用户列表时,它将以超级用户身份显示 quaysuper :
$ curl -X GET -H "Authorization: Bearer mFCdgS7SAIoMcnTsHCGx23vcNsTgziAa4CmmHIsg" http://quay-server:8080/api/v1/superuser/users/ | jq
{
"users": [
{
"kind": "user",
"name": "quayadmin",
"username": "quayadmin",
"email": "quayadmin@example.com",
"verified": true,
"avatar": {
"name": "quayadmin",
"hash": "357a20e8c56e69d6f9734d23ef9517e8",
"color": "#5254a3",
"kind": "user"
},
"super_user": true,
"enabled": true
},
{
"kind": "user",
"name": "quaysuper",
"username": "quaysuper",
"email": "quaysuper@example.com",
"verified": true,
"avatar": {
"name": "quaysuper",
"hash": "c0e0f155afcef68e58a42243b153df08",
"color": "#969696",
"kind": "user"
},
"super_user": true,
"enabled": true
}
]
}18.4.3. 列出使用日志
可以使用 intrnal API /api/v1/superuser/logs 列出当前系统的使用日志。结果会被分页,在以下示例中,创建了超过 20 个仓库来显示如何使用多个调用来访问整个结果集。
18.4.3.1. 分页示例
第一次调用
$ curl -X GET -k -H "Authorization: Bearer qz9NZ2Np1f55CSZ3RVOvxjeUdkzYuCp0pKggABCD" https://example-registry-quay-quay-enterprise.apps.example.com/api/v1/superuser/logs | jq
初始输出
{
"start_time": "Sun, 12 Dec 2021 11:41:55 -0000",
"end_time": "Tue, 14 Dec 2021 11:41:55 -0000",
"logs": [
{
"kind": "create_repo",
"metadata": {
"repo": "t21",
"namespace": "namespace1"
},
"ip": "10.131.0.13",
"datetime": "Mon, 13 Dec 2021 11:41:16 -0000",
"performer": {
"kind": "user",
"name": "user1",
"is_robot": false,
"avatar": {
"name": "user1",
"hash": "5d40b245471708144de9760f2f18113d75aa2488ec82e12435b9de34a6565f73",
"color": "#ad494a",
"kind": "user"
}
},
"namespace": {
"kind": "org",
"name": "namespace1",
"avatar": {
"name": "namespace1",
"hash": "6cf18b5c19217bfc6df0e7d788746ff7e8201a68cba333fca0437e42379b984f",
"color": "#e377c2",
"kind": "org"
}
}
},
{
"kind": "create_repo",
"metadata": {
"repo": "t20",
"namespace": "namespace1"
},
"ip": "10.131.0.13",
"datetime": "Mon, 13 Dec 2021 11:41:05 -0000",
"performer": {
"kind": "user",
"name": "user1",
"is_robot": false,
"avatar": {
"name": "user1",
"hash": "5d40b245471708144de9760f2f18113d75aa2488ec82e12435b9de34a6565f73",
"color": "#ad494a",
"kind": "user"
}
},
"namespace": {
"kind": "org",
"name": "namespace1",
"avatar": {
"name": "namespace1",
"hash": "6cf18b5c19217bfc6df0e7d788746ff7e8201a68cba333fca0437e42379b984f",
"color": "#e377c2",
"kind": "org"
}
}
},
...
{
"kind": "create_repo",
"metadata": {
"repo": "t2",
"namespace": "namespace1"
},
"ip": "10.131.0.13",
"datetime": "Mon, 13 Dec 2021 11:25:17 -0000",
"performer": {
"kind": "user",
"name": "user1",
"is_robot": false,
"avatar": {
"name": "user1",
"hash": "5d40b245471708144de9760f2f18113d75aa2488ec82e12435b9de34a6565f73",
"color": "#ad494a",
"kind": "user"
}
},
"namespace": {
"kind": "org",
"name": "namespace1",
"avatar": {
"name": "namespace1",
"hash": "6cf18b5c19217bfc6df0e7d788746ff7e8201a68cba333fca0437e42379b984f",
"color": "#e377c2",
"kind": "org"
}
}
}
],
"next_page": "gAAAAABhtzGDsH38x7pjWhD8MJq1_2FAgqUw2X9S2LoCLNPH65QJqB4XAU2qAxYb6QqtlcWj9eI6DUiMN_q3e3I0agCvB2VPQ8rY75WeaiUzM3rQlMc4i6ElR78t8oUxVfNp1RMPIRQYYZyXP9h6E8LZZhqTMs0S-SedaQJ3kVFtkxZqJwHVjgt23Ts2DonVoYwtKgI3bCC5"
}
使用 next_page 进行第二次调用
$ curl -X GET -k -H "Authorization: Bearer qz9NZ2Np1f55CSZ3RVOvxjeUdkzYuCp0pKggABCD" https://example-registry-quay-quay-enterprise.apps.example.com/api/v1/superuser/logs?next_page=gAAAAABhtzGDsH38x7pjWhD8MJq1_2FAgqUw2X9S2LoCLNPH65QJqB4XAU2qAxYb6QqtlcWj9eI6DUiMN_q3e3I0agCvB2VPQ8rY75WeaiUzM3rQlMc4i6ElR78t8oUxVfNp1RMPIRQYYZyXP9h6E8LZZhqTMs0S-SedaQJ3kVFtkxZqJwHVjgt23Ts2DonVoYwtKgI3bCC5 | jq
第二个调用的输出
{
"start_time": "Sun, 12 Dec 2021 11:42:46 -0000",
"end_time": "Tue, 14 Dec 2021 11:42:46 -0000",
"logs": [
{
"kind": "create_repo",
"metadata": {
"repo": "t1",
"namespace": "namespace1"
},
"ip": "10.131.0.13",
"datetime": "Mon, 13 Dec 2021 11:25:07 -0000",
"performer": {
"kind": "user",
"name": "user1",
"is_robot": false,
"avatar": {
"name": "user1",
"hash": "5d40b245471708144de9760f2f18113d75aa2488ec82e12435b9de34a6565f73",
"color": "#ad494a",
"kind": "user"
}
},
"namespace": {
"kind": "org",
"name": "namespace1",
"avatar": {
"name": "namespace1",
"hash": "6cf18b5c19217bfc6df0e7d788746ff7e8201a68cba333fca0437e42379b984f",
"color": "#e377c2",
"kind": "org"
}
}
},
...
]
}
18.4.4. 目录同步
要在机构 testadminorg 中为团队 newteam 启用目录同步,其中 LDAP 中的对应组名称是 ldapgroup :
$ curl -X POST -H "Authorization: Bearer 9rJYBR3v3pXcj5XqIA2XX6Thkwk4gld4TCYLLWDF" \
-H "Content-type: application/json" \
-d '{"group_dn": "cn=ldapgroup,ou=Users"}' \
http://quay1-server:8080/api/v1/organization/testadminorg/team/newteam/syncing为同一团队禁用同步:
$ curl -X DELETE -H "Authorization: Bearer 9rJYBR3v3pXcj5XqIA2XX6Thkwk4gld4TCYLLWDF" \
http://quay1-server:8080/api/v1/organization/testadminorg/team/newteam/syncing18.4.5. 通过 API 创建存储库构建
要从指定的输入构建存储库,并标记带有自定义标签的构建,用户可以使用 requestRepoBuild 端点。它采用以下数据:
{
"docker_tags": [
"string"
],
"pull_robot": "string",
"subdirectory": "string",
"archive_url": "string"
}
archive_url 参数应指向 tar 或 zip 存档,其包含 Dockerfile 和其他构建所需的文件。file_id 参数超出了我们旧的构建系统。它无法再使用。如果 Dockerfile 位于子目录中,则需要指定它。
归档应该可以被公开访问。OAuth 应用应具有"管理员组织"范围,因为只有机构管理员有权访问机器机器的帐户令牌。否则,某人可以通过向机器授予构建访问权限(无需访问其自身)来获得机器人的权限,并使用它来获取镜像内容。如果出现错误,请检查返回的 json 块,并确保正确传递归档位置、拉取机器和其他参数。单击各个构建页面右上角的"下载日志",以检查日志以了解更详细的消息。
18.4.6. 创建机构机器
$ curl -X PUT https://quay.io/api/v1/organization/{orgname}/robots/{robot shortname} \
-H 'Authorization: Bearer <token>''18.4.7. 触发构建
$ curl -X POST https://quay.io/api/v1/repository/YOURORGNAME/YOURREPONAME/build/ \ -H 'Authorization: Bearer <token>'
带有请求的 Python
import requests
r = requests.post('https://quay.io/api/v1/repository/example/example/image', headers={'content-type': 'application/json', 'Authorization': 'Bearer <redacted>'}, data={[<request-body-contents>})
print(r.text)18.4.8. 创建私有存储库
$ curl -X POST https://quay.io/api/v1/repository \
-H 'Authorization: Bearer {token}' \
-H 'Content-Type: application/json' \
-d '{"namespace":"yournamespace", "repository":"yourreponame",
"description":"descriptionofyourrepo", "visibility": "private"}' | jq18.4.9. 创建已镜像的存储库
最小配置
curl -X POST
-H "Authorization: Bearer ${bearer_token}"
-H "Content-Type: application/json"
--data '{"external_reference": "quay.io/minio/mc", "external_registry_username": "", "sync_interval": 600, "sync_start_date": "2021-08-06T11:11:39Z", "root_rule": {"rule_kind": "tag_glob_csv", "rule_value": [ "latest" ]}, "robot_username": "orga+robot"}' https://${quay_registry}/api/v1/repository/${orga}/${repo}/mirror | jq
扩展配置
$ curl -X POST
-H "Authorization: Bearer ${bearer_token}"
-H "Content-Type: application/json"
--data '{"is_enabled": true, "external_reference": "quay.io/minio/mc", "external_registry_username": "username", "external_registry_password": "password", "external_registry_config": {"unsigned_images":true, "verify_tls": false, "proxy": {"http_proxy": "http://proxy.tld", "https_proxy": "https://proxy.tld", "no_proxy": "domain"}}, "sync_interval": 600, "sync_start_date": "2021-08-06T11:11:39Z", "root_rule": {"rule_kind": "tag_glob_csv", "rule_value": [ "*" ]}, "robot_username": "orga+robot"}' https://${quay_registry}/api/v1/repository/${orga}/${repo}/mirror | jq