Dify、Docker設定のマージ修正を統合　サービス環境変数の上書き不具合に対応

Difyは11月3日、Docker環境変数の修正をメインブランチにマージし、セルフホスト環境で「設定ファイルを変更しても、コンテナがデフォルト値を使い続ける」という不整合に対処した。この問題は前日に報告され、メインブランチとデフォルトの1.18.0イメージを使った環境で再現したものだ。そのため、既存のすべてのバージョンが影響を受けるとは限らない。問題報告

報告に挙げられた例では、nginxのアップロード上限を200Mに設定しても、実際には100Mのままだった。また、サンドボックスの実行タイムアウトを120秒に設定しても、コンテナ内のWORKER_TIMEOUTは15秒のままだった。さらに、プラグインデーモンが共通設定を読み込まず、想定されるデータベースとRedisの接続値が不足していた。ワークフローの運用では、こうした不整合により、ファイルのアップロードやコードの実行が誤ったしきい値で失敗するおそれがある。調査時に、アプリケーション自体の制限だと誤認することにもつながりかねない。再現手順と結果

技術的なポイントは、Composeの変数補間とコンテナ環境変数の読み込みが別の段階で行われることにある。Dockerの公式ドキュメントでは、Composeのenvironment設定はenv_fileより優先されると明記されている。前者がすでにデフォルト値に解決されている場合、サービス定義内のカスタム値で上書きできない。環境ファイルを追加するだけでは、コンテナに利用者が指定した値が渡るとは限らない。Dockerの優先順位に関する説明

今回の修正では、同梱のサービス用テンプレートを.defaultsに変更し、任意の上書き値がコンテナの変数マッピングに反映されるようにした。また、プラグインデーモンの共通接続デフォルト値も補った。既存のサービス用.envのパスは維持され、ルートディレクトリの.envが引き続き最優先となる。ポートやマウントパスなど、Composeレベルの入力値は引き続きルート設定ファイルに記述する必要がある。修正内容

新しい設定を使うにはDocker Compose 2.35.0以上が必要だ。古いファイルに残っている意図しない空値も手動で削除する必要があり、ローカル設定は自動では書き換えられない。エンジニアリングチームはまずdocker compose configで解析結果を確認し、対象のリリースに修正が含まれているかを確かめる必要がある。確認時点でリリースページの最新バージョンは1.18.0だった。メインブランチへのマージだけでは、既存のイメージに修正が適用されたことにはならない。互換性要件、リリースページ