简介：这份 OpenStack 安装部署手册面向云计算运维人员、系统集成工程师及高校相关专业学习者，针对开源 IaaS 平台从零搭建时环境配置繁琐、组件依赖复杂的问题，提供一套可对照执行的部署参考。资源包共 1 个 docx 文件，约 519KB，内容以 Havana 版本为基准，目录结构清晰，便于按章节检索。手册覆盖环境准备中的网卡配置、主机名修改与 MySQL 数据库安装，梳理 Keystone、Glance、Nova、Swift、Cinder、Neutron 等组件的整体结构与职责，并逐步展开 OpenStack 核心包与 Messaging Server 的安装流程。其中 Keystone 认证服务部分尤为细致，包含数据库连接创建、授权令牌定义、密钥与证书配置、服务启动、用户租客与 roles 定义以及 API endpoint 注册等关键环节，Glance 等组件的配置步骤亦有对应说明。目前已有 369 人学习，适合需要快速理解 OpenStack 部署脉络、对照搭建实验环境的读者参考。

1. Openstack安装部署手册：从裸机到能跑虚拟机的完整路径

手里拿到一台刚装完 CentOS 的物理机，或者一台配置还行的闲置服务器，想把它变成一套能创建虚拟机、能分配浮动 IP、能通过 Web 界面管理的私有云，这件事的门槛其实比很多人想象的低。Openstack 安装部署这件事，十年前确实让人头疼，组件多、依赖乱、文档散，但今天用 Kolla-Ansible 这套方案，一个稍微熟悉 Linux 的工程师花半天时间就能把一套 All-in-One 环境跑起来。这篇内容面向的是需要在内网环境里搭建一套可用 Openstack 云平台的运维人员或后端工程师，不追求生产级高可用，先把最小可用闭环跑通，再谈扩展。Havana 那个年代的手工编译安装方式已经不适合作为入门路径了，容器化部署才是当前的主流做法。

2. 部署方案选型：为什么 Kolla-Ansible 比手工装更靠谱

2.1 三种常见部署路径的对比

Openstack 安装部署走到今天，大致有三条路可以走。第一条是早期的手工逐组件安装，从 Keystone 到 Nova 到 Neutron，每个组件单独配数据库、单独调配置文件，Havana 版本时期基本都是这么干的。这条路的好处是能让你彻底理解每个组件在干什么，坏处是组件之间的依赖关系太复杂，一个配置项写错，后面所有服务都起不来，排查成本极高。第二条路是 DevStack，适合开发人员快速拉一套环境做代码调试，但它本质上是个脚本堆出来的临时环境，重启就崩，不适合拿来当长期使用的云平台。第三条路是 Kolla-Ansible，用 Docker 容器把每个 Openstack 服务打包运行，通过 Ansible 做编排部署，配置集中管理，服务隔离清晰，出问题也容易定位到具体容器。

我一般会推荐 Kolla-Ansible 作为入门和中小规模部署的首选。原因很直接：它把 Openstack 那些繁琐的 Python 依赖、消息队列配置、数据库初始化全部封装在容器镜像和 Ansible 角色里了，你只需要关心几份配置文件和一个 inventory 文件。对于需要快速验证 Openstack 功能、或者内网私有云场景来说，这是投入产出比最高的方式。

2.2 硬件与系统的最低要求

All-in-One 部署意味着计算、控制、网络、存储全部跑在同一台机器上。这台机器的配置直接决定了你能不能跑通。

内存这里要特别说一句。8 GB 是理论底线，但 Kolla 会把几十个容器全部拉起来，光 MariaDB、RabbitMQ、Keystone、Nova、Neutron、Glance、Horizon 这些核心服务的内存占用加起来就接近 6 GB，再算上系统本身的开销，8 GB 会非常紧张。如果机器只有 8 GB，建议在/etc/kolla/globals.yml里关掉不需要的服务，比如 Cinder、Swift、Heat 这些暂时用不上的组件。

2.3 部署前的系统准备

在开始跑 Kolla-Ansible 之前，有几件系统层面的事情必须先做掉，否则后面会出各种玄学问题。

# 关闭防火墙和 SELinux，内网环境先关掉，生产环境再按需配置规则 systemctl stop firewalld systemctl disable firewalld setenforce 0 sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config # 设置主机名，Kolla 对主机名有要求，不能用默认的 localhost hostnamectl set-hostname openstack-node echo "127.0.0.1 openstack-node" >> /etc/hosts # 安装基础依赖 yum install -y epel-release yum install -y python3-devel libffi-devel gcc openssl-devel python3-libs

