简介：这份文档面向云计算初学者与运维人员，系统讲解如何从零搭建一套 OpenStack 私有云平台，帮助读者理解开源云平台各组件的部署逻辑与配置要点。资源包为单个 doc 文档，约 119KB，内容以文字步骤与命令示例为主，便于边看边在实验环境中对照操作。文档从修改主机名、主机名与地址映射、清除防火墙规则、设置 SELinux 为 permissive 等基础准备讲起，逐步推进到上传镜像、创建目录、挂载镜像文件、配置 YUM 源、安装 iaas-xiandian 软件包与 OpenStack 组件，并覆盖创建镜像、磁盘、外网、内网及子网、外网与内网连接、创建虚拟机并绑定浮动 IP、创建卷类型与挂载云硬盘、分区格式化等完整流程。目前已有 618 人学习，适合需要搭建私有云实验环境、准备相关课程或认证考核的读者参考，可帮助快速理清部署顺序与关键命令，减少环境配置中的试错成本。

1. OpenStack 私有云搭建：从零到能跑虚拟机的真实路径

很多团队第一次碰 OpenStack 私有云搭建，都是被"开源、可控、不绑厂商"这几个词吸引进来的，结果装到第三天发现 RabbitMQ 连不上、Keystone 认证 401、Horizon 白屏，最后不了了之。我自己第一次搭 OpenStack 是在两台退役的 Dell R720 上，前后重装了四遍才让一台虚拟机成功拿到 IP。这篇笔记不讲 OpenStack 有多伟大，只讲一条能落地的路径：用 Kolla-Ansible 在 3 台物理机或虚拟机上搭出一套能创建实例、能挂卷、能登录 Dashboard 的最小可用私有云，并把每一步的参数、验证命令和翻车点写清楚。适合手里有 3 台以上 x86 机器、想自建云平台但不想被厂商锁定的运维和后端工程师。如果你只有一台机器，后面会讲 All-in-One 的降级方案。

2. 先想清楚：为什么是 Kolla-Ansible 而不是 DevStack 或手动装

2.1 三种主流部署方式的真实差别

OpenStack 部署方式这几年收敛到三条路：DevStack、手动逐组件安装、Kolla-Ansible 容器化部署。DevStack 是官方给开发者用的，把所有服务跑在一个节点上，改代码方便，但重启就崩、不适合长期运行，我见过有人拿它当生产环境，结果一次git pull直接全挂。手动装就是照着官方文档一个个装 Keystone、Glance、Nova、Neutron，能学到东西，但组件间版本兼容是个黑匣子，Queens 之后各组件独立发版，依赖冲突能让你调一周。

Kolla-Ansible 的思路是把每个 OpenStack 服务打成 Docker 镜像，用 Ansible 编排到多节点上。它的价值在于：版本组合是官方验证过的、升级有路径、配置集中在/etc/kolla/globals.yml一个文件里。代价是你得先理解容器网络和 Ansible 的 inventory 逻辑。对想长期维护私有云的团队，这是目前最稳的选择。

2.2 硬件和系统的最低门槛

别信"OpenStack 能跑在树莓派上"这种话，能跑和能用是两回事。我建议的最低配置是：控制节点 8 核 16G 内存 + 100G SSD，计算节点按你要跑的虚拟机数量算，每台至少 16 核 32G。网络必须有两块网卡，一块做管理网（API、数据库、消息队列），一块做业务网（虚拟机流量），如果要做 Neutron 的 VLAN 或 VXLAN 还需要第三块。

操作系统我固定用 CentOS Stream 9 或 Ubuntu 22.04 LTS，Kolla-Ansible 对这两个支持最好。装系统时注意：关闭 SELinux 或设为 permissive、关闭 firewalld、时间同步必须开（chronyd），否则 Keystone 的 token 会因为时间偏差直接失效。主机名要能互相解析，我一般直接写/etc/hosts，不折腾 DNS。

# 三台机器统一执行的基础准备 hostnamectl set-hostname control01 # 各节点改成自己的名字 systemctl disable --now firewalld setenforce 0 sed -i 's/^SELINUX=enforcing/SELINUX=permissive/' /etc/selinux/config systemctl enable --now chronyd # 确认时间同步 chronyc sources -v

这几条命令里，setenforce 0是临时生效，改配置文件才是永久。chronyc sources输出里如果看到^*开头的行说明同步正常，如果全是^?就是没连上时间源，后面 Keystone 一定报错。主机名解析用ping control01能通就行。

3. 用 Kolla-Ansible 跑通部署：从装依赖到第一个实例

3.1 控制节点的依赖安装与 inventory 配置

Kolla-Ansible 只需要在控制节点（部署机）上装，它会通过 SSH 推到其他节点。先装 Python 环境和 Ansible：

