OpenStack Ironic 独立部署入门详解：上

新钛云服已累计为您分享856篇技术干货

想在云环境中像管理虚拟机（VM）一样管理物理服务器吗？想在物理节点上实现基础设施即代码（IaC）和 CI/CD 流水线吗？下面，让我们通过一些实用、简单且可复现的案例，来揭开私有云基础设施和裸金属生命周期管理的一些神秘面纱，我们将从一个最小化的 OpenStack Ironic “独立”部署开始。

• 使用 OpenStack Kolla 和 Ironic 安装并管理一个简单的裸金属配置系统。

• 管理物理服务器的通用生命周期：上线、资源收集、操作系统安装、故障恢复、回收。

• 应用 IaC 方法进行节点和应用程序的配置。

一旦我们了解了 Ironic 的“独立”模式，将其与 Keystone、Cinder、Nova 和 Neutron 等其他 OpenStack 服务集成就会变得更加简单，从而扩展其功能，将数据中心转变为一个能够同时管理裸金属工作负载和虚拟机的真正私有云。

引 言

日常与物理服务器 、手动配置、驱动程序、BIOS以及维护庞大物理机器打交道的人，都深知裸金属管理（即管理未预装操作系统的物理服务器）是多么耗时且繁琐。

你肯定对OpenStack不陌生。它是一个开源的云服务套件，允许你以代码方式和“as-a-Service”的形式管理虚拟资源（虚拟机、网络、存储）。而Ironic正是 OpenStack 中将这一理念延伸到物理机管理的组件。

OpenStack Ironic 是一个裸金属配置和管理服务，它将物理服务器集成到 OpenStack 框架中，视其为云资源。这意味着物理服务器可以通过 API 进行请求、分配、配置和释放，就像操作虚拟机一样。

这与虚拟化无关：Ironic 不会在物理硬件上创建虚拟机。Ironic 管理的是物理硬件本身，它直接在机器上安装操作系统，没有任何中间的虚拟化层。

管理裸金属生命周期

传统上，管理裸金属服务器的生命周期是一个包含多个阶段的过程，通常是手动的且非常耗时：

1. 采购与物理安装：接收、上架、布线。

2. BIOS/UEFI 配置：手动进入、进行特定设置。

3. RAID 控制器配置：创建阵列、配置磁盘。

4. 操作系统安装：从 CD/USB/PXE 启动，手动或半自动安装。

5. 安装后配置：驱动、软件、网络、安全加固。

6. 维护与更新：打补丁、升级固件。

7. 回收：擦除磁盘、移除设备。

有了 Ironic，整个过程发生了转变，我们就实现了“as-a-Service”的管理方式：

1. 发现与注册（Onboarding）：Ironic 通过 PXE 启动和代理“发现”机器，并将其注册到其清单中。注册后，Ironic 可以直接与其BMC（管理控制器，如 iLO、iDRAC、IMM）进行交互。

2. “As-a-Service”式配置：用户（或自动化服务）可以通过 OpenStack API 请求一台具有特定特性（CPU、RAM、存储）的物理服务器。Ironic 会选择一台可用的服务器，打开电源，安装所选的操作系统（GNU/Linux、Windows、VMware ESXi 等），配置网络，并在短时间内使其可用。

3. 远程自动化管理：得益于与 BMC 的集成，Ironic 可以通过程序方式执行诸如开/关机、重启、重置、引导设备管理、固件更新（通过插件）甚至 BIOS/UEFI 设置等操作，所有这些都无需任何手动干预。

4. 回收与清理：当不再需要某台服务器时，Ironic 可以执行安全磁盘擦除并重置 BIOS/UEFI 设置，使服务器恢复到“干净”状态，可供重用或最终回收，整个过程完全自动化。

5. 与其他 OpenStack 服务集成：最后但同样重要的是，Ironic 可以与用于物理网络管理的Neutron、用于操作系统镜像管理的Glance、用于提供持久性存储的Cinder以及用于提供统一图形界面的Horizon集成。这使得构建复杂的解决方案成为可能，其中裸金属是云基础设施的延伸，不仅可以实现资源的“即服务”消费，还可以实现像 CI/CD 流水线这样的自动化交互。

01

实验环境

让我们考虑一个简化的环境，这样我们就可以用最少的精力来搭建它，并主要关注裸金属配置机制：

