Ubuntu 版本与架构：部署前检查兼容性
选择 Ubuntu Linux VPS 镜像时，先根据应用支持范围确定系统版本和 CPU 架构，再下单。实例创建后，还要检查实际系统、候选软件包和应用行为，确保拿到的环境符合预期。
VPSuntu · 更新： · 约 6 分钟阅读
本页目录
先核对软件要求，再选镜像
列出应用及扩展支持的操作系统、运行时、数据库和架构，也别漏掉备份与监控代理。网站能打开，不代表所需恢复工具也能在该平台工作。注明哪些组合获得厂商支持，哪些只是团队自行测过。
- 整理应用支持的 Ubuntu 版本、运行时版本和数据库版本。
- 逐一检查原生扩展、容器镜像和备份代理需要的架构。
- 结合剩余维护期限，缩小可选系统版本。
- 确认服务商在所需地域提供目标 Ubuntu 镜像和架构。
- 创建后用下方命令检查实际系统，迁移数据或流量前先测试应用。
以 Ubuntu 24.04 LTS 为例：发布时默认提供 Python 3.12、PHP 8.3 和 PostgreSQL 16，补丁版本随更新变化。支持旧主要版本的软件不一定支持这些新版本。维护时间线见LTS 选择表；这里首先要确认整套软件是否匹配。
确认实例里装的是什么
在 VPS 内执行以下只读命令，查看发行版、运行中的内核、软件包架构和机器架构。安装其他软件前，把结果记入部署文档。
cat /etc/os-release
uname -r
dpkg --print-architecture
uname -m小屏幕上可左右滚动表格，查看完整内容。
| 输出项 | 含义 |
|---|---|
| /etc/os-release 中的 VERSION_ID | 安装的 Ubuntu 版本，例如 24.04 |
| uname -r 的内核字符串 | 当前运行内核，更新并重启后可能改变 |
| dpkg 的 amd64 与 uname 的 x86_64 | 64 位 x86 常见的软件包架构和机器架构名称 |
| dpkg 的 arm64 与 uname 的 aarch64 | 64 位 Arm 的常见名称 |
仅凭内核字符串无法判断 Ubuntu 发行版或支持范围，服务商可能使用云平台专用内核。不要假设只面向 amd64 的二进制程序可以在 arm64 原生运行；确定使用前，先找到 Arm 构建或明确支持的替代方案。
检查初始化是否完成
许多镜像通过 cloud-init 安装密钥、创建账号和配置网络。先确认它是否存在，再查询状态。没有 cloud-init 不一定是故障，需要弄清服务商如何初始化这款镜像。
if command -v cloud-init >/dev/null 2>&1; then
cloud-init status --long
else
printf '%s\n' 'cloud-init is not installed; check the provider provisioning method.'
firunning 表示初始化还在进行。即使 SSH 已能登录，error 或 degraded 也应排查。如果存在 cloud-init，再查看相关日志：
sudo tail -n 50 /var/log/cloud-init.log
sudo tail -n 50 /var/log/cloud-init-output.log初始化脚本可能输出敏感值，分享日志前先脱敏。不要为了消除报错而执行 cloud-init clean 或替换网络配置。初始化完成也不等于应用、数据库和备份任务都健康，这些仍需分别检查。
安装前查看候选软件包
先刷新软件包元数据，再查看准备使用组件的候选版本。update 更新的是索引，不会安装这些应用包。记录版本及其仓库来源。
sudo apt update
apt-cache policy python3 php postgresql
apt-cache policy python3.12 php8.3 postgresql-16Installed: (none) 表示尚未安装；候选版本为 (none) 则表示当前源没有提供这个包。先检查包名、架构和已启用的 Ubuntu 仓库组件，不要随意添加第三方源。
php、postgresql 等元包会选择默认实现，也应检查具体带版本号的软件包。已安装的软件要核对实际可执行文件或运行服务。python3 --version 和 php --version 显示对应执行文件的版本；数据库服务端与客户端工具的版本可能不同。
用一个例子判断兼容性
假设应用仅支持 Python 3.10，原生扩展也只提供 amd64 版本。这是假设条件，不是在描述某个实际产品。默认 Ubuntu 24.04 arm64 镜像有两项不匹配：Python 默认为 3.12，扩展也面向另一种架构。
换成 amd64 只能解决架构问题，默认 Python 仍然不变。虚拟环境使用创建它的解释器来隔离软件包，不能把 Python 3.12 变为 3.10。不要为满足应用要求而替换 Ubuntu 的系统 Python。
可以升级应用，或选择有明确维护计划的独立运行时／容器，同时确认所有原生组件支持目标平台。较旧 Ubuntu 也有自己的剩余维护期限，不一定能直接解决问题。
验收应在测试环境运行扩展的实际代码路径、数据库操作、后台任务以及一次备份／恢复流程，并记录版本和应用构建。安装完成或首页返回成功，覆盖面都不足以证明兼容性。
同时考虑容器和各层软件支持
容器可以隔离应用依赖与 Ubuntu 默认包，但仍依赖宿主机内核、存储和网络。确认镜像有适用于目标平台的受支持构建。模拟执行会改变性能和支持假设，不能悄悄代替原生构建。
把数据持久化到有明确说明的卷或外部存储，并练习脱离可丢弃容器进行恢复。固定版本或镜像摘要有助重现，但也要安排更新。长期固定一个有漏洞的镜像虽然可重现，却不代表维护到位。
Ubuntu 发行版支持与每个已安装包的支持范围不同。标准安全维护和 Ubuntu Pro 覆盖范围不同；第三方源、下载的二进制程序和容器镜像各有维护者。应记录每一层由谁更新，而不是认为 Ubuntu 版本支持能覆盖全部组件。
把日常更新与发行版升级分开
变更前检查待更新软件包和失败服务。先刷新包索引；以下命令仅列出信息，不执行发行版升级。
apt list --upgradable
systemctl --failed
if [ -f /var/run/reboot-required ]; then cat /var/run/reboot-required; fi选择合适维护窗口，审核并应用软件包更新，然后重新检查应用。维护期间服务可能重启。出现重启标记时应重视，但没有标记也不能证明所有组件都已更新。
在副本或新机器上测试发行版升级，重新核对运行时、仓库、数据库升级要求和扩展。安排最终数据同步及回退路径，把变更后的新写入也考虑进去。升级前的快照不会包含之后产生的客户订单。
留下可复现的部署记录
小屏幕上可左右滚动表格，查看完整内容。
| 记录类别 | 需要保存 |
|---|---|
| 操作系统 | 发行版、架构、内核和镜像标识 |
| 应用环境 | 构建、运行时、锁定文件及仓库来源 |
| 初始化 | 结果和不含机密的配置 |
| 验收 | 测试流程、结果及尚未解决的问题 |
| 维护 | 各软件包负责人、更新窗口和通知接收人 |
| 恢复 | 备份位置、操作步骤及最后验证恢复时间 |
机密应单独保存，非机密配置可纳入版本控制。重要依赖变更时，另建环境验证重建。公开云端实验可以使用免费 Ubuntu VPS 创建指南；确认镜像适用后，再按部署教程发布网站。
常见问题
Ubuntu 24.04 总是最合适的吗？
它是本文的具体示例。应选择应用整套依赖和服务商均支持的版本，再记录剩余维护期。较新与较旧系统都可能要求调整应用。
更换镜像会丢数据吗？
服务商的重装通常会替换系统磁盘。先查明流程，导出数据和配置并验证恢复。重装镜像与原地发行版升级是不同操作。