Dify on EC2をやめて、きちんとAWSのマネージメントサービスを使う試み

docker-compose.yamlをまずは読み解いていく。

ものすごいコンテナ数があるけど、.env.exampleを見てわかる通り初期状態はweaviateだけ有効。

COMPOSE_PROFILES=${VECTOR_STORE:-weaviate}
https://github.com/langgenius/dify/blob/main/docker/.env.example#L697

つまるところ、デフォルトで起動するのは以下のコンテナたち。

ssrf_proxyは、SSRF攻撃対策で用いられている。
SSRF攻撃はざっくりいうと、想定外のホスト, ポートにアクセスされる攻撃のこと。
例えば、EC2に紐づいているRDSとか。

sandbox環境などはコードを実際に動かすから、想定外環境にアクセスされやすい。
そこで、予め許可するリストや許可しないリストを明示しておこうぜ。って用途。
多分なくても動くけどあった方が安心そう。

ssrf_proxyはAWSならSGで多分どうにかなる。
nginxもELBをうまく使えば多分どうにかなる。

ってことで、最低限やらなければいけないのは以下のコンテナ等。

一番厄介そうなのは、weaviateとかかなぁ。

ただ、これに関していうとサービスレベルでOpenSearchに対応しているから、多分そっちを使った方が楽。
性能は別にして、もっと楽なのはpgvectorを使うこと。
RDS for PostgreSQLならモジュールが使える。

ということで、以下を構築していく。

公式が、docker-compose.yamlを提供してくれているので、この記述を元にECS用のdocker-compose.yml作る方が楽そうだよなぁの顔。