Dify | じじぃの引出し https://www.kazuban.com/blog なにかしら、皆さんの参考になれば幸いです！ Thu, 22 May 2025 01:03:00 +0000 ja hourly 1 https://wordpress.org/?v=6.9.4 https://www.kazuban.com/blog/wp-content/uploads/2020/05/cropped-ICON-1-32x32.png Dify | じじぃの引出し https://www.kazuban.com/blog 32 32 AIに教えてもらいながら、どうにかUbuntu上の Docker EngineでDifyをサーバー化できた。 https://www.kazuban.com/blog/ubuntu-dockerengine-dify/ Mon, 05 May 2025 01:17:22 +0000 https://www.kazuban.com/blog/?p=11029 前回までで、「Docker Engine」の設定は完了しています。
今回は、「Docker」で「Dify」を起動させサーバー化が目的です。
実現するにあたって、かなりAIに助けてもらったので、そのやり取りも紹介しています。

Difyをクローン化

gitの確認

difyをクローン化するのに、「git」を利用するので、「git」のインストール状況を確認します。
windows ターミナルを開き、wsl を起動し、「git -v」で状況を確認します。

PS C:\Users\hogehoge2> wsl

$ git -v
git version 2.43.0
インストールされていない場合には、インストール
$ sudo apt update
$ sudo apt install git

Gitでdifyをクローン化する

「git clone ・・」でクローン化を実行すると、カレントディレクト下「dify」ディレクトリへソースコードがクローン化されます。
windowsターミナルで、「wsl」を実行し、ubuntu環境へ入ると、デフォルトでは、winndowsユーザーのディレクトリへセットされた状態で起動します。
好みの問題だと思いますが、この場所へ「dify」環境を作成してもいいと思いますが、筆者はubuntuのユーザーホームディレクトリ下に作成しようと思います。
wsl、ubuntuプロンプトで、「cd」を実行すると、ユーザーのホームディレクトリへ移動します。
その場所で「git clone・・」すると、そのディレクトリ直下に「dify」さらにその下に「docker」ディレクトリが作成されています。
「ls」コマンドで確認できます。
「dify/docker」ディレクトリへ「cd」コマンドで移動しておきます。
「pwd」コマンドで、現在のディレクトリが確認できます。

hogehoge2@hoge-PC:/mnt/c/Users/hogehoge2$
$ cd
$ git clone https://github.com/langgenius/dify.git
Cloning into 'dify'...
remote: Enumerating objects: 153846, done.
remote: Counting objects: 100% (536/536), done.
remote: Compressing objects: 100% (359/359), done.
remote: Total 153846 (delta 396), reused 178 (delta 177), pack-reused 153310 (from 3)
Receiving objects: 100% (153846/153846), 87.73 MiB | 5.07 MiB/s, done.
Resolving deltas: 100% (111131/111131), done.
$ ls
dify
$ cd dify/docker/
$ pwd
/home/hogehoge2/dify/docker

Difyコンテナ起動

「git clone」を実行したディレクトリに、「dify/docker」ディレクトリが作成されています。
その中に「.env.example」のサンプル環境変数ファイルが作成されています。
通常ファイルは「ls」コマンドで確認できますが。「.」で始まるファイルは表示されません。
その場合「ls -la」コマンドを実行すると、表示されます。
コピーは「cp <オリジナルファイル名>　<複写ファイル名>」で複写できます。
「.env.example」ファイルを、正式な環境変数「.env」としてコピーし、「docker compose」コマンドで、コンテナを起動させます。

$ pwd
/home/hogehoge2/dify/docker
$ cp .env.example .env
$ docker compose up -d
[+] Running 80/80    
✔ web Pulled             149.7s
✔ sandbox Pulled         221.1s
 ✔ ssrf_proxy Pulled      88.2s
 ✔ db Pulled             224.4s
 ✔ worker Pulled         402.2s
 ✔ plugin_daemon Pulled  404.6s
 ✔ nginx Pulled           36.4s
 ✔ weaviate Pulled       225.1s
 ✔ redis Pulled          221.2s
 ✔ api Pulled            402.2s
[+] Running 12/12
 ✔ Network docker_default             Created    0.1s
 ✔ Network docker_ssrf_proxy_network  Created    0.0s
 ✔ Container docker-web-1             Started    3.7s
 ✔ Container docker-ssrf_proxy-1      Started    4.0s
 ✔ Container docker-sandbox-1         Started    3.7s
 ✔ Container docker-redis-1           Started    3.7s
 ✔ Container docker-weaviate-1        Started    3.7s
 ✔ Container docker-db-1              Healthy    10.7s
 ✔ Container docker-worker-1          Started    9.3s
 ✔ Container docker-plugin_daemon-1   Started    9.3s
 ✔ Container docker-api-1             Started    9.5s
 ✔ Container docker-nginx-1           Started    10.0s

docker compose upでエラー発生！AIに聞いてみる。

上記は正常な例ですが、古いPCをテストマシンとして利用した時、「docker compose up」で下記エラーがでた事がありました。

dependency failed to start: container docker-db-1 is unhealthy

この時もgeminiに聞いてみたところ、「docker logs docker-db-1」でログを確認してくれとの事なので、ログを直接貼り付けると、

Ai
Ai

ログを見る限り、データベースの初期化自体は正常に完了しています (PostgreSQL init process complete; ready for start up.)。 その後の起動プロセスも進んでいますが、2025-04-29 00:02:07.998 UTC [557] FATAL: the database system is starting up という致命的なエラーが出力されています。

このエラーは、PostgreSQLサーバーが起動してリカバリなどの内部処理を行っている最中に、外部からの接続要求（この場合はおそらくDockerのヘルスチェックや、依存するDifyコンテナからの初期接続試行）があった場合に発生することがあります。

つまり、データベースサーバー自体は最終的に database system is ready to accept connections の状態になりますが、Dockerのヘルスチェックがサーバーの準備が完全に整う前に接続を試み、上記の FATAL エラーを受け取ってしまい、それが原因でコンテナが unhealthy と判定されている可能性が高いです。

解決策:

Dockerのヘルスチェック設定を調整し、データベースが完全に起動して接続可能になるまで、チェックを待つように設定を変更するのが最も有効な対策です。

データベースサービス (db または postgresql) の healthcheck 設定を見つける:
services のセクションにある、データベースコンテナに対応するサービス定義（通常は db という名前）を探します。その中に healthcheck というブロックがあるはずです。

YAML
services:

db: # ... その他の設定 ...
healthcheck: # ここに設定があります
　　・
test: ["CMD-EXEC", "pg_isready -U <db_user> -d <db_name>"] # 例
interval: 10s
timeout: 5s
retries: 5
start_period: 30s # <-- この値を調整します

docker-compose.yml を開く: Difyを起動するために使用している docker-compose.yml ファイルをテキストエディタで開きます。

じじぃ
じじぃ

docker-compose.yamlを確認した所、「start_period:」の設定がありません。

Ai
Ai

