Deploy Interfaces

部署接口在供应过程中起着至关重要的作用。它协调整个部署过程，并定义镜像如何传输到目标磁盘。

Direct deploy

使用 direct 部署接口时，部署 ramdisk 会从 HTTP 位置获取镜像。它可以是对象存储（swift 或 RadosGW）的临时 URL，也可以是用户提供的 HTTP URL。然后，部署 ramdisk 会将镜像复制到目标磁盘。有关此部署接口工作原理的详细说明，请参阅 direct deploy diagram。

在创建或更新节点时，您可以指定此部署接口

baremetal node create --driver ipmi --deploy-interface direct
baremetal node set <NODE> --deploy-interface direct

注意

出于历史原因，direct 部署接口有时被称为 agent。这是因为在 Kilo 版本之前，ironic-python-agent 只支持此部署接口。

Deploy with custom HTTP servers

还可以配置 direct 部署接口，与在 ironic conductor 节点上设置的自定义 HTTP 服务器一起使用，镜像将被本地缓存并可通过 HTTP 服务器访问。

要将此部署接口与自定义 HTTP 服务器一起使用，请在 [agent] 部分将 image_download_source 设置为 http。

[agent]
...
image_download_source = http
...

此配置会影响glance 和 file:// 镜像。如果您希望 http(s):// 镜像也被本地缓存和提供，请改用

[agent]
image_download_source = local

注意

此选项也可以在 driver_info 中按节点设置

baremetal node set <node> --driver-info image_download_source=local

或在 instance_info 中按实例设置

baremetal node set <node> --instance-info image_download_source=local

您需要在每个启用了 direct 部署接口的 conductor 节点上设置一个可用的 HTTP 服务器，并检查 ironic 配置文件中的 http 相关选项，以匹配 HTTP 服务器的配置。

[deploy]
http_url = http://example.com
http_root = /httpboot

注意

另请参阅： Deploying outside of the provisioning network。

每个 HTTP 服务器都应配置为遵循符号链接以访问 HTTP 服务中的镜像。如果您使用的是 Apache HTTP 服务器，请参考配置选项 FollowSymLinks；如果您使用的是 Nginx HTTP 服务器，请参考 disable_symlinks。

Streaming raw images

Bare Metal 服务能够将原始镜像直接流式传输到节点的目标磁盘，而无需将其缓存在节点的 RAM 中。当源镜像不是原始格式时，conductor 会转换镜像并计算新的校验和。

注意

如果未通过 image_os_hash_algo 字段指定算法，或者此字段设置为 md5，则 SHA256 用于更新的校验和。

对于已经是原始格式的 HTTP 或本地文件镜像，您需要显式设置磁盘格式以防止不必要地重新计算校验和。例如

baremetal node set <node> \
    --instance-info image_source=http://server/myimage.img \
    --instance-info image_os_hash_algo=sha512 \
    --instance-info image_os_hash_value=<SHA512 of the raw image> \
    --instance-info image_disk_format=raw

要禁用此功能并将镜像缓存在节点的 RAM 中，请设置

[agent]
stream_raw_images = False

要完全禁用 conductor 端转换，请设置

[DEFAULT]
force_raw_images = False

Ansible deploy

此接口与 direct 类似，因为镜像直接由 ramdisk 从镜像存储（而不是从 ironic-conductor 主机）下载，但节点的供应逻辑由 ironic-conductor 服务处理的一组 Ansible playbook 来控制。尽管设置起来更复杂一些，但此部署接口在供应过程中的高级节点准备方面提供了更大的灵活性。

此接口受 ironic 中声明的大部分硬件类型支持，但并非全部。但是，此部署接口默认不启用。要启用它，请在 ironic 的配置文件 [DEFAULT] 部分的 enabled_deploy_interfaces 选项列表中添加 ansible。

[DEFAULT]
...
enabled_deploy_interfaces = direct,ansible
...

启用后，您可以在创建或更新节点时指定此部署接口

baremetal node create --driver ipmi --deploy-interface ansible
baremetal node set <NODE> --deploy-interface ansible

有关此部署接口、其功能以及如何使用的更多信息，请参阅 Ansible deploy interface。

Anaconda deploy

anaconda 部署接口是高度定制化部署的另一个选择。有关更多详细信息，请参阅 Deploying with anaconda deploy interface。

Ramdisk deploy

ramdisk 接口旨在提供一种机制来“部署”实例，其中要部署的项目实际上是 ramdisk。它单独记录，请参阅 Booting a Ramdisk or an ISO。

Custom agent deploy

