企业官网建设流程全解析

我最开始碰 OpenStack 的时候，第一反应是这玩意儿没法碰：翻遍教程，不是让你准备三台物理服务器，就是让你上 Kolla-Ansible 拉一堆容器，普通一台笔记本根本遭不住。后来换了 DevStack + Multipass 这套本地方案，才终于找到一条适合学习、调试、复现问题的路径。简单说，这套方案就是在你的笔记本上用 Multipass 秒开一台 Ubuntu 虚拟机，再在虚拟机里用 DevStack 脚本一键拉起整个单节点 OpenStack 云平台，整个过程高度可复现，环境随时可以销毁重来。

读完这篇文章，你能得到一台跑在你本地的真实 OpenStack：有 Dashboard 网页控制台，有 CLI 命令行，能上传镜像、创建网络、启动云主机。它适合三类人：准备学 OpenStack 但不想折腾集群的开发者，需要在本地跑一个测试环境做二次开发的人，以及给团队搭一个可复现演示环境的运维新人。文章里我会把每一步为什么这么做、参数为什么这么写、踩过的坑有哪些都讲清楚，你照着敲命令就行。

1. 为什么选 DevStack + Multipass 这套组合

1.1 DevStack 解决的是“能跑”的问题

OpenStack 本身不是一个软件，是一堆服务的集合。Keystone 管认证，Glance 管镜像，Nova 管计算，Neutron 管网络，Cinder 管块存储，Horizon 管网页界面，Placement 管资源分配。生产环境里这些服务分布在几十台机器上，新手光看架构图就晕了，更别说手动部署。

DevStack 是 OpenStack 官方维护的一套脚本，核心就一个stack.sh。它的作用是在一台干净的系统上，把上面这些服务全部以本地进程方式启动起来，形成一个 all-in-one 的单节点云平台。它不是为了生产环境设计的，而是为了让开发者快速拿到一个能跑、能测、能调试的环境。你在上面做任何实验，都不影响真实业务，这比什么都重要。

有人可能会问，为什么不用 Kolla-Ansible 或者 TripleO？Kolla-Ansible 是容器化部署，适合模拟生产环境的容器编排，但对笔记本资源要求高，拉镜像也费时间；TripleO 主要是给生产环境做裸机部署用的，学习曲线非常陡。手动一步步部署各服务确实能学到最多东西，但如果没有扎实的 OpenStack 服务依赖基础，光一个 Keystone 的 Fernet key 就能卡你一整天。DevStack 的价值在于：先让你有一个能用的环境，再逐步去理解服务之间怎么交互，这是性价比最高的学习路径。

1.2 Multipass 解决的是“环境”的问题

DevStack 官方明确要求跑在 Ubuntu 上，而且最好是一台干净、独立、资源可控的机器。如果你直接拿自己的主力电脑跑，一堆 Python 包、数据库、虚拟网桥全都塞进系统里，后面想清理非常痛苦，一不小心还把开发环境搞乱。

Multipass 是 Canonical 官方出的轻量级虚拟机管理工具，底层在 Linux 上走 LXD，在 macOS 和 Windows 上走 Hyper-V。用起来比 VirtualBox 简单太多，不需要下载 ISO，不需要手动配置网络，不需要等待完整的图形界面装完。你只需一条命令，几十秒内就能得到一台干净的 Ubuntu 虚拟机。它创建出来的虚拟机资源隔离很干净，删除起来也彻底，非常适合做“用完即弃”的实验环境。

为什么不直接用 VirtualBox？两个原因：第一，VirtualBox 创建虚拟机要手动设置 CPU、内存、网络模式，步骤多，而且默认 NAT 网络在虚机里访问外网没问题，但端口转发、SSH 配置都得自己弄；第二，VirtualBox 的图形界面在服务器或远程开发场景下基本没用。Multipass 是纯命令行的，创建、进入、删除一条命令搞定，脚本化能力也强，和 DevStack 这种命令行驱动的部署方式搭配非常顺手。

