企业官网建设流程全解析

1. 为什么要在 Ubuntu 18.04 上折腾单节点 OpenStack

很多人第一次接触 OpenStack 都是在虚拟机里跑一个 All-in-One 环境，而 DevStack 几乎是绕不开的起点。它的定位很明确：不是给生产环境用的，而是给开发者、测试人员和想快速理解 OpenStack 组件协作关系的人，用一套脚本把 Keystone、Nova、Neutron、Glance、Cinder、Horizon 等核心服务全部拉起来。你不需要手动一个个装服务、配数据库、调消息队列，DevStack 会帮你把这些脏活累活全干了。

但问题也恰恰出在这里。DevStack 的“自动化”是建立在对系统环境极度敏感的基础上的，尤其是 Ubuntu 18.04 LTS 这个版本，它自带 Python 3.6，而 OpenStack 较新的版本对 Python 版本、pip 源、系统库依赖都有比较明确的要求。如果你直接照着几年前的教程复制粘贴，大概率会在./stack.sh跑到一半的时候卡住，然后面对满屏红色报错不知道从哪下手。

这篇文章要解决的就是这个问题：在 Ubuntu 18.04 LTS 上，用 DevStack 把当前较新的 OpenStack 版本以单节点模式跑起来。我会把整个流程拆成环境准备、DevStack 配置、安装执行、常见报错处理、以及装完之后怎么验证和日常使用这几个部分。适合两类人看：一类是刚接触 OpenStack、想快速搭个环境做实验的；另一类是老手但换了系统版本，发现以前的经验不灵了，需要重新踩一遍坑的。

需要提前说明的是，单节点 All-in-One 模式对机器资源有硬性要求。我实测下来，4GB 内存是底线，但跑起来会非常卡，Horizon 打开一个页面要等好几秒；8GB 内存是比较舒服的起点，16GB 以上基本可以流畅做实验。CPU 核心数建议 4 核以上，磁盘至少留 50GB 给 DevStack 用，因为镜像、卷、日志加起来膨胀得很快。如果你是在虚拟机里装，记得把嵌套虚拟化打开，否则 Nova 起实例的时候会报 KVM 相关的错误。

2. 系统层面的准备工作：别急着 clone DevStack

2.1 换源与系统更新

Ubuntu 18.04 默认的软件源在国内访问速度很不稳定，装依赖的时候经常卡住或者超时。第一步先把 apt 源换成国内镜像。编辑/etc/apt/sources.list，把archive.ubuntu.com和security.ubuntu.com替换成你常用的镜像地址。换完之后执行：

sudo apt update sudo apt upgrade -y

这里有个细节：apt upgrade可能会升级内核，如果你是在虚拟机里跑，升级完建议重启一次，确保内核和驱动匹配。重启之后再继续后面的步骤，否则后面装 libvirt 相关包的时候可能出现版本冲突。

2.2 创建专用用户

DevStack 官方明确不建议用 root 直接跑，也不建议用你日常登录的账号跑，因为脚本会往家目录里写大量配置文件，还会改 sudo 权限。正确做法是创建一个独立的stack用户：

sudo useradd -s /bin/bash -d /opt/stack -m stack sudo passwd stack echo "stack ALL=(ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/stack sudo chmod 0440 /etc/sudoers.d/stack

这几条命令的意思是：建一个家目录在/opt/stack的用户，给它设置密码，然后配置免密 sudo。免密 sudo 是必须的，因为 DevStack 脚本里大量使用 sudo 执行命令，如果每次都要输密码，脚本会直接卡死。

注意：/etc/sudoers.d/stack这个文件的权限必须是 0440，否则 sudo 会拒绝加载，你会发现自己突然用不了 sudo 了。如果真遇到了，用 root 或者单用户模式改回来。

2.3 安装基础依赖

切换到 stack 用户，先装一批基础工具：

sudo apt install -y git curl python3-pip python3-dev \ build-essential libssl-dev libffi-dev python3-setuptools \ libxml2-dev libxslt1-dev zlib1g-dev libpq-dev \ bridge-utils cpu-checker

这里每一项都有用：build-essential和python3-dev是编译 Python C 扩展用的，libssl-dev和libffi-dev是 cryptography 库的依赖，libxml2-dev和libxslt1-dev是 lxml 的依赖，libpq-dev是 PostgreSQL 相关，bridge-utils是 Neutron 建网桥用的，cpu-checker用来验证 KVM 是否可用。