• LAN 网络192.168.0.0/24：也称为公共网络，这将是一个统一的客户端和服务器网络，通过一个路由器（.254）连接到互联网，该路由器在 x.x.x.101-199 范围内通过 DHCP 分配 IP 地址。

• OOB/IB 网络172.19.74.0/24：这个独立的网络由一台小型服务器（图中标记为“bms”）管理，用于控制裸金属节点的配置。这些节点通过 BMC 连接以进行带外管理（iLO、iDRAC、IMM 等），并通过以太网卡进行带内管理（部署、巡检、救援等）。

两个交换机都是非网管交换机，没有 VLAN，这样就可以使用“现成”的硬件，或者用企业级设备、甚至虚拟化环境轻松模拟。

1.1 裸金属服务

bms服务器，即我们将要安装裸金属配置环境的服务器，并不需要很高的资源。最低规格要求是4GB 内存、2 个 CPU 核心、2 个网卡和至少 200GB 的磁盘空间（用于托管和构建操作系统镜像及容器）。但是，建议至少使用8GB 内存和 4 个 CPU 核心，以便将来可以扩展环境并添加更多服务。

在软件方面，将使用以下主要组件：

• OpenStack 2025.1 (Epoxy)：在撰写本文时，这是最新的 OpenStack 版本，Kolla 和 Kolla Ansible（本文用于部署 OpenStack 的系统）已经为其发布了即用型容器。

• Debian GNU/Linux 12 (Bookworm)：尽管 OpenStack 在很大程度上与各种 GNU/Linux 发行版无关（尤其是在通过容器安装时），但为了避免偏向商业发行版，我们将使用 Debian。

• Podman：它为 Docker 提供了一个轻量级且集成的替代方案，同时保持了与现有生态系统的兼容性，并与像 Kubernetes 这样的“Pod”基础设施保持一致。

02

创建实验环境

1. 安装 bms 服务器；

2. 安装 Podman 容器管理系统；

3. 创建 kolla 管理用户；

4. 创建 Python 虚拟环境；

5. 安装 OpenStack Kolla Ansible；

6. 为裸金属配置进行最小化配置；

7. 部署 OpenStack。

2.1 服务器安装（bms）

对于操作系统安装，请选择您偏好的 GNU/Linux 版本并相应地调整配置：

root@bms:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback
auto enp1s0
iface enp1s0 inet static
    address 192.168.0.13/24
    gateway 192.168.0.254
auto enp2s0
iface enp2s0 inet static
    address 172.19.74.1/24
root@bms:~# cat /etc/hosts
127.0.0.1 localhost
172.19.74.1 bms.ironic.lab bms
root@bms:~# hostname -i
172.19.74.1
root@bms:~# hostname -f
bms.ironic.lab

• enp1s0 (192.168.0.13/24):LAN网络

• enp2s0 (172.19.74.1/24):OOB/IB网络

对于 Kolla Ansible 项目来说，至关重要的一点是服务器名称——在本场景中是 bms 和 bms.ironic.lab——必须解析到 OpenStack 内部服务将要监听的IP 地址（172.19.74.1）。在所提议的实验中，这个 IP 地址与OOB/IB 管理网络的 IP 地址相同。

2.2 Podman

作为Docker 的直接替代品，Podman 即使对新手来说也很容易使用。安装非常直接，因为它已作为标准软件包包含在大多数 GNU/Linux 发行版中：

root@bms:~# apt install -y podman
...
root@bms:~# podman info
host:
  arch: amd64
  buildahVersion: 1.28.2
  cgroupControllers:
  - cpu
  - memory
  - pids
cgroupManager: systemd
cgroupVersion: v2
...
version:
  APIVersion: 4.3.1
  Built: 0
  BuiltTime: Thu Jan 1 01:00:00 1970
  GitCommit: ""
  GoVersion: go1.19.8
  Os: linux
  OsArch: linux/amd64
  Version: 4.3.1

如果您习惯使用 Docker 并希望为了方便而保留 docker 命令，您也可以安装 podman-docker 包，它会为此创建一个专用的包装器。然而，在大多数情况下，一个简单的 alias docker=podman 可能就足够了。

与 Docker 最明显的区别之一是，Podman 使用调用它的用户来运行容器，而不依赖于一个集中的守护进程。如果多个用户运行容器，那么只有拥有这些容器的用户才能通过 podman container ps 命令看到它们；root 用户也不例外。

