企业官网建设流程全解析

简介：这份《Openstack安装部署手册》面向云计算运维人员、OpenStack初学者及需要搭建私有云环境的工程师，以Havana版本为基准，系统梳理从环境准备到核心组件落地的完整部署路径。内容涵盖网卡配置、主机名修改、MySQL数据库安装等前置步骤，并逐一讲解Keystone认证服务、Glance镜像服务、Nova计算服务、Swift对象存储、Cinder块存储与Neutron网络服务的安装与配置要点，同时涉及Messaging Server通信、授权令牌定义、密钥与证书配置、用户租客与roles划分、API endpoint创建等关键环节。资源包内含1个docx文档，大小约519KB，目录结构清晰，按章节组织便于对照查阅。目前已有369人学习关注，适合希望快速掌握OpenStack组件关系与部署流程、减少环境搭建试错成本的读者参考使用。

1. 从一份 Openstack 安装部署手册说起：Havana 版云平台到底怎么落地

很多人第一次接触 Openstack，都是被一份《Openstack安装部署手册.docx》带进门的。文档里写着 Havana 版本、控制节点、计算节点、网络节点，看着像一份标准作业指导书，真照着敲命令时却处处卡壳：Keystone 起不来、Nova 连不上 RabbitMQ、Neutron 的网桥配完虚拟机就是不通。问题不在你手笨，而在于 Openstack 从来不是「装几个包」那么简单，它是一整套云平台的编排系统，安装部署的本质是把认证、计算、存储、网络、消息队列、数据库这几条链路按正确顺序串起来。这篇笔记就围绕这份手册背后的技术栈，把 Havana 时代的经典部署路径拆开讲清楚：它解决的是「从零搭出一套能创建虚拟机的私有云」这件事，适合手里有 3 台以上物理机或虚拟机、想真正跑通 Openstack 全流程的运维和云计算从业者。热词里常出现的 openstack云平台搭建、基于packstack安装openstack，其实都是这条路上的不同走法，后面会一并对比。

2. Havana 版 Openstack 的组件依赖与部署顺序：为什么顺序错了必翻车

2.1 先认清 Havana 的六个核心组件和它们的关系

Havana 是 Openstack 在 2013 年底发布的版本，代号对应的是那个时期最稳定的一套架构。它的核心组件包括：Keystone 负责认证和令牌发放，是所有组件的前置依赖；Glance 管镜像；Nova 管计算实例生命周期；Neutron 管网络；Cinder 管块存储；Horizon 提供 Web 控制台。除此之外还有两个「隐形主角」：RabbitMQ 做组件间消息通信，MySQL 存各服务的状态数据。

这些组件的依赖关系是单向的：Keystone 最先，因为它要给其他所有服务发令牌；MySQL 和 RabbitMQ 要在 Keystone 之前就绪，因为 Keystone 自己也要存数据、也要发消息。Glance、Nova、Neutron、Cinder 之间没有严格的先后，但它们都必须在 Keystone 注册完 endpoint 之后才能正常通信。Horizon 最后装，因为它依赖前面所有服务的 API。

我一般把部署顺序固定成：系统基础环境 → MySQL → RabbitMQ → Keystone → Glance → Nova（控制节点）→ Neutron（控制节点）→ Cinder → Horizon → 计算节点 Nova → 网络节点 Neutron。这个顺序不是官方强制，但按它走，出问题时排查范围最小。

2.2 用 Packstack 快速验证还是手工分步部署

热词里「基于packstack安装openstack」出现频率很高，说明很多人想先快速看到效果。Packstack 是 Red Hat 系的一个应答式安装工具，一条命令就能把 all-in-one 或双节点的 Openstack 拉起来。它的优点是快，缺点是黑匣子——出错了你很难知道是哪一步的配置有问题。

我的建议是：如果你只是想验证 Openstack 能不能跑，用 Packstack 没问题；但如果你要真正理解安装部署手册里的每一步，必须手工分步做一遍。下面给一个 Packstack 的最小验证命令，再给手工部署的关键步骤。

# 在 CentOS 7 上安装 packstack（Havana 时代对应 RHEL/CentOS 6/7） yum install -y centos-release-openstack-havana yum install -y openstack-packstack # 生成应答文件，只装核心组件，all-in-one 模式 packstack --gen-answer-file=answer.txt # 编辑 answer.txt，关键参数如下： # CONFIG_KEYSTONE_ADMIN_PW=你的密码 # CONFIG_NOVA_COMPUTE_HOSTS=本机IP # CONFIG_NEUTRON_INSTALL=y # CONFIG_NEUTRON_L2_PLUGIN=openvswitch # CONFIG_GLANCE_INSTALL=y # CONFIG_CINDER_INSTALL=y # 执行安装 packstack --answer-file=answer.txt

