如果你是一名刚接触 OpenStack 的运维工程师第一次想在自己电脑上把这个云平台真正跑起来我的建议是先别碰手动部署。最早我照着官方文档手动装过一次装到 neutron 的时候心态就崩了——组件依赖多、版本匹配难、数据库初始化一步错就得全部重来。后来转向 DevStack一条stack.sh脚本二十多分钟把一整套 OpenStack 拉起来Keystone、Nova、Neutron、Glance、Horizon 全齐活。这个“每天5分钟玩转 OpenStack”系列写到第 17 篇前面讲了很多概念这一篇开始动手从部署 DevStack 入手把环境跑起来后面再聊组件原理就有抓手了。做运维这么多年我越来越觉得“能跑起来”比“背概念”重要得多。DevStack 就是那种能让你在最短时间内看到 OpenStack 全貌的工具适合学习、适合开发调试、适合做接口联调但不适合生产。这篇文章会把整个部署过程拆开讲包括环境怎么规划、local.conf 怎么写、每个参数是什么含义、部署完怎么验证、踩坑了怎么排查尽量让新手也能照着走完。1. 认识 DevStack为什么它是 OpenStack 入门的第一站1.1 DevStack 是什么DevStack 是 OpenStack 社区官方维护的一套脚本工具集。它的核心作用是在一台干净的 Linux 主机上自动完成 OpenStack 各服务的下载、配置、初始化、启动最终给你一个可以登录、可以创建云主机的完整环境。它和一键安装包有本质区别DevStack 拉取的是 OpenStack 项目的代码仓库你可以自由切换分支、修改代码、重启指定服务本质上是一个为开发者和学习者准备的“可折腾”环境。很多人会把 DevStack 当成 OpenStack 的安装包这个理解不够准确。它更像一套脚本化的部署流程你把参数告诉它它按顺序把所有事情做完。它的设计目标不是“装完就不动”而是“装完方便你反复改、反复重来”。我自己最常用的场景就是改一段 neutron 代码然后重启对应服务看效果验证完直接unstack.sh推倒重来。1.2 它解决的核心痛点手动部署 OpenStack 最痛的不是某个组件难装而是组件之间的依赖关系太复杂。以最简环境为例至少要装 Keystone认证、Nova计算、Neutron网络、Glance镜像、Horizon界面每个服务还有自己的数据库、配置文件、日志目录、消息队列对接。这些服务之间的调用关系是一张网不是一条线。DevStack 把这张网自动织好了。它会替你创建数据库、初始化表结构、生成服务账号、配置消息队列、设置网络参数、写入配置文件甚至帮你启动所有服务的进程。你只需要关注两件事硬件够不够local.conf 配得对不对。更重要的是“快速重建”能力。学习 OpenStack 过程中改坏配置文件是家常便饭。手动部署时改坏了可能得手动清理一堆残留但 DevStack 环境下unstack.sh停服务、clean.sh清数据、重新./stack.sh半小时又是一套干净环境。这种“随时可以推倒重来”的底气是学习过程中最值钱的东西。1.3 DevStack 与生产部署工具的本质区别这里必须说清楚一个边界DevStack 不是生产部署工具。生产环境部署 OpenStack主流方案是 Kolla-Ansible基于容器化部署、TripleO基于镜像编排、OpenStack-Ansible基于 Ansible等。这些方案会有高可用、负载均衡、安全加固、滚动升级等能力而 DevStack 完全没有这些。那为什么还要学 DevStack因为运维工程师理解 OpenStack 架构最有效的方式就是先看它在一台机器上怎么跑起来的。Kolla-Ansible 把服务封装进容器很多细节被容器隔离了反而不容易理解组件间的关系。DevStack 所有服务都以本机进程方式运行日志直接写在/opt/stack/logs/下配置直接躺在/etc/里你想看什么都能看到。它像是解剖模型而生产工具更像是一台整机。先看模型再碰整机路径就顺了。2. 部署前的环境规划这几件事不做好后面全是坑2.1 硬件配置要求与资源评估DevStack 对硬件的要求核心瓶颈不在 CPU而在内存和磁盘。我自己实测低配机器装到一半可能服务起不来不是脚本有问题是资源确实不够。项目最低要求推荐配置说明CPU2 核4 核及以上编译源码和启动服务都会用到核太多没坏处内存8 GB16 GB8GB 能装完但创建云主机后会很卡16GB 更从容磁盘40 GB 可用80 GB 以上 SSD源码、镜像、数据库日志都占空间SSD 能明显缩短安装时间网络可访问外网固定 IP 的网络需要拉取代码和安装依赖包固定 IP 能避免很多服务注册的坑很多人会问2 核 8GB 的虚拟机能不能跑能跑但你要有心理准备。部署完成后光是 Keystone、Nova、Neutron、Glance、Horizon 加上数据库和消息队列内存占用基本就到 5GB 以上了。你再创建一台云主机里面跑的是虚拟机里的虚拟机内存马上吃紧。所以我一直建议如果用云主机测试选 4 核 16GB 这个档位一步到位省得后面反复折腾。磁盘方面DevStack 会把 OpenStack 所有项目代码 clone 到/opt/stack/下这部分大概 3~5GB。数据库文件、日志、镜像文件会继续占用空间。如果你还准备上传几个测试镜像、创建几台临时云主机40GB 是最低门槛上不封顶。2.2 操作系统选择与 stack 用户创建DevStack 官方支持的 Linux 发行版中Ubuntu 是最省心的一个。我建议直接用 Ubuntu 22.04 LTS 或 24.04 LTS 的干净系统。CentOS 和 Fedora 也不是不能用但遇到问题排查时网上的资料大部分都基于 Ubuntu少给自己添堵。系统装好后DevStack 明确要求不能直接用 root 用户执行脚本。原因很简单脚本里有很多操作是普通用户权限下执行、再通过 sudo 提权的这样能减少误操作对整个系统的损害。官方推荐创建一个叫 stack 的用户sudo useradd -s /bin/bash -d /opt/stack -m stack sudo chmod x /opt/stack echo stack ALL(ALL) NOPASSWD: ALL | sudo tee /etc/sudoers.d/stack sudo su - stack这段命令创建了一个主目录在/opt/stack的用户并且给了它免密的 sudo 权限。最后的sudo su - stack是为了直接切换到这个用户后面所有操作都在这个用户下进行。我习惯在装完系统后先执行一遍sudo apt update sudo apt upgrade -y把系统基础包更新到最新版本再开始。倒不是必须但能减少一些依赖库版本过旧导致的编译错误。2.3 网络规划固定 IP 比动态 IP 省心得多DevStack 部署时HOST_IP是核心参数之一。安装脚本会用这个 IP 作为 OpenStack 各服务对外监听的地址也会写进 Keystone 的 endpoint 里。如果这台机器的 IP 后来变了你会发现 Horizon 能打开但 API 请求全部失败因为 endpoint 还是指向老 IP。所以我的建议是部署前先把 IP 固定下来。在虚拟机里就给网卡配静态 IP在物理机上也可以从路由器 DHCP 池里预留一个地址。还有个很容易忽略的坑/etc/hosts里主机名解析要正常。最好把本机 IP 和主机名加上去防止部分服务通过主机名访问时解析到 127.0.0.1。顺带确认一件事如果你打算在虚拟机里跑 DevStack请在虚拟机软件设置里确认“嵌套虚拟化”功能已经打开。OpenStack 里的 Nova 计算服务需要用 KVM 启动实例这要求在宿主机的 CPU 支持硬件虚拟化且虚拟化标记能透传进虚拟机。可以在安装前先用这个命令验证grep -E -c (vmx|svm) /proc/cpuinfo返回的数字大于 0说明当前环境能看到虚拟化标志位。如果返回 0后续创建云主机大概率会失败要么换台带虚拟化支持的机器要么想办法确认虚拟化层面是否锁住了。2.4 网络管理工具的干扰问题DevStack 安装 Neutron 的时候会在系统里创建网桥、虚拟网卡并配置 iptables 规则。如果你的系统里还开着 NetworkManager、firewalld 这类网络管理服务它们可能会在安装过程中主动去修改网络配置导致 Neutron 的虚拟网络设备起不来。Ubuntu Desktop 版本默认启用 NetworkManager服务器版则用 netplan。如果可能我建议直接用 Ubuntu Server 版来跑 DevStack然后关闭不需要的网络管理服务sudo systemctl stop NetworkManager sudo systemctl disable NetworkManager如果是干净的 Server 版网络配置走 netplan一般不会和 Neutron 冲突。要注意的是自己手动关闭 NetworkManager 之后一定要确认系统的物理网卡仍然能正常工作否则后面部署过程中 SSH 突然断开那才是最抓狂的。3. 部署实操从拉取代码到仪表板可用的完整流程3.1 获取 DevStack 源码确认环境准备完毕后第一步是把 DevStack 的代码仓库拉下来。官方仓库在 OpenDev 平台上使用git clone命令即可sudo apt update sudo apt install -y git git clone https://opendev.org/openstack/devstack cd devstack你可能注意到这里没有手动安装很多依赖包。DevStack 脚本会在安装过程中自动搞定包括 Python 版本、pip、数据库、消息队列等。这种“脚本从头管到尾”的设计也是它能保持操作简单的原因。国内网络环境下从 GitHub 或 OpenDev 拉代码的速度可能会波动。DevStack 支持通过GIT_BASE参数修改代码下载源如果你所在网络环境拉取很慢可以考虑临时把GIT_BASE指向访问速度更快的镜像仓库。但要注意镜像仓库的代码同步及时性和完整性不一定有保证这属于环境优化手段不作为默认推荐。多数情况下耐心等一会儿就过去了。3.2 编写 local.conf部署的核心配置文件DevStack 的部署行为全部由local.conf控制。它位于 devstack 目录下格式采用 ini 风格里面可以定义密码、IP、启停组件、日志级别、版本分支等。在首次部署前至少要创建一个最小可用的配置[[local|localrc]] ADMIN_PASSWORDsecretadmin DATABASE_PASSWORD$ADMIN_PASSWORD RABBIT_PASSWORD$ADMIN_PASSWORD SERVICE_PASSWORD$ADMIN_PASSWORD HOST_IP192.168.1.100这里我解释一下每个参数的含义。ADMIN_PASSWORD是管理员用户的密码也是你登录 Horizon 和命令行时的主要凭据。DATABASE_PASSWORD、RABBIT_PASSWORD、SERVICE_PASSWORD分别是数据库、RabbitMQ 消息队列、内部服务账号的密码。注意$ADMIN_PASSWORD这个写法它直接引用了上面定义过的变量。DevStack 配置文件里支持这种变量引用好处是你只需要修改一处密码值其他密码自动跟着变不用每行都单独改。这个技巧在实际操作中非常实用尤其当你准备把部署脚本提交到 Git 仓库做版本管理时只需要记得别把真实密码硬编码到代码里。HOST_IP是最容易出错的一项。这里必须是当前机器实际可用的 IP 地址对外的 API endpoint 会基于这个 IP 生成。写错了会是什么现象部署可能正常完成但是你用命令行登录时会发现认证地址指向一个完全不对的 IP这时候再排查就要花不少时间。下面是一个更完整的配置示例适合学习场景[[local|localrc]] ADMIN_PASSWORDsecretadmin DATABASE_PASSWORD$ADMIN_PASSWORD RABBIT_PASSWORD$ADMIN_PASSWORD SERVICE_PASSWORD$ADMIN_PASSWORD HOST_IP192.168.1.100 RECLONEnoRECLONEno的意思是部署时如果本地已经有项目代码不重新拉取。首次部署时可以不用管但如果你打算升级到最新代码把它改成yesDevStack 会强制重新拉取一遍各项目代码成功切换版本后再改回来即可。3.3 执行 stack.sh 并解读安装过程环境配置就绪后开始正式部署./stack.sh这条命令会执行很长一段时间首次部署 20~40 分钟都很正常取决于硬件性能和网络速度。终端会滚动打印大量输出从 apt 安装系统依赖包到 pip 安装 Python 包再到数据库初始化。你不要被这些输出吓到大部分阶段脚本都在自动处理。安装过程大致可以分成几个阶段。第一阶段是系统层面准备脚本会调用 apt 安装编译工具、Python 开发库、数据库服务、消息队列服务等。第二阶段是代码拉取所有 OpenStack 项目keystone、nova、neutron、glance、horizon 等的源码会被克隆到/opt/stack/目录。第三阶段是配置生成脚本根据 local.conf 生成各服务的配置文件并把服务之间的认证信息、数据库连接、消息队列地址写入。第四阶段是启动服务所有 OpenStack 组件会依次启动日志写到/opt/stack/logs/目录下。如果你遇到长时间没有输出的情况不要直接 CtrlC。先用另一个终端 SSH 进机器查看日志确认当前进度tail -n 100 /opt/stack/logs/stack.sh.log这个日志文件记录了脚本执行到哪一步排查问题时看它比看终端输出有用得多。真正部署完成时终端最后几行一般会显示 Horizon 的访问地址和管理员提示信息。3.4 部署完成后的第一轮检查Deployment 结束后不要急着登录界面。先做一轮快速检查确认核心服务真的活着。最简单的命令是cd /opt/stack/devstack ./status.sh它会列出当前 DevStack 管理的所有服务进程状态正常情况应该全部显示 running 或 enabled。如果某个服务状态不对比如 neutron-server 挂了再针对性地去看对应日志。命令行工具也要顺手验证一下source /opt/stack/devstack/openrc admin admin openstack service listsource openrc admin admin的作用是加载管理员凭据环境变量。之后openstack service list如果列出了 keystone、nova、neutron、glance 等服务的端点信息说明认证服务和基础服务都正常。浏览器访问http://192.168.1.100/dashboard用admin或demo用户登录密码就是你在ADMIN_PASSWORD里设置的值。devstack 默认创建了好几个演示用户包括admin和demo都属于各自的默认项目。能看到登录页并顺利进入控制台就说明整套环境已经喘上气了。4. 跑通第一个云主机部署只是学习的第一步4.1 通过 Horizon 仪表板上传镜像和创建网络DevStack 默认是创建了一些“演示数据”的包括默认的外部网络和租户网络但如果你想完整体验一遍“上传镜像、创建网络、创建云主机”的流程建议自己动手走一遍。登录 Horizon 后左侧菜单找到“镜像”页面点击“创建镜像”。镜像文件可以从 Cirros 官网下载这是一个专门为 OpenStack 测试设计的最小 Linux 镜像只有十几 MB非常适合当练习对象。上传时选择镜像文件容器格式选“Bare”磁盘格式选“QCOW2”可见性可以选“公共”这样 demo 用户也能使用这个镜像。接着进入“网络”菜单创建网络。学习环境里可以创建一个扁平网络子网网段用10.0.0.0/24网关保持默认即可。这里要理解的是云主机在 OpenStack 里默认是拿不到公网流量的需要网络、路由、浮动 IP 三层配合。DevStack 默认会提供一个外部网络你把新建的私有网络通过路由器连接到外部网络再给云主机分配浮动 IP才能从外部访问到云主机。4.2 使用命令行完成同一套操作命令行方式更适合自动化脚本和后续的运维操作。同样的步骤用 CLI 命令走一遍能帮你把概念理得更清楚。先加载凭据source /opt/stack/devstack/openrc admin admin然后上传镜像openstack image create cirros \ --container-format bare \ --disk-format qcow2 \ --file cirros-0.6.2-x86_64-disk.img \ --public创建网络和子网openstack network create net1 openstack subnet create subnet1 \ --network net1 \ --subnet-range 10.0.0.0/24 \ --dns-nameserver 8.8.8.8创建云主机openstack server create test-vm \ --image cirros \ --flavor m1.tiny \ --network net1m1.tiny是 DevStack 默认创建的最小规格内存只有 512MBCPU 1 核学习完全够用。创建完成后用openstack server list查看实例状态看到ACTIVE就说明 Nova 已经成功调度并启动了虚拟机。这一步成功有着特殊意义它证明了 Nova 计算节点能正常使用 KVM 创建虚拟机Neutron 网络节点能分配 IPGlance 镜像能正常引导系统。整条链路走通了OpenStack 才算真正“能用”。4.3 验证服务状态和日志位置日常调试 OpenStack最常用的服务状态检查方式前面已经提过就是./status.sh。但如果你想看某个具体服务的日志DevStack 的日志目录设计非常直接ls /opt/stack/logs/里面可以看到nova-compute.log、neutron-server.log、keystone.log等各服务的日志文件。排查时先对应当前出问题的服务然后再去日志里搜异常关键字。比如创建云主机失败第一步应该是看nova-compute.log而不是到处乱猜。这套日志组织方式和生产环境的集中化日志平台比不了但对学习阶段来说它反而更友好每个服务一个文件路径固定、语义清晰。这也是我推荐用 DevStack 学习底层组件的一个原因你想知道哪个组件在干什