简介面向需要快速搭建企业级 ERP 系统的开发与运维人员这是一份基于 VMware 虚拟机中 Ubuntu 22.04 环境、通过 Docker 部署 ERPNext 14 的完整操作指南。内容从 Git、Docker 与 Docker Compose 的安装入手包含依赖包安装、软件源与 GPG 密钥校验、用户组权限配置、docker-compose 版本检查并针对 Docker Hub 拉取失败给出 daemon.json 镜像加速器配置方案随后以汉化开箱即用镜像完成数据库创建与服务启动每一步都配有命令和验证方法。资源为 docx 格式共 1 个文件压缩包大小 321KB单篇步骤化部署笔记包含完整命令、配置示例与验证输出便于实训教学或企业内部搭建时直接参照。当前已有 628 人下载学习。通过学习可完整掌握从系统准备、镜像加速到 ERPNext 14 容器化运行的关键操作显著缩短部署时间容器化方式也方便后续按业务需求扩展组件并借助社区支持获得持续更新。1. 虚拟机里跑ERPNext14为什么这条路线最适合个人和企业内部部署先给结论在 VMware 虚拟机里装 Ubuntu 22.04再在 Ubuntu 上安装 ERPNext 14是我做过这么多企业内部系统部署里最省心、最不容易翻车的一条路径。ERPNext 是一套开源 ERP覆盖采购、销售、库存、会计、HR 等核心模块而 ERPNext14 是 Frappe 框架在 Python 3.10 / Node 14 生态下比较成熟的一个大版本既避开了 v15 之后对 Node 版本和依赖包的新要求也还没有 v16 那么多未稳定的新特性。对想低成本试水 ERP 的小团队或者只想在一台旧服务器上跑内部系统的个人用户来说虚拟机 Ubuntu 22.04 ERPNext14 这套组合能把环境隔离、快照回滚、备份迁移都一并解决掉比直接拿物理机裸装要稳得多。这篇文章不绕弯子直接从虚拟机参数怎么给、Ubuntu 22.04 装完要先调什么到 bench 命令怎么跑、站点怎么建再到我踩过的五个坑和最后的验收清单全部按可复现的步骤写。新手照着做能装通熟手也能从坑里省下半天时间。2. 准备虚拟机与 Ubuntu 22.04先把地基打牢2.1 虚拟机创建时的三处关键参数内存、磁盘与 CPU很多人装 ERPNext 失败不是 ERPNext 本身的问题而是虚拟机起步参数给得太小。ERPNext14 在编译前端资源时bench build 阶段非常吃内存官方建议生产环境 4GB 起步但虚拟机里如果只给 2GBbench 跑着跑着就会 OOM进程被内核直接杀掉。我一般会在 VMware Workstation 里这样分配参数这个思路也适用于 VirtualBox内存至少 4GB推荐 6GB。如果你的宿主机内存大于 16GB直接给 8GB后面跑 worker 进程和编译前端都会从容很多。磁盘至少 60GB推荐 100GB。不要只算 Ubuntu 系统占用的 15GBDocker 镜像、bench 的 env 目录、站点数据库、备份文件撑起来非常快磁盘满了以后 MariaDB 报错会让你很难排查。CPU至少 2 核推荐 4 核。bench install 阶段要编译 Python 依赖和 Node 前端核数多能明显缩短等待时间。虚拟机创建的时候记得选择「稍后安装操作系统」避免 VMware 自动用简易安装方式装出来的系统分区方案不合你的需求。磁盘控制器默认 NVMe 或 SCSI 都可以不影响 Ubuntu 22.04 的安装。创建完成后进虚拟机设置里把「显示」的 3D 加速关掉显卡内存给 128MB 就够。这不是装系统必需的步骤但 Ubuntu 22.04 默认桌面环境是 GNOME开着 3D 加速在虚拟机上容易出现花屏或黑屏进不去桌面的问题提前关掉能少折腾一次。2.2 安装 Ubuntu 22.04 并完成系统初始化换源、SSH 与快照Ubuntu 22.04 的镜像可以从官方源下载 ISO安装过程本身没什么特别要说的选「最小安装」即可不要选「第三方软件安装」那个选项会额外拉取闭源驱动和编解码器在虚拟机上纯属浪费时间。分区用默认的「使用整个磁盘」就行不需要手动做 LVM 或单独挂 /data除非你后续有特别的备份策略。系统装完以后第一件事不是装 ERPNext而是把系统源换成国内镜像源这能省下大量 apt 下载时间。顺手开启 SSH 服务这样你就能从宿主机用终端连进去操作比在虚拟机窗口里复制粘贴命令舒服很多。流程如下# 换源把 Ubuntu 官方源替换为清华镜像源 sudo sed -i s//.*archive.ubuntu.com//mirrors.tuna.tsinghua.edu.cng /etc/apt/sources.list sudo sed -i s//security.ubuntu.com//mirrors.tuna.tsinghua.edu.cng /etc/apt/sources.list sudo apt update sudo apt upgrade -y # 安装 openssh-server 并启动 sudo apt install -y openssh-server sudo systemctl enable --now ssh # 查看虚拟机 IP宿主机用 ssh 连接 ip addr show | grep inet这里换源的命令只替换了主机名前缀没有改动 sources.list 的文件结构。Ubuntu 22.04 之前的版本如果启用了 Ubuntu Pro 或 ESM 的话sources.list 里还会有esm.ubuntu.com这类源不过对全新安装的 22.04 LTS 来说不会遇到不用管。换源后执行 apt upgrade 时如果看到「daemon.json 被修改」的提示直接按 N 保留现有版本即可那是 Docker 相关提示现在还没装 Docker保留默认值就行。SSH 连通后我建议做一个快照。虚拟机的好处就在于做错了能回滚这个快照价值极高——如果后面 bench init 失败把系统环境搞乱了直接恢复到刚装完系统的快照重新来过比手动清理环境快得多。VMware 里右键虚拟机 - 快照 - 拍摄快照命名成 Ubuntu-22.04-base备注写「刚完成换源与SSH未安装任何开发依赖」。2.3 网络与存储的两个常见误配置及检查命令虚拟机的网络模式我强烈建议用 NAT 而不是桥接。桥接模式下虚拟机会占用局域网独立 IP如果宿主机所在网络有 MAC 绑定或 DHCP 地址池限制虚拟机可能会拿不到 IP或者 IP 经常变导致你 SSH 断连。NAT 模式下宿主机访问虚拟机用虚拟机自己的 IP 即可我们从宿主机 SSH 进去完全没有障碍。真正要注意的是虚拟机里的 apt 和 pip 是否放行NAT 模式默认没问题但如果装系统时选过「限制本地网络」之类的选项就要检查一下# 检查 DNS 解析是否正常 nslookup mirrors.tuna.tsinghua.edu.cn # 检查默认路由 ip route | grep default # 测试外部连通性 ping -c 3 baidu.comping baidu.com能通说明网络没问题。如果 ping IP 通但域名不通基本是 DNS 配置问题在 /etc/resolv.conf 或 netplan 配置里改成114.114.114.114就能解决。存储方面常见的坑是虚拟磁盘没有做 preallocated。如果你创建虚拟机时选了「将虚拟磁盘拆分成多个文件」那么虚拟机运行时磁盘性能会略差bench init 阶段大量小文件读写时会更明显。已经装好系统的话不需要为此重装影响不算大但如果是新建虚拟机建议选「立即分配所有磁盘空间」备份时也方便。另外一个容易忽略的是虚拟机的「磁盘空间」其实只代表虚拟磁盘上限Ubuntu 里的分区大小还要看 LVM 或普通分区是否自动扩展。装完后用df -h看一眼根分区容量如果只有 20GB 多而在 VMware 里明明给了 100GB说明分区没有对齐虚拟磁盘大小。这时用sudo lvextend -l 100%FREE /dev/ubuntu-vg/ubuntu-lv sudo resize2fs /dev/ubuntu-vg/ubuntu-lv扩容根分区。提示Ubuntu 22.04 默认安装会把剩余磁盘空间全部分配给根分区正常情况下无需手动扩容。只有使用旧版 Ubuntu 镜像或手动分区时才会遇到这个情况。3. 安装 ERPNext14 的完整路径bench init 到创建站点3.1 为什么选 ERPNext14 而不是 15/16版本与依赖定位先明确一个背景ERPNext14 对应的是 Frappe 框架 v14它在 2022 年发布是当时基于 Python 3.10 和 Node 14 的主力版本。到了 2024 年之后 ERPNext15 和 v16 陆续成为主线但它们对底层依赖的要求更激进——v15 需要 Python 3.11 以上且默认走 Docker 安装v16 直接不再支持 bench 方式裸装要求强制用 Docker 或 Kubernetes。这里不存在「哪个版本更高级」的问题只存在「哪个版本更适合虚拟机安装」。ERPNext14 是可以直接以源码方式跑在 Ubuntu 22.04 上的最后一个稳定主线版本它的依赖树和 22.04 的 apt 源比较匹配不需要额外折腾 Python 版本管理器。如果你的诉求是低成本快速上一个能用的 ERP而不是追新功能那么 v14 是最稳的选择。bench 是 Frappe 的命令行工具它负责创建虚拟环境、管理依赖、构建前端、配置 Nginx 和守护进程。装 ERPNext14 本质上就是装 bench然后通过 bench 创建站点和安装 ERPNext 应用。3.2 安装系统依赖与 Python 环境一段可复制的脚本在开始之前我惯例先做一遍系统依赖安装。ERPNext14 在 Ubuntu 22.04 上的系统依赖包括 git、curl、redis-server、mariadb-server、nginx、python3-pip 等其中 MariaDB 是 ERPNext 默认的数据库引擎Redis 用于缓存和队列。有一个细节需要注意Ubuntu 22.04 的 Python 默认是 3.10正好落在 Frappe v14 的支持区间内所以直接用系统自带的 Python 3.10 即可不需要装 pyenv 或手动编译。如果你手贱装了 Python 3.11 并把它设为默认反而可能遇到依赖包编译失败的问题。先安装基础依赖sudo apt install -y git curl redis-server mariadb-server nginx \ python3-pip python3-dev python3-venv python3-setuptools \ libffi-dev libssl-dev libjpeg-dev libpng-dev \ wkhtmltopdf xvfb # 配置 MariaDB注意这里要用交互方式设置 root 密码 sudo mariadb-secure-installationmariadb-secure-installation 过程中会问你 root 密码、是否移除匿名用户、是否禁止 root 远程登录等问题建议统一回答root 密码设一个强密码匿名用户移除root 远程登录禁止test 数据库移除。这步做完后需要手动编辑 MariaDB 配置文件加入 ERPNext 要求的字符集和排序规则sudo tee -a /etc/mysql/mariadb.conf.d/99-erpnext.cnf /dev/null EOF [mysqld] character-set-client-handshake FALSE character-set-server utf8mb4 collation-server utf8mb4_unicode_ci EOF sudo systemctl restart mariadbcharacter-set-server 和 collation-server 这两行不加的话后续创建站点时数据库默认字符集是 latin1表单里输入中文会出现乱码或者保存报错。这是很常见的一个坑很多人前面装得很顺到录第一张采购单的时候发现中文全变问号返回来看数据库字符集才发现问题。Python 侧需要把 pip 源也切换成清华镜像否则下载依赖包时会非常痛苦。同时升级 pip 和 setuptools避免部分老包在当前环境下安装失败pip3 install --upgrade pip setuptools pip3 config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple pip3 config set global.trusted-host pypi.tuna.tsinghua.edu.cn3.3 bench init 与创建新站点命令、参数与逐行说明系统依赖就绪后开始安装 bench。这里有一个版本问题bench 最新版默认是为 ERPNext15/16 设计的直接装最新 bench 再装 v14 会报依赖冲突。所以我用指定版本的方式安装# 用 pip 安装指定版本 benchv14 对应 5.x 系列 pip3 install frappe-bench5.22.1 # 初始化 bench 目录frappe-bench 会自动创建虚拟环境并拉取 frappe 框架 bench init --version v14.14.0 erpnext-benchbench init 过程中会依次做创建 virtualenv、安装 Python 依赖几百个包、克隆 frappe 框架代码、安装 Node 依赖、构建前端资源。这个过程耗时长取决于网速和机器性能一般要 15 到 30 分钟。期间如果看到某个 pip 包编译失败先别急着重跑整个命令看清报错的是哪个包通常是因为系统缺少某个库装上对应的 -dev 包后重试即可。注意 bench init 的--version参数指定的是 frappe 框架版本不是 ERPNext 应用版本。frappe v14.14.0 对应 ERPNext 14.x 系列的可用版本范围我通常用 frappe v14.14.0 配合 ERPNext 14.13.0这两个版本组合经过验证比较稳定。如果你指定了 frappe 版本且没有指定 ERPNext 版本后面 get-app 时会自动拉取对应主版本的 ERPNext。初始化完成后进入 bench 目录并创建站点。站点名建议直接用域名或项目名比如erp.example.com不要用 IP 地址。虽然 bench 支持 IP 作为站点名但后续配置域名时不方便cd erpnext-bench # 创建新站点--force 表示忽略已存在同名目录--mariadb-root-password 指向刚设置的 MariaDB root 密码 bench new-site erp.local.com --mariadb-root-password 你的数据库root密码 --admin-password admin初始密码 # 从官方仓库拉取 ERPNext 应用v14 分支 bench get-app erpnext --branch version-14 # 将 ERPNext 应用安装到站点 bench --site erp.local.com install-app erpnextnew-site 的参数里admin-password 是 ERPNext 系统管理员的初始密码登录后可以在系统设置里改掉。mariadb-root-password 对应的是你在 mariadb-secure-installation 里设置的 root 密码。install-app 执行完毕后站点数据库里会创建几百张表这个过程大概需要几分钟正常完成后会看到一长串表名输出。3.4 配置 gunicorn/nginx 与后台进程让 ERPNext 跑在浏览器里站点安装完成后ERPNext 实际上还没有对外提供服务。bench 默认的开发模式是bench start但那只是前台进程用于调试不合适。生产环境应该用 bench 自带的 production 配置# 生成 nginx 配置并启用后台服务 sudo bench setup production erp.local.com # 查看服务状态 sudo supervisorctl statussetup production 会做三件事第一为站点生成 nginx 配置文件并写入 /etc/nginx/conf.d 目录第二创建 supervisor 配置文件管理 gunicornWeb 进程、rq-worker后台队列进程和 schedule定时任务第三配置日志目录和缓存目录。执行完后应看到 supervisor 里至少有 frappe-web、frappe-worker-default、frappe-worker-long、frappe-worker-short、frappe-schedule 这几个进程处于 RUNNING 状态。如果执行 setup production 时提示 nginx 配置测试失败先跑sudo nginx -t看具体语法错误绝大多数情况是 80 端口被占或 /etc/nginx/sites-enabled/default 里的默认站点冲突。Ubuntu 上常见的处理办法是删掉默认站点再重试sudo rm /etc/nginx/sites-enabled/default sudo systemctl reload nginx浏览器里打开http://虚拟机IP如果能看到 ERPNext 的登录页面核心安装就算完成了。首次登录用你在 new-site 里设置的 admin 密码登录后系统会先让你确认企业名称和默认货币这里可以直接填中文因为前面 MariaDB 已经改成 utf8mb4不会出现乱码。提示VMware 虚拟机用 NAT 模式时宿主机浏览器访问虚拟机 IP 没问题如果想让局域网内其他机器也能访问虚拟机网络模式要改成桥接并且防火墙放行 80 端口。4. 避坑与常见问题排查虚拟机环境下最容易翻车的五个点4.1 内存不足导致编译中途被杀现象bench init 或 install-app 过程中终端最后几行输出是Killed或Segmentation fault没有其他报错。重跑教程里的恢复命令bench setup production时提示某个进程状态为 FATAL。原因虚拟机内存不满足编译 Node 前端资源的峰值要求。Node 在构建 JavaScript 资源时通常需要 3GB 以上的可用内存内存不足时 Linux 内核 OOM Killer 会直接杀掉 node 进程而且不留下像样的日志看起来像程序自己崩了。解决关掉虚拟机在 VMware 设置里把内存增加到 6GB 以上再开机重试。不用重装系统也不用清理已有文件直接重新执行bench initbench 遇到已存在的目录会提示是否覆盖选覆盖或删掉 erpnext-bench 目录重来。另外可以临时加 2GB swap 缓解峰值压力sudo fallocate -l 2G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile echo /swapfile none swap sw 0 0 | sudo tee -a /etc/fstab4.2 时区问题导致单据时间差 8 小时现象ERPNext 里录一张采购单保存后创建时间显示的比当前时间早 8 个小时。原因Ubuntu 22.04 虚拟机默认时区是 UTC而国内时间用 UTC8。ERPNext 存数据库时用的是 UTC 时间页面展示时按系统设置里的时区转换。如果虚拟机系统时区是 UTC而浏览器所在时区也是 UTC就会把 UTC 时间直接当作本地时间显示看起来少了 8 小时。解决把系统时区改为 Asia/Shanghai同时确认 ERPNext 系统设置里的时区参数一致。sudo timedatectl set-timezone Asia/Shanghai登录 ERPNext 后依次进入「设置 - 系统设置」把时区选成Asia/Shanghai并保存。改完以后新建单据验证一次如果不生效重启 supervisor 管理的 frappe-web 进程sudo supervisorctl restart frappe-web。4.3 Nginx 默认站点覆盖访问 IP 看不到登录页现象安装完成后访问虚拟机 IP显示的是 Nginx 欢迎页或 Ubuntu 默认页面不是 ERPNext 登录页面。检查 /etc/nginx/conf.d 里的 erpnext 配置存在但就是没生效。原因Ubuntu 22.04 的 nginx 安装后自带一个 default server监听 80 端口并指向 /var/www/html。ERPNext 生成的 nginx 配置文件也监听 80 端口根据 server_name 匹配路由。用 IP 访问时 nginx 找不到匹配的 server_name就回落到 default server展示默认页面。解决删掉默认站点后 reload nginx。sudo rm /etc/nginx/sites-enabled/default sudo nginx -t sudo systemctl reload nginx同时确认 bench 生成的配置里 listen 80 且 server_name 包含你的站点名。如果你访问的 URL 是http://IP而没有用站点名ERPNext 的 nginx 配置默认不会包含 IP 的 server_name此时要么在 /etc/hosts 里把域名指向虚拟机 IP 后用域名访问要么手动在 nginx 配置里加一行server_name _;让它成为默认站点。我一般推荐前者保持域名访问语义清晰。4.4 pip 下载超时或安装依赖包失败现象bench init 执行到安装 Python 依赖时卡住或报Read timed out、Connection reset by peer重试几次还是同样的位置失败。原因默认 pip 源访问速度太慢或连接不稳定。虽然 3.2 节已经推荐配置清华源但如果你在 bench init 之前没有执行 pip3 config setbench 创建的虚拟环境会使用默认源下载大包装时极易超时。解决在 bench 目录下对虚拟环境单独配置 pip 源或者直接重跑初始化。基准做法是在执行 bench init 前先跑一遍 pip config这样虚拟环境创建时会继承全局配置cd /tmp python3 -m venv /tmp/piptest /tmp/piptest/bin/pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple如果你已经装到一半失败了不必删掉整个 bench 目录进入 erpnext-bench 下的 env 虚拟环境里改 pip 源再重新执行 bench initcd erpnext-bench source env/bin/activate pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple再配一个超时时间避免再次卡死pip config set global.timeout 60。改完后重新跑 bench init注意如果刚才已经创建了 erpnext-bench 目录要先rm -rf erpnext-bench再 init否则 bench 会拒绝初始化到已有目录里。4.5 重启虚拟机后服务全部丢失现象虚拟机重启后浏览器访问 ERPNext 登录页面超时或连接拒绝sudo supervisorctl status显示没有任何进程在运行。原因bench setup production 配置的 supervisor 服务虽然写入了 /etc/supervisor/conf.d但 supervisor 本身没有设置开机自启或者系统启动时 supervisor 先于 MariaDB/Redis 启动失败。另外 Redis 服务也可能因为没启用 systemd 服务而在重启后处于停止状态。解决先确认并启用依赖服务的自启再看 supervisorsudo systemctl enable --now mariadb redis-server supervisor sudo supervisorctl reread sudo supervisorctl update sudo supervisorctl start all这三步分别做启用五个服务开机自启重新读取 supervisor 配置目录里的变化启动所有管理中的进程。之后重启虚拟机验证一次。sudo reboot重启后sudo supervisorctl status看到所有进程都是 RUNNING说明自启配置生效。如果某一个 worker 进程显示 FATAL用sudo tail -n 50 /var/log/erpnext/worker.error.log查看日志常见原因是 MariaDB 还没起来等几秒后sudo supervisorctl restart frappe-worker-default即可。5. 让 ERPNext14 在虚拟机里更好用备份、域名与性能调整5.1 定期备份的 bench 命令与恢复验证备份这一步再懒也不能跳过。ERPNext 数据量大SQL 文件可能上百 MB但虚拟机场景下备份成本极低。bench 自带备份命令可以同时导出数据库和文件cd erpnext-bench bench --site erp.local.com backup --with-files这个命令会在erpnext-bench/sites/erp.local.com/private/backups/下生成一个 SQL 文件和一个文件压缩包文件名带时间戳。加上--with-files会把私有文件目录附件、打印格式等一并打包恢复时才能真正还原。我习惯把备份目录挂到一个独立的虚拟磁盘或复制到宿主机共享目录防止虚拟机磁盘损坏时数据跟着陪葬。另外要设置 crontab 定期执行备份并且保留最近 7 天的备份具体做法是用crontab -e加一行0 2 * * * cd /home/ubuntu/erpnext-bench bench --site erp.local.com backup --with-files /var/log/erpnext-backup.log 21备份做完了至少要手动验证一次恢复。恢复命令是bench --site erp.local.com restore后面跟备份的 SQL 文件路径恢复前会先要求确认覆盖当前数据库。这一步真实做过的人不多等哪天真要用了才发现备份文件是坏的那就晚了。5.2 绑定域名与 HTTPS 的注意点如果这台虚拟机只在局域网内使用用 IP 访问完全没有问题。但如果要让同事通过域名访问或者以后要接入企业微信、钉钉之类的第三方应用就必须绑定正式域名并且启用 HTTPS。ERPNext 的 nginx 配置是基于站点名生成的所以站点名最好一开始就用你规划的域名避免后续改站点名。实现 HTTPS 的标准姿势先在 DNS 解析里把域名指向虚拟机 IP然后使用 certbot 申请证书sudo apt install -y certbot python3-certbot-nginx sudo certbot --nginx -d erp.example.comcertbot 会自动修改你的 nginx 配置加上 SSL 证书路径和 443 端口监听。注意一个坑申请证书时要求域名必须能从公网解析到这台虚拟机如果你只做了内网 DNSLet’s Encrypt 会验证失败。内网部署场景下要么用自签名证书自己信任要么用企业内部 CA不要死磕公网证书。自签名的方式是openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/erp.key -out /etc/ssl/certs/erp.crt然后把 nginx 配置里的证书路径指过去。5.3 调整 Worker 数与内存占用ERPNext 默认创建三个 worker 类型default、short、long分别处理不同的队列任务。默认配置下每个 worker 会起两个进程总共六个 RQ worker加上 gunicorn 默认的两个进程内存占用在 2GB 左右。虚拟机内存如果只有 4GB跑起来会比较紧张。worker 数量的调整在 bench 的 Procfile 里配置修改/home/ubuntu/erpnext-bench/Procfileweb: gunicorn -w 2 -b 0.0.0.0:8000 frappe.app:application worker_default: bench worker --queue default --worker-type default worker_short: bench worker --queue short --worker-type short worker_long: bench worker --queue long --worker-type longgunicorn 的-w参数控制 worker 进程数改成 1 可以省近 300MB 内存。worker_default 这个条目里的--worker-type default可以去掉只保留bench worker --queue default这样默认队列只会启一个进程。改完 Procfile 后执行sudo supervisorctl restart all生效。内存偏紧的场景下还可以把 Redis 的 maxmemory 限制往下调避免缓存把内存吃满。编辑/etc/redis/redis.conf找到maxmemory参数改成512mb然后sudo systemctl restart redis-server。这个参数对单站点小团队完全够用对多站点高并发不适用自己酌情取舍。提示改 Procfile 前先备份原文件改坏了可以恢复后再 restar。worker 数量调完建议观察一天的负载再决定要不要加回去不要一上来就盲目追求多进程虚拟机场景下内存比 CPU 更稀缺。5.4 虚拟机磁盘快照与系统升级的配合虚拟机最实用的功能就是快照。ERPNext 升级前、系统 apt 升级前、修改 nginx 或 supervisor 配置前都可以拍一个快照。VMware 里快照和备份是两个概念快照是虚拟机状态的瞬时记录备份是数据文件的可恢复副本两者配合使用才能做到进可攻退可守。我的习惯是重大操作前拍快照每天晚上用 crontab 做数据备份。快照不能替代备份因为快照依赖虚拟机的虚拟磁盘文件如果磁盘文件所在的宿主机存储坏了快照也没了。备份文件我会另外复制到宿主机另一个物理磁盘或者 NAS 上。这里提醒一句快照拍得太多且不清理会让虚拟磁盘文件越来越大VMware 里的虚拟磁盘从单个 60GB 膨胀到上百 GB 很常见。建议在正常稳定运行状态保留一个「干净快照」升级或改配置前拍「临时快照」操作成功后合并临时快照只留干净快照。6. 安装完成后的验收清单从登录到第一张采购单安装结束不等于交付我会按固定清单走一遍才宣布「能用」。这套清单的核心逻辑验证登录、验证文件上传、验证工作流通知、验证附件和打印格式、验证中文显示。任何一步出问题趁数据量小赶紧修比用了三个月再修代价小得多。6.1 用 site diagnose 做一次健康检查bench 自带诊断命令可以一次性输出站点相关的关键配置cd erpnext-bench bench --site erp.local.com diagnose看输出里的几项Site verbose 显示站点路径MariaDB 版本是否在支持范围内Redis 连接是否成功worker 是否在运行文件权限是否正常。诊断命令不会告诉你所有问题但能帮你发现最显眼的配置缺失。然后再手动检查两个地方一是登录页面的 favicon 和静态资源是否正常加载浏览器按 F12 看 Network 里有没有 404二是随便打开一个表单页面看右上角有没有 JS 报错。如果控制台出现红色的 500 错误大概率是 gunicorn worker 数量太少或内存不足看/var/log/erpnext/web.error.log。6.2 走一遍采购到付款的最小流程ERPNext 有几十个模块全测一遍不现实但核心链路必须通。我的习惯是从「采购 - 收货 - 付款」这条业务主链路测起因为这条链路涉及供应商主数据、采购订单、采购收货、付款申请、应付账款几乎把 ERP 里最常见的对象都覆盖了。建议流程先在「设置 - 公司」里确认企业名称和财务报表起始日期再在「采购 - 供应商」里新建一个测试供应商录一张采购订单添加物料行并保存提交这张采购订单做采购收货最后在会计模块里做应付付款。每个节点都正常流转、状态从「草稿」变「已提交」说明最核心的库存和财务状态机没问题。顺便验证通知和邮件在系统设置里配置企业邮箱提交采购订单后看系统是否能正常发送邮件通知。如果 SMTP 没配好也不影响使用只是提醒功能不可用加上mailing模块要稍微花点时间调所以通常放到第二个阶段再做。6.3 我个人的维护习惯与建议整套装通之后我一般会再花十分钟做三件事。第一把 admin 密码改成强密码并创建两个子用户一个管理员、一个普通业务员日常登录用业务员账号避免所有操作都在 admin 下。第二备份 Procfile 和 nginx 配置到/home/ubuntu/config-backup/以后升级或调整时能对照原配置。第三写一个简单的系统状态脚本放在 crontab 里定期检查 MariaDB、Redis、Gunicorn 的存活状态异常时往系统日志里写一条记录。不需要上监控软件虚拟机场景里一条systemctl is-active的 shell 脚本就够了。这半年里我前后在虚拟机里装过三套 ERPNext两套 v14、一套 v15。v15 在 Ubuntu 22.04 上也能装但依赖处理明显更费劲光 Python 3.11 的编译就折腾了一个下午。v14 的实际体验和功能完整度对于中小团队的内部管理够用也一直有安全更新短期内不会有「被迫升级」的紧迫压力。如果你正在虚拟机方案和 Docker 方案之间犹豫我的建议很直接个人试用或快速验证用 Docker想长期运营且需要自己改代码的地方更灵活就用这篇文章讲的 bench 源码方式。最后一条提醒也是我自己的教训虚拟机里装 ERPNext 不是装完就算结束数据库的定时备份、虚拟机的快照清理、系统日志的/var/log分区占用这三件事至少每隔一个月检查一次。ERP 这种系统平常感觉不到它的存在一旦数据丢了或者服务挂了才是真的麻烦。这篇文章能帮你把这套环境干净利落地搭起来后面的维护守住底线希望帮到你。本文还有配套的精品资源点击获取