custom-agent 部署接口专为希望使用 in-band deploy steps from a custom agent image 完全协调写入实例镜像的运算符而设计。如果您使用此部署接口，您负责提供所有必要的部署步骤，其优先级介于 61 和 99 之间（有关优先级的更多信息，请参阅 Agent steps）。

Bootc Agent Deploy

bootc 部署接口旨在使运算符能够直接从容器镜像注册表部署容器，而无需中间转换步骤，例如创建自定义磁盘镜像进行修改。此部署接口利用 bootc project。

最终，这会实现一个简化的流程，部署接口的用户可以快速创建更新的容器，部署接口会以简化的方式部署该容器镜像，而无需创建中间磁盘镜像并将磁盘镜像发布到可供部署访问的位置。

最终，此接口实现了一个简化的流程，并且在部署模型方面灵活性有限。因此，此接口会占用被部署主机上的整个目标磁盘，并且在分区方面不提供任何自定义。这主要是因为 bootc 部署的整体安全模型（利用 os-tree）与利用分区分离的模型也根本不同。

注意

此接口应被视为实验性的，并可能随着 Ironic 项目维护者收到其他反馈而演进，以包含其他功能。

注意

此接口依赖于容器中 bootc 的存在，以及被部署的裸机节点上具有足够的内存来启用在系统内存中完整下载和提取镜像内容。正是这个内存限制导致此接口未在 upstream CI 中得到积极测试。此接口的可能故障模式主要集中在 ramdisk 下载、启动和运行 bootc 以触发安装的能力上，这也将大部分风险隔离在实际 bootc 进程的执行中。

特性

虽然此 deploy_interface 支持部署配置驱动器，就像大多数其他 Ironic 提供的部署接口一样，但可以通过 instance_info 提供一些附加参数，以使用户能够调整部署时行为，而这些行为在部署后无法修改。

  • bootc_authorized_keys - 此选项允许注入一个根用户 authorized keys 文件，该文件保存在主机上的已部署容器内。此选项用于实际密钥文件，可以是一个或多个密钥，并以换行符分隔。

  • bootc_tpm2_luks - 一个布尔选项，默认为 False，启用 bootc 尝试使用自动加密已部署容器所在的宿主文件系统。由于 Ironic CI 中缺乏软件 TPM，因此默认不启用此选项。如果运算符希望更改此设置的默认值，请与 Ironic 开发人员讨论。

此外，此接口还支持传递一个拉取密钥以启用从远程镜像注册表下载，这是从 OCI Container 注册表检索工件支持的一部分。此参数是 image_pull_secret。

注意事项

  • 此部署接口并非设计为与 OpenStack Compute 服务兼容。这是因为 OpenStack 关注 Glance 的磁盘镜像用于部署什么，而此接口的模式是利用容器镜像注册表。

  • 从性能角度来看，此部署接口执行许多较小的操作，有时需要在特定顺序执行，例如解包层。因此，当比较相似大小的容器与磁盘镜像时，此接口比 direct 部署接口慢。

  • 容器镜像必须包含 bootc 命令以及适用于正在部署的任何平台的适用引导加载程序和工件。

  • 由于 bootc 的工作方式，不存在直接“镜像流式传输”到磁盘的概念。这是因为此接口的工作方式是，使用 podman 下载所有容器镜像层工件，并提取这些层。然后执行 bootc，它开始设置主机的磁盘。因此，在部署进行时，大部分时间都将显示为 deploy wait，而 bootc 则在执行。

  • 由于此接口的工作方式，ramdisk 的内存需求要求能够下载容器镜像、复制并最终将所有层提取到内存文件系统中。由于内核启动和分配 ramdisk 内存以供文件系统使用的方式，一个 600MB 的容器镜像可能需要在整个主机上提供高达 10GB 的 RAM。

  • 此部署接口明确向 bootc 发出信号，表示不应执行其内部的部署后“fetch check”以确保升级正常工作。这是因为此操作可能需要身份验证才能成功，并且因此需要容器中的凭据才能工作。对于诸如执行 bootc upgrade 等Day-2 操作的凭据配置，必须在部署后解决。

  • 如果您打算在已部署的主机上启用 SELinux，则必须在 ironic-python-agent ramdisk 中也启用它。这是 bootc 在 Ironic 控制之外的设计限制。

限制

  • 目前，此接口不支持使用缓存代理。这可能在未来解决。

  • 此部署接口直接从请求的容器注册表下载工件。不支持将容器工件缓存在 ironic-conductor 主机上。如果您需要将容器内容本地化到 conductor，请考虑使用您自己的容器注册表。