1.3 这套方案的资源要求与适用边界

在动手之前，先明确一下资源底线。DevStack 单节点跑起来，MySQL、RabbitMQ、Nova、Neutron 这些服务加起来，空闲状态大概要吃 3GB 到 4GB 内存，一旦开始创建云主机、跑编译任务，内存会再往上走。所以：

这套方案能做什么，不能做什么，我提前说清楚。它能满足：学习 OpenStack API、测试自己写的 Heat 模板或 Terraform 配置、调试 Keystone 权限问题、跑通从镜像上传到实例创建的完整流程、作为开发调试控制台。它不能做什么：不能模拟多节点高可用，不能扛生产流量，不能精确衡量生产环境的性能指标。说白了，它是“开发测试环境”而不是“生产实验床”，目标只有一个：让你以最低成本把 OpenStack 跑起来并理解它。

2. 动手前的准备：本机检查和 VM 创建

2.1 本机虚拟化支持和资源检查

Multipass 要正常创建虚拟机，前提是你的 CPU 支持虚拟化并且在 BIOS 里开启了。这一步很多人会忽略，结果创建 VM 时一直失败或者卡住不动。

在 Linux 上，用下面命令确认：

egrep -c '(vmx|svm)' /proc/cpuinfo

输出数字大于 0 就说明支持虚拟化。在 macOS 上，在终端里执行sysctl -a | grep -E 'VMX|SVM'或者直接跑 Multipass 命令看报错。在 Windows 上，打开任务管理器，切到“性能”标签页，看 CPU 的“虚拟化”是否显示“已启用”。如果显示未启用，需要重启进 BIOS，找到 Intel VT-x / AMD-V 相关选项打开。

内存和磁盘检查很简单。Windows 上打开“任务管理器”，macOS 上点左上角苹果图标选“关于本机”，Linux 上执行free -h和df -h。这里我要多说一句：如果你电脑总共只有 8GB 内存，那么给虚拟机分 6GB 之后，宿主机只剩 2GB，开个浏览器都会卡。我建议直接用 4GB 内存跑一个阉割版 DevStack，或者干脆先给虚拟机分 5GB，然后给宿主机加一个临时 swap，后面部署时会更稳。具体怎么做，我放在第 5 章排查部分讲。

2.2 各平台安装 Multipass 的几种方式

Multipass 的安装方式取决于你当前的操作系统。

Windows 用户有两种方式。一种是直接去官网下载安装包，安装完重启终端就能用；另一种是用管理员权限打开 PowerShell，执行winget install Canonical.Multipass。装完后打开新的命令行窗口，执行multipass version，能打印出版本号就说明安装成功。

macOS 用户有 Homebrew 的话，最方便的命令是：

brew install multipass

如果没装 Homebrew，也可以去官网下载.pkg安装包。装完后同样用multipass version验证。

Linux 用户，如果系统是 Ubuntu，最推荐用 snap 安装：

sudo snap install multipass

其他发行版可以下载对应的 AppImage 或二进制包，不过 DevStack 本身要求 Ubuntu 系统，如果你宿主机是其他 Linux 发行版，把 Multipass 装好之后，里面照样跑 Ubuntu 虚机，没冲突。

有一个坑需要提前说：Windows 上如果 Multipass 默认使用 Hyper-V 驱动，但你的系统是家庭版或者没启用 Hyper-V，创建 VM 时会报错。解决方法是用multipass set local.driver=virtualbox，前提是你装了 VirtualBox；或者用multipass set local.driver=hyperv并启用 Windows 功能里的 Hyper-V，重启后再试。macOS 上一般默认驱动是 qemu，不需要额外配置。

2.3 用 multipass launch 创建开发用虚拟机

