YAML 文档格式概述

YAML（YAML Ain’t Markup Language）是一种用文本写配置的格式，设计目标是 让人能轻松看懂。广泛用于各类工具和平台的配置文件。

📋 基础信息

🔤 核心语法规则

基础规则

1
2
3
4
5

# 大小写敏感 | 空格缩进 | 2 空格标准
server:
  host: localhost
  port: 8080
  ssl: true

四大铁律：

注释

1
2
3

# 这是行首注释，说明下文意图
server:
  host: localhost # 行尾注释，代码后至少空 2 格

注意：YAML 不支持多行注释，需逐行使用 #。

🏗️ 数据结构

标量（Scalars）

1
2
3
4
5
6
7

string: "hello world"
integer: 42
float: 3.14
boolean: true # ✅ 仅用 true/false
null: ~ # 或留空 / null
date: 2025-12-25
datetime: 2025-12-25T00:00:00+08:00

映射（Mappings）

1
2
3
4
5
6
7
8

# ✅ 块式（推荐）
database:
  host: localhost
  port: 3306
  name: myapp

# ⚠️ 流式（仅简单结构）
database: { host: localhost, port: 3306 }

序列（Sequences）

1
2
3
4
5
6
7
8

# ✅ 块式（推荐）
services:
  - web
  - database
  - cache

# ⚠️ 流式
services: [web, database, cache]

复合结构

1
2
3
4
5
6
7

instances:
  - name: node-1
    region: us-east
    cpu: 4
  - name: node-2
    region: us-west
    cpu: 8

📝 字符串处理

多行字符串

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# | 保留换行符
script: |
  #!/bin/bash
  echo "hello"
  exit 0
# 输出: "#!/bin/bash\necho "hello"\nexit 0\n"
# > 折叠换行（换行转空格）
description: >
  这是一个很长的段落，
  会被合并为一行。
# 输出: "这是一个很长的段落，会被合并为一行。\n"
# |- 保留换行但去掉末尾换行（最常用）
config: |-
  line1
  line2

# 输出: "line1\nline2"

引号规则

建议：仅在包含 : # @ { } [ ] , & * ! > | 等特殊字符时加引号，优先使用单引号。

⚡ 高级特性

锚点与引用（配置复用）

1
2
3
4
5
6
7
8
9

defaults: &defaults
  timeout: 30
  retries: 3
  log_level: info

service:
  <<: *defaults # 合并默认配置
  name: auth-service # 新增字段
  timeout: 60 # 覆盖默认值

类型显式声明

1
2
3
4

port_str: !!str 8080 # 强制转换为字符串
checksum: !!binary | # Base64 编码
  R0lGODlhDAAMAIQAAP//
created: !!timestamp 2025-08-23T12:00:00Z

安全警告：!python/object 等危险标签存在代码注入风险，生产环境应使用 safeloader。

多文档流

1
2
3
4
5
6
7
8
9

---
# 文档 1：开发环境
env: development
db_url: jdbc:mysql://dev-db:3306
---
# 文档 2：生产环境
env: production
db_url: jdbc:mysql://prod-db:3306
...

✅ 编写规范与最佳实践

格式规范速查

命名风格

1
2
3
4
5
6

# ✅ 推荐：小写 + 下划线（snake_case）
max_connections: 100
db_host: localhost

# ❌ 避免：含义不明的缩写
ph: /usr/local # → 应改为 program_home

布尔值规范

1
2
3
4
5
6
7
8
9

# ✅ YAML 1.2 标准
enabled: true
disabled: false

# ❌ 旧版兼容，不推荐
active: yes # 可能被解析为布尔值
inactive: no
turned_on: on
turned_off: off

结构组织原则

1. 相关配置分组为逻辑段落，用空行分隔
2. 控制嵌套深度 ≤ 3–4 层
3. 块式优先于流式（可读性更佳）
4. 大型配置文件拆分为子文件，合并引入

🛡️ 安全规范

🔧 质量工具链

⚠️ 常见陷阱

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# ❌ 陷阱 1：TAB 混入（YAML 绝对禁止）
server:
	host: localhost   # 此处使用了 TAB，解析报错

# ❌ 陷阱 2：类型自动推断
phone: 0123456       # 可能被解析为八进制（YAML 1.1）
# ✅ 应写为
phone: "0123456"     # 加引号明确为字符串

# ❌ 陷阱 3：布尔值误判
active: yes          # YAML 1.1 中解析为 true
# ✅ 应写为
active: true

# ❌ 陷阱 4：重复键
key: value1
key: value2          # 后者覆盖前者，静默错误

📌 速查卡（Golden Rules）

1
2
3
4
5
6
7
8
9
10

 1. ✅ 2 空格缩进，只用空格
 2. ✅ UTF-8 编码，LF 行尾
 3. ✅ 文件末尾保留一个换行符
 4. ✅ 特殊字符使用引号，优先单引号
 5. ✅ 布尔值只用 true / false
 6. ✅ 块式优先于流式
 7. ✅ 注释写在上一行，说明"为什么"
 8. ✅ 使用 yamllint 校验语法
 9. ✅ 敏感信息不硬编码
10. ✅ 控制嵌套深度不超过 4 层

总结：YAML 凭借简洁、易读的语法，已成为目前最流行的配置格式之一。统一缩进、善用锚点复用配置、配合检查工具保证质量，是写好 YAML 的关键。

INI 文件格式概述

INI（Initialization File）是一种轻量级纯文本配置文件格式，起源于 MS-DOS 3.0（1980s），至今仍在桌面应用、嵌入式系统等领域广泛使用。

📋 文件结构

一个完整的 INI 文件由以下三种核心元素构成：

1
2
3
4
5
6
7
8
9
10
11

┌─────────────────────────────────┐
│  ; 注释                          │
│  全局键 = 值                      │
│                                 │
│  [节名称]                        │
│  键 = 值                         │
│  键 = 值                         │
│                                 │
│  [另一个节]                       │
│  键 = 值                         │
└─────────────────────────────────┘

🔤 基本语法

1️⃣ 节（section）

1

[section_name]

2️⃣ 键值对（key-value）

1
2

key = value
key: value

3️⃣ 注释（comment）

1
2

; 分号注释 — 标准写法，推荐使用
#  井号注释 — 常见但非所有解析器支持

🖥️ 完整示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

; 应用配置文件
; 全局默认配置区
app_name = myapp
debug = false

[server]
host = 0.0.0.0
port = 8080
enabled = true
workers = 4

