Red Hat Training
A Red Hat training course is available for Red Hat OpenStack Platform
第 6 章 使用 CLI 工具配置基本的 overcloud
本章介绍了使用 CLI 工具配置 OpenStack 平台环境的基本步骤。overcloud 基本配置中不含任何自定义功能。但是,您可以按照 Advanced Overcloud Customization 指南中的说明,向这类基本 overcloud 添加高级配置选项,并按照您的具体规格进行自定义。
6.1. 为 overcloud 注册节点
director 需要一个节点定义模板,这个模板由您手动创建。此文件采用 JSON 或 YAML 格式,其中包含节点的详细硬件和电源管理信息。
步骤
创建一个模板来列出您的节点。例如,采用 JSON 格式的模板可能如下方所示:
{ "nodes":[ { "mac":[ "bb:bb:bb:bb:bb:bb" ], "name":"node01", "cpu":"4", "memory":"6144", "disk":"40", "arch":"x86_64", "pm_type":"ipmi", "pm_user":"admin", "pm_password":"p@55w0rd!", "pm_addr":"192.168.24.205" }, { "mac":[ "cc:cc:cc:cc:cc:cc" ], "name":"node02", "cpu":"4", "memory":"6144", "disk":"40", "arch":"x86_64", "pm_type":"ipmi", "pm_user":"admin", "pm_password":"p@55w0rd!", "pm_addr":"192.168.24.206" } ] }
或者,YAML 格式的类似节点模板可能如下方所示:
nodes: - mac: - "bb:bb:bb:bb:bb:bb" name: "node01" cpu: 4 memory: 6144 disk: 40 arch: "x86_64" pm_type: "ipmi" pm_user: "admin" pm_password: "p@55w0rd!" pm_addr: "192.168.24.205" - mac: - cc:cc:cc:cc:cc:cc name: "node02" cpu: 4 memory: 6144 disk: 40 arch: "x86_64" pm_type: "ipmi" pm_user: "admin" pm_password: "p@55w0rd!" pm_addr: "192.168.24.206"
这个模板使用以下属性:
- name
- 节点的逻辑名称。
- pm_type
要使用的电源管理驱动程序。本例中使用 IPMI 驱动程序 (
ipmi
),这是首选的电源管理驱动程序。注意IPMI 是首选的受支持电源管理驱动程序。如需更多受支持的电源管理类型及其选项,请参阅 附录 B, 电源管理驱动。如果这些电源管理驱动程序不能正常工作,请将 IPMI 用于电源管理。
- pm_user; pm_password
- IPMI 的用户名和密码。
- pm_addr
- IPMI 设备的 IP 地址。
- mac
- (可选)节点上网络接口的 MAC 地址列表。对于每个系统的 Provisioning NIC,只使用 MAC 地址。
- cpu
- 节点上的 CPU 数量。(可选)
- memory
- 以 MB 为单位的内存大小。(可选)
- disk
- 以 GB 为单位的硬盘的大小。(可选)
- arch
系统架构。(可选)
重要在构建多架构云时,
arch
键是必需的,用于区分使用x86_64
和ppc64le
架构的节点。
创建完模板后,将这个文件保存到
stack
用户的主目录 (/home/stack/nodes.json
),然后使用以下命令将其导入到 director:$ source ~/stackrc (undercloud) $ openstack overcloud node import ~/nodes.json
这会导入模板,并把模板中的每个节点注册到 director。
完成节点注册和配置之后,在 CLI 中查看这些节点的列表:
(undercloud) $ openstack baremetal node list
6.2. 检查节点的硬件
director 可以在每个节点上运行内省进程。这个进程会使每个节点通过 PXE 引导一个内省代理。这个代理从节点上收集硬件数据,并把信息发送回 director,director 把这些信息保存在运行于 director 上的 OpenStack Object Storage (swift) 服务中。director 使用硬件信息用于不同目的,如进行 profile tagging、benchmarking、手工引导磁盘分配等。
步骤
运行以下命令检查每个节点的属性:
(undercloud) $ openstack overcloud node introspect --all-manageable --provide
-
--all-manageable
选项仅内省处于受管理状态的节点。本例中为所有节点。 -
--provide
选项会在内省后将所有节点重置为available
状态。
-
在一个单独的终端窗口中运行以下命令来监测内省的进程:
(undercloud) $ sudo journalctl -l -u openstack-ironic-inspector -u openstack-ironic-inspector-dnsmasq -u openstack-ironic-conductor -f
重要确保这个过程成功完成。它可能需要 15 分钟来检查这些裸机节点。
-
内省完成后,所有节点都会变为
available
状态。
6.3. 为节点添加标签以加入到配置集
在注册并检查完每个节点的硬件后,需要为它们添加标签,加入特定的配置集。这些配置集标签会把节点和类型(flavor)相匹配,从而使类型分配到部署角色。下方的示例显示了 Controller 节点的角色、类型、配置集和节点之间的关系:
类型 | 描述 |
---|---|
角色 |
|
类型 |
|
配置集 |
|
节点 |
您也可以对单个节点应用 |
默认的配置文件类型 compute
、control
、swift-storage
、ceph-storage
和 block-storage
会在 undercloud 的安装过程中创建,多数环境中可不经修改直接使用。
步骤
为了通过添加标签把节点标记为特定的配置集,把
profile
选项添加到每个节点的properties/capabilities
参数中。例如,把环境中的两个节点分别标记为使用 controller 配置集和 compute 配置集,使用以下命令:(undercloud) $ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 58c3d07e-24f2-48a7-bbb6-6843f0e8ee13 (undercloud) $ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0
其中的
profile:compute
和profile:control
选项会把节点标记为相关的配置集。这些命令还设置
boot_option:local
参数,该参数用于定义每个节点的引导方式。在标记完节点后,检查分配的配置集或可能的配置集:
(undercloud) $ openstack overcloud profiles list
6.4. 设置 UEFI 引导模式
默认引导模式是传统 BIOS 模式。新式系统可能要求使用 UEFI 引导模式,而非传统 BIOS 模式。下列步骤可用来更改为 UEFI 模式。
步骤
在
undercloud.conf
文件中设置下列参数:ipxe_enabled = True inspection_enable_uefi = True
保存此文件并执行 undercloud 安装:
$ openstack undercloud install
等待安装脚本完成。
将每个注册节点的引导模式设置为
uefi
。例如,要在capabilities
属性中添加或替换现有的boot_mode
参数,可运行以下命令:$ NODE=<NODE NAME OR ID> ; openstack baremetal node set --property capabilities="boot_mode:uefi,$(openstack baremetal node show $NODE -f json -c properties | jq -r .properties.capabilities | sed "s/boot_mode:[^,]*,//g")" $NODE
注意检查是否保留了
profile
和boot_option
功能。+
$ openstack baremetal node show r530-12 -f json -c properties | jq -r .properties.capabilities
将各个类型的引导模式设为
uefi
:$ openstack flavor set --property capabilities:boot_mode='uefi' control
6.5. 为节点定义根磁盘
一些节点可能会使用多个磁盘。这意味着 director 需要识别在置备过程中作为根磁盘的磁盘。在置备过程中,director 将 QCOW2 overcloud-full
镜像写入到根磁盘。
以下几个属性可帮助 director 识别根磁盘:
-
model
(字符串):设备 ID。 -
vendor
(字符串):设备厂商。 -
serial
(字符串):磁盘序列号。 -
hctl
(字符串):SCSI 的 Host:Channel:Target:Lun。 -
size
(整数):设备的大小(以 GB 为单位)。 -
wwn
(字符串):唯一的存储 ID。 -
wwn_with_extension
(字符串):唯一存储 ID 附加厂商扩展名。 -
wwn_vendor_extension
(字符串):唯一厂商存储标识符。 -
rotational
(布尔值):旋转磁盘设备为 true (HDD),否则为 false (SSD)。 -
name
(字符串):设备名称,例如:/dev/sdb1。
只对有固定名称的设备才使用 name
。不要使用 name
来设置其他设备的根磁盘,因为此值在节点引导时可能会改变。
本例演示了如何使用序列号指定根设备。
步骤
通过对每个节点的硬盘执行内省,检查磁盘信息。以下命令显示了一个节点的磁盘信息:
(undercloud) $ openstack baremetal introspection data save 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0 | jq ".inventory.disks"
例如,一个节点的数据可能会显示 3 个磁盘:
[ { "size": 299439751168, "rotational": true, "vendor": "DELL", "name": "/dev/sda", "wwn_vendor_extension": "0x1ea4dcc412a9632b", "wwn_with_extension": "0x61866da04f3807001ea4dcc412a9632b", "model": "PERC H330 Mini", "wwn": "0x61866da04f380700", "serial": "61866da04f3807001ea4dcc412a9632b" } { "size": 299439751168, "rotational": true, "vendor": "DELL", "name": "/dev/sdb", "wwn_vendor_extension": "0x1ea4e13c12e36ad6", "wwn_with_extension": "0x61866da04f380d001ea4e13c12e36ad6", "model": "PERC H330 Mini", "wwn": "0x61866da04f380d00", "serial": "61866da04f380d001ea4e13c12e36ad6" } { "size": 299439751168, "rotational": true, "vendor": "DELL", "name": "/dev/sdc", "wwn_vendor_extension": "0x1ea4e31e121cfb45", "wwn_with_extension": "0x61866da04f37fc001ea4e31e121cfb45", "model": "PERC H330 Mini", "wwn": "0x61866da04f37fc00", "serial": "61866da04f37fc001ea4e31e121cfb45" } ]
本例演示了如何将根设备设置为磁盘 2,该磁盘的序列号为
61866da04f380d001ea4e13c12e36ad6
。这需要更改节点定义的root_device
参数:(undercloud) $ openstack baremetal node set --property root_device='{"serial": "61866da04f380d001ea4e13c12e36ad6"}' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0
注意把每个节点的 BIOS 配置为包括从所选 root 磁盘引导。推荐的引导顺序是:网络引导,然后是 root 磁盘引导。
6.6. 创建特定于架构的角色
在构建多云架构时,需要将特定于架构的角色添加到 roles_data.yaml
中。以下是一个同时包含 ComputePPC64LE
角色和默认角色的示例。如需与角色相关的信息,可参阅 Creating a Custom Role File 小节。
openstack overcloud roles generate \ --roles-path /usr/share/openstack-tripleo-heat-templates/roles -o ~/templates/roles_data.yaml \ Controller Compute ComputePPC64LE BlockStorage ObjectStorage CephStorage
6.7. 环境文件
undercloud 带有一组 Heat 模板,作为创建 overcloud 的方案。您可以使用环境文件来自定义 overcloud 的各个方面,这些文件是 YAML 格式的文件,其内容可覆盖核心 Heat 模板集合中的参数和资源。您可以根据需要纳入多个环境文件。但是,环境文件的顺序非常重要,因为后续环境文件中定义的参数和资源更为优先。以下列表是环境文件顺序的示例:
- 每个角色及其类型的节点数量。包含此信息对于创建 overcloud 至关重要。
- 容器化 OpenStack 服务的容器镜像位置。
-
任何网络隔离文件,首先是 heat 模板集合中的初始化文件 (
environments/network-isolation.yaml
),然后是您自定义的 NIC 配置文件,最后是任何额外的网络配置。 - 任何外部的负载平衡环境文件。
- 任何存储环境文件,如 Ceph Storage、NFS、iSCSI 等。
- 任何用于红帽 CDN 或 Satellite 注册的环境文件。
- 任何其它自定义环境文件。
建议将自定义环境文件放在一个单独目录中,比如 templates
目录。
您可以按照 Advanced Overcloud Customization 指南来自定义 overcloud 的高级功能。
一个基本的 overcloud 会使用本地 LVM 存储作为块存储,这种配置不受支持。建议您使用外部存储解决方案(如 Red Hat Ceph Storage)来实现块存储。
下面几节演示如何为您的 overcloud 创建所需环境。
6.8. 创建定义节点数目和类型的环境文件
默认情况下,director 部署具有 1 个 Controller 节点和 1 个 Compute 节点的 overcloud,节点的类型是 baremetal
。不过,这仅适用于概念验证部署。您可以通过指定不同的节点数目和类型来覆盖默认配置。对于小型生产环境,您可能要考虑至少 3 个 Controller 节点和 3 个 Compute 节点,并且分配特定的类型来确保使用适当的资源规格来创建节点。以下过程演示了如何创建名为 node-info.yaml
的环境文件,该文件用于存储节点数目和类型分配情况。
步骤
创建一个
node-info.yaml
文件,保存在/home/stack/templates/
目录下:(undercloud) $ touch /home/stack/templates/node-info.yaml
编辑这个文件,使其包含您需要的节点数目和类型。本例部署 3 个 Controller 节点、3 个 Compute 节点和 3 个Ceph Storage 节点。
parameter_defaults: OvercloudControllerFlavor: control OvercloudComputeFlavor: compute ControllerCount: 3 ComputeCount: 3
6.9. 创建 undercloud CA 信任的环境文件
如果您的 undercloud 使用 TLS 且其 CA 不是公共信任的,您需要遵照此过程操作。undercloud 运行自己的证书颁发机构 (CA) 来进行 SSL 端点加密。要让 undercloud 端点可被部署中的其余部分访问,请将 overcloud 配置为信任 undercloud CA。
为了让这种方法凑效,您的 overcloud 节点需要指向 undercloud 的公开端点的网络路径。依赖于脊叶型网络的部署可能需要应用这种配置。
undercloud 中可以使用两种类型的自定义证书:
-
用户提供的证书 - 当您自行提供证书时,会应用此定义。证书可能来自于您自己的 CA,也可能是自签名的。这通过使用
undercloud_service_certificate
选项来传递。在这种情形中,您需要信任自签名证书或者信任其 CA(取决于您的部署)。 -
自动生成的证书 - 当您通过
certmonger
生成使用自己的本地 CA 的证书时,会应用此定义。这通过generate_service_certificate
选项来启用。在这种情形中,会存在一个 CA 证书 (/etc/pki/ca-trust/source/anchors/cm-local-ca.pem
),以及供 undercloud 的 HAProxy 实例使用的服务器证书。要向 OpenStack 出示证书,您需要将 CA 添加到inject-trust-anchor-hiera.yaml
文件中。
步骤
本例中使用了位于 /home/stack/ca.crt.pem
的一个自签名证书。如果您使用自动生成的证书,请改为使用 /etc/pki/ca-trust/source/anchors/cm-local-ca.pem
。
打开证书文件,仅复制证书部分。不要包括其密钥:
$ vi /home/stack/ca.crt.pem
您需要的证书部分与下方简写的示例类似:
-----BEGIN CERTIFICATE----- MIIDlTCCAn2gAwIBAgIJAOnPtx2hHEhrMA0GCSqGSIb3DQEBCwUAMGExCzAJBgNV BAYTAlVTMQswCQYDVQQIDAJOQzEQMA4GA1UEBwwHUmFsZWlnaDEQMA4GA1UECgwH UmVkIEhhdDELMAkGA1UECwwCUUUxFDASBgNVBAMMCzE5Mi4xNjguMC4yMB4XDTE3 -----END CERTIFICATE-----
创建一个名为
/home/stack/inject-trust-anchor-hiera.yaml
的 YAML 文件,其包含下列内容以及您从 PEM 文件复制而来的证书:parameter_defaults: CAMap: ... undercloud-ca: content: | -----BEGIN CERTIFICATE----- MIIDlTCCAn2gAwIBAgIJAOnPtx2hHEhrMA0GCSqGSIb3DQEBCwUAMGExCzAJBgNV BAYTAlVTMQswCQYDVQQIDAJOQzEQMA4GA1UEBwwHUmFsZWlnaDEQMA4GA1UECgwH UmVkIEhhdDELMAkGA1UECwwCUUUxFDASBgNVBAMMCzE5Mi4xNjguMC4yMB4XDTE3 -----END CERTIFICATE-----
注意证书字符串必须采用 PEM 格式。
在 overcloud 部署期间,CA 证书会复制到各个 overcloud 节点,使它信任 undercloud 的 SSL 端点提供的加密。如需关于如何包含环境文件的更多信息,请参阅 第 6.12 节 “在 overcloud 部署中包括环境文件”。
6.10. 部署命令
创建 OpenStack 环境的最后一个环节是运行 openstack overcloud deploy
命令进行创建。在运行此命令前,您应当已经熟悉关键的选项,以及如何纳入自定义的环境文件。
不要以后台进程的形式运行 openstack overcloud deploy
,因为这可能会造成在 overcloud 的创建过程中出现进程无法继续的问题。
6.11. 部署命令选项
下表列出了 openstack overcloud deploy
命令的额外参数。
表 6.1. 部署命令选项
参数 | 描述 |
---|---|
|
包括在部署过程中使用的 Heat 模板的目录。如果为空,命令会使用位于 |
|
创建或更新的栈的名称 |
|
部署超时时间(分钟) |
|
hypervisor 使用的虚拟类型 |
|
网络时间协议 (NTP) 服务器用于同步时间。您也可以在逗号分隔列表中指定多个 NTP 服务器,例如: |
|
为环境变量 no_proxy 指定自定义值。这个环境变量被用来在代理通讯中排除特定的主机名。 |
|
定义访问 overcloud 节点的 SSH 用户。SSH 访问通常使用 |
|
传递给 overcloud 部署的额外环境文件。此参数可以指定多次。请注意,传递到 |
|
需要在部署中包括的环境文件所在的目录。这个命令会使用数字顺序而不是字母顺序处理这些环境文件。 |
|
overcloud 在创建过程中会执行一组部署前检查。如果部署前检查出现任何非严重错误,则此选项会退出创建。我们推荐使用此选项,因为任何错误都有可能造成部署失败。 |
|
overcloud 在创建过程中会执行一组部署前检查。如果部署前检查出现任何非关键警告,则此选项会退出创建。 |
|
对 overcloud 进行验证检查,但不实际创建 overcloud。 |
|
跳过 overcloud 部署后配置。 |
|
强制进行 overcloud 部署后配置。 |
|
跳过生成 |
|
到带有选项和参数的 YAML 文件的路径。 |
|
把 overcloud 节点注册到客户门户或 Satellite 6。 |
|
overcloud 节点的注册方法。 |
|
用于注册的组织。 |
|
强制注册系统(即使已经注册过)。 |
|
注册 overcloud 节点的 Satellite 服务器的基本 URL。此参数需要使用 Satellite 的 HTTP URL 而不是 HTTPS URL。例如,http://satellite.example.com,而不是 https://satellite.example.com。overcloud 的创建过程会使用此 URL 来确定服务器是 Red Hat Satellite 5 还是 Red Hat Satellite 6 服务器。如果是 Red Hat Satellite 6 服务器,overcloud 会获取 |
|
用于注册的激活码。 |
运行以下命令获得选项的完整列表:
(undercloud) $ openstack help overcloud deploy
某些命令行参数已过时或已弃用,它们的功能可以通过环境文件的 parameter_defaults
部分中所包含的 Heat 模板参数实现。下表将已弃用的参数与 Heat 模板中的等效参数对应了起来。
表 6.2. 将被弃用的 CLI 参数映射到 Heat 模板参数
参数 | 描述 | Heat 模板参数 |
---|---|---|
|
扩展的 Controller 节点数量 |
|
|
扩展的 Compute 节点数量 |
|
|
扩展的 Ceph 节点数量 |
|
|
扩展的 Cinder 节点数量 |
|
|
扩展的 Swift 节点数量 |
|
|
Controller 节点使用的 flavor |
|
|
Compute 节点使用的 flavor |
|
|
Ceph 节点使用的 flavor |
|
|
Cinder 节点使用的 flavor |
|
|
Swift 存储节点使用的 flavor |
|
|
定义在 neutron 插件中配置的平面网络。默认是 "datacentre",允许外部网络创建 |
|
|
在每个虚拟机管理器上创建的 Open vSwitch 网桥。默认值是 "br-ex",一般情况下不需要修改它 |
|
|
要使用的逻辑网络到物理网桥的映射。默认情况是把主机上的外部网桥(br-ex)映射到一个物理名(datacentre)。您可以使用它作为默认的浮动网络 |
|
|
定义网络节点的 br-ex 中的网桥接口 |
|
|
neutron 的租户网络类型 |
|
|
Neutron 租户网络的隧道类型。使用逗号分隔的字符串可以指定多个值 |
|
|
可以用来进行租户网络分配的 GRE 隧道 ID 的范围 |
|
|
可以用来进行租户网络分配的 VXLAN VNI ID 范围 |
|
|
支持的 Neutron ML2 和 Open vSwitch VLAN 映射范围。默认是在 datacentre 物理网络中允许任何 VLAN |
|
|
neutron 租户网络的机制驱动。默认值是 "openvswitch"。使用逗号分隔的字符串可以指定多个值 |
|
|
禁用隧道功能以在 Neutron 中使用 VLAN 分段网络或平面网络 |
无参数映射。 |
|
overcloud 在创建过程中会执行一组部署前检查。在使用这个选项时,如果部署前检查出现任何严重错误,则会退出创建。我们推荐使用此选项,因为任何错误都有可能造成部署失败。 |
未进行参数映射 |
这些参数计划从未来的 Red Hat OpenStack Platform 版本中移除。
6.12. 在 overcloud 部署中包括环境文件
使用 -e
来包含用于自定义 overcloud 的环境文件。您可以根据需要包含多个环境文件。但是,环境文件的顺序非常重要,后续环境文件中定义的参数和资源会覆盖前面环境文件中定义的相同参数和资源。下表是环境文件顺序的一个示例:
- 每个角色及其类型的节点数量。包含此信息对于创建 overcloud 至关重要。
- 容器化 OpenStack 服务的容器镜像位置。
-
任何网络隔离文件,首先是 heat 模板集合中的初始化文件 (
environments/network-isolation.yaml
),然后是您自定义的 NIC 配置文件,最后是任何额外的网络配置。 - 任何外部的负载平衡环境文件。
- 任何存储环境文件,如 Ceph Storage、NFS、iSCSI 等。
- 任何用于红帽 CDN 或 Satellite 注册的环境文件。
- 任何其它自定义环境文件。
使用 -e
选项添加的所有环境文件都会成为 overcloud 栈定义的一部分。
下例中的命令演示如何使用此场景中早前定义的环境文件来启动 overcloud 创建过程:
(undercloud) $ openstack overcloud deploy --templates \ -e /home/stack/templates/node-info.yaml\ -e /home/stack/templates/overcloud_images.yaml \ -e /home/stack/inject-trust-anchor-hiera.yaml -r /home/stack/templates/roles_data.yaml \
这个命令包括以下的额外选项:
- --templates
-
以
/usr/share/openstack-tripleo-heat-templates
中的 Heat 模板集合为基础来创建 overcloud - -e /home/stack/templates/node-info.yaml
- 添加环境文件以定义每种角色有多少个节点以及使用哪些类型。
- -e /home/stack/templates/overcloud_images.yaml
- 添加包含容器镜像源的环境文件。
- -e /home/stack/inject-trust-anchor-hiera.yaml
- 添加用于在 undercloud 中安装自定义证书的环境文件。
- -r /home/stack/templates/roles_data.yaml
- (可选)如果使用自定义角色或启用多架构云,这是生成的角色数据。如需更多信息,请参阅 第 6.6 节 “创建特定于架构的角色”。
director 需要这些环境文件来进行重新部署并使用部署后的功能(请参阅 第 9 章 创建 overcloud 后执行的任务)。没有正确包含这些文件可能会破坏您的 overcloud。
如果计划在以后修改 overcloud 配置,您应该:
- 修改定制环境文件和 Heat 模板中的参数
-
使用相同的环境文件再次运行
openstack overcloud deploy
命令
不要直接编辑 overcloud 的配置,因为在使用 director 对 overcloud 栈进行更新时,这种手动配置会被 director 的配置覆盖。
6.13. 在部署前验证 overcloud 配置
在执行 overcloud 部署操作前,先验证您的 Heat 模板和环境文件,确认是否存在任何错误。
步骤
overcloud 的 Heat 核心模板采用 Jinja2 格式。要验证您的模板,请使用以下命令呈现未采用 Jinja2 格式的版本:
$ cd /usr/share/openstack-tripleo-heat-templates $ ./tools/process-templates.py -o ~/overcloud-validation
使用下列命令来验证模板语法:
(undercloud) $ openstack orchestration template validate --show-nested \ --template ~/overcloud-validation/overcloud.yaml -e ~/overcloud-validation/overcloud-resource-registry-puppet.yaml \ -e [ENVIRONMENT FILE] \ -e [ENVIRONMENT FILE]
验证过程需要
overcloud-resource-registry-puppet.yaml
环境文件包括针对于 overcloud 的资源。使用-e
选项为这个命令添加其他额外的环境文件。此外,还需包含--show-nested
选项,以解析来自嵌套模板的参数。- 此命令可以识别模板中的任何语法错误。如果模板语法验证成功,输出会显示生成的 overcloud 模板的预览。
6.14. Overcloud 部署输出
一旦 overcloud 创建完毕,director 会提供为配置 overcloud 而执行的 Ansible play 的总结:
PLAY RECAP ************************************************************* overcloud-compute-0 : ok=160 changed=67 unreachable=0 failed=0 overcloud-controller-0 : ok=210 changed=93 unreachable=0 failed=0 undercloud : ok=10 changed=7 unreachable=0 failed=0 Tuesday 15 October 2018 18:30:57 +1000 (0:00:00.107) 1:06:37.514 ****** ========================================================================
director 还会提供用于访问 overcloud 的详细信息。
Ansible passed. Overcloud configuration completed. Overcloud Endpoint: http://192.168.24.113:5000 Overcloud Horizon Dashboard URL: http://192.168.24.113:80/dashboard Overcloud rc file: /home/stack/overcloudrc Overcloud Deployed
6.15. 访问 overcloud
director 会生成脚本来配置和帮助认证 director 主机与 overcloud 的交互。director 将此文件保存为 stack
用户主目录的 overcloudrc
文件。运行以下命令来使用此文件:
(undercloud) $ source ~/overcloudrc
这会加载所需的环境变量,以便通过 director 主机的 CLI 与 overcloud 进行交互。命令提示符的变化会显示当前状态:
(overcloud) $
要返回与 director 主机进行交互的状态,运行以下命令:
(overcloud) $ source ~/stackrc (undercloud) $
overcloud 中的每个节点还会包括一个名为 heat-admin
的用户。stack
用户有到每个节点上的此用户的 SSH 访问权限。要通过 SSH 访问某一节点,可查找相关节点的 IP 地址:
(undercloud) $ openstack server list
使用 heat-admin
用户和节点的 IP 地址连接到节点:
(undercloud) $ ssh heat-admin@192.168.24.23
6.16. 后续步骤
使用命令行工具创建 overcloud 的步骤到此结束。有关创建后的功能,请参阅第 9 章 创建 overcloud 后执行的任务。