Ubuntu 22.04上使用DevStack快速部署OpenStack开发测试环境

在国内开发或测试环境中，快速搭建一个可用的 OpenStack 平台是很多学习者和开发者面临的第一道门槛。手动部署 OpenStack 组件复杂且耗时，而 DevStack 作为一个自动化部署脚本工具，能够极大地简化这一过程。它通过一系列 Shell 脚本，将 OpenStack 的核心服务快速部署到一台机器上，非常适合用于开发、测试和概念验证。本文将带你在一台 Ubuntu 22.04 LTS 系统上，从零开始，完成 DevStack 的配置和 OpenStack 的快速部署，并解释每一步背后的原理和常见问题的排查方法。

本文的目标读者是具备 Linux 基础操作知识，希望快速获得一个 OpenStack 实验环境的开发者或运维人员。通过本文，你将理解 DevStack 的工作机制，掌握从系统准备、网络配置、脚本修改到服务验证的全流程，并能处理部署过程中遇到的大部分典型错误。

1. 理解 DevStack 的核心机制与准备工作

DevStack 并非一个生产级的部署工具，它的设计目标是“快速”和“可重复”。它通过 Git 拉取 OpenStack 各个项目的最新代码（或指定分支），然后运行一系列安装和配置脚本，在本地创建一个 All-in-One（单节点）的 OpenStack 环境。这意味着所有服务（如 Nova、Neutron、Glance、Keystone 等）都将运行在同一台主机上。

在开始之前，必须明确几个关键前提，这能避免后续很多问题：

1. 纯净的系统：强烈建议使用新安装的 Ubuntu 22.04 LTS 系统。已有复杂环境或旧版本残留可能导致依赖冲突。
2. 充足的资源：单节点部署对硬件有一定要求。建议至少提供 4 核 CPU、8 GB 内存和 50 GB 磁盘空间。虚拟机资源不足是部署失败的主要原因之一。
3. 稳定的网络：部署过程中需要从 GitHub、PyPI 等源下载大量软件包和代码，网络中断或缓慢会导致脚本执行超时失败。
4. 正确的身份：全程需要使用具有sudo权限的非 root 用户（例如ubuntu或stack）进行操作，DevStack 脚本会检查此点。

1.1 基础系统环境准备

首先，确保系统是最新的，并安装一些基础工具。

# 更新系统包列表和已安装的包 sudo apt update && sudo apt upgrade -y # 安装 DevStack 所需的基础工具，如 Git、Python 环境等 sudo apt install -y git python3-pip

接下来，创建一个专门用于运行 DevStack 的用户。虽然可以使用现有用户，但创建一个独立的stack用户是一种最佳实践，可以更好地隔离环境。

# 创建 stack 用户并设置密码 sudo useradd -s /bin/bash -d /opt/stack -m stack echo "stack ALL=(ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/stack

切换到stack用户，后续所有操作都将在此用户下进行。

sudo su - stack

1.2 配置系统与网络环境

DevStack 会配置复杂的网络，包括桥接设备和 IP 地址。为了避免与现有网络管理服务冲突，我们需要先禁用 Ubuntu 自带的网络管理器（对于服务器版，通常未安装，可跳过）。更重要的是，确保主机名设置正确。

# 设置主机名，例如设置为 ‘devstack’ sudo hostnamectl set-hostname devstack # 编辑 /etc/hosts，确保 127.0.1.1 或 127.0.0.1 指向正确的主机名 echo "127.0.0.1 devstack" | sudo tee -a /etc/hosts

对于虚拟机环境（如 VMware、VirtualBox），需要确保虚拟机的网络适配器设置为“桥接模式”或“NAT 模式”，并且主机可以访问互联网。在物理机上则需保证网络连通。

2. 获取与配置 DevStack

环境准备就绪后，就可以获取 DevStack 脚本并进行关键配置了。

2.1 克隆 DevStack 仓库

在stack用户的家目录下，克隆官方仓库。建议使用稳定分支，如stable/zed（对应 OpenStack Zed 版本），以避免主分支可能存在的临时问题。

# 进入家目录 cd ~ # 克隆 stable/zed 分支 git clone https://opendev.org/openstack/devstack -b stable/zed cd devstack

2.2 创建本地配置文件local.conf

local.conf是 DevStack 的核心配置文件，它允许我们自定义各种参数，如密码、服务、网络配置等。在devstack目录下创建该文件。

# 使用文本编辑器创建并编辑 local.conf nano local.conf

以下是一个最小化但功能完整的local.conf配置示例，它定义了管理员密码、启用基础服务并配置了简单的 FlatDHCP 网络。将此内容复制到文件中：

