跳转到主要内容

更新与扩展

第二天的运营: 获取新的发布,并随着团队的成长给予 Kanera 更多的空间。

最新情况​

每个Kanera版本都是标记版本,如 v1.9.0 具有自己的 docker-compose.yml。更新意味着交换新版本的撰写文件并拉取其图像。您可以跳过版本：从 v1.9.0 直接升级到 v1.12.0 就可以了，因为每个待处理的数据库迁移在更新期间都会按顺序运行。

更新到最新版本​

从你的 kanera 服务器上没有找到该页面

docker compose exec -T postgres pg_dump -U kanera kanera | gzip > kanera-$(date +%F).sql.gz
cp docker-compose.yml docker-compose.previous.yml
curl -fsSLo docker-compose.yml https://github.com/happendev/Kanera/releases/latest/download/docker-compose.yml
docker compose pull
docker compose up -d
docker compose logs migrate

在运行之前，请阅读 发行说明 需要采取行动的更改,例如新设置或一次性重新连接,会在引入该更改的版本下面列出,因此从 v1.9.0 到 v1.12.0 的更改意味着要阅读 1.10.0、1.11.0 和 1.12.0 的说明。

要转移到特定版本而不是最新版本,请按标记下载其编写文件:

curl -fsSLo docker-compose.yml https://github.com/happendev/Kanera/releases/download/v1.9.0/docker-compose.yml

检查您正在运行哪个版本​

docker compose images api

该 TAG 例如,列显示发布 1.9.0。第一行 docker-compose.yml 太过分了。

更新前​

  • 备份数据库并上传。 该 pg_dump 数据库的使用 kanera_uploads 保留两者,再加上您的 .env，关闭服务器的主磁盘。参见 存储与备份.
  • 保留上一个编写文件。 该 cp 将其保存为 docker-compose.previous.yml，这就是您需要回滚的内容。
  • 保持您的更改不会被 docker-compose.yml. 将端口、额外网络或其他本地更改放入一个新的文件夹中。 docker-compose.override.yml 编写会自动合并它,更新时不会影响它。
  • 确保当前部署正常运行。 更新不应隐藏现有的数据库、存储或路由问题。

验证更新​

docker compose images api
docker compose ps --all
docker compose logs --tail=100 api worker public-api mcp
curl https://kanera.example.com/api/health

该 api 图像应该显示新版本,并且 migrate 应显示为退出,代码为 0。 还要检查公共 API 和 MCP 运行状况端点(如果您公开了它们 ), 然后登录,打开填充的看板,并创建和删除临时卡片。

如果更新失败​

  • 迁移未开始: 修复编写或环境错误并重新运行 docker compose up -d.
  • 迁移失败: 保留日志和备份,并且不要在不了解错误的情况下反复重新运行。 打开一个问题 与 migrate 日志。
  • 您需要返回: 较旧的版本不能在较新的版本迁移的数据库上运行。 Stop Kanera (docker compose down），恢复更新前的数据库并一起上传，把之前的compose文件放回去（mv docker-compose.previous.yml docker-compose.yml），然后运行 docker compose up -d.
  • 切勿在运行的更新版本上恢复备份。 在依赖之前,请先在单独的数据库或主机上测试恢复过程。

比例尺​

默认部署使用多个应用 API 副本和一个工作程序。

  • API_REPLICAS 控制应用 API 进程计数。 默认值为 2.
  • PUBLIC_API_REPLICAS 控制公共 API 进程计数。 默认值为 1.
  • MCP_REPLICAS 控制 MCP 进程计数。 1.
  • 保持 worker 确切地说 1.
  • 实时范围、存在和共享速率限制需要 Valkey。

只有在服务器具有足够的 CPU、内存和数据库连接容量时才能提升副本。 API_REPLICAS, 回顾 PG_POOL_MAX SQL 和 PostgreSQL 数据库 max_connections.

单个工作进程是故意的,它运行调度程序、通知和 webhook 交付以及清理作业,而第二个副本将重复而不是共享这些工作。 如果交付落后,请在考虑增加工作进程之前查看数据库和出站网络容量。