装完之后验证一下虚拟化支持：

kvm-ok

如果输出INFO: /dev/kvm exists和KVM acceleration can be used，说明没问题。如果提示 KVM 不可用，要么是 BIOS 里没开虚拟化，要么是虚拟机没开嵌套虚拟化，这个必须解决，否则后面起实例会失败。

2.4 Python 版本与 pip 源的处理

Ubuntu 18.04 自带 Python 3.6.9，这个版本对于较新的 OpenStack 来说偏旧，但 DevStack 本身会创建虚拟环境，所以系统 Python 只要够用就行。真正容易出问题的是 pip 源。默认的 PyPI 源在国内下载速度极慢，DevStack 安装过程中会 pip install 上百个包，用默认源可能要跑几个小时甚至超时失败。

配置 pip 全局源：

mkdir -p ~/.pip cat > ~/.pip/pip.conf <<EOF [global] index-url = https://pypi.tuna.tsinghua.edu.cn/simple trusted-host = pypi.tuna.tsinghua.edu.cn timeout = 120 EOF

这里把 timeout 设成 120 秒，是因为有些包体积较大，默认的 15 秒很容易超时。trusted-host 是因为用的是 http 源，不加这个 pip 会警告甚至拒绝。

3. DevStack 的获取与 local.conf 的关键配置

3.1 选择分支与克隆代码

DevStack 的 master 分支对应 OpenStack 的最新开发版本，稳定性一般，但功能最新。如果你想要相对稳定的版本，可以切换到对应的 stable 分支。我个人的建议是：做实验用 master，遇到问题好查；如果要长期跑，用最近的一个 stable 分支。

cd /opt/stack git clone https://opendev.org/openstack/devstack cd devstack git branch -a | head -20

克隆完之后先别急着跑，DevStack 的所有行为都由local.conf控制，这个文件不配好，后面全是坑。

3.2 local.conf 的最小可用配置

在 devstack 目录下创建local.conf，内容如下：

[[local|localrc]] ADMIN_PASSWORD=secret DATABASE_PASSWORD=$ADMIN_PASSWORD RABBIT_PASSWORD=$ADMIN_PASSWORD SERVICE_PASSWORD=$ADMIN_PASSWORD HOST_IP=192.168.1.100 LOGFILE=$DEST/logs/stack.sh.log LOGDAYS=2 ENABLED_SERVICES=key,rabbit,mysql,horizon,placement-api,nova-api,nova-conductor,nova-novncproxy,nova-scheduler,neutron-server,neutron-api,neutron-agent,glance-api,glance-registry,cinder-api,cinder-scheduler,cinder-volume disable_service n-net enable_service q-svc,q-agt,q-dhcp,q-l3,q-meta IMAGE_URLS="http://download.cirros-cloud.net/0.5.2/cirros-0.5.2-x86_64-disk.img"

逐项解释一下。ADMIN_PASSWORD是 Horizon 登录密码，也是各服务之间通信的密码，这里用变量引用简化配置。HOST_IP必须改成你机器的实际 IP，不能写 127.0.0.1，否则 Neutron 和 Nova 之间通信会出问题。LOGFILE和LOGDAYS控制日志，出问题的时候全靠这个日志排查。

ENABLED_SERVICES是核心，它决定了装哪些组件。这里我列的是比较完整的一套：Keystone 认证、RabbitMQ 消息队列、MySQL 数据库、Horizon 面板、Placement 资源调度、Nova 计算、Neutron 网络、Glance 镜像、Cinder 块存储。注意 Placement 在新版本里是独立服务，老教程里经常漏掉，漏了之后 Nova 起不来。

disable_service n-net和enable_service q-svc...是告诉 DevStack 用 Neutron 而不是老的 nova-network。虽然 nova-network 早就废弃了，但有些老配置模板里还留着，不显式禁用可能会冲突。

IMAGE_URLS是装完之后自动下载的测试镜像，cirros 很小，适合快速验证。如果你网络不好，可以先把镜像下载到本地，然后改成file:///path/to/image的形式。

3.3 几个容易忽略但很关键的配置项

除了上面这些，还有几个配置我强烈建议加上：

# 关闭不必要的服务，节省资源 disable_service tempest disable_service swift # 设置 Neutron 的网段，避免和你的局域网冲突 FLOATING_RANGE=192.168.100.0/24 PUBLIC_NETWORK_GATEWAY=192.168.100.1 Q_FLOATING_ALLOCATION_POOL=start=192.168.100.10,end=192.168.100.200 # 日志级别调成 DEBUG，方便排查 VERBOSE=True LOG_COLOR=False