这段命令的逻辑是：先装 Packstack 工具本身，生成一份默认应答文件，然后按需修改关键参数再执行。参数里CONFIG_KEYSTONE_ADMIN_PW是 Keystone 管理员密码，后面登录 Horizon 和做 API 调用都要用；CONFIG_NEUTRON_L2_PLUGIN选 openvswitch 是因为 Havana 时代 OVS 是主流，Linuxbridge 虽然也能用但功能受限。执行完如果看到Successfully installed不代表万事大吉，还要验证 Keystone 令牌能不能拿到、Nova 服务列表是不是全 up。

手工部署的关键步骤则是：先配好 hosts 解析和 SELinux 策略，再装 MySQL 并建库授权，然后装 RabbitMQ 并建 openstack 用户，接着装 Keystone 并初始化数据库、注册 admin 用户和 service 项目，最后才是 Glance、Nova 等。每一步做完都要用keystone token-get或nova service-list验证，不要攒到最后一起查。

2.3 控制节点、计算节点、网络节点的角色划分

Havana 时代最经典的部署拓扑是三个角色分开：控制节点跑 Keystone、Glance、Nova API、Neutron Server、Cinder API、Horizon、MySQL、RabbitMQ；计算节点只跑 Nova Compute 和 Neutron OVS Agent；网络节点跑 Neutron L3 Agent、DHCP Agent、Metadata Agent 和 OVS Agent。

这种划分的好处是职责清晰，坏处是网络节点容易成为瓶颈。如果只是测试环境，把三个角色合并到一台机器上也能跑，但生产环境不建议。判断一个节点该装什么，看它需要跟哪些服务通信：计算节点只需要跟控制节点的 RabbitMQ、MySQL、Keystone、Glance、Neutron 通信，所以它上面不需要装数据库和消息队列。

3. 手工部署 Keystone 与 Glance：从建库到验证令牌的完整命令

3.1 Keystone 的数据库初始化和 endpoint 注册

Keystone 是 Openstack 的认证入口，它自己也需要一个数据库存用户、项目、角色和令牌。手工部署时，先在 MySQL 里建库授权：

CREATE DATABASE keystone; GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'localhost' IDENTIFIED BY 'KEYSTONE_DBPASS'; GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'%' IDENTIFIED BY 'KEYSTONE_DBPASS'; FLUSH PRIVILEGES;

这段 SQL 做了两件事：建 keystone 库，然后授权本地和远程访问。KEYSTONE_DBPASS要换成你自己的密码，后面配置文件里要一致。注意@'%'是允许远程连接，如果控制节点和数据库不在同一台机器上，这条必须有。

接着装 Keystone 包、改配置文件、同步数据库：

yum install -y openstack-keystone python-keystoneclient # 编辑 /etc/keystone/keystone.conf # [database] # connection = mysql://keystone:KEYSTONE_DBPASS@控制节点IP/keystone # [DEFAULT] # admin_token = ADMIN_TOKEN # 同步数据库 su -s /bin/sh -c "keystone-manage db_sync" keystone # 初始化 admin 用户和角色 export OS_SERVICE_TOKEN=ADMIN_TOKEN export OS_SERVICE_ENDPOINT=http://控制节点IP:35357/v2.0 keystone user-create --name=admin --pass=ADMIN_PASS --email=admin@example.com keystone role-create --name=admin keystone tenant-create --name=admin keystone user-role-add --user=admin --tenant=admin --role=admin

这里的admin_token是 Keystone 的超级令牌，用于在还没有用户体系时做初始化操作。OS_SERVICE_TOKEN和OS_SERVICE_ENDPOINT是环境变量，告诉 keystone 客户端用哪个令牌和哪个地址。初始化完 admin 用户后，就可以用 admin 账号来注册其他服务的 endpoint 了。

注册 Glance 的 endpoint 示例：

keystone service-create --name=glance --type=image --description="Glance Image Service" keystone endpoint-create \ --service-id=$(keystone service-list | awk '/ image / {print $2}') \ --publicurl=http://控制节点IP:9292 \ --internalurl=http://控制节点IP:9292 \ --adminurl=http://控制节点IP:9292

service-create创建服务条目，endpoint-create创建访问入口。publicurl 给外部用户用，internalurl 给内部服务用，adminurl 给管理操作用。测试环境三者可以一样，生产环境建议分开。

3.2 Glance 的镜像存储后端选择与上传验证

Glance 管镜像，它的存储后端可以是本地文件系统、Swift、Ceph 等。Havana 时代最常用的是本地文件系统，简单直接。配置文件/etc/glance/glance-api.conf里关键项：