[database]
host = 192.168.1.100
port = 3306
user = admin
password = p@ssw0rd

[logging]
level = info
path = /var/log/app.log
format = json

⚙️ 高级特性（非标准）

部分解析器支持以下扩展语法：

转义序列

数组表示

1
2
3
4

[application]
features[] = logging
features[] = caching
features[] = validation

嵌套节

1
2
3
4
5

[parent]
domain = example.com

[parent.child]
nested_key = value

重复处理

📐 编写规范

✅ 推荐做法

1
2
3

[server_config]          ; 节名统一风格（下划线/帕斯卡）
host = 0.0.0.0          ; 键值分隔用 =
port = 8080

• 分隔符统一使用 =
• 节名推荐 小写加下划线 或 帕斯卡命名
• 键名推荐 下划线风格
• 全局默认配置放在文件顶部
• 文件编码使用 utf-8
• 敏感信息使用环境变量，不硬编码

❌ 避免做法

• 不要 依赖行尾注释（跨解析器兼容性差）
• 不要 使用超过 2 层的嵌套结构
• 不要 假设值类型——所有值读取后均为字符串

📊 格式对比

📚 多语言解析库

🎯 适用场景

总结： INI 以极简语法和广泛兼容性立足至今，适合轻量键值对配置场景。但缺乏统一标准、无原生类型、不支持复杂嵌套是其局限性。复杂场景建议换用 toml 或 yaml。

2025-2026学年广东省职业院校学生专业技能大赛云计算应用赛题总结

模块一：OpenStack云计算平台部署与运维

1.1 基础环境与核心服务部署

1.1.1 集群主机环境配置

• 创建两台云主机，设置控制节点主机名controller，计算节点主机名compute
• 修改/etc/hosts实现IP映射
• 配置yum源文件/etc/yum.repos.d/local.repo
• 配置controller节点无密钥访问compute节点

1.1.2 基础软件包安装

• 安装iaas-yoga软件包
• 配置脚本文件/etc/1cloud/openrc.sh中的基本变量（数据库密码、各服务密码、域名、网卡等，密码均为000000）

1.1.3 数据库及消息服务安装与使用

• 使用iaas-install-mariadb.sh安装Mariadb、Memcached、RabbitMQ
• 修改/etc/my.cnf：支持大小写、innodb缓冲4G、log buffer 64MB、redo log大小256MB且文件组2、最大通信包64M
• 修改Memcached：内存512MB、最大连接数2048、hash算法md5

1.1.4 Keystone服务安装与使用

• 使用iaas-install-keystone.sh安装Keystone
• 编写/etc/keystone/admin-openrc.sh
• 创建域210Demo，包含Engineering和Production项目，组Devops
• 创建用户：Robert（Engineering member+admin）、George（Engineering member）、William（Production member+admin）、John（Production member），并设置对应邮箱

1.1.5 Glance安装与使用

• 使用iaas-install-glance.sh安装Glance
• 上传镜像cirros-0.5.2-x86_64-disk.img，名称为cirros-0.5.2

1.1.6 Nova安装

• controller执行iaas-install-nova-controller.sh，compute执行iaas-install-nova-compute.sh
• 配置调度器采用缓存调度器，缓存主机信息（不重启服务）

1.1.7 Neutron安装

• controller执行iaas-install-neutron-controller-openvswitch.sh
• compute执行iaas-install-neutron-compute-openvswitch.sh

1.1.8 Dashboard安装

• 使用iaas-install-horizon.sh安装
• 修改Django数据存储为文件
• 登录页面标题改为“私有云云计算基础架构平台”

1.1.9 Swift安装

• controller执行iaas-install-swift-controller.sh，compute执行iaas-install-swift-storage.sh
• 创建容器examcontainer
• 上传cirros-0.3.4-x86_64-disk.img，设置分段存放每段10M

1.1.10 Cinder安装与创建硬盘

• controller执行iaas-install-cinder-controller.sh，compute执行iaas-install-cinder-storage.sh
• 在计算节点分出5G分区，加入cinder块存储后端

1.2 云平台运维与调优

1.2.1 Cgroup运维

• 使用cgroup创建cpu_limit组，限制yes命令CPU使用率最多20%单核

1.2.2 Glance调优

• 配置镜像缓存目录，设置缓存最大容量50GB，超过12小时未访问自动清理

1.2.3 Glance API调优

• 设置socket超时180秒，启用KeepAlive机制

1.2.4 监控系统部署与应用

• 部署Prometheus和Grafana到/opt/monitor/，配置systemd
• 另一台云主机安装node_exporter到/usr/local/
• 配置Prometheus为Grafana数据源，导入JSON监控面板，监控网络带宽

1.2.5 OpenStack镜像压缩

• 使用qemu命令压缩CentOS7.5-compress.qcow2为/root/chinaskill-js-compress.qcow2

1.2.6 Nova调优

• 修改nova配置文件，限制同时只创建3台虚拟机

1.2.7 ISCSI存储配置

• 计算节点作为服务端，创建target：iqn.2024-11.com.chinaskills:compute
• 创建存储设备chinaskills.iscsi_store并绑定
• 设置ACL仅允许controller主机访问，关闭密码验证
• 客户端连接共享存储

1.2.8 Keystone调优

• 修改keystone配置文件，启用memcached缓存（IP以controller主机名代替）

1.2.9 Nova组件优化

• 修改nova相关配置，缩短非root用户执行系统命令的耗时（减少命令白名单加载开销）

1.2.10 Heat模板创建容器

• 编写/root/create_container.yaml，执行后创建名为heat-swift的容器

1.3 云计算应用开发

1.3.1 MariaDB数据库操作开发

• 安装Python 3.7.3环境
• 编写/root/mysql_db_manager.py，实现DM_Manager类
• 方法：__init__(db_name)、create_table()（创建member表）、insert_table_data(**kwargs)、update_table_data(**kwargs)、run_table_raw_sql(raw_sql)、delete_table()
• member表字段：id(主键自增), name(VARCHAR256), level(INT), place(VARCHAR256)

1.3.2 OpenStack用户命令行管理工具开发

• 使用FastAPI+argparse，端口9046，编写/root/onecloud/onecloud.py
• 命令格式：onecloud stack user <list|show|create|delete> [参数]
• list：表格化输出所有user（ID、Name）
• show：通过ID或Name查询详细信息，表格Field-Value
• create：--name --password创建用户
• delete：通过ID或Name删除用户

模块二：Kubernetes容器云平台部署与运维

2.1 集群与组件部署

