2026/10/12 1:18:26

Nexent Docker Compose 升级指南:从备份、在线/离线升级到健康检查的完整实战

Nexent Docker Compose 升级指南:从备份、在线/离线升级到健康检查的完整实战 AI AgentAI 应用后端前端大模型RAG【免费下载链接】nexentNexent is a zero-code platform for auto-generating production-grade AI agents using Harness Engineering principles — unified tools, skills, memory, and orchestration with built-in constraints, feedback loops, and control planes.项目地址https://gitcode.com/gh_mirrors/ne/nexent点击查看免费下载本指南面向使用 Docker Compose 部署 Nexent 的运维与开发人员系统讲解升级全流程升级前的数据一致性备份、在线fast-forward 拉取 脚本部署与离线离线包 --reuse-from复用配置两种升级路径以及升级后的容器健康状态核查。读完本文你将掌握 Nexent 官方推荐的先备份、再升级、后校验三步法并能对照源码理解备份脚本的空间检查、SQL 自动迁移的校验和机制与级联重放逻辑等底层实现具备独立完成一次生产级 Nexent Docker 升级的能力。1. 升级前的检查与备份1.1 适用范围与前置条件本指南适用于以 Docker Compose 方式部署的 Nexent 环境。升级应尽量安排在空闲或低流量窗口执行。最关键的一条纪律是备份开始前必须停止业务写入用户操作、API 请求、定时任务等但容器无需停止不要执行docker stop或docker compose down。⚠️ 如果复制期间业务仍在写入PostgreSQL、Elasticsearch、Redis、MinIO 等组件的数据可能不处于同一时间点备份可能无法恢复。1.2 执行备份命令在当前用于部署的 Nexent 仓库根目录下执行离线部署则在之前解压的部署包根目录下执行备份目录必须同时位于ROOT_DIR与NEXENT_USER_DIR之外bash deploy/docker/backup.sh --backup-dir /mnt/backup/nexent该脚本有两个可识别参数--backup-dir PATH必填备份所在目录与--help|-h。脚本不会检测写入活动也不会请求确认输入——停止业务写入完全依赖操作者的纪律。1.3 脚本执行流程与输出解读对照 deploy/docker/backup.sh 的源码其执行主线为parse_args → load_deployment_env → validate_backup_base → validate_docker → discover_volumes → validate_backup_layout_names → measure_sources → check_space → warn_writes_stopped → copy_files。关键行为如下读取部署环境脚本从deploy/env/.env读取ROOT_DIR若未显式设置NEXENT_USER_DIR则使用部署默认值${HOME}/nexent见load_deployment_env中的NEXENT_USER_DIR${NEXENT_USER_DIR:-$HOME/nexent}。两个目录都必须存在且可读。目录合法性校验备份目录若位于ROOT_DIR或NEXENT_USER_DIR内部或其子目录脚本直接报错退出validate_backup_base中的两条case分支。Docker 前置检查要求 Docker CLI 与 daemon 可用且nexent-config容器处于运行状态随后以nexent-config的镜像作为备份辅助镜像BACKUP_HELPER_IMAGE用于后续进入 named volume 进行 du/cp 操作。卷发现通过docker volume ls --filter labelcom.docker.compose.projectnexent与monitor收集命名卷并去重discover_volumes。名称冲突防护ROOT_DIR与NEXENT_USER_DIR的目录名备份后作为顶层目录名以及各命名卷的名称之间不得重名否则拒绝执行validate_backup_layout_names。空间预检脚本先打印ROOT_DIR、NEXENT_USER_DIR、本次部署使用的命名卷、未压缩数据总大小以及备份目录可用空间。文件不压缩因此校验按原始大小计算。只有打印出[PASS] Pre-upgrade space check passed.才会开始复制空间不足时打印[ERROR]并在复制前退出check_space中AVAILABLE_SIZE_KIB -lt TOTAL_SIZE_KIB即fail。复制过程中请关注[INFO]进度消息。备份目录命名为docker-UTC时间戳如docker-20261011-120000其顶层保留源名称两个主机路径使用各自目录名每个命名卷使用卷名。例如默认部署会产生nexent-data/来自ROOT_DIR目录名、nexent/来自NEXENT_USER_DIR、nexent-agent-workspace/、nexent_db-config/等目录。只有出现[PASS] Backup complete: path才表示备份完成path为实际备份目录若出现[ERROR]不要使用脚本打印出的不完整目录脚本在退出时也会提示Backup is incomplete. Inspect but do not use: partial-dir。1.4 备份脚本的工程约束源码佐证deploy/tests/test_docker_backup.sh 以伪docker/du/df命令覆盖了上述全部路径并明确断言脚本不得使用sudoassert_not_contains ... sudo 创建 tar/gz/zip 等压缩归档或 SHA-256 校验文件tar 、sha256断言停止容器或执行docker compose down断言 fake docker log 中不含stop与down提供写入确认交互--confirm-writes-stopped被判定为未知选项。测试同样验证了备份目录位于ROOT_DIR/NEXENT_USER_DIR内会被拒绝、源名称冲突会被拒绝、空间不足在复制前失败、复制失败不产生最终目录、未设置NEXENT_USER_DIR时回退到${HOME}/nexent。这些约束意味着备份是一个低成本、可重复、纯文件级的操作正式升级前可放心执行。2. 执行升级说明Nexent 的 Docker 升级入口统一为根目录deploy.sh首次安装与升级共用同一入口。仓库中的 deploy/docker/upgrade.sh 已标记为 deprecated 的兼容包装器仅转发到deploy/docker/deploy.sh升级请直接使用根入口。2.1 在线升级在可访问 GitHub 与所需镜像仓库的环境中从当前 Nexent 仓库执行在线升级。先确认当前分支与目标版本再以fast-forward only方式更新代码不要用未记录的latest值替代具体版本号git branch --show-current git pull --ff-only bash deploy.sh docker --defaults --version X.Y.Z各步骤要点git pull --ff-only保证只做快进合并避免出现未预料的合并提交bash deploy.sh docker是根入口内部转发到 deploy/docker/deploy.sh--version X.Y.Z显式指定应用版本否则脚本按 deploy/common/version.sh 的deployment_read_version自动探测优先VERSION文件首行其次backend/consts/const.py中的APP_VERSION最后回退为latest。当前仓库 VERSION 记录为v2.7.0--defaults复用已保存的部署配置并跳过交互界面。升级前务必确认deploy/docker/deploy.options存在且其中的组件、端口策略与镜像源与当前环境一致非敏感选择在部署成功后即写入该文件。在线部署的完整背景组件选择、端口策略、镜像源、HTTPS 等参见 Docker 安装与部署对应仓库路径 installation.md。2.2 离线升级当目标主机无法访问公共镜像仓库时按 Docker 离线部署 下载与服务器架构匹配的目标版本离线包拷贝到目标主机并解压到新目录unzip nexent-version-amd64.zip -d nexent-version cd nexent-version bash deploy.sh \ --reuse-from /path/to/previous/nexent \ --load-images \ --defaults \ docker关键语义/path/to/previous/nexent必须是之前解压部署包的真实根目录且其中包含deploy/env/.env--reuse-from复用旧包的.env、monitoring.env与 Docker 部署选项根入口 deploy.sh 的reuse_deployment_files会先校验源目录存在且与当前包目录不同、.env可读然后复制.env并依据当前包的deploy/env/.env.example自动补充新引入的变量deployment_merge_env_from_example随后按需复用deploy/env/monitoring.env与deploy/docker/deploy.options--load-images从新包./images目录加载镜像 tar 文件默认关闭离线升级必须显式开启ARM64 服务器使用对应的nexent-version-arm64.zip包。2.3 升级过程中的数据库迁移机制升级期间nexent-config容器会运行自动数据库迁移其余后端容器则等待迁移到达目标状态后才继续启动。这正是 deploy/common/run-sql-migrations.sh 的两种运行模式migrate模式nexent-config执行使用pg_advisory_lock加锁按版本感知文件名排序sort -V收集deploy/sql/migrations下所有*.sql逐条比对nexent.schema_migrations表中记录的校验和无记录则执行并记为applied校验和相同则跳过校验和不同则重放append_one_migration_sqlwait模式其余后端容器执行轮询比对期望的(migration_id, checksum)集合与表内实际记录全部匹配且状态为applied/baselined时返回readyrun_wait_mode超时默认 300 秒NEXENT_SQL_MIGRATION_WAIT_TIMEOUT_SECONDS。级联重放规则见 deploy/sql/migrations/README.md一旦某个文件因校验和变化被重放本次会话内其后的所有文件都会被强制重放——即使自身校验和未变。原因是链前部的破坏性语句如DROP COLUMN可能把 schema 回滚到后续文件所补偿的旧状态跳过会导致数据不一致。因此已合并的 SQL 文件v*.0_merged_migrations.sql等不得修改、重命名或删除。哪怕只改动注释也会触发级联导致其后所有文件在大型合并上被长时间重放。合并之后的新变更应使用新的独立版本化文件如v2.6.0_xxxx_*.sql。3. 升级后检查升级完成后分别检查 Nexent 与可选监控项目的容器健康状态docker ps -a --filter labelcom.docker.compose.projectnexent \ --format table {{.Names}}\t{{.Status}} docker ps -a --filter labelcom.docker.compose.projectmonitor \ --format table {{.Names}}\t{{.Status}}判定标准通过每个配置了 healthcheck 的容器均报告healthy等待仍有容器处于starting继续等待失败任一容器报告unhealthy。未配置 healthcheck 的容器不会报告healthy它们不在本检查范围内。以 deploy/docker/compose/docker-compose.yml 为例Elasticsearch 与 Redis 均配置了 healthcheck分别探测_cluster/health的green|yellow状态与redis-cli ping而部分服务可能不配置属正常现象。4. 升级前后的通用要点小结备份与升级分步确认以[PASS] Backup complete:与升级脚本正常退出为两段完成的标志备份目录命名含 UTC 时间戳便于多版本回滚追溯。版本语义显式指定X.Y.Z避免latest--defaults复用deploy/docker/deploy.options首次交互部署的组件/端口/镜像源选择都会保存在其中升级前应核对。迁移纪律不要在已部署后改动任何*_merged_migrations.sql新变更走新文件deploy/sql/init.sql每次启动都会无条件执行不参与级联其语句必须保持幂等。回滚依据备份保留了ROOT_DIR、NEXENT_USER_DIR与全部命名卷的原始目录/卷名结构若升级后健康检查不通过可直接用该备份目录对照恢复具体恢复流程建议结合部署拓扑在测试环境先行演练。以上流程与脚本行为均可在当前仓库的部署脚本deploy/docker/backup.sh、deploy.sh、deploy/docker/deploy.sh、迁移运行器deploy/common/run-sql-migrations.sh与测试用例deploy/tests/test_docker_backup.sh中得到验证可作为升级排障与二次开发时的权威参考。赞分享AI AgentAI 应用后端前端大模型RAG【免费下载链接】nexentNexent is a zero-code platform for auto-generating production-grade AI agents using Harness Engineering principles — unified tools, skills, memory, and orchestration with built-in constraints, feedback loops, and control planes.项目地址https://gitcode.com/gh_mirrors/ne/nexent点击查看免费下载相关推荐Nexent Kubernetes 升级指南备份、在线与离线升级、数据库迁移全流程Nexent Kubernetes 升级指南备份、在线与离线升级、数据库迁移全流程 本篇导读 本文是 Nexent 零代码 AI Agent 平台在 HelAI AgentAI 应用后端前端大模型RAGMission Control 实例运维指南健康检查、诊断、升级与备份的完整管理 API 实战Mission Control 实例运维指南健康检查、诊断、升级与备份的完整管理 API 实战 导读 Mission Control 是一个自托管的 AI ARook 集群升级前健康检查实战指南CephCluster 健康验证、状态解读与异常升级策略Rook 集群升级前健康检查实战指南CephCluster 健康验证、状态解读与异常升级策略 本文是 Rook 升级指南 https://link.gitco云原生存储容器编排运维上一篇Fireworq与Docker完美集成一键部署完整的作业队列生态系统下一篇ChestAgentBench全面解析2500个医疗查询基准测试的构建与应用创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考