FLOATING_RANGE这个特别重要。DevStack 默认用的浮动 IP 网段可能和你实际局域网重叠，一旦重叠，实例的网络就全乱了。我一般会选一个明显不会用的网段，比如 192.168.100.0/24。

VERBOSE=True会让日志输出更详细，虽然日志文件会变大，但排查问题的时候能救命。LOG_COLOR=False是因为有些终端对颜色转义支持不好，日志里全是乱码。

4. 执行安装：stack.sh 跑起来之后会发生什么

4.1 启动安装与预期时间

配置好之后，用 stack 用户执行：

cd /opt/stack/devstack ./stack.sh

这个过程视网络和机器性能，通常需要 20 到 40 分钟。它会依次做这些事：安装系统依赖包、创建 Python 虚拟环境、从 git 拉取各个 OpenStack 组件的代码、安装 Python 依赖、初始化数据库、配置各服务、启动服务、下载测试镜像。整个过程日志会同时输出到终端和stack.sh.log。

我建议用screen或者tmux跑，因为 SSH 一旦断开，脚本就中断了，而且中断之后重新跑不一定能续上，很多时候要./unstack.sh清理再重来。

screen -S devstack ./stack.sh # Ctrl+A D 脱离，回来用 screen -r devstack

4.2 安装过程中的典型报错与处理

报错一：pip 安装超时或 hash 校验失败

这个最常见，本质是网络问题。除了前面配的 pip 源，还可以在 local.conf 里加：

PIP_UPGRADE=True PIP_USE_WHEEL=True

如果还是失败，可以手动进虚拟环境装那个包，然后再重新跑 stack.sh。虚拟环境在/opt/stack/venv或者/usr/local/lib/python3.6/dist-packages下，具体看 DevStack 版本。

报错二：数据库连接失败

通常是 MySQL 没起来或者密码不对。检查/var/log/mysql/error.log，如果是权限问题，可能是 apparmor 拦了。临时禁用 apparmor 对 mysql 的限制：

sudo ln -s /etc/apparmor.d/usr.sbin.mysqld /etc/apparmor.d/disable/ sudo apparmor_parser -R /etc/apparmor.d/usr.sbin.mysqld

报错三：Neutron 网桥创建失败

报错信息里会出现bridge或者ovs关键字。先确认openvswitch服务状态：

sudo systemctl status openvswitch-switch

如果没起来，手动启动。另外检查/etc/network/interfaces里有没有把网卡配成静态 IP 又同时被 Neutron 接管，这种情况要先把网卡配置清理干净。

报错四：Nova 服务起不来，日志报 Placement API 连接失败

这就是前面说的 Placement 没装的问题。确认ENABLED_SERVICES里有placement-api，然后重新./unstack.sh && ./stack.sh。如果已经装了但还是报错，检查 Placement 的端口 8778 是否监听：

sudo netstat -tlnp | grep 8778

4.3 安装成功的标志

当终端出现类似下面的输出，就说明装完了：

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

这时候打开浏览器访问 Horizon 地址，用 admin / secret 登录，能看到面板就成功了一大半。

5. 装完之后的第一轮验证：别急着创建实例

5.1 用命令行验证各服务状态

Horizon 能打开不代表所有服务都正常。先用命令行过一遍：

source /opt/stack/devstack/openrc admin admin openstack service list openstack endpoint list openstack hypervisor list

service list应该能看到 keystone、nova、neutron、glance、cinder、placement 等。endpoint list每个服务应该有 public、internal、admin 三个 endpoint。hypervisor list应该能看到你的主机，状态是 up。

如果 hypervisor 状态是 down，检查 nova-compute 日志：

sudo journalctl -u devstack@nova-compute -n 50

常见原因是虚拟化支持没开，或者 nova 用户没有权限访问/dev/kvm。

5.2 网络连通性检查

Neutron 是单节点环境里最容易出问题的部分。先看网络和子网：

openstack network list openstack subnet list

DevStack 默认会创建一个 public 网络和一个 private 网络。如果没有，说明 Neutron 配置有问题。再检查 agent：

openstack network agent list

所有 agent 的 Alive 和 State 都应该是 True 和 UP。如果有 down 的，看对应的日志，通常在/var/log/neutron/下。

5.3 创建第一个实例的完整流程

