如果你准备在 openEuler 2209 上搭一套 OpenStack Yoga我建议你先别急着敲安装命令。这套组合看着像是“系统换皮就能跑”实际动手会发现内核、仓库、Python 环境和容器化组件之间有一堆隐性门槛。写这篇东西是想把我踩过的坑和能直接照抄的步骤整理出来给准备做 OpenStack 入门验证或私有云基线测试的人避个雷。先说结论我最后选的是 Kolla-Ansible 容器化部署方式不是 packstack也不是 DevStack更不是手工一个个组件装。原因不是别的就是 openEuler 22.09 的软件源跟 CentOS/RHEL 系不完全一样硬套网上那些基于 CentOS 7 的 RPM 部署教程很容易在最无聊的依赖问题上卡死。这篇内容适合谁适合手里正好有 openEuler 22.09 环境想把 OpenStack Yoga 跑起来做实验、做课程设计、做中小规模私有云技术验证的人。如果你要上生产思路可以参考但架构上还要把高可用、存储后端、网络方案一起补上不能照搬这一套。1. 为什么是 openEuler 22.09 OpenStack Yoga而不是别的组合很多人一听到“在 openEuler 上装 OpenStack”第一反应是找 openEuler 自己的 OpenStack 软件包。这个方向没错但版本匹配是个大坑。openEuler 22.09 是一个社区滚动版本软件仓库里的 OpenStack 相关包不一定能对上 Yoga 这个发布版更多时候是 Wallaby、Xena 这类旧版本甚至只有零散的几个组件。你要做“基于 OpenStack Yoga”的项目就必须把版本控制在自己手里。OpenStack Yoga 就是 2022.1 版本官方支持周期里不算老也不像最新的 Zed、Antelope 那样对底层依赖要求激进。更关键的是Kolla-Ansible 在 Yoga 分支上的容器镜像体系已经非常成熟在 openEuler 22.09 这种内核和系统库都比较新的发行版上跑起来兼容性反而比老旧的 CentOS 7 更好。我建议不要用 packstack 的原因很简单packstack 是为 RDO 的 RPM 包设计的强依赖 CentOS 官方源和 RDO 仓库openEuler 上直接源替换会有一堆签名和路径问题。DevStack 倒是能跑但它是开发环境工具会把代码栈拉得很散不适合作为“一个可维护的 OpenStack 环境”交付。手工部署不是不行但 OpenStack 每个组件背后都有独立的 Python 依赖、数据库脚本和消息队列配置光是把 Keystone 调通就能耗掉一整天。这里我用一个表格快速对比几种方式的感受部署方式优点缺点Packstack/RDO命令简单适合 CentOS 系快速演示openEuler 源兼容差Yoga 支持弱DevStack单机验证最快捷代码路径复杂不适合稳定运行手工源码部署完全可控能学到每个细节步骤多依赖冲突多排错成本高Kolla-Ansible容器化部署接近生产形态镜像多内存要求高首次学习曲线略陡我做完一轮对比后选了 Kolla-Ansible。它的核心逻辑是用 Docker 容器把 Keystone、Glance、Nova、Neutron、Horizon、Cinder 这些组件都封装起来宿主机只负责提供基础资源。这样既避免了 Python 包的全局环境污染也方便以后从单节点扩展成多节点。更重要的是Kolla-Ansible 对 Yoga 有单独的 stable 分支版本对齐非常明确不会出现“装完才发现 OpenStack 版本是 Xena”的情况。2. 搭建前先把这几个问题想清楚这一节不是走形式而是我把第一次部署失败后的经验总结出来的前置检查项。很多人上来就dnf install docker然后直接部署最后内存不够、磁盘格式不对、网卡名配错各种问题一起爆根本分不清是哪一层出的问题。2.1 硬件和磁盘的基本门槛如果你只做一个 All-in-One 单节点实验环境最低配置是 4 核 CPU、8GB 内存、60GB 磁盘。但我强烈建议内存提到 12GB 以上磁盘留 80GB 以上。为什么OpenStack Yoga 全容器跑起来仅仅控制平面就有一堆容器常驻haproxy、mariadb、rabbitmq、keystone、glance-api、nova-api、nova-conductor、nova-scheduler、neutron-server、horizon再加上一个 nova-compute 和 neutron agent内存占用轻松超过 5GB。如果你还开了 Cinder那还会多两个 LVM 相关容器。8GB 内存不是不能跑而是 swap 会被疯狂使用一旦宿主机 OOM最先死的就是 nova-compute 这类业务容器。磁盘上我要特别提醒Docker 的数据目录不要放在根分区默认的/var/lib/docker上凑合最好单独给一块数据盘。因为 OpenStack 镜像、容器日志、Cinder 临时文件都会往这里塞。如果你有条件建议用 XFS 文件系统并且格式化时一定要加上ftype1参数。这个参数决定了 Docker 能不能用 overlay2 存储驱动后面我会在常见问题里展开讲。2.2 主机名、网络接口和时间同步需要提前确认在 openEuler 22.09 上NetworkManager默认是开启的。Kolla-Ansible 部署时会创建 docker0、br-ex 这类网络设备如果主机名带下划线或者特殊字符Hostname 在 HAProxy 和 MariaDB 的配置里会出很难查的问题。所以第一步就是设置一个规范的短主机名比如kolla-control然后写进/etc/hosts。网络接口名也必须提前确认。不要想当然认为网卡叫eth0在 openEuler 上很多机器是ens160、enp3s0这种名称。你可以在globals.yml里写错一个网卡名部署时 Neutron 的 agent 就会因为找不到 bridge 而反复重启。另外Yoga 的 Keystone 签发 token 对时间非常敏感。如果你的宿主机时钟和网络时钟差一分钟以上会出现明明用户名密码都对但认证就是失败的情况。openEuler 默认装了 chrony但默认配置不一定能联网同步。建议部署前先执行一次chronyc tracking确认时钟状态该同步的提前同步好。2.3 工具链准备Python、Pip、Docker 缺一不可Kolla-Ansible 本质上是一堆 Ansible playbook它需要 Python 3、Pip、Git 和 Docker。openEuler 22.09 默认装了 Python 3但python3-pip不一定带。我的建议是先把基础编译工具一次装齐dnf update -y dnf install -y python3 python3-devel python3-pip git gcc make openssl-devel libffi-devel装完之后检查一下 pip 版本如果太老就先升级pip3 install --upgrade pip这里有个很多人忽略的点Kolla-Ansible 通过 pip 安装时会自动拉很多 Python 依赖比如 ansible-core、jinja2、netaddr。如果你的 pip 源访问不稳定后面安装会在任意一个包上报错。建议先配置一个国内 pip 源起码下载速度快很多mkdir -p ~/.pip cat ~/.pip/pip.conf EOF [global] index-url https://pypi.tuna.tsinghua.edu.cn/simple EOFDocker 方面openEuler 不同小版本的包名不统一有的叫docker有的叫docker-engine。装完后一定要确认 Docker 服务能起来dnf install -y docker systemctl enable --now docker docker info | grep Storage DriverStorage Driver那一行如果是overlay2恭喜你可以继续。如果是vfs先别往下走去解决磁盘格式问题否则后面拉镜像和启动容器都会慢到怀疑人生。3. Kolla-Ansible 部署的核心思路搞清楚了环境前置检查再来理解 Kolla-Ansible 到底在做什么。它不是一个“一键安装脚本”而是一套基于 Ansible 的容器编排工具。先用 Docker 镜像封装好 OpenStack 各个服务再用 Ansible 在目标节点上批量拉镜像、配置数据库、启动容器。理解这套逻辑后面部署报错时你才知道该看哪个容器。3.1 为什么用容器化而不是传统 RPM 方式OpenStack 从 Newton 开始就有一个让人头疼的问题组件之间的 Python 依赖互相打架。比如python-neutronclient要求某个版本的requests而python-novaclient又要求另一个版本。如果你用 RPM 方式装系统中只有一个/usr/lib/python3/site-packages所有组件共享一套依赖很难隔离。Kolla-Ansible 用容器把每个服务装进独立环境Keystone 容器里只有 Keystone 需要的依赖Neutron 容器里只有 Neutron 需要的依赖。宿主机只需要有 Docker不需要装任何 OpenStack 的 Python 包。这样既减少了环境冲突也让升级变得简单——拉一个新镜像替换旧容器就算升级了一个组件。这种思路最初会让人不习惯特别是以前手动改配置文件的人都习惯进入虚拟环境或者直接改/etc/keystone/keystone.conf。但在 Kolla 里配置文件其实是统一生成到宿主机/etc/kolla/config/下的容器启动时会把文件挂载进去。你不需要进入容器改配置改宿主机对应路径下的文件然后重启容器就行。3.2 核心配置文件inventory、globals.yml、passwords.ymlKolla-Ansible 目录里最重要的就是这三个文件inventory定义节点角色control、network、compute、storage 分别跑哪些服务。globals.yml全局配置决定启用哪些组件、使用哪个网络接口、VIP 地址是多少。passwords.yml所有服务账号的密码由kolla-genpwd随机生成。单节点部署时inventory 最简单所有角色都指向同一台机器。globals.yml 里最关键的一个参数是kolla_internal_vip_address它就是 OpenStack 内部管理面的 VIP 地址必须是一个未被占用的内网 IP并且和你的管理网卡在同一网段。即使只有一个节点Kolla 也会起一个 HAProxy 容器绑定这个 VIP所有 API 请求先进 HAProxy 再分发到后端服务。还有一个参数是kolla_base_distroKolla 的镜像支持 base distro比如centos、ubuntu、debian。在 openEuler 宿主机上我建议选择centos作为容器基础镜像因为 Kolla 对 CentOS 系的镜像最成熟。这不是说宿主机必须是 CentOS容器和宿主机本来就隔离宿主机的发行版不影响容器内部的系统。4. 完整实操单节点 All-in-One 部署 Yoga下面开始进入正题。我假设你已经有一台最小 4 核 12GB 内存、磁盘 80GB 的 openEuler 22.09 机器并且可以拿到 root 权限。所有命令都在 root 下执行ansible_connectionlocal的方式不需要额外创建部署用户最省事。4.1 初始化系统环境先把主机名和 hosts 设置好hostnamectl set-hostname kolla-control echo 10.0.0.11 kolla-control /etc/hosts10.0.0.11换成你实际的管理 IP。然后关掉 firewalld。实验室阶段防火墙规则会成为排查 HAProxy 和 Neutron 端口问题时的干扰项先停掉systemctl disable --now firewalld如果有 SELinux也先临时放行setenforce 0这里我不建议你直接改/etc/selinux/config。如果你后面要跑生产SELinux 策略需要重新评估临时关闭只是为了让第一次部署少一个变量。最后确认内核网络转发参数Kolla 的 bootstrap 脚本会自动调优但提前确认没坏处sysctl -w net.ipv4.ip_forward14.2 安装 Docker 和基础软件包前面章节提到过安装 Docker这里再强调一次装完一定要看Storage Driverdnf install -y docker systemctl enable --now docker docker info | grep Storage Driver如果结果不是overlay2先修磁盘格式别急着部署。另外确认 Docker 版本不要太老最好 20.10 以上。Kolla Yoga 对 Docker 的 systemd cgroup 支持有要求老版本会在容器启动阶段直接报cgroup parent错误。接着安装 Python 工具链dnf install -y python3 python3-devel python3-pip git gcc make openssl-devel libffi-devel pip3 install --upgrade pip4.3 安装 Kolla-Ansible 并生成密码文件从 Yoga 分支拉取安装pip3 install githttps://opendev.org/openstack/kolla-ansiblestable/yoga安装完成后Kolla-Ansible 会顺着 Python 包的路径把示例配置文件放到某个目录下一般是/usr/share/kolla-ansible/etc/kolla/或 Python site-packages 下的etc/kolla。把它拷到标准目录mkdir -p /etc/kolla cp -r /usr/share/kolla-ansible/etc/kolla/* /etc/kolla/如果找不到这个目录用这条命令定位python3 -c import kolla_ansible; print(kolla_ansible.__file__)然后生成随机密码cd /etc/kolla kolla-genpwd这会生成/etc/kolla/passwords.yml里面包含几十个密码。不要自己手动改成弱密码尤其是database_password和keystone_admin_password全平台认证都靠它们弱密码反而容易被扫描工具盯上。4.4 编辑 globals.yml 并准备 inventory用编辑器打开/etc/kolla/globals.yml找到下面几个参数改成你的实际环境kolla_base_distro: centos kolla_install_type: source openstack_release: yoga kolla_internal_vip_address: 10.0.0.10 network_interface: ens160 enable_horizon: yes enable_cinder: yes nova_compute_virt_type: qemu解释一下kolla_base_distro和kolla_install_type决定容器镜像的基础系统与安装方式。openstack_release: yoga确保拉取的镜像是对应 Yoga 版本。network_interface一定要改成宿主机实际管理网卡名。nova_compute_virt_type如果宿主机支持嵌套虚拟化可以改成kvm不支持就用qemu但性能会差一些不过对实验环境足够。然后创建/etc/kolla/all-in-one文件[control] kolla-control ansible_connectionlocal [network] kolla-control ansible_connectionlocal [compute] kolla-control ansible_connectionlocal [storage] kolla-control ansible_connectionlocal [monitoring] kolla-control ansible_connectionlocal [deployment] kolla-control ansible_connectionlocal这个 inventory 把所有角色都指向本机。控制节点、网络节点、计算节点、存储节点、监控节点全在一台机器上这就是 All-in-One 的本质。4.5 Bootstrap-Servers、拉取镜像和部署先让 Kolla 对宿主机环境做初始化kolla-ansible -i /etc/kolla/all-in-one bootstrap-servers这个命令会做很多事包括安装 Docker、调优 sysctl、创建必要目录、安装 Python 依赖。如果你之前手动装过 Docker它会检查并保持不动。接着拉取所有 Yoga 容器镜像kolla-ansible -i /etc/kolla/all-in-one pull这一步会从公共镜像仓库拉几十个镜像网络慢的话会等很久。我自己的经验是如果镜像源不稳定宁可先挂着等也不要中途 CtrlC。中断后重新拉偶尔会留下不完整的镜像标签后面的 deploy 阶段会报 manifest 找不到之类的问题。镜像就绪后正式开始部署kolla-ansible -i /etc/kolla/all-in-one deploy部署过程会逐个启动数据库、消息队列、认证服务、镜像服务、计算服务、网络服务。第一次跑大约 20 分钟到 40 分钟取决于机器性能和磁盘 IO。期间会看到大量 Ansible task黄色表示执行中红色表示失败。不要看到红色就慌先看是哪个 host 的哪个 task 失败再去看对应容器日志。部署完成后kolla-ansible -i /etc/kolla/all-in-one post-deploy这一步会生成/etc/kolla/admin-openrc.sh这是 OpenStack 命令行客户端的认证文件。4.6 验证服务状态和创建第一个测试实例先看容器整体状态docker ps --format table {{.Names}}\t{{.Status}}正常情况下你会看到类似keystone、glance-api、nova-api、neutron-server、horizon这些名字状态都是Up。然后载入管理员环境变量source /etc/kolla/admin-openrc.sh openstack service list如果能看到identity、image、compute、network等服务说明控制面已经通了。接下来创建最小网络和一个 Cirros 测试虚拟机。先下载 Cirros 镜像curl -L -o /tmp/cirros.img https://download.cirros-cloud.net/0.5.1/cirros-0.5.1-x86_64-disk.img然后依次执行openstack network create demo-net openstack subnet create --network demo-net --subnet-range 192.168.100.0/24 --gateway 192.168.100.1 demo-subnet openstack flavor create m1.tiny --ram 512 --disk 1 --vcpus 1 openstack image create cirros --file /tmp/cirros.img --disk-format qcow2 --container-format bare openstack server create --image cirros --flavor m1.tiny --network demo-net demo-vm虚拟机创建后等半分钟再openstack server list看到状态变成ACTIVE就说明整套 OpenStack Yoga 已经能正常调计算节点了。Horizon 的访问地址就是http://10.0.0.10用户名admin密码在/etc/kolla/passwords.yml里的keystone_admin_password字段。5. 常见问题与排查实录第一次部署几乎不可能一次过下面这些问题是 openEuler Kolla 组合里出现频率最高的。5.1 Docker Storage Driver 是 vfs部署慢且空间爆炸如果你docker info看到Storage Driver: vfs基本可以断定 Docker 的数据分区不是 overlay2 支持的文件系统。vfs 是个没有任何层复用机制的存储驱动每个容器都要拷一份完整文件几十个容器叠加起来磁盘立刻吃满。我踩过这个坑是这样的单独挂载给 Docker 的数据盘格式化时用了mkfs.xfs /dev/sdb没有加-n ftype1导致 Docker 退到 vfs。后来重新格式化才解决。正确的做法mkfs.xfs -f -n ftype1 /dev/sdb然后把 Docker 数据目录指到这块盘上。修改/etc/docker/daemon.json{ data-root: /data/docker }重启 Docker 后再检查docker info确认变成overlay2。5.2 pip 安装 Kolla-Ansible 时编译报错openEuler 默认 Python 3 环境里源码编译一些依赖包时会缺头文件。报错信息通常是fatal error: openssl/opensslv.h: No such file或ffi.h: No such file。解决办法是装编译依赖dnf install -y gcc make python3-devel openssl-devel libffi-devel装完以后重新执行 pip 安装命令。如果你之前已经装到一半建议先pip3 uninstall kolla-ansible再重装避免残留半成品。5.3 Neutron Agent 一直重启表现是docker ps里neutron_openvswitch_agent或neutron_linuxbridge_agent反复重启。排查命令docker logs --tail 100 neutron_openvswitch_agent多数情况下是因为globals.yml里的network_interface配错了网卡导致 agent 找不到物理桥。还有一种可能是因为neutron_external_interface与管理网卡是同一张网卡Open vSwitch 尝试把网卡加入 bridge 时和管理 IP 冲突。如果你的机器只有一张网卡建议先不在 globals.yml 里启用外部网络功能把对外网络留在后续再配置。单网卡环境下强行做 provider 网络很容易把管理面搞断。5.4 Horizon 打不开页面 502Horizon 是 Web 服务它前面有 HAProxy。页面 502 一般不是 Horizon 容器自身崩了而是 HAProxy 没把流量转发到正确的后端或者 VIP 地址不可达。先检查docker logs haproxy docker ps | grep haproxy如果 haproxy 容器反复重启可能是kolla_internal_vip_address无效比如 IP 被局域网内其他设备占用或者和宿主机根本不在同一子网。VIP 地址必须是管理网内的空闲地址不需要在宿主机网卡上显式配置但必须路由可达。另一个隐藏坑是浏览器访问时用的地址和 Horizon 的server_name不匹配。Yoga 版本的 Horizon 会在收到请求后根据 Host 头跳转如果你用 IP 访问没问题但用域名访问之前必须先改/etc/kolla/globals.yml里的相关域名参数否则会 301 到错误的地址。5.5 内存不足导致容器被 OOM Kill单节点 8GB 内存跑 Yoga 全组件高并发操作虚拟机时很容易 OOM。你看docker ps -a会看到一堆容器Exited (137)137就是被内核 OOM Killer 杀掉的特征值。确认方法dmesg | grep -i oom如果你已经按最低配置部署了这里有两个临时办法。第一个是在 globals.yml 里关掉不用的组件比如监控项、控制台的调试服务减少常驻容器数量。第二个是临时加 swap但我不推荐长期用因为容器频繁 swap 会导致服务响应波动。最省心的办法还是给机器加到 16GB 内存。All-in-One 环境本来就是把多个节点角色挤在一台机器上内存才是真正的瓶颈。6. 实战心得与后续扩展整个流程走完我个人最大的感触是openEuler 22.09 跑 OpenStack Yoga 是可行的但前提是你愿意接受容器化部署并且耐心处理前置环境里的细节。第一次部署的人最容易犯的错是贪多。我看到过有同事在 globals.yml 里一次性把 Heat、Octavia、Trove、Ironic 全部enable成yes结果部署失败后根本不知道是哪个组件的问题。我的建议是第一次只保留核心服务Keystone、Glance、Nova、Neutron、Horizon最多加一个 Cinder。等这套核心跑稳了再逐步开其他组件。这样排错时有清晰边界不会几十个角色一起报错无从下手。再一个忠告/etc/kolla/passwords.yml一定要备份到安全位置。这个文件丢了管理面密码全部失联数据库密码、服务账号密码全在里面重置密码的流程会让运维崩溃。我通常会把它同时放到一个 root 才能访问的备份目录并做一次异地拷贝。如果后续要往生产方向走可以沿着三条线扩展。一是把 inventory 改成多节点控制节点、计算节点、网络节点分开部署不再 All-in-One。二是给 Glance 和 Cinder 接 Ceph 后端解决镜像存储和高可用的问题。三是把网络方案从 Linux Bridge 换成 OVN性能和可维护性都会更好。最后分享一个小技巧部署时不要裸跑尽量加日志参数。kolla-ansible -i /etc/kolla/all-in-one deploy --log-file /var/log/kolla-deploy.log第一次部署的排错信息基本都在日志里。很多人报错后第一反应是百度但真正有用的第一手信息往往就在 Ansible 输出的那几行红色错误里先看日志比盲目查教程快得多。