这几条命令做的事情分别是：关闭 firewalld 和 SELinux 是为了避免容器网络和端口被拦截；设置主机名是因为 Kolla 的 Ansible inventory 里需要用主机名来标识节点；安装 python3-devel 和 gcc 这些是因为后面 pip 安装 Kolla-Ansible 时需要编译一些 Python C 扩展。

注意：如果你的环境有安全合规要求不能关闭 SELinux，那需要额外配置容器相关的 SELinux 策略，复杂度会上升不少，建议先在测试环境验证。

3. Kolla-Ansible 安装与配置：从 pip 到 globals.yml

3.1 安装 Kolla-Ansible 并生成配置文件

系统准备做完之后，接下来就是安装 Kolla-Ansible 本身。它本质上是一个 Python 包，通过 pip 安装即可。

# 创建虚拟环境，避免污染系统 Python python3 -m venv /opt/kolla-venv source /opt/kolla-venv/bin/activate # 升级 pip 并安装 Kolla-Ansible pip install --upgrade pip pip install kolla-ansible # 创建配置目录 mkdir -p /etc/kolla chown $USER:$USER /etc/kolla # 复制默认配置文件 cp -r /opt/kolla-venv/share/kolla-ansible/etc_examples/kolla/* /etc/kolla/ cp /opt/kolla-venv/share/kolla-ansible/ansible/inventory/all-in-one .

这里有几个关键点。第一，用虚拟环境是为了隔离依赖，Kolla-Ansible 对 Ansible 版本有要求，直接装在系统 Python 里容易和系统自带的 Ansible 冲突。第二，all-in-one这个 inventory 文件是单节点部署的模板，复制到当前目录后 Kolla 会默认读取它。第三，/etc/kolla/目录下会有两个关键文件：globals.yml和passwords.yml，前者是全局配置，后者是自动生成的各种服务密码。

3.2 生成密码并修改 globals.yml

密码文件不需要手动填，Kolla 提供了一个命令自动生成随机密码。

# 生成随机密码，写入 passwords.yml kolla-genpwd # 查看生成的密码，确认文件非空 head -5 /etc/kolla/passwords.yml

接下来是重头戏globals.yml。这个文件决定了你的 Openstack 集群长什么样。以下是我一般会修改的关键配置项：

# 镜像类型和版本，CentOS 7.9 用 centos 作为基础镜像 kolla_base_distro: "centos" kolla_install_type: "binary" # Openstack 版本，选一个稳定版 openstack_release: "yoga" # 网络接口，用 ip addr 查看你的实际网卡名 network_interface: "ens33" api_interface: "ens33" # VIP 地址，单节点也要设，就用本机 IP kolla_internal_vip_address: "192.168.1.100" # Neutron 网络类型，先用 flat 或 vxlan neutron_external_interface: "ens34" neutron_plugin_agent: "openvswitch" # 启用核心服务 enable_glance: "yes" enable_keystone: "yes" enable_nova: "yes" enable_neutron: "yes" enable_horizon: "yes" # 暂时不用的服务关掉，省内存 enable_cinder: "no" enable_swift: "no" enable_heat: "no"

network_interface和api_interface填的是你机器上实际存在的网卡名称，用ip addr命令能看到。kolla_internal_vip_address在单节点场景下直接填本机 IP 就行，多节点才需要额外配置 Keepalived。neutron_external_interface是给虚拟机访问外网用的网卡，如果你只有一张网卡，可以先不配这个，后面用 flat 网络也能跑通。

3.3 执行部署前的环境检查

在真正跑kolla-ansible deploy之前，先做一次 bootstrap 和 prechecks，这两个步骤能帮你提前发现大部分问题。

# 安装 Ansible Galaxy 依赖 kolla-ansible install-deps # 初始化节点，安装 Docker 等基础组件 kolla-ansible -i ./all-in-one bootstrap-servers # 部署前检查 kolla-ansible -i ./all-in-one prechecks

bootstrap-servers这一步会在目标节点上安装 Docker、配置 Docker 镜像加速、调整内核参数。如果你的机器在国内，Docker Hub 拉镜像会很慢甚至超时，需要在/etc/docker/daemon.json里配置镜像加速地址，这个文件 bootstrap 之后会生成，可以手动改完再继续。

prechecks是最重要的一步。它会检查端口占用、磁盘空间、内存、网络连通性、Python 版本等等。如果 prechecks 报错，一定要逐条解决，不要跳过。常见的报错包括：端口 80 被 httpd 占用、内存不足、/etc/hosts里主机名解析不对。

