OpenStack Havana手册过时了？用Kolla-Ansible在CentOS 7.9上部署Train版

简介这份《Openstack安装部署手册》面向云计算运维人员、系统集成工程师及高校相关专业学生针对Havana版本OpenStack平台从零搭建过程中环境配置繁琐、组件依赖复杂、认证链路易出错等痛点提供一套可对照执行的部署参考。资源包内仅含1个docx文档压缩包约519KB篇幅紧凑但目录结构完整便于按章节检索查阅。内容覆盖网卡配置、主机名修改、MySQL数据库安装等环境准备环节并逐一梳理Keystone、Glance、Nova、Swift、Cinder、Neutron等核心组件的整体结构与职责划分其中Keystone认证服务部分展开较细涉及数据库连接创建、授权令牌定义、密钥与证书配置、服务启动、用户租客与roles定义以及API endpoint注册等关键操作Glance章节亦给出数据连接、用户与角色添加、身份验证配置等步骤。目前已有369人学习适合需要快速理解OpenStack组件关系、按手册完成基础部署与排错的中级读者参考。1. 从一份 Openstack 安装部署手册说起Havana 版到底还能不能跑起来手里拿到一份《Openstack安装部署手册.docx》第一反应往往不是兴奋而是犯嘀咕这玩意儿是哪个年代的如果手册里写的是 Havana 版本那基本可以确认它是一份有年头的资料了。Havana 是 OpenStack 早期的一个发行版那时候 Kolla、TripleO 这些自动化部署工具还没成气候装一套云平台靠的是手工敲命令、逐个服务配配置文件。今天再翻出这份手册直接照抄大概率会翻车但它的价值不在于「照着装一遍」而在于帮你理解 OpenStack 各个组件之间到底是怎么串起来的。现在主流的做法是用 Kolla-Ansible 或者 DevStack 来搭环境前者面向生产、后者面向开发和验证。但如果你手上只有一份 Havana 手册又确实需要把一套 OpenStack 跑起来比较务实的路径是先用手册理清组件关系再用 Kolla-Ansible 在 CentOS 7.9 或 Ubuntu 上做容器化部署。这篇文章就是按这个思路走的——先讲清楚 OpenStack 安装部署这件事在 Havana 语境下意味着什么再给出今天能复现的部署路径、参数配置和排错方法。适合手里有旧手册不知道怎么处理的人也适合第一次接触 OpenStack、想搞明白「装一套云平台到底要动哪些东西」的工程师。2. Havana 手册里的组件关系与今天的部署选型2.1 Havana 时代的安装逻辑为什么是手工逐服务配置Havana 版本的 OpenStack 安装部署核心逻辑是「每个服务独立安装、独立配置、独立启动」。那时候没有容器编排也没有统一的部署框架装一套环境的基本流程是先在控制节点上装 MySQL、RabbitMQ、Keystone再装 Glance、Nova、Neutron、Horizon计算节点上单独装 Nova Compute 和 Neutron Agent。每个服务都有自己的配置文件通常放在/etc/服务名/下面改完配置手动重启服务。这种方式的优点是透明——你能清楚看到每个组件依赖什么、监听哪个端口、连的哪个数据库。缺点是重复劳动多而且一旦某个服务的配置写错排查起来要在多个日志文件之间来回翻。Havana 手册里通常会给出每个服务的配置文件模板和启动命令但不会告诉你这些配置项之间的依赖关系。比如 Keystone 的 endpoint 配错了Nova 就注册不上Horizon 也登不进去但报错信息可能只显示「无法连接」或者「认证失败」。今天再用手工方式装 Havana 已经不现实了主要是依赖包源基本不可用Python 2.7 的环境也不好找。但手册里对组件关系的描述仍然有价值它告诉你 Keystone 是认证入口、Glance 管镜像、Nova 管计算、Neutron 管网络、Cinder 管块存储、Horizon 是 Web 控制台。这个骨架没变变的是部署方式。2.2 今天装 OpenStack 的三条路Kolla、DevStack 和手动如果你现在要搭一套 OpenStack常见的选择有三条第一条是 Kolla-Ansible。它把每个 OpenStack 服务打包成 Docker 容器用 Ansible 做编排。优点是部署快、环境隔离好、升级相对方便适合生产环境或者需要长期维护的测试环境。缺点是对 Docker 和 Ansible 要有基本了解出问题时要看容器日志而不是系统日志。第二条是 DevStack。它本质上是一堆 Shell 脚本从源码拉取各个组件然后在本机跑起来。优点是适合开发调试改代码方便。缺点是它会把你的机器搞得很「脏」不适合当稳定环境用重启后经常需要重新跑一遍。第三条是纯手动部署。除非你有特殊需求否则不建议。手工部署一套完整的 OpenStack 至少需要两天而且很容易在某个依赖上卡住。我一般会推荐 Kolla-Ansible因为它的部署过程可重复、可回滚而且社区文档比较全。下面就以 Kolla-Ansible 为例讲一下在 CentOS 7.9 上部署一套最小可用 OpenStack 的具体步骤。2.3 用 Kolla-Ansible 在 CentOS 7.9 上跑通最小环境先确认基础环境两台机器一台做控制节点计算节点all-in-one一台可选做第二个计算节点。每台至少 8GB 内存、4 核 CPU、两块网卡一块管理网、一块业务网。操作系统用 CentOS 7.9关闭 SELinux 和防火墙或者放行必要端口。第一步安装 Docker 和 Ansible# 安装 Docker CE yum install -y yum-utils yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo yum install -y docker-ce docker-ce-cli containerd.io systemctl enable docker systemctl start docker # 安装 Ansible yum install -y epel-release yum install -y ansible ansible --versionDocker 用来跑 OpenStack 各个服务的容器Ansible 用来做批量配置和编排。CentOS 7.9 默认的 Python 版本是 2.7Kolla-Ansible 的某些版本对 Python 3 有要求如果遇到语法错误需要额外装 Python 3 并切换。第二步安装 Kolla-Ansible 并生成配置pip install kolla-ansible9.0.0 # 对应 Train 版本兼容 CentOS 7.9 mkdir -p /etc/kolla cp -r /usr/share/kolla-ansible/etc_examples/kolla/* /etc/kolla/ cp /usr/share/kolla-ansible/ansible/inventory/all-in-one . kolla-genpwd # 生成各服务的随机密码写入 /etc/kolla/passwords.ymlkolla-genpwd会为 Keystone、MySQL、RabbitMQ 等生成随机密码保存在passwords.yml里。这个文件很重要后面排查认证问题时要对照看。第三步修改全局配置# /etc/kolla/globals.yml 关键配置项 kolla_base_distro: centos kolla_install_type: binary openstack_release: train network_interface: eth0 # 管理网网卡 neutron_external_interface: eth1 # 业务网网卡 kolla_internal_vip_address: 10.0.0.100 # 控制节点 VIP enable_horizon: yes enable_neutron_provider_networks: yesnetwork_interface是管理网用来跑 API 和数据库通信neutron_external_interface是给虚拟机出网用的不能配 IP由 Neutron 接管。kolla_internal_vip_address是 Keepalived 的 VIP单节点部署时也建议设一个方便后续扩展。第四步执行部署kolla-ansible -i ./all-in-one prechecks # 预检查看环境是否满足 kolla-ansible -i ./all-in-one deploy # 正式部署耗时约 20-40 分钟 kolla-ansible -i ./all-in-one post-deploy # 生成 admin-openrc.shprechecks会检查 Docker 版本、端口占用、磁盘空间等有问题会提前报出来。deploy阶段会拉取镜像、启动容器如果卡在某个容器上用docker logs 容器名看日志。post-deploy生成的环境变量文件在/etc/kolla/admin-openrc.sh后面用 OpenStack 命令前先 source 一下。部署完成后浏览器访问http://kolla_internal_vip_address就能看到 Horizon 登录页用户名admin密码在passwords.yml里搜keystone_admin_password。3. 部署完成后的验证与常见配置调整3.1 用命令行验证各服务是否正常部署完不等于能用先做一轮验证。source 环境变量后依次检查source /etc/kolla/admin-openrc.sh openstack token issue # 验证 Keystone 认证 openstack image list # 验证 Glance openstack compute service list # 验证 Nova openstack network agent list # 验证 Neutron openstack volume service list # 验证 Cinder如果token issue报 401说明 Keystone 有问题去看/var/log/kolla/keystone/keystone.log。如果compute service list里没有节点说明 Nova Compute 没注册上检查计算节点的nova-compute容器日志。network agent list里应该看到Open vSwitch agent和DHCP agent的状态是UP如果是DOWN通常是网络配置或防火墙问题。3.2 网络配置provider network 和 tenant network 的区别Kolla 默认会创建两类网络provider network 直接映射到物理网卡虚拟机拿到的 IP 在物理网段里tenant network 是 VXLAN overlay虚拟机 IP 是内部网段出网需要走路由和 NAT。如果你只是做测试用 provider network 更简单openstack network create --share --external \ --provider-physical-network physnet1 \ --provider-network-type flat provider openstack subnet create --network provider \ --allocation-pool start10.0.0.200,end10.0.0.250 \ --dns-nameserver 8.8.8.8 --gateway 10.0.0.1 \ --subnet-range 10.0.0.0/24 provider-subnet--provider-physical-network physnet1要和/etc/kolla/neutron-openvswitch-agent/里的网桥配置对应。如果创建实例后拿不到 IP先检查neutron agent list里 agent 是否 alive再看openvswitch的流表。3.3 镜像和实例从上传到能 SSH 登录上传一个 CirrOS 镜像做测试wget http://download.cirros-cloud.net/0.5.2/cirros-0.5.2-x86_64-disk.img openstack image create cirros \ --file cirros-0.5.2-x86_64-disk.img \ --disk-format qcow2 --container-format bare --public创建实例openstack flavor create --vcpus 1 --ram 512 --disk 1 m1.tiny openstack keypair create --public-key ~/.ssh/id_rsa.pub mykey openstack server create --flavor m1.tiny --image cirros \ --nic net-idprovider-network-id --key-name mykey test-vmnet-id用openstack network list查。实例起来后openstack server list看状态是ACTIVE然后用openstack console url show test-vm拿控制台地址或者直接 SSHprovider network 下 IP 可直接访问。如果实例一直卡在BUILD去看/var/log/kolla/nova/nova-compute.log常见原因是镜像格式不对或者资源不足。4. 避坑与排查Havana 手册照抄会遇到的五个问题4.1 坑一依赖包源失效yum install 直接报 404现象按照 Havana 手册执行yum install openstack-keystone之类的命令提示找不到包或者 404。原因Havana 对应的 EPEL 和 RDO 源早就下线了CentOS 6/7 的官方源也不再维护这些旧版本。解决不要试图修复旧源。改用 Kolla-Ansible 的容器化方案或者用 DevStack 从源码拉取。如果必须用 Havana 做实验找离线的 RPM 包或者用 Docker 镜像跑但投入产出比很低。4.2 坑二Keystone 认证失败但日志里只写「Unauthorized」现象openstack token issue返回 401Keystone 日志里只有一行Unauthorized没有更多信息。原因通常是admin-openrc.sh里的密码和passwords.yml里的keystone_admin_password不一致或者OS_AUTH_URL指向的端口不对Kolla 默认是 5000旧版可能是 35357。解决先grep keystone_admin_password /etc/kolla/passwords.yml确认密码再检查admin-openrc.sh里的OS_PASSWORD。如果密码对但还报错用curl -i http://vip:5000/v3看 Keystone 是否响应不响应就去看容器状态。4.3 坑三Neutron agent 显示 DOWN虚拟机拿不到 IP现象openstack network agent list里Open vSwitch agent状态是DOWN创建实例后一直BUILD或者没有 IP。原因通常是neutron_external_interface配错了网卡或者网卡上有 IP 地址导致 OVS 无法接管。另外如果管理网和业务网用了同一块网卡也会出问题。解决确认globals.yml里neutron_external_interface对应的网卡没有 IPip addr show eth1应该只有UP没有inet。如果有 IP用ip addr del删掉。然后重启neutron_openvswitch_agent容器。4.4 坑四Horizon 能登录但页面报 500现象Horizon 登录页正常输入用户名密码后跳转报 500 错误。原因通常是 Horizon 容器连不上 Keystone 或者数据库也可能是memcached没起来。Kolla 的 Horizon 依赖memcached做 session 存储。解决docker ps | grep memcached看容器是否运行没运行就docker start memcached。再看/var/log/kolla/horizon/horizon.log如果是数据库连接错误检查nova和keystone的数据库用户权限。4.5 坑五部署卡在prechecks的 Docker 版本检查现象kolla-ansible prechecks报错提示 Docker 版本不满足要求。原因Kolla-Ansible 对 Docker 版本有最低要求CentOS 7.9 默认源里的 Docker 版本可能太旧。解决用 Docker 官方源安装最新稳定版或者按 Kolla 文档指定版本。安装后docker --version确认然后重新跑prechecks。如果还报错看具体是哪个检查项失败通常是docker info里的Storage Driver或者Cgroup Driver不匹配。5. 从 Havana 手册到 Kolla 部署一份可复用的检查清单如果你手里有一份旧手册想把它变成今天能用的部署方案我一般会按这个顺序过一遍检查项Havana 手册里的写法今天的对应做法认证服务手动装 Keystone配keystone.confKolla 容器keystone密码在passwords.yml镜像服务手动装 Glance配glance-api.confKolla 容器glance_api后端默认本地文件计算服务手动装 Nova配nova.confKolla 容器nova_compute和nova_api网络服务手动装 Neutron配neutron.confKolla 容器neutron_server和neutron_openvswitch_agent控制台手动装 Horizon配local_settings.pyKolla 容器horizon配置在globals.yml数据库手动装 MySQL建库建用户Kolla 容器mariadb密码自动生成消息队列手动装 RabbitMQKolla 容器rabbitmq这张表的作用是帮你做映射手册里每提到一个服务你就知道在 Kolla 里对应哪个容器、哪个配置文件、哪个日志路径。这样即使手册里的命令不能直接跑你也能顺着组件关系找到今天的替代方案。还有一个习惯每次部署完把passwords.yml和globals.yml备份到 Git 仓库里。OpenStack 的密码和 VIP 配置一旦丢了恢复起来很麻烦。我吃过这个亏后来所有 Kolla 环境都强制做配置版本管理。另外kolla-ansible deploy之前先跑prechecks不要跳过很多问题在预检查阶段就能暴露出来比部署到一半失败再回滚省事得多。希望帮到你。本文还有配套的精品资源点击获取