Docker | じじぃの引出し https://www.kazuban.com/blog なにかしら、皆さんの参考になれば幸いです！ Mon, 16 Mar 2026 04:04:27 +0000 ja hourly 1 https://wordpress.org/?v=7.0 https://www.kazuban.com/blog/wp-content/uploads/2020/05/cropped-ICON-1-32x32.png Docker | じじぃの引出し 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を活用した実践例として、このやり取りもご参考にしていただければ幸いです。

]]> WSLのUbuntu24.04にDockerEngineをインストール。 https://www.kazuban.com/blog/wsl-ubuntu-dockerengine/ Tue, 22 Apr 2025 11:59:02 +0000 https://www.kazuban.com/blog/?p=10895 以前の記事では、「WSL」を構築し、Windowsアプリの「Docker Desktop」をインストールし、そこに「Dify」をクローン化して起動させました。

話題のDifyをインストールしてみた。失敗談あり。
話題のDifyをローカルインストールしてみました。普通にやれば何てことない作業ですが、余計な事したので時間がかかってしましました。
www.kazuban.com
2025.03.15

この状態では、「WSL」環境には、別途Linuxはインストールされていません。
「wsl -l -v」コマンドで確認できます。

PS C:\Users\hoge> wsl -l -v
  NAME              STATE           VERSION
* docker-desktop    Running         2

現在は、仮想環境として「Docker Engine」のみが動作し、そのコンテナとして「Dify」が動作しています。
この状態でも、「Dify」を利用する場合には問題ありませんが、せかっくの「WSL」なので「ubuntu」環境に「Docker」を構築し、「Dify」コンテナを構築し直そうと思います。
また、windowsアプリ「Docker Desktop」は、ライセンス的に完全オープンではありませんし、「Dify」もLinuxとの組み合わせのほうが、貧弱スペックマシンでは、パフォーマンスが向上しそうな気がしています。

Docker Desktop と WSLを完全アンインストール

再度、クリーンな状態から再インストールしたい場合もあると思います
gemini君に教えてもらった、クリーンインストール方法をメモしておきます。

Docker Desktop のアンインストール

★Docker Desktopのアンインストール
1. 「設定」アプリを開く:
　Windowsキー + Iキーを押すか、スタートメニューから「設定」を選択します。
2. 「アプリ」を開く:
　「アプリ」をクリックします。
3. 「アプリと機能」を開く:
　左側のメニューから「アプリと機能」を選択します。
4. Docker Desktopを選択してアンインストール:
　アプリの一覧から「Docker Desktop」を見つけて選択し、「アンインストール」をクリックします。
　画面の指示に従ってアンインストールを完了させます。

★ 関連するファイルの削除 (オプション)
Docker Desktopのアンインストール後、残りのファイルを手動で削除することで、より完全にアンインストールすることができます。

1. 以下のフォルダを削除:
　`C:\Program Files\Docker`
　`C:\ProgramData\DockerDesktop`
　`C:\Users\<ユーザー名>\AppData\Local\Docker`
　`C:\Users\<ユーザー名>\AppData\Roaming\Docker`
2. Hyper-Vを無効化 (Docker DesktopでHyper-Vを使用していた場合):
　「コントロールパネル」>「プログラム」>「Windowsの機能の有効化または無効化」を開きます。
　「Hyper-V」のチェックボックスをオフにして、「OK」をクリックします。
　コンピュータを再起動します。
3. WSL 2を無効化 (Docker DesktopでWSL 2を使用していた場合):
　管理者としてPowerShellを開きます。

　`wsl --unregister docker-desktop`と`wsl --unregister docker-desktop-data`コマンドを実行します。
　「コントロールパネル」>「プログラム」>「Windowsの機能の有効化または無効化」を開きます。
　「Linux用Windowsサブシステム」のチェックボックスをオフにして、「OK」をクリックします。
　コンピュータを再起動します。
4. 環境変数の削除 (Docker関連の環境変数を設定していた場合):
　「システム環境変数の編集」を検索して開きます。
　「環境変数」ボタンをクリックします。
　ユーザー環境変数とシステム環境変数から、Dockerに関連する変数を削除します。
★注意点:
　上記のフォルダやファイルは、環境によって異なる場合があります。
　レジストリを編集する場合は、誤った操作をするとシステムに問題が発生する可能性があるため、注意が必要です。
　Docker Toolboxを使用していた場合は、VirtualBoxもアンインストールする必要があります。

