この記事は、メイン記事『【構築】ConoHa VPSではじめるDifyコミュニティ版 導入・起動ガイド』の補足記事です。
Difyのコミュニティ版をConoHa VPSのようなサーバーにセットアップ（セルフホスト）する際、その起動には「Docker（ドッカー）」という技術が使われています。
この記事は、Difyの導入ガイドを読む上で前提知識となる「Dockerとは何か？」「なぜDifyの起動に必要なのか？」という基本概念から、インストール、主要なコマンドまでを初心者向けに解説します。
第一章：なぜ今、コンテナとDockerなのか？
コンテナとは？
コンテナとは、アプリケーションのコードと、その実行に必要なライブラリや設定ファイルといった「依存関係」をすべて一つにまとめた、軽量なパッケージです。
従来の開発では、開発者のPCでは動いたのに、本番サーバーに持っていくと動かない、といった「環境の違い」による問題が頻繁に発生していました。
コンテナは、この「環境」ごとアプリケーションを丸ごとパッケージ化します。これにより、「一度ビルドすれば、どこでも動く (Build once, Run anywhere)」という理想的な状態を実現します。
Dockerとは？
Dockerは、この「コンテナ」という技術を、誰でも簡単に利用できるようにしたツール（プラットフォーム）です。Difyのコミュニティ版は、Dockerの形式で配布されているため、Difyを起動するにはDockerの実行環境が必要となります。
コンテナ化の3つの大きなメリット
Difyのような複雑なアプリケーションがDocker（コンテナ）で配布されるのには、明確な理由があります。
- 環境の統一と再現性の確保（最大のメリット） Difyは、Webサーバー、APIサーバー、データベース、キャッシュサーバーなど、多くの部品（コンポーネント）が連携して動作します。これらを手動で一つずつインストールして設定するのは非常に複雑で、OSのバージョン違いなどで必ず失敗します。 Dockerを使えば、Difyが必要とする全ての環境が「コンテナ」としてパッケージ化されているため、開発者のPCでも、ConoHa VPS上でも、誰でも全く同じ環境を即座に再現できます。
- 開発サイクルの高速化 コンテナは数秒で起動・停止できます。設定を変更して試すプロセスが非常にスムーズになります。
- 運用管理の効率化 各コンポーネントが独立したコンテナとして動作するため、管理やアップデートが容易になります。
第二章：Dockerの基本コマンド（イメージとコンテナ）
Dockerを操る上で、絶対に避けて通れないのが「イメージ」と「コンテナ」という2つの概念です。
- Dockerイメージ (設計図) アプリケーションの実行に必要なすべて（コード、ライブラリ、設定）をパッケージ化した、読み取り専用のテンプレートです。車の「設計図」にあたります。Difyで言えば、「DifyのAPIサーバー」や「DifyのWebサーバー」の設計図がこれにあたります。
- Dockerコンテナ (実体) Dockerイメージ（設計図）から作成され、実際にアプリケーションが動作する実行可能なインスタンスです。「設計図」に基づいて組み立てられた、実際に動く「車」そのものです。
Docker コンテナ 構成
0.Docker Desktopのインストール
公式ドキュメントに従って簡単にインストールできます。
注意点: 企業でDocker Desktopを利用する場合、ライセンスが必要な場合があります。念のため、所属する組織のルールを確認してください。
-
動作確認
インストールが完了したら、以下のコマンドでDockerが正しく動いているか確認してみましょう。docker run hello-worldこのコマンドを実行して、ターミナルに「Hello from Docker!」と表示されれば成功です！
1. イメージを操るコマンド
コンテナを作成するためには、まず元となる「イメージ」が必要です。ほとんどの場合、Docker Hubという公式のレジストリから、他の開発者が公開しているイメージをダウンロードして利用します。
docker pull : イメージのダウンロード
docker pullコマンドは、リモートのリポジトリからイメージをローカルに取得するために使います。
# 例: nginx Webサーバーのイメージをダウンロード
docker pull nginx
# 特定のバージョンを指定してダウンロード
docker pull ubuntu:20.04
タグを指定しない場合は、デフォルトでlatestが適用されます。latestタグは便利なタグですが、その内容はプロジェクトの運用方針によって異なります。本番環境では、予期せぬ変更を避けるため、具体的なバージョンのタグを指定することが推奨されます。
docker images : ローカルイメージの一覧表示
ローカルに保存されているイメージの一覧を確認するには、docker imagesを使います。
docker images
このコマンドを実行すると、以下の情報が表示されます。
- REPOSITORY: イメージ名
- TAG: バージョン
- IMAGE ID: イメージを一意に識別するID
- CREATED: イメージが作成されてからの経過時間
- SIZE: イメージのサイズ
docker rmi : イメージの削除
不要になったイメージを削除するには、docker rmiを使います。
# イメージ名とタグで削除
docker rmi nginx:latest
2. コンテナを操るコマンド
イメージをダウンロードしたら、次はそれを基にコンテナを起動します。
docker run : コンテナの作成と起動
docker runは、Dockerコマンドの中で最も重要で、多機能なコマンドです。イメージを指定してコンテナを作成し、すぐに実行します。
# 例: バックグラウンドでnginxコンテナを起動し、ポートフォワードを設定
docker run -d --name my-nginx -p 8080:80 nginx
-d(--detach): コンテナをバックグラウンド（デタッチモード）で実行します。-p(--publish): ホストマシンとコンテナのポートをマッピングします。構文は「ホストポート:コンテナポート」です。上記の例では、ホストの8080番ポートへのアクセスを、コンテナの80番ポートに転送します。--name: コンテナにわかりやすい名前を付けます。
実際の開発でよく使う docker run オプション
- 環境変数の設定:
-eオプションで環境変数を渡します。docker run -e DB_HOST=db_server -e DB_USER=admin my-app - ボリュームマウント:
-vオプションでホストのディレクトリをコンテナにマウントします。docker run -v /Users/user/my-data:/app/data my-app - 作業ディレクトリの指定:
-wオプションでコンテナ内の作業ディレクトリを指定します。docker run -w /app ubuntu /bin/bash
docker ps : 実行中のコンテナ一覧表示
現在実行中のコンテナを確認するには、docker psを使います。
docker ps
-a(--all): 実行中かどうかにかかわらず、停止中のコンテナも含めてすべてのコンテナを表示します。
docker start / docker stop : コンテナの起動と停止
停止したコンテナを再起動するにはdocker startを、実行中のコンテナを停止するにはdocker stopを使います。
# 名前でコンテナを起動
docker start my-nginx
# 名前でコンテナを停止
docker stop my-nginx
docker rm : コンテナの削除
不要になったコンテナを削除するには、docker rmを使います。コンテナを削除する際は、先にdocker stopで停止させておくのが基本です。
３. 実行中のコンテナをデバッグするコマンド
docker runでコンテナを起動したら、そのコンテナ内でさらにコマンドを実行したい場合があります。
docker exec : 実行中のコンテナ内でコマンドを実行
docker runは新しいコンテナを作成して実行するのに対して、docker execは既存の実行中コンテナ内でコマンドを実行します。デバッグや設定確認の際によく使用されます。
# 例: 実行中のnginxコンテナでbashシェルを起動
docker exec -it my-nginx /bin/bash
このコマンドを実行すると、ターミナルがコンテナ内に切り替わり、直接操作できます。exitと入力して抜けても、コンテナ自体は停止しません。
docker logs : コンテナのログを見る
コンテナの標準出力（stdout）と標準エラー出力（stderr）のログを確認するには、docker logsを使います。
# 例: nginxコンテナのログを表示
docker logs my-nginx
# リアルタイムでログを追跡
docker logs -f my-nginx
第三章： HTTP/HTTPS 接続先ポート番号の変更
Difyのセットアップで最初に検討すべきことの一つがポート番号です。
なぜ変更するのか？
通常、DifyのコンテナはホストOS（ConoHa VPS）の 80番（HTTP用）と 443番（HTTPS用）ポートを使用しようとします。 しかし、VPSサーバーではこれらの「ウェルノウンポート」を、Difyとは別のWebサーバー（例：ApacheやNginx）が既に使用しているケースが非常に多いです。
ポートが競合すると、Difyは正常に起動できません。 そのため、競合を避けるためにDifyが使用するポート番号を、最初から別の番号に変更しておくことをお勧めします。
変更方法
設定は、dify/docker/ ディレクトリにある .env ファイル（.env.example からコピーして作成）を編集することで行います。
なお、詳細な設定方法については、『【補足３】Difyの高度なネットワーク設定ガイド (ポート変更・プロキシ対応・独自証明書)』を参考にして下さい。
第四章：Difyを構成するコンテナ群
実際の Docker は多数のコンテナから構成されています。
docker-compose.yamlというファイルから拾い上げたコンテナ一覧を列挙しておきます。
| 名称 | 説明 |
|---|---|
| api | DifyのバックエンドAPIサーバーです。ユーザーインターフェースからのリクエストを受け付け、ビジネスロジックを実行し、データベースや他のサービスと連携します。 |
| worker | バックグラウンドタスクを実行するワーカープロセスです。大規模なデータ処理、モデルのトレーニング、非同期処理などを担当します。APIサーバーからの指示を受けて動作します。 |
| web | DifyのフロントエンドWebアプリケーションを提供するサーバーです。ユーザーがDifyを操作するためのインターフェースを提供します。 |
| db | Difyが利用するデータベースサーバーです。アプリケーションの設定、ユーザー情報、会話履歴、データソース情報などを永続的に保存します。 |
| redis | インメモリのデータ構造ストアであり、キャッシュ、メッセージブローカー、セッション管理などに利用されます。Difyでは、APIサーバーとワーカー間の通信や、頻繁にアクセスされるデータの高速な読み書きなどに使用される可能性があります。 |
| sandbox | コードの実行環境を隔離するためのサンドボックス環境を提供するサービスです。ユーザーがアップロードしたコードや、Difyの機能内で動的に生成されたコードを安全に実行するために利用されます。 |
| plugin_daemon | Difyのプラグイン機能を管理するデーモンプロセスです。外部のサービスやツールと連携するためのプラグインのロード、アンロード、実行などを担当します。 |
| ssrf_proxy | Server-Side Request Forgery（SSRF）攻撃を防ぐためのプロキシサーバーです。Difyのバックエンドからの外部へのリクエストを仲介し、許可されたホストへのアクセスのみを許可することでセキュリティを強化します。 |
| certbot | SSL/TLS証明書を自動的に取得・更新するためのツールです。DifyのWebインターフェースやAPIエンドポイントへのHTTPSアクセスを有効にするために使用されます。 |
| nginx | 高性能なWebサーバーおよびリバースプロキシサーバーです。DifyのWebアプリケーションへのリクエストを処理したり、APIサーバーへのリクエストをルーティングしたり、SSL/TLS終端処理を行ったりします。 |
| weaviate | オープンソースのベクトル検索エンジンです。Difyのデータソースや埋め込み表現された情報を格納し、類似検索やセマンティック検索などの機能を提供するために利用される可能性があります。 |
| qdrant | オープンソースのベクトル類似性検索エンジンです。Weaviateと同様に、Difyのデータや埋め込みベクトルを格納し、高速な類似検索を実現するために利用される可能性があります。 |
| pgvector | PostgreSQLの拡張機能であり、ベクトル類似性検索を可能にします。DifyがPostgreSQLをデータベースとして利用している場合、この拡張機能を使ってベクトル検索機能を実現する可能性があります。 |
| pgvecto-rs | PostgreSQLのベクトル類似性検索を行うための別の拡張機能です（Rust実装）。pgvectorと同様の目的で使用される可能性があります。 |
| chroma | 埋め込みのためのオープンソースAIネイティブベクトルデータベースです。Difyのデータや埋め込みベクトルを格納し、簡単にベクトル検索機能を利用できるようにするために使用される可能性があります。 |
| oceanbase | アリババクラウドが提供する分散型リレーショナルデータベースです。Difyのデータベースとして利用される可能性があります。 |
| oracle | オラクル社が提供する商用リレーショナルデータベースです。Difyのデータベースとして利用される可能性があります。 |
| etcd | 分散型のキーバリューストアであり、設定情報やサービスのディスカバリーなどに利用されます。Difyの内部コンポーネントの設定管理や連携に利用される可能性があります。 |
| minio | Amazon S3互換のオブジェクトストレージサーバーです。Difyが扱うファイルやアセットなどの非構造化データを保存するために利用される可能性があります。 |
| milvus-standalone | オープンソースのベクトルデータベースです。大規模なベクトルデータの保存と高速な類似検索に特化しており、Difyの高度な検索機能やAI機能の実現に利用される可能性があります。 |
| opensearch | Apache Luceneをベースとしたオープンソースの検索・分析エンジンです。ログ分析、全文検索、データ可視化などの機能を提供し、Difyのログ収集や検索機能の基盤として利用される可能性があります。 |
| opensearch-dashboards | OpenSearchのデータを可視化するためのオープンソースのダッシュボードツールです。Difyのログやパフォーマンスデータなどを視覚的に分析するために利用される可能性があります。 |
| opengauss | Huaweiが開発したオープンソースのリレーショナルデータベースです。Difyのデータベースとして利用される可能性があります。 |
| myscale | MySQLをベースとしたオープンソースのデータベースです。Difyのデータベースとして利用される可能性があります。 |
| elasticsearch | 分散型の検索・分析エンジンです。OpenSearchと同様の目的で、Difyのログ収集、全文検索、データ分析などに利用される可能性があります。 |
| kibana | Elasticsearchのデータを可視化するためのオープンソースのダッシュボードツールです。Difyのログやパフォーマンスデータなどを視覚的に分析するために利用される可能性があります。 |
| unstructured | 非構造化データを構造化データに変換するためのツールやライブラリを提供するサービスである可能性があります。Difyが様々な形式のドキュメントやデータを処理する際に、前処理として利用されることが考えられます。 |
第五章：Dockerfile（イメージの設計図）の基本
1. Dockerfileの基本構成とビルド
Dockerfileは、通常、アプリケーションのソースコードと同じディレクトリに配置します。ファイル名はそのまま「Dockerfile」です。
my-app/
├── Dockerfile
├── .dockerignore
├── requirements.txt
├── app.py
└── static/
基本的なDockerfileは、主に以下の3つの要素で構成されます。
- ベースイメージの指定 (
FROM) - ファイルのコピー (
COPYやADD) - コマンドの実行 (
RUN,CMD,ENTRYPOINT)
これらの命令を組み合わせることで、アプリケーションの実行環境をゼロから構築できます。
docker pull は他人が作ったイメージを使う方法でしたが、「Dockerfile」は自分だけのオリジナルイメージを作成するための「設計図（レシピ）」ファイルです。
DifyのセットアップではDockerfileを自分で書く必要はありませんが、Difyのソースコード内にはこのDockerfileが含まれており、docker compose は内部的にこれを使ってイメージをビルド（構築）しています。
# Dockerfileの簡単な例 (Pythonアプリの場合)
# 1. ベースとなるイメージを指定
FROM python:3.9-slim
# 2. 作業ディレクトリを指定
WORKDIR /app
# 3. 必要なファイルをコピー
COPY requirements.txt .
# 4. コマンドを実行（ライブラリのインストール）
RUN pip install -r requirements.txt
# 5. 残りのコードをコピー
COPY . .
# 6. このコンテナが起動した時に実行されるコマンド
CMD ["python", "app.py"]
- マルチステージビルド: ビルドに必要な環境（
builder）と、実行に必要な環境（runner）を分けることで、最終的なイメージサイズを劇的に小さくする高度なテクニックもあります。
ビルドと .dockerignore
Dockerfileが完成したら、docker build コマンドでイメージをビルド（構築）します。
ビルド時に不要なファイル（.gitやnode_modulesなど）をDockerfileと同じ階層に置くことで、ビルドを高速化できます。
# -t はイメージに名前を付けるオプション。「.」はDockerfileがある場所（カレントディレクトリ）を示す
docker build -t my-python-app:1.0 .
ビルド時には、.dockerignore ファイル（.gitignore と同様）を作成し、.git や node_modules など、イメージに含めたくないファイルを指定することで、ビルドの高速化とイメージの軽量化が図れます。
.dockerignoreファイルの活用
.dockerignoreファイルは、ビルドコンテキストから除外したいファイルやディレクトリを指定するために使います。
# .dockerignoreファイルの例
.git
.env
.env.local
node_modules
*.log
Thumbs.db
このファイルを適切に使うことで、ビルドコンテキストのサイズを劇的に削減できます。例えば、node_modulesディレクトリを除外するだけで、ビルド時間が短縮し、ネットワークトラフィックが削減される効果が見込めます。.dockerignoreなしで500MBだったビルドコンテキストが、ありでは50MBになるなど、90%の削減も珍しくありません。
Dockerfileの詳細については、以下の記事で詳しく説明しています。
第六章：Docker Compose（複数コンテナの管理）：Dify起動の主役
実際のアプリケーションは、Difyのように「APIサーバー」「Webサーバー」「DBサーバー」など、複数のコンテナが連携して動作します。
これらを docker run で一つずつ起動・設定するのは非常に大変です。
Docker Composeは、複数コンテナで構成されるアプリケーションを定義し、たった一つのコマンドでまとめて管理・実行するためのツールです。
Difyのセットアップで docker compose up というコマンドを使います。これがDocker Composeです。
その定義ファイルが、Difyの docker/ ディレクトリにある docker-compose.yml です。
1. docker-compose.yml ファイル
Docker Composeは、docker-compose.yml というYAML形式のファイルに、起動するコンテナ群（サービス）の定義を記述します。Difyの dify/docker/ ディレクトリにある docker-compose.yaml がまさにこれにあたります。
# docker-compose.yml の簡易的な例
# (Difyのファイルは、これより遥かに高機能です)
# services: 以下に、起動したいコンテナ（サービス）を定義する
services:
# 1つ目のサービス「web」 (Webサーバー)
web:
# どのイメージを使うか (この場合はDockerfileからビルド)
build: .
# ポートの接続
ports:
- "5000:5000"
# 環境変数の設定 (Difyの .env ファイルがここで読み込まれる)
env_file:
- .env
# 依存関係 (webより先にdbを起動する)
depends_on:
- db
# 2つ目のサービス「db」 (データベース)
db:
# Docker Hubの公式イメージを使用
image: postgres:13
# データの永続化設定 (詳細は次章)
volumes:
- postgres_data:/var/lib/postgresql/data
env_file:
- .env
# ボリュームの定義
volumes:
postgres_data:
Docker Composeの主要コマンド
docker compose up -ddocker-compose.ymlに基づき、全てのサービスを**バックグラウンド（-d）**で起動します。（Difyの起動で使うコマンドです）docker compose down起動した全てのサービス（コンテナ、ネットワーク）を停止し、削除します。Difyを安全に停止する際に使います。docker compose down -v: コンテナと一緒にボリューム（データベースのデータなど）も削除するので注意が必要です。
docker compose logs -f全サービスのログをリアルタイムでまとめて表示します。Dify全体の動作確認に非常に便利です。
第七章：ボリュームとネットワーク（データの永続化）
Dockerの基本を学ぶ上で、最後に重要なのが「ボリューム」と「ネットワーク」です。
1. ボリューム (データの永続化)
コンテナは一時的な存在です。 docker compose down や docker rm でコンテナを削除すると、コンテナ内に保存されていたデータもすべて消えてしまいます。
Difyが書き込んだデータベースの内容（作成したアプリ、ナレッジベース、チャット履歴など）が消えてしまっては大変です。
そこで「ボリューム (Volume)」を使います。ボリュームは、Dockerが管理する特別な領域（ホストOS上）にデータの実体を保存し、それをコンテナに接続（マウント）する仕組みです。
docker-compose.yml の volumes: セクションで定義されたボリューム（例: postgres_data）は、docker compose down を実行しても削除されません（-v オプションを付けない限り）。これにより、Difyのコンテナをアップデート（再作成）しても、データは安全に引き継がれます。
2. ネットワーク (コンテナ間の通信)
Docker Composeは、起動時に自動でプライベートな仮想ネットワークを作成します。docker-compose.yml 内の全サービス（web, api, dbなど）はそのネットワークに接続されます。
webコンテナは、dbというサービス名（ホスト名）でデータベースコンテナに接続できます。- データベース（
db）は、ports:でポートを公開していないため、ホストOSや外部インターネットからは直接アクセスできず、セキュリティが保たれます。
まとめ
これで、Difyのセットアップに必要なDockerの基本知識は万全です。
- DifyはDockerという技術で「環境ごと」配布されている。
docker compose upは、docker-compose.yml（複数コンテナの設計図）を読み込んで、Difyアプリケーション全体（Web, API, DBなど）を起動するコマンド。docker psやdocker logsは、Difyが正しく動いているか確認するために必須。volumes（ボリューム）のおかげで、Difyコンテナを停止・更新してもデータ（チャット履歴やナレッジ）は消えない。
これらの知識があれば、Difyのセットアップガイドや、次に提案する「Docker手動インストールガイド」もスムーズに理解できるはずです。
Dockerの補足説明として、以下の記事を用意していますので併せてお読みください。
コメント