メインコンテンツにスキップ

アップデートとスケーリング

2 日目の業務: 新しいリリースを取り込み、チームの成長に合わせて 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

実行する前に、以下をお読みください。 リリースノート 現在のバージョンと新しいバージョンの間のすべてのリリースに対して。新しい設定や 1 回限りの再接続など、アクションが必要な変更は、それを導入したリリースの下にリストされているため、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 その隣に。 Compose はそれを自動的にマージし、更新ではそのままにしておきます。
  • 現在の展開が正常であることを確認してください。 更新によって、既存のデータベース、ストレージ、またはルーティングの問題が隠れてはいけません。

アップデートを確認する​

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 ログ。
  • 戻る必要があります: 古いリリースは、新しいリリースが移行したデータベースに対して実行できません。Kaneraを止めろ（docker compose down)、更新前のデータベースとアップロードを復元し、以前の構成ファイルを戻します (mv docker-compose.previous.yml docker-compose.yml)、実行します docker compose up -d.
  • 実行中の新しいバージョンにバックアップを復元しないでください。復元手順を信頼する前に、別のデータベースまたはホストで復元手順をテストしてください。

スケーリングノート​

デフォルトのデプロイでは、複数のアプリ API レプリカと 1 つのワーカーが使用されます。

  • API_REPLICAS アプリの API プロセス数を制御します。デフォルトは 2.
  • PUBLIC_API_REPLICAS パブリック API プロセス数を制御します。デフォルトは 1.
  • MCP_REPLICAS MCP プロセス数を制御します。デフォルトは 1.
  • キープする worker まさに 1.
  • Valkey は、リアルタイムのファンアウト、プレゼンス、共有レート制限に必要です。

サーバーに十分な CPU、メモリ、およびデータベース接続容量がある場合にのみ、レプリカを起動します。上げるなら API_REPLICAS、レビュー PG_POOL_MAX およびPostgreSQL max_connections.

一人の労働者は意図的です。スケジューラー、通知と Webhook の配信、およびクリーンアップ ジョブを実行し、2 番目のコピーはその作業を共有するのではなく複製します。配信が遅れている場合は、ワーカー プロセスの追加を検討する前に、データベースと送信ネットワークの容量を確認してください。