start_period が指定されていない場合、コンテナが起動を開始すると同時にヘルスチェックが始まります。今回のデータベースのログで見たように、起動直後の一時的な準備期間中に接続を試みると FATAL: the database system is starting up のようなエラーが発生することがあります。

interval: 1s と非常に短い間隔でチェックが実行されるため、データベースが完全に準備できる前に多くのチェックが走ってしまい、すぐにリトライ回数（retries: 60）を使い果たして unhealthy と判定されてしまう可能性が高いです。

解決策:

start_period を追加し、必要に応じて interval も調整しましょう。

  1. healthcheck 設定に start_period を追加する: データベースが起動して準備ができるまでの猶予期間として、start_period を設定します。
    例えば 30s または 60s (30秒または60秒) を指定します。
    YAML
    services:
    db: # ... その他の設定 ...

    healthcheck:
    test: [ 'CMD', 'pg_isready', '-h', 'db', '-U', '${PGUSER:-postgres}', '-d', '${POSTGRES_DB:-dify}' ]
    interval: 5s # 例: 毎秒ではなく5秒ごとにチェックに緩和
    timeout: 3s
    retries: 10 # 例: リトライ回数を調整 (intervalを長くすればretriesは少なくても良い)
    start_period: 60s # <- この行を追加 (例: 60秒待つ)

    ポイント: start_period の間は、ヘルスチェックが失敗してもコンテナは starting 状態のままとなり、unhealthy とは判定されません。start_period が経過した後に初めて、ヘルスチェックの失敗が unhealthy の判定に使われます。
  2. interval も少し長めにすることをお勧めします: interval: 1s は開発時などに素早く確認したい場合には便利ですが、本番に近い環境や安定性を重視する場合は 5s や 10s に設定することが一般的です。これにより、データベースへの不要な負荷も軽減されます。
  3. docker-compose.yml を保存する。
  4. Docker Compose を再起動する: 変更を反映させるために、コンテナを再作成して起動します。

アドバイス通りに、編集して再度「docker compose up -d」を実行すると、正常になりました。
いやぁ～、AIさまさま、ですね～
おそらく、ネット検索では、解決できなかったと思います。
ただし、古いPCだったのが、一番の原因かもしれません。
５年ほど前のPCでは、このエラーはでなかったので、レアなケースかもしれませんが、AIの利用例として紹介しました。

Dify起動

初期画面

「docker compose up」が正常に終了すると、Webブラウザで「http://localhost/install」へアクセスすると「dify」の初期設定が開きます

Difyの動作と試用

とりあえず、起動しました。
以前このサイトでも説明していますが、簡単なチャットボットを作成し試してみます。
LLMモデルはオンラインの「gemini」を登録し、動作を確認できました。
オンラインであれば、「LM Studio」や「Ollama」など、ローカルLLMを利用するアプリは必要ないので、すぐに確認できます。

Difyを自動起動

Difyを動作させるには、Dockerが起動していなくてはいけません。
それには、WSL上で、ubuntuも起動している必要があります。
手動でやる場合、

・windowsターミナル起動
・wslコマンドで、ubuntuターミナル起動
・ubuntuターミナルでカレントディレクトリを、Difyのクローンディレクトリに移動
・「docker compose up -d」 コマンド実行

このような手順が必要ですが、問題なのは、ターミナルを閉じるとdockerも終了してしまうことです
Difyを使うには、dockerが起動していなくてはいけません。
windowsアプリの「docker desktop」であれば、標準で自動起動設定だったと思いますし、起動後もシステムトレイのアイコンで起動が確認できます。右ボタンで状態確認や終了も簡単です。
ubuntu経由の場合には、GUIでの確認ができないので、ここが面倒なところですね～。
自動起動方法をいろいろ調べると、windowsバッチファイルを作成し、スタートアップフォルダに登録する事で、windows起動時に、自動起動できそうです。
ただ、
「コマンドプロンプト　⇒　ubuntuターミナル　⇒　docker」
のタスクが必要で、ターミナルは開いた状態にしておく必要があります。
このようなバッチファイルを作りたいですが、どんなコードにすればいいのか・・？
うまいコードを考え付かなかったので、difyの試しもかねて起動しているチャットボットで設定しているgeminiに考えてもらいました。

@echo off
title Starting Dify via WSL

echo Starting WSL and navigating to ~/dify/docker...
echo Running 'docker compose up -d'...
echo WSL window will remain open after commands.

REM WSLを起動し、bashシェル内でコマンドを実行します。
REM cd ~          : ホームディレクトリに移動 (念のため)
REM cd ./dify/docker : dify/docker ディレクトリに移動
REM docker compose up -d : docker compose をバックグラウンドで起動
REM exec bash     : 上記コマンド実行後、インタラクティブなbashシェルを開始して終了させない
wsl.exe -e bash -c "cd ~/dify/docker && docker compose up -d && echo '--- Dify containers started (or attempted to start) ---' && exec bash"

echo WSL window launched. This batch window can be closed if desired.
REM pause REM Optionally uncomment this line to keep the batch window open until a key is pressed

すごいです。
ほとんど実際の起動には影響がない「REM」や「echo」文がほとんどですが、
「REM」文を使っての説明文や、「echo」での実行中のメッセージにも手抜きがないですね！
このコードをコピーしてエディターで、「start_dify.bat」というファイルで保存しました。
バッチファイルの単独実行では問題ありませんでした。
後はこのファイルのショートカットを、スタートアップフォルダへコピーするだけです。

・上記の作成したバッチファイルを、適当は場所へ保存します
　私は、ユーザーフォルダ「C:\Users\「ユーザー」」へ保存しました。
・次に、このファイルのショートカットを作成します。
・このショートカットを「スタートアップフォルダ」へ保存します。
　スタートアップフォルダは、エクスプローラーのアドレスバーへ「shell:startup」と入力すると開くことができます。

特に必須ではないですが、ターミナルは起動状態にさせるので邪魔になる場合、作成したショートカットファイルを、マウス右ボタンで「プロパティ」を開きます。
「プロパティ」の「ショートカット」タブの「実行時の大きさ」を「最小化」に設定すると、起動時にタスクバーに最小化状態で起動できます。

これで、再起動すると、自動起動したターミナルはタスクバーへ最小化状態ですが、環境によっては起動途中の場合があるので、すぐに使用したい場合には、一度開いてDockerの状態を確認したほうがいいと思います。
正常に起動できると、Webブラウザのアドレスバーに「http://localhost/install」でdifyが起動できます。
場合によっては、「http://localhost/signin」にリダイレクトされる場合もあります

この画面が開くと、ローカルPCでは、Difyを利用する事ができますが、今回はサーバーとして利用したいので、LAN上の別のPCからのアクセスも必要です。

Difyをサーバー化して、他のPCからもアクセスさせる

同じLAN上であっても、「localhost」では、他のPCではアクセスできません。
前回後半で少し話題にしましたが、「windowsホスト」「WSL(ubuntu)」「Docker」と複雑な通信環境なので面倒です。

DifyPCのIPアドレス調査