4. 部署执行与验证：跑通第一台虚拟机

4.1 执行部署并观察日志

prechecks 全部通过之后，就可以执行正式部署了。

# 正式部署，这一步耗时较长，取决于网络和机器性能 kolla-ansible -i ./all-in-one deploy # 部署完成后生成 admin 用户的 openrc 文件 kolla-ansible -i ./all-in-one post-deploy

deploy这一步会依次拉取所有容器镜像、创建容器、初始化数据库、启动服务。整个过程在网络正常的情况下大概 20 到 40 分钟。如果中途卡住，大概率是在拉某个镜像，可以用docker images看已经拉下来哪些。如果某个容器反复重启，用docker logs <容器名>看具体报错。

post-deploy会生成/etc/kolla/admin-openrc.sh文件，里面包含了 admin 用户的认证信息和 Keystone 的地址。后续所有 Openstack 命令行操作都需要先 source 这个文件。

4.2 验证核心服务状态

部署完成后，第一件事是确认各个服务是否正常。

# 加载 admin 认证 source /etc/kolla/admin-openrc.sh # 查看 Keystone 用户列表，能返回说明认证正常 openstack user list # 查看 Nova 计算节点状态 openstack compute service list # 查看 Neutron 网络代理状态 openstack network agent list # 查看 Glance 镜像列表 openstack image list

这几个命令能正常返回结果，说明核心服务已经跑起来了。如果openstack user list报认证失败，检查admin-openrc.sh里的OS_AUTH_URL是不是指向了正确的 VIP 地址和端口。如果openstack compute service list返回空，说明 Nova 的 compute 服务没起来，去docker ps -a | grep nova看容器状态。

4.3 创建第一台虚拟机

验证服务正常之后，就可以走一遍完整的虚拟机创建流程了。这个过程能帮你确认网络、存储、镜像三个环节是否都通了。

# 下载一个测试用的小镜像 wget http://download.cirros-cloud.net/0.6.2/cirros-0.6.2-x86_64-disk.img # 上传镜像到 Glance openstack image create "cirros" \ --file cirros-0.6.2-x86_64-disk.img \ --disk-format qcow2 \ --container-format bare \ --public # 创建外部网络 openstack network create --external --provider-physical-network physnet1 \ --provider-network-type flat public-net # 创建外部子网 openstack subnet create --network public-net \ --subnet-range 192.168.1.0/24 \ --gateway 192.168.1.1 \ --no-dhcp public-subnet # 创建内部网络和子网 openstack network create private-net openstack subnet create --network private-net \ --subnet-range 10.0.0.0/24 \ --gateway 10.0.0.1 \ --dns-nameserver 114.114.114.114 private-subnet # 创建路由并连接内外网 openstack router create router1 openstack router set --external-gateway public-net router1 openstack router add subnet router1 private-subnet # 创建安全组规则，允许 ping 和 ssh openstack security group rule create --proto icmp default openstack security group rule create --proto tcp --dst-port 22 default # 创建密钥对 ssh-keygen -t rsa -f ~/.ssh/id_rsa -N "" openstack keypair create --public-key ~/.ssh/id_rsa.pub mykey # 创建虚拟机 openstack server create --flavor m1.tiny --image cirros \ --nic net-id=$(openstack network show private-net -f value -c id) \ --security-group default --key-name mykey test-vm # 查看虚拟机状态 openstack server list

这一串命令走下来，如果openstack server list里能看到test-vm的状态变成ACTIVE，说明你的 Openstack 环境已经完整跑通了。从镜像上传到网络创建到虚拟机启动，整条链路都验证过了。

提示：m1.tiny这个 flavor 默认可能不存在，需要用openstack flavor create手动创建，指定 vcpu、内存和磁盘大小。

5. 避坑指南：部署 Openstack 最容易翻车的五个地方

5.1 容器镜像拉取超时导致部署中断

现象：kolla-ansible deploy执行到一半卡住，日志显示某个镜像pull操作超时，或者直接报manifest unknown。

原因：Kolla 默认从 Docker Hub 拉取镜像，国内网络访问不稳定。另外openstack_release如果填了一个不存在的版本号，对应的镜像 tag 也会找不到。

解决：在/etc/kolla/globals.yml里配置docker_registry指向国内可访问的镜像源，或者在 bootstrap 之后手动修改/etc/docker/daemon.json添加registry-mirrors。如果已经卡住，先docker images看哪些镜像已经拉下来了，然后重新执行kolla-ansible deploy，Kolla 会跳过已存在的镜像。

