OpenStack Ironic 獨立部署入門詳解

作者：祝祥 2025-08-20 08:07:29

想在云環境中像管理虛擬機（VM）一樣管理物理服務器嗎？想在物理節點上實現基礎設施即代碼（IaC）和 CI/CD 流水線嗎？

想在云環境中像管理虛擬機（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 管理的是物理硬件本身，它直接在機器上安裝操作系統，沒有任何中間的虛擬化層。

管理裸金屬生命周期

傳統上，管理裸金屬服務器的生命周期是一個包含多個階段的過程，通常是手動的且非常耗時：

采購與物理安裝：接收、上架、布線。
BIOS/UEFI 配置：手動進入、進行特定設置。
RAID 控制器配置：創建陣列、配置磁盤。
操作系統安裝：從 CD/USB/PXE 啟動，手動或半自動安裝。
安裝后配置：驅動、軟件、網絡、安全加固。
維護與更新：打補丁、升級固件。
回收：擦除磁盤、移除設備。

有了 Ironic，整個過程發生了轉變，我們就實現了“as-a-Service”的管理方式：

發現與注冊（Onboarding）：Ironic 通過 PXE 啟動和代理“發現”機器，并將其注冊到其清單中。注冊后，Ironic 可以直接與其 BMC（管理控制器，如 iLO、iDRAC、IMM）進行交互。
“As-a-Service”式配置：用戶（或自動化服務）可以通過 OpenStack API 請求一臺具有特定特性（CPU、RAM、存儲）的物理服務器。Ironic 會選擇一臺可用的服務器，打開電源，安裝所選的操作系統（GNU/Linux、Windows、VMware ESXi 等），配置網絡，并在短時間內使其可用。
遠程自動化管理：得益于與 BMC 的集成，Ironic 可以通過程序方式執行諸如開/關機、重啟、重置、引導設備管理、固件更新（通過插件）甚至 BIOS/UEFI 設置等操作，所有這些都無需任何手動干預。
回收與清理：當不再需要某臺服務器時，Ironic 可以執行安全磁盤擦除并重置 BIOS/UEFI 設置，使服務器恢復到“干凈”狀態，可供重用或最終回收，整個過程完全自動化。
與其他 OpenStack 服務集成：最后但同樣重要的是，Ironic 可以與用于物理網絡管理的 Neutron、用于操作系統鏡像管理的 Glance、用于提供持久性存儲的 Cinder 以及用于提供統一圖形界面的 Horizon 集成。這使得構建復雜的解決方案成為可能，其中裸金屬是云基礎設施的延伸，不僅可以實現資源的“即服務”消費，還可以實現像 CI/CD 流水線這樣的自動化交互。

1.實驗環境

讓我們考慮一個簡化的環境，這樣我們就可以用最少的精力來搭建它，并主要關注裸金屬配置機制：

圖片

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”基礎設施保持一致。

2.創建實驗環境

安裝 bms 服務器；
安裝 Podman 容器管理系統；
創建 kolla 管理用戶；
創建 Python 虛擬環境；
安裝 OpenStack Kolla Ansible；
為裸金屬配置進行最小化配置；

部署 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 <<EOF
# 激活 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 <<EOF
# 加載本地 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 <<EOF
# Kolla Ansible 默認配置路徑
export KOLLA_CONFIG_PATH=~/etc
EOF
kolla@bms:~$ cp -a ~/share/kolla-ansible/etc_examples/kolla $KOLLA_CONFIG_PATH
kolla@bms:~$ kolla-genpwd --passwords $KOLLA_CONFIG_PATH/passwords.yml
kolla@bms:~$ mkdir -p $KOLLA_CONFIG_PATH/ansible/inventory
kolla@bms:~$ ln -s ~/share/kolla-ansible/ansible/inventory/all-in-one $KOLLA_CONFIG_PATH/ansible/inventory/

同時，我們將用一個最小化版本替換 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 <<EOF
[defaults]
stdout_callback = yaml
EOF

為了驗證一切是否正確，讓我們運行 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 文件包含以下幾行：

...<SNIP>...
enable_openstack_core: false
enable_ironic: true
...<SNIP>...

enable_openstack_core: false 選項禁用了所有本應由 Kolla Ansible 自動安裝的組件，包括 Keystone、Glance、Nova、Neutron、Heat 和 Horizon。相反，enable_ironic: true 只啟用了 Ironic。

2.7 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.8 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 的文件：

當前目錄
~/.config/openstack 目錄
/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）來指定相關條目。

責任編輯：武曉燕來源：新鈦云服

OpenStack VM 云環境