基于Kolla-Ansible的OpenStack安装部署与运维全指南

简介一份面向OpenStack初学者与运维实施人员的部署指导手册聚焦Havana版本的完整安装流程覆盖环境准备、网络与主机配置、核心组件结构以及Keystone认证服务等关键环节帮助读者快速理解并落地IaaS云平台的基础搭建。资源为单个docx文档压缩包大小519KB内容以目录式章节组织便于按步骤查阅。文档不仅列出MySQL、OpenStack核心包、Messaging Server等安装要点还详细说明Keystone的数据库连接、授权令牌、密钥证书、用户租客与角色定义并延伸至Glance镜像服务的配置与身份验证适合作为实验环境部署时的参考手册。已有369人学习下载适合需要系统部署OpenStack或整理实施文档的技术人员学习参考。1. OpenStack安装部署为什么容易翻车OpenStack不是一个软件而是一套按角色拆开的云管理组件集合Keystone管认证、Nova管计算、Neutron管网络、Glance管镜像、Cinder管块存储、Horizon管界面。安装部署的难点从来不是把安装包装上去而是让几十个服务按正确顺序、正确参数互相握手。Neutron网络配错卡几天、RabbitMQ连不上反复报错、容器起来又退出这些高频问题的根因大多在部署规划和环境参数上。下面的内容按“先选型、再执行、后验证”的顺序展开覆盖环境规划、Kolla-Ansible实操、服务验证和故障定位的完整路径适合需要自行搭建OpenStack云平台的技术人员也给刚入门、希望有一份能照着执行的参考的读者。后半部分会给出可直接上手的命令和常见坑位的排查思路。2. 选对安装部署路径DevStack、PackStack、Kolla-Ansible三选一OpenStack官方并没有锁死某一种安装方式社区里长期并存着三套主流路径。花十分钟把这三条路的边界搞清楚比直接复制网上的命令省下的时间要多得多。选错路径的典型结果是用DevStack搭出来的环境想加节点发现根本不支持或者用PackStack部署完想上生产却在网络功能上受限。所以在执行任何安装命令之前先回答两个问题这套环境要跑多久以及后面会不会扩容。2.1 DevStack单机入门最快但离生产很远DevStack的定位是开发环境底层用一组Shell脚本把所有服务装进一台机器的系统环境。它适合的场景是你想弄清楚Nova和Neutron之间怎么通信想改一个服务的代码快速看效果或者只想看看Horizon控制台长什么样。不适合的场景是长期运行因为所有组件共享一套Python环境系统更新很容易把依赖弄坏而且它默认不做高可用和持久化。部署前需要创建一个非root的专用用户官方习惯叫stacksudo useradd -s /bin/bash -d /opt/stack -m stack echo stack ALL(ALL) NOPASSWD: ALL | sudo tee /etc/sudoers.d/stack sudo -u stack -i git clone -b stable/2023.1 https://opendev.org/openstack/devstack /opt/stack/devstack克隆完成后进入devstack目录写local.conf这是DevStack唯一的必要配置文件最少三行[[local|localrc]] ADMIN_PASSWORDcloud123 DATABASE_PASSWORDcloud123 RABBIT_PASSWORDcloud123ADMIN_PASSWORD是管理员登录Horizon和OpenStack命令行的密码DATABASE_PASSWORD和RABBIT_PASSWORD分别给数据库和消息队列使用。这三个值在同一套环境里要保持一致DevStack会自动把它们写入各服务的配置。保存后执行./stack.sh脚本按Keystone、Glance、Nova、Neutron的顺序把服务装起来一般需要20到40分钟。跑完会在终端输出一组OS_开头的环境变量复制出来即可开始使用命令行。对于菜鸟教程阶段的入门者DevStack最大的价值是帮你把组件关系在脑子里建立起来。但要注意它不会检查宿主机端口占用如果3306、5672已被其他服务占用需要先停掉再部署。DevStack没有提供可靠的加节点方式验证完功能后建议直接销毁重装。2.2 PackStack一条命令拉起的快速部署方案PackStack是RDO项目推出的部署工具由Puppet在后台完成服务编排。它的适用场景是节点数量少、网络结构简单、希望快速交付一套演示环境或预生产环境的场景。比如你只需要一个控制节点加两个计算节点业务方要在一个下午看到可操作的云平台PackStack是最直观的选择。All-in-one部署只需要几步sudo dnf install -y centos-release-openstack-train sudo dnf update -y sudo dnf install -y openstack-packstack sudo packstack --allinone第一条命令把RDO源加入系统--allinone参数让PackStack把控制服务和计算服务全部部署在一台机器上。如果要部署多节点需要先产生应答文件sudo packstack --gen-answer-file/root/answers.txt应答文件是PackStack的核心配置需要修改三个参数CONFIG_CONTROLLER_HOST填控制节点IPCONFIG_COMPUTE_HOSTS填计算节点IP且多个IP用逗号分隔CONFIG_NETWORK_HOSTS填负责网络服务的节点IP。改完后执行sudo packstack --answer-file/root/answers.txtPackStack的几个常见坑分布在执行阶段Puppet模块之间偶尔会出现依赖竞争比如Neutron先于Nova写好网络配置导致Nova读到旧文件。好在这个工具是幂等的报错后不需要清环境直接重跑一次相同命令就能收敛。另外PackStack的版本跟随RDO发行周期对最新系统的适配会慢半拍在CentOS Stream 9上部署时尤其要注意源是否匹配。2.3 Kolla-Ansible生产环境的最优解与选型边界Kolla-Ansible是目前生产环境搭建OpenStack的主流方案。它把每个服务打包成Docker镜像由Ansible负责生成配置、按依赖顺序启动容器。相比前两种方案隔离性和可维护性都更好宿主机只需要装Docker和基础依赖系统升级不会扫掉云平台组件所有配置集中在/etc/kolla/globals.yml和inventory清单里改参数后重跑部署即可扩容计算节点时可以只针对新节点执行不用全量重来。选型边界很清晰学习原理用DevStack快速演示用PackStack要持续运行、不断扩容、还有升级预期的平台直接选Kolla-Ansible。三者的对比如下维度DevStackPackStackKolla-Ansible底层机制脚本装进系统Puppet编排Docker Ansible多节点扩展不支持支持但费力支持且规范生产可用性低有限高配置变更方式改脚本重跑改应答文件重跑改globals.yml滚动更新排错入口系统日志系统日志容器日志为主因此后面的部署实操围绕Kolla-Ansible展开这套方案的配置和执行命令沉淀下来可以直接当作团队内部的OpenStack安装部署参考。在进入命令之前先把环境规划和版本选择讲清楚。3. 基于Kolla-Ansible的OpenStack安装部署从环境准备到服务拉起3.1 节点规划与宿主机基础配置Kolla-Ansible部署前先做规划。以一个最小可用环境为例控制节点至少4核8G、100G磁盘计算节点至少8核16G磁盘按虚拟机数量预留。每台节点要有两张网卡一张走管理网一张走外部网外部网用于浮动IP和南北向流量。先修好节点间的主机解析。假设控制节点主机名为controller计算节点为compute01cat /etc/hosts EOF 192.168.10.11 controller 192.168.10.21 compute01 EOF所有节点都要执行这个步骤。然后是时间同步Kolla-Ansible对时间偏差非常敏感Keystone签发的token校验会直接因为时钟偏移失败。控制节点作为NTP服务器计算节点指向它sudo dnf install -y chrony sudo systemctl enable --now chronyd控制节点上编辑/etc/chrony.conf添加本地局域网的时间源计算节点上把server指向controller的IP。配置后重启chronyd用chronyc sources -v确认状态为^*。节点规划汇总如下节点主机名建议配置承担角色控制节点controller4C8G / 100Gcontrol network monitoring storage计算节点compute018C16G / 200Gcompute neutron agent另需要提前在控制节点生成SSH密钥并分发到所有节点的authorized_keys里后续Kolla-Ansible的所有操作都依赖控制节点免密登录到各节点。3.2 安装Kolla-Ansible并生成inventory文件控制节点上创建工作目录和Python虚拟环境避免依赖污染系统Pythonsudo dnf install -y python3-devel libffi-devel gcc openssl-devel python3-pip git python3 -m venv /opt/kolla-venv source /opt/kolla-venv/bin/activate pip install -U pip pip install kolla-ansible python-openstackclient python-neutronclientpython-openstackclient提供openstack命令行python-neutronclient提供网络相关扩展。不同OpenStack release对Ansible版本有约束如果pip在解析依赖时报版本冲突以你选定release对应版本的Kolla-Ansible文档为准没有固定答案。安装完成后把模板文件和inventory样例拷到/etc/kollasudo mkdir -p /etc/kolla sudo cp -r /usr/share/kolla-ansible/etc_examples/kolla/* /etc/kolla/ sudo cp /usr/share/kolla-ansible/ansible/inventory/multinode /etc/kolla/如果Kolla-Ansible装在虚拟环境里模板路径一般在虚拟环境的share目录下例如/opt/kolla-venv/share/kolla-ansible/。multinode就是节点清单文件按组件角色分组[control] controller ansible_host192.168.10.11 [network] controller ansible_host192.168.10.11 [compute] compute01 ansible_host192.168.10.21 [monitoring] controller ansible_host192.168.10.11 [storage] controller ansible_host192.168.10.11控制、网络、监控、存储这四组都可以复用同一个控制节点计算节点单独一组。后续扩容就是在这个文件的[compute]分组下加一行新节点IP。3.3 手把手搭OpenStack的关键globals.yml参数与密码文件/etc/kolla/globals.yml是Kolla-Ansible的主配置部署行为几乎全由它决定。手把手搭OpenStack过程中最容易出错的地方是参数之间互相矛盾下面这几个参数是每次部署都必须过一遍的。先初始化随机密码kolla-genpwd如果不幸提示权限不足用sudo /opt/kolla-venv/bin/kolla-genpwd。这个命令生成/etc/kolla/passwords.yml包含所有服务间的通信密钥和数据库密码。同一套环境下后续所有部署操作都必须使用同一份passwords.yml换掉它会导致服务之间认证全部失败。编辑globals.yml时必改参数如下kolla_base_distro: rocky kolla_install_type: binary openstack_release: 2023.1 network_interface: eth0 kolla_internal_vip_address: 192.168.10.250 neutron_external_interface: eth1 enable_neutron_provider_networks: yes nova_compute_virt_type: kvm这几个参数的含义和配置要点参数说明配置注意kolla_base_distro宿主机发行版rocky对应Rocky Linuxubuntu对应Ubuntukolla_install_type镜像获取方式binary拉预编译镜像source编译源码生产用binaryopenstack_release版本tag决定拉取哪个版本的容器镜像network_interface管理网卡所有服务监听此网段kolla_internal_vip_address控制面虚拟IP配合keepalived实现高可用需与管理网同一网段neutron_external_interface外部网卡承载浮动IP建议独立物理网卡enable_neutron_provider_networks是否启用provider网络生产环境必须为yesnova_compute_virt_type虚拟化类型物理机用kvm虚拟机嵌套环境用qemu3.4 三阶段执行bootstrap-servers、prechecks、deploy云平台搭建到这里才真正进入执行阶段。整个执行过程分三个阶段顺序固定的原因是每阶段都要为上阶段打好基础。第一阶段初始化所有节点的系统依赖安装Docker、配置内核参数和系统服务source /opt/kolla-venv/bin/activate sudo /opt/kolla-venv/bin/kolla-ansible -i /etc/kolla/multinode bootstrap-servers后续所有kolla-ansible命令都建议用完整路径执行目的就是为了让sudo环境能正确找到安装在虚拟环境里的命令。第二阶段是预检查验证节点间网络连通性、时钟同步状态、Docker可用性和磁盘空间sudo /opt/kolla-venv/bin/kolla-ansible -i /etc/kolla/multinode prechecks提示prechecks输出里如果出现FATAL结尾的条目先解决再往下走。跳过预检查直接deploy后面排错成本会成倍增加。第三阶段执行正式部署sudo /opt/kolla-venv/bin/kolla-ansible -i /etc/kolla/multinode deploy部署时间视机器配置不同在15到40分钟之间。所有容器按依赖顺序启动Ansible会在每个步骤完成后等待容器健康检查通过。完成后执行post-deploy生成认证环境变量文件sudo /opt/kolla-venv/bin/kolla-ansible -i /etc/kolla/multinode post-deploy这个命令会在/etc/kolla下生成admin-openrc.shsource之后即可使用openstack命令管理云平台。4. OpenStack部署完成后的验证清单与故障定位4.1 容器、认证、计算与网络的状态检查部署完成后先不要急着上业务按下面的顺序过一遍。第一步看容器状态在所有节点执行docker ps | grep -E keystone|nova|neutron|glance|horizon正常情况下STATUS列显示Up不应出现Restarting或Exited。若发现容器反复重启用docker logs 容器名 --tail 100查看最近日志容器名用下划线风格比如nova_compute、neutron_server。第二步验证API层source /etc/kolla/admin-openrc.sh openstack service list openstack endpoint list能正常返回服务列表说明Keystone认证链路通。第三步查计算和网络组件openstack compute service list openstack network agent list输出里每个服务的State列应为upStatus列不应包含down。如果某个计算节点状态异常去该节点执行docker logs nova_compute --tail 50报错集中在消息队列连接失败或libvirt配置错误这两类。4.2 用命令行走通创建云主机的全链路验证完整业务链路最快的方式是从创建项目到登录云主机一条龙走一遍。先创建项目、用户和租户网络openstack project create demo openstack user create --project demo --password demo123 demo openstack role add --project demo --user demo member openstack network create demo-net openstack subnet create --network demo-net --subnet-range 10.0.10.0/24 --dns-nameserver 223.5.5.5 demo-subnet openstack router create demo-router openstack router add subnet demo-router demo-subnet这段命令先建了隔离的项目和用户再创建租户内子网和路由器。--subnet-range是云主机内部IP段按需规划--dns-nameserver填环境可用的DNS。接着把路由器接到外部网络openstack network list --external openstack router set --external-gateway 外部网络ID demo-router上传云镜像前建议选择带cloud-init的qcow2格式镜像否则后边的密钥注入不会生效openstack image create --public --container-format bare --disk-format qcow2 --file ./CentOS-Stream-9-cloud.qcow2 centos9 openstack flavor create --vcpus 1 --ram 1024 --disk 10 m1.small openstack keypair create --public-key ~/.ssh/id_rsa.pub mykey openstack server create --flavor m1.small --image centos9 --network demo-net --key-name mykey demo-vm最后分配浮动IP并绑定openstack floating ip create 外部网络名称 openstack server add floating ip demo-vm 浮动IP绑定后从局域网直连这个浮动IP的22端口能登录说明从Keystone认证到Neutron网络再到Nova计算调度的整条链路都通了。4.3 高频故障对照表与排错顺序把运维过程中遇到最多的几个故障整理成速查表现象直接原因定位方法Keystone token校验失败节点间时钟偏差各节点执行chronyc sources -v重新同步后重试nova-compute状态downRabbitMQ连接中断或libvirt异常该节点docker logs nova_compute看最后50行ping消息队列IP测试连通性云主机无法获取IPNeutron DHCP agent未运行执行openstack network agent list查docker logs neutron_dhcp_agent浮动IP不通外部网卡接线或交换机trunk问题核对neutron_external_interface对应网卡检查物理交换机允许的VLANHorizon打不开VIP或haproxy异常确认kolla_internal_vip_address所在网段可路由docker ps查haproxy容器状态处理故障的第一步永远是确认现象发生在哪个节点。控制节点侧重看keystone、neutron-server、nova-api这些API容器计算节点侧重看nova_compute和neutron_openvswitch_agent。用docker ps对比正常节点上的容器清单多出来的、少掉的、反复重启的容器就是嫌疑点。第二步再针对性看日志Kolla-Ansible的容器日志默认写入容器内/var/log/kolla也可以用docker logs直接看stdout内容一致。注意修改过globals.yml后要重新执行kolla-ansible deploy才能生效。如果只改了某个服务参数可以用kolla-ansible reconfigure --tags 服务名定向重跑比全量deploy快得多。5. 后续维护的三个关键操作扩容、凭证管理、升级5.1 用--limit定向扩容计算节点Kolla-Ansible扩容计算节点不需要重跑全量部署。先在multinode的[compute]分组下追加新节点然后bootstrap和定向部署sudo /opt/kolla-venv/bin/kolla-ansible -i /etc/kolla/multinode bootstrap-servers --limit compute02 sudo /opt/kolla-venv/bin/kolla-ansible -i /etc/kolla/multinode deploy --limit compute02--limit参数让Ansible只在目标节点上执行控制面服务不受影响。扩容完成后确认nova和neutron的agent状态变为up同时检查新节点的时间和chrony配置避免token校验问题。如果存储用了Ceph新计算节点还要额外配置Ceph密钥这里不做展开。5.2 管理多个项目的认证凭证/etc/kolla/admin-openrc.sh是管理入口多项目环境要防止混用凭证。常见做法是维护一套rc文件每个项目一个切换前先清理环境变量再sourceunset OS_PROJECT_NAME OS_USERNAME OS_AUTH_URL OS_PASSWORD source /root/openrc-demo.sh清理是必要的否则旧环境变量残留在shell里命令会作用到错误项目上。5.3 版本升级的镜像切换与数据库备份升级的核心是修改globals.yml里的openstack_release指向新版本然后执行sudo /opt/kolla-venv/bin/kolla-ansible -i /etc/kolla/multinode upgrade这个命令会先拉取新镜像再按依赖顺序滚动替换容器。升级前必须备份/etc/kolla整目录和数据库数据库备份可以直接通过mariadb容器执行docker exec mariadb mysqldump --all-databases -p$(grep database_password /etc/kolla/passwords.yml | awk {print $2}) /data/kolla_db_backup.sql升级完成后用openstack service list和openstack compute service list做一次全量健康检查确认所有组件状态为up。本文还有配套的精品资源点击获取