IPアドレスは、windowsターミナルでは「ipconfig」コマンド
WSLターミナルでは、「ip addr」で確認できます。
この情報を、Aiに添付して聞いてみました。

Ai
Ai

詳細な情報ありがとうございます！ipconfig と ip a の結果から状況がより明確になりました。
原因の特定
・Windows ホスト:
　あなたの Windows PC の Wi-Fi アダプターには 192.168.0.94 という IP アドレスが割り当てられています。
　これはご自宅などの LAN 内の IP アドレスです。
・WSL (Ubuntu):
　Windows Subsystem for Linux (WSL) 環境内の Ubuntu には、eth0 インターフェースに 172.31.226.6 という IP アドレスが割り当てられています。
　これは WSL が使用する仮想ネットワーク内の IP アドレスです。

Ai
Ai

WSL2 環境で Docker コンテナを動かしている場合、Windows ホストからそのコンテナ内のサービスにアクセスするには、通常以下のいずれかのアドレスを使用します。
１．localhost:
　Windows ホストのブラウザで http://localhost/chat/…と入力する。
　WSL2 は localhost 経由でのポートフォワーディングをサポートしています。
　（これが最も一般的な方法です）
２．WSL の IP アドレス: http://172.31.226.6/chat/…
　(今回アクセスできている方法)

・http://192.168.0.94/chat/… でアクセスできないのは、WSL2 と Docker のネットワークアーキテクチャ上、自然なことです。
サービスが Windows ホストの物理的な IP アドレスに直接公開されているわけではないためです。
・もし、LAN 内の他の PC (例: 192.168.0.100) からもこの Dify 環境にアクセスしたい場合は、追加の設定が必要になる可能性があります:

１．Windows ファイアウォールの設定: Windows のファイアウォールで、外部からのポート 80 (または Dify が使用しているポート) への着信接続を許可する必要があります。
２．ポートフォワーディング (状況による): WSL2 のネットワーク設定によっては、Windows ホストの 192.168.0.94 のポート 80 へのアクセスを、WSL の 172.31.226.6 のポート 80 へ転送する設定が必要になる場合があります。
これは 「netsh interface portproxy」 コマンドなどで設定できますが、まずは localhost や WSL の IP でアクセスできることを確認するのが先決です。

要約:
・Windows ホストからアクセスする場合: http://localhost/chat/… または http://172.31.226.6/chat/… を使用してください。
・http://192.168.0.94/chat/… でアクセスできないのは仕様であり、問題ではありません。

Windowsのアドレスからは、アクセスできない。

じじぃ
じじぃ

http://localhost や http://172.31.226.6 からはアクセスできています。
今回は、LAN上の別のPCからhttp://192.168.0.94 にアクセスしたいため、自分PCで試したら、アクセスできませんでした

Ai
Ai

なるほど、LAN上の他のPCからアクセスできるようにしたい、ということですね。承知いたしました。

ご自身のPC (192.168.0.94) から http://192.168.0.94/chat/... にアクセスできなかったのは、まさにその設定がまだされていないためです。Windowsホストのネットワーク(192.168.0.x) と WSL内部のネットワーク (172.31.x.x) は分離されており、外部（LANを含む）から直接WSL内のサービスにアクセスするには、「ポートフォワーディング（ポート転送）」という設定が必要になります。

設定手順