Multipass 安装好之后，不需要做任何镜像预下载，它会自动拉取 Ubuntu 官方镜像。创建一台供 DevStack 使用的虚拟机，我推荐的命令是：

multipass launch 22.04 --name devstack --cpus 4 --memory 8G --disk 50G

这里有几个参数需要解释。22.04指定 Ubuntu 22.04 LTS 版本，这是 DevStack 社区验证最充分、踩坑最少的版本，虽然 24.04 也能跑，但遇到问题时可参考的资料少很多，没必要给自己增加难度。--name给虚拟机起个名字，后面操作都靠这个名字。--cpus 4分配 4 个 CPU 核心，--memory 8G分配 8GB 内存，--disk 50G分配 50GB 磁盘。

创建完成后，执行multipass list能看到这台虚拟机的状态和 IP 地址。执行multipass shell devstack可以直接进入虚拟机终端，执行multipass info devstack可以查看资源使用情况。如果创建失败，可以先看一下是不是虚拟化没开启，或者宿主机内存不足。

进入虚拟机后，第一件事是更新系统包。虽然 Multipass 拉取的镜像是官方的，但软件包索引可能比较旧。在虚拟机的终端里执行：

sudo apt update && sudo apt full-upgrade -y

这个过程可能需要几分钟，取决于网络速度。更新完建议重启一次虚拟机，让内核和系统服务都处于干净状态：

sudo reboot

重启后用multipass shell devstack重新进入。

2.4 进入 VM 后的基础系统配置

系统更新完成后，还需要装几个基础工具，不用很多，够用就行：

sudo apt install -y git vim software-properties-common

然后确认虚拟机的 IP 地址，后面配置 DevStack 时要用到：

ip -4 addr show

常见情况下输出类似192.168.64.2或10.0.2.15，取决于 Multipass 使用的虚拟网络。记下这个 IP。

这里再分享一个经验：后面的 DevStack 部署过程比较长，如果 Multipass shell 窗口在部署中途断开了，终端会话里的进程可能会被中断。为了解决这个问题，建议在虚拟机里安装并启用 tmux：

sudo apt install -y tmux tmux new -s devstack

后续部署命令都跑在 tmux 会话里，即使 SSH 断开，重新连上后执行tmux attach -t devstack还能回来。这一步看起来不起眼，但遇到网络不稳定或笔记本待机时，能帮你少跑一次完整部署。

3. DevStack 部署实操：从 clone 到 stack.sh

3.1 创建 stack 用户和下载 DevStack

DevStack 官方明确要求不能以 root 用户运行，原因是脚本里有很多检查，用 root 跑会报错，而且从安全角度讲，运行第三方部署脚本时用低权限用户更稳妥。在虚拟机里创建一个名为stack的用户：

sudo useradd -s /bin/bash -d /opt/stack -m stack

然后给 stack 用户免密 sudo 权限，因为 DevStack 在部署过程中需要执行大量需要 root 权限的操作：

echo "stack ALL=(ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/stack

接着切换到 stack 用户：

sudo -i -u stack

后面所有操作都在 stack 用户下进行。如果前面用了 tmux，直接在 tmux 会话里执行切换。

从官方代码仓库克隆 DevStack。注意，DevStack 代码托管在 OpenStack 的官方 Gerrit 代码库，地址是https://opendev.org/openstack/devstack，不是 GitHub。命令如下：

cd ~ git clone https://opendev.org/openstack/devstack.git cd devstack

如果你在国内网络环境下 clone 特别慢，可以用https://github.com/openstack/devstack.git或者 OpenMirror 等镜像，这只是为了拉代码快一点，不影响后续使用。

3.2 选对分支，master 容易踩坑

很多人 clone 完就直接跑，结果跑到一半报各种奇怪错误。这是因为 DevStack 的 master 分支处于持续开发状态，今天能跑通，明天一个上游变更就挂了。

正确的做法是选择一个稳定的 release 分支。以 2024.1 版本（代号 Caracal）为例：

