DifyをAzure上に構築するこちらの 「dify-azure-terraform」 を参考に、学習がてら CDK for Terraformで書き直してみました。せっかくなので備忘録として記録を残します。そして書き直したリポジトリはこちらです。因みにデプロイしたDifyの動作確認などは細かくおこなってません🙇
全体の概要
書き直しながらAzureの構成は大まかに以下のようになっていることが分かりました。
そして、ただ書き直すだけではもったいないので、一部、Azure Key Vaultでシークレットを管理するようにしました。が...PostgreSQLのパスワードだけで、他のプライマリキーなどは手を付ける前に力尽きました...
-
Virtual Network
- ACA Subnet (10.0.16.0/20): Azure Container Apps 用
- Private Link Subnet (10.0.1.0/24): Private Endpoint 用
- PostgreSQL Subnet (10.0.2.0/24): PostgreSQL 用
-
Azure Container Apps
- Nginx: リバースプロキシ
- Web: フロントエンド
- API: バックエンド
- Worker: 非同期処理用ワーカー
- Sandbox: ユーザーのコード実行環境
- SSRF Proxy: プロキシサービス
-
データストア
- PostgreSQL Flexible Server（PgVector 拡張機能付き）
- Azure Cache for Redis
- Storage Account
- Blobコンテナ
- ファイル共有 (コンテナからマウント)
-
監視
- Log Analytics: コンテナアプリのログ収集と分析
-
シークレット
- Azure Key Vault (PostgreSQLのパスワードだけ)
各コンポーネント間を図にすると以下のような感じになっていると理解しました。
※PostgreSQLやRedisは省略
Azure ファイル共有でUploadしたNginxやSquidのコンフィグファイルをContainer Appsからマウントしており、その中のsquid.confを見るとプロキシサーバーはSSRF (Server-Side Request Forgery) プロキシとして動作し、Sandboxコンテナからの外部向けリクエストを制御していることが分かりました。
また、ポート8194をリバースプロキシ(アクセラレータモード) としてsandboxに転送する設定が書かれています。環境変数 CODE_EXECUTION_ENDPOINT が http://sandbox:8194 となっている部分を http://ssrf_proxy:8194 に変更しポートを開けることで、sandbox へのインバウンドも Squid 経由にする。といった事を見越しているのだろうと考えています（間違っているかもしれませんが…）。
- 以下参考
さいごに
最終的には、ほぼ写経みたいな感じになってしまいましたが、何がどうなっているのかな～という感じで書き直していったのでAzureの構成やDifyに関しての解像度は少し上がった気がしてます。あと、Azure with CDKTF 楽しいです。