wslを完全に削除する

★ WSLディストリビューションのアンインストール
　WSLに、既にLinuxディストリビューションがインストールされている場合、
　まず、これらを個別にアンインストールします。
1. 管理者権限でPowerShellまたはコマンドプロンプトを開きます。
2. `wsl --list --verbose` または `wsl -l -v` コマンドを実行し、インストールされているディストリビューションの一覧と名前を確認します。
3. `wsl --unregister <ディストリビューション名>` コマンドを実行します。
　例：`wsl --unregister Ubuntu-24.04`
4. 他のディストリビューションに対しても同様の手順を繰り返します。
**補足:**
　ディストリビューションをアンインストールすると、そのディストリビューションに関連付けられたすべてのデータが削除されます。
　必要なデータがある場合は、事前にバックアップしてください。
　Microsoft Storeからインストールしたディストリビューションは、通常のWindowsアプリと同様にアンインストールすることも可能です。

★WSL機能の無効化
　ディストリビューションをアンインストールした後、WSL機能を完全に無効化することもできます。
1. 「コントロールパネル」>「プログラム」>「Windowsの機能の有効化または無効化」を開きます。
2. 「Windows Subsystem for Linux」と「仮想マシン プラットフォーム」のチェックボックスをオフにします。
3. 「OK」をクリックし、コンピューターを再起動します。
**補足:**
　WSL機能を無効化すると、すべてのWSL関連機能が利用できなくなります。
　Hyper-Vを有効にしている場合は、Hyper-Vも無効にする必要があります。
**その他の注意点**
　 WSL関連のファイルやフォルダが残っている場合は、手動で削除することも可能です。ただし、システムの重要なファイルを誤って削除しないように注意してください。
　レジストリを編集する場合は、誤った操作をするとシステムに問題が発生する可能性があるため、注意が必要です。

これらの手順に従うことで、WSLを完全に削除することができます。

ハードディスクのチェック

古いPCにインストールしていると、ハードディスクの調子が悪いのか？WSLが正常にインストールできない事がありました。
Windows付属のチェッカーで回復する可能性がありますので、メモしておきます。

★システムファイルチェッカー（SFC）の実行:
システムファイルの破損を修復します。
管理者権限でコマンドプロンプトを開き、
「sfc /scannow」と入力して実行。
★DISMコマンドの実行:
SFCで修復できないシステムイメージの破損を修復します。
管理者権限でコマンドプロンプトを開き、
「DISM /Online /Cleanup-Image /RestoreHealth」と入力して実行。

WSLにUbintu24.04をインストール

「Docker Desktop」と「WSL」のアンインストール方法を紹介しました。
今回は、WSLに「Ubuntu24.04」を構築し、「Docker Engine」環境を構築しますが、まだ「Docker Desktop」の環境は残しておきたいので、Windowsに新しいユーザーアカウントを作成し新しい環境で作業したいと思います。

Windows新しいアカウント作成

新しいユーザーの作成方法は、ネット上に情報がありますので、検索してみてください。
新しいユーザーでサインインし、新たに「WSL」環境を構築する場合では、こちらを参考してしてください。
新しいユーザーでサインインした初期状態では「wsl -l -v」で確認すると、なにも環境がないのがわかります。

PS C:\Users\hoge2> wsl -l -v
Linux 用 Windows サブシステムにインストールされているディストリビューションはありません。
この問題を解決するには、以下の手順に従ってディストリビューションをインストールしてください:

'wsl.exe --list --online' を使用して利用可能な配布を一覧表示する
および 'wsl.exe --install <Distro>' を使用してインストールしてください。

Ubuntu24.04インストール

いよいよインストールを始めますが、２つの方法
「Microsoft Store 経由」と「wsl コマンド経由」があります。
どちらでもいいと思いますが、アンインストールなどアプリの管理は「Microsoft Store 経由」のほうが簡単です

インストール自体はどちらも、簡単です。

「Microsoft Store 経由」
・Microsoft Store を開き、「Ubuntu 24.04」を検索。
・ 「入手」をクリック。
・ インストールが完了したら、「起動」をクリックします。