2.1.1 部署Kubernetes容器云平台

• 使用两台4vCPU/12G/100G云主机，部署K8s集群（Master+Node）

2.1.2 部署Harbor镜像仓库

• 在K8s集群中部署Harbor

2.1.3 部署Istio服务网格

• 在K8s集群中部署Istio

2.1.4 部署kubeVirt虚拟化组件

• 在K8s集群中部署kubeVirt

2.2 容器化与CI/CD

2.2.1 容器化部署Node-Exporter

• Dockerfile构建monitor-exporter:v1.0
• 基础镜像centos:centos7.9.2009，安装node_exporter-0.18.1，声明端口9100，开机自启

2.2.2 容器化部署Alertmanager

• 构建monitor-alert:v1.0
• 安装alertmanager-0.19.0，声明端口9093、9094，开机自启

2.2.3 容器化部署Grafana

• 构建monitor-grafana:v1.0
• 安装grafana-6.4.1，声明端口3000，用户名密码admin/admin，开机自启

2.2.4 容器化部署Prometheus

• 构建monitor-prometheus:v1.0
• 安装prometheus-2.13.0，配置/data/prometheus/prometheus.yml含三个任务模板（prometheus, node, alertmanager），声明端口9090，开机自启

2.2.5 编排部署监控系统

• 编写docker-compose.yaml，部署四个容器：monitor-node、monitor-alertmanager、monitor-grafana、monitor-prometheus
• 端口映射对应9100、9093/9094、3000、9090
• 配置Grafana数据源Prometheus，密码admin/admin

2.2.6 部署GitLab

• 命名空间gitlab-ci，Deployment和Service名称gitlab，NodePort 30880暴露80端口
• root密码admin@123，导入项目包demo-2048.tar.gz并命名为demo-2048

2.2.7 部署GitLab Runner

• 部署到gitlab-ci命名空间，Release名gitlab-runner
• 创建持久化缓存目录/home/gitlab-runner/ci-build-cache并注册到GitLab

2.2.8 部署GitLab Agent

• 将K8s集群添加到demo-2048项目中，命名为kubernetes-agent，命名空间gitlab-ci

2.2.9 构建CI/CD

• 编写.gitlab-ci.yml：基于maven:3.6-jdk-8构建，镜像名demo:latest，推送到Harbor仓库demo项目，自动发布应用到K8s集群gitlab-ci命名空间

2.2.10 Etcd配额优化

• 扩容etcd数据库空间配额至8GB

2.2.11 Kubernetes控制器调优

• 配置服务控制器，增加Service资源的并发处理数为100

2.3 开发任务

2.3.1 Docker Restful API实现容器创建

• 启用Docker API端口2375
• 编写/root/api_docker_manager.py，使用nginx:latest创建容器：主机名chinaskills-nginx，开机自启，端口8010，标签chinaskill: nginx，网络bridge
• 查询容器信息，控制台输出并以JSON保存到api_containers.json

2.3.2 Kubernetes资源监控开发

• 安装Python 3.7.3，使用FastAPI框架，编写/root/k8s/main.py，端口9089，host 0.0.0.0，uvicorn启动热重启
• 定义GET接口/cluster/metrics/，返回集群节点名称、CPU数量、内存容量、可分配内存/CPU等

模块三：边缘计算

3.1 边缘计算平台部署

3.1.1 云端部署

• 使用k8s-allinone-v1.22.1镜像创建云主机（已内置K8s）
• 部署KubeEdge 1.11 cloudcore模块，配置systemd管理服务

3.1.2 边端部署

• 创建两台CentOS7.9云主机（edge-node1, edge-node2）
• 编译部署MQTT服务和KubeEdge edgecore模块，启动edgecore服务，启用metrics监控

3.1.3 边缘应用部署

• 编写DeviceModel（counter-model）：属性status（字符串，读写，默认空）
• 编写Device（counter）：引用counter-model，通过节点选择器绑定edge-node1，twins定义status期望值”OFF”、真实值”0”
• 部署DeviceModel、Device、云端计数应用控制器和计数应用，打开计数器

3.2 边缘计算云服务开发

3.2.1 FastAPI封装AI识别服务

• 导入ai_face.tar.gz，在apps目录下编写face_recognition.py
• 服务端口7047，地址0.0.0.0，接口/detect_face，识别material_video.mp4中的人脸，返回人脸坐标字典

3.2.2 边缘设备管理开发

• 导入fastapi_device.zip，使用FastAPI+K8s SDK，端口8070
• 实现接口：
  • GET /cloud_edge_service/node/cloudnode：获取设备资源
  • GET /device/{name}：查询default命名空间中的Device资源
  • PUT /device/device：根据name更新status.twins.desired.value
  • POST /device/device：根据name、dmName、nodeName创建设备（需先创建DeviceModel test-devicemodel）
  • DELETE /device/device：删除default命名空间中的Device资源

模块四：大语言模型应用

4.1 基础服务部署

4.1.1 Dify服务部署

• 使用CentOS7.9安装docker，导入dify-1.9.1和dify_images.zip
• 修改配置：Python初始化超时320秒，插件最大执行时长2400秒，知识库上传文件大小限制100M

4.1.2 Ollama服务部署

• 部署Ollama容器（名称ollama），暴露11434端口
• 导入models.tar.gz中的离线大模型进行管理

4.2 智能聊天机器人开发

4.2.1 智能聊天机器人

• 安装Python 3.7.3，编写/root/chatbot.py，使用Streamlit+Ollama，端口7860，host 0.0.0.0
• 功能要求：
  • 对话历史展示（实时显示、区分用户和模型）
  • 文件解析（支持docx、txt、pdf，作为上下文）
  • 清空对话按钮
  • 多轮流式对话（流式生成）
  • 多模型切换下拉框（切换后上下文保留）

2025-2026广东省职业技能大赛云计算赛项知识点清单

模块一：OpenStack云计算平台部署与运维

1.1 基础环境与核心服务部署

• Linux基础环境配置：主机名修改、/etc/hostsIP映射、yum本地源配置（local.repo）。
• SSH免密登录：RSA密钥对生成与公钥分发（ssh-keygen, ssh-copy-id）。
• OpenStack基础包与变量：安装iaas-yoga，配置环境变量脚本（openrc.sh，密码、域名、网卡等）。
• 数据库与消息队列服务：
  • MariaDB安装与调优：/etc/my.cnf配置（大小写忽略、innodb缓冲池、log buffer、redo log大小与文件组、最大通信包）。
  • Memcached调优：内存大小、最大连接数、hash算法配置。
  • RabbitMQ安装。