以下の手順を管理者権限で実行してください。

  1. Difyが使用しているポートを確認 (重要):
    • まず、DifyがWSL内でどのポート番号で待ち受けているか確認します。HTTPなので通常は 80番 ですが、Dockerの設定によっては異なるポート（例: 3000番など）がホスト(WSL)に公開されている場合があります。
    • Docker Composeを使っている場合は docker-compose.yml ファイルの ports: セクションを確認してください。例えば ports: - "80:80" や ports: - "3000:80" のようになっています。左側の数字がWSL側で公開されているポート番号です。
    • docker ps コマンドを実行しても確認できます。PORTS 列に 0.0.0.0:80->80/tcp や 0.0.0.0:3000->80/tcp のように表示されます。0.0.0.0: の後の数字がWSL側で公開されているポート番号です。
    • 以降の説明では、Difyがポート 80 を使用していると仮定します。もし異なるポート（例: 3000）だった場合は、コマンド内の 80 をその番号に読み替えてください。
  2. Windows ファイアウォールでポートを開放:
    • LAN内の他のPCからのアクセスを許可するために、WindowsのファイアウォールでDifyが使用するポート（ここでは80番）を開ける必要があります。
    • 管理者としてPowerShellを開き、以下のコマンドを実行します。
      powershell New-NetFirewallRule -DisplayName "Allow Dify Access from LAN" -Direction Inbound -LocalPort 80 -Protocol TCP -Action Allow
      (もしコマンドプロンプトを使いたい場合は、管理者として開き netsh advfirewall firewall add rule name="Allow Dify Access from LAN" dir=in action=allow protocol=TCP localport=80 を実行)
  3. ポートフォワーディングの設定:
    • Windowsホスト (192.168.0.94) のポート80に来た通信を、WSL (172.31.226.6) のポート80に転送するように設定します。
    • 管理者としてPowerShell（またはコマンドプロンプト）を開き、以下のコマンドを実行します。 powershell netsh interface portproxy add v4tov4 listenport=80 listenaddress=0.0.0.0 connectport=80 connectaddress=172.31.226.6
      • listenport=80: Windows側で外部からの接続を待ち受けるポート番号。
      • listenaddress=0.0.0.0: Windowsの全てのIPアドレス（192.168.0.94 を含む）で待ち受ける設定。特定のIP (192.168.0.94) だけを指定することも可能です。
      • connectport=80: 転送先のWSL内でDifyが待ち受けているポート番号。
      • connectaddress=172.31.226.6: 転送先のWSLのIPアドレス。
  4. 動作確認:
    • 設定後、まずご自身のPCのブラウザから http://192.168.0.94/chat/84aj9r6azPSYjXt8 にアクセスできるか試してください。 (ポートが80以外の場合は http://192.168.0.94:ポート番号/chat/... のように指定)
    • アクセスできれば、LAN内の他のPCからも同じアドレス (http://192.168.0.94/chat/...) でアクセスできるはずです。

注意点:

  • WSLのIPアドレスの変動: WSLを再起動すると、WSLのIPアドレス (172.31.226.6) が変わる可能性があります。もしアクセスできなくなった場合は、ip a コマンドでWSLの新しいIPアドレスを確認し、手順3のポートフォワーディング設定を一度削除して再作成する必要があります。
    • 削除コマンド: netsh interface portproxy delete v4tov4 listenport=80 listenaddress=0.0.0.0
    • 再作成コマンド: (新しい connectaddress を指定して再度実行)
  • 管理者権限: ファイアウォールとポートフォワーディングの設定には管理者権限が必要です。
  • ポート番号: Difyが使用しているポート番号を正確に確認し、コマンド内の 80 を適宜修正してください。

この手順で、LAN内の他のPCからアクセスできるようになるはずです。試してみてください。

docker ps コマンドで実行中のコンテナーを提出

じじぃ
じじぃ

docker ps では下記になっています。
$ docker ps
・・
・
・

Ai
Ai

docker ps の出力結果、ありがとうございます。

コンテナ docker-nginx-1 の PORTS 列にご注目ください。

PORTS
0.0.0.0:80->80/tcp, [::]:80->80/tcp, 0.0.0.0:443->443/tcp, [::]:443->443/tcp

これは、以下のことを意味しています。

  • 0.0.0.0:80->80/tcp: WSLホスト（172.31.226.6 など）の ポート 80 (HTTP) へのTCP接続を、docker-nginx-1 コンテナ内部のポート 80 に転送する。
  • [::]:80->80/tcp: 上記のIPv6版。
  • 0.0.0.0:443->443/tcp: WSLホストの ポート 443 (HTTPS) へのTCP接続を、docker-nginx-1 コンテナ内部のポート 443 に転送する。
  • [::]:443->443/tcp: 上記のIPv6版。

docker-web-1 コンテナ自体は内部的にポート 3000 を使っていますが、外部（WSLホスト）からのアクセスは docker-nginx-1 コンテナがポート 80 (HTTP) と 443 (HTTPS) で受け付けています。Nginx がリバースプロキシとして動作し、リクエストを docker-web-1 や docker-api-1 などに振り分けている構成です。

結論

あなたが LAN 上の他の PC からアクセスしたい HTTP のポート番号は 80 です。

したがって、先ほどのポートフォワーディング設定のコマンドは、ポート番号 80 を使って実行してください。

  1. ファイアウォール開放 (ポート 80): New-NetFirewallRule -DisplayName "Allow Dify Access from LAN (HTTP)" -Direction Inbound -LocalPort 80 -Protocol TCP -Action Allow
  2. ポートフォワーディング設定 (ポート 80):
    powershell netsh interface portproxy add v4tov4 listenport=80 listenaddress=0.0.0.0 connectport=80 connectaddress=172.31.226.6

これで、 http://192.168.0.94 (ポート80は省略可能) でアクセスできるはずです。

もし将来的にHTTPS (https://192.168.0.94) でアクセスしたい場合は、同様にポート 443 用のファイアウォールルールとポートフォワーディング設定を追加する必要があります。

ファイヤーウォールとポートフォワーディング設定

ファイアウォールを開放し、ポートフォワーディング設定をしろ、のアドバイスです。
教わったコードを実行してみます。

１．ファイアウォール開放 (ポート 80):

PowerShell
PS C:\Users\hoge2>　New-NetFirewallRule -DisplayName "Allow Dify Access from LAN (HTTP)" -Direction Inbound -LocalPort 80 -Protocol TCP -Action Allow

コントロールパネル→システムとセキュリティ→windows Defender ファイアウォール→詳細設定
受信の規則で
コマンドで指定したAllow Dify Access from LAN(HTTP)が設定されているのが、確認できます。
コマンドではなく、この画面で、GUI設定する事もできます。

2．ポートフォワーディング設定 (ポート 80):

管理者権限のPowerShell の、「netsh」コマンドで設定します。

PowerShell（管理者）
PS C:\Users\hoge2> netsh interface portproxy add v4tov4 listenport=80 listenaddress=0.0.0.0 connectport=80 connectaddress=172.31.226.6

「netsh interface portproxy show v4tov4」で確認できます。

PS C:\Users\hoge2> netsh interface portproxy show v4tov4
ipv4 をリッスンする:         ipv4 に接続する:
Address         Port        Address         Port
--------------- ----------  --------------- ----------
0.0.0.0         80          172.31.226.6    80

アクセスできた～

これで無事に「http://192.168.0.94/instal」でアクセスできました。
LAN上の別のPCからも、アクセス確認できました。
おそらく、ネット検索では、ここまで的確なアドバイスを見つけるのは至難の業だと思います。
ちょっと前までは、言語生成AIをうまく使うには、プロンプトが重要だと言われていましたが、最近の言語生成AIはかなり言語の理解力が向上していると感じます。
上記のじじぃの質問でもわかりますが、ほとんど「プロンプト」など意識していません。
とにかくわからない事やPCからの出力を、自分の言葉で質問しているだけです。
それでもかなり的確な回答をくれます。
たまには、間違った回答もありますが、それでエラーが発生した場合、そのエラーやログをそのまま突っ込めば、新たな回答をくれます。
すごい時代になりました。

DifyにLLMを設定して、カスタムチャット環境を構築

やっとDifyサーバーが起動できました。

次に、このDifyにLLMモデルを設定することで、チャットボットをはじめカスタムLLMアプリを開発する事ができるようになります。
左図の例では、
一番上の「Gemini」はオンラインで公開されているLLMです。
二番目は、「LM Studio」でダウンロードしたローカルLLMです。
三番目は、「Ollama」で読み込んでいるローカルLLMです。
このように、「Dify」ではオンライン、ローカルあまり意識せず、使用するLLMを自由にカスタマイズできます。

DifyにLLMの設定方法

ネット上でも、多くの情報があると思いますが、このサイトでも以前の記事で紹介しています。

オンラインLLMの登録

ローカルでDifyとLM_Studio を連携させ、ローカルでチャットボットを作る。
LM StudioとDifyをローカルで連携させたのでレポートします。記事を書いている時に、Dify設定にLM Studioのプラグインを発見したので、そちらの設定も追加してます。
www.kazuban.com
2025.03.23

LM Studio モデルの登録

ローカルでDifyとLM_Studio を連携させ、ローカルでチャットボットを作る。
LM StudioとDifyをローカルで連携させたのでレポートします。記事を書いている時に、Dify設定にLM Studioのプラグインを発見したので、そちらの設定も追加してます。
www.kazuban.com
2025.03.23

Ollama　モデルの登録

DifyとOllamaを連携させ、ローカルチャットボット環境を作る
前回はLM StudioとDifyの連携でしたが、今回は、Ollamaと連携させてみました。どちらもそれぞれ特徴があるので、使い分けてもいいと思います。 私的には、スタンドアローンで使うならLM Studio。Difyとの連携であればOllama かな？と思っています。
www.kazuban.com
2025.03.30

あとがき

Windowsアプリ「Docker Desktop」を使わず、「Ubuntu」にインストールした「Docker Engine」で「Dify」をサーバー化する方法を紹介しました。
「Docker Desktop」はWindows環境向けのツールであり、構築の手間は比較的少ないですが、Ubuntuサーバー上で動作させる際は、仮想化環境の設定やネットワーク通信の複雑さが生じるため、トラブルシューティングがやや難しくなります。
今回は、AIのアシストにより、Difyサーバーを構築することができました。
設定プロセスだけでなく、AIを活用した実践例として、このやり取りもご参考にしていただければ幸いです。

]]> DifyとOllamaを連携させ、ローカルチャットボット環境を作る https://www.kazuban.com/blog/dify-ollama/ Sat, 29 Mar 2025 23:22:16 +0000 https://www.kazuban.com/blog/?p=10632 前回は、DifyとLM Studioを連携させて、ローカル環境を作成しました。
ただし、LM Studioは、完全にオープンライセンスではないようで、企業で使用する場合には、確認が必要です。
Ollamaのほうが、自由に使えそうです。
ただし、いろいろなLLMを試してみたり、チャットが主な目的な場合には、LM Studioのほうが、GUIでの操作ができるので、初心者はLM Studioが取りつきやすいと思います。
特に、使用ＰＣスペックでの動作推測やモデルの詳細などは、分かりやすいです。
Difyと連携させて利用する場合では、繋がってしまえば、あまり違いはないかもしれません。
いろんなモデルをLM Studioでの試してみて、気に入ったモデルをOllama経由でDify連携の使い方もありかな、と思います。

