Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Docker Compose デプロイ完全ガイド ── 前提準備からサービス起動・検証・トラブルシューティングまで

Dify Enterprise を最も素早く体感できるのが Docker Compose によるデプロイです。本記事では、1 台のサーバーに Dify Enterprise の全サービスを立ち上げ、ブラウザからアクセスできるようになるまでの手順を、コマンドレベルで丁寧に解説します。

位置づけ: Docker Compose は PoC・検証・トレーニング用途に最適です。本番環境の高可用性構成には Helm Chart デプロイガイド を参照してください。


1. 前提条件

1.1 ハードウェア要件

項目最低スペック推奨スペック
CPU4 コア8 コア以上
メモリ16 GB32 GB 以上
ディスク50 GB SSD100 GB SSD 以上

ベクトルデータベースにデータを大量投入する場合、ディスクとメモリはさらに余裕を持たせてください。

1.2 ソフトウェア要件

ソフトウェアバージョン確認コマンド
Docker Engine24.0 以上docker version
Docker Compose (V2)2.23 以上docker compose version
Git任意git --version

Docker Compose V1(docker-compose コマンド)は非推奨です。V2(docker compose サブコマンド形式)を使用してください。

1.3 ネットワーク要件

  • Docker Hub またはプライベートレジストリへの Pull アクセス
  • 80 / 443 ポートの開放(nginx が Listen)
  • 社内プロキシ環境の場合は HTTP_PROXY / HTTPS_PROXY の設定
# Docker のバージョン確認
docker version --format '{{.Server.Version}}'

# Docker Compose V2 の確認
docker compose version

2. リポジトリのクローンとディレクトリ構成

2.1 ソースの取得

# Dify リポジトリをクローン
git clone https://github.com/langgenius/dify.git
cd dify/docker

Enterprise 版のプライベートリポジトリが提供されている場合は、そちらの URL に読み替えてください。

2.2 主要ディレクトリ構成

dify/docker/
├── docker-compose.yaml          # メインの Compose 定義
├── docker-compose.middleware.yaml # ミドルウェアのみの構成(開発用)
├── .env.example                 # 環境変数テンプレート
├── nginx/
│   ├── nginx.conf.template      # nginx 設定テンプレート
│   └── proxy.conf.template      # プロキシ設定テンプレート
├── volumes/                     # 永続化データの格納先
│   ├── db/                      # PostgreSQL データ
│   ├── redis/                   # Redis データ
│   └── weaviate/                # ベクトルデータベース
└── ssrf_proxy/
    └── squid.conf.template      # SSRF プロキシ設定

3. 環境変数の設定(.env)

3.1 テンプレートのコピー

cp .env.example .env

3.2 主要な設定項目

.env ファイルは Dify の動作を決定する最も重要な設定ファイルです。以下のカテゴリに分けて解説します。

サービス基本設定

# ── モード設定 ──
MODE=api      # api | worker(単独起動時に使用)

# ── シークレットキー ──
# 必ず変更してください。openssl rand -base64 42 などで生成
SECRET_KEY=sk-xxxxxxxxxxxxxxxxxxxx

# ── ログレベル ──
LOG_LEVEL=INFO    # DEBUG | INFO | WARNING | ERROR

データベース接続

# ── PostgreSQL ──
DB_USERNAME=postgres
DB_PASSWORD=difyai123456    # 必ず変更してください
DB_HOST=db
DB_PORT=5432
DB_DATABASE=dify

# 接続プール
SQLALCHEMY_POOL_SIZE=30
SQLALCHEMY_MAX_OVERFLOW=10

Redis 接続

# ── Redis ──
REDIS_HOST=redis
REDIS_PORT=6379
REDIS_PASSWORD=difyai123456    # 必ず変更してください
REDIS_DB=0

# Celery ブローカー(Worker が使用)
CELERY_BROKER_URL=redis://:difyai123456@redis:6379/1

ベクトルデータベース

# ── ベクトルストア ──
VECTOR_STORE=weaviate    # weaviate | qdrant | milvus | pgvector など

# Weaviate の場合
WEAVIATE_ENDPOINT=http://weaviate:8080
WEAVIATE_API_KEY=WVF5YThaHlkYwhGUSmCRgsX3tD5ngdN8pkih

ストレージ設定