• Keystone身份认证服务：
  • 安装与环境变量脚本编写（admin-openrc.sh）。
  • 多域多项目管理：创建域、项目、组。
  • 用户与角色管理：创建用户并分配角色（member, admin），设置邮箱。
• Glance镜像服务：安装、QCOW2镜像上传与命名。
• Nova计算服务：
  • 控制节点与计算节点分离安装。
  • 调度器调优：配置缓存调度器及主机信息缓存。
• Neutron网络服务：基于OpenvSwitch插件的控制节点与计算节点安装。
• Horizon仪表板服务：
  • Django Session存储引擎修改（改为文件存储）。
  • Web UI定制：修改登录页面标题。
• Swift对象存储服务：
  • 控制节点与存储节点安装。
  • 容器创建与对象分段上传（指定段大小）。
• Cinder块存储服务：
  • 控制节点与存储节点安装。
  • LVM后端配置：磁盘分区、物理卷（PV）、卷组（VG）创建并加入Cinder后端。

1.2 云平台运维与调优

• Cgroup资源限制：创建CPU控制组，限制进程CPU使用率（cpu.cfs_quota_us）。
• Glance镜像缓存调优：配置缓存目录、最大容量、自动清理时间。
• Glance API网络调优：Socket超时时间、KeepAlive机制配置。
• 监控系统部署：
  • Prometheus与Grafana二进制部署与Systemd服务管理。
  • Node Exporter部署。
  • Grafana数据源配置及JSON监控面板导入。
• 镜像压缩：使用qemu-img convert压缩QCOW2镜像。
• Nova并发限制：修改配置限制同时创建虚拟机的最大数量。
• iSCSI存储配置：
  • 服务端：targetcli创建Target、Backstore（文件映射）、LUN绑定、ACL配置（限制Initiator访问，关闭认证）。
  • 客户端：iscsiadm发现与登录Target。
• Keystone缓存调优：启用Memcached缓存令牌与数据，配置连接地址。
• Nova组件优化：修改配置减少非Root用户命令白名单加载开销。
• Heat编排：编写YAML模板创建Swift容器资源（OS::Swift::Container）。

1.3 云计算应用开发

• Python源码安装：Python 3.7.3编译安装。
• 数据库操作开发（PyMySQL）：
  • 面向对象编程：类与魔术方法（__init__）。
  • 动态参数传参（**kwargs）。
  • CRUD操作：建表、动态插入、动态更新、执行原生SQL、删表。
• OpenStack命令行工具开发（FastAPI + argparse）：
  • RESTful API设计（GET/POST/DELETE）。
  • 命令行参数解析与子命令路由。
  • OpenStack SDK/API调用：用户列表查询（表格化输出）、详情查询、创建、删除。
  • 数据格式化：表格输出（如tabulate库）。

模块二：Kubernetes容器云平台部署与运维

2.1 集群与组件部署

• K8s集群初始化：使用kubeadm部署Master和Node节点，网络插件安装。
• Harbor镜像仓库：在K8s中通过Helm或YAML部署Harbor及NodePort暴露。
• Istio服务网格：使用istioctl或Helm部署Istio框架。
• KubeVirt虚拟化：在K8s中部署KubeVirt Operator及CRD，支持虚拟机管理。

2.2 容器化与CI/CD

• Dockerfile编写与镜像构建：
  • 基于CentOS 7.9.2009构建：Node-Exporter、Alertmanager、Grafana、Prometheus镜像。
  • 技能点：解压安装、声明端口、配置开机自启（CMD/ENTRYPOINT）、环境变量注入。
  • Prometheus配置文件挂载与Job模板配置。
• Docker Compose编排：编写docker-compose.yaml部署多容器监控栈，端口映射配置。
• GitLab CI/CD体系构建：
  • GitLab部署：K8s Namespace、Deployment、Service（NodePort）、Root密码配置、项目导入。
  • GitLab Runner部署：Helm Release部署，持久化缓存目录配置与注册。
  • GitLab Agent部署：集群注册到GitLab项目，命名空间配置。
  • 流水线构建：.gitlab-ci.yml编写（Maven构建、Docker镜像构建推送、K8s自动部署）。
• Etcd数据库调优：修改启动参数扩容空间配额（--quota-backend-bytes）。
• K8s控制器调优：修改kube-controller-manager参数增加Service并发处理数（--concurrent-service-syncs）。

2.3 开发任务

• Docker Remote API调用：
  • Docker Daemon配置开启TCP 2375端口。
  • Python Docker SDK操作：容器创建（指定主机名、重启策略、端口映射、标签、网络模式）、查询并输出JSON。
• K8s资源监控开发（FastAPI + K8s Python Client）：
  • K8s Python Client认证与API调用。
  • 集群节点指标获取：节点名称、CPU数量、内存容量、可分配CPU/内存。
  • Uvicorn ASGI服务器启动与热重启配置。

模块三：边缘计算

3.1 边缘计算平台部署

• KubeEdge云端部署：
  • 使用keadm init部署CloudCore，配置Systemd服务管理。
• KubeEdge边端部署：
  • MQTT服务（Mosquitto）编译安装。
  • EdgeCore部署：keadm join加入云端，开启Metrics监控。
• 边缘应用部署（CRD编排）：
  • DeviceModel编写：定义设备属性（字符串类型、读写权限、默认值）。
  • Device编写：引用Model，通过nodeSelector绑定边缘节点，配置Twins（期望值与真实值）。
  • 应用部署：部署DeviceModel、Device及计数器应用控制器。

3.2 边缘计算云服务开发

• FastAPI封装AI服务：
  • 视频处理与人脸识别库调用。
  • 接口开发（/detect_face），返回人脸坐标数据结构。
• 边缘设备管理开发（FastAPI + K8s Python Client）：
  • K8s CustomObjectsApi调用：操作KubeEdge Device CRD。
  • 接口开发：获取云端节点资源、查询Device、更新Device Twins期望值、创建Device（级联创建DeviceModel）、删除Device。

模块四：大语言模型应用

4.1 基础服务部署

• Dify平台部署：
  • Docker及离线镜像导入。
  • 环境变量配置：Python初始化超时、插件最大执行时长、知识库文件大小限制。
• Ollama服务部署：
  • Docker容器运行与端口暴露（11434）。
  • 离线大模型导入与管理（ollama create / 离线文件放置）。

4.2 智能聊天机器人开发