git checkout stable/2024.1

如果你想用更新的版本，可以先git branch -r查看所有远程分支，找一个最新的 stable 分支。我的建议是：如果要追求稳定和排障方便，就用 stable/2024.1 或 stable/2023.2；如果想尝鲜，再考虑 master。对第一次部署的人来说，稳定分支能帮你把变量控制在最小范围内，出了问题时网上能搜到的经验也最多。

3.3 local.conf 逐项解析与推荐模板

DevStack 的配置核心是一个叫local.conf的文件，它放在 devstack 目录下，里面写的是部署参数。官方文档对里面每一项都有描述，但我把最关键的几项拆开讲。

在devstack目录下创建local.conf：

vim local.conf

内容如下：

[[local|localrc]] ADMIN_PASSWORD=admin123 DATABASE_PASSWORD=admin123 RABBIT_PASSWORD=admin123 SERVICE_PASSWORD=admin123 HOST_IP=你的虚拟机IP LOGFILE=$DEST/logs/stack.sh.log LOGDAYS=2 # Swift 和 Cinder 根据需求启用 disable_service tempest

解释一下这些参数的含义。

ADMIN_PASSWORD是部署完成后登录 OpenStack 控制台的 admin 用户密码。DATABASE_PASSWORD、RABBIT_PASSWORD、SERVICE_PASSWORD分别是 MySQL、RabbitMQ 和内部服务使用的密码。这里我统一设成了同一个值，省得记好多个密码。注意，如果你设置的密码太简单，有些服务可能不接受，建议至少 8 位以上。

HOST_IP是这台虚拟机的 IP 地址，必须和 2.4 节里查到的 IP 一致。DevStack 会用这个 IP 生成服务端点，注册到 Keystone 里，后面 Dashboard 和 CLI 访问都靠它。

LOGFILE指定部署日志的保存位置，默认在/opt/stack/logs/stack.sh.log。出错时这是第一排查对象。

disable_service tempest是关掉 tempest 测试套件，因为本地实验环境不需要跑集成测试，能省不少部署时间。

还有一个参数值得提，GIT_BASE。默认情况下 DevStack 会从git.openstack.org或者opendev.org拉取 OpenStack 各组件的源码，如果你所在网络访问这些地址慢，可以在 local.conf 里加一行：

GIT_BASE=http://github.com

这会让 DevStack 从 GitHub 的 OpenStack 镜像仓库拉代码。不过需要注意，改成 GitHub 后有些镜像仓库路径是https://github.com/openstack/xxx.git，默认就会补充这个前缀，一般没问题。如果你的网络环境下 GitHub 也不快，可以考虑用 Gitee 等代码托管平台上的 OpenStack 镜像，但那种方式对不同服务的兼容情况参差不齐，我建议优先用默认地址，配合多尝试几次，实在不行再换。

3.4 执行 stack.sh 与日志观察技巧

local.conf 配置完成之后，在 devstack 目录下执行：

./stack.sh

这一步会持续 20 到 50 分钟，视网络和机器性能而定。期间会看到大量输出，包括 git clone OpenStack 各项目、安装 Python 依赖、生成配置文件、初始化数据库、启动服务等。

屏幕上的输出刷得很快，你不可能完全看完，但可以留意几个关键阶段：

1. 阶段一，Cloning OpenStack projects：这个阶段在拉取各组件源码，如果网络慢会卡住，此时耐心等待，不要轻易 Ctrl+C。
2. 阶段二，Installing Python packages：会看到大量 pip 安装输出。如果在这里报错，多半是网络或 pip 源问题。
3. 阶段三，Starting services：脚本开始启动 Keystone、Glance、Nova、Neutron 等服务，并输出类似Starting ... service的提示。

当看到最后几行类似下面的输出时，说明部署基本成功：

This is your host IP address: 192.168.64.2 Horizon is now available at http://192.168.64.2/dashboard