インストール

OllamaをWindowsにインストールするには、下記サイトからインストール実行ファイル「OllamaSetup.exe」をダウンロード・実行でインストールできます。

インストール完了後、何事もなく終了ますが、スタートメニューには登録され、タスクバーの「隠れているインジケータ」にアイコンがあれば起動しています。
コマンドプロンプトなどを開いて、「ollama ーーhelp」コマンドで確認してみます。

PS C:\Users\hoge> ollama --help
Large language model runner

Usage:
  ollama [flags]
  ollama [command]

Available Commands:
  serve       Start ollama
  create      Create a model from a Modelfile
  show        Show information for a model
  run         Run a model
  stop        Stop a running model
  pull        Pull a model from a registry
  push        Push a model to a registry
  list        List models
  ps          List running models
  cp          Copy a model
  rm          Remove a model
  help        Help about any command

Flags:
  -h, --help      help for ollama
  -v, --version   Show version information

Use "ollama [command] --help" for more information about a command.
PS C:\Users\hoge>

エラーが出なければ、無事に動作しています。
「ollama ーーversion」でバージョンを確認できます。

PS C:\Users\hoge> ollama --version
ollama version is 0.6.2

モデルをダウンロードして起動

LLMを利用するにいは、公開されているモデルを下記から確認、ダウンロードできます。
https://ollama.com/search
一覧から、利用したいモデル名をクリックすると、さらに「1b」「4b」など、モデルサイズで数種類でてきます。
一般的に小さい方が、性能は低い傾向にありますが、レスポンスはよくなります。
自分の環境で、レスポンスと相談して、大きいモデルがいいと思います。
LM Studio の場合、自分のＰＣスペックとの相性をある程度アイコンで表示してくれますが、Ollamaでは、とりあえず試してみて・・になるのかな～？
LM Studioで体験しておくと、自分の環境でも大丈夫なモデルサイズは察しがつきます。

ターミナルで「ollama run [モデル名]」でダウンロード後実行できます。
モデル名は、ダウンロードサイトのコピーアイコンを利用するとモデル名をクリップボードへコピーできるので便利です。

PS C:\Users\hoge> ollama run gemma3:4b
pulling manifest
pulling aeda25e63ebd... 100% ▕███████████▏ 3.3 GB
pulling e0a42594d802... 100% ▕███████████▏  358 B
pulling dd084c7d92a3... 100% ▕███████████▏ 8.4 KB
pulling 3116c5225075... 100% ▕███████████▏   77 B
pulling b6ae5839783f... 100% ▕███████████▏  489 B
verifying sha256 digest
writing manifest
success
>>> 始めまして
はじめまして！こちらこそ、ご挨拶ありがとうございます。

何か私にできることはありますか？ 例えば、

*   何か質問に答える
*   文章を作成する
*   アイデアを出し合う
*   ただおしゃべりする

など、どんなことでも構いません。😊

>>> Send a message (/? for help)

「>>> Send a message (/? for help)」のプロンプトがでると、会話ができます。
会話の終了は「/bye」です。

Difyとの連携

前回、「LM Studio」との連携で、LM Studioプラグインの設定方法と、ほとんど同じです。

「設定」の「モデルプロバイダー」から「Ollama」プラグインをインストールします。
インストールが完了したら、再度「設定」の「モデルプロバイダー」「Ollamaモデル」に「モデルを追加」で上記でダウンロードしたモデルと「URL（ＩPアドレス）」を設定します。
ダウンローズ済みモデルは、ターミナルから「ollama list」コマンドで確認できます

PS C:\Users\hoge> ollama list
NAME           ID              SIZE      MODIFIED
llama3.2:1b    baf6a787fdff    1.3 GB    8 minutes ago
gemma3:4b      c0494fe00251    3.3 GB    26 minutes ago
PS C:\Users\hoge> ollama run llama3.2:1b
>>> /bye
PS C:\Users\hoge>

また、「Base URL」は「ollama」が動作している、PCの「IPアドレス」に「:11434」のポート番号を付加して設定します。
ただし、URLがLAN上の他のPCのIP（localhost以外の場合）でエラーが発生してしまう場合、下記の「環境変数の編集」を試してみてください。
正常に「保存」が終了すると、前回記事の「LM Studio」の場合と同様に、Difyで利用するモデルとして選択できるようになります。

Windows 環境変数の編集

「Ollama」の環境変数について、geminiに聞いて、下記回答をもらいました。

Ollamaの環境変数についてですね。Ollamaは、ローカルで大規模言語モデル（LLM）を実行するためのツールであり、いくつかの環境変数を使用してその動作をカスタマイズできます。主な環境変数は以下の通りです。

  • OLLAMA_HOST:
    • Ollamaがリッスンするホストアドレスを指定します。デフォルトは127.0.0.1であり、ローカルマシンからの接続のみを受け付けます。ネットワーク上の他のマシンからOllamaにアクセスできるようにするには、この変数を0.0.0.0に設定します。
  • OLLAMA_MODELS:
    • モデルの重みを保存するディレクトリのパスを指定します。デフォルトでは、Ollamaは特定のデフォルトディレクトリにモデルを保存しますが、この変数を使用して別の場所を指定できます。これにより、モデルファイルを別のドライブやディレクトリに保存することができます。
  • OLLAMA_ORIGINS:
    • クロスオリジンリクエストを許可するオリジンを指定します。OLLAMA APIをWebアプリケーションから利用する場合に設定します。
  • OLLAMA_DEBUG:
    • デバッグモードを有効にします。Ollamaのデバッグ情報を表示する場合に設定します。

これらの環境変数を設定することで、Ollamaの動作を柔軟に制御できます。環境変数の設定方法は、オペレーティングシステムによって異なります。

  • Windows:
    • 「システム環境変数の編集」から設定します。
  • macOS / Linux:
    • ターミナルからexportコマンドを使用して一時的に設定するか、.bashrcや.zshrcなどのファイルに記述して永続的に設定します。また、サービスとしてOllamaを実行している場合は、systemdの設定ファイルに環境変数を記述します。

より詳細な情報や具体的な設定方法については、Ollamaの公式ドキュメントや関連するオンラインリソースを参照することをおすすめします。