5.2 prechecks 报内存不足

现象：prechecks阶段报错，提示可用内存低于最低要求，或者nova_compute容器反复重启。

原因：All-in-One 部署把所有服务塞在一台机器上，8 GB 内存跑全套服务确实吃力。特别是 Nova 的 compute 服务，启动时会预分配一部分内存。

解决：在globals.yml里关掉非必要服务，enable_cinder、enable_swift、enable_heat、enable_sahara全部设为no。如果还是不够，把nova_compute的reserved_host_memory_mb调小，或者直接加内存条。

5.3 Horizon 登录后报 500 错误

现象：浏览器打开 Horizon 地址，输入 admin 密码后页面报 500 Internal Server Error。

原因：Horizon 容器里的 session 存储或者 Keystone 认证配置有问题。常见的是memcached服务没起来，或者openstack_release版本和 Horizon 的配置模板不匹配。

解决：先docker logs horizon看具体报错。如果是 memcached 连接失败，docker restart memcached然后重启 horizon 容器。如果是版本问题，确认globals.yml里的openstack_release和实际拉取的镜像 tag 一致。

5.4 虚拟机创建后无法 ping 通外网

现象：虚拟机状态是 ACTIVE，但ping 114.114.114.114不通，浮动 IP 也分配了但 SSH 连不上。

原因：Neutron 的 external 网络和物理网卡之间的桥接没配好，或者安全组规则没放行。另外neutron_external_interface如果填错了网卡名，外部网络根本不通。

解决：检查neutron_external_interface对应的网卡是否处于 up 状态，ovs-vsctl show看 OVS 网桥配置。安全组默认只放行 DHCP 和 SSH，ICMP 需要手动加规则。浮动 IP 分配后还需要openstack server add floating ip绑定到虚拟机。

5.5 重启物理机后 Openstack 服务全部失效

现象：物理机重启后，openstack命令全部报连接超时，Horizon 也打不开。

原因：Kolla 部署的容器默认没有设置restart: always策略，物理机重启后容器不会自动启动。另外 MariaDB 和 RabbitMQ 这些基础服务如果启动顺序不对，依赖它们的上层服务也会起不来。

解决：Kolla 提供了一个kolla-ansible -i ./all-in-one start命令来启动所有容器。如果需要开机自启，可以配置 systemd 服务或者用docker update --restart=always批量设置容器重启策略。更稳妥的做法是写一个开机脚本，按顺序启动 mariadb、rabbitmq、keystone，再启动其他服务。

6. 进阶技巧：用 Kolla 做多节点扩展和版本升级

单节点跑通之后，下一步自然是扩展到多节点。Kolla-Ansible 的多节点部署和单节点在流程上完全一样，区别只在 inventory 文件。你需要把all-in-one换成multinode模板，然后在[control]、[network]、[compute]、[storage]这些分组下面填入各个节点的 IP 或主机名。控制节点至少三个才能做高可用，计算节点按需添加。所有节点需要提前做好免密登录和主机名解析，bootstrap-servers要在所有节点上执行一遍。

版本升级是另一个绕不开的话题。Kolla 的升级路径是逐版本递进的，不能从 Yoga 直接跳到 Antelope。升级前必须备份数据库和配置文件，然后修改openstack_release为目标版本，执行kolla-ansible -i ./all-in-one upgrade。升级过程中最怕的是数据库 schema 变更失败，所以升级前用mysqldump把所有 Openstack 相关的库导出一份，出问题还能回滚。

还有一个实用技巧是自定义容器配置。Kolla 允许你在/etc/kolla/config/目录下放针对特定服务的配置文件覆盖，比如/etc/kolla/config/nova/nova.conf里的内容会合并到 Nova 容器的配置中。这个机制在调优和排查问题时特别有用，不用去改容器里的文件，改完重新kolla-ansible deploy就生效。

我自己踩过最深的一个坑是：有一次在客户现场部署，prechecks 全部通过，deploy 也显示成功，但 Horizon 就是打不开。查了两个小时才发现是客户的内网 DNS 把 VIP 地址解析到了一个错误的 IP 上。从那以后我养成了一个习惯，部署完成后第一件事不是开 Horizon，而是先用curl -I http://VIP:5000确认 Keystone 的 API 能通，再用curl -I http://VIP:80确认 Horizon 能通，最后才开浏览器。这个顺序能帮你快速定位问题出在认证层还是 Web 层。希望帮到你。

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