軽量デプロイ(SQLite)
Aivory のバックエンドは、起動時に環境変数によって自動的に選択されます。DATABASE_URL 以 postgres://まず、PostgreSQL(PostgreSQL)を使います。.dbファイルパス)は、組み込まれたSQLiteを使用します。REDIS_URL空白は、プロセス中にキャッシュ/コレクションを使用する。QDRANT_URL空はベクトル回収を無効にし、RAGは完全なコンテンツを注入するために戻ります。 バイナリの生産と開発は同じであり、SQLite ドライバーは鏡にコンパイルされています。
つまり、あなたは取ることができます。完全生産スタック5 サービスを 1 にカット: 走るだけappコンテナ、データは SQLite ファイルに収められています。このページでは、この展開方法が誰に適しているか、compose がどのように変更されたか、どのような制限があるか、そして後で Postgres に痛みなく移行する方法について説明します。
いつ SQLite モデルを選択するか
| シーン | 推奨 |
|---|---|
| 個人使用 / 試用評価 | コンテナを1分間引っ張る |
| 小型チーム(個数から数十人まで)、単機配備 | SQLite は通常十分です。 |
| リソース制限の小型VPS(1コア 1 GBレベル) | スカウト、完全に動かない。 |
| 複数のコピー/レベルの拡張が必要 | 必須 Postgres、SQLite は単入者 |
| 密集した書き込み(大量の並行会話、頻繁なナレッジベースの書き込み) | ポストグレース |
| 外部ツールが必要で、データベースを直接読み書きする | ポストグレース |
SQLite はハンマーではなく、バックアップ形式はエンジン中立で、その後、いつでもすべてのライブラリを Postgres に移行できます。以下)。
最小 compose ドキュメント
保留のみappサービス:削除postgres、redis、qdrant3 サービス及びその他depends_on持ってDATABASE_URLSQLite ファイルパスに変更し、および設定なし REDIS_URL 和 QDRANT_URL。
name: aivory
services:
app:
image: ghcr.io/${IMAGE_OWNER:-hjxwz123}/aivory-app:${IMAGE_TAG:-latest}
restart: unless-stopped
ports:
- "80:8787"
environment:
AIVORY_ENV: production
# SQLite:非 postgres:// 的值即选中内嵌 SQLite。
# 两个 pragma 分别开启 WAL 日志模式和 5 秒写锁等待。
DATABASE_URL: "/app/data/aivory.db?_pragma=journal_mode(WAL)&_pragma=busy_timeout(5000)"
# 不设置 REDIS_URL:使用进程内缓存/队列
# 不设置 QDRANT_URL:禁用向量检索,RAG 走全文注入回退
JWT_SECRET: ${JWT_SECRET:?set JWT_SECRET in .env}
# 试用时可置 true,启用内置演示模型,无需任何真实 API key
ENABLE_MOCK_PROVIDER: ${ENABLE_MOCK_PROVIDER:-false}
volumes:
# 一个目录装下所有持久化数据:aivory.db + uploads/ + artifacts/ + backups/
- ${DATA_DIR:-./data}:/app/data
付き添い.env必要なのは1本だけ:
# openssl rand -hex 32
JWT_SECRET=<至少 32 字符的强随机值>
スタートと検証:
docker compose up -d
curl -fsS http://localhost/api/health
最初に起動したとき、システムにはユーザーがなく、サイトを開いた後、最初に登録されたアカウントが自動的に管理者になります。初めての運用配置。
データベースファイルはなぜ /app/data に置かれているのか
映像内蔵のアップロードディレクトリ、製品ディレクトリ、バックアップディレクトリは/app/data下(UPLOAD_DIR=/app/data/uploads、ARTIFACT_DIR=/app/data/artifacts、BACKUP_DIR=/app/data/backupsSQLite ファイルも入力します。/app/data縛り付けが覆われている。全部持続的なデータ:
./data/ # 宿主机目录(DATA_DIR)
├── aivory.db # SQLite 主库
├── aivory.db-wal # WAL 日志(运行期存在,属于数据库的一部分)
├── aivory.db-shm # WAL 共享内存文件
├── uploads/ # 用户上传的文件
├── artifacts/ # 生成的产物
└── backups/ # 管理后台导出的备份归档
もしDATABASE_URL持ち込みボリュームの外側のコンテナ内のパスを指し、コンテナが再構築されると、データベース全体がなくなります。DATABASE_URL時刻の値は、./data/aivory.db?_pragma=journal_mode(WAL)&_pragma=busy_timeout(5000)(コンテナ内でのプロセスワークディレクトリ)/app/data/下)は、正確に貼り付けの点に落ちる;明示的に絶対的な道を書くのは、差別を排除するためである。
2 Pragma パラメーターの意味
| パラメータ | 值 | 役割 |
|---|---|---|
_pragma=journal_mode(WAL) | WAL | 前記日記モデル:読み書きは互いに矛盾せず、複数の読者が単一の著者と並行して読むことができる |
_pragma=busy_timeout(5000) | 5000 ms | 書き込みロックに遭遇すると、すぐに失敗するのではなく、最大5秒間間の間違ったメッセージを待つ |
この2つのパラメータは、サービス側のデフォルト構成であり、コピーできますが、削除は推奨されません。
Redis と Qdrant のコストを削減する
| 削除した部品 | 代替行動 | 実際の影響 |
|---|---|---|
postgres | 内蔵 SQLite | 単一書き込み者制限(以下のセクションを参照);機能の差異なし |
redis | プロセスにおけるキャッシュとコレクション | 単一インスタンスで機能が利用可能で、ストリーム回復など、Redisに依存する機能は有効でなく、キャッシュとストリーム制限数はプロセスが再起動するにつれてゼロになります。 |
qdrant | RAGの全文が返ってくる。 | ナレッジベースはまだ利用可能ですが、ベクトル類似度の検出ではなく、範囲内のドキュメントの全文をコンテンツに注入します。 |
選択型はそれぞれ独立しています: Postgres を SQLite に置き換えるだけで保存できます。redis 和 qdrantサービス(相応の保留)REDIS_URL / QDRANT_URL / QDRANT_API_KEY環境変数およびdepends_onナレッジベースは重度の使用シーンの場合、少なくともQdrantを保持することをお勧めします。
サンドボックスのコードは?
サンドボックス データベースの選択とは関係ありません。 コードを実行する機能が必要な場合は、完全なステックを設定します。sandboxコンポーネントのファイルに移行し、app2つの環境変数:
environment:
# ...上面的变量保持不变...
SANDBOX_BASE_URL: "http://sandbox:8000"
SANDBOX_API_KEY: ${SANDBOX_API_KEY:-aivory-bundled-sandbox}
サンドボックス サービスの完全な定義とセキュリティに関する注意事項 (Docker ソケットの持ち込み、ポートを公開しないなど)コード サンドボックス 展開コードを実行する必要がなく、他の機能は影響を受けません。
書き込み者の制限
SQLite は単一ファイルに組み込まれたデータベースで、WAL モードでは複数の読者とある作家同時に、これはいくつかの厳格な制約をもたらします:
- 1つしかありません。
appインスタンス* このデータベース ファイルを開きます。サービスを複数のコピーに拡張したり、同じデータ ディレクトリを 2 つのコンテナに貼り付けたり、アプリが実行されている間に他のツールでファイルを書き込まないでください。 - データベースファイルは、地元文書システム上に! 置かないで
DATA_DIRNFS または他のネットワーク ファイル システムに配置されたファイル ロックは信頼性の低いため、データベースの損傷を引き起こす可能性があります。 - 浸透には上限があります。
busy_timeout(5000)したがって、ピークの書き込み時には、書き込みのリクエストが5秒まで連続することを意味し、継続的な書き込み圧力の積み重ねがリクエストが遅くなり、あるいは時間が経過することを意味します。
JWT_SECRET は SQLite で同様に強制されます。
「軽量デプロイ」がこれを省くと思わないでください デプロイレベルのセキュリティー検査を実行するかどうかを判断するには、以下のとおりです。AIVORY_ENV開発価値がない場合、或 DATABASE_URLPostgres ですか? 上の最小 compose が設定されています。AIVORY_ENV: productionデータベースが SQLite であれば、JWT_SECRETまた、設定し、少なくとも32文字でなければ、アプリは起動を拒否します。
開発環境なしJWT_SECRETこの場合、アプリケーションは自動的に臨時鍵を生成します。すべてのログインセッションを再起動するたびにすべて無効それは、デプロイのオプションではなく、ローカル開発のための準備行為です。外部にサービスを提供するインスタンスは明示的に設定する必要があります。AIVORY_ENV: production強力な偶然JWT_SECRET。
バックアップ
SQLite モードの大きな利点は、バックアップ面が非常に小さいことです:すべての持続可能なデータがDATA_DIR1 カタログに。
- オプション: 管理コンソール 輸出Backup & Migration ページで生成された完全なバックアップ ZIP は、エンジン中立(manifest + テーブルごとに 1 つの JSONL + オプションファイル)で、「実行中のデータベース ファイルのコピー」の問題に影響されず、Postgres デプロイに直接インポートできます。
- 冷たい準備: まず
docker compose stopまた、コピー全体。DATA_DIRカテゴリ:注意aivory.db-wal和aivory.db-shmデータベースの一部であり、ノーアプリケーション内での拷問のみaivory.db単一のファイルでは、WALに統合されていない書き込みが失われ、拷問されたファイルも一致しない可能性があります。
入力するサイズの上限はMAX_BACKUP_BYTES制御(デフォルトは20 GiB)。
Postgres への移行
バックアップ形式はエンジン中立:SQLite バックアップは Postgres デプロイにインポートできますが、セクションと外部キーはインポートプロセスによって自動的に処理されます。典型的な「ビジネスが成長し、SQLite からフル スタックへ」プロセス:
- 古い例を出す: 管理コンソールの Backup & Migration で完全なバックアップを生成する (ファイルとベクトルを選択する場合)、ZIP をダウンロードします。
- 新たな例を引く: 按Docker Compose 生産展開初回スタート後、初回スタート後、旧インスタンス管理者と同じメールボックス最初のアカウントを登録します(それは管理者になります)。
- 導入: 新しいインスタンスの Backup & Migration ページで ZIP をインポートし、確認単語を入力します。
REPLACEインポートはライブラリ全体の置き換えです: 1 つのトランザクションですべてのテーブルを空にして再ロードし、ファイルとベクトルを復元し、現在のセッションが終了した後、バックアップ内のアカウントパスワードで再ログインする必要があります。 - ベータ処理: 古いインスタンスに Qdrant がない場合(このページの最小デプロイがない場合)、バックアップにベクトルデータが含まれていません。新しいインスタンスでは、データベースの既存の chunk テキストからベクトルメンテナンス機能の管理でベクトルを再構築できます。
インポートが完了すると「インポート操作を実行する管理者メールボックス」に加えて、バックアップに含まれる他の admin アカウントは、通常のユーザーに引き下げられます。新しい旧インスタンスの管理者メールボックスは同じで、インポート後に管理者としてのアイデンティティティは保持されます。
逆方向のプロセス(Postgres が SQLite に移行し、例えば小規模なデプロイをコンテナに縮小させる)はまったく同じですが、コストページに新しいインスタンスを交換するための最小の compose ファイルです。
完全なエクスポートオプション、非同期エクスポートタスク、設定エクスポートおよびインポートの詳細を参照バックアップと移行。