[DEFAULT] default_store = file filesystem_store_datadir = /var/lib/glance/images/ [database] connection = mysql://glance:GLANCE_DBPASS@控制节点IP/glance [keystone_authtoken] auth_uri = http://控制节点IP:5000 auth_host = 控制节点IP auth_port = 35357 auth_protocol = http admin_tenant_name = service admin_user = glance admin_password = GLANCE_PASS

default_store = file表示用本地文件存镜像，filesystem_store_datadir是存储路径。keystone_authtoken段是 Glance 向 Keystone 认证用的，admin_tenant_name一般是 service 项目，admin_user是 glance 用户。这些用户和项目要在 Keystone 里提前建好。

同步数据库、启动服务、上传测试镜像：

su -s /bin/sh -c "glance-manage db_sync" glance systemctl start openstack-glance-api systemctl start openstack-glance-registry # 下载一个测试用 cirros 镜像并上传 glance image-create --name="cirros" --disk-format=qcow2 \ --container-format=bare --file=cirros-0.3.2-x86_64-disk.img # 验证 glance image-list

glance-manage db_sync建表，两个 systemctl 启动 API 和 registry 服务。上传镜像时--disk-format和--container-format要跟镜像实际格式一致，cirros 是 qcow2 格式、bare 容器。上传完用glance image-list看到镜像状态是 active 才算成功。如果卡在 queued，多半是存储路径权限不对或 Keystone 认证失败。

4. Nova 与 Neutron 联调：实例起不来时先查这三条链路

4.1 Nova 控制节点与计算节点的配置差异

Nova 是 Openstack 的计算核心，控制节点跑 API、调度器、 conductor，计算节点跑 nova-compute。控制节点的/etc/nova/nova.conf关键配置：

[DEFAULT] auth_strategy = keystone rpc_backend = rabbit rabbit_host = 控制节点IP rabbit_userid = openstack rabbit_password = RABBIT_PASS my_ip = 控制节点IP [database] connection = mysql://nova:NOVA_DBPASS@控制节点IP/nova [keystone_authtoken] auth_uri = http://控制节点IP:5000 auth_host = 控制节点IP auth_port = 35357 auth_protocol = http admin_tenant_name = service admin_user = nova admin_password = NOVA_PASS

计算节点的 nova.conf 大部分一样，但my_ip要改成计算节点自己的 IP，并且要加vnc_enabled = true和vncserver_listen = 计算节点IP，否则控制台打不开。rpc_backend = rabbit表示用 RabbitMQ 做消息通信，rabbit_host指向控制节点。如果 RabbitMQ 连不上，Nova 服务会起不来或者起来后不响应。

同步数据库、启动服务：

su -s /bin/sh -c "nova-manage db sync" nova systemctl start openstack-nova-api systemctl start openstack-nova-scheduler systemctl start openstack-nova-conductor # 计算节点上 systemctl start openstack-nova-compute # 验证 nova service-list

nova service-list应该看到 nova-api、nova-scheduler、nova-conductor、nova-compute 都是 up 状态。如果有 down 的，先看日志/var/log/nova/下对应的 log，最常见的是 RabbitMQ 认证失败或数据库连不上。

4.2 Neutron 的 OVS 网桥配置与租户网络打通

Neutron 是 Havana 时代最复杂的组件，网络不通是新手最大的坑。控制节点的/etc/neutron/neutron.conf和/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini要配合改。关键配置：

# neutron.conf [DEFAULT] core_plugin = neutron.plugins.openvswitch.ovs_neutron_plugin.OVSNeutronPluginV2 rabbit_host = 控制节点IP rabbit_userid = openstack rabbit_password = RABBIT_PASS [database] connection = mysql://neutron:NEUTRON_DBPASS@控制节点IP/neutron [keystone_authtoken] auth_uri = http://控制节点IP:5000 admin_tenant_name = service admin_user = neutron admin_password = NEUTRON_PASS

# ovs_neutron_plugin.ini [ovs] tenant_network_type = gre tunnel_id_ranges = 1:1000 integration_bridge = br-int tunnel_bridge = br-tun local_ip = 控制节点IP [securitygroup] firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver

tenant_network_type = gre表示租户网络用 GRE 隧道，tunnel_id_ranges是隧道 ID 范围。local_ip是本节点用于隧道通信的 IP。网络节点还要配 L3 agent 和 DHCP agent，计算节点只跑 OVS agent。

创建租户网络和子网：

neutron net-create demo-net neutron subnet-create demo-net 10.0.0.0/24 --name demo-subnet --gateway 10.0.0.1 neutron router-create demo-router neutron router-interface-add demo-router demo-subnet neutron router-gateway-set demo-router external-net

这几条命令创建了一个租户网络、子网、路由器，并把路由器连到外部网络。external-net是提前创建好的外部网络，对应物理网卡。如果虚拟机起不来但网络配置看着都对，先查neutron agent-list看各 agent 是不是 alive，再查 OVS 网桥ovs-vsctl show看 br-int、br-tun、br-ex 是不是都在。

