Dify 1.19.0、Composeは2.35.0以上が必須に

自社のサーバーでDifyを動かしているなら、上げる前にdocker compose versionで版を見る。11月4日に出た1.19.0は、Docker Compose 2.35.0以上を必須にした。リリースノートは、設定のファイル（.env）での上書きが正しく効く最低の版だと説明している。

Difyは、AIを使うアプリやワークフローを画面で組み立てるオープンソースのツールだ。1.19.0の目玉は、ワークフローの中から呼んだ別のワークフローの動きまで、外部の監視ツールでたどれるようになったことにある。運用する側が気にしたいのは、上げ方の手引きにある7つの注意だ。

上げる前に見る3つのこと

まず、バックアップを取る。手引きは、データベース、ベクトルの保存先、アップロードされたファイル、エージェントの作業領域、秘密の値、設定のファイルを残すよう求めている。1つの構成で動かしているなら、止める時間を取って上げる。

次に、部品をそろえて上げる。API、ワーカー、Web、エージェントの部分、サンドボックスの画像はどれも1.19.0にし、プラグインを動かす部分は0.6.14-localにする。1.18.0より前から上げる場合は、1.18.0の手引きも合わせて読む。

もう1つ、設定のファイルの置き場所も変わった。既定の値はdocker/envsの下の.defaultsのファイルから読み込まれ、変えたい値はサービスごとの.envに書く。これまでのshared.envもそのまま読まれる。ただし、新しいapi-worker.envと同じ項目があれば、新しい方が勝つ。手引きは、空のままの項目や、古い見本を写したときの値が残っていないかを見直すよう勧めている。

アプリの書き出しは形式v2に

1.19.0から、アプリを書き出すと、すべて新しい形式v2のパッケージになる。ワークフローを部品として呼ぶ「Workflow Tools」も、パッケージに一緒に入るようになった。パッケージは.ifpkgのファイルで、呼び出し先のワークフローは、そのとき結び付けていた版のまま入る。読み込む側に同じツールがあれば使い回し、無ければ作り直して登録する。

注意したいのは、受け取る側だ。古い版のDifyは、v2のパッケージを読み込めないことがある。開発用と本番用でDifyを分けている会社は、受け取る本番の方を先に1.19.0へ上げる。逆の順にすると、開発で作ったアプリを本番へ移せない期間ができる。なお、これまでのv1のパッケージは1.19.0でも読み込め、YAMLでの書き出しも残る。ただし、YAMLにはWorkflow Toolsの中身は入らない。

止めずに上げるときの注意

止めずに順に上げる場合は、トレースを送る仕事の行き先（キュー）に気をつける。新しい仕事はops_trace_v2に入るため、API、ワーカー、Beatの設定をそろえる。古いキューのops_traceは、古い仕事がすべて終わるまで消さない。

データベースの変更は6つある。保存先を掃除するための索引を作るときは、データを読み直すため、ディスクに負荷がかかる。トレースの設定が重複していた場合は、最も新しいもの以外が消え、元に戻しても戻らない。そのため、上げる前のバックアップは必ず取っておく。

セキュリティの面では、モデルの提供元の有効と無効を切り替えられるのは、所有者か管理者だけになった。データセットへのアクセスのトークンも、結び付けたデータセットしか一覧に出なくなった。権限を細かく分けて使っている会社には、上げる理由が増えたと言えるだろう。

上げる前と上げるときの手順を並べると、次の4つになる。

1. docker compose versionで2.35.0以上かを見る
2. データベースと保存先と設定のファイルをバックアップする
3. 本番と開発の両方を、受け取る側から順に1.19.0へ上げる
4. 止めずに上げるなら、トレースのキューの設定をそろえる

ほかの自動化のツールとの違いは、1.18.0のニュースで、n8nとMicrosoft Power Automateと並べている。