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 DevStack2.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_PASSWORDsecret DATABASE_PASSWORD$ADMIN_PASSWORD RABBIT_PASSWORD$ADMIN_PASSWORD SERVICE_PASSWORD$ADMIN_PASSWORD HOST_IP192.168.1.100 LOGFILE$DEST/logs/stack.sh.log LOGDAYS2 ENABLED_SERVICESkey,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_URLShttp://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_RANGE192.168.100.0/24 PUBLIC_NETWORK_GATEWAY192.168.100.1 Q_FLOATING_ALLOCATION_POOLstart192.168.100.10,end192.168.100.200 # 日志级别调成 DEBUG方便排查 VERBOSETrue LOG_COLORFalseFLOATING_RANGE这个特别重要。DevStack 默认用的浮动 IP 网段可能和你实际局域网重叠一旦重叠实例的网络就全乱了。我一般会选一个明显不会用的网段比如 192.168.100.0/24。VERBOSETrue会让日志输出更详细虽然日志文件会变大但排查问题的时候能救命。LOG_COLORFalse是因为有些终端对颜色转义支持不好日志里全是乱码。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 # CtrlA D 脱离回来用 screen -r devstack4.2 安装过程中的典型报错与处理报错一pip 安装超时或 hash 校验失败这个最常见本质是网络问题。除了前面配的 pip 源还可以在 local.conf 里加PIP_UPGRADETrue PIP_USE_WHEELTrue如果还是失败可以手动进虚拟环境装那个包然后再重新跑 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 87784.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 listservice list应该能看到 keystone、nova、neutron、glance、cinder、placement 等。endpoint list每个服务应该有 public、internal、admin 三个 endpoint。hypervisor list应该能看到你的主机状态是 up。如果 hypervisor 状态是 down检查 nova-compute 日志sudo journalctl -u devstacknova-compute -n 50常见原因是虚拟化支持没开或者 nova 用户没有权限访问/dev/kvm。5.2 网络连通性检查Neutron 是单节点环境里最容易出问题的部分。先看网络和子网openstack network list openstack subnet listDevStack 默认会创建一个 public 网络和一个 private 网络。如果没有说明 Neutron 配置有问题。再检查 agentopenstack 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 之后绑定浮动 IPopenstack floating ip create public openstack server add floating ip test-vm floating-ip然后用 ssh 连上去ssh -i mykey.pem cirrosfloating-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 devstacknova-api -f sudo journalctl -u devstackneutron-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_CONNECTIONS10006.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 缓存和镜像文件保留下来能省很多时间。