简介：这份PDF面向云计算运维人员、OpenStack初学者及需要落地私有云的技术团队，系统梳理基于OpenStack搭建私有云的完整实践路径，帮助读者理解从基础环境准备到核心组件集成的关键环节。资源包共1个PDF文件，大小约1.64MB，内容以图文步骤与配置说明为主，便于按章节查阅与对照实践。文档围绕Rancher容器基础环境、NTP时间同步、NOVA计算服务、NEUTRON网络服务等核心模块展开，并延伸至Cinder、Glance、Swift、Horizon等组件的安装配置，同时覆盖安全监控、自动化部署与测试优化等运维要点。目录结构清晰，包含compute01节点操作、PackStack快速安装、Cell创建、用户查看、页面登录与日志排查等实操记录，适合作为私有云部署的参考手册与排错指南。目前已有890人学习下载，可供读者在搭建与验证OpenStack环境时借鉴具体配置思路。
1. 从一台 CentOS 7 容器说起：这份 OpenStack 私有云搭建笔记到底能跑通什么
如果你手上只有一两台物理机，却想搭一套能创建云主机、能绑浮动 IP、能 SSH 登录的私有云环境，这份《私有云实践-基于 OpenStack 的私有云搭建》大概率能帮你省掉大量翻官方文档的时间。它不讲 OpenStack 各组件的抽象概念，而是直接以 compute01 计算节点为主线，从 Rancher 生成容器、NTP 时间同步、NOVA 计算服务安装，一路写到 NEUTRON 网络服务、PackStack 快速安装、实例管理、计算节点扩展、镜像与数据管理、网络拓扑创建，最后落到聚合多物理节点创建云主机的完整流程。适合正在做 OpenStack 私有云搭建、需要一份可照抄的 CentOS 7 + Liberty 版本实操记录的运维和云计算从业者。下面按「资源是什么 → 怎么用 → 坑在哪」的顺序拆开讲。
2. 基础环境与 NOVA 计算服务：从容器生成到服务注册的完整链路
2.1 用 Rancher 或 Docker 生成 compute01 容器
这份笔记的第一步不是装系统，而是用 Rancher 生成容器作为基础环境。原文给了一条 Docker 直接创建的命令，我把它整理成可直接执行的版本：
# 创建 controller 容器，privileged=true 让容器内可以跑 systemd docker run -d --name controller --privileged=true \ docker.io/sf2gis/openstack:ntp /usr/sbin/init # 进入容器 docker exec -it controller /bin/bash逻辑说明：--privileged=true是必须的，因为容器里要跑 libvirtd、nova-compute 这类需要访问内核模块和设备的服务，普通容器权限不够。/usr/sbin/init作为入口命令，是为了让容器内能用 systemctl 管理服务，否则 systemctl 会报 “Failed to get D-Bus connection”。
参数说明：容器名controller对应控制节点，计算节点在 Rancher 里要单独设置 IP10.42.0.11和主机名compute01。进入容器后第一件事是写/etc/hosts：
# 在 compute01 容器内执行 cat >> /etc/hosts <<EOF 10.42.0.10 controller 10.42.0.11 compute01 EOF这一步不做，后面 nova-compute 连 controller 的 RabbitMQ 会直接失败，而且报错信息往往只显示连接超时，排查起来很费时间。
2.2 NTP 时间同步：分布式系统的隐形地基
OpenStack 各节点之间靠消息队列通信，时间不同步会导致 token 校验失败、日志时间错乱、服务注册异常。笔记里明确要求 compute01 同步 controller 的时间。常见做法是在 compute01 上装 chrony 或 ntpdate，指向 controller：
# 安装 chrony yum install chrony -y # 编辑 /etc/chrony.conf，把 server 指向 controller sed -i 's/^server.*/server controller iburst/' /etc/chrony.conf # 启动并设置开机自启 systemctl enable chronyd.service systemctl start chronyd.service # 验证同步状态 chronyc sources -v逻辑说明：iburst参数让 chrony 在启动时快速发送一组包，缩短首次同步时间。验证时看chronyc sources输出里 controller 前面有没有^*，有就说明同步成功。如果显示^?，说明 controller 的 NTP 服务没起来或者防火墙挡了 UDP 123。
2.3 修改 YUM 源并安装 NOVA 计算服务
原文花了大量篇幅在 YUM 源修改上，这不是啰嗦，而是因为 CentOS 7 默认源里没有 OpenStack Liberty 的包。笔记里备份源、改 Base 源、加 OpenStack Liberty 源、改 rdo-release.repo 和 rdo-testing.repo，步骤很细。我把它压缩成可执行的核心操作：
# 备份原有源 mkdir -p /etc/yum.repos.d/bak_tmp cp /etc/yum.repos.d/*.repo /etc/yum.repos.d/bak_tmp/ # 安装 OpenStack Liberty 源 yum install centos-release-openstack-liberty -y # 安装 nova-compute yum install openstack-nova-compute -y逻辑说明：centos-release-openstack-liberty这个包会自动写入正确的 repo 文件，比手动改五六个 repo 文件更稳。原文手动改源的方式适合源包不可用或需要指定 buildlogs 地址的场景。装完 nova-compute 后，先确认 CPU 是否支持硬件加速：
egrep -c '(vmx|svm)' /proc/cpuinfo返回 1 或更大值，说明支持 KVM 加速，不用额外配置。返回 0，就必须在/etc/nova/nova.conf的[libvirt]段里加virt_type = qemu，否则实例创建会卡在 spawn 阶段。
2.4 配置 nova.conf 并启动服务
原文的 nova.conf 配置是整份笔记里最值得抄的部分。它先备份、再用egrep -v "^#|^$"去掉注释和空行，得到一个干净配置，然后逐段写入。核心段落如下：
[DEFAULT] enabled_apis = osapi_compute,metadata transport_url = rabbit://openstack:abc123@controller auth_strategy = keystone my_ip = 10.42.0.11 use_neutron = True firewall_driver = nova.virt.firewall.NoopFirewallDriver [keystone_authtoken] auth_uri = http://controller:5000 auth_url = http://controller:35357 memcached_servers = controller:11211 auth_type = password project_domain_name = Default user_domain_name = Default project_name = service username = nova password = nova [vnc] enabled = True vncserver_listen = 0.0.0.0 vncserver_proxyclient_address = $my_ip novncproxy_base_url = http://controller:6080/vnc_auto.html [glance] api_servers = http://controller:9292 [oslo_concurrency] lock_path = /var/lib/nova/tmp参数说明：my_ip必须写计算节点自己的管理 IP，写错会导致 VNC 代理地址不对。firewall_driver设为 NoopFirewallDriver 是因为 Neutron 已经接管了网络和防火墙，Nova 再管会冲突。transport_url里的abc123是 RabbitMQ 密码，要和 controller 上保持一致。lock_path目录必须存在且 nova 用户可写，否则并发操作会报锁文件错误。
启动服务：
systemctl enable libvirtd.service openstack-nova-compute.service systemctl start libvirtd.service openstack-nova-compute.service原文特别提醒：polkit 服务可能启动失败，重装后重启可以解决；重启后要检查/etc/hosts保证 controller 可解析。这两条都是实际踩过的坑。
2.5 在 controller 端验证计算节点注册
计算节点服务起来后，必须到 controller 上验证：
# 加载 admin 凭证 source admin-openrc # 列出计算服务 openstack compute service list # 列出 nova 服务组件 nova service-list # 查看认证服务端点 nova endpoints逻辑说明：openstack compute service list应该显示四个服务组件在控制节点上启用，一个在计算节点上启用。如果 compute01 没出现，先看 compute01 上systemctl status openstack-nova-compute的状态，再看/var/log/nova/nova-compute.log里有没有连 RabbitMQ 或 Keystone 失败的记录。常见原因是/etc/hosts没写对，或者 RabbitMQ 密码不匹配。
3. NEUTRON 网络服务与 PackStack：两条部署路线的取舍
3.1 安装 neutron-linuxbridge 并配置通用组件
NOVA 管计算，NEUTRON 管网络。原文在 compute01 上装的是openstack-neutron-linuxbridge，这是 Linux 桥接代理，适合没有硬件 SDN 设备的场景。
yum install openstack-neutron-linuxbridge ebtables ipset -y装完后配置/etc/neutron/neutron.conf，同样先备份、去注释、再写核心段：
[DEFAULT] transport_url = rabbit://openstack:abc123@controller auth_strategy = keystone [keystone_authtoken] auth_uri = http://controller:5000 auth_url = http://controller:35357 memcached_servers = controller:11211 auth_type = password project_domain_name = Default user_domain_name = Default project_name = service username = neutron password = neutron参数说明：transport_url和 nova 用的是同一个 RabbitMQ，但用户名密码是 neutron 的。auth_strategy = keystone表示认证走 Keystone。如果这里密码写错，neutron-linuxbridge-agent 会反复重启，日志里报AMQP server on controller:5672 is unreachable。
3.2 配置 Linux 桥接代理并重启服务
Linux 桥接代理的配置文件在/etc/neutron/plugins/ml2/linuxbridge_agent.ini，核心是物理网卡映射和 VXLAN 开关：
[linux_bridge] physical_interface_mappings = provider:eth0 [vxlan] enable_vxlan = True local_ip = 10.42.0.11 l2_population = True [securitygroup] enable_security_group = True firewall_driver = neutron.agent.linux.iptables_firewall.IptablesFirewallDriver参数说明：physical_interface_mappings里的provider:eth0表示把宿主机的 eth0 映射为 provider 网络，eth0 要换成实际网卡名。local_ip写计算节点管理 IP。l2_population = True开启 VXLAN 的 L2 填充，减少广播。改完后重启服务：
systemctl restart neutron-linuxbridge-agent.service systemctl enable neutron-linuxbridge-agent.service验证还是在 controller 上执行openstack network agent list，看 compute01 上的 Linux bridge agent 是否 Alive 且 State 为 UP。
3.3 PackStack 快速安装：适合验证，不适合生产
原文第 2 章给了 PackStack 快速安装路线。PackStack 是 RDO 提供的自动化部署工具，一条命令能拉起全部核心组件，适合快速验证和实验环境。核心步骤：
# 安装 PackStack yum install openstack-packstack -y # 生成应答文件 packstack --gen-answer-file=answer.txt # 编辑 answer.txt，至少改这几项 # CONFIG_DEFAULT_PASSWORD=xxx # CONFIG_NOVA_COMPUTE_HOSTS=10.42.0.11 # CONFIG_NEUTRON_L2_AGENT=linuxbridge # 执行安装 packstack --answer-file=answer.txt逻辑说明：--gen-answer-file生成模板，改完再执行，比交互式安装可控。安装完成后原文提到要创建 Cell、查看用户、页面登录、查看日志。Cell 是 Nova 的单元概念，Liberty 版本里默认只有一个 cell，创建 cell 是为了后续扩展。页面登录走 Horizon，默认地址是http://controller/dashboard，账号 admin，密码在 answer.txt 里。
PackStack 的边界：它把配置都写死了，后期改一个参数可能牵动多个服务，生产环境更推荐手动分组件部署或者用 Kolla。这份笔记把 PackStack 作为快速验证路线，定位是准确的。
3.4 实例管理：从创建到 VNC 和 SSH
原文第 3 章讲 OpenStack 管理，实例管理是核心。创建实例前要准备镜像、网络、安全组、密钥对。创建完成后，两种管理方式：
VNC：在 Horizon 里点击实例名称，进控制台或 VNC，能直接看到系统界面。适合调试启动阶段的问题，比如实例卡在 grub 或网络没配好。
SSH：先绑定浮动 IP，再用 SSH 远程管理。浮动 IP 从外部网络分配，绑到实例的端口上。绑定后如果 SSH 不通，先检查安全组有没有放行 22 端口，再检查实例内部防火墙，最后看路由器有没有正确连接内外网。
实例控制操作包括启动、停止、删除、编辑。删除实例时要注意，如果实例有挂载的卷，先卸载再删，否则卷会残留。
3.5 计算节点扩展：加节点比装第一个节点更容易翻车
原文 3.4 节讲计算节点扩展，步骤和装第一个计算节点类似，但有几个额外注意点：
配置 hostname 时改/etc/hosts，把新节点和 controller 都写进去。配置 nova 时，参数参考 controller 上的配置，但my_ip要改成新节点的 IP。启动服务后，到 controller 上验证openstack compute service list，看新节点是否注册。
常见翻车点：新节点的 YUM 源没配好，装出来的 nova 版本和 controller 不一致；新节点的 NTP 没同步，导致 token 校验失败；新节点的/etc/hosts里 controller 解析不对，连不上 RabbitMQ。这三个问题占扩展失败原因的八成以上。
4. 网络拓扑与存储管理：外部网络、内部网络、路由器怎么串
4.1 创建外部网络和内部网络
原文 3.7 节把网络管理讲得很清楚。外部网络在管理员视角创建，模拟物理网卡，是物理网卡的代理。创建时要指定 provider 网络的 VLAN 或 flat 类型，以及物理网卡映射。
内部网络在项目视角创建，模拟内部局域网。创建时指定子网和 CIDR，比如192.168.1.0/24。内部网络的实例默认不能访问外网，需要路由器做 NAT。
创建外部网络的命令示例：
# 加载 admin 凭证 source admin-openrc # 创建外部网络 openstack network create --share --external \ --provider-physical-network provider \ --provider-network-type flat public # 创建外部子网 openstack subnet create --network public \ --allocation-pool start=10.42.0.100,end=10.42.0.200 \ --dns-nameserver 114.114.114.114 \ --gateway 10.42.0.1 \ --subnet-range 10.42.0.0/24 public-subnet参数说明：--external标记为外部网络，--share让所有项目可见。--provider-physical-network provider对应 linuxbridge_agent.ini 里的映射名。--allocation-pool是浮动 IP 池，范围要在物理网络里可用且没被占用。
4.2 创建路由器并连接内外网
路由器是外部网络和内部网络的连接器。创建路由器时指定外部网络，然后添加内部子网接口：
# 创建路由器 openstack router create router1 # 设置路由器外部网关 openstack router set router1 --external-gateway public # 把内部子网加到路由器 openstack router add subnet router1 private-subnet逻辑说明：--external-gateway public让路由器能走外部网络出去。add subnet把内部子网挂到路由器上，路由器自动做 NAT，内网实例就能访问外网。如果内网实例 ping 不通外网，先检查路由器的外部网关设了没，再检查外部网络的子网网关是否可达。
4.3 外网访问内网：绑定浮动 IP
内网访问外网靠路由器 NAT，外网访问内网靠浮动 IP。浮动 IP 从外部网络的 allocation pool 里分配，绑到实例的端口上：
# 创建浮动 IP openstack floating ip create public # 绑定到实例 openstack server add floating ip my-instance 10.42.0.101绑定后，从外部网络里的机器就能 SSH 到10.42.0.101。如果 SSH 不通，按顺序查：安全组有没有放行 22、实例内部 sshd 有没有起来、路由器有没有正确连接内外网、浮动 IP 有没有真的绑到实例端口上。
4.4 Swift 与 Cinder：对象存储和块存储的分工
原文 3.6 节区分了 Swift 和 Cinder。Swift 是对象存储，类似 Web 服务的网盘，适合存镜像、备份、静态文件。Cinder 是块存储，提供硬盘及网络存储，挂到实例上当数据盘用。
选型理由：需要共享、可扩展、通过 HTTP 访问的，用 Swift；需要挂到单台实例上、像本地硬盘一样读写、支持快照的，用 Cinder。两者不是替代关系，是互补关系。私有云里如果只是跑几台云主机，Cinder 更常用；如果要存大量非结构化数据，Swift 更合适。
5. 避坑与排查：这份笔记里没写全但一定会遇到的五个问题
5.1 现象：nova-compute 启动后反复重启，日志报 AMQP 连接失败
原因：compute01 的/etc/hosts里没有 controller 的解析记录，或者 RabbitMQ 密码和 controller 不一致。
解决：先ping controller确认解析，再cat /etc/nova/nova.conf | grep transport_url对比 controller 上的密码。改完重启openstack-nova-compute。
5.2 现象：实例创建卡在 spawn 阶段，长时间不变成 ACTIVE
原因：CPU 不支持硬件加速，但 nova.conf 里没配virt_type = qemu，libvirt 尝试用 KVM 启动失败。
解决：egrep -c '(vmx|svm)' /proc/cpuinfo确认返回值，如果是 0，在/etc/nova/nova.conf的[libvirt]段加virt_type = qemu，重启 nova-compute 和 libvirtd。
5.3 现象：实例绑了浮动 IP，但 SSH 不通
原因：安全组没放行 22 端口，或者路由器没连内外网，或者浮动 IP 没绑到正确端口。
解决：openstack security group rule list看有没有 22 规则；openstack router show router1看外部网关和接口；openstack server show my-instance看浮动 IP 有没有在 addresses 里。
5.4 现象：PackStack 安装到一半报错退出，重跑也失败
原因：之前安装残留了配置或数据库，PackStack 不是幂等的。
解决：清理/etc/nova、/etc/neutron、/etc/keystone等目录下的配置，删掉 MariaDB 里的相关库，再重跑。更稳的做法是重装系统或回滚快照。
5.5 现象：计算节点扩展后，新节点上的实例 VNC 打不开
原因：新节点的vncserver_proxyclient_address写的是旧 IP，或者 controller 上的 novncproxy 连不到新节点的 VNC 端口。
解决：检查新节点 nova.conf 里的my_ip和vncserver_proxyclient_address，确保是当前节点 IP。在 controller 上curl新节点的 6080 端口，确认网络可达。
6. 聚合多物理节点创建云主机：从规划到 SSH 登录的完整验证
原文第 4 章是整份笔记的收口，把前面所有组件串成一条完整链路。整体规划阶段要确定控制节点、计算节点、网络节点的角色分配，以及管理网络、业务网络、存储网络的网段划分。添加计算节点时，按 3.4 节的步骤扩展，每加一个节点就在 controller 上验证一次服务注册。
安装操作系统镜像时，常见做法是用openstack image create上传 qcow2 镜像，指定--disk-format qcow2 --container-format bare。创建安全组时，至少放行 22 和 ICMP，否则 SSH 和 ping 都不通。创建密钥对时，公钥存在 OpenStack 里，私钥下载到本地，SSH 时用-i指定私钥。
创建网络拓扑时，按 4.1 到 4.3 的顺序：先外部网络，再内部网络，再路由器，最后浮动 IP。创建实例时分配资源、系统、网络，启动后进控制台看启动日志，确认 cloud-init 正常执行。绑定浮动 IP 后，用 SSH 远程管理，验证整条链路。
整体概况验证清单：
| 验证项 | 命令 | 预期结果 |
|---|---|---|
| 计算服务 | openstack compute service list | 控制节点 4 个，计算节点 1 个 |
| 网络代理 | openstack network agent list | Linux bridge agent Alive |
| 实例状态 | openstack server list | 实例 ACTIVE |
| 浮动 IP | openstack floating ip list | 已绑定到实例端口 |
| SSH 连通 | ssh -i private.key user@floating-ip | 登录成功 |
我自己的习惯是，每加一个计算节点、每改一次网络配置，都强制走一遍这张表。有一次扩展节点后忘了验证网络代理，结果新节点上的实例死活拿不到 IP，查了两个小时才发现是 linuxbridge agent 没起来。从那以后我每次扩展节点都先跑openstack network agent list，确认新节点的 agent 是 Alive 再继续。希望帮到你。
本文还有配套的精品资源，点击获取
 精准编排视图动画时序)
