Dify Ops Manual: Dockerデプロイメントからデータへの移行に関する実践ガイド

この記事では Docker 歌で応える Docker Compose オープンソースLLMアプリケーション開発プラットフォームの導入、更新、移行 Dify (v0.6.14).内容は、迅速なデプロイからデータのバックアップ、ソースコードからのイメージの構築まで、高度な操作をカバーしており、開発者やO&M担当者にわかりやすく実用的な操作ガイドを提供することを目的としています。

Docker ComposeによるDifyの迅速なデプロイメント

ほとんどのユーザーにとって、公式に提供されている Docker Compose ドキュメントの配備 Dify 最も手っ取り早く、最もお勧めの方法だ。

ステップ 1: Dify 配置ファイルの入手

まず Dify の公式リポジトリを取得する。 docker 配備カタログ。

ステップ2：環境変数の設定

Dify すべてのコンフィギュレーションは環境変数で管理される。デプロイメントの前に、コンフィギュレーション・テンプレート・ファイル .env.example リプリケート .env ドキュメントを作成し、実際のニーズに合わせて修正する。

# 进入 docker 部署目录
cd dify/docker
# 复制环境变量配置文件
cp .env.example .env

その後、テキストエディタで .env ファイルのコメントに従ってデータベース・パスワードを変更してください、SECRET_KEY といった主要なコンフィギュレーションがある。

ステップ3：サービスの開始

設定が完了したら、以下のコマンドを実行してバックグラウンドで起動する。 Dify すべてのサービスの

docker-compose up -d

このコマンドは自動的に必要な Docker イメージを作成し、すべてのコンテナを順番に起動する。

Difyサービスの更新

(落とす Dify 新バージョンのリリース時には、以下の手順でセキュリティアップデートを行うことができます。

1. 古い容器を止めて取り除く:

   cd dify/docker
   docker-compose down
   

2. バックアップデータ（重要）:
   アップデートを行う前にバックアップを取ることを強くお勧めします。 docker のカタログに掲載されている。 volumes サブディレクトリ。これがデータのセキュリティを確保する鍵である。
3. ドキュメントの新しいバージョンを取得する:
   最新バージョンの Dify ソースコードでは、新しい docker カタログは古いものに取って代わる。
4. 新しいバージョンの画像をインポートする:
   オフライン環境の場合は、事前に新しいバージョンの画像ファイルをインポートする必要があります。
5. 設定ファイルの更新:
   新旧比較 .env ファイルを使用して、カスタム設定を新しい .env ドキュメンテーション
6. 新バージョンのサービス開始:

   docker-compose up -d
   

データ移行とバックアップ

データ移行は、運用・保守の現場では一般的な要件である。Dify データの永続化は、ローカル・ディレクトリ・マッピングと Docker データボリュームに名前を付け、異なる方法で移行する。

ローカルにマッピングされたボリュームディレクトリの移行

Dify な docker-compose.yaml ドキュメントによると、「ローカル・ディレクトリ・マッピング」によってデータを永続化するサービスもある。これは、コンテナ内のディレクトリがホストの ./volumes カタログ

この方法での移行は非常に簡単で、基本的にはファイルのコピーである。

1. Difyサービス停止
   データの書き込み競合を防ぐため、ファイルを操作する前にすべてのコンテナを停止しなければならない。

   docker-compose down
   

2. パック・ボリューム・カタログ
   そうしれいかん volumes ディレクトリがzipファイルにまとめられている。

   tar -czvf dify-volumes.tar.gz ./volumes
   

3. 新しいサーバーで解凍する
   新しいサーバーの目的の場所にzipを転送したら、解凍する。

   tar -xzvf dify-volumes.tar.gz
   

Docker名前付きデータボリュームの移行

に関して PostgreSQL などの主要サービスを提供する。Dify 採用 Docker データは「名前付きデータボリューム」に永続化される。このようなボリュームは以下から構成される。 Docker 物理ファイルが /var/lib/docker/volumes/ ディレクトリに直接コピーするのは比較的面倒で、パーミッションの問題があるかもしれない。

には oradata 歌で応える dify_es01_data この2つのデータボリュームを例として、推奨される移行方法を以下に示す。

指示で展開された場合 docker-compose -p dify プロジェクト名を指定する。Docker ボリューム名にはプレフィックスが自動的に追加されます。 dify_oradata.

方法1：一時コンテナを使ったバックアップと復元（推奨）

この方法には root 許可され、ホスト上のボリュームの特定の物理パスを気にする必要はなく、安全で標準化されたプラクティスである。

1. バックアップ・データ・ボリューム
   一時的な alpine コンテナを作成し、バックアップするデータボリュームとローカルバックアップディレクトリの両方をマウントし、コンテナ内でpackコマンドを実行する。

   # 确保当前目录下有 backup 子目录
   mkdir -p backup
   # 备份 oradata 数据卷
   docker run --rm -v oradata:/source -v $(pwd)/backup:/backup alpine sh -c "cd /source && tar czf /backup/oradata.tar.gz ."
   # 备份 dify_es01_data 数据卷
   docker run --rm -v dify_es01_data:/source -v $(pwd)/backup:/backup alpine sh -c "cd /source && tar czf /backup/es_data.tar.gz ."
   

2. バックアップファイルの転送
   そうしれいかん backup ディレクトリの oradata.tar.gz 歌で応える es_data.tar.gz 新サーバーへのファイル転送。
3. 新しいサーバーでデータを復元する
   まず、新しいサーバー上に同じ名前のデータボリュームを作成し、同様の方法でそこにデータをリストアする。

   # 在新服务器上创建空的命名数据卷
   docker volume create oradata
   docker volume create dify_es01_data
   # 从备份文件恢复数据到 oradata 卷
   docker run --rm -v oradata:/target -v /path/to/backup:/backup alpine sh -c "cd /target && tar xzf /backup/oradata.tar.gz"
   # 从备份文件恢复数据到 dify_es01_data 卷
   docker run --rm -v dify_es01_data:/target -v /path/to/backup:/backup alpine sh -c "cd /target && tar xzf /backup/es_data.tar.gz"
   

方法2：ホストボリュームのディレクトリを直接操作する（root権限が必要）

を所有するサーバーが root パーミッションがあれば、ボリュームの物理ディレクトリを直接バックアップすることもできる。

1. ボリュームへの物理パスの検索

   docker volume inspect oradata dify_es01_data
   

   このコマンドはボリュームの Mountpointすなわち、物理的なストレージパスである。

2. ダイレクト・パッケージング

   # 获取路径并打包
   ORADATA_PATH=$(docker volume inspect -f '{{.Mountpoint}}' oradata)
   ES_DATA_PATH=$(docker volume inspect -f '{{.Mountpoint}}' dify_es01_data)
   sudo tar -czf oradata_backup.tar.gz -C $ORADATA_PATH .
   sudo tar -czf es_data_backup.tar.gz -C $ES_DATA_PATH .
   

高度な操作：ソースからのイメージの構築と管理

二次開発が必要な場合、セキュリティパッチを適用する場合、またはオフラインでデプロイする場合、ソースからの手動ビルドが必要です。 Dify な Docker ミラーリング。

APIとウェブミラーの構築

Dify コア・サービスは次のように分けられる。 api 歌で応える web 2つの部品を別々に作る必要がある。

1. APIイメージをビルドするdify/dify-api)

   cd api && docker build . -t dify/dify-api:0.6.14
   