如果你用的 tmux 会话，部署过程中可以随时按 Ctrl+B 再按 C 开一个新窗口，执行tail -f /opt/stack/logs/stack.sh.log查看实时日志。有一点必须强调：如果stack.sh中途失败，不要直接再跑一次，先看日志确认失败原因。盲跑第二次往往会在同一个坑里再跌一次。

3.5 部署完成后的服务状态验证

部署成功后，先别急着创建云主机，花两分钟验证一下核心服务是否都在线。加载 OpenStack 环境变量：

source ~/devstack/openrc admin admin

这个文件是 DevStack 自动生成的，里面设置了OS_AUTH_URL、OS_USERNAME、OS_PASSWORD等环境变量。然后执行：

openstack service list openstack endpoint list openstack compute service list

第一条命令查看注册的服务类型，如果看到compute、identity、image、network、placement等条目，说明服务注册正常。第二条命令查看 API 端点地址，确认HOST_IP是否生效。第三条命令查看 Nova 计算服务的状态，State列如果是up，Binary列对应nova-compute的服务是enabled，说明计算节点正常。

再检查一下网络服务：

openstack network agent list

确认neutron-linuxbridge-agent或类似 agent 的State是alive。这一步经常被忽略，但后面创建实例失败往往就是网络 agent 没起来。

最后打开浏览器，访问http://你的虚拟机IP/dashboard，能出现登录页面就说明 Horizon 正常。用admin和local.conf里设置的密码登录，你就真正进入 OpenStack 控制台了。

4. 在云平台上创建第一台实例

4.1 加载管理员环境变量

部署完成后的 OpenStack 平台上，账户权限、网络、镜像都是空的，需要自己一步步创建。先把管理员环境加载好：

source ~/devstack/openrc admin admin

这一行的第一个admin是用户名，第二个admin是项目名（租户名），DevStack 默认创建了名为admin的项目。执行env | grep OS_可以看到所有设置好的环境变量，其中OS_AUTH_URL应该指向你配置的HOST_IP的 5000 端口。

如果后面命令行工具报Unauthorized或The request you have made requires authentication，通常是因为环境变量没加载，或者密码和 local.conf 里不一致。

4.2 上传 Cirros 测试镜像

创建实例前得有镜像。Cirros 是一个专为 OpenStack 测试设计的最小 Linux 镜像，只有十几兆，自带 cloud-init，能自动注入 SSH 密钥，非常适合验证流程。下载并上传：

cd ~ curl -L -o cirros.img http://download.cirros-cloud.net/0.6.2/cirros-0.6.2-x86_64-disk.img

下载完执行：

openstack image create --public \ --container-format bare \ --disk-format qcow2 \ --file cirros.img \ cirros

参数解释如下。--public表示所有项目都能使用这个镜像，--container-format bare和--disk-format qcow2是标准的镜像格式声明，--file cirros.img指定要上传的文件，最后一个cirros是给镜像起的名字。上传完成后用openstack image list确认状态为active。

4.3 创建扁平网络和路由

网络是新手最容易卡住的地方。先看一下默认网络情况：

openstack network list

DevStack 默认会创建一个叫public的外部网络，甚至可能有一个叫private的内部网络。为了方便演示完整的网络流程，我带你从零创建一个独立的内网并把它和外部网络连通。

首先手动创建一个内部网络和子网：

openstack network create demo-net openstack subnet create demo-subnet \ --network demo-net \ --subnet-range 192.168.100.0/24 \ --dhcp

--subnet-range可以自己选，只要不和主机网络冲突即可。这里选192.168.100.0/24，是因为 DevStack 默认的外部网络通常占用172.24.4.0/24网段，两者不会冲突。

接着创建路由器，把内部网络和外部网络连起来：

openstack router create demo-router openstack router set demo-router --external-gateway public openstack router add subnet demo-router demo-subnet

