简介这份《Openstack安装部署手册》面向云计算运维人员、OpenStack初学者及需要搭建私有云环境的技术人员以Havana版本为基准系统讲解从零部署开源IaaS平台的关键流程。资源为单个docx文档压缩包约519KB内容按章节组织涵盖环境准备、组件整体结构、OpenStack核心包安装、Keystone认证服务配置、Glance镜像服务配置等模块并细化了网卡配置、主机名修改、MySQL数据库安装、Messaging Server部署、授权令牌定义、密钥与证书配置、用户租客与roles定义、API endpoint创建等具体操作要点。读者可借助这份手册理清各组件之间的依赖关系与配置顺序掌握身份验证、镜像、计算、存储、网络等服务的安装思路适合作为实验环境搭建与部署排错的参考。目前已有369人学习对希望快速上手OpenStack部署的读者具有一定参考价值。1. 从一份 Openstack 安装部署手册说起为什么手把手搭云平台总在第三步翻车很多人第一次接触 Openstack 安装部署都是被一份《Openstack安装部署手册.docx》带进门的。文档写得清清楚楚先装 Keystone 做认证再上 Glance 管镜像然后 Nova 跑计算最后 Horizon 给个界面。照着敲前两步往往顺利到第三步就开始报错——服务起不来、数据库连不上、消息队列超时。这不是你手笨而是 Openstack 本身就是一个由十几个组件拼起来的分布式系统组件之间的依赖关系比手册里写的“按顺序装”复杂得多。这份手册真正要解决的不是“怎么敲命令”而是“怎么让这些组件在同一个网络、同一个数据库、同一个消息队列下互相认识”。它适合两类人一是需要在内网搭一套私有云做测试或教学的运维二是想理解云平台底层怎么运转的开发者。如果你只是想快速跑个虚拟机其实有更轻的路子但如果你要吃透 Openstack这份手册里的组件拆解就是最好的入口。下面我按自己踩过的坑把这份手册背后的部署逻辑重新讲一遍。2. 拆解手册里的核心组件Keystone、Glance、Nova 到底谁依赖谁2.1 三个核心组件的角色与依赖关系Openstack 的组件不是平级的它们有明确的调用链。Keystone 是认证服务所有其他组件在启动时都要向它注册自己的端点endpoint运行时也要拿 token 去访问其他服务。Glance 是镜像服务负责存储和检索虚拟机镜像它自己不做计算但 Nova 创建虚拟机时必须从 Glance 拉镜像。Nova 是计算服务负责调度、创建、销毁虚拟机实例它依赖 Keystone 做认证、依赖 Glance 拿镜像、依赖 Neutron 拿网络、依赖 Placement 做资源跟踪。手册里通常按 Keystone → Glance → Nova 的顺序写这个顺序是对的但手册不会告诉你Keystone 的数据库和消息队列必须先于所有服务就绪Glance 的存储后端必须在 Nova 之前配置好Nova 的 cell 数据库在较大规模部署时需要单独初始化。我见过太多人在 Nova 启动时报“Unable to establish connection to http://keystone:5000/v3”回头查发现 Keystone 的 endpoint 里写的是主机名而 Nova 的配置文件里写的是 IP两者对不上。2.2 部署前必须确认的四个基础服务在敲任何 Openstack 组件安装命令之前有四样东西必须先跑起来并且验证通过基础服务作用验证命令常见问题MariaDB/MySQL存 Keystone、Glance、Nova 等的关系数据mysql -u root -p -e SHOW DATABASES;字符集不是 utf8mb4导致后续建表失败RabbitMQ组件间异步通信rabbitmqctl list_queues默认 guest 用户只能本地登录远程组件连不上Memcached存 Keystone 的 tokenecho stats | nc 127.0.0.1 11211监听地址是 127.0.0.1其他节点访问不到etcd存 Nova 的 cell 映射和 Placement 数据etcdctl endpoint health版本不匹配Nova 启动时报 API 版本错误这四个服务里RabbitMQ 和 Memcached 是最容易被忽略的。手册通常只写“安装并启动”但不会强调RabbitMQ 要创建一个专用用户并赋权Memcached 要改监听地址为 0.0.0.0如果组件跨节点部署。我一般会在装完这四个服务后用上面表格里的命令逐个验证确认无误再继续。2.3 用 Kolla-Ansible 还是手动装选型理由手册里写的通常是手动安装一步步 apt install 或 yum install然后改配置文件。这种方式适合理解原理但生产环境或需要反复重建的环境手动装就是灾难。现在社区更推荐 Kolla-Ansible它把每个 Openstack 服务打包成 Docker 容器用 Ansible 编排部署。好处是组件隔离、版本一致、升级回滚方便。坏处是出问题时排查链路变长需要懂 Docker 和 Ansible。我的建议是第一次学按手册手动装一遍把 Keystone、Glance、Nova 的配置文件和数据库表结构看明白第二次搭环境直接上 Kolla-Ansible。下面给一个 Kolla-Ansible 的最小化配置示例假设你已经装好 Docker 和 Ansible# 安装 kolla-ansible pip install kolla-ansible # 复制配置文件模板 cp -r /usr/share/kolla-ansible/etc_examples/kolla /etc/kolla/ cp /usr/share/kolla-ansible/ansible/inventory/all-in-one . # 生成密码 kolla-genpwd # 编辑 globals.yml关键参数如下# /etc/kolla/globals.yml 关键配置 kolla_base_distro: ubuntu kolla_install_type: source network_interface: eth0 neutron_external_interface: eth1 kolla_internal_vip_address: 10.0.0.100 enable_keystone: yes enable_glance: yes enable_nova: yes enable_neutron: yes enable_horizon: yes# 预检查 kolla-ansible -i all-in-one prechecks # 部署 kolla-ansible -i all-in-one deploy # 生成 admin-openrc 文件 kolla-ansible post-deploy这段配置里network_interface是管理网卡neutron_external_interface是给虚拟机通外网的网卡kolla_internal_vip_address是 HAProxy 的 VIP单节点部署时就是本机 IP。kolla-genpwd会生成所有服务的密码并写入/etc/kolla/passwords.yml不要手动改这个文件里的密码否则部署时会不一致。预检查阶段会验证网络、端口、依赖包如果这一步报错先解决再 deploy不要跳过。3. 手动部署 Keystone 与 Glance从建库到验证的完整命令链3.1 Keystone 的数据库初始化和 Fernet 密钥配置Keystone 是第一个要装的组件它的数据库和 token 机制决定了后面所有服务能不能正常认证。先建库建用户CREATE DATABASE keystone; GRANT ALL PRIVILEGES ON keystone.* TO keystonelocalhost IDENTIFIED BY KEYSTONE_DBPASS; GRANT ALL PRIVILEGES ON keystone.* TO keystone% IDENTIFIED BY KEYSTONE_DBPASS; FLUSH PRIVILEGES;注意%那条授权如果 Glance、Nova 和 Keystone 不在同一台机器上没有这条远程授权后面服务连数据库会直接拒绝。密码KEYSTONE_DBPASS要替换成你自己的并且和后面配置文件里的一致。Keystone 用 Fernet token 替代了早期的 UUID token需要生成两个密钥仓库一个用于签名一个用于加密。手册里通常只写“生成 Fernet 密钥”但不会说清楚这两个仓库的区别# 生成签名密钥仓库 keystone-manage fernet_setup --keystone-user keystone --keystone-group keystone # 生成加密密钥仓库 keystone-manage credential_setup --keystone-user keystone --keystone-group keystone签名密钥用于 token 的完整性校验加密密钥用于 token 中敏感信息的加密。两个仓库默认都在/etc/keystone/fernet-keys/下部署后不要手动删里面的文件否则所有已签发的 token 立即失效。3.2 启动 Keystone 并创建 service 实体与 endpoint配置文件/etc/keystone/keystone.conf里要改三处[database]的 connection、[token]的 provider fernet、[DEFAULT]的 log 路径。改完后同步数据库并启动su -s /bin/sh -c keystone-manage db_sync keystone systemctl enable --now keystone启动后不要急着往下走先验证 Keystone 本身是否正常export OS_USERNAMEadmin export OS_PASSWORDADMIN_PASS export OS_PROJECT_NAMEadmin export OS_USER_DOMAIN_NAMEDefault export OS_PROJECT_DOMAIN_NAMEDefault export OS_AUTH_URLhttp://controller:5000/v3 export OS_IDENTITY_API_VERSION3 openstack token issue如果这条命令返回了 token 的详细信息说明 Keystone 的认证链路通了。如果报 401检查ADMIN_PASS是否和初始化时设置的一致如果报连接拒绝检查 Keystone 服务是否监听在 5000 端口以及防火墙是否放行。接下来创建 service 实体和 endpoint这是后面 Glance、Nova 能注册进来的前提openstack service create --name keystone --description OpenStack Identity identity openstack endpoint create --region RegionOne identity public http://controller:5000/v3 openstack endpoint create --region RegionOne identity internal http://controller:5000/v3 openstack endpoint create --region RegionOne identity admin http://controller:5000/v3三个 endpoint 分别对应 public、internal、admin 三种网络场景。单节点部署时三者可以一样多节点时 public 和 internal 可能走不同网段。我一般会在创建完 endpoint 后用openstack endpoint list确认一遍确保没有重复或遗漏。3.3 Glance 的存储后端选型与镜像上传验证Glance 支持多种存储后端本地文件系统、NFS、Ceph、Swift。手册里通常用本地文件系统简单但不利于扩展。如果只是测试本地文件够用如果要接 Ceph配置文件里[glance_store]的stores和default_store要改成 rbd并且要提前在 Ceph 里建好 pool 和用户。本地文件后端的配置示例# /etc/glance/glance-api.conf [database] connection mysqlpymysql://glance:GLANCE_DBPASScontroller/glance [glance_store] stores file,http default_store file filesystem_store_datadir /var/lib/glance/images/建库、同步、启动的流程和 Keystone 类似su -s /bin/sh -c glance-manage db_sync glance systemctl enable --now glance-api验证 Glance 是否可用最直接的方式是上传一个 CirrOS 镜像wget http://download.cirros-cloud.net/0.6.2/cirros-0.6.2-x86_64-disk.img openstack image create cirros \ --file cirros-0.6.2-x86_64-disk.img \ --disk-format qcow2 \ --container-format bare \ --public openstack image list--disk-format qcow2要和镜像实际格式一致写错了后面 Nova 创建虚拟机会报格式不支持。--public表示所有项目可见测试环境方便生产环境按需改成--private再共享给指定项目。上传完成后openstack image list能看到状态是 active说明 Glance 的存储和数据库都正常。4. Nova 计算节点的部署与虚拟机创建从 cell 数据库到实例启动4.1 Nova 的 cell 架构与数据库拆分Nova 从 Newton 版本开始引入 cell 架构把计算节点的数据库从主数据库里拆出来减轻主库压力。手册里如果写的是较老版本可能还是单库新版本部署时nova-manage db sync之后还要执行nova-manage cell_v2 simple_cell_setup来创建默认 cell。# 主数据库同步 su -s /bin/sh -c nova-manage api_db sync nova su -s /bin/sh -c nova-manage cell_v2 map_cell0 nova su -s /bin/sh -c nova-manage cell_v2 create_cell --namecell1 --verbose nova su -s /bin/sh -c nova-manage db sync nova这几条命令的顺序不能乱先同步 API 数据库再映射 cell0存失败实例的记录再创建 cell1存正常实例最后同步 cell1 的数据库。如果跳过map_cell0后面创建虚拟机失败时没有地方记录错误信息排查会很困难。4.2 计算节点的 nova-compute 配置与发现控制节点装完 nova-api、nova-scheduler、nova-conductor 后计算节点只需要装 nova-compute。配置文件里关键几项# /etc/nova/nova.conf [DEFAULT] transport_url rabbit://openstack:RABBIT_PASScontroller my_ip 10.0.0.11 [api] auth_strategy keystone [keystone_authtoken] www_authenticate_uri http://controller:5000/ auth_url http://controller:5000/ memcached_servers controller:11211 auth_type password project_domain_name Default user_domain_name Default project_name service username nova password NOVA_PASS [glance] api_servers http://controller:9292 [oslo_concurrency] lock_path /var/lib/nova/tmp [placement] region_name RegionOne project_domain_name Default project_name service auth_type password user_domain_name Default auth_url http://controller:5000/v3 username placement password PLACEMENT_PASSmy_ip是计算节点自己的管理 IPtransport_url里的RABBIT_PASS要和 RabbitMQ 里创建的用户密码一致。启动 nova-compute 后在控制节点执行openstack compute service list应该能看到计算节点的状态是 enabled 和 up。如果状态是 down检查计算节点的 nova-compute 日志通常是认证失败或消息队列连不上。发现计算节点并加入 cellsu -s /bin/sh -c nova-manage cell_v2 discover_hosts --verbose nova这条命令要在每次新增计算节点后执行否则调度器不知道新节点的存在。可以配置scheduler.discover_hosts_in_cells_interval让它自动发现但生产环境我一般手动执行避免意外把未配置好的节点加进来。4.3 创建第一台虚拟机的完整命令与网络检查创建虚拟机之前需要先创建网络、子网、路由和 flavor。这里假设用 Neutron 的 provider 网络openstack network create --share --external \ --provider-physical-network physnet1 \ --provider-network-type flat public openstack subnet create --network public \ --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 public openstack flavor create --id 0 --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-id$(openstack network show public -f value -c id) \ --key-name mykey --security-group default myinstance--provider-physical-network physnet1要和 Neutron 的bridge_mappings配置一致否则虚拟机会创建成功但网络不通。--allocation-pool是给虚拟机分配的浮动 IP 范围不要和物理网络里已有的 IP 冲突。创建后用openstack server list看状态从 BUILD 变成 ACTIVE 通常需要十几秒。如果卡在 BUILD用openstack server show myinstance看 fault 字段常见原因是镜像格式不对、资源不足、或网络端口创建失败。5. 部署 Openstack 时最容易踩的五个坑现象、原因与解决5.1 坑一Keystone 报 401但密码明明是对的现象openstack token issue返回 401 Unauthorized确认密码和用户名都没错。原因Keystone 的[DEFAULT]里admin_token没注释掉或者[token]的provider不是 fernet导致 token 签发失败。另一个常见原因是 Memcached 没启动或监听地址不对Keystone 无法缓存 token。解决检查/etc/keystone/keystone.conf里[token] provider fernet确认 Memcached 在 11211 端口可访问重启 Keystone 后重试。5.2 坑二Glance 上传镜像成功但 Nova 创建虚拟机时报“找不到镜像”现象openstack image list能看到镜像状态 active但openstack server create时报 ImageNotFound。原因Glance 的 endpoint 注册时用了主机名而 Nova 的[glance] api_servers里写的是 IP或者反过来。Nova 通过 endpoint 拿到的 Glance 地址和实际能访问的地址不一致。解决统一用 IP 或统一用主机名确保/etc/hosts里解析正确。用openstack endpoint list --service glance确认 endpoint 地址和 Nova 配置文件里的api_servers对比。5.3 坑三计算节点状态是 up但调度器不往上面放虚拟机现象openstack compute service list显示 nova-compute 是 up但创建虚拟机时一直调度到其他节点或者报 NoValidHost。原因计算节点没有加入 cell或者 Placement 服务里没有该节点的资源记录。nova-manage cell_v2 discover_hosts没执行或者 Placement 的 endpoint 配置错误。解决在控制节点执行nova-manage cell_v2 discover_hosts --verbose然后openstack resource provider list确认计算节点的资源提供者存在。如果不存在检查 nova-compute 日志里的 Placement 连接错误。5.4 坑四虚拟机创建成功但网络不通ping 不到网关现象openstack server list显示 ACTIVE但控制台里 ping 网关不通。原因Neutron 的bridge_mappings配置和--provider-physical-network不一致或者安全组规则默认只允许 SSH 和 ICMP但没允许 DHCP。另一个常见原因是物理网卡没开混杂模式或者网桥没起来。解决检查/etc/neutron/plugins/ml2/linuxbridge_agent.ini里的physical_interface_mappings确认physnet1对应的网卡正确。用ip link show看网桥是否 up用brctl show看网卡是否挂到网桥上。安全组里临时加一条允许所有流量的规则测试。5.5 坑五重启后服务全部起不来数据库连接超时现象服务器重启后Keystone、Glance、Nova 全部报数据库连接超时。原因MariaDB 没有设置开机自启或者 RabbitMQ 的 guest 用户远程登录限制导致组件连不上消息队列。另一个原因是/etc/hosts在重启后被覆盖主机名解析失败。解决systemctl enable mariadb rabbitmq-server memcached确保开机自启。RabbitMQ 创建专用用户并赋权rabbitmqctl add_user openstack RABBIT_PASS和rabbitmqctl set_permissions openstack .* .* .*。检查/etc/hosts里 controller 和计算节点的主机名解析。6. 用 Kolla-Ansible 做多节点部署时我固定会改的三个参数手动装完一遍之后如果要把这套环境扩展到多节点或者需要反复重建Kolla-Ansible 是更实际的选择。但 Kolla-Ansible 的默认配置在多节点场景下有几个参数必须改否则部署会卡住或者性能很差。第一个是kolla_internal_vip_address和kolla_external_vip_address的分离。单节点时两者可以一样多节点时内部 VIP 走管理网外部 VIP 走业务网。如果混在一起Horizon 的访问和 API 的调用会互相干扰。我一般会在globals.yml里显式指定kolla_internal_vip_address: 10.0.0.100 kolla_external_vip_address: 192.168.1.100 kolla_external_vip_interface: eth1第二个是neutron_external_interface对应的网卡必须是一张没有 IP 的物理网卡或 VLAN 子接口。如果这张网卡上已经有 IPNeutron 创建外部网络时会报“设备被占用”。我习惯用ip addr flush dev eth1清掉 IP然后在globals.yml里指定neutron_external_interface: eth1。第三个是docker_registry和docker_namespace。默认从 Docker Hub 拉镜像国内环境经常超时。可以换成内网 registry或者提前把镜像拉到本地。Kolla-Ansible 支持docker_registry: registry.example.com:5000但要注意所有节点都要能访问这个 registry并且 Docker 配置了 insecure-registries如果是 HTTP。验证多节点部署是否成功我固定会做三件事kolla-ansible -i multinode check确认所有节点可达openstack compute service list确认所有计算节点 up创建一台虚拟机并openstack server ssh进去 ping 外网。这三步过了基本就能交付使用。最后说一个我自己的习惯每次部署完不管多顺利我都会把/etc/kolla/passwords.yml和globals.yml备份到本地并且在globals.yml里加一行注释写明这次部署的日期和改动点。Openstack 的部署状态太依赖配置文件没有后悔药只能靠备份。希望帮到你。本文还有配套的精品资源点击获取
