アプリを開発してテストしたら、Docker または PM2 で自社のサーバーの本番環境に独立してデプロイします。Docker はアプリをコンテナで動かします。PM2 は Node.js のプロセスを監視し、app-installer がインストールと更新を担います。
このセクションは、自社の NocoBase Core アプリが対象です。どちらのガイドも 製品カタログのサンプルアプリ を実例として使い、エージェントを使う場合 と エージェントを使わない場合 の手順を示します。
方法を選ぶ
| 方法 | 向いているケース | ガイド |
|---|---|---|
| Docker | コンテナを運用し、イメージと永続化用のマウントを管理している | Docker でデプロイする |
| PM2（app-installer） | Linux サーバーで Node.js のプロセスを動かし、app-installer でアーカイブのインストール、設定の管理、アプリの更新を行う | PM2（app-installer）でデプロイする |
すでにコンテナを運用しているなら Docker を、サーバー上で Node.js のプロセスを直接監視したいなら PM2（app-installer）を選びます。どちらの方法でも、本番用の設定、データベース、ファイルストレージを分けて使います。ビルドの前に、対象のプラットフォーム、データベース、ストレージの計画を決めておきます。前提条件は各ガイドに記載されています。
デプロイの準備をする
- ビルドできるソース：テストが通過し、依存関係とロックファイルが確定していて、ビルドの対象が実行環境と一致している。
- 特定された環境：サーバー、アプリのディレクトリ、ポート、アクセス URL、権限を確認する。ドメイン、HTTPS、リバースプロキシはその環境向けに設定する。
- 分離された実行時の設定：データベース、管理者、サービスの設定を準備する。生成されたシークレットを保持し、シークレットを含む設定はリポジトリに入れない。
- 永続データ：データベースとファイルストレージの場所を特定し、バックアップと復旧の手順を決める。
ビルドの出力には、ページ、API、マイグレーション、実行時の依存関係が含まれます。開発用のデータベース、アップロードされたファイル、実行時のシークレットは自動では含まれません。新しいデータベースではマイグレーションと必要なシードが実行されます。製品カタログのサンプルアプリはカタログのロールを初期化しますが、開発中の製品、ユーザー、ロールの割り当てはコピーしません。管理ページで作成したその他のロールや付与も、残す必要がある場合は別にデータ移行が必要です。
node dist/server/standalone.js を実行すれば、ビルドの成果物を確認できます。デプロイにはさらに、プロセスの監視、設定の管理、永続データの保存が必要です。
初回のデプロイと以降のリリース
| 初回のデプロイ | 以降のリリース |
|---|---|
| デプロイ先のディレクトリと本番用の実行時の設定を準備する | アプリとデプロイ先のディレクトリを再利用し、固定のシークレットを保持する |
| 新しいデータベースでマイグレーションと必要な初期化を実行するか、計画に沿って既存のデータを移行する | 既存のデータをバックアップし、新しいマイグレーションを確認して適用する |
| サインイン、業務の動作、権限、永続性を確認する | 新しい動作、残っているデータ、既存の権限をまとめて確認する |
以降の業務のリリースでは、ソースを変更し、テストし、ビルドし直して、元のデプロイ方法で更新します。各ガイドには「新しいリリースを公開する」のセクションがあります。2 つの更新方法の違いは アプリのリリースを公開する にまとめています。
フレームワークと関連する依存関係を更新するには、先に NocoBase Core をアップグレードする に従って互換性を確認してから、デプロイします。
確認と復旧
デプロイ後は、実際のアプリの URL、サインイン、主要な業務の読み書き、一般ユーザーの権限、再起動後の永続性を確認します。ビルド、アップロード、ヘルスチェックが成功しただけでは、これらの動作は証明されません。
公開の前に、以前のビルド、対応する設定、復元可能なデータベースとファイルのバックアップを保持しておきます。プログラムのコードをロールバックしても、マイグレーションや業務の書き込みは自動では元に戻りません。以前のランタイムが新しいスキーマを使えない場合は、互換性のあるデータを復元し、バックアップ以降の書き込みを考慮してください。更新と復旧の操作は、選んだ方法のガイドに従います。