# ── ファイルストレージ ──
STORAGE_TYPE=local             # local | s3 | azure-blob | google-storage
STORAGE_LOCAL_PATH=storage     # local の場合のパス

# S3 互換ストレージの場合
S3_ENDPOINT=https://s3.amazonaws.com
S3_BUCKET_NAME=dify-storage
S3_ACCESS_KEY=your-access-key
S3_SECRET_KEY=your-secret-key
S3_REGION=ap-northeast-1

nginx / 公開 URL

# ── nginx ──
NGINX_HTTPS_ENABLED=false
NGINX_PORT=80
NGINX_SSL_PORT=443

# ── サービスの公開 URL ──
# 外部からアクセスする際の URL(nginx 経由)
CONSOLE_WEB_URL=http://your-server-ip
CONSOLE_API_URL=http://your-server-ip
SERVICE_API_URL=http://your-server-ip
APP_WEB_URL=http://your-server-ip

3.3 セキュリティ上の注意

以下の値は 必ず デフォルトから変更してください。

項目理由
SECRET_KEYセッション署名・暗号化に使用
DB_PASSWORDPostgreSQL パスワード
REDIS_PASSWORDRedis パスワード
WEAVIATE_API_KEYベクトルデータベース認証
# シークレットキーの生成例
openssl rand -base64 42

4. docker-compose.yaml のサービス構成

4.1 アーキテクチャ全体像

graph TB
    Client[ブラウザ / API クライアント]
    Client --> nginx

    subgraph "Docker Compose ネットワーク"
        nginx[nginx<br/>リバースプロキシ<br/>:80 / :443]
        nginx --> web[web<br/>Next.js フロントエンド<br/>:3000]
        nginx --> api[api<br/>Flask API サーバー<br/>:5001]

        api --> db[(db_postgres<br/>PostgreSQL<br/>:5432)]
        api --> redis[(redis<br/>Redis<br/>:6379)]
        api --> weaviate[(weaviate<br/>ベクトル DB<br/>:8080)]
        api --> sandbox[sandbox<br/>コード実行<br/>:8194]
        api --> ssrf_proxy[ssrf_proxy<br/>Squid<br/>:3128]
        api --> plugin_daemon[plugin_daemon<br/>プラグイン実行]

        worker[worker<br/>Celery Worker]
        worker --> db
        worker --> redis
        worker --> weaviate

        worker_beat[worker_beat<br/>Celery Beat<br/>定期タスク]
        worker_beat --> redis
    end

4.2 各サービスの役割

コアサービス

サービス名役割ベースイメージ内部ポート
apiREST API を提供。LLM 呼び出し、ナレッジベース操作、ワークフロー実行などの中核処理langgenius/dify-api5001
workerCelery Worker。非同期タスク(ドキュメントインデックス作成、メール送信など)を処理langgenius/dify-api-
worker_beatCelery Beat。定期タスク(統計集計、クリーンアップなど)をスケジュールlanggenius/dify-api-
webNext.js ベースのフロントエンド UI。管理コンソールとアプリ画面を提供langgenius/dify-web3000
plugin_daemonプラグインの実行環境。ツールやモデルプロバイダのプラグインを管理langgenius/dify-plugin-daemon-

インフラサービス

サービス名役割ベースイメージ内部ポート
dbPostgreSQL。ユーザー、アプリ、会話履歴などの永続データを格納postgres:15-alpine5432
redisRedis。キャッシュ、Celery タスクキュー、セッション管理に使用redis:7-alpine6379
weaviateベクトルデータベース。ナレッジベースの Embedding インデックスを格納semitechnologies/weaviate8080
nginxリバースプロキシ。外部リクエストを web / api に振り分けnginx:latest80, 443
sandboxコード実行のサンドボックス環境。ワークフローのコードノードで使用langgenius/dify-sandbox8194
ssrf_proxySquid ベースのプロキシ。SSRF 攻撃を防止するネットワーク隔離ubuntu/squid:latest3128

4.3 サービス間の依存関係

docker-compose.yamldepends_on で定義される起動順序は以下の通りです。

db, redis ← api ← nginx
db, redis ← worker
redis     ← worker_beat
           ← web ← nginx
           ← sandbox ← api
           ← ssrf_proxy ← api
weaviate  ← api, worker

重要: depends_on はコンテナの起動順序のみを保証し、サービスの Ready 状態は保証しません。PostgreSQL や Redis が完全に起動する前に api が接続を試みる場合があるため、healthcheckcondition: service_healthy の組み合わせが推奨されます。