这三条命令相当于把内网的出口接到公网上，云主机只有经过路由器才能访问外网。如果不做这一步，实例即使起来也 ping 不通外网。

4.4 配置规格、安全组与密钥对

DevStack 默认已经创建了m1.tiny、m1.small等规格，不需要额外创建，执行openstack flavor list可以确认。m1.tiny的配置是 1 核、512MB 内存、1GB 磁盘，跑 Cirros 完全够用。

安全组规则默认会创建default安全组，但它的入站规则默认是拒绝一切。为了让实例能被 ping 通和 SSH 登录，需要放行 ICMP 和 22 端口：

openstack security group rule create --proto icmp default openstack security group rule create --proto tcp --dst-port 22 default

第一条放行 ICMP 协议，也就是 ping 命令；第二条放行 TCP 的 22 端口，也就是 SSH。

密钥对用于登录实例。生成一个本地 SSH 密钥，把公钥上传到 OpenStack：

ssh-keygen -t rsa -b 2048 -f ~/.ssh/id_rsa -N "" openstack keypair create --public-key ~/.ssh/id_rsa.pub mykey

如果你不想生成密钥，也可以直接用密码登录，但这会多一层安全组配置，没必要。用密钥对是最规范的方式。

4.5 启动实例并验证网络连通

所有前置条件准备好之后，启动一台测试云主机：

openstack server create \ --flavor m1.tiny \ --image cirros \ --network demo-net \ --key-name mykey \ demo-instance

执行openstack server list能看到实例状态从BUILD变为ACTIVE。这个过程一般需要十几秒到半分钟。如果状态一直停留在BUILD，多半是 Nova 或 Neutron 服务有问题，参考第 5 章排查。

给实例分配一个浮动 IP，让你能从外部访问它：

openstack floating ip create public

记下返回的floating_ip_address，然后绑定到实例：

openstack server add floating ip demo-instance <浮动IP>

在 OpenStack 这台虚拟机内部测试连通性：

ping -c 3 <浮动IP>

能收到 ICMP 回包，说明整个链路是通的。这一步放在 OpenStack 所在的 VM 里执行，是因为 DevStack 单机部署时浮动 IP 是在虚拟机内部的网络命名空间里处理的，从宿主机直接访问不一定通，这是正常现象。

SSH 登录实例验证密钥注入：

ssh -i ~/.ssh/id_rsa cirros@<浮动IP>

Cirros 镜像默认用户是cirros，密码是gocubsgo，但用密钥登录时会优先走密钥认证。如果你能登录进去，恭喜，你已经成功在本地从零搭建并使用了 OpenStack 云平台。

4.6 用 Horizon 图形界面再操作一遍

命令行跑通之后，我建议你再到 Horizon 网页控制台点一遍。这不是重复劳动，而是帮助你建立 OpenStack 抽象模型的直观认识。

打开http://你的虚拟机IP/dashboard，用 admin 登录。在左侧导航栏的“项目”下面，你能看到“计算”、“网络”、“镜像”等菜单，分别对应命令行里的nova、neutron、glance。点“计算”里的“实例”，能看到刚才用命令行创建的demo-instance；点“网络”里的“网络拓扑”，能看到网络和路由的关系图。

在 Horizon 里再创建一台实例也可以，流程和命令行几乎一一对应：启动实例时选镜像、选规格、选网络、选密钥对、选安全组，每一步都有对应用户界面。熟练之后你会发现，图形界面的每个参数，其实背后都对应一个 API 调用，这也解释了为什么 OpenStack 有那么多 CLI 工具，因为它们只是 API 的封装。

5. 常见问题与排查技巧实录

5.1 高频问题速查表

我在多台机器上用这套方案部署过，也在给同事带教时记录过各种报错，下面这张表基本覆盖了 90% 的常见问题。