2. ウェブ画像 (dify/dify-web)

   cd web && docker build . -t dify/dify-web:0.6.14
   

画像のエクスポートとインポート（オフライン環境用）

画像を作成したり取り出したりした後、その画像を .tar ファイルをインポートし、外部ネットワークにアクセスできないサーバーで使用する。

1. ミラーのエクスポート
   利用する docker save コマンドを使って、1つまたは複数のイメージをパッケージ化します。

   # 导出 Dify 核心镜像
   docker save -o dify_dify_api_0.6.14.tar dify/dify-api:0.6.14
   docker save -o dify_dify_web_0.6.14.tar dify/dify-web:0.6.14
   # 导出其它依赖镜像
   docker save -o postgres_15_alpine.tar postgres:15-alpine
   docker save -o redis_6_alpine.tar redis:6-alpine
   

2. 画像のインポート
   新しいサーバーでは docker load コマンドから .tar ファイルで画像をロードする。

   docker load -i dify_dify_api_0.6.14.tar
   docker load -i dify_dify_web_0.6.14.tar
   docker load -i postgres_15_alpine.tar
   docker load -i redis_6_alpine.tar
   

コア・コンセプトの分析

以下の重要な概念を理解することは、より良いメンテナンスと使用に役立ちます。 Dify.

docker とともに docker-legacy ディレクトリ

ある Dify ソースコードには2つのデプロイメント・ディレクトリがある。docker-legacy は古いデプロイ方法であり docker カタログは、現在推奨されている、より明確に構造化された配備オプションである。新規ユーザーは常に docker カタログ

SECRET_KEY 役割

ある dify-api サービス .env 設定ファイル。SECRET_KEY は重要なセキュリティ設定である。これは長いランダムな文字列で、ユーザーのセッションを暗号化して発行するために使用される。 cookieこれはセッションが改ざんされるのを防ぐためのものです。誰も推測できないような複雑な値に設定してください。

ビルド時に無視される storage ディレクトリ

Dify な Dockerfile 画像が構築されると、その画像は .dockerignore 文書が明示的に無視される storage カタログなぜなら storage ディレクトリは、テナントがアップロードしたファイル、キー・ペア、その他の機密情報や個人情報を保存するために使用されます。 Docker 代わりに、実行時にデータボリュームを介して動的にマウントされるべきです。

パース docker run --rm バックアップ・コマンド

データ移行セクションの推奨バックアップコマンドテンプレートには、各パラメーターに以下の意味があります：

docker run --rm -v <volume_to_backup>:/source -v <host_backup_dir>:/backup <image> sh -c "<commands>"