• Streamlit Web框架：
  • UI组件：聊天消息展示（st.chat_message）、输入框（st.chat_input）、按钮（st.button）、下拉框（st.selectbox）。
  • 会话状态管理（st.session_state）：保存对话历史及上下文。
• Ollama Python SDK调用：
  • 流式对话生成（stream=True）。
  • 多模型切换与上下文保留机制实现。
• 文件解析技术：
  • 多格式文件读取（docx、txt、pdf），提取文本作为LLM上下文。

OpenStack Ceilometer 监控计量服务概念

Ceilometer 是 OpenStack Telemetry 项目的数据收集层，负责采集云平台中各类资源的计量（Meter）和事件（Event）数据，输出给下游的 Gnocchi（时间序列存储）、Aodh（告警）、CloudKitty（计费）等组件，为性能调优和成本分析提供数据基础📊。

一、两种数据采集方式

Polling Agent 三种角色

📝 等价关系：ceilometer-agent-compute ≡ ceilometer-polling --polling-namespaces COMPUTE，Central 和 IPMI 同理。

二、Pipeline 数据处理管道

采集的原始数据经过 Pipeline 三阶段处理⚙️：

1

Gathering（汇集） ➔ Transforming（转换） ➔ Publishing（发布）

1. Gathering（数据汇集）

从 Notification Agent 或 Polling Agent 接收原始计量数据与事件。

2. Transforming（转换计算）

支持多种转换器处理原始数据，例如：

• rate-of-change：将累计值转换为速率
• arithmetic：数学计算（CPU Time → CPU 利用率百分比）
• aggregation：聚合计算（平均值、最大值、最小值）

3. Publishing（发布输出）

处理后的数据可发布至以下目标端：

所有 Pipeleine 规则通过 pipeline.yaml 配置文件定义，支持灵活的过滤、转换和多重发布策略。

三、架构组件一览🏗️

数据流概览

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

OpenStack Services（Nova / Cinder / Neutron / Glance / Swift / Keystone / Heat）
        │
        ├─── Notification bus（AMQP）──► Notification Agent ──┐
        │                                                     │
        ├─── REST APIs ◄── Central Agent ─────────────────────┤
        │                                                     │
        └─── Hypervisor ◄── Compute Agent ────────────────────┤
                        ◄── IPMI Agent  ──────────────────────┤
                                                              │
                                                              ▼
                                                     Pipeline Manager
                                                              │
                                              ┌───────────────┴───────────────┐
                                              ▼                               ▼
                                          Gnocchi（存储）              Aodh（告警）
                                      CloudKitty（计费）          HTTP/Kafka/文件

四、架构演进🔧

早期 Ceilometer 集采集、存储、告警于一体，单体架构导致性能瓶颈。自 Ocata 版本起完成解耦：

1
2

旧版：Ceilometer（采集 + 存储 + 告警）
新版：Ceilometer（采集） ➔ Gnocchi（存储） + Aodh（告警）

关键变化：

• ceilometer-api 和 ceilometer-collector 不再使用
• 存储委托给 Gnocchi（时间序列数据库）
• 告警委托给 Aodh（独立告警服务）
• 事件存储委托给 Panko

五、生产建议⚠️

• 通知优先：Notification 机制对 API 服务无额外负载，优先使用
• 轮询间隔：通过 pipeline.yaml 配置合理的 polling 间隔，避免过度请求 API
• 存储后端：生产环境推荐 Gnocchi 替代传统数据库，性能显著提升
• 横向扩展：Ceilometer 各 Agent 支持多实例部署，按需增加 Worker 节点
• Jitter 配置：shuffle_time_before_polling_task 参数添加随机抖动，避免惊群效应

六、技术术语💡

• Telemetry — OpenStack 遥测项目组，包含 Ceilometer、Gnocchi、Aodh、Panko 四个子项目
• Meter — 计量样本，如 cpu_util、disk.read.bytes、network.incoming.bytes
• Event — 事件记录，如虚拟机创建/删除/迁移等操作
• Pipeline — 可配置的 YAML 管道，定义数据如何被转换和发布
• Gnocchi — 时间序列数据库，Ceilometer 的推荐存储后端
• Aodh — 基于 Ceilometer 数据的告警服务，支持阈值、组合等告警规则
• AMQP — 高级消息队列协议，Ceilometer 各组件间通过 RabbitMQ 实现异步通信
• Hypervisor — 虚拟机监视器（如 KVM/libvirt），Compute Agent 通过其采集 VM 数据

OpenStack Cinder 块存储服务概念

Cinder 是 OpenStack 平台中的块存储服务组件，为虚拟机提供持久化块级存储设备，数据不随虚拟机生命周期结束而丢失🚀。其最初源自 Nova 项目中的 nova-volume，在 Folsom 版本中独立为 Cinder 项目。

核心设计理念：通过软件定义存储（SDS） 方式将存储资源抽象为可动态调度的逻辑卷，实现存储容量与计算资源的解耦。

一、核心架构

Cinder 采用微服务架构，由以下核心组件构成🏗️：

典型工作流

1
2

用户请求 ➔ cinder-api（接收+鉴权） ➔ 消息队列 ➔ cinder-scheduler（选节点）
    ➔ 消息队列 ➔ cinder-volume（执行操作） ➔ 返回结果

二、核心功能

1. 卷生命周期管理

提供完整的卷操作支持📦：

• 创建卷：从空白或指定镜像创建
• 删除卷：释放存储资源
• 扩展卷：在线扩容
• 挂载/卸载：将卷挂载到指定虚拟机
• 类型转换（retype）：在存储类型间迁移（如 HDD → SSD）

1
2
3
4
5

cinder create --display-name myvolume 10
cinder list
cinder show myvolume
cinder extend myvolume 20
cinder delete myvolume

2. 快照与克隆📸

基于写时复制（CoW）机制，秒级完成：

• 创建快照：对指定卷创建时间点副本
• 从快照创建卷：实现快速克隆
• 一致性组快照：保证多个卷的写一致性

1
2
3

cinder snapshot-create --display-name mysnapshot myvolume
cinder create --snapshot-id SNAPSHOT_ID 10
cinder snapshot-delete mysnapshot

3. 多后端存储支持

同一部署中支持启用多个存储后端，通过 Volume Type 和 volume_backend_name 指定卷创建位置💾：

4. QoS 策略⚡

通过 QoS 规格限制卷的最大 IOPS 与吞吐量，实现多租户资源隔离：

1
2

cinder qos-create high-iops consumer="front-end" read_iops_max=10000 write_iops_max=5000
cinder qos-associate QOS_ID VOLUME_TYPE_ID