2.3 管理用户

创建一个管理用户（例如 kolla）来执行各种操作，始终是一个好的实践。这在安全性和功能性方面都有好处，可以将部署环境与您的个人用户或 root 用户分离开来：

root@bms:~# useradd --system --add-subids-for-system \
  -d /var/lib/kolla \
  -c 'Kolla Administrator' \
  -s /bin/bash \
  -m kolla
root@bms:~> passwd kolla
New password: *********
Retype new password: *********
passwd: password updated successfully

注意：--add-subids-for-system选项是必需的，以允许即使是系统用户也能执行无根容器 (rootless containers)。

确保该用户能够通过 sudo 执行 root 命令：

root@bms:~# echo 'kolla ALL=(ALL:ALL) NOPASSWD:ALL' >/etc/sudoers.d/kolla

现在我们可以用 kolla 管理用户连接并继续进行服务器配置。

2.4 Python 虚拟环境（venv）

用于裸金属配置和部署 OpenStack 本身的 OpenStack 组件也可以作为PyPI 包获取。在大多数最新的 GNU/Linux 发行版中，强烈不建议在系统级别安装 Python 包。要拥有一个包含必要软件的 Python 环境，而又不“污染”系统的 Python 环境，最方便的方法是创建一个与先前创建的管理用户相关联的Python 虚拟环境：

kolla@bms:~$ sudo apt install -y \
  python3-dbus \
  python3-venv
...
kolla@bms:~$ python3 -m venv --system-site-packages $HOME
...
kolla@bms:~$ cat >>~/.profile <
# 激活 Python 虚拟环境
if [ -f "\$HOME/bin/activate" ]; then
    . "\$HOME/bin/activate"
fi
EOF
kolla@bms:~$ source ~/bin/activate
kolla@bms:~$ python3 -m pip install -U pip

修改用户主目录中的 .profile 文件可以在每次登录时自动激活虚拟环境。同时，使用 --system-site-packages选项可以访问系统的 Python 库（例如 python3-dbus），而无需重新安装它们。

注意：要在虚拟环境中安装 dbus-python 包（相当于系统包 python3-dbus），从而避免使用 --system-site-packages 选项，您需要安装开发工具：sudo apt install build-essential pkg-config libdbus-1-dev libglib2.0-dev python3-dev。如果您选择这条路，最好在生产环境中安装后移除编译器。

2.5 OpenStack Kolla Ansible

Kolla Ansible 项目的主要目标是简化和最大化 OpenStack 配置和管理的效率。为实现这一目标，它利用Ansible实现自动化和可复现性，并将 OpenStack 组件封装在Docker 容器中，以简化其部署、更新和扩展。

Kolla Ansible 依赖于一个特定且严格的 Python 包及其各自版本的链条。使用先前配置的Python 虚拟环境有助于在 kolla-ansible 包的各种版本之间保持分离和一致性，特别是 Ansible 本身及其各种 Ansible Galaxy 库依赖项。