「wsl コマンド経由」
・PowerShell またはコマンドプロンプトを管理者権限で開く。
・「wsl --list --online」　でLinux ディストリビューションが一覧表示できる
・希望のディストリビューションをインストール
・「wsl --install -d Ubuntu-24.04」
・インストールが完了後「Ubuntu」起動

ユーザーとパスワード設定

「ubuntu」の起動は、「Microsoft Store 経由」であれば、「スタートメニュー」にアイコンが作成されています。
「wsl コマンド経由」の場合は、ターミナルを起動し「wsl」コマンドで起動できます。
「ubuntu」の最初の起動では、Unixユーザ名の作成を求められます。
特に、WIndowsユーザーと同じ必要はないので、適当なユーザー名とパスワードを設定します。

・
Enter new UNIX username: hoge2
New password:
Retype new password:
passwd: password updated successfully
Installation successful!
・

root パスワード設定

こちらでもレポートしましたが、「ubuntu」では管理権限が必要な場合には「sudo」コマンドで行い、「root」ユーザーは極力使わないを基本にしているみたいです。
したがってデフォルトでは「root」パスワードは設定されていません。
ただ、管理者権限が必要なコマンドやフォルダのアクセスなど、設定やメンテナンスの場合一回一回「sudo」を使うのは面倒です。
「root」での作業は、注意が必要ですが、管理者コマンドの連続の場合、筆者は使用しています。
その場合、筆者は「root」パスワードを設定しています。
「root」パスワードは、「sudo passwd root」コマンドで設定できます。

$ sudo passwd root
[sudo] password for hoge2:
New password:
Retype new password:
passwd: password updated successfully

設定されました。
「root」になりたい時には、「su」コマンドを使用します。
「root」になると「$」プロンプトが「#」に換わります。
元のユーザに戻るには「exit」コマンドを実行します。
現在のユーザーは「whoami」で確認できます。

$ su
Password:
# whoami
root
# exit
exit
$ whoami
hoge2

パスワード入力なしで「sudo」を実行する

通常は「sudo」コマンドを使用しますが、いちいちパスワードを聞かれるので、結構面倒です。
パスワードなしで「sudo」を実行できる設定は「visudo」コマンドの特殊なエディターで設定します。

$ sudo visudo
・
・
# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL
・
## Same thing without a password
%sudo  ALL=(ALL)       NOPASSWD: ALL
・
・

開いた設定ファイルに、
「%sudo ALL=(ALL) NOPASSWD: ALL」
この設定値を追加し上書き保存します。
この設定で、「sudo」グループのユーザーは「sudo」が実行でき、パスワードが不要になります。
ただし、「sudo」コマンドを実行できるのは、「sudoグループ」登録されているユーザーのみなので、現ユーザーを「suduグループ」に登録します。

$ sudo usermod -aG sudo $USER
$ newgrp sudo

この設定で、現ユーザーは「sudoグループ」に登録され「sudo」コマンドが実行できます。

Docker Engine をインストール

「ubuntu」を操作できるユーザー設定が完了したので、いよいよ「Docker Engine」をインストールしていきます。

古いバージョンのアンインストール

古いバージョンがインストールされている可能性がある場合には、念のため次のコマンドを実行してアンインストールしておきます

$ sudo apt-get remove docker docker-engine docker.io containerd runc

完全に削除するには、次のコマンドでボリュームやイメージデータを削除します

$ sudo rm -rf /var/lib/docker
$ sudo rm -rf /var/lib/containerd

Docker Engine インストール手順（Ubuntu 編）

・依存パッケージのインストール

$ sudo apt-get update
$ sudo apt-get install -y ca-certificates curl gnupg lsb-release

・ディレクトリを作製し、Docker の公式 GPG 鍵を追加

$ sudo mkdir -p /etc/apt/keyrings
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

・Docker リポジトリを追加

$ echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

・パッケージ更新＆インストール

$ sudo apt-get update
$ sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

・Docker の動作確認

$ sudo docker run hello-world

↑ これで「Hello from Docker!」が出れば OK！

・dockerコマンド実行は、「sudo」 が必要ですが、実行ユーザーがdockerグループであれば、不要になります。
下記コマンドで、douckerグループに参加させます。