5. 备份与灾备🛡️

• cinder-backup 服务支持跨区域备份
• 结合 Ceph 等后端可实现 RPO≈0 的容灾方案
• 三级数据保护：本地快照 ➔ 远程复制 ➔ 存储双活

1
2
3

cinder backup-create --display-name mybackup myvolume
cinder backup-list
cinder backup-restore BACKUP_ID

6. 卷迁移

跨主机迁移卷，支持在线迁移与离线迁移：

1
2

cinder migrate VOLUME_ID HOST_NAME
cinder migration-list

三、配置与管理

1. 创建卷类型

1
2

cinder type-create ssd
cinder type-key ssd set volume_backend_name=SSD_BACKEND

2. 挂载卷到虚拟机

1
2
3
4
5

# 挂载
nova volume-attach SERVER_ID VOLUME_ID

# 卸载
nova volume-detach SERVER_ID VOLUME_ID

3. 从镜像创建卷

1

cinder create --image-id IMAGE_ID --display-name bootable-volume 20

4. 从卷创建镜像

1

cinder upload-to-image --force True VOLUME_ID IMAGE_NAME

5. 配额管理

1
2

cinder quota-show PROJECT_ID
cinder quota-update --volumes 50 --gigabytes 500 PROJECT_ID

四、架构设计要点🔧

1. 控制-数据分离：控制平面（API/Scheduler）与数据平面（Volume）分离，支持横向扩展
2. 驱动抽象层：通过 VolumeDriver 接口标准化后端适配，厂商只需实现 create_volume、delete_volume、create_snapshot 等关键方法
3. Filter Scheduler 算法：先过滤（排除不满足条件的节点），再加权计算（基于容量、IOPS 排序），最终选择最优节点
4. 高可用设计：cinder-api 和 cinder-scheduler 可多节点部署，结合 Pacemaker 实现故障切换

五、生产环境建议⚠️

• 默认 LVM iSCSI 驱动存在性能瓶颈，仅建议用于评估和概念验证环境
• 生产环境建议使用 Ceph RBD 等企业级分布式存储后端
• 控制节点建议三节点集群 + 存储节点双活架构

六、常见问题排查

OpenStack Glance 镜像服务概念

Glance 是 OpenStack 的核心组件之一，提供虚拟机镜像的发现、注册、存储和分发能力，为 Nova 计算服务提供启动镜像资源。

一、镜像格式

1. 磁盘格式（Disk Format）

Glance 支持多种磁盘格式，以适应不同的虚拟化平台和使用场景：

2. 容器格式（Container Format）

与磁盘格式配合使用，描述镜像是否封装：

二、镜像生命周期状态

三、镜像操作命令

1. 上传镜像

1
2

openstack image create --disk-format QCOW2 --container-format BARE --file ./IMAGE.QCOW2 镜像名
glance image-create --disk-format QCOW2 --container-format BARE --file ./IMAGE.QCOW2 --name 镜像名

• --disk-format：指定磁盘格式（QCOW2 / RAW / VMDK / ISO）
• --container-format：指定容器格式（常用 bare）
• --file：指定本地镜像文件路径
• --public / --private：设置镜像可见性

2. 下载镜像

1
2

openstack image save --file ./OUTPUT.QCOW2 镜像ID
glance image-download --file ./OUTPUT.QCOW2 镜像ID

3. 列出与查询镜像

1
2
3

openstack image list
openstack image show 镜像ID
glance image-list

• --status ACTIVE：筛选状态
• --disk-format QCOW2：按格式筛选

4. 删除镜像

1
2

openstack image delete 镜像ID
glance image-delete 镜像ID

5. 共享镜像

1
2

openstack image set --shared 镜像ID
openstack image add project 镜像ID 租户ID

• 通过 RBAC 策略控制租户间共享，支持 member 角色授权
• 镜像所有者可将镜像共享给指定租户

四、镜像导入高级特性

Glance 支持多种导入方式以满足不同场景：

1
2
3
4
5

# Web-Download 导入（从URL直接下载到后端存储）
openstack image create --disk-format QCOW2 --container-format BARE --import --uri HTTPS://EXAMPLE.COM/IMAGE.QCOW2 镜像名

# Glance-Direct 导入（任务方式导入）
glance md-namespace-list

• Web-Download：直接从 URL 拉取镜像到后端，不经过客户端，适合大文件
• Glance-Direct：基于任务的任务型导入，支持进度追踪
• Copy-Image：在不同存储后端间复制镜像（multi‑store 场景）

五、后端存储

Glance 架构将镜像元数据与镜像实际数据分离，支持动态切换后端：

镜像与后端存储解耦

Glance 的核心设计理念是将镜像的元数据（存于 MySQL/PostgreSQL）与实际数据（存于后端存储）彻底分离，带来以下优势：

• 后端可切换：无需修改镜像元数据即可更换存储后端
• Multi‑Store 多后端：可同时挂载多个存储后端，实现异构存储管理
• 存储扩展灵活：从本地文件到 Ceph/Swift 可平滑迁移

六、架构组件

生产最佳实践

• 生产环境推荐 QCOW2 + Ceph RBD 组合
• 使用 --public 或 --shared 管理跨租户共享权限，避免镜像重复上传
• 大镜像导入优先使用 Web-Download 模式，避免客户端网络瓶颈
• 定期清理 killed / deleted 状态的镜像以释放后端存储空间
• 多存储场景下可通过 Copy-Image 实现镜像在不同后端间的迁移

OpenStack Heat 编排服务概念

Heat 是 OpenStack 的核心编排服务（Orchestration Service）🔥，通过声明式模板定义一组云资源及其依赖关系，实现基础设施即代码（IaC），自动化完成资源的创建、更新与删除。

核心设计理念：将基础设施部署转化为代码化模板，实现可重复、可版本控制、可自动化编排的云资源管理。

一、HOT 模板语法

Heat Orchestration Template（HOT）是基于 YAML 的声明式模板格式，是 Heat 的核心编排语言📝。

模板顶层结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

HEAT_TEMPLATE_VERSION: 2016-10-14
DESCRIPTION: 描述模板用途

PARAMETER_GROUPS:
  - LABEL: 网络配置
    PARAMETERS:
      - NETWORK_NAME
      - SUBNET_CIDR

PARAMETERS:
  NETWORK_NAME:
    TYPE: STRING
    LABEL: 网络名称
    DEFAULT: MY-NETWORK