4.3 用 cirros 实例验证全链路

前面都配好后，启动一个 cirros 实例做端到端验证：

nova boot --flavor m1.tiny --image cirros --nic net-id=$(neutron net-list | awk '/ demo-net / {print $2}') test-vm nova list nova console-log test-vm

nova boot创建实例，--flavor选规格，--image选镜像，--nic指定网络。创建后用nova list看状态，从 BUILD 变成 ACTIVE 才算成功。如果一直 BUILD，看nova console-log和/var/log/nova/nova-compute.log。能 ping 通实例 IP、能 SSH 进去，说明 Keystone、Nova、Neutron、Glance 全链路通了。

5. Openstack 安装部署避坑：这 5 个问题让新手反复重装

5.1 现象：Keystone 启动报 503，日志显示数据库连接失败

原因通常是 keystone.conf 里的 connection 字符串格式不对，或者 MySQL 用户授权没做远程访问。Havana 时代 SQLAlchemy 的连接串是mysql://user:pass@host/db，少一个斜杠或密码里有特殊字符都会失败。解决方法是先用mysql -u keystone -p -h 控制节点IP手动连一次，确认能连上再改配置文件。如果密码里有@或#，要在配置文件里转义或换密码。

5.2 现象：Nova 服务列表里 nova-compute 是 down

先看计算节点的/var/log/nova/nova-compute.log，最常见的原因是 RabbitMQ 连不上或my_ip配错。RabbitMQ 连不上一般是 openstack 用户没建或权限不对，用rabbitmqctl list_users和rabbitmqctl list_permissions检查。my_ip如果配成了 127.0.0.1，控制节点就找不到计算节点。解决方法是改my_ip为计算节点真实 IP，重启 nova-compute，再在控制节点nova service-list确认。

5.3 现象：虚拟机创建后一直 BUILD，最后变成 ERROR

看nova console-log和计算节点的 nova-compute.log。常见原因有三个：Glance 镜像没上传成功或格式不对；Neutron 网络没配通，实例拿不到 IP；计算节点没装 KVM 或嵌套虚拟化没开。如果是嵌套虚拟化环境，要在物理机的 KVM 里给虚拟机开nested参数。解决方法是先glance image-list确认镜像 active，再neutron net-list确认网络存在，最后在计算节点virsh list --all看实例有没有真正起来。

5.4 现象：Horizon 能登录但看不到实例或报错

Horizon 的配置文件/etc/openstack-dashboard/local_settings里OPENSTACK_HOST要指向控制节点 IP，OPENSTACK_KEYSTONE_URL要写http://控制节点IP:5000/v2.0。如果登录后报权限错误，检查 Keystone 里 admin 用户的角色和项目绑定对不对。Havana 时代 Horizon 对浏览器版本也有要求，太新的浏览器可能不兼容，换 Firefox ESR 或旧版 Chrome 试试。

5.5 现象：重启后所有服务起不来，手动启动又正常

这是 SELinux 和防火墙的锅。Havana 时代很多手册让你关 SELinux 和 firewalld，但生产环境不能关。正确做法是给 Openstack 相关端口加防火墙规则，给 SELinux 加策略或设成 permissive 先验证。如果关了 SELinux 还是起不来，检查服务是不是设了开机自启：systemctl enable openstack-keystone等。重启后服务顺序也有影响，MySQL 和 RabbitMQ 要先起来，其他服务才能连上。

6. 从 Havana 手册到现代 Openstack：一套验证部署是否成功的检查清单

Havana 虽然老，但它把 Openstack 的核心链路暴露得最清楚。现代版本用 Kolla-Ansible、TripleO 或 Openstack-Helm 部署，底层逻辑没变，只是容器化和自动化了。如果你手里有一份 Havana 安装部署手册，别急着逐条敲，先按下面的清单验证每一步：

这张表我每次部署完都会跑一遍，任何一项不对就停下来查，不要往下走。Havana 时代最容易忽略的是 endpoint 的 adminurl，很多操作失败是因为 adminurl 写成了 publicurl，导致服务间调用走外部地址被防火墙拦了。

最后一个技巧：把部署过程写成脚本，但不要写成一个大脚本。按组件拆成多个小脚本，每个脚本只做一件事，执行完输出验证结果。这样出问题时你知道是哪个组件挂了，重跑也只需要重跑那一个。我早期图省事写了一个 all-in-one 脚本，结果 Keystone 挂了导致后面全挂，排查了一整天才发现是 MySQL 密码里有个特殊字符没转义。从那以后我坚持分步验证，每一步都留后悔药。希望帮到你。

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