[[local|localrc]] # 通用配置 ADMIN_PASSWORD=secretadmin DATABASE_PASSWORD=$ADMIN_PASSWORD RABBIT_PASSWORD=$ADMIN_PASSWORD SERVICE_PASSWORD=$ADMIN_PASSWORD # 启用基础服务 enable_plugin heat https://opendev.org/openstack/heat stable/zed enable_plugin magnum https://opendev.org/openstack/magnum stable/zed # 网络配置 - 使用简单的 FlatDHCP 模式，更易成功 FLOATING_RANGE=192.168.100.224/27 FIXED_RANGE=10.0.0.0/24 FIXED_NETWORK_SIZE=256 FLAT_INTERFACE=eth0 PUBLIC_INTERFACE=eth0 # 禁用安全组（仅用于测试，简化网络访问） disable_service tempest

关键参数解释：

• ADMIN_PASSWORD：OpenStack 管理员密码，其他服务密码默认与其相同。
• FLOATING_RANGE：浮动 IP 池，需要是一个与主机物理网络（eth0所在网络）同网段但未被占用的 IP 段。例如，主机 IP 是192.168.100.10，那么可以设置一个该子网内的小段。
• FLAT_INTERFACE：指定用于扁平网络的物理网卡名称，使用ip addr命令查看你的网卡名（可能是ens33,enp0s3等）。
• disable_service tempest：禁用集成测试服务 Tempest，以加快部署速度。

注意：FLOATING_RANGE的配置是初期失败的高发区。如果主机使用 DHCP 获取 IP，且你无法控制所在网段，可以考虑先使用PUBLIC_INTERFACE=eth0但不配置FLOATING_RANGE，让 DevStack 仅创建私有网络，后续再处理外部网络。

3. 执行部署与监控过程

配置完成后，就可以运行部署脚本了。这个过程会持续较长时间（30分钟到数小时，取决于网络和机器性能）。

3.1 启动部署脚本

在devstack目录下，直接运行stack.sh脚本。

./stack.sh

脚本会开始执行以下主要阶段，可以在终端输出中观察到：

1. 系统依赖安装：安装所需的系统包（如数据库、消息队列）。
2. 项目代码克隆：从 Git 拉取各个 OpenStack 服务的代码。
3. Python 虚拟环境创建与依赖安装：为每个服务创建独立的虚拟环境并安装 Python 包。
4. 数据库初始化：创建服务所需的数据库和表结构。
5. 服务配置与启动：生成配置文件，并以后台进程形式启动所有 OpenStack 服务。

3.2 监控日志与处理交互

部署过程是自动的，但需要关注以下几点：

• 网络交互：脚本可能会提示输入密码或确认，通常直接按回车即可。
• 错误暂停：如果遇到错误，脚本会暂停并高亮显示错误信息。此时需要根据错误日志进行排查（见第5节）。
• 日志文件：所有服务的日志都位于/opt/stack/logs/目录下。如果脚本运行失败，查看stack.sh.log或对应服务的.log文件是首要的排查手段。

一个成功的部署会在最后输出类似以下的信息：

... This is your host IP address: 192.168.100.10 This is your host IPv6 address: ::1 Horizon is now available at http://192.168.100.10/dashboard Keystone is serving at http://192.168.100.10/identity/ The default users are: admin and demo The password: secretadmin ...

记下输出的 Horizon（Web 控制台）地址和管理员密码。

4. 验证部署结果与基本操作

部署脚本成功运行完毕，并不代表所有服务都健康。需要进行基础验证。

4.1 加载环境变量并检查服务状态

DevStack 会创建一个管理员权限的环境变量文件openrc。加载它后，才能使用命令行工具。

# 加载管理员环境变量 source ~/devstack/openrc admin admin

检查核心服务列表是否都处于up状态：

openstack compute service list openstack network agent list openstack volume service list

4.2 访问 Dashboard 并创建第一个实例

1. 打开浏览器，访问http://<你的主机IP>/dashboard。
2. 使用用户名admin和密码secretadmin（即local.conf中设置的ADMIN_PASSWORD）登录。
3. 进入“管理员” -> “系统” -> “计算服务”，查看所有 Nova 服务是否正常。
4. 创建测试实例：
   • 镜像：进入“项目” -> “计算” -> “镜像”，可以上传一个 Cirros（一个微型 Linux 测试镜像）的 QCOW2 文件，或使用 DevStack 可能已预下载的cirros镜像。
   • 网络：确保在“网络” -> “网络拓扑”中，存在一个网络且路由器连接到了外部网络（如果配置了FLOATING_RANGE）。
   • 安全组：添加一条规则，允许 ICMP 和 SSH 入站流量。
   • 启动实例：选择镜像、网络、密钥对（需提前创建），然后启动实例。

4.3 通过命令行管理资源

除了 Dashboard，熟悉命令行操作至关重要。以下是一些基本命令：

# 查看镜像列表 openstack image list # 查看网络列表 openstack network list # 查看创建的实例 openstack server list # 为实例分配浮动 IP openstack floating ip create public openstack server add floating ip <实例ID> <浮动IP地址>

5. 常见问题排查与解决