RESOURCES:
  MY_NETWORK:
    TYPE: OS::NEUTRON::NET
    PROPERTIES:
      NAME: { GET_PARAM: NETWORK_NAME }

  MY_SERVER:
    TYPE: OS::NOVA::SERVER
    DEPENDS_ON: MY_NETWORK
    PROPERTIES:
      NAME: MY-INSTANCE
      FLAVOR: M1.SMALL
      IMAGE: CIRROS-0.6.2
      NETWORKS:
        - NETWORK: { GET_RESOURCE: MY_NETWORK }

OUTPUTS:
  INSTANCE_IP:
    DESCRIPTION: 实例IP地址
    VALUE: { GET_ATTR: [MY_SERVER, FIRST_ADDRESS] }

模板版本

二、三大核心概念

1. Stack（栈）📦

Stack 是 Heat 的基本部署单元，一次模板部署即产生一个 Stack。

Stack 生命周期：

1
2
3
4

CREATE_IN_PROGRESS → CREATE_COMPLETE
                      ↘ (回滚) → ROLLBACK_COMPLETE
UPDATE_IN_PROGRESS → UPDATE_COMPLETE
DELETE_IN_PROGRESS → DELETE_COMPLETE

嵌套 Stack（Nested Stack）：通过 OS::HEAT::STACK 类型引用子模板，实现模块化编排。

2. Resource（资源）📋

Resource 是 Stack 内被管理的具体 OpenStack 云资源。资源类型命名格式：OS::<服务>::<类型>。

资源间关系建立方式：

• DEPENDS_ON — 显式声明依赖
• GET_RESOURCE — 引用同 Stack 内其他资源的 ID
• GET_ATTR — 获取资源的运行时属性
• 自动推理 — Heat 引擎根据 PROPERTIES 引用自动推断隐式依赖

3. Parameter（参数）🔧

Parameter 是模板的输入变量，让模板在不同环境间复用：

1
2
3
4
5
6
7
8
9
10
11
12

PARAMETERS:
  INSTANCE_TYPE:
    TYPE: STRING
    LABEL: 实例规格
    DEFAULT: M1.SMALL
    CONSTRAINTS:
      - ALLOWED_VALUES: [M1.SMALL, M1.MEDIUM, M1.LARGE]
  ADMIN_PASSWORD:
    TYPE: STRING
    LABEL: 管理员密码
    HIDDEN: TRUE
    NO_ECHO: TRUE

环境文件（Environment File）：将参数值与模板分离，独立存储：

1
2
3
4
5

# ENVIRONMENT.YAML
PARAMETERS:
  INSTANCE_TYPE: M1.LARGE
RESOURCE_REGISTRY:
  "OS::NOVA::SERVER": "CUSTOM_SERVER.YAML"

三、架构组件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

用户 (CLI / Horizon / API)
        │
        ▼
  ┌──────────┐   ┌──────────────────┐
  │ HEAT-API │──▶│   HEAT-API-CFN   │── AWS CloudFormation 兼容 API
  └────┬─────┘   └────────┬─────────┘
       │                  │
       ▼                  ▼
  ┌──────────────────────────────┐
  │        HEAT-ENGINE           │ ← 核心编排引擎
  │  (依赖解析 + 任务编排 + 回滚) │
  └──────┬───────┬───────┬───────┘
         │       │       │
         ▼       ▼       ▼
    OpenStack 服务 (Nova / Neutron / Cinder / ...)

heat-api — REST API 入口 🚪

• 暴露原生 Heat REST API（端口 8004）
• 接收模板提交与 Stack 操作请求
• 与 Keystone 集成进行认证鉴权

heat-api-cfn — CloudFormation 兼容 API 🔄

• 暴露 AWS CloudFormation 兼容的 Query API（端口 8000）
• 允许 AWS CloudFormation 工具/脚本直接对接 OpenStack
• 提供从 AWS 迁移到 OpenStack 的便捷路径

heat-engine — 核心编排引擎 ⚙️

四、与 AWS CloudFormation 兼容性

Heat 在设计上兼容 AWS CloudFormation 的模板语法和 API 风格，便于混合云或从 AWS 迁移的场景🔄。

五、常用操作命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

# 创建 Stack
openstack stack create -T TEMPLATE.YAML -E ENVIRONMENT.YAML MY-STACK

# 列出 Stack
openstack stack list

# 查看 Stack 详情
openstack stack show MY-STACK

# 查看 Stack 资源列表
openstack stack resource list MY-STACK

# 更新 Stack
openstack stack update -T TEMPLATE.YAML -E ENVIRONMENT.YAML MY-STACK

# 删除 Stack
openstack stack delete MY-STACK

# 查看 Stack 事件（排错用）
openstack stack event list MY-STACK

# 查看模板输出
openstack stack output show MY-STACK OUTPUT_NAME

六、Heat vs Terraform 对比 ⚖️

一句话概括

Heat 是 OpenStack 的 IaC 编排引擎——通过 HOT 模板定义 Stack（部署单元），Stack 包含 Resource（云资源）和 Parameter（输入参数），heat-engine 解析依赖 DAG 自动按序创建/更新/删除，实现基础设施部署的自动化与可重复。

OpenStack Horizon Web界面概念 🖥️

Horizon 是 OpenStack 平台的官方 Web 管理界面组件（Dashboard），基于 Django 框架构建，为管理员和租户用户提供图形化的云资源管理入口，无需记忆命令行即可完成绝大部分日常操作🚀。

核心设计理念：将底层各 OpenStack 组件的 API 调用封装为直观的 Web 操作界面，降低使用门槛，提升运维效率。

一、核心架构

Horizon 采用 Django MTV（Model-Template-View）架构模式🏗️：

通信架构

1
2
3

浏览器（用户） ➔ Apache/nginx（WSGI） ➔ Horizon（Django App）
    ➔ REST API ➔ Keystone（认证） / Nova（计算） / Neutron（网络）
    ➔ Cinder（存储） / Glance（镜像） / Swift（对象存储）

二、界面结构

1. Dashboard（仪表板）与 Panel（面板）

Horizon 的界面按用户角色划分为两大 Dashboard📊：

2. UI 核心组件

Horizon 提供多种标准 UI 组件，确保界面一致性与可扩展性🎨：

• DataTables（数据表）：展示资源列表，支持排序、过滤、分页、批量操作
• Tabs & TabGroups（标签页）：将关联数据分组展示（如实例详情/控制台/日志）
• Workflows（工作流）：多步骤导向型操作，如创建实例（选择镜像 ➔ 选择规格 ➔ 网络配置 ➔ 确认）
• Forms（表单）：参数填写与配置提交
• Wizards（向导）：复杂操作的引导式流程