他のサイトをみると、環境変数を設定しないでも、正常に動作しているような記事も見かけましたし、「OLLAMA_HOST」だけ設定している記事もありました。
筆者の場合も、「OLLAMA_HOST」だけで正常に動作ましたが、「OLLAMA_ORIGINS」も設定しました。
また、「OLLAMA_MODELS」を設定すると、デフォルト（Cドライブ）以外にモデルを保存できます

Ollama用、環境変数の追加

環境変数を行う前には、「ollama」は終了しておきましょう。
タスクバー右の「^」ボタン「隠れているインジケーター」から、Ollamaアイコン右クリック「Quit Ollama」でも終了できます。
Windows検索バーに「環境変数」と入力すると「システム環境変数の編集」が見つかるので、「環境変数」ボタンをクリックして上段の「ユーザー環境変数」の「新規」で環境変数を追加します。

OLLAMA_HOST : 0.0.0.0
OLLAMA_ORIGINS : *
OLLAMA_MODELS : D:\Ollama_Models

ただし、「OLLAMA_MODELS」の設定は、注意が必要です。
環境変数追加前に、ダウンロードしたモデルは、自働的には移動してはくれません。
再度、ダウンロードするか、デフォルトでは
「C:\Users\[ユーザー]\.ollama\models」の下に登録されているので、環境変数変更前に指定フォルダへコピーしておくと、反映されると思いますが、試してはいません。
環境変数変更後でも、Ollamaを起動する前に、設定したフォルダへ移動してもいいかもしれません。
環境変数の編集が適応されているかは、下記で確認できます。
コマンドプロンプトとPowerShellで指令が違うので注意してください。

★コマンドプロンプト
C:\Users\hoge>echo %OLLAMA_HOST%
0.0.0.0

C:\Users\hoge>echo %OLLAMA_MODELS%
D:\Ollama_Models

C:\Users\hoge>echo %OLLAMA_ORIGINS%
*

★PowerShell
PS C:\Users\hoge> $env:OLLAMA_HOST
0.0.0.0

PS C:\Users\hoge> $env:OLLAMA_MODELS
D:\Ollama_Models

PS C:\Users\hoge> $env:OLLAMA_ORIGINS
*

Dify にもモデルを登録する

モデルフォルダを変更した場合には、「ollama list」コマンドで確認できます。
正常に変更されていれば、再度「Olama」を起動して、「Dify」の「Ollama」モデルのプラグイン設定で追加できるようになります。
追加方法は、LM Studio 編を参考にしてください。

追加したモデルは、Difyで作成するアプリから、ollamaを利用できるようになります。

あとがき

これで、完全ローカルで、DifyからOllamaも利用できるようになりました。
筆者の環境では、「Windows環境変数の編集」が必要だったので、少し戸惑いましたが、どうにか利用できるようになりました。
LM Studioがいいのか？Ollamaがいいのか？は、自分の環境や使い勝手で使い分けてください。
選択肢があるというのは、いいことだと思います。
さぁ、いよいよ、Difyの勉強を始められる環境は出来上がりましたが・・・・
ちょっと、Docker Desktop の環境なのが気になっています。
WSLでUbuntu24.04を起動させた環境か、現在稼働中のLinuxマシンか・・・
いずれにしても、linux環境で立ち上げてみたくなってきました。

]]> ローカルでDifyとLM_Studio を連携させ、ローカルでチャットボットを作る。 https://www.kazuban.com/blog/dify-lmstudio/ Sat, 22 Mar 2025 23:40:15 +0000 https://www.kazuban.com/blog/?p=10639 以前の記事で、LM Studioを利用して、ローカル環境でLLMを利用する方法
を紹介しました。
また前回、生成Aiアプリを比較的簡単に開発できる、Difyをローカルで起動
させてみました。
今回はこのDifyとLM Studioを連携させ、完全ローカル環境で生成Aiアプリを開発する環境設定を作ってみます。
筆者はDifyは超初心者なので、Difyでのアプリ開発に興味あるかたはネットをチェックしてみてください。
ここでは、DifyとローカルLLMと連携する方法を紹介します。

Difyで簡単なチャットボット作る

まずは、Difyで一番簡単なチャットボットを作成する流れを説明します。
前回までで、Difyをインストールして「http://localhost/install」でアカウント作成を行いました。
ログインすると、「最初から作成」でアプリが作成できるようになります。

とりあえずチャットボットを選択し、「アプリのアイコンと名前」と「説明」は任意で入力します
「作成する」で、次の画面へ進みます。

ここで、右上の設定から、使用したいモデルを選択する事で、このモデルと会話するチャットアプリが作れますが、事前に使用するLLMモデルの登録が必要です。
ここでは、事前にオンラインのgeminiモデルを登録しておいたので、geminiの複数モデルが選択できるようになっています。
違うモデルで何種類か作成し公開すれば、簡単に違うモデルと会話できるアプリが作成できます。
ただしこれは、ローカルではなくオンライン環境になります。
ここで、LM_Studioで動作させてさせている、ローカルLLMを登録すれば、ローカルLLMと会話できるようになります。

モデルを登録する

Difyはとても機能が多く非常に興味的なアプリなので、筆者ももう少し取り組んでみたいと思っていますが、まずはローカル環境でいろいろ試せる環境を作ります。

オンラインLLM gemini の登録

まずは、ローカルではないですが、Googleのgeminiを利用してみます。
利用するには、geminiプラグインのインストールが必要です。
プラグインは、右上のユーザー名から出てくるプルダウンで「設定」を選択すると、
左サイドに「設定」の項目が表示されます。
その下段のモデルプロバイダーで登録します

インストールしたいモデル（今回は、Gemini）を探してインストールします。
インストールは私の環境では結構時間がかかりました。
インストール中でも画面にあまり変化がないので完了したタイミングを見逃しがちですが、
右上のプラグインアイコンがこの状態は、インストール中です
完了するとこのアイコンになりますので、待ちます。
次に、インストール後Geminiを使用するには、API-KEYのセットアップが必要です。

APIキーが正常に設定されると、「右上のユーザ」⇒「設定」⇒「モデルプロバイダー」で設定済みのモデルとして表示されます。

ただし、私の環境では、正常に設定できたとメッセージがでたのに、ここに表示されていない事がありました、その場合、もう一度モデルプロバイダー一覧から再度インストールすると表示されました。
この場合、インストール時間は殆どかかりません。
これで、上の例のように、使用モデルとして選択できるようになります。

ローカルLLM LM Studio の登録

Geminiはオンラインクラウド上のLLMですが、いよいよローカルLLMと連携させます。

LM Studio をサーバーモードにする

DifyとLM Studioを連携するには、まず、LM Studioをサーバーモードで動作させます。
まず左サイドバーのDeveloperアイコンで、開発者モードに入り、

その横のスイッチで「Static Running」状態に設定すれば、サーバーモードで動作しています。
次に、Difyに提供する、モデルを「Select a model load」でダウンロード済みのモデルから選択します。
２個のモデルをロードしてみました。