DevStack 部署失败很常见，关键在于学会查看日志和定位问题。

5.1 部署失败通用排查流程

当./stack.sh运行失败时，按以下顺序排查：

1. 检查最直接的错误信息：脚本停止时，屏幕上最后几行通常包含错误摘要。
2. 查看主日志文件：tail -f /opt/stack/logs/stack.sh.log查看实时日志，或less /opt/stack/logs/stack.sh.log查看完整日志，搜索ERROR、Failed关键字。
3. 检查特定服务日志：如果错误指向某个服务（如nova-api），则查看/opt/stack/logs/nova-api.log。
4. 检查网络连通性：使用ping 8.8.8.8和curl -I https://github.com测试外网连通性。国内环境有时需要配置 Git 和 Pip 代理。
5. 检查资源是否充足：使用free -h查看内存，df -h查看磁盘空间。内存不足会导致编译或服务启动失败。

5.2 典型错误与解决方案

下表列出了几个最常见的错误场景及处理思路：

问题现象	可能原因	检查与解决方案
git clone超时或失败	网络连接问题，特别是访问 GitHub。	1. 配置 Git HTTP/HTTPS 代理：git config --global http.proxy <your_proxy> 2. 或使用国内镜像源（需修改 DevStack 脚本中的仓库地址，较复杂）。
pip install失败，提示包找不到或版本冲突	Python 包索引访问慢或依赖解析问题。	1. 配置 PIP 源：在stack用户下创建~/.pip/pip.conf，指向国内镜像（如清华、阿里云）。 2. 尝试重启./stack.sh，有时重试即可。
服务启动失败，日志中出现Address already in use	端口被占用。可能是之前未清理的旧服务。	运行./unstack.sh和./clean.sh进行彻底清理，然后重新部署。
实例启动失败，状态为ERROR，日志提示No valid host was found	计算节点（本机）资源不足或调度失败。	1. 检查内存和磁盘是否足够。 2. 检查 Nova 计算服务状态：openstack compute service list。 3. 查看/opt/stack/logs/nova-scheduler.log和nova-compute.log获取详细原因。
无法访问 Horizon 控制台	防火墙阻止了 80 端口，或apache2服务未运行。	1. 检查防火墙：sudo ufw status，如需则放行 80 端口：sudo ufw allow 80/tcp。 2. 检查 Apache 服务：sudo systemctl status apache2。
网络创建失败，Neutron 代理异常	网络配置错误，特别是FLAT_INTERFACE指定错误。	1. 确认FLAT_INTERFACE的网卡名是否正确 (ip addr)。 2. 查看/opt/stack/logs/neutron-*.log获取具体错误。 3. 考虑使用更简单的local.conf，先禁用复杂网络功能。

5.3 清理与重装

如果环境混乱需要推倒重来，务必使用 DevStack 自带的清理脚本：

# 在 devstack 目录下执行 ./unstack.sh # 停止所有服务 ./clean.sh # 删除所有编译安装的程序、配置和数据（危险！）

执行clean.sh后，相当于回到了刚克隆完仓库的状态，可以修改local.conf后再次运行./stack.sh。

6. 生产环境考量与最佳实践

再次强调，DevStack 仅适用于开发、测试和学习。如果你需要考虑更接近生产的环境，以下是一些重要的扩展方向和最佳实践：

1. 多节点部署：生产环境需要将控制节点、计算节点、网络节点、存储节点分离。可以考虑使用 Kolla-Ansible、OpenStack-Ansible 或 Charms 等专业的部署工具。
2. 高可用：对关键服务（如 API、数据库、消息队列）实施集群化部署，避免单点故障。
3. 网络规划：生产环境需要精心规划 Provider Networks、Overlay Networks（VXLAN/GRE）、安全组策略、负载均衡器等。
4. 存储后端：DevStack 通常使用本地存储或简单的 LVM。生产环境需要集成 Ceph、SAN/NAS 等共享存储以实现实时迁移和卷服务高可用。
5. 监控与日志：集成 Prometheus、Grafana 进行监控，使用 ELK 或 Loki 栈集中管理日志。
6. 配置管理：所有对 OpenStack 的配置变更都应通过代码（如 Ansible Playbook）进行管理，并纳入版本控制。
7. 定期备份：备份数据库（尤其是 Keystone、Nova、Neutron 的库）和关键配置文件。

对于使用 DevStack 的学习环境，一个核心建议是：将部署成功的整个虚拟机或物理机状态制作一个快照或模板。这样可以在实验环境被破坏后，快速恢复到已知的健康状态，节省大量重复部署的时间。

通过本文的步骤，你应该已经成功搭建起一个基础的 OpenStack 环境。接下来，可以深入探索具体服务的使用，如通过 Heat 进行编排，通过 Magnum 管理容器集群，或者深入研究 Neutron 的网络模型。理解这个单节点环境的构成，是迈向理解复杂分布式云平台架构的第一步。