kolla@bms:~$ sudo apt install -y tree yq
...
kolla@bms:~$ python3 -m pip install kolla-ansible docker podman
...
kolla@bms:~$ kolla-ansible --version
kolla-ansible 19.4.0
kolla@bms:~$ kolla-ansible install-deps
Installing Ansible Galaxy dependencies
Starting galaxy collection install process
Process install dependency map
...
kolla@bms:~$ ansible --version
ansible [core 2.17.9]
  config file = None
  configured module search path = ['/var/lib/kolla/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /var/lib/kolla/lib/python3.11/site-packages/ansible
  ansible collection location = /var/lib/kolla/.ansible/collections:/usr/share/ansible/collections
  executable location = /var/lib/kolla/bin/ansible
  python version = 3.11.2 (main, Nov 30 2024, 21:22:50) [GCC 12.2.0] (/var/lib/kolla/bin/python3)
  jinja version = 3.1.6
  libyaml = True

注意：tree 和 yq 包不是必需的；它们包含本文中用于目录检查和简化 YAML 和 JSON 文件管理的实用程序。

让我们安装 OpenStack 命令行客户端：

kolla@bms:~$ python3 -m pip install \
  -c https://releases.openstack.org/constraints/upper/master \
  python-openstackclient \
  python-ironicclient

可选地，如果您想在登录时通过 [tab] 键启用命令自动补全，可以创建以下文件和目录：

kolla@bms:~$ mkdir ~/.bash_completion.d
kolla@bms:~$ openstack complete >~/.bash_completion.d/openstack
kolla@bms:~$ cat >~/.bash_completion <
# 加载本地 bash 补全
if [[ -d ~/.bash_completion.d ]]; then
    for i in ~/.bash_completion.d/*; do
        [[ -f \$i && -r \$i ]] && . "\$i"
    done
fi
EOF

要配置 Kolla Ansible，您需要提供一对YAML 文件，globals.yml 和 passwords.yml，它们定义了配置以及与各种已启用组件的系统用户相关联的凭据集。此外，还需要一个Ansible inventory文件。所有这些文件都应放在默认目录 /etc/kolla 中，或由 KOLLA_CONFIG_PATH 环境变量指定的目录中。

利用 kolla 系统用户的主目录，我们将所有配置文件放在 /var/lib/kolla/etc 中。

注意：拥有一个不同于默认值 (/etc/kolla) 的配置目录，可以防止在重置 Kolla 环境时（例如，使用 kolla-ansible destroy 命令）意外删除其文件。

对于 inventory，我们将使用提供的示例all-in-one文件，passwords.yml 文件也类似。后者是一个模板，稍后将使用 kolla-genpwd命令填充：

kolla@bms:~$ export KOLLA_CONFIG_PATH=~/etc
kolla@bms:~$ cat >>~/.bashrc <

同时，我们将用一个最小化版本替换 globals.yml 配置文件：

---
# 主机配置
kolla_base_distro: "debian"
kolla_container_engine: "podman"
# OpenStack 'master' 或发布版本
openstack_release: "2025.1"
#openstack_tag_suffix: "-aarch64"
# OpenStack 服务
enable_fluentd: false
enable_haproxy: false
enable_memcached: false
enable_proxysql: false
enable_openstack_core: false
enable_ironic: true
# Kolla 配置
network_interface: "enp2s0"
kolla_internal_vip_address: "172.19.74.1"
# Ironic 配置
ironic_dnsmasq_interface: "{{ network_interface }}"
ironic_dnsmasq_dhcp_ranges:
- range: "172.19.74.101,172.19.74.199,255.255.255.0"
routers: "172.19.74.1"

注意：如果您使用的是基于ARM 处理器的系统，容器也必须遵循相同的架构。只需取消注释 openstack_tag_suffix: "-aarch64"这一行即可下载正确的容器。

在使用 Ansible playbooks 并尝试解读任何以 JSON 表示的错误消息之前，使用一种稍微更易读的输出格式可能会很方便，例如YAML：

kolla@bms:~$ cat >~/.ansible.cfg <

为了验证一切是否正确，让我们运行 kolla-ansible prechecks 命令：

我们收到的红色错误消息表明缺少两个文件，它们代表Ironic Python Agent (IPA)的内核和ramdisk：

failed: [localhost] (item=ironic-agent.kernel) => changed=false 
  ansible_loop_var: item
  failed_when_result: true
  item: ironic-agent.kernel
  stat:
    exists: false
failed: [localhost] (item=ironic-agent.initramfs) => changed=false 
  ansible_loop_var: item
  failed_when_result: true
  item: ironic-agent.initramfs
  stat:
    exists: false

顾名思义，它是一个用 Python 编写的代理，充当裸金属服务器和 OpenStack Ironic 之间的中介。它由一个实时的、在内存中运行的 GNU/Linux 操作系统组成，通过网络启动（PXE）加载到要管理的服务器上。

目前，我们将从 OpenStack 文档

(https://tarballs.opendev.org/openstack/ironic-python-agent/dib/files/)

下载一个预构建的版本：

kolla@bms:~$ mkdir -p $KOLLA_CONFIG_PATH/config/ironic
kolla@bms:~$ curl https://tarballs.opendev.org/openstack/ironic-python-agent/dib/files/ipa-centos9-master.kernel \
  -o $KOLLA_CONFIG_PATH/config/ironic/ironic-agent.kernel
kolla@bms:~$ curl https://tarballs.opendev.org/openstack/ironic-python-agent/dib/files/ipa-centos9-master.initramfs \
  -o $KOLLA_CONFIG_PATH/config/ironic/ironic-agent.initramfs

这两个文件（ironic-agent.kernel 和 ironic-agent.initramfs）必须放在 $KOLLA_CONFIG_PATH/config/ironic/ 目录中。稍后它们将被一个为我们的需求专门创建的自定义版本所取代。

现在我们可以重新运行 kolla-ansible prechecks 命令：

注意：每个报告的错误都必须被纠正，并且预检查步骤必须重新执行，直到获得一个干净的结果（errors=0）。

2.6 OpenStack Ironic “独立”配置

在“独立”模式下，Ironic 可以独立于其他 OpenStack 服务运行。这使您可以使用其功能而无需安装整个云平台（尽管您会放弃私有云环境可能提供的一系列高级功能）。因此，$KOLLA_CONFIG_PATH/globals.yml 文件包含以下几行：

...

 ... enable_openstack_core: false enable_ironic: true ...

 ... 

enable_openstack_core: false选项禁用了所有本应由 Kolla Ansible 自动安装的组件，包括 Keystone、Glance、Nova、Neutron、Heat 和 Horizon。相反，enable_ironic: true只启用了 Ironic。

2.6 Ironic 配置

ironic.conf配置文件，应放置在 $KOLLA_CONFIG_PATH/config/ 中，必须包含特定的指令以启用要支持的 BMC 类型（Ironic 称之为硬件类型 (Hardware Types)）以及其他关于如何管理特定领域的说明。

对于 Ironic 管理的每个领域，都有相应的“接口”来控制操作：

• BIOS：管理 BIOS 设置。

• Boot：提供引导机制（例如，PXE、虚拟介质等）。

• Console：访问串行控制台。

• Deploy：管理节点安装和清理。

• Firmware：更新 BIOS/UEFI、RAID 控制器等。

• Inspect：收集硬件配置。

• Management：管理服务器引导模式。

• Network：与 OpenStack 的网络服务交互。

• Power：管理电源状态。

• RAID：配置 RAID 卷。

• Rescue：提供恢复功能。

• Storage：与 OpenStack 的存储系统交互。

• Vendor：提供额外的特定于供应商的功能。

[DEFAULT]
enabled_hardware_types = ipmi,redfish
enabled_bios_interfaces = no-bios
enabled_boot_interfaces = ipxe
enabled_console_interface = no-console
enabled_deploy_interfaces = direct
enabled_firmware_interfaces = no-firmware
enabled_inspect_interfaces = agent
enabled_management_interfaces = ipmitool,redfish
enabled_network_interfaces = noop
enabled_power_interfaces = ipmitool,redfish
enabled_raid_interfaces = agent
enabled_rescue_interfaces = agent
enabled_storage_interfaces = noop
enabled_vendor_interfaces = ipmitool,redfish
[conductor]
deploy_kernel = http://{{ ironic_http_interface_address }}:{{ ironic_http_port }}/ironic-agent.kernel
deploy_ramdisk = http://{{ ironic_http_interface_address }}:{{ ironic_http_port }}/ironic-agent.initramfs
rescue_kernel = http://{{ ironic_http_interface_address }}:{{ ironic_http_port }}/ironic-agent.kernel
rescue_ramdisk = http://{{ ironic_http_interface_address }}:{{ ironic_http_port }}/ironic-agent.initramfs

在 [conductor] 部分，我们可以指定用于系统安装和恢复的默认内核和 ramdisk。变量 ironic_http_interface_address 和 ironic_http_port——其名称已足够自明——将在实际配置文件创建过程中由 Ansible 用其各自的值进行扩展。

2.7 OpenStack 部署

让我们检查一下配置目录 $KOLLA_CONFIG_PATH，它应该包含以下文件：

kolla@bms:~$ tree $KOLLA_CONFIG_PATH
/var/lib/kolla/etc
├── ansible
│   └── inventory
│   └── all-in-one
├── config
│   ├── ironic
│   │   ├── ironic-agent.initramfs
│   │   └── ironic-agent.kernel
│   └── ironic.conf
├── globals.yml
└── passwords.yml
5 directories, 6 files

• globals.yml：OpenStack Kolla 的 YAML 配置文件；

• passwords.yml：包含各组件使用的用户和密码的 YAML 文件；

• ansible/inventory/all-in-one：默认的 Ansible inventory；

• config/ironic.conf：包含 OpenStack Ironic 特定配置选项的 INI 文件；

• config/ironic/ironic-agent.{kernel,initramfs}：与 Ironic Python Agent 相关的二进制文件。

要在实际部署前预先验证配置，您可以运行 kolla-ansible validate-config 命令，如果没有错误需要纠正，最终可以继续执行 kolla-ansible deploy 命令：

注意：如果出现错误，为了获得更多的调试信息，您可以通过使用相应数量的“-v”选项重新运行命令来增加 Ansible 消息的“详细程度”（例如，kolla-ansible deploy -vvv）。

部署完成后，将有多个容器处于活动状态：一些是服务容器，另一些是 OpenStack Ironic 特有的容器：

• kolla_toolbox：这是一个管理“代理”容器。

• cron：用于执行计划的批处理操作（例如，logrotate）。

• mariadb[tcp/3306]：用于 OpenStack 持久化数据的数据库。

• rabbitmq[tcp/5672]：用于跟踪事务性或有状态活动的消息队列。

• ironic_conductor：Ironic 的业务逻辑。

• ironic_api[tcp/6385]：RESTful API 前端 (裸金属 API)。

• ironic_tftp[udp/69]：用于通过 PXE 提供内核和 ramdisk 的 Trivial FTP (FTP over UDP)。

• ironic_http[tcp/8089]：HTTP 仓库。

• ironic_dnsmasq[udp/67]：DHCP 服务器。

kolla@bms:~$ sudo podman container ps -a
CONTAINER ID  IMAGE                        CREATED        STATUS                      NAMES
978e287862b4  kolla-toolbox:2025.1         5 minutes ago  Up 5 minutes ago            kolla_toolbox
6d0150fa51e2  cron:2025.1                  5 minutes ago  Up 5 minutes ago            cron
a9df741f70c6  mariadb-clustercheck:2025.1  4 minutes ago  Up 4 minutes ago            mariadb_clustercheck
e222e740d7ce  mariadb-server:2025.1        4 minutes ago  Up 4 minutes ago (healthy)  mariadb
efe4ebcce42c  rabbitmq:2025.1              4 minutes ago  Up 4 minutes ago (healthy)  rabbitmq
fd7169161d76  ironic-conductor:2025.1      3 minutes ago  Up 3 minutes ago (healthy)  ironic_conductor
040e1ae3254e  ironic-api:2025.1            3 minutes ago  Up 3 minutes ago (healthy)  ironic_api
6a3956ff2c25  ironic-pxe:2025.1            3 minutes ago  Up 3 minutes ago            ironic_tftp
26f5c058b419  ironic-pxe:2025.1            3 minutes ago  Up 3 minutes ago (healthy)  ironic_http
be427175421b  dnsmasq:2025.1               3 minutes ago  Up 3 minutes ago            ironic_dnsmasq

相关组件的最终配置可以在 /etc/kolla 目录中找到，该目录只能用 root 权限访问：

kolla@bms:~$ sudo tree /etc/kolla/etc/kolla
├── cron
│   ├── config.json
│   └── logrotate.conf
├── ironic-api
│   ├── config.json
│   ├── ironic-api-wsgi.conf
│   └── ironic.conf
├── ironic-conductor
│   ├── config.json
│   └── ironic.conf
├── ironic-dnsmasq
│   ├── config.json
│   └── dnsmasq.conf
├── ironic-http
│   ├── config.json
│   ├── httpd.conf
│   ├── inspector.ipxe
│   ├── ironic-agent.initramfs
│   └── ironic-agent.kernel
├── ironic-tftp
│   └── config.json
├── kolla-toolbox
│   ├── config.json
│   ├── erl_inetrc
│   ├── rabbitmq-env.conf
│   └── rabbitmq-erlang.cookie
├── mariadb
│   ├── config.json
│   └── galera.cnf
├── mariadb-clustercheck
│   └── config.json
└── rabbitmq
    ├── advanced.config
    ├── config.json
    ├── definitions.json
    ├── enabled_plugins
    ├── erl_inetrc
    ├── rabbitmq.conf
    └── rabbitmq-env.conf
11 directories, 29 files

这包括默认的OpenStack Kolla配置，并结合了位于由$KOLLA_CONFIG_PATH变量标识的目录下 config文件夹中文件的特定变动。在本实验中，该目录是 /var/lib/kolla/etc/config，而默认情况下应为 /etc/kolla/config。

或者，托管自定义配置文件的目录可以在 globals.yml文件中通过设置 node_custom_config 变量来定义 。

注意：这些配置文件可以独立于部署过程，使用 kolla-ansible genconfig 命令生成。

要检查Ironic服务是否已启动并运行，我们可以直接使用命令 curl http://172.19.74.1:6385 | yq -y 查询 API：

name: OpenStack Ironic API
description: Ironic is an OpenStack project which enables the provision and management
  of baremetal machines.
default_version:
  id: v1
  links:
    - href: http://172.19.74.1:6385/v1/
      rel: self
  status: CURRENT
  min_version: '1.1'
  version: '1.96'
versions:
  - id: v1
    links:
      - href: http://172.19.74.1:6385/v1/
        rel: self
    status: CURRENT
    min_version: '1.1'
    version: '1.96'

我们再通过命令行测试一下客户端：

kolla@bms:~$ openstack \
  --os-endpoint=http://172.19.74.1:6385 \
  --os-auth-type=none \
  baremetal driver list
+---------------------+----------------+
| Supported driver(s) | Active host(s) |
+---------------------+----------------+
| ipmi                | bms            |
| redfish             | bms            |
+---------------------+----------------+
kolla@bms:~$ openstack \
  --os-endpoint=http://172.19.74.1:6385 \
  --os-auth-type=none \
  baremetal conductor list
+----------------+-----------------+-------+
| Hostname.      | Conductor Group | Alive |
+----------------+-----------------+-------+
| bms            |                 | True  |
+----------------+-----------------+-------+
kolla@bms:~$ openstack \
  --os-endpoint=http://172.19.74.1:6385 \
  --os-auth-type=none \
  baremetal conductor show bms
+-----------------+---------------------------+
| Field           | Value                     |
+-----------------+---------------------------+
| created_at      | 2025-03-31T17:50:26+00:00 |
| updated_at      | 2025-04-01T17:16:56+00:00 |
| hostname        | bms                       |
| conductor_group |                           |
| drivers         | ['ipmi', 'redfish']       |
| alive           | True                      |
+-----------------+---------------------------+

作为第二种选择，您可以用OS_ENDPOINT和OS_AUTH_TYPE环境变量替换 --os-endpoint 和 --auth-type 参数：

kolla@bms:~$ export OS_ENDPOINT=http://172.19.74.1:6385/
kolla@bms:~$ export OS_AUTH_TYPE=none
kolla@bms:~$ openstack baremetal driver show ipmi -f yaml | grep ^def
default_bios_interface: no-bios
default_boot_interface: ipxe
default_console_interface: no-console
default_deploy_interface: direct
default_firmware_interface: no-firmware
default_inspect_interface: agent
default_management_interface: ipmitool
default_network_interface: noop
default_power_interface: ipmitool
default_raid_interface: no-raid
default_rescue_interface: agent
default_storage_interface: noop
default_vendor_interface: ipmitool
kolla@bms:~$ openstack baremetal driver show redfish -f yaml | grep ^def
default_bios_interface: no-bios
default_boot_interface: ipxe
default_console_interface: no-console
default_deploy_interface: direct
default_firmware_interface: no-firmware
default_inspect_interface: agent
default_management_interface: redfish
default_network_interface: noop
default_power_interface: redfish
default_raid_interface: redfish
default_rescue_interface: agent
default_storage_interface: noop
default_vendor_interface: redfish

另外，OpenStack 客户端会按特定顺序在以下文件系统位置使用一个名为 clouds.yaml 的文件：

1. 当前目录

2. ~/.config/openstack目录

3. /etc/openstack目录

kolla@bms:~$ mkdir -p ~/.config/openstack
kolla@bms:~$ cat >~/.config/openstack/clouds.yaml <<-EOF 
clouds:
  ironic-standalone:
    endpoint: http://172.19.74.1:6385
    auth_type: none
EOF

注意：如果 clouds.yaml 文件中有多个配置，则必须使用 --os-cloud 命令行选项（例如，openstack --os-cloud=ironic …）或通过 OS_CLOUD 环境变量（例如，export OS_CLOUD=ironic）来指定相关条目。

如有相关问题，请在文章后面给小编留言，小编安排作者第一时间和您联系，为您答疑解惑。

未完待续…