5. デプロイの実行

5.1 サービスの起動

# docker ディレクトリにいることを確認
cd dify/docker

# 全サービスをバックグラウンドで起動
docker compose up -d

初回起動時は Docker イメージの Pull に数分かかります。回線速度に応じて待機してください。

5.2 起動状態の確認

# 全コンテナの状態を確認
docker compose ps

# 期待される出力例
# NAME          STATUS       PORTS
# api           Up (healthy) 5001/tcp
# worker        Up           
# worker_beat   Up           
# web           Up           3000/tcp
# db            Up (healthy) 5432/tcp
# redis         Up (healthy) 6379/tcp
# weaviate      Up           8080/tcp
# nginx         Up           0.0.0.0:80->80/tcp
# sandbox       Up           8194/tcp
# ssrf_proxy    Up           3128/tcp
# plugin_daemon Up           

全コンテナが Up ステータスであることを確認してください。(healthy) が表示されるサービスは、ヘルスチェックまで完了していることを示します。

5.3 ログの確認

# 全サービスのログをリアルタイムで表示
docker compose logs -f

# 特定サービスのログのみ
docker compose logs -f api
docker compose logs -f worker

# 直近 100 行を表示
docker compose logs --tail 100 api

6. 動作検証

6.1 ブラウザからのアクセス

  1. ブラウザで http://<サーバーIP> にアクセス
  2. 初回はセットアップ画面が表示される
  3. 管理者アカウント(メールアドレス、パスワード)を登録
  4. ログイン後、ダッシュボードが表示されれば成功

6.2 API ヘルスチェック

# API サーバーの稼働確認
curl -s http://localhost/v1/health | python3 -m json.tool

# 期待される応答
# {
#     "status": "ok"
# }

6.3 各コンポーネントの接続確認

# PostgreSQL への接続確認
docker compose exec db psql -U postgres -d dify -c "SELECT version();"

# Redis への接続確認
docker compose exec redis redis-cli -a difyai123456 ping
# 期待される応答: PONG

# Weaviate の稼働確認
curl -s http://localhost:8080/v1/.well-known/ready

6.4 簡易テストシナリオ

デプロイが正常かどうかを包括的に確認するには、以下のシナリオを実行してください。

ステップ操作確認ポイント
1コンソールにログインUI が正常に表示される
2モデルプロバイダを設定API キーの保存が成功する
3チャットアプリを作成アプリ作成ダイアログが動作する
4チャットを送信LLM からの応答が返る
5ナレッジベースを作成しドキュメントをアップロードインデックス作成が開始される
6ナレッジベース付きチャットで質問RAG による回答が返る

7. よく使う運用コマンド

7.1 サービスの停止・再起動

# 全サービスを停止(データは保持)
docker compose stop

# 全サービスを停止し、コンテナとネットワークを削除(ボリュームは保持)
docker compose down

# 全サービスを停止し、ボリュームも削除(データ完全削除)
docker compose down -v

# 特定サービスの再起動
docker compose restart api
docker compose restart worker

7.2 アップデート

# 最新のソースを取得
git pull origin main

# 最新イメージの Pull と再起動
docker compose pull
docker compose up -d

# 特定サービスのみ更新
docker compose pull api web
docker compose up -d api web

7.3 リソース監視

# コンテナごとの CPU / メモリ使用率をリアルタイム表示
docker stats

# 特定コンテナのリソース確認
docker stats api worker db redis

8. トラブルシューティング

8.1 コンテナが起動しない

# コンテナの終了理由を確認
docker compose ps -a
docker compose logs <サービス名>

# よくある原因と対処
# 1. ポート競合 → 80 番ポートが別プロセスで使用中
sudo lsof -i :80

# 2. メモリ不足 → Docker Desktop のメモリ割り当てを確認
docker info | grep "Total Memory"

8.2 データベース接続エラー

# PostgreSQL のログを確認
docker compose logs db

# 接続テスト
docker compose exec api python -c "
import psycopg2
conn = psycopg2.connect(
    host='db', port=5432,
    user='postgres', password='difyai123456',
    dbname='dify'
)
print('Connection OK')
conn.close()
"

