第 1 章 Image 服务(glance)
管理 Red Hat OpenStack Platform(RHOSP)中的镜像和存储。
虚拟机镜像是一个文件,其中包含安装可引导操作系统的虚拟磁盘。支持不同格式的虚拟机镜像。RHOSP 中提供了以下格式:
-
RAW
- 非结构化磁盘镜像格式。 -
QCOW2
- QEMU 模拟器支持的磁盘格式。此格式包括 QCOW2v3(有时称为 QCOW3),它要求 QEMU 1.1 或更高版本。 -
ISO
- 磁盘上的数据扇区副本,保存在二进制文件中。 -
AKI
- 指示 Amazon 内核镜像. -
AMI
- 指示 Amazon 机器镜像。 -
ARI
- 禁止 Amazon RAMDisk 镜像。 -
VDI
- VirtualBox 虚拟机显示器和 QEMU 模拟器支持的磁盘格式。 -
VHD
- 来自 VMware、VirtualBox 和其他虚拟机监控器所使用的通用磁盘格式。 -
PLOOP
- Virtuozzo 支持并使用磁盘格式来运行 OS 容器。 -
OVA
- 表示存储在镜像服务(glance)中的内容是一个 OVA tar 存档文件。 -
DOCKER
- 表示存储在镜像服务(glance)中的内容是容器文件系统的 Docker tar 存档。
虽然 ISO
通常不被视为虚拟机镜像格式,因为 ISO 包含带有安装操作系统的可引导文件系统,但使用它们的方式与其他虚拟机镜像文件相同。
要下载官方的 Red Hat Enterprise Linux 云镜像,您的帐户必须具有有效的 Red Hat Enterprise Linux 订阅:
如果您没有登录到客户门户网站,则会打开一个提示,其中必须输入您的红帽帐户凭证。
1.1. 了解镜像服务
Red Hat OpenStack Platform(RHOSP)镜像服务(glance)功能。
1.1.1. 支持的镜像服务后端
支持以下镜像服务(glance)后端场景:
- 使用 Ceph 时,RBD 是默认后端。有关更多信息,请参阅高级 Overcloud 自定义指南中的 配置 Ceph 存储。
- RBD 多存储.更多信息请参阅 第 2.1 节 “存储边缘架构要求”。
Object Storage(swift)。有关更多信息,请参阅高级 Overcloud 自定义指南中的使用外部 Object Storage 集群。
镜像服务使用 Object Storage 类型和后端作为默认值。
- 块存储(cinder)。有关更多信息,请参阅高级 Overcloud 自定义指南中的为镜像服务配置 Cinder 后端。
NFS.如需更多信息,请参阅高级 Overcloud 自定义指南中的 配置 NFS 存储。
- 重要的
虽然 NFS 是受支持的镜像服务部署选项,但提供更多可靠的选项。
NFS 对镜像服务不是原生的。当您在镜像服务上挂载 NFS 共享时,镜像服务不会管理这个操作。镜像服务将数据写入文件系统,但不知道后端是一个 NFS 共享。
在这种类型的部署中,如果共享失败,镜像服务将无法重试请求。这意味着,当后端出现失败时,存储可能会进入只读模式,或者可能会继续将数据写入本地文件系统中,在这种情况下,您会面临数据丢失。要从这种情况中恢复,您必须确保共享已挂载并保持同步,然后重新启动镜像服务。因此,红帽不推荐将 NFS 用作镜像服务后端。
但是,如果您选择使用 NFS 作为镜像服务后端,则以下最佳实践可帮助降低风险:
- 使用可靠的生产级 NFS 后端。
- 确保您在 Controller 节点和 NFS 后端之间有强大且可靠的连接:第 2 层(L2)网络连接。
- 包含挂载共享的监控和警报。
- 设置底层文件系统权限。写入权限必须存在于您用作存储的共享文件系统中。
- 确保在 上运行的用户和组 glance-api 进程在挂载点上没有本地文件系统的写入权限。这意味着,进程可以检测可能的挂载失败,并在写入尝试时将存储置于只读模式。
1.1.2. 镜像签名和验证
镜像签名和验证通过启用部署器对镜像进行签名并将签名和公钥证书保存为镜像属性,从而保护镜像的完整性和真实性。
通过利用此功能,您可以执行这些任务:
- 使用您的私钥为镜像签名并上传镜像、签名以及对公钥证书(验证元数据)的引用。然后,镜像服务验证签名是否有效。
- 在 Compute 服务中创建镜像,使 Compute 服务为镜像签名,并上传镜像并验证元数据。镜像服务再次验证签名是否有效。
- 在 Compute 服务中请求已签名的镜像。镜像服务提供镜像及其验证元数据,允许计算服务在引导镜像前验证镜像。
有关镜像签名和验证的详情,请参考使用 OpenStack Key Manager 管理 Secret 中的 验证镜像服务(glance)镜像。
1.1.3. 镜像转换
镜像转换通过在导入镜像时调用任务 API 来转换镜像。
作为导入工作流的一部分,插件提供镜像转换。可根据部署器配置激活或取消激活此插件。因此,部署器需要为部署指定首选镜像格式。
在内部,镜像服务以特定格式接收镜像的位。这些位存储在临时位置。然后,触发插件将镜像转换为目标格式并移到最终目的地。任务完成后,会删除临时位置。因此,初始上传的格式不会被镜像服务保留。
有关镜像转换的更多信息,请参阅 第 1.2.8 节 “启用镜像转换”
只有在导入镜像时才能触发转换。上传镜像时不会运行它。例如:
$ glance image-create-via-import \ --disk-format qcow2 \ --container-format bare \ --name NAME \ --visibility public \ --import-method web-download \ --uri http://server/image.qcow2
1.1.4. 可互操作的镜像导入
可互操作的镜像导入工作流可让您以两种方式导入镜像:
-
使用
web-download
(默认)方法从 URI 导入镜像。 -
使用
glance-direct
方法从本地文件系统中导入镜像。
1.1.5. 通过镜像服务缓存提高可扩展性
使用 glance-api 缓存机制在镜像服务(glance)API 服务器上存储镜像副本,并自动检索它们来提高可扩展性。通过镜像服务缓存,glance-api 可以在多个主机上运行。这意味着不需要多次从后端存储检索同一镜像。镜像服务缓存不会影响任何镜像服务操作。
使用 Red Hat OpenStack Platform director(tripleo)heat 模板配置镜像服务缓存:
流程
在环境文件中,将
GlanceCacheEnabled
参数的值设置为true
,这将在glance-api.conf
heat 模板中自动将flavor
值设置为keystone+cachemanagement
:parameter_defaults: GlanceCacheEnabled: true
-
在重新部署 overcloud 时,将环境文件包含到
openstack overcloud deploy
命令中。 可选:在重新部署 overcloud 时,对
glance_cache_pruner
进行微调。以下示例显示了 5 分钟的频率:parameter_defaults: ControllerExtraConfig: glance::cache::pruner::minute: '*/5'
根据您的需要调整频率,以避免文件系统完整场景。选择替代频率时包含以下元素:
- 要在环境中缓存的文件大小。
- 可用文件系统空间量。
- 环境缓存镜像的频率。
1.1.6. 镜像预缓存
Red Hat OpenStack Platform(RHOSP)director 可以预缓存镜像作为 glance-api
服务的一部分。
1.1.6.1. 为定期镜像预缓存配置默认间隔
镜像预缓存的默认定期间隔为 300 秒。您可以根据您的要求增加或减少默认间隔。
流程
根据您的要求,在 undercloud 上的环境文件中使用
ExtraConfig
参数添加新间隔:parameter_defaults: ControllerExtraConfig: glance::config::glance_api_config: DEFAULT/cache_prefetcher_interval: value: '<300>'
将 <300> 替换为您要作为预缓存镜像的间隔的秒数。
在调整
/home/stack/templates/
中的环境文件中的间隔后,以stack
用户身份登录并部署配置:$ openstack overcloud deploy --templates \ -e /home/stack/templates/<env_file>.yaml
将 <env_file> 替换为包含您添加的
ExtraConfig
设置的环境文件名称。重要如果您在创建 overcloud 时传递任何额外的环境文件,请使用
-e
选项再次传递这些文件,以避免对 overcloud 进行不必要的更改。
有关 openstack overcloud deploy
命令的更多信息,请参阅 Director 安装和使用 指南中的 部署命令。
1.1.6.2. 使用定期作业来预缓存镜像
先决条件
要使用定期作业来预缓存镜像,您必须使用 glance-cache-manage
命令直接连接到运行 glance_api
服务的节点。不要使用代理,它将隐藏回答服务请求的节点。由于 undercloud 可能无法访问运行 glance_api
服务的网络,因此在第一个 overcloud 节点上运行命令(默认为 controller-0
)。
完成以下先决条件步骤,以确保从正确的主机运行命令,具有必要的凭据,并且也从 glance-api
容器内运行 glance-cache-manage
命令。
流程
以 stack 用户身份登录 undercloud,再识别
controller-0
的调配 IP 地址:(undercloud) [stack@site-undercloud-0 ~]$ openstack server list -f value -c Name -c Networks | grep controller overcloud-controller-1 ctlplane=192.168.24.40 overcloud-controller-2 ctlplane=192.168.24.13 overcloud-controller-0 ctlplane=192.168.24.71 (undercloud) [stack@site-undercloud-0 ~]$
要对 overcloud 进行身份验证,默认将存储在
/home/stack/overcloudrc
中的凭证复制到controller-0
:$ scp ~/overcloudrc heat-admin@192.168.24.71:/home/heat-admin/
连接到
controller-0
:$ ssh heat-admin@192.168.24.71
在
controller-0
上,以heat-admin
用户身份识别glance_api 服务的
IP 地址。在以下示例中,IP 地址是172.25.1.105
:(overcloud) [root@controller-0 ~]# grep -A 10 '^listen glance_api' /var/lib/config-data/puppet-generated/haproxy/etc/haproxy/haproxy.cfg listen glance_api server central-controller0-0.internalapi.redhat.local 172.25.1.105:9292 check fall 5 inter 2000 rise 2
由于
glance-cache-manage
命令只能在glance_api
容器中可用,因此创建一个脚本,以执行要向 overcloud 进行身份验证的环境变量的节点。在controller-0
上的/home/heat-admin
中创建一个名为glance_pod.sh
的脚本,其内容如下:sudo podman exec -ti \ -e NOVA_VERSION=$NOVA_VERSION \ -e COMPUTE_API_VERSION=$COMPUTE_API_VERSION \ -e OS_USERNAME=$OS_USERNAME \ -e OS_PROJECT_NAME=$OS_PROJECT_NAME \ -e OS_USER_DOMAIN_NAME=$OS_USER_DOMAIN_NAME \ -e OS_PROJECT_DOMAIN_NAME=$OS_PROJECT_DOMAIN_NAME \ -e OS_NO_CACHE=$OS_NO_CACHE \ -e OS_CLOUDNAME=$OS_CLOUDNAME \ -e no_proxy=$no_proxy \ -e OS_AUTH_TYPE=$OS_AUTH_TYPE \ -e OS_PASSWORD=$OS_PASSWORD \ -e OS_AUTH_URL=$OS_AUTH_URL \ -e OS_IDENTITY_API_VERSION=$OS_IDENTITY_API_VERSION \ -e OS_COMPUTE_API_VERSION=$OS_COMPUTE_API_VERSION \ -e OS_IMAGE_API_VERSION=$OS_IMAGE_API_VERSION \ -e OS_VOLUME_API_VERSION=$OS_VOLUME_API_VERSION \ -e OS_REGION_NAME=$OS_REGION_NAME \ glance_api /bin/bash
Source
overcloudrc
文件,运行glance_pod.sh
脚本,以使用必要的环境变量在glance_api
中执行以在 overcloud Controller 节点中进行身份验证。[heat-admin@controller-0 ~]$ source overcloudrc (overcloudrc) [heat-admin@central-controller-0 ~]$ bash glance_pod.sh ()[glance@controller-0 /]$
使用
glance image-list
等命令来验证容器是否可以针对 overcloud 运行经过身份验证的命令。()[glance@controller-0 /]$ glance image-list +--------------------------------------+----------------------------------+ | ID | Name | +--------------------------------------+----------------------------------+ | ad2f8daf-56f3-4e10-b5dc-d28d3a81f659 | cirros-0.4.0-x86_64-disk.img | +--------------------------------------+----------------------------------+ ()[glance@controller-0 /]$
流程
以 admin 用户身份,将镜像队列为缓存:
$ glance-cache-manage --host=<host_ip> queue-image <image_id>
-
将 <host_ip> 替换为运行
glance-api
容器的 Controller 节点的 IP 地址。 将 <image_id> 替换为您要队列的镜像的 ID。
当您排队要预缓存的镜像时,
cache_images
定期作业会同时列出所有排队的镜像。注意由于镜像缓存是每个节点的本地缓存,如果使用 HA(有 3、5 或 7 控制器)部署 Red Hat OpenStack Platform,那么在您运行
glance-cache-manage
命令时,您必须使用--host
选项指定主机地址。
-
将 <host_ip> 替换为运行
运行以下命令,以查看镜像缓存中的镜像:
$ glance-cache-manage --host=<host_ip> list-cached
将 <host_ip> 替换为环境中主机的 IP 地址。
相关信息
您可以对以下目的使用额外的 glance-cache-manage
命令:
-
list-cached
,列出当前缓存的所有镜像。 -
list-queued
,列出当前排队以缓存的所有镜像。 -
queue-image
以将镜像队列用于缓存。 -
delete-cached-image
从缓存中清除镜像。 -
delete-all-cached-images
从缓存中移除所有镜像。 -
delete-queued-image
从缓存队列中删除镜像。 -
删除-all-queued-images
,从缓存队列中删除所有镜像。
1.1.7. 使用镜像服务 API 启用稀疏镜像上传
使用镜像服务(glance)API,您可以使用稀疏镜像上传来减少网络流量并保存存储空间。此功能在分布式 Compute 节点 (DCN) 环境中特别有用。使用稀疏镜像文件,镜像服务不会写入 null 字节序列。镜像服务使用给定偏移写入数据。存储后端将这些偏移解析为不实际消耗存储空间的 null 字节。
限制
- 仅 Ceph RBD 支持稀疏镜像上传。
- 文件系统不支持稀疏镜像上传。
- 在客户端和镜像服务 API 间传输过程中不会维护 Sparseness。在镜像服务 API 级别中,该镜像是稀疏的。
先决条件
- 您的 Red Hat OpenStack Platform(RHOSP)部署使用 RBD 作为镜像服务后端。
流程
-
以
stack
用户身份登录 undercloud 节点。 查找
stackrc
凭证文件:$ source stackrc
使用以下内容创建环境文件:
parameter_defaults: GlanceSparseUploadEnabled: true
使用其他环境文件将新环境文件添加到堆栈中并部署 overcloud:
$ openstack overcloud deploy \ --templates \ … -e <existing_overcloud_environment_files> \ -e <new_environment_file>.yaml \ …
有关上传镜像的更多信息,请参阅 第 1.2.2 节 “上传镜像”。
验证
您可以导入镜像并检查其大小来验证稀疏镜像上传。
在本地下载镜像文件:
$ wget <file_location>/<file_name>
将
<file_location
> 替换为文件的位置。将<file_name
> 替换为文件的名称。以下流程使用示例命令。在适当的环境中,将值替换为您环境中的值。
$ wget https://cloud.centos.org/centos/6/images/CentOS-6-x86_64-GenericCloud-1508.qcow2
检查您要上传的镜像的磁盘大小和虚拟大小:
qemu-img info <file_name>
以下流程使用示例命令。在适当的环境中,将值替换为您环境中的值。
$ qemu-img info CentOS-6-x86_64-GenericCloud-1508.qcow2 image: CentOS-6-x86_64-GenericCloud-1508.qcow2 file format: qcow2 virtual size: 8 GiB (8589934592 bytes) disk size: 1.09 GiB cluster_size: 65536 Format specific information: compat: 0.10 refcount bits: 1
导入镜像:
$ glance image-create-via-import --disk-format qcow2 --container-format bare --name centos_1 --file <file_name>
- 记录镜像 ID。后续步骤中需要用到它。
验证镜像是否已导入并处于 active 状态:
$ openstack image show <image_id>
在 Ceph Storage 节点上,验证镜像的大小是否小于第 1 步输出中的虚拟大小:
$ sudo rbd -p images diff <image_id> | awk '{ SUM += $2 } END { print SUM/1024/1024/1024 " GB" }' 1.03906 GB
可选:您可以确认在 Controller 节点上的 glance 配置文件中配置了
rbd_thin_provisioning
:使用 SSH 访问 Controller 节点:
$ ssh -A -t heat-admin@<controller_node_IP_address>
确认该 Controller 节点上的
rbd_thin_provisioning
等于True
:$ sudo podman exec -it glance_api sh -c 'grep ^rbd_thin_provisioning /etc/glance/glance-api.conf'
1.1.8. 安全 metadef API
在 Red Hat OpenStack Platform(RHOSP)中,用户可以通过元数据定义(metadef)API 定义键值对和标签元数据。目前,用户可以创建的元命名空间、对象、属性、资源或标签数量没有限制。
Metadef API 可能会向未经授权的用户泄漏信息。恶意用户可以利用缺乏限制并填充镜像服务(glance)数据库,且带有无限资源,这可以创建一个服务(DoS)风格的攻击。
镜像服务策略控制 metadef API。但是,metadef API 的默认策略设置可让所有用户创建或读取 metadef 信息。由于潜在的敏感名称(如内部基础架构详情或客户名称)无法隔离元数据,因此元数据资源不会将信息暴露给恶意用户。
1.1.8.1. 配置策略来限制 metadef API
要使镜像服务(glance)更安全,请在 Red Hat OpenStack Platform(RHOSP)部署中默认将 metadef 修改 API 限制为仅限管理员访问。
流程
作为云管理员,创建单独的 heat 模板文件,如
lock-down-glance-metadef-api.yaml
,使其包含镜像服务 metadef API 的策略覆盖:... parameter_defaults: GlanceApiPolicies: { glance-metadef_default: { key: 'metadef_default', value: '' }, glance-metadef_admin: { key: 'metadef_admin', value: 'role:admin' }, glance-get_metadef_namespace: { key: 'get_metadef_namespace', value: 'rule:metadef_default' }, glance-get_metadef_namespaces: { key: 'get_metadef_namespaces', value: 'rule:metadef_default' }, glance-modify_metadef_namespace: { key: 'modify_metadef_namespace', value: 'rule:metadef_admin' }, glance-add_metadef_namespace: { key: 'add_metadef_namespace', value: 'rule:metadef_admin' }, glance-delete_metadef_namespace: { key: 'delete_metadef_namespace', value: 'rule:metadef_admin' }, glance-get_metadef_object: { key: 'get_metadef_object', value: 'rule:metadef_default' }, glance-get_metadef_objects: { key: 'get_metadef_objects', value: 'rule:metadef_default' }, glance-modify_metadef_object: { key: 'modify_metadef_object', value: 'rule:metadef_admin' }, glance-add_metadef_object: { key: 'add_metadef_object', value: 'rule:metadef_admin' }, glance-delete_metadef_object: { key: 'delete_metadef_object', value: 'rule:metadef_admin' }, glance-list_metadef_resource_types: { key: 'list_metadef_resource_types', value: 'rule:metadef_default' }, glance-get_metadef_resource_type: { key: 'get_metadef_resource_type', value: 'rule:metadef_default' }, glance-add_metadef_resource_type_association: { key: 'add_metadef_resource_type_association', value: 'rule:metadef_admin' }, glance-remove_metadef_resource_type_association: { key: 'remove_metadef_resource_type_association', value: 'rule:metadef_admin' }, glance-get_metadef_property: { key: 'get_metadef_property', value: 'rule:metadef_default' }, glance-get_metadef_properties: { key: 'get_metadef_properties', value: 'rule:metadef_default' }, glance-modify_metadef_property: { key: 'modify_metadef_property', value: 'rule:metadef_admin' }, glance-add_metadef_property: { key: 'add_metadef_property', value: 'rule:metadef_admin' }, glance-remove_metadef_property: { key: 'remove_metadef_property', value: 'rule:metadef_admin' }, glance-get_metadef_tag: { key: 'get_metadef_tag', value: 'rule:metadef_default' }, glance-get_metadef_tags: { key: 'get_metadef_tags', value: 'rule:metadef_default' }, glance-modify_metadef_tag: { key: 'modify_metadef_tag', value: 'rule:metadef_admin' }, glance-add_metadef_tag: { key: 'add_metadef_tag', value: 'rule:metadef_admin' }, glance-add_metadef_tags: { key: 'add_metadef_tags', value: 'rule:metadef_admin' }, glance-delete_metadef_tag: { key: 'delete_metadef_tag', value: 'rule:metadef_admin' }, glance-delete_metadef_tags: { key: 'delete_metadef_tags', value: 'rule:metadef_admin' } } …
有关策略和策略语法的详情,请参考此策略 章节。
在部署 overcloud 时,使用
-e
选项包括部署命令中包含策略覆盖的环境文件:$ openstack overcloud deploy -e lock-down-glance-metadef-api.yaml
1.1.8.2. 启用 metadef API
如果您之前限制的元数据定义(metadef)API,或希望重新放置新的默认值,您可以覆盖修改策略,以允许用户更新其各自资源。
具有依赖于对 metadef API 的写入访问权限的云管理员可能会导致所有用户访问这些 API。然而,在这种配置中,可能会意外泄漏敏感资源名称,如客户名称和内部项目。管理员必须审核其系统,以识别之前创建的资源,即使所有用户启用了读取访问权限也是如此。
流程
作为云管理员,登录 undercloud 并为策略覆盖创建一个文件。例如:
$ cat open-up-glance-api-metadef.yaml
配置策略覆盖文件,允许所有用户进行 metadef API 读写访问:
GlanceApiPolicies: { glance-metadef_default: { key: 'metadef_default', value: '' }, glance-get_metadef_namespace: { key: 'get_metadef_namespace', value: 'rule:metadef_default' }, glance-get_metadef_namespaces: { key: 'get_metadef_namespaces', value: 'rule:metadef_default' }, glance-modify_metadef_namespace: { key: 'modify_metadef_namespace', value: 'rule:metadef_default' }, glance-add_metadef_namespace: { key: 'add_metadef_namespace', value: 'rule:metadef_default' }, glance-delete_metadef_namespace: { key: 'delete_metadef_namespace', value: 'rule:metadef_default' }, glance-get_metadef_object: { key: 'get_metadef_object', value: 'rule:metadef_default' }, glance-get_metadef_objects: { key: 'get_metadef_objects', value: 'rule:metadef_default' }, glance-modify_metadef_object: { key: 'modify_metadef_object', value: 'rule:metadef_default' }, glance-add_metadef_object: { key: 'add_metadef_object', value: 'rule:metadef_default' }, glance-delete_metadef_object: { key: 'delete_metadef_object', value: 'rule:metadef_default' }, glance-list_metadef_resource_types: { key: 'list_metadef_resource_types', value: 'rule:metadef_default' }, glance-get_metadef_resource_type: { key: 'get_metadef_resource_type', value: 'rule:metadef_default' }, glance-add_metadef_resource_type_association: { key: 'add_metadef_resource_type_association', value: 'rule:metadef_default' }, glance-remove_metadef_resource_type_association: { key: 'remove_metadef_resource_type_association', value: 'rule:metadef_default' }, glance-get_metadef_property: { key: 'get_metadef_property', value: 'rule:metadef_default' }, glance-get_metadef_properties: { key: 'get_metadef_properties', value: 'rule:metadef_default' }, glance-modify_metadef_property: { key: 'modify_metadef_property', value: 'rule:metadef_default' }, glance-add_metadef_property: { key: 'add_metadef_property', value: 'rule:metadef_default' }, glance-remove_metadef_property: { key: 'remove_metadef_property', value: 'rule:metadef_default' }, glance-get_metadef_tag: { key: 'get_metadef_tag', value: 'rule:metadef_default' }, glance-get_metadef_tags: { key: 'get_metadef_tags', value: 'rule:metadef_default' }, glance-modify_metadef_tag: { key: 'modify_metadef_tag', value: 'rule:metadef_default' }, glance-add_metadef_tag: { key: 'add_metadef_tag', value: 'rule:metadef_default' }, glance-add_metadef_tags: { key: 'add_metadef_tags', value: 'rule:metadef_default' }, glance-delete_metadef_tag: { key: 'delete_metadef_tag', value: 'rule:metadef_default' }, glance-delete_metadef_tags: { key: 'delete_metadef_tags', value: 'rule:metadef_default' } }
注意您必须将所有 metadef 策略配置为使用
rule:metadef_default
。有关策略和策略语法的详情,请参考此策略 章节。在部署 overcloud 时,使用
-e
选项在部署命令中包括新策略文件:$ openstack overcloud deploy -e open-up-glance-api-metadef.yaml