$ sudo usermod -aG docker $USER
$ newgrp docker

コンテナの削除

動作確認で「hello-world」コンテナを作製しましたが、コンテナ削除操作を覚書しておきます。

★コンテナの一覧を表示
$ docker ps -a

★コンテナ削除
$ docker rm <CONTAINER ID または NAMES>

★hello-world イメージ自体を削除
★動作している場合に、エラーになるので、コンテナ削除後にイメージ削除
　 ※"hello-word"のCONTAINER IDを表示する
　 $ docker ps -a -q --filter ancestor=hello-world
$ docker rm $(docker ps -a -q --filter ancestor=hello-world)
$ docker rmi hello-world

★全てのコンテナと全てのコンテナイメージを削除
  -f オプションを付加すると、強制的に削除されるので注意
$ docker rm -f $(docker ps -a -q)
$ docker rmi -f $(docker images -a -q)

★ボリュームの削除: 全ボリュームを削除します。
$ docker volume rm $(docker volume ls -q)

★ネットワークの削除: ネットワークを削除します。
$ docker network rm $(docker network ls -q)

★キャッシュのクリア: 必要に応じて、Dockerのキャッシュをクリアします。
$ docker system prune -a

★すべての停止中コンテナと未使用イメージのみを一掃
　実行中のコンテナは削除しない
$ docker system prune

WSL、Ubuntu24.04、Docker Engine、環境完了

WSL、ubuntu、docker の環境が出来上がりました。
次に、dockerでDifyの環境をセットアップする予定ですが、windowsアプリの「docker Desktop」の場合は、ある程度アプリがやってくれそうですが、今回は「Ubuntu24.04」環境に「Docker」をインストールしたのでネットワーク環境が複雑になりそうな気がしています。

ubuntu、docker の通信状態

windows環境とwsl環境で、通信状態を調べてみます。

Windowsターミナルで、ipconfig コマンド

PS C:\Users\hogehoge2> ipconfig
Windows IP 構成
・
Wireless LAN adapter Wi-Fi:
   接続固有の DNS サフィックス . . . . .:
   IPv6 アドレス . . . . . . . . . . . .: 240f:110:2717:1:f62b:3484:aafb:ade5
   一時 IPv6 アドレス. . . . . . . . . .: 240f:110:2717:1:b1bf:2b2:5d5d:2a98
   リンクローカル IPv6 アドレス. . . . .: fe81::84c1:d56e:ece:1ad8%15
   IPv4 アドレス . . . . . . . . . . . .: 192.168.0.94
   サブネット マスク . . . . . . . . . .: 255.255.255.0
   デフォルト ゲートウェイ . . . . . . .: fe81::fab7:98ff:fe4b:95b8%15
・                                          192.168.0.1
イーサネット アダプター vEthernet (WSL):
   接続固有の DNS サフィックス . . . . .:
   リンクローカル IPv6 アドレス. . . . .: fe81::f749:f04d:c08e:932%44
   IPv4 アドレス . . . . . . . . . . . .: 172.31.224.1
   サブネット マスク . . . . . . . . . .: 255.255.240.0
   デフォルト ゲートウェイ . . . . . . .:

WindowsホストマシンIPアドレス、家庭内LAN：
192.168.0.94/24

WSL Windows側IPアドレス、WindowsとWSL間の通信するためのゲートウェイ：
172.31.244.1/20

wslで、ip a コマンド

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:c8:2e:42 brd ff:ff:ff:ff:ff:ff
    inet 172.31.226.6/20 brd 172.31.239.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe81::215:5dff:fec8:2e42/64 scope link
       valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether ba:b5:41:49:d7:3c brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever

WSL Docker側IPアドレス、WSL環境はこのアドレスで、Windowsと通信：
172.31.226.6/20

docker0 のIPアドレス、Dockerがコンテナにネットワーク機能を提供するためにWSL 2のLinux環境内に作成するブリッジネットワークインターフェースです
172.17.0.1/16

ネットワーク環境・・複雑ですね

次回、DockerにDifyのコンテナを作成しようと思います。
LAN内でも別のPCからのアクセス可能にしたいので、設定状況をレポートします。

]]>