よくある原因:

  • .envDB_PASSWORD と実際の PostgreSQL パスワードが不一致
  • PostgreSQL の初期化が完了する前に api が起動した(→ docker compose restart api

8.3 Redis 接続エラー

# Redis のログを確認
docker compose logs redis

# Redis への直接接続テスト
docker compose exec redis redis-cli -a difyai123456 info server

8.4 nginx が 502 Bad Gateway を返す

# nginx のログを確認
docker compose logs nginx

# api / web コンテナが起動しているか確認
docker compose ps api web

# nginx の設定をテスト
docker compose exec nginx nginx -t

よくある原因:

  • api または web がまだ起動中(起動完了まで待機)
  • .envCONSOLE_API_URL 設定が不正

8.5 Worker がタスクを処理しない

# Worker のログを確認
docker compose logs worker worker_beat

# Redis のキュー状態を確認
docker compose exec redis redis-cli -a difyai123456 llen celery

よくある原因:

  • Redis への接続失敗
  • CELERY_BROKER_URL の設定ミス

8.6 ディスク容量の問題

# Docker が使用しているディスク容量を確認
docker system df

# 未使用のイメージ・コンテナ・ボリュームを削除
docker system prune -f

# 未使用ボリュームの削除(注意: データが失われる可能性あり)
docker volume prune -f

9. HTTPS の有効化

本番に近い検証環境では HTTPS を有効にすることを推奨します。

9.1 自己署名証明書の作成(検証用)

mkdir -p nginx/ssl

openssl req -x509 -nodes -days 365 \
  -newkey rsa:2048 \
  -keyout nginx/ssl/server.key \
  -out nginx/ssl/server.crt \
  -subj "/CN=dify.local"

9.2 .env の変更

NGINX_HTTPS_ENABLED=true
NGINX_PORT=80
NGINX_SSL_PORT=443

# URL も https に変更
CONSOLE_WEB_URL=https://dify.local
CONSOLE_API_URL=https://dify.local
SERVICE_API_URL=https://dify.local
APP_WEB_URL=https://dify.local

9.3 再起動

docker compose down
docker compose up -d

10. サービス障害の影響範囲

どのサービスが停止するとどの機能に影響が出るかを把握しておくことは、運用上非常に重要です。

停止サービス影響範囲
nginx全アクセス不可
apiAPI 呼び出し全般が不可。UI は表示されるがデータ取得不可
webフロントエンド UI が表示不可。API 直接呼び出しは可能
workerドキュメントインデックス作成、非同期処理が停止。チャット自体は動作する場合あり
worker_beat定期タスク(統計集計など)が実行されなくなる
dbほぼ全機能停止。ユーザー認証、アプリ設定、会話履歴の読み書きが不可
redisキャッシュ・キュー停止。API レスポンス遅延、Worker タスク処理停止
weaviateナレッジベース検索が不可。チャット自体は動作するが RAG が使えない
sandboxワークフローのコードノードが実行不可
plugin_daemonプラグイン(カスタムツール・モデルプロバイダ)が動作不可

11. 本番環境への移行に向けて

Docker Compose は検証・PoC に最適ですが、本番運用には以下の制約があります。

課題Docker Compose の限界本番推奨構成
高可用性単一ホスト障害で全停止Kubernetes + ReplicaSet
スケーリング手動スケールのみHPA (Horizontal Pod Autoscaler)
ローリングアップデートダウンタイムが発生Kubernetes Deployment
監視Docker stats のみPrometheus + Grafana
シークレット管理.env にプレーンテキストKubernetes Secret / Vault
バックアップ手動スクリプトVelero / マネージド DB

本番環境への移行は Helm Chart デプロイガイド を参照してください。


まとめ

本記事では、Dify Enterprise の Docker Compose デプロイについて、以下の流れで解説しました。

  1. 前提条件の確認 – ハードウェア・ソフトウェア要件のチェック
  2. リポジトリのクローン – ディレクトリ構成の把握
  3. 環境変数の設定.env ファイルの各項目の意味と推奨値
  4. サービス構成の理解 – 11 のサービスの役割と依存関係
  5. 起動と検証docker compose up -d から動作確認まで
  6. 運用コマンド – 停止・更新・監視の基本操作
  7. トラブルシューティング – 頻出問題とその解決手順

Docker Compose でシステム全体の構造を理解した上で、次のステップとして Helm Chart による Kubernetes デプロイに進むことを推奨します。


参考資料