アップデート

セルフホスティングの Nodaro のアップデートとは、新しいアプリのイメージを取得して、アプリを再起動することです。同梱のスタックでは、新しいデータベースのマイグレーションが起動時に自動で適用されるため、ほかに実行するものはありません。メジャーバージョンの前には、リリースノートを読み、バックアップを取ってください。ダウングレードする方法がないためです。

イメージのタグ

main ブランチがビルドされるたびに、アプリのイメージ ghcr.io/nodaroai/nodaro-community が、latest タグと、そのコミットのタグで公開されます。リリースでは、さらに 3 つのバージョンタグが追加されます。

タグは、.env の NODARO_IMAGE で選びます。たとえば NODARO_IMAGE=ghcr.io/nodaroai/nodaro-community:v1.23.0 のように設定します。

環境をアップデートする

アプリだけをアップデートするには、次のコマンドを実行します。

docker compose -f docker-compose.community.yml pull nodaro
docker compose -f docker-compose.community.yml up -d nodaro

Compose ファイル、tools/ のスクリプト、同梱のサービスもアップデートするには、次のコマンドを実行します。

git pull
docker compose -f docker-compose.community.yml pull
docker compose -f docker-compose.community.yml up -d

Business エディションなどで、イメージをソースからビルドしている場合は、pull を build に置き換えてください。pull を使うと、公開されている Community エディションのイメージがダウンロードされてしまいます。

マイグレーションは、新しいテーブルや列の追加によって、前方互換性を保つようにしています。破壊的な変更がある場合は、リリースノートで告知します。慎重に運用する必要がある場合は、タグかコミットに固定してください。

メジャーバージョンの前に

メジャーバージョンでは、v1 から v2 のように、最初の数字が変わります。環境変数、Compose の構成、利用者が依存している可能性のある動作を変更できるのは、メジャーバージョンのリリースだけです。

1. GitHub でリリースノートを読みます。
2. tools/community-backup.sh でバックアップを取ります。バックアップと復元を参照してください。
3. アップデートしてから、/setup を確認します。すべてのカードが緑色になっているはずです。

ロールバックする

マイグレーションのロールバックはありません。データベースは前方にしか進みません。以前のバージョンに戻すには、次の手順を実行します。

1. アップデートの前に取ったバックアップを、tools/community-restore.sh <archive> で復元します。
2. 古いイメージに固定します。たとえば NODARO_IMAGE=ghcr.io/nodaroai/nodaro-community:v1.25.1 のように設定します。正確な vX.Y.Z タグは移動しません。
3. docker compose -f docker-compose.community.yml up -d nodaro で起動します。

マネージドの Supabase プロジェクトを使う場合

マイグレーションの自動実行がオフの場合は、新しいイメージで再起動する前に、supabase/migrations/ にある新しいファイルをファイル名の順に適用してください。適用されていないマイグレーションがあっても、通常 API は停止しませんが、そのマイグレーションを必要とする機能は、テーブルが作成されるまで 500 を返します。データベースを参照してください。

実行中のバージョン

実行中のバージョンは、アプリのサイドバーと /health に表示されます。バージョンをクリックすると、実行中のバージョンのリリースノートが表示されます。新しいリリースがある場合は、バージョンの横に赤い点が表示されます。このとき同じダイアログには、最新のリリースノートと、アップグレードに必要な正確なコマンドが、バックアップの手順を先頭にして表示されます。

更新チェックでは、GitHub API に 1 日 1 回、匿名のリクエストを送ります。チェックに失敗すると 5 分後に再試行し、その後は成功するまで、間隔を徐々に空けながら再試行します。

GitHub が許可する匿名リクエストは、送信元アドレスごとに 1 時間あたり 60 回です。専用のアドレスを持つ環境では、トークンは必要ありません。アドレスをほかと共有している環境では、この上限を他人に使い切られることがあります。その場合、バージョン表示は組み込みのバージョンに戻り、再試行が成功するまで、リリースノートは空のままになります。ログに [update-check] … read failed: HTTP 403 (rate limit: 0 of 60 left…) という行があれば、これが原因です。トークンは api.github.com にだけ送信され、ログに記録されることはありません。

Compose ファイルは、.env のこの 2 つの変数をコンテナに渡しません。nodaro サービスの environment: に追加してください。

  nodaro:
    environment:
      # ...the variables already listed...
      NODARO_UPDATE_CHECK: "off"

再起動すると反映されます。

GitHub Actions からサーバーをアップデートする

リポジトリには、SSH 経由で Nodaro のサーバーをアップデートするワークフローの例 examples/deploy-host.yml が含まれています。

1. 自分のリポジトリの .github/workflows/ にコピーします。
2. リポジトリのシークレット DEPLOY_HOST、DEPLOY_USER、DEPLOY_SSH_KEY を設定します。
3. スクリプト内のインストールディレクトリと Compose のコマンドを、サーバーに合わせて調整します。
4. Actions タブから手動で実行し、デプロイするイメージタグを選びます。

このワークフローは、サーバーに接続して docker compose pull と docker compose up -d を実行し、/health が応答するまで最大 90 秒待ってから、古いイメージのレイヤーを削除します。ブランチへのプッシュで、本番環境へのデプロイを開始しないでください。また、デプロイ先の環境ごとに、別のシークレット名を使ってください。