3. 用户设置

用户可在设置面板中个性化配置⚙️：

• 时区选择（Timezone）：控制时间显示
• 语言偏好（Language）：支持多语言切换
• 页面大小（Items Per Page）：列表每页显示条目数
• HTTP 日志（Logs）：查看 API 调用历史

三、核心功能

1. 计算管理（Nova）💻

2. 网络管理（Neutron）🌐

3. 存储管理（Cinder/Glance/Swift）💾

4. 项目与用户管理（Keystone）👥

四、扩展与定制 🔧

Horizon 支持丰富的定制与扩展能力：

1. Dashboard 注册机制

开发者的自定义功能通过 Django dashboard.py 文件注册到 Horizon：

1
2

# 将自定义面板注册到 Dashboard
dashboard.default_panels.append('MyCustomPanel')

2. 主题与品牌定制

• 修改 openstack_dashboard/settings.py 中的 AVAILABLE_THEMES 切换主题
• 支持自定义 Logo、品牌色、页脚、样式表
• 内置 Bootstrap 主题引擎，支持响应式布局

3. 功能模块扩展

• 采用 Django App 机制，各功能独立模块化
• Panel（面板）是基本功能单元，可自由增删
• 支持第三方插件（如 Heat / Mistral / Sahara 等扩展组件）

4. 常见扩展方式

五、部署模式

生产环境部署建议⚠️

1
2
3
4
5
6
7
8
9

# 安装 Horizon
apt install openstack-dashboard

# 配置 Apache
a2ensite 000-default
systemctl restart apache2

# HTTPS 配置（签发有效期检查）
openstack-config --set /etc/openstack-dashboard/local_settings.py DEFAULT_ENABLE_HTTPS True

六、监控与排查

七、Horizon SDN 管理思想

Horizon 的核心设计哲学：通过抽象化资源视图，屏蔽底层组件差异。

关键技术注解 💡

• Django MTV 架构: Horizon 的基础框架，Model（数据模型）→ Template（模板渲染）→ View（业务逻辑处理）
• REST API 封装: Horizon 内部通过 python-openstackclient 和各组件 SDK 与后端服务通信，用户操作最终转化为 API 调用
• Workflows 工作流: Horizon 独创的多步骤操作模式，将创建实例等复杂操作分解为有引导的步骤，每步可独立验证
• Panel 面板机制: 最细粒度的功能单元，支持按角色/权限动态加载显示，实现功能级 RBAC 控制

Keystone认证服务概念

Keystone 是 OpenStack 中的身份认证服务（Identity Service）👤，负责用户认证、授权和服务目录管理。所有 OpenStack 服务之间的交互都必须经过 Keystone，它是整个云平台的安全中枢。

什么是 Keystone

Keystone 提供三大核心功能：

• 认证（Authentication） 🔐：验证用户身份的真实性
• 授权（Authorization） 🛡️：确定用户是否有权限执行特定操作
• 服务目录（Service Catalog） 📖：提供服务注册与发现能力，让各组件相互找到对方

User（用户）

操作主体，可以是人、服务或系统。

• 用户是执行操作的最小实体，本身不拥有资源
• 用户名在所属 Domain 内唯一，不同 Domain 可以有同名用户
• 用户必须加入特定 Project 并分配 Role 后才能访问资源
• 典型服务用户：nova、glance、cinder、neutron 等（用于服务间通信）

Project（项目）

资源归属的基本单元和隔离边界（V2 中称为 Tenant/租户）。

• 所有 OpenStack 资源（虚拟机、卷、镜像、网络等）都必须归属于某个 Project
• 一个 Project 可包含多个 User，每个 User 可分配不同 Role
• Project 名称在所属 Domain 内唯一
• 支持按 Project 设置配额（Quota）限制资源使用

Role（角色）

定义用户在 Project 或 Domain 中的操作权限级别。

• 角色存在隐式继承关系：admin ⊃ member ⊃ reader
• 授权机制 = Role + Policy（通过 policy.json 定义具体可执行的 API）

Domain（域）

V3 API 引入的高层容器和命名空间，是 Project、User、Group 的顶层隔离单元。

• Domain 名称全局唯一（其他资源只需域内唯一）
• 系统预设 Default 域
• 不同 Domain 支持不同的认证后端（如一个用 SQL，一个用 LDAP）
• 实现**真正多租户（Multi-tenancy）**架构，客户可在自己域内独立管理资源

Endpoint（端点）

服务的网络访问 URL，存储在服务目录（Service Catalog）中。

Token（令牌）

认证通过后 Keystone 颁发的字符串通行凭证。

Token 格式演进：

• UUID Token — 简单但需持久化到数据库，性能较差
• PKI Token — 包含大量信息，体积大，传输效率低
• Fernet Token ✅ — 当前默认，AES256 加密 + SHA256 签名，无需持久化，轻量安全

Group（组）

用户的集合容器（V3 新增）。

• 给 Group 分配 Role，组内所有用户自动继承该角色
• 避免逐一对每个用户分配角色的繁琐操作
• 类比 Linux 操作系统中的用户组

数据模型关系

1
2
3
4
5
6

Domain（域）[全局唯一]
├── Project（项目）[域内唯一] ← 资源归属
│   └── User + Role → 用户在项目中的权限
├── User（用户）[域内唯一] ← 认证主体
├── Group（组）[域内唯一] ← 用户集合
└── Role（角色）[域内唯一] ← 权限定义

典型认证流程

1
2
3
4
5
6

User → 提交凭证（用户名/密码）
     → Keystone 验证身份（Authentication）
     → 返回 Token + 服务目录（Endpoint 列表）
     → 携带 Token 调用 Nova/Glance 等服务
     → 目标服务用 authtoken 中间件向 Keystone 验证 Token
     → 验证通过，执行操作

使用场景

• 多租户云平台 ☁️：通过 Domain 隔离不同租户，Project 隔离租户内资源
• 服务间通信 🔄：Nova 调用 Glance 创建云主机时，使用服务用户 Token 进行认证
• 权限分级管理 🛡️：admin 管理平台、member 使用资源、reader 只读审计

一句话概括

Domain 是顶层容器，Project 是资源隔离单元，User 是操作主体，Role 是权限级别，Token 是通行凭证，Endpoint 是服务入口。六者协同构成 OpenStack 完整的身份认证与授权体系。