验证通过后，走一遍创建实例的流程：

# 创建 flavor（如果默认的太小可以自己建） openstack flavor create --ram 512 --disk 1 --vcpus 1 m1.tiny # 查看镜像 openstack image list # 创建密钥对 openstack keypair create mykey > mykey.pem chmod 600 mykey.pem # 创建安全组规则，允许 ping 和 ssh openstack security group rule create --proto icmp default openstack security group rule create --proto tcp --dst-port 22 default # 创建实例 openstack server create --flavor m1.tiny --image cirros-0.5.2-x86_64-disk --key-name mykey --network private test-vm # 查看状态 openstack server list

等状态变成 ACTIVE 之后，绑定浮动 IP：

openstack floating ip create public openstack server add floating ip test-vm <floating-ip>

然后用 ssh 连上去：

ssh -i mykey.pem cirros@<floating-ip>

能进去就说明整个环境完全跑通了。

6. 日常使用与维护中的实操心得

6.1 重启之后环境怎么恢复

机器重启之后，DevStack 的服务不会自动全部起来。需要手动执行：

cd /opt/stack/devstack ./rejoin-stack.sh

如果这个脚本不存在或者报错，就重新./stack.sh，它会检测已安装的组件，只做增量启动，比从头装快很多。但要注意，如果之前是异常中断的，最好先./unstack.sh清理，再./stack.sh。

6.2 日志的查看姿势

DevStack 把每个服务都做成了 systemd 服务，命名格式是devstack@服务名。查看日志：

sudo journalctl -u devstack@nova-api -f sudo journalctl -u devstack@neutron-server -f

-f是实时跟踪，调试的时候很有用。另外stack.sh.log是安装过程的完整日志，出问题先看这个。

6.3 资源占用与性能调优

单节点跑全套服务，内存是最大的瓶颈。我实测 8GB 内存的机器，跑起来之后空闲状态就占了 5GB 左右。如果还要起实例，每个 cirros 实例至少再占 512MB。所以如果机器只有 8GB，建议在 local.conf 里禁用 Cinder 和 Swift，只保留核心的 Nova、Neutron、Glance、Keystone、Horizon。

另外 MySQL 的默认配置对单节点来说偏保守，可以适当调大：

# 在 local.conf 里加 MYSQL_MAX_CONNECTIONS=1000

6.4 几个我踩过的坑

第一个坑是时间同步。OpenStack 各服务之间对时间敏感，如果机器时间不准，Keystone 签发的 token 会立即过期，表现为登录之后马上又跳回登录页。装个 ntp 或者 chrony 同步一下时间就好。

第二个坑是/opt/stack目录空间。DevStack 会把所有代码、日志、虚拟环境都放这里，50GB 是起步，如果日志级别开 DEBUG，几天就能涨到几个 GB。定期清理/opt/stack/logs下的旧日志。

第三个坑是浮动 IP 网段冲突。前面提过，但真的很容易忘。装之前先用ip route看一下本机路由，确认FLOATING_RANGE选的网段不在现有路由表里。

第四个坑是 pip 缓存。DevStack 反复重装的时候，pip 缓存会越来越大，占满磁盘。可以在 local.conf 里加PIP_DOWNLOAD_CACHE=/opt/stack/pip-cache，然后定期清理这个目录。

7. 从单节点到多节点的扩展思路

单节点环境跑通之后，如果你想把计算节点分离出去，DevStack 也支持多节点部署。基本思路是：控制节点上跑 Keystone、Nova API、Neutron Server、Glance、Horizon，计算节点上只跑 nova-compute 和 neutron-agent。计算节点的 local.conf 里把HOST_IP改成自己的 IP，然后加上SERVICE_HOST指向控制节点，MYSQL_HOST、RABBIT_HOST、GLANCE_HOST也都指向控制节点。

不过多节点部署的复杂度比单节点高一个量级，网络配置、消息队列认证、数据库远程访问权限，每一项都可能卡住。我的建议是先把单节点玩熟，理解各组件之间的调用关系，再考虑扩展。单节点上遇到的所有报错，在多节点上都会以更复杂的形式重现，基础不牢的话会非常痛苦。

最后说一个实际体会：DevStack 装一次成功不代表每次都能成功，网络波动、源站更新、依赖版本变化都可能导致失败。所以装成功之后，如果环境还能用，尽量不要随便unstack重装。真要重装，先把local.conf备份好，把 pip 缓存和镜像文件保留下来，能省很多时间。