OpenStack安装部署手册：kolla-ansible与手动部署避坑指南

简介这份《Openstack安装部署手册》面向云计算运维工程师、OpenStack初学者及需要搭建私有云平台的IT从业者以Havana版本为基准系统讲解从零部署开源IaaS平台的关键流程。手册围绕环境准备、组件整体结构、核心组件安装与认证服务配置展开涵盖网卡配置、主机名修改、MySQL数据库安装、OpenStack单元包与Messaging Server部署并逐一说明Keystone、Glance、Nova、Swift、Cinder、Neutron等组件的功能定位与协作关系。其中Keystone部分详细记录了数据库连接创建、授权令牌定义、密钥与证书配置、服务启动及用户租客与roles定义等操作要点Glance部分则涉及数据连接、用户与roles添加、身份验证配置及凭证写入等步骤。资源包内含1个docx文档大小约519KB目录结构清晰按章节组织便于按模块查阅。目前已有369人学习适合希望快速掌握OpenStack部署思路、对照实践搭建云计算平台的读者参考。1. 从一份 Openstack 安装部署手册说起为什么很多人卡在第一步如果你在网上搜“Openstack安装部署手册.docx”大概率不是想读一份官方文档而是想找一份能照着敲、敲完能跑起来的东西。Openstack 这个名词本身不复杂它是一套开源云计算平台把计算、存储、网络、认证拆成若干独立服务通过 API 互相调用。但真正动手时很多人会在第一个服务 keystone 上就卡住——认证跑不通后面 glance、nova 全部连不上。这不是你能力问题而是 Openstack 的部署路径本身分叉太多有传统手动逐服务装、有 kolla-ansible 容器化批量装、有 devstack 单机脚本装。选错路径后面每一步都是坑。这篇笔记面向的是想在自己机器或几台测试服务器上把 Openstack 跑起来的人不追求生产级高可用只求理解每个组件在干什么、怎么装、参数怎么改、报错怎么查。读完你能独立完成一套最小可用环境的搭建并知道哪些地方最容易翻车。2. 部署路径选型kolla-ansible 还是手动逐服务装2.1 三条主流路径的适用边界Openstack 部署方式经过多年演化目前从业者常用的有三条路。第一条是 devstack本质是一个 shell 脚本集合把全部服务装在一台机器上适合读源码和开发调试但重启后状态容易丢不适合当“环境”用。第二条是手动逐服务安装按 keystone、glance、nova、neutron 的顺序一个个配能让你彻底看清每个服务的配置文件和数据库表但耗时极长一个参数写错就要回滚。第三条是 kolla-ansible用 Docker 容器跑每个服务通过 Ansible playbook 批量下发配置部署速度快、环境一致性好是目前社区和多数企业测试环境的首选。我一般会建议如果你目标是“先跑起来看看”选 kolla-ansible如果你目标是“搞懂每个服务怎么工作”选手动装但只装 keystone glance nova 三个核心。下面重点讲 kolla-ansible因为它在热词里出现频率最高也是最能复现的路径。2.2 kolla-ansible 部署的最小前置条件在动手前先确认基础环境。以两台机器为例一台控制节点同时跑 keystone、glance、nova-api、neutron-server一台计算节点跑 nova-compute、neutron-agent。操作系统用 CentOS 8 Stream 或 Ubuntu 22.04内核版本不低于 4.18。每台机器至少 8GB 内存、4 核 CPU、两块网卡一块管理网一块业务网。管理网用于 Ansible 下发和 API 通信业务网用于虚拟机流量。需要提前关掉防火墙和 SELinux否则容器间通信会被拦截。这不是偷懒是 kolla-ansible 默认配置没有为 firewalld 写规则。关闭命令如下# 关闭 firewalld 并禁止开机自启 systemctl stop firewalld systemctl disable firewalld # 临时关闭 SELinux永久关闭需改 /etc/selinux/config setenforce 0 sed -i s/^SELINUXenforcing/SELINUXpermissive/ /etc/selinux/config逻辑说明kolla-ansible 部署的容器使用 host 网络模式服务端口直接暴露在宿主机上firewalld 默认会阻断这些端口。SELinux 在 enforcing 模式下会阻止容器挂载宿主机目录导致 glance 镜像存储失败。参数说明setenforce 0只对当前会话生效改配置文件才能持久。生产环境应写精细规则而非直接关闭但测试环境先跑通再说。2.3 安装 kolla-ansible 与依赖在控制节点上执行# 安装 Python 虚拟环境和依赖 yum install -y python3-devel libffi-devel gcc openssl-devel git # 创建虚拟环境并安装 kolla-ansible python3 -m venv /opt/kolla-venv source /opt/kolla-venv/bin/activate pip install -U pip pip install ansible4,6 kolla-ansible逻辑说明kolla-ansible 对 Ansible 版本有要求太新或太旧都会导致 playbook 语法不兼容。这里锁定 4 到 6 之间。参数说明/opt/kolla-venv是虚拟环境路径可以改成任意目录。安装完成后用kolla-ansible --version验证。接着复制配置文件模板# 创建配置目录 mkdir -p /etc/kolla cp -r /opt/kolla-venv/share/kolla-ansible/etc_examples/kolla/* /etc/kolla/ # 生成随机密码写入 passwords.yml kolla-genpwd逻辑说明globals.yml是主配置文件passwords.yml存所有服务密码。kolla-genpwd会自动填充密码字段避免手动设弱密码。参数说明生成后可以用grep keystone_admin_password /etc/kolla/passwords.yml查看 admin 密码后面登录 dashboard 要用。2.4 编辑 globals.yml 的五个必改参数打开/etc/kolla/globals.yml以下五项必须改参数示例值作用kolla_base_distrocentos容器基础镜像发行版kolla_install_typebinary安装类型binary 比 source 快network_interfaceeth0管理网网卡名neutron_external_interfaceeth1业务网网卡名kolla_internal_vip_address10.0.0.100API 访问虚拟 IP逻辑说明network_interface填管理网卡Ansible 会用它做 API 通信。neutron_external_interface填业务网卡虚拟机流量走这里。kolla_internal_vip_address是 keepalived 提供的 VIP单节点也建议设方便后续扩展。参数说明网卡名用ip addr查看不要照抄 eth0可能是 ens33 或 enp3s0。2.5 执行部署与验证先做预检查kolla-ansible -i /opt/kolla-venv/share/kolla-ansible/ansible/inventory/all-in-one prechecks逻辑说明prechecks 会检查端口占用、磁盘空间、Python 版本、网卡配置。如果有报错先解决再往下走。参数说明-i指定 inventory 文件all-in-one 是单节点模板多节点用 multinode 并编辑文件填入 IP。预检查通过后正式部署kolla-ansible -i /opt/kolla-venv/share/kolla-ansible/ansible/inventory/all-in-one deploy逻辑说明deploy 会拉取容器镜像、创建数据库、启动服务。首次执行约 15 到 30 分钟取决于网速。参数说明如果卡在拉镜像可以配 Docker 镜像加速但不要用来源不明的加速地址。部署完成后生成 admin 凭据kolla-ansible post-deploy source /etc/kolla/admin-openrc.sh openstack token issue逻辑说明post-deploy把 admin 密码写入 openrc 文件。openstack token issue返回 token 说明 keystone 正常。参数说明如果报 401检查admin-openrc.sh里的密码和passwords.yml是否一致。3. keystone、glance、nova 三个核心服务的配置要点3.1 keystone认证服务的数据库与端点配置keystone 是 Openstack 的门卫所有服务调用前都要先过它。手动安装时keystone 的配置集中在/etc/keystone/keystone.conf。关键三处数据库连接、token 驱动、admin 端点。[database] connection mysqlpymysql://keystone:密码控制节点IP/keystone [token] provider fernet [resource] admin_project_domain_name Default admin_project_name admin逻辑说明connection指向 MySQL安装前需先建库并授权。provider fernet是当前主流 token 格式比 UUID token 更安全且支持撤销。admin_project_name定义管理员项目名后续创建服务用户时要用。参数说明密码不要用特殊字符否则 ini 解析可能出错。初始化数据库su -s /bin/sh -c keystone-manage db_sync keystone keystone-manage fernet_setup --keystone-user keystone --keystone-group keystone逻辑说明db_sync建表fernet_setup生成加密密钥。两条命令缺一不可否则启动后报 token 解密失败。参数说明--keystone-user指定运行用户必须和 systemd 服务里的 User 一致。3.2 glance镜像服务的存储后端选择glance 管镜像存储后端可以是本地文件、Ceph、NFS。测试环境用本地文件最简单。配置文件/etc/glance/glance-api.conf[glance_store] stores file,http default_store file filesystem_store_datadir /var/lib/glance/images/逻辑说明stores列出可用后端default_store指定默认。filesystem_store_datadir是镜像存放目录需确保 glance 用户有写权限。参数说明如果后续要接 Ceph把stores改成rbd并配[glance_store] rbd_store_pool。上传镜像验证openstack image create cirros \ --file cirros-0.5.2-x86_64-disk.img \ --disk-format qcow2 --container-format bare --public openstack image list逻辑说明--disk-format qcow2是 KVM 常用格式--container-format bare表示无额外封装。--public让所有项目可见。参数说明cirros 是轻量测试镜像约 16MB适合快速验证。3.3 nova计算服务的调度与 libvirt 配置nova 管虚拟机生命周期。控制节点跑 nova-api、nova-scheduler、nova-conductor计算节点跑 nova-compute。计算节点配置文件/etc/nova/nova.conf[DEFAULT] transport_url rabbit://openstack:密码控制节点IP:5672/ my_ip 计算节点IP [vnc] enabled true server_listen 0.0.0.0 server_proxyclient_address 计算节点IP [libvirt] virt_type kvm逻辑说明transport_url指向 RabbitMQ 消息队列nova 组件间靠它通信。my_ip是本机管理网 IP。virt_type kvm表示用硬件加速如果嵌套虚拟化里不支持 KVM改成qemu但性能下降。参数说明server_proxyclient_address填计算节点 IPVNC 代理用。验证计算节点是否注册openstack compute service list openstack hypervisor list逻辑说明compute service list显示 nova-compute 状态State为 up 才算正常。hypervisor list显示可用资源。参数说明如果 nova-compute 没出现查/var/log/nova/nova-compute.log常见原因是 RabbitMQ 连不上或 libvirt 权限不足。4. 避坑与排查部署 Openstack 最常见的五个翻车点4.1 现象keystone 启动后 500日志报 “Unable to connect to database”原因MySQL 里 keystone 库没建或者keystone.conf里的连接密码和实际授权密码不一致。很多人复制命令时改了密码但忘了同步改配置文件。解决登录 MySQL 执行SHOW DATABASES;确认 keystone 库存在。然后SELECT user,host FROM mysql.user;看 keystone 用户授权主机是否为%或控制节点 IP。最后核对keystone.conf的connection行密码用grep从passwords.yml里取不要手打。4.2 现象glance 上传镜像卡住日志报 “Permission denied: /var/lib/glance/images/”原因glance-api 以 glance 用户运行但目录属主是 root或者 SELinux 上下文不对。kolla 部署时如果没关 SELinux容器挂载目录会被拒绝。解决chown -R glance:glance /var/lib/glance/images/然后restorecon -Rv /var/lib/glance/images/。如果用的是 kolla检查/etc/kolla/globals.yml里enable_selinux是否为 no。4.3 现象nova-compute 服务状态 up 但创建虚拟机报 “No valid host was found”原因nova-scheduler 找不到满足条件的计算节点。常见于计算节点没配[neutron]认证信息或者 hypervisor 资源被占满。解决openstack hypervisor show 计算节点名看 vcpus 和 memory_mb 剩余量。如果为 0删掉无用实例或调大[DEFAULT] reserved_host_memory_mb的相反值。再检查/etc/nova/nova.conf的[neutron]段auth_url、username、password必须和 keystone 里 neutron 用户一致。4.4 现象虚拟机获取不到 IPneutron 日志报 “Unable to bind port”原因neutron 的 ML2 插件配置和实际网卡不匹配。比如tenant_network_types设了 vxlan 但没配[vxlan] local_ip或者bridge_mappings里的物理网桥名和neutron_external_interface不一致。解决检查/etc/neutron/plugins/ml2/ml2_conf.ini的[ml2] tenant_network_types和[ml2_type_vxlan] vni_ranges。再查[ml2_type_flat] flat_networks和[linux_bridge] physical_interface_mappings确保public:eth1里的 eth1 是业务网卡。改完重启 neutron-server 和 openvswitch-agent。4.5 现象dashboard 登录报 “Unauthorized”但命令行 token 正常原因dashboard 的local_settings.py里OPENSTACK_KEYSTONE_URL指向了 VIP 但 VIP 没起来或者ALLOWED_HOSTS没包含访问 IP。解决单节点部署时把OPENSTACK_KEYSTONE_URL改成控制节点实际 IP不要用 VIP。ALLOWED_HOSTS [*]先放开测试。如果 kolla 部署检查/etc/kolla/horizon/local_settings.py是否被正确渲染。5. 进阶技巧用 kolla-ansible 做多节点扩展与版本回退5.1 从单节点扩到三节点单节点跑通后扩展成控制计算存储三节点是常见需求。编辑/opt/kolla-venv/share/kolla-ansible/ansible/inventory/multinode在[control]、[compute]、[storage]组下填入各节点 IP。然后重新执行kolla-ansible -i multinode deploy。Ansible 会增量部署只在新节点上拉容器和配服务。注意kolla_internal_vip_address要设成所有控制节点都能访问的 VIPkeepalived 会自动选主。5.2 版本回退的后悔药kolla-ansible 支持指定镜像标签。如果升级后发现 nova 调度异常可以回退。在globals.yml里设openstack_release: zed然后执行kolla-ansible -i inventory pull拉旧镜像再kolla-ansible -i inventory deploy。数据库迁移不会自动回滚所以升级前用mysqldump备份 keystone、nova、neutron 三个库。我一般会在升级前把/etc/kolla整个目录打包回退时连配置一起还原。5.3 验证部署是否真的可用不要只看openstack service list全绿就放心。跑一个完整流程创建网络、子网、路由、安全组上传镜像创建 flavor启动实例绑定浮动 IPSSH 登录。这套走通才算环境可用。我习惯写一个 shell 脚本串起来每次重装后跑一遍比逐个命令敲省事。#!/bin/bash source /etc/kolla/admin-openrc.sh openstack network create test-net openstack subnet create --network test-net --subnet-range 192.168.100.0/24 test-subnet openstack router create test-router openstack router add subnet test-router test-subnet openstack flavor create --ram 512 --disk 1 --vcpus 1 test-flavor openstack server create --flavor test-flavor --image cirros --network test-net test-vm openstack server list逻辑说明这段脚本覆盖了 neutron 网络创建、nova 实例启动的核心路径。如果server list里状态变成 ACTIVE说明计算、网络、镜像、认证全部正常。参数说明--ram 512是 MB--disk 1是 GBcirros 镜像小512MB 内存够用。5.4 一个容易被忽略的日志习惯Openstack 排错 80% 靠日志。kolla 部署的日志在/var/log/kolla/服务名/下比如/var/log/kolla/nova/nova-compute.log。手动部署的在/var/log/nova/。我习惯用tail -f同时盯三四个日志创建实例时看 nova-compute、neutron-server、glance-api 谁先报错。另外journalctl -u docker能看容器启动失败原因比翻容器内日志快。这套环境我前后装过七八次每次翻车点都不一样但归根结底是网络和认证两块。把 keystone 和 neutron 的配置吃透Openstack 就不再是黑匣子。希望帮到你。本文还有配套的精品资源点击获取