この状態であれば、Difyでロードしたモデルを使用できるようになります。
ただし、LM Studioをクローズすると、モデルも使用できなくなってしまいます。
右下の歯車マークで設定画面に入り

「Enable Local LLM Service」にチェックすれば、クローズしてもサーバー状態を維持します。

DifyでLM Studio のモデルを利用する

この記事を書いている時に自分でも再作業をしていたら、「LM Studio」用のプラグインが公開されているのに気が付きました。
これから説明する「OpneAI-API-compatible」よりも、わかりやすそうです。
たぶん公開は最近だと思うので、不具合がないとも言えませんが、もし、こだわりがなければ、「LM Studio」プラグインの方が簡単だと思います

ここでは、書き始めていた「OpneAI-API-compatible」の説明を行います。
geminiの時と同様に、「モデルプロバイダー」の「設定」で対応しているプラグインをインストールします。
LM Studioが利用するには「OpneAI-API-compatible」をインストールします。

インストールが完了したら、「モデルを追加」で、モデル名と
LM Studio サーバーの「URL」＋「/V1」を設定します。

モデル名とLM Studio のURL は、「LM Studio」の画面から、「コピー」アイコンで、クリップボードへコピーすれば、ペーストできます。
ただし、「API endpoint URL」は「URL」の後ろに「/V1」が必要です。
「/V1」がなくても、正常に保存できる場合がありますが、実際にチャットする時にエラーになりますので忘れないでください。
「LM Studio」に何種類がモデルがロードされている場合、ここでも複数設定しておくと、Dify側で複数のモデルを使分ける事ができます

LM Studio サーバーのモデル使用

ここまで完了すると、Dify側でのモデル選択で利用できるようになっています。
上記の「gemini」モデル一覧の下に、追加されているので、ここで選択する事でつかえるようになります。

LM Studio のモデルプロバイダーが追加されてる・・・

この記事を書いていて、Difyを触っていて気が付いたのですが、「モデルプロバイダー」一覧に「LM Studio」が入っていました。

筆者が見落としていただけなのか？ちょっと前にはなかったと思います。
そういう理由で、「OpneAI-API-compatible」を利用したのですが、「LM Studio」のほうが、名前からして分かりやすいですね。
試しに、インストールしてみたところ、問題なく使用できました。
ただ、「OpneAI-API-compatible」では、「API endpoint URL」で、「LM Studioサーバー」の「URL」とその後ろに「/V1」が必要でしたが、こちらは「Base URL」の設定項目で「URL」のみでOKです。
この設定も、わかりやすいです。

あとがき

ついに、ローカル上で、ローカル上のLLMモデルを利用した、チャットアプリ開発環境が完成しました。
企業で使うには、ライセンスの確認も必要ですし、動作させるPCのスペックは大きくなると思いますが、個人や少人数で使う場合、簡単に試しながら、気軽にDifyの学習ができるようになります。

]]> 話題のDifyをインストールしてみた。失敗談あり。 https://www.kazuban.com/blog/dify-install/ Sat, 15 Mar 2025 08:14:52 +0000 https://www.kazuban.com/blog/?p=10515 LM Studio は、簡単にローカルで複数のLLMを試す事ができる便利なアプリです
以前、このサイトでも記事にしました。

LM Studio、ChatGPTのような大規模言語モデル（LLM）をローカルで簡単に動かせる時代が来た
LM Studio を体験してみました。 簡単に、ローカルPCでAiとチャットできます。 機密性の情報を扱う場合には、ローカルなので安全性は高まります 文章を要約したり、レポート作成してもらったり、正確な回答が必要でない場合には、使えそうです。 プログラムなど正確性が必要な場合には、オンラインのほうがよさそうです。
www.kazuban.com
2025.01.01


Difyは、チャットボットなど、AIアプリを比較的簡単に作成する事ができるアプリですが、LM Studioと連携する事で、ローカルでのチャットボットが作れそうです。
今回は、まずDifyを起動させてみました。
Difyの詳しい使用方法は、ネット上に沢山情報があるので、検索してみてください。
筆者もこれから触ってみて、記事にできそうであれば、レポートしたいと思います
Difyの立ち上げはそれほど難しくはないですが、ちょっと余計な事して、思うように動作せず、かなり悩んでしまったので、覚書かねて、レポートします。

Difyをローカルで立ち上げる

Difyは、クラウド上にも、Webアプリサービスが提供されており、サブスクで利用することもできますhttps://cloud.dify.ai/signin
ただ、オープンソースも公開されており、個人PCでクローン化すれば、無料で制限なく使用できますが、通常のwindowsインストールとは、ちょっと違う作業が必要です。

  • 「WSL2」環境の構築
  • 「Git」のインストール
  • 「Docker　Desktop」のインストール
  • 「Docker」で「Dify」をクローン化して利用可能にする

もともとは、Linux環境で開発されたソフトウェアなので、通常のWindowsアプリをインストールするよりも、コマンド作業も出てくるので、戸惑う事もありますが、一ステップずつやっていけば、意外と簡単です。

WSL2インストール

Linux 用 Windows サブシステム 機能の有効化

「Docker」は「Windows Subsystem for Linux」上で動作するので、WSLの環境が必要です。
最近のPCであれな、デフォルトで有効になっているのかもしれませんが、古い場合事前の設定が必要です。
WSLの環境ができていなくても、機能が有効になっていれば「Docker Desktop」のインストーラがやってくれますが、警告メッセージや更新作業などの要求がでる場合があるので、事前にWSL環境を作っておいたほうがいいと思います。

WSLの環境ですが、古いマシンの場合、場合よっては、BIOSでの仮想マシン有効設定が必要な場合もあるようです。
古いマシンを利用する場合には、事前に調査しておいたほうがいいと思います。
BIOS的に、仮想マシンが有効であれば、

コントロールパネル　⇒　プログラム　⇒
　　　　⇒　「プログラム機能：windowsの機能の有効化または無効化」

で、「Linux用Windiwsサブシステム」と「仮想マシンプラットフォーム」にチェックをいれます、

「OK」ボタンを押すと、自動的に必要なファイルを検索し、構築してくれます。
作業が終了したら、WIndowsを再起動します。

WSL更新

再起動後は、「コマンドプロンプト」でアップデートしておきます。

C:\Users\hogehoge>wsl --update
更新プログラムを確認しています。
Linux 用 Windows サブシステムをバージョンに更新しています: 2.4.12。

Git のインストール

「Git」は、Windowsのインストーラが用意されているので、比較的簡単にインストールできます。
こちらにアクセスし、「Click here to download 」でダウンロードして実行します。
いろいろ選択するダイアログが出てきますが、私はダウンロード先を「Dドライブ」に変更しただけで、すべてデフォルトでインストールしました。

Docker Desktopインストール

「Docker」は、複数の開発環境を、パッケージにしてアプリを実行できるアプリです。
環境ごとに、ハードウェアを用意する必要がないので、特に開発側ではよく使われているようです。
Difyを動かすには、「Dify」環境を「Docker」内でパッケージ化して、動作させます。
「Docker Desktop」は、Windowsインストーラも用意されているので、比較的簡単にインストールできます。
ただし、完全無料ではありません。
下記を超える規模の企業で利用する場合、利用回数制限やサブスク型有料になります。