# 在部署节点执行 dnf install -y python3-devel python3-pip libffi-devel gcc git pip3 install -U pip pip3 install 'ansible-core>=2.15,<2.16' pip3 install kolla-ansible # 验证版本 kolla-ansible --version

ansible-core的版本要卡住，Kolla-Ansible 对 Ansible 版本敏感，装错版本会在prechecks阶段报模块找不到。装完后配置文件在/usr/share/kolla-ansible/etc_examples/kolla/，inventory 在/usr/share/kolla-ansible/ansible/inventory/，把它们复制到/etc/kolla和当前目录：

mkdir -p /etc/kolla cp /usr/share/kolla-ansible/etc_examples/kolla/* /etc/kolla/ cp /usr/share/kolla-ansible/ansible/inventory/multinode ./

然后编辑multinode文件，把三台机器的 IP 填进去。控制节点放control、network、monitoring组，计算节点放compute、storage组。同一个节点可以属于多个组，但compute和control分开是生产的基本要求。

[control] 10.0.0.11 [network] 10.0.0.11 [compute] 10.0.0.12 [storage] 10.0.0.12 [monitoring] 10.0.0.11

填完先跑一遍连通性测试：ansible -i multinode all -m ping，全部返回 pong 才能继续。这一步失败通常是 SSH 密钥没配或主机名解析不对。

3.2 globals.yml 里必须改的 8 个参数

/etc/kolla/globals.yml是整套部署的核心，几百行配置里真正必须改的就那么几个。我按重要性列出来：

# 网卡名，用 ip a 查，别照抄 network_interface: "ens192" # 业务网网卡，做 Neutron 用 neutron_external_interface: "ens224" # 管理网段 kolla_internal_vip_address: "10.0.0.10" # 对外访问的 VIP，可以和上面一样 kolla_external_vip_address: "10.0.0.10" # 镜像类型，CentOS 用 yum，Ubuntu 用 apt openstack_release: "2023.2" # 启用哪些服务 enable_haproxy: "yes" enable_neutron_provider_networks: "yes" # 密码文件位置 kolla_passwords_file: "/etc/kolla/passwords.yml"

network_interface填错是最常见的翻车点，填成lo或者不存在的网卡，部署到haproxy阶段直接卡死。kolla_internal_vip_address必须是一个没被占用的 IP，它会被 keepalived 接管，如果这个 IP 已经被别的机器用了，HAProxy 起不来。openstack_release决定拉哪个版本的镜像，2023.2 是 Caracal，写错会拉不到镜像。

改完 globals 后生成密码：kolla-genpwd，它会把/etc/kolla/passwords.yml里所有密码字段填上随机值。这个文件要备份，丢了就得重装。

3.3 部署命令与各阶段验证

正式部署分两步：bootstrap-servers装 Docker 和依赖，deploy拉镜像起容器。

# 给所有节点装 docker 和 python 依赖 kolla-ansible -i multinode bootstrap-servers # 部署前检查，这一步会暴露 90% 的配置错误 kolla-ansible -i multinode prechecks # 拉镜像，国内网络慢的话这一步最久 kolla-ansible -i multinode pull # 正式部署 kolla-ansible -i multinode deploy # 生成 admin-openrc.sh kolla-ansible -i multinode post-deploy

prechecks阶段会检查内存、磁盘、网络、端口占用，任何一项不过都会明确告诉你哪台机器哪个检查项失败。我遇到最多的是内存不足（控制节点低于 8G 直接拒绝）和 5672、3306 端口被占。deploy阶段如果卡在某个容器起不来，用docker logs <容器名>看日志，Kolla 的容器名都是keystone、nova_api这种，很好认。

部署完成后验证：

source /etc/kolla/admin-openrc.sh openstack token issue # 能返回 token 说明 Keystone 正常 openstack compute service list # 能看到 nova-compute 状态 up openstack network agent list # 能看到 neutron 各 agent alive

三条命令都通过，说明核心服务活了。compute service list里如果 nova-compute 是down，去计算节点看docker logs nova_compute，通常是消息队列连不上或虚拟化没开。

3.4 创建第一个实例：网络、镜像、规格、密钥

服务起来不等于能用，还得建网络和镜像。先建一个 provider 网络（直接桥接到物理网卡，最简单）：

openstack network create --share --external \ --provider-physical-network physnet1 \ --provider-network-type flat public1 openstack subnet create --network public1 \ --allocation-pool start=10.0.0.100,end=10.0.0.200 \ --gateway 10.0.0.1 --subnet-range 10.0.0.0/24 public1-subnet

--provider-physical-network physnet1要和 Neutron 配置里的 bridge mapping 对应，Kolla 默认在/etc/kolla/neutron-openvswitch-agent/ml2_conf.ini里配了physnet1:br-ex。allocation-pool是给虚拟机分配的浮动 IP 范围，别和物理机 IP 冲突。

然后传镜像、建规格、建密钥对：

# 下载一个 cirros 测试镜像 curl -O http://download.cirros-cloud.net/0.6.2/cirros-0.6.2-x86_64-disk.img openstack image create --disk-format qcow2 --container-format bare \ --file cirros-0.6.2-x86_64-disk.img cirros openstack flavor create --vcpus 1 --ram 512 --disk 1 m1.tiny ssh-keygen -t rsa -f ~/.ssh/id_rsa_kolla -N "" openstack keypair create --public-key ~/.ssh/id_rsa_kolla.pub mykey

最后创建实例并验证：

openstack server create --flavor m1.tiny --image cirros \ --nic net-id=$(openstack network show public1 -f value -c id) \ --key-name mykey test-vm openstack server list

server list里状态从BUILD变ACTIVE就成功了。如果卡在BUILD超过两分钟，去计算节点看docker logs nova_compute，常见原因是镜像格式不对或计算节点没连上 Glance。

4. 部署过程中最容易翻车的 5 个坑

4.1 坑一：prechecks 报内存不足

现象：prechecks阶段报Memory check failed，控制节点明明有 16G。原因是 Kolla 默认要求控制节点可用内存不低于 8G，但它算的是free的可用值，如果系统缓存占太多会误判。解决：echo 3 > /proc/sys/vm/drop_caches清缓存，或者在 globals.yml 里加prechecks_enable_memory_check: false跳过（不推荐，内存真不够后面会 OOM）。

4.2 坑二：VIP 起不来导致 HAProxy 失败

现象：deploy卡在haproxy容器，日志显示Cannot bind to 10.0.0.10。原因是kolla_internal_vip_address这个 IP 已经被别的设备占用，或者网卡没开promisc。解决：arping -I ens192 10.0.0.10确认没响应，换一个空闲 IP；确认网卡是 up 状态且能通网关。

4.3 坑三：计算节点 nova-compute 一直 down

现象：openstack compute service list里 nova-compute 状态down，但容器在跑。原因通常是计算节点连不上 RabbitMQ 或 Keystone，或者/etc/kolla/nova-compute/nova.conf里的transport_url密码不对。解决：进计算节点docker exec -it nova_compute bash，cat /etc/nova/nova.conf | grep transport_url，对比控制节点的密码是否一致。不一致就重新kolla-genpwd后reconfigure。

4.4 坑四：实例拿不到 IP

现象：实例ACTIVE但console log显示一直在 DHCP 请求。原因是 Neutron 的 DHCP agent 没起来，或者 provider 网络的 bridge mapping 配错。解决：openstack network agent list看DHCP agent是否alive，不是就docker logs neutron_dhcp_agent；再看/etc/kolla/neutron-openvswitch-agent/ml2_conf.ini里bridge_mappings是否和创建网络时的physnet1一致。

4.5 坑五：Horizon 登录 500

现象：Dashboard 能打开但登录报 500。原因是 Keystone 的 endpoint 配错，或者 memcached 没起来。解决：openstack endpoint list看 keystone 的 public/internal/admin 三个 URL 是否都指向 VIP；docker logs keystone看有没有Connection refused到 memcached。Kolla 默认 memcached 在控制节点，如果被防火墙拦了就会这样。

5. 单机 All-in-One 与后续扩展的取舍

如果你只有一台机器，Kolla-Ansible 也支持 All-in-One，把multinode里所有组都填同一个 IP，globals.yml 里network_interface和neutron_external_interface可以指向同一块网卡的不同子接口。但我要提醒：单机跑 OpenStack 只能用来验证流程，性能极差，一台 16G 的机器跑完所有服务后剩不下多少给虚拟机。我一般建议先用 All-in-One 把流程走通，确认命令和参数都对，再上三节点。

扩展计算节点时，只需要在新机器上跑bootstrap-servers，把 IP 加进multinode的[compute]组，然后kolla-ansible -i multinode deploy --limit compute。注意新节点的主机名、时间同步、Docker 版本要和现有节点一致，否则会出现容器镜像版本不匹配的玄学问题。

验证一套私有云是否真的可用，我的习惯是跑一个"三件套"：创建实例能拿到 IP、能 SSH 进去、能挂一块卷并格式化。这三步过了，基本就能交给业务用了。后面再折腾 Cinder 后端、Neutron VXLAN、Ceilometer 监控，都是在这个地基上加东西。希望帮到你。

本文还有配套的精品资源，点击获取