尧图网页设计 
Zulip 如何升级到新的正式发行版并确认升级过程正常【免费下载链接】zulipZulip server and web application. Open-source team chat that helps teams stay productive and focused.项目地址: https://gitcode.com/GitHub_Trending/zu/zulip本文面向自托管 Zulip 服务器的管理员任务是把一台已用发行版 tarball 方式安装的服务器升级到新的正式发行版release并在升级后确认服务确实恢复正常。适用前提是服务器由 Zulip 官方安装脚本安装而非 Docker 部署Docker 部署的 PostgreSQL 与服务升级走镜像更新流程需要查阅 Docker 升级文档本文命令不适用。整个流程的核心命令来自 升级文档验证方式参考 故障排查文档。前提条件服务器上已有一个可正常运行的 Zulip 发行版安装代码位于/home/zulip/deployments/目录下current是指向当前部署的软链接。升级脚本upgrade-zulip必须以 root 运行脚本本体 scripts/upgrade-zulip 开头会检查EUID非 root 直接报错退出并把全部输出记录到/var/log/zulip/upgrade.log。如果你改动过 Zulip 管理的系统配置文件例如 nginx 配置注意升级过程中的puppet apply会覆盖这些文件。可先用不带-f的测试运行查看将被修改的文件scripts/zulip-puppet-apply它会做一次 Puppet 测试运行并列出将要做的变更。把清单中你修改过的文件先备份升级后再恢复。第一步阅读升级说明并下载发行版升级前先阅读 changelog 的 upgrade notes 中当前版本到目标版本之间所有发行版的升级说明其中会标注那些耗时较长的数据库迁移帮助你预判停机时间。然后下载最新的正式发行版 tarball。下面的命令会获取zulip-server-latest.tar.gz即当前最新 release 的发行包curl -fLO https://download.zulip.com/server/zulip-server-latest.tar.gz如果你当前运行的版本较旧、且希望升级到某个特定正式版本而不是最新可从下载页获取对应版本的 tarball下载链接形式见 升级文档 给出的https://download.zulip.com/server/。第二步执行升级在服务器上以 root 身份运行/home/zulip/deployments/current/scripts/upgrade-zulip zulip-server-latest.tar.gz参数是 tarball 路径即上一步下载的文件。脚本会把 tarball 归档到/home/zulip/archives解包后在新版本目录下执行upgrade-zulip-stage-2完成后续工作见 scripts/lib/upgrade-zulip。升级过程会依次运行apt-get upgrade安装新版 Zulip 的依赖主要是 Python 包停止 Zulip 服务运行puppet apply执行数据库迁移以新版本启动 Zulip 服务。服务会有短暂停机除非涉及耗时较长的数据库迁移否则应在 30 秒以内这类迁移会在 release notes 中说明。如果停机对组织是问题文档建议先在 备份 上演练升级或选择低峰时段执行。脚本失败时会打印Zulip upgrade failed (exit code ...)并提示可重试无论成败完整输出都在/var/log/zulip/upgrade.log。可选替代路径从 Git 升级到正式版本如果你偏好直接按版本标签升级例如从 Git 仓库的11.5标签文档也提供了等价入口/home/zulip/deployments/current/scripts/upgrade-zulip-from-git 11.5其中11.5是示例中的正式发行版标签。除此之外该脚本还支持11.x维护分支、zulip-cloud-current和main等分支。相比 tarball 路径Git 路径额外会用webpack构建前端资源因此更耗内存见下文排查部分。除非你需要未发布的修改或维护 fork正式发行版升级用 tarball 路径即可。确认升级过程正常升级命令正常结束不等于验证完成。按以下顺序核对1. 打开服务器 URL确认界面可访问。文档对升级后验证的表述是You should now be able to navigate to the Zulip servers URL and confirm everything is working correctly. 即浏览器能打开登录/消息界面是文档给出的基本成功条件。2. 检查服务状态。运行supervisorctl status所有 Zulip 相关服务都应显示RUNNING。如果出现非RUNNING状态或某个服务的 uptime 小于 5 秒说明启动后立即崩溃并反复重启该服务就没跑起来。下面是 troubleshooting 文档 中给出的正常状态示例输出pid 和 uptime 数值仅为例示不是固定预期process-fts-updates RUNNING pid 11392, uptime 19:40:06 smokescreen RUNNING pid 3113, uptime 29 days, 21:58:32 zulip-django RUNNING pid 11441, uptime 19:39:57 zulip-tornado RUNNING pid 11397, uptime 19:40:03 zulip_deliver_scheduled_emails RUNNING pid 10289, uptime 19:41:04 zulip_deliver_scheduled_messages RUNNING pid 10294, uptime 19:41:02 zulip-workers:zulip_events_deferred_work RUNNING pid 10314, uptime 19:41:00如果有服务未正常运行而/var/log/zulip/errors.log里没有相关日志去/etc/supervisor/conf.d/zulip.conf中该服务的stdout_logfile对应日志查看——日志只有在服务完全启动后才会进入errors.log。3. 确认服务器版本。release-lifecycle 文档 说明Zulip 网页应用在齿轮gear菜单中显示当前服务器版本也可以通过 API 的 get-server-settings 接口获取。升级后在 gear 菜单里核对版本号是否已变为新发行版。4. 检查日志。升级脚本的全部输出在/var/log/zulip/upgrade.log服务端的 Internal Server Error 记录在/var/log/zulip/errors.log。一个正常运行的服务器不应持续产生新的错误如果升级后errors.log持续出现 traceback按 troubleshooting 文档 的思路处理先看/var/log/zulip/下对应服务的日志其中server.logDjango 和 Tornado 日志和workers.log队列 worker 日志是常用排查入口。失败处理重试与回滚重试。升级脚本是幂等的idempotent解决导致失败的问题后用同一条命令重跑即可没有副作用风险。文档列出的最常见失败原因网络问题服务器无法稳定访问 Internet或需要配置代理。修复网络后重试。内存不足尤其在upgrade-zulip-from-git路径下内存只有最低运行要求的机器可能在升级过程中 OOM一般是tools/webpack步骤失败。可以先以zulip用户运行./scripts/stop-server释放内存再执行升级。回滚。如果新版本无法正常工作可以在 升级文档的 rollback 一节 找到做法。Zulip 升级时会在/home/zulip/deployments/下创建完整的新部署目录并移动current、last、next三个软链接因此# 回滚到上一个部署例如 9.4 回 9.3 /home/zulip/deployments/last/scripts/restart-server # 回滚到更早的某个历史部署用部署目录名代替 DATE /home/zulip/deployments/DATE/scripts/restart-serverrestart-server会先停掉正在运行的 Zulip 服务再启动对应部署路径的版本。注意文档的边界说明这套回滚只适用于小版本之间的降级如果要降到更早的大版本必须先回滚数据库迁移是更复杂的过程。跨大版本后的收尾更新 settings.py/etc/zulip/settings.py不会在升级时被自动修改。跨大版本升级后该文件仍基于旧版本的模板可能缺少新设置项。文档建议在跨大版本升级后对照当前模板/home/zulip/deployments/current/zproject/prod_settings_template.py更新它cp -a /etc/zulip/settings.py ~/zulip-settings-backup.py cp -a /home/zulip/deployments/current/zproject/prod_settings_template.py /etc/zulip/settings-new.py然后打开两个文件把settings.py中已设置的每项配置逐一找到settings-new.py中对应位置并拷贝过去。可以借助下面的工具查看你的settings.py相对模板做了哪些修改/home/zulip/deployments/current/scripts/setup/compare-settings-to-template如果有设置在新模板中找不到查 changelog 确认它是否已被移除。确认无误后用新文件覆盖并重启这一步本身应是无变化的 no-op但立即重启能尽早发现问题cp -a /etc/zulip/settings-new.py /etc/zulip/settings.py su zulip -c /home/zulip/deployments/current/scripts/restart-server升级完成后的可选下一步Zulip 服务器升级完成后还可以考虑单独升级 PostgreSQL 大版本——它与 Zulip 服务器版本是分开管理的步骤见 升级文档的 Upgrading PostgreSQL 一节先升级 Zulip 到当前大版本的最新维护版、停服备份、以 root 运行upgrade-postgresql、再以zulip用户启动服务。是否执行取决于当前 PostgreSQL 版本与目标 Zulip 版本的 支持关系表。至此本次升级的核对闭环是upgrade-zulip无报错退出 → 浏览器可访问服务器 URL →supervisorctl status全部RUNNING→ gear 菜单显示新版本号。若任一步不满足回到/var/log/zulip/upgrade.log与/var/log/zulip/errors.log定位或按回滚一节切回旧部署。【免费下载链接】zulipZulip server and web application. Open-source team chat that helps teams stay productive and focused.项目地址: https://gitcode.com/GitHub_Trending/zu/zulip创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Zulip 如何升级到新的正式发行版并确认升级过程正常
Zulip 如何升级到新的正式发行版并确认升级过程正常【免费下载链接】zulipZulip server and web application. Open-source team chat that helps teams stay productive and focused.项目地址: https://gitcode.com/GitHub_Trending/zu/zulip本文面向自托管 Zulip 服务器的管理员任务是把一台已用发行版 tarball 方式安装的服务器升级到新的正式发行版release并在升级后确认服务确实恢复正常。适用前提是服务器由 Zulip 官方安装脚本安装而非 Docker 部署Docker 部署的 PostgreSQL 与服务升级走镜像更新流程需要查阅 Docker 升级文档本文命令不适用。整个流程的核心命令来自 升级文档验证方式参考 故障排查文档。前提条件服务器上已有一个可正常运行的 Zulip 发行版安装代码位于/home/zulip/deployments/目录下current是指向当前部署的软链接。升级脚本upgrade-zulip必须以 root 运行脚本本体 scripts/upgrade-zulip 开头会检查EUID非 root 直接报错退出并把全部输出记录到/var/log/zulip/upgrade.log。如果你改动过 Zulip 管理的系统配置文件例如 nginx 配置注意升级过程中的puppet apply会覆盖这些文件。可先用不带-f的测试运行查看将被修改的文件scripts/zulip-puppet-apply它会做一次 Puppet 测试运行并列出将要做的变更。把清单中你修改过的文件先备份升级后再恢复。第一步阅读升级说明并下载发行版升级前先阅读 changelog 的 upgrade notes 中当前版本到目标版本之间所有发行版的升级说明其中会标注那些耗时较长的数据库迁移帮助你预判停机时间。然后下载最新的正式发行版 tarball。下面的命令会获取zulip-server-latest.tar.gz即当前最新 release 的发行包curl -fLO https://download.zulip.com/server/zulip-server-latest.tar.gz如果你当前运行的版本较旧、且希望升级到某个特定正式版本而不是最新可从下载页获取对应版本的 tarball下载链接形式见 升级文档 给出的https://download.zulip.com/server/。第二步执行升级在服务器上以 root 身份运行/home/zulip/deployments/current/scripts/upgrade-zulip zulip-server-latest.tar.gz参数是 tarball 路径即上一步下载的文件。脚本会把 tarball 归档到/home/zulip/archives解包后在新版本目录下执行upgrade-zulip-stage-2完成后续工作见 scripts/lib/upgrade-zulip。升级过程会依次运行apt-get upgrade安装新版 Zulip 的依赖主要是 Python 包停止 Zulip 服务运行puppet apply执行数据库迁移以新版本启动 Zulip 服务。服务会有短暂停机除非涉及耗时较长的数据库迁移否则应在 30 秒以内这类迁移会在 release notes 中说明。如果停机对组织是问题文档建议先在 备份 上演练升级或选择低峰时段执行。脚本失败时会打印Zulip upgrade failed (exit code ...)并提示可重试无论成败完整输出都在/var/log/zulip/upgrade.log。可选替代路径从 Git 升级到正式版本如果你偏好直接按版本标签升级例如从 Git 仓库的11.5标签文档也提供了等价入口/home/zulip/deployments/current/scripts/upgrade-zulip-from-git 11.5其中11.5是示例中的正式发行版标签。除此之外该脚本还支持11.x维护分支、zulip-cloud-current和main等分支。相比 tarball 路径Git 路径额外会用webpack构建前端资源因此更耗内存见下文排查部分。除非你需要未发布的修改或维护 fork正式发行版升级用 tarball 路径即可。确认升级过程正常升级命令正常结束不等于验证完成。按以下顺序核对1. 打开服务器 URL确认界面可访问。文档对升级后验证的表述是You should now be able to navigate to the Zulip servers URL and confirm everything is working correctly. 即浏览器能打开登录/消息界面是文档给出的基本成功条件。2. 检查服务状态。运行supervisorctl status所有 Zulip 相关服务都应显示RUNNING。如果出现非RUNNING状态或某个服务的 uptime 小于 5 秒说明启动后立即崩溃并反复重启该服务就没跑起来。下面是 troubleshooting 文档 中给出的正常状态示例输出pid 和 uptime 数值仅为例示不是固定预期process-fts-updates RUNNING pid 11392, uptime 19:40:06 smokescreen RUNNING pid 3113, uptime 29 days, 21:58:32 zulip-django RUNNING pid 11441, uptime 19:39:57 zulip-tornado RUNNING pid 11397, uptime 19:40:03 zulip_deliver_scheduled_emails RUNNING pid 10289, uptime 19:41:04 zulip_deliver_scheduled_messages RUNNING pid 10294, uptime 19:41:02 zulip-workers:zulip_events_deferred_work RUNNING pid 10314, uptime 19:41:00如果有服务未正常运行而/var/log/zulip/errors.log里没有相关日志去/etc/supervisor/conf.d/zulip.conf中该服务的stdout_logfile对应日志查看——日志只有在服务完全启动后才会进入errors.log。3. 确认服务器版本。release-lifecycle 文档 说明Zulip 网页应用在齿轮gear菜单中显示当前服务器版本也可以通过 API 的 get-server-settings 接口获取。升级后在 gear 菜单里核对版本号是否已变为新发行版。4. 检查日志。升级脚本的全部输出在/var/log/zulip/upgrade.log服务端的 Internal Server Error 记录在/var/log/zulip/errors.log。一个正常运行的服务器不应持续产生新的错误如果升级后errors.log持续出现 traceback按 troubleshooting 文档 的思路处理先看/var/log/zulip/下对应服务的日志其中server.logDjango 和 Tornado 日志和workers.log队列 worker 日志是常用排查入口。失败处理重试与回滚重试。升级脚本是幂等的idempotent解决导致失败的问题后用同一条命令重跑即可没有副作用风险。文档列出的最常见失败原因网络问题服务器无法稳定访问 Internet或需要配置代理。修复网络后重试。内存不足尤其在upgrade-zulip-from-git路径下内存只有最低运行要求的机器可能在升级过程中 OOM一般是tools/webpack步骤失败。可以先以zulip用户运行./scripts/stop-server释放内存再执行升级。回滚。如果新版本无法正常工作可以在 升级文档的 rollback 一节 找到做法。Zulip 升级时会在/home/zulip/deployments/下创建完整的新部署目录并移动current、last、next三个软链接因此# 回滚到上一个部署例如 9.4 回 9.3 /home/zulip/deployments/last/scripts/restart-server # 回滚到更早的某个历史部署用部署目录名代替 DATE /home/zulip/deployments/DATE/scripts/restart-serverrestart-server会先停掉正在运行的 Zulip 服务再启动对应部署路径的版本。注意文档的边界说明这套回滚只适用于小版本之间的降级如果要降到更早的大版本必须先回滚数据库迁移是更复杂的过程。跨大版本后的收尾更新 settings.py/etc/zulip/settings.py不会在升级时被自动修改。跨大版本升级后该文件仍基于旧版本的模板可能缺少新设置项。文档建议在跨大版本升级后对照当前模板/home/zulip/deployments/current/zproject/prod_settings_template.py更新它cp -a /etc/zulip/settings.py ~/zulip-settings-backup.py cp -a /home/zulip/deployments/current/zproject/prod_settings_template.py /etc/zulip/settings-new.py然后打开两个文件把settings.py中已设置的每项配置逐一找到settings-new.py中对应位置并拷贝过去。可以借助下面的工具查看你的settings.py相对模板做了哪些修改/home/zulip/deployments/current/scripts/setup/compare-settings-to-template如果有设置在新模板中找不到查 changelog 确认它是否已被移除。确认无误后用新文件覆盖并重启这一步本身应是无变化的 no-op但立即重启能尽早发现问题cp -a /etc/zulip/settings-new.py /etc/zulip/settings.py su zulip -c /home/zulip/deployments/current/scripts/restart-server升级完成后的可选下一步Zulip 服务器升级完成后还可以考虑单独升级 PostgreSQL 大版本——它与 Zulip 服务器版本是分开管理的步骤见 升级文档的 Upgrading PostgreSQL 一节先升级 Zulip 到当前大版本的最新维护版、停服备份、以 root 运行upgrade-postgresql、再以zulip用户启动服务。是否执行取决于当前 PostgreSQL 版本与目标 Zulip 版本的 支持关系表。至此本次升级的核对闭环是upgrade-zulip无报错退出 → 浏览器可访问服务器 URL →supervisorctl status全部RUNNING→ gear 菜单显示新版本号。若任一步不满足回到/var/log/zulip/upgrade.log与/var/log/zulip/errors.log定位或按回滚一节切回旧部署。【免费下载链接】zulipZulip server and web application. Open-source team chat that helps teams stay productive and focused.项目地址: https://gitcode.com/GitHub_Trending/zu/zulip创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考