個人・従業員250人未満かつ年間収益1,000万ドル以下の企業

実際の動作環境は、裏で「Docker Engine」が働いているようで、こちらだけであれば、オープンソースで公開されています。
ただし、こちらは、Linuxでのコマンド操作が必要になりそうです。
ちょっと興味もありますが、まずは「Docker Desktop」で進めます

インストール

こちらに、アクセスし、「Download Docker Desktop」から「Download for Windows-AMD64」をダウンロードし実行ます。
Windowsの警告などのメッセージがでる事もありすが、許可すると確認の画面が出てきます
「OK」でインストールが始まります。

終了すると、再起動要求がない場合には不要かもしれませんが、念のため再起動しておきましょう。
Windowsが再起動すると、上記の「Configuration」⇒「Add shortcut desktop」にチェックを入れておいた場合、デスクトップに「Docker」のショートカットが作られていると思います。
もし作られていない場合、PCの環境が管理者権限を必要としているかもしれません。
通常は、ショートカットのアイコンで起動できますが、作られていない場合、タスクメニューからでも起動できます。
ただし、ショートカットが作られなかった場合、管理者権限で実行しないと、正常に起動しない場合もあります。
管理者権限での起動の場合、下記の説明と違ってくるかもしれませんので、ご了承ください。

セットアップ

最初の起動では、タコやクジラのイラストの画面が立ち上げります。

これは、上記でも少し説明した、ライセンスに関しての注意事項です。
個人使用や指定規模未満の企業であれば「Accept」で次へ進みます。

「Welcom_to_Docker」と「Welcom Survey」は「Skip」でも大丈夫です。
無事に次に進むと、「Containers」の説明などへのリンクが表示されます。
これで、「Docker Desktop」のインストールは完了しています。
次にいよいよ、「Dify」をクローン化して使えるようにしていきます。
クローン化は、ターミナルでコマンドを入力して実行しますが、「コマンドプロンプト」や「PowerShell」を開いてもいいし、最後の画面右下の「>_Terminal」も利用できます。

Difyのインストール

「Docker」を使って「Dify」を起動させるには、次の操作を行います

  • GitHub に公開されている dify プロジェクトのソースコードをダウンロードし、複製する。
  • Docker Composeというツールを使って複製されたアプリの構築と起動する。

GitアプリでGithubで公開されている、difyのコードをクローン化する

「PowerShell」などのターミナルを開き、次のコマンドを実行します。

git clone https://github.com/langgenius/dify.git

このコマンドを実行すると、カレントディレクトリに、「dify」、さらにその下に「docker」ディレクトリが作成され、「docker」内に、difyがクローン化されます。

★ここで、失敗談

カレントディレクトリと言う考えが良くなかったようで、カレントに入るのであれば、カレントを変更すれば、Dドライブなどにもインストールできるな！
と、勝手に思ってしまいました。
通常のアプリのインストールでも、なるべくCドライブへは入れないようにしています。
試しに、クローン化前に、ターミナルから「ch」コマンドでカレントディレクトリを変更し、やってみたところ正常にクローン化され、その後の「Docker Compose」も「Dify」も正常に動作しているように見えました。
しかし、Difyを触っていて、LLMの「APIキー」の認証がうまくいきませんでした。
「Dify」の動作自体は正常だったので、「APIキー」の認証方法が悪いのか？と結構悩みましたが、デフォルトの設定がWindowsでログインしているユーザーのホームディレクトリを想定しるとすれば、「APIキー」がうまく書き込めない可能性も考えられます。
設定用のYAMLファイルや、環境変数を編集する事で、正常にできそうではありますが、慣れないうちは、ログインユーザーフォルダでの作業がよさそうです。

それでは、ターミナルを開いた状態で、クローン化していきます。

PS C:\Users\hoge> git clone https://github.com/langgenius/dify.git
Cloning into 'dify'...
remote: Enumerating objects: 146709, done.
remote: Counting objects: 100% (800/800), done.
remote: Compressing objects: 100% (440/440), done.
Receiving objects:  5% (7336/146709), 3.07 MiB | 6.10 MiB/s, done.
Receiving objects:  6% (8803/146709), 3.07 MiB | 6.10 MiB/s, done.
            ・ 
            ・

これで、「C:\Users\hoge」直下に「dify」、さらにその下に「docker」ディレクトリが作成され、その中に必要なファイル群が作成されてます。
作成されたファイル群には、環境ファイルのサンプルも入っているので、そのファイルをコピーし、必要あれば、編集して、アプリのパッケージ（コンテナ）を生成します。
まずディレクトリを「dify\docker」に移動し、その中に作成されている、サンプル環境変数を正式な環境変数としてコピーし、「docker compose」コマンドで、コンテナを起動させます。

環境ファイルサンプル「.env.example」を、「.env」の名前でコピーし
「docker compose」コマンドで、コンテナを操作します

PS C:\Users\hoge>cd dify\docker
PS C:\Users\hoge\dify\docker> copy .env.example .env
PS C:\Users\hoge\dify\docker> docker compose up -d

ちなみに、AIに「docker compose up」は何者なのか？聞いてみました。

docker compose up -d コマンドは、Docker Compose ファイルに従って、コンテナをデバッグモードで起動・実行するコマンドです。
解説:
docker-compose: Docker Compose を使うためのツール。複数のコンテナとそれらの依存関係を管理するためのファイル（docker-compose.yml）を読み込み、その定義に基づいてコンテナを操作します。
up: Docker Compose ファイルに従ってコンテナを起動するコマンドです。
-d: デバッグモードで実行することを意味します。このオプションを使えば、コンテナがバックグラウンドで動作し、ターミナルからは出力されなくなります。
docker compose up -d を実行すると:
docker-compose.yml ファイルを読み込みます。
定義されている各サービス (アプリケーション) のためのコンテナを起動します。
サービス間の依存関係を自動的に解決し、必要な順序でコンテナを立ち上げます。
バックグラウンドでコンテナが動作を開始します。
使用例:
docker-compose.yml ファイル内に複数のアプリケーションが定義されており、それらが互いに連携して動作する場合に便利です。例えば、ウェブサーバーとデータベースの連携などを設定する際に役立ちます。

らしいです。
さて、正常に完了すると、Webブラウザで下記アドレスにアクセスすると、Difyが起動します。

http://localhost/install

Difyが動き出した

やっと動き出しました。
いらん事しなけりゃ、簡単でしたが、結構悩んでしまいました。
Difyは、まだ触り始めですが、チャットだけでなく、AIを利用したいろいろなアプリを自分で作成きそうです。
次は、DifyとLM Studioを連携させて、ローカルLLMでのチャットボットを作ろうと思います。
ローカルであれば、セキュリティ的なリスクもかなり少なりますし、オンラインLLMを使用する場合の制限や課金も抑える事ができると思います。

]]>