简介：一份面向OpenStack初学者与运维实施人员的部署指导手册，聚焦Havana版本的完整安装流程，覆盖环境准备、网络与主机配置、核心组件结构，以及Keystone认证服务等关键环节，帮助读者快速理解并落地IaaS云平台的基础搭建。资源为单个docx文档，压缩包大小519KB，内容以目录式章节组织，便于按步骤查阅。文档不仅列出MySQL、OpenStack核心包、Messaging Server等安装要点，还详细说明Keystone的数据库连接、授权令牌、密钥证书、用户租客与角色定义，并延伸至Glance镜像服务的配置与身份验证，适合作为实验环境部署时的参考手册。已有369人学习下载，适合需要系统部署OpenStack或整理实施文档的技术人员学习参考。
1. OpenStack安装部署为什么容易翻车
OpenStack不是一个软件，而是一套按角色拆开的云管理组件集合，Keystone管认证、Nova管计算、Neutron管网络、Glance管镜像、Cinder管块存储、Horizon管界面。安装部署的难点从来不是把安装包装上去，而是让几十个服务按正确顺序、正确参数互相握手。Neutron网络配错卡几天、RabbitMQ连不上反复报错、容器起来又退出，这些高频问题的根因大多在部署规划和环境参数上。下面的内容按“先选型、再执行、后验证”的顺序展开，覆盖环境规划、Kolla-Ansible实操、服务验证和故障定位的完整路径，适合需要自行搭建OpenStack云平台的技术人员，也给刚入门、希望有一份能照着执行的参考的读者。后半部分会给出可直接上手的命令和常见坑位的排查思路。
2. 选对安装部署路径：DevStack、PackStack、Kolla-Ansible三选一
OpenStack官方并没有锁死某一种安装方式，社区里长期并存着三套主流路径。花十分钟把这三条路的边界搞清楚，比直接复制网上的命令省下的时间要多得多。选错路径的典型结果是：用DevStack搭出来的环境想加节点发现根本不支持，或者用PackStack部署完想上生产，却在网络功能上受限。所以在执行任何安装命令之前，先回答两个问题：这套环境要跑多久，以及后面会不会扩容。
2.1 DevStack：单机入门最快，但离生产很远
DevStack的定位是开发环境，底层用一组Shell脚本把所有服务装进一台机器的系统环境。它适合的场景是：你想弄清楚Nova和Neutron之间怎么通信，想改一个服务的代码快速看效果，或者只想看看Horizon控制台长什么样。不适合的场景是长期运行，因为所有组件共享一套Python环境，系统更新很容易把依赖弄坏，而且它默认不做高可用和持久化。
部署前需要创建一个非root的专用用户，官方习惯叫stack：
sudo useradd -s /bin/bash -d /opt/stack -m stack echo "stack ALL=(ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/stack sudo -u stack -i git clone -b stable/2023.1 https://opendev.org/openstack/devstack /opt/stack/devstack克隆完成后进入devstack目录写local.conf，这是DevStack唯一的必要配置文件，最少三行：
[[local|localrc]] ADMIN_PASSWORD=cloud123 DATABASE_PASSWORD=cloud123 RABBIT_PASSWORD=cloud123ADMIN_PASSWORD是管理员登录Horizon和OpenStack命令行的密码，DATABASE_PASSWORD和RABBIT_PASSWORD分别给数据库和消息队列使用。这三个值在同一套环境里要保持一致，DevStack会自动把它们写入各服务的配置。保存后执行./stack.sh，脚本按Keystone、Glance、Nova、Neutron的顺序把服务装起来，一般需要20到40分钟。跑完会在终端输出一组OS_开头的环境变量，复制出来即可开始使用命令行。
对于菜鸟教程阶段的入门者，DevStack最大的价值是帮你把组件关系在脑子里建立起来。但要注意它不会检查宿主机端口占用，如果3306、5672已被其他服务占用，需要先停掉再部署。DevStack没有提供可靠的加节点方式，验证完功能后建议直接销毁重装。
2.2 PackStack：一条命令拉起的快速部署方案
PackStack是RDO项目推出的部署工具，由Puppet在后台完成服务编排。它的适用场景是节点数量少、网络结构简单、希望快速交付一套演示环境或预生产环境的场景。比如你只需要一个控制节点加两个计算节点，业务方要在一个下午看到可操作的云平台，PackStack是最直观的选择。
All-in-one部署只需要几步：
sudo dnf install -y centos-release-openstack-train sudo dnf update -y sudo dnf install -y openstack-packstack sudo packstack --allinone第一条命令把RDO源加入系统，--allinone参数让PackStack把控制服务和计算服务全部部署在一台机器上。如果要部署多节点，需要先产生应答文件：
sudo packstack --gen-answer-file=/root/answers.txt应答文件是PackStack的核心配置，需要修改三个参数：CONFIG_CONTROLLER_HOST填控制节点IP，CONFIG_COMPUTE_HOSTS填计算节点IP且多个IP用逗号分隔，CONFIG_NETWORK_HOSTS填负责网络服务的节点IP。改完后执行：
sudo packstack --answer-file=/root/answers.txtPackStack的几个常见坑分布在执行阶段：Puppet模块之间偶尔会出现依赖竞争，比如Neutron先于Nova写好网络配置，导致Nova读到旧文件。好在这个工具是幂等的，报错后不需要清环境，直接重跑一次相同命令就能收敛。另外PackStack的版本跟随RDO发行周期，对最新系统的适配会慢半拍，在CentOS Stream 9上部署时尤其要注意源是否匹配。
2.3 Kolla-Ansible：生产环境的最优解与选型边界
Kolla-Ansible是目前生产环境搭建OpenStack的主流方案。它把每个服务打包成Docker镜像，由Ansible负责生成配置、按依赖顺序启动容器。相比前两种方案，隔离性和可维护性都更好：宿主机只需要装Docker和基础依赖，系统升级不会扫掉云平台组件；所有配置集中在/etc/kolla/globals.yml和inventory清单里，改参数后重跑部署即可；扩容计算节点时可以只针对新节点执行，不用全量重来。
选型边界很清晰：学习原理用DevStack，快速演示用PackStack，要持续运行、不断扩容、还有升级预期的平台直接选Kolla-Ansible。三者的对比如下：
| 维度 | DevStack | PackStack | Kolla-Ansible |
|---|---|---|---|
| 底层机制 | 脚本装进系统 | Puppet编排 | Docker + Ansible |
| 多节点扩展 | 不支持 | 支持但费力 | 支持且规范 |
| 生产可用性 | 低 | 有限 | 高 |
| 配置变更方式 | 改脚本重跑 | 改应答文件重跑 | 改globals.yml滚动更新 |
| 排错入口 | 系统日志 | 系统日志 | 容器日志为主 |
因此后面的部署实操围绕Kolla-Ansible展开，这套方案的配置和执行命令沉淀下来，可以直接当作团队内部的OpenStack安装部署参考。在进入命令之前，先把环境规划和版本选择讲清楚。
3. 基于Kolla-Ansible的OpenStack安装部署：从环境准备到服务拉起
3.1 节点规划与宿主机基础配置
Kolla-Ansible部署前先做规划。以一个最小可用环境为例：控制节点至少4核8G、100G磁盘，计算节点至少8核16G，磁盘按虚拟机数量预留。每台节点要有两张网卡，一张走管理网，一张走外部网，外部网用于浮动IP和南北向流量。
先修好节点间的主机解析。假设控制节点主机名为controller，计算节点为compute01：
cat >> /etc/hosts <<EOF 192.168.10.11 controller 192.168.10.21 compute01 EOF所有节点都要执行这个步骤。然后是时间同步，Kolla-Ansible对时间偏差非常敏感，Keystone签发的token校验会直接因为时钟偏移失败。控制节点作为NTP服务器，计算节点指向它：
sudo dnf install -y chrony sudo systemctl enable --now chronyd控制节点上编辑/etc/chrony.conf，添加本地局域网的时间源；计算节点上把server指向controller的IP。配置后重启chronyd，用chronyc sources -v确认状态为^*。节点规划汇总如下：
| 节点 | 主机名 | 建议配置 | 承担角色 |
|---|---|---|---|
| 控制节点 | controller | 4C8G / 100G | control + network + monitoring + storage |
| 计算节点 | compute01 | 8C16G / 200G+ | compute + neutron agent |
另需要提前在控制节点生成SSH密钥，并分发到所有节点的authorized_keys里，后续Kolla-Ansible的所有操作都依赖控制节点免密登录到各节点。
3.2 安装Kolla-Ansible并生成inventory文件
控制节点上创建工作目录和Python虚拟环境，避免依赖污染系统Python：
sudo dnf install -y python3-devel libffi-devel gcc openssl-devel python3-pip git python3 -m venv /opt/kolla-venv source /opt/kolla-venv/bin/activate pip install -U pip pip install 'kolla-ansible' 'python-openstackclient' 'python-neutronclient'python-openstackclient提供openstack命令行，python-neutronclient提供网络相关扩展。不同OpenStack release对Ansible版本有约束，如果pip在解析依赖时报版本冲突，以你选定release对应版本的Kolla-Ansible文档为准，没有固定答案。
安装完成后，把模板文件和inventory样例拷到/etc/kolla：
sudo mkdir -p /etc/kolla sudo cp -r /usr/share/kolla-ansible/etc_examples/kolla/* /etc/kolla/ sudo cp /usr/share/kolla-ansible/ansible/inventory/multinode /etc/kolla/如果Kolla-Ansible装在虚拟环境里，模板路径一般在虚拟环境的share目录下，例如/opt/kolla-venv/share/kolla-ansible/。multinode就是节点清单文件，按组件角色分组：
[control] controller ansible_host=192.168.10.11 [network] controller ansible_host=192.168.10.11 [compute] compute01 ansible_host=192.168.10.21 [monitoring] controller ansible_host=192.168.10.11 [storage] controller ansible_host=192.168.10.11控制、网络、监控、存储这四组都可以复用同一个控制节点，计算节点单独一组。后续扩容就是在这个文件的[compute]分组下加一行新节点IP。
3.3 手把手搭OpenStack的关键：globals.yml参数与密码文件
/etc/kolla/globals.yml是Kolla-Ansible的主配置，部署行为几乎全由它决定。手把手搭OpenStack过程中最容易出错的地方是参数之间互相矛盾，下面这几个参数是每次部署都必须过一遍的。
先初始化随机密码：
kolla-genpwd如果不幸提示权限不足，用sudo /opt/kolla-venv/bin/kolla-genpwd。这个命令生成/etc/kolla/passwords.yml，包含所有服务间的通信密钥和数据库密码。同一套环境下，后续所有部署操作都必须使用同一份passwords.yml，换掉它会导致服务之间认证全部失败。
编辑globals.yml时，必改参数如下：
kolla_base_distro: "rocky" kolla_install_type: "binary" openstack_release: "2023.1" network_interface: "eth0" kolla_internal_vip_address: "192.168.10.250" neutron_external_interface: "eth1" enable_neutron_provider_networks: "yes" nova_compute_virt_type: "kvm"这几个参数的含义和配置要点：
| 参数 | 说明 | 配置注意 |
|---|---|---|
| kolla_base_distro | 宿主机发行版 | rocky对应Rocky Linux，ubuntu对应Ubuntu |
| kolla_install_type | 镜像获取方式 | binary拉预编译镜像，source编译源码，生产用binary |
| openstack_release | 版本tag | 决定拉取哪个版本的容器镜像 |
| network_interface | 管理网卡 | 所有服务监听此网段 |
| kolla_internal_vip_address | 控制面虚拟IP | 配合keepalived实现高可用，需与管理网同一网段 |
| neutron_external_interface | 外部网卡 | 承载浮动IP，建议独立物理网卡 |
| enable_neutron_provider_networks | 是否启用provider网络 | 生产环境必须为yes |
| nova_compute_virt_type | 虚拟化类型 | 物理机用kvm，虚拟机嵌套环境用qemu |
3.4 三阶段执行：bootstrap-servers、prechecks、deploy
云平台搭建到这里才真正进入执行阶段。整个执行过程分三个阶段，顺序固定的原因是每阶段都要为上阶段打好基础。
第一阶段初始化所有节点的系统依赖，安装Docker、配置内核参数和系统服务：
source /opt/kolla-venv/bin/activate sudo /opt/kolla-venv/bin/kolla-ansible -i /etc/kolla/multinode bootstrap-servers后续所有kolla-ansible命令都建议用完整路径执行，目的就是为了让sudo环境能正确找到安装在虚拟环境里的命令。第二阶段是预检查，验证节点间网络连通性、时钟同步状态、Docker可用性和磁盘空间：
sudo /opt/kolla-venv/bin/kolla-ansible -i /etc/kolla/multinode prechecks提示：prechecks输出里如果出现
FATAL结尾的条目，先解决再往下走。跳过预检查直接deploy，后面排错成本会成倍增加。
第三阶段执行正式部署：
sudo /opt/kolla-venv/bin/kolla-ansible -i /etc/kolla/multinode deploy部署时间视机器配置不同在15到40分钟之间。所有容器按依赖顺序启动，Ansible会在每个步骤完成后等待容器健康检查通过。完成后执行post-deploy生成认证环境变量文件：
sudo /opt/kolla-venv/bin/kolla-ansible -i /etc/kolla/multinode post-deploy这个命令会在/etc/kolla下生成admin-openrc.sh，source之后即可使用openstack命令管理云平台。
4. OpenStack部署完成后的验证清单与故障定位
4.1 容器、认证、计算与网络的状态检查
部署完成后先不要急着上业务，按下面的顺序过一遍。第一步看容器状态，在所有节点执行：
docker ps | grep -E "keystone|nova|neutron|glance|horizon"正常情况下STATUS列显示Up，不应出现Restarting或Exited。若发现容器反复重启，用docker logs <容器名> --tail 100查看最近日志，容器名用下划线风格，比如nova_compute、neutron_server。第二步验证API层：
source /etc/kolla/admin-openrc.sh openstack service list openstack endpoint list能正常返回服务列表说明Keystone认证链路通。第三步查计算和网络组件：
openstack compute service list openstack network agent list输出里每个服务的State列应为up，Status列不应包含down。如果某个计算节点状态异常，去该节点执行docker logs nova_compute --tail 50，报错集中在消息队列连接失败或libvirt配置错误这两类。
4.2 用命令行走通创建云主机的全链路
验证完整业务链路最快的方式是从创建项目到登录云主机一条龙走一遍。先创建项目、用户和租户网络：
openstack project create demo openstack user create --project demo --password demo123 demo openstack role add --project demo --user demo member openstack network create demo-net openstack subnet create --network demo-net --subnet-range 10.0.10.0/24 --dns-nameserver 223.5.5.5 demo-subnet openstack router create demo-router openstack router add subnet demo-router demo-subnet这段命令先建了隔离的项目和用户，再创建租户内子网和路由器。--subnet-range是云主机内部IP段，按需规划；--dns-nameserver填环境可用的DNS。接着把路由器接到外部网络：
openstack network list --external openstack router set --external-gateway <外部网络ID> demo-router上传云镜像前，建议选择带cloud-init的qcow2格式镜像，否则后边的密钥注入不会生效：
openstack image create --public --container-format bare --disk-format qcow2 --file ./CentOS-Stream-9-cloud.qcow2 centos9 openstack flavor create --vcpus 1 --ram 1024 --disk 10 m1.small openstack keypair create --public-key ~/.ssh/id_rsa.pub mykey openstack server create --flavor m1.small --image centos9 --network demo-net --key-name mykey demo-vm最后分配浮动IP并绑定：
openstack floating ip create <外部网络名称> openstack server add floating ip demo-vm <浮动IP>绑定后从局域网直连这个浮动IP的22端口，能登录说明从Keystone认证到Neutron网络再到Nova计算调度的整条链路都通了。
4.3 高频故障对照表与排错顺序
把运维过程中遇到最多的几个故障整理成速查表：
| 现象 | 直接原因 | 定位方法 |
|---|---|---|
| Keystone token校验失败 | 节点间时钟偏差 | 各节点执行chronyc sources -v，重新同步后重试 |
| nova-compute状态down | RabbitMQ连接中断或libvirt异常 | 该节点docker logs nova_compute看最后50行，ping消息队列IP测试连通性 |
| 云主机无法获取IP | Neutron DHCP agent未运行 | 执行openstack network agent list，查docker logs neutron_dhcp_agent |
| 浮动IP不通 | 外部网卡接线或交换机trunk问题 | 核对neutron_external_interface对应网卡，检查物理交换机允许的VLAN |
| Horizon打不开 | VIP或haproxy异常 | 确认kolla_internal_vip_address所在网段可路由，docker ps查haproxy容器状态 |
处理故障的第一步永远是确认现象发生在哪个节点。控制节点侧重看keystone、neutron-server、nova-api这些API容器，计算节点侧重看nova_compute和neutron_openvswitch_agent。用docker ps对比正常节点上的容器清单，多出来的、少掉的、反复重启的容器就是嫌疑点。第二步再针对性看日志，Kolla-Ansible的容器日志默认写入容器内/var/log/kolla，也可以用docker logs直接看stdout，内容一致。
注意：修改过globals.yml后要重新执行
kolla-ansible deploy才能生效。如果只改了某个服务参数，可以用kolla-ansible reconfigure --tags <服务名>定向重跑，比全量deploy快得多。
5. 后续维护的三个关键操作：扩容、凭证管理、升级
5.1 用--limit定向扩容计算节点
Kolla-Ansible扩容计算节点不需要重跑全量部署。先在multinode的[compute]分组下追加新节点，然后bootstrap和定向部署：
sudo /opt/kolla-venv/bin/kolla-ansible -i /etc/kolla/multinode bootstrap-servers --limit compute02 sudo /opt/kolla-venv/bin/kolla-ansible -i /etc/kolla/multinode deploy --limit compute02--limit参数让Ansible只在目标节点上执行，控制面服务不受影响。扩容完成后确认nova和neutron的agent状态变为up，同时检查新节点的时间和chrony配置，避免token校验问题。如果存储用了Ceph，新计算节点还要额外配置Ceph密钥，这里不做展开。
5.2 管理多个项目的认证凭证
/etc/kolla/admin-openrc.sh是管理入口，多项目环境要防止混用凭证。常见做法是维护一套rc文件，每个项目一个，切换前先清理环境变量再source：
unset OS_PROJECT_NAME OS_USERNAME OS_AUTH_URL OS_PASSWORD source /root/openrc-demo.sh清理是必要的，否则旧环境变量残留在shell里，命令会作用到错误项目上。
5.3 版本升级的镜像切换与数据库备份
升级的核心是修改globals.yml里的openstack_release指向新版本，然后执行：
sudo /opt/kolla-venv/bin/kolla-ansible -i /etc/kolla/multinode upgrade这个命令会先拉取新镜像，再按依赖顺序滚动替换容器。升级前必须备份/etc/kolla整目录和数据库，数据库备份可以直接通过mariadb容器执行：
docker exec mariadb mysqldump --all-databases -p$(grep database_password /etc/kolla/passwords.yml | awk '{print $2}') > /data/kolla_db_backup.sql升级完成后用openstack service list和openstack compute service list做一次全量健康检查，确认所有组件状态为up。
本文还有配套的精品资源，点击获取
