以前、「Dify OSSをRailwayに構築してみた」という記事を書きました。
あの時は、
- ドメイン設定
- Railway側の障害
- なぜかログインできない問題
などなど、なかなか盛りだくさんでした。
結局得られた教訓はひとつ。
「動く」と「運用できる」は別物。
そんなわけで今回は方針転換です。
RailwayのようなモダンなPaaSはいったん横に置いて、もっとシンプルに考えることにしました。
普通のLinuxサーバに置けばいいのでは？
使ったのは AWS Lightsail。
そして結果から言うと、
拍子抜けするほど普通に動きました。
本当に普通です。
Dockerを起動して、設定して、アクセスする。
それだけ。
前回あれだけ苦労した身からすると、
「え、終わり？」
という感想しか出てきませんでした。
むしろ何か見落としているんじゃないかと疑ったくらいです。
今回の構成
今回やったことはこんな感じです。
Lightsailを作って、
Dockerを入れて、
Difyをgit cloneして、docker compose up -d
あとはAPIキーを設定して、ドメイン付けて、WordPressに埋め込む。
文字にするとこれだけです。かなり王道なLinuxサーバ構築ですね。
逆に言うと、「特殊なことは何もしていない」というのが今回のポイントだったりします。
前回のRailway構築では環境固有の挙動に振り回されましたが、今回はサーバ上でDockerを動かしているだけなので、トラブルが起きても調べる場所が分かりやすい。
結果的に、こちらの方がずっと気楽でした。
まずはLightsail
今回使ったのは：
- AWS Lightsail
- Ubuntu 24.04
です。
正直、最初は
「EC2より簡単とはいえ、Linuxサーバ立てるの面倒そうだな…」
と思っていました。
でも実際やってみると、Railwayより何が起きてるかわかるので、逆に安心感がありました。
Docker環境を入れる
まずはDocker関連。
sudo apt update
sudo apt install -y git docker.io docker-compose-plugin
sudo systemctl enable docker
sudo systemctl start docker
sudo usermod -aG docker ubuntu
ここで一度ログアウト / ログイン。この辺になると急に、
「あ、いま俺、普通にサーバ構築してるな…」
感が出てきます。
Dify OSSをclone
ここはかなりシンプルでした。
git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env
docker compose up -d
すると…
普通に起動。
え？
終わり？
Railway時代の苦労は…？
というぐらい普通に立ち上がりました。
しかし、2GBメモリでは甘かった
今回使ったLightsailは2GBメモリ。最初は「まあDifyだけだし余裕でしょ」
と思っていたのですが、甘かったです。
Difyログインが不安定だったので、途中で
free -h
を見たら、RAMがかなり埋まっていました。
Redis、Postgres、API、Worker…
Dify、思ったより普通に重い。
ということで swap を追加。
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
するとかなり安定。
Linux触ってる感が増してきます。
HTTPS化で nginx が殴り合いを始める
ここで次の壁。
Dify OSS側のDocker nginxがPORT、
80
443
を使っていました。一方で、OS側でも nginx を使いたい。
nginx vs nginx
開戦です。そこで、Dify側の .env を変更。
EXPOSE_NGINX_PORT=8080
EXPOSE_NGINX_SSL_PORT=8443
外側のOS nginxが80/443を受け、内部的にDifyの8080へ流す構成にしました。
つまり、
・OS側nginx：外部公開・HTTPS終端・リバースプロキシ
・Dify側nginx：Docker内のDifyアプリへの入口
という役割分担です。
外側nginxでリバースプロキシ
今回は、取得したドメイン
chat.******.jp
をDifyへ流す構成。
nginx側はこんな感じ。
server {
server_name chat.******.jp;
client_max_body_size 50m;
large_client_header_buffers 4 32k;
client_header_buffer_size 16k;
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}ここまで来ると、「AIアプリ構築記事」のはずなのに、nginx 記事っぽいな
certbot、君だったのか
HTTPS化では certbot を使いました。
sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d chat.testdifytest.jp
途中で、
「certbotって何者だっけ…？」となりましたが、
Let’s Encrypt の証明書取得をかなり自動でやってくれる便利なやつです。
本当に便利。
昔のSSL設定の苦労は何だったのか。
そしてAWS側Firewallでハマる
そして最後に待っていたのが、まさかのFirewallでした。
必要だったのは、
- HTTP (80)
- HTTPS (443)
- SSH (22)
この3つ。
特に HTTPS の 443 を開ける必要があります。
nginxも動いている。
certbotも成功している。
設定ファイルもそれっぽい。
なのに繋がらない。
「え、またDifyが何かやってる？」
と思いながら30分ぐらい眺めていたのですが、原因はシンプルでした。
Firewall閉まってました。
インフラあるあるですね。
複雑そうなところを疑っていたら、実は一番単純なところだったパターンです。
とはいえ、Lightsailの場合はAWSコンソールからポチポチ設定するだけなので数分で解決しました。
原因が分かった瞬間の脱力感はなかなかのものでした
ナレッジ投入でまたnginxが怒る
Difyに約8MBのMarkdownをアップロードしたところ、見事に失敗しました。
最初は
「またDifyか？」
と思ったのですが、ログを見てみると原因は一発でした。
client intended to send too large body
完全にお前でした。
ということで nginx の設定に
client_max_body_size 50m;
を追加。
無事アップロード成功です。
最近こういうことが本当に増えました。
AIを触っているつもりなのに、気付くと nginx のログを読んでいる。
AIエージェントを作っているつもりなのに、
気付くと Linux と Docker と nginx を触っている。
結局のところ、AIの周りには昔ながらのインフラ技術が山ほど残っています。
そしてトラブルの原因も、だいたいそっちにあります。
まとめ
今回やってみて一番感じたのは、
「モダンそうなものが、必ずしも簡単とは限らない」ということでした。
Railwayは便利です。
数クリックで環境ができるし、見た目も洗練されています。
ただ、その分ブラックボックスな部分も多く、
- どこで問題が起きているのか分かりにくい
- 切り分けに時間がかかる
という場面もありました。
一方で Lightsail は驚くほど普通です。
普通のUbuntu。
普通のDocker。
普通のnginx。
特別なことは何もありません。
でも、だからこそ何か問題が起きたときに原因を追いやすい。
ログを見れば分かるし、設定ファイルも見えるし、サーバの中で何が動いているのかも把握できます。
派手さはありませんが、個人的にはこちらの方が安心して運用できそうだと感じました。
少なくとも今回のDify環境については、
「おしゃれなPaaSで苦労する」より、
「普通のLinuxサーバで普通に動く」
の方が幸せだった気がします。
後編を書くつもりだった
ちなみにこの記事、前回の記事のタイトルが「前編」だったので、本来なら「後編」に続くはずでした。
ところが気づいたら、
Railway
↓
Lightsail
へ転職していました。もう後編ではありません。別ルートです。
映画でいうと、「前作主人公が2作目で急にいなくなった」みたいな感じです。
ちなみに今回、Dify構築より nginx を触っていた時間の方が長かった気がします。
最近のAI構築、だいたい最後は nginx 触ってる説あります。
あと AWS を触るたびに思うのですが、
Lightsail
EC2
Route53
CloudFront
あたりの名前、毎回どれが何なのか一瞬わからなくなります。
そのうち、
Moonlight
Sunrise
Thunderbolt
とか出てきても普通に信じそうです。
そんなこんなで、今回の環境は今のところかなり安定しています。
少なくとも、
「朝起きたらなぜかログインできなくなっていた」
みたいなことは起きていません。
しばらくはこの構成で遊びながら、Difyそのものの検証を進めていこうと思います。
そしてもし本当に続きが書けたら、今度こそ「後編」です。