这些问题的共性是：多数不是 OpenStack 本身的 bug，而是网络、资源和配置问题。所以排查顺序永远先是看日志，再确认资源，最后才怀疑代码。

5.2 日志和进程排查的完整路径

OpenStack 各服务运行时会产出大量日志，DevStack 统一把它们放在/opt/stack/logs/目录下。这个目录下面的文件按服务命名，比如nova-compute.log、neutron-server.log、keystone.log，一眼就能找到对应服务。

部署日志是另一个入口。stack.sh.log记录了整个部署过程的输出，路径在/opt/stack/logs/stack.sh.log。执行tail -n 100 /opt/stack/logs/stack.sh.log查看部署失败时的最后一段输出，通常能定位到具体步骤。

如果你要排查哪个服务起不来，先看它的系统状态。DevStack 会为服务注册 systemd 单元，用systemctl status devstack@nova-compute查看状态，用journalctl -u devstack@nova-compute -n 50查看最近日志。这个命令模式可以替换成其他服务名，比如devstack@neutron-server。

还有一个常用的排查姿势：查看某个端口的监听情况。比如 Keystone 挂了，curl http://你的虚拟机IP:5000应该返回 JSON 或 401 响应，如果连接拒绝，说明服务没起来。执行ss -tlnp也能看到哪些端口在监听，用这个对照 OpenStack 默认端口表，能快速定位目标服务是否存活。

5.3 重启后的恢复操作和日常维护

OpenStack 服务不像普通应用，重启系统后不会自动全部恢复。如果你关闭并重新启动 Multipass 虚拟机，需要手动恢复服务。

最简单的恢复方式是执行 DevStack 自带的重新加入脚本：

cd ~/devstack ./rejoin-stack.sh

这个脚本会把所有 DevStack 管理下的服务重新拉起来。执行完再验证关键服务：

openstack service list

如果提示认证失败，先重新source ~/devstack/openrc admin admin。如果rejoin-stack.sh不能完全恢复，更彻底的方式是先停服务再重新部署：

cd ~/devstack ./unstack.sh ./stack.sh

unstack.sh会停止所有相关进程并清理状态，stack.sh重新执行完整部署。重新部署不一定 100% 干净，但至少能保证你得到一个可用的环境。

日常使用时还要注意磁盘空间。/opt/stack目录包含了所有组件代码和数据，时间久了容易膨胀。用du -sh /opt/stack和df -h定期检查。如果磁盘满了，先清理stack.sh.log这种大日志文件，再清理/opt/stack/data下没用的虚拟机镜像。

5.4 彻底销毁重建的干净姿势

这套方案最强的一点，就是环境可以随时彻底销毁。如果你觉得当前环境已经搞得乱七八糟，或者想测试另一个 OpenStack 版本，直接：

multipass delete devstack multipass purge

第一条命令删除虚拟机，第二条命令彻底清理磁盘上的残留数据。然后回到第 2.3 节，重新执行multipass launch，再走一遍部署流程。整套流程从零开始大概三十分钟，比你手动卸载一堆服务要快得多。

如果你不想从头部署，只想在现有环境里测试不同配置，建议用multipass copyvm复制一份虚拟机，在副本上做实验：

multipass copyvm devstack devstack-test

这样原始环境不受影响，实验环境独立，跑坏了直接删掉devstack-test重新复制，非常灵活。

我自己在实际操作中的感受是，这套组合最让人安心的地方就是“不怕搞坏”。以前用传统方式搭 OpenStack，出了问题是想着怎么修复；现在出了问题是想着干脆删了重建。这不是偷懒，而是 DevStack 和 Multipass 这类工具的设计哲学本身就是“可丢弃、可重建”。当你不再担心环境被搞坏时，反而更愿意去尝试各种配置，比如加一个服务、改一个网络模式，这些尝试才是真正能加深理解的部分。多折腾几次，OpenStack 的服务依赖关系、配置项的来龙去脉，都会变得清晰起来。