[FEATURE]Docker Runで利用可能にすることでハードルを下げる

[nishio]

(by Devin)

背景

現在のワークフローでは各ユーザーが個別にDockerイメージをビルドする必要があります。より使いやすいワークフローとして、docker runコマンドだけで利用できる設計への改善が提案されています。

目的

• ユーザーの利用ハードルを下げる
• カスタマイズ可能性を維持しながら、シンプルな利用方法を提供する
• 独自データでの分析を容易にする

設計要件

1. データの取り扱い

独自データの利用

• ボリュームマウントによるデータ受け渡し

docker run -v /path/to/mydata:/app/data ...

• マウントポイントの標準化
• データの入出力ディレクトリ構造の明確化

2. 設定のカスタマイズ

環境変数による設定

• プロンプトのカスタマイズ

docker run -e CUSTOM_PROMPT="新しいプロンプト" ...

• その他の設定パラメータ
  • OPENAI_API_KEY
  • その他のモデル設定
  • 出力形式の設定

3. ユースケース別の実行方法

1. サンプルデータでの実行

docker run broadlistening:latest

2. 独自データでの分析

docker run -v /path/to/mydata:/app/data -e CUSTOM_PROMPT="プロンプト" broadlistening:latest

検討事項

1. データの構造化

   • 入力データの配置場所
   • 出力データの保存場所
   • 一時ファイルの取り扱い

2. 設定の優先順位

   • デフォルト値
   • 環境変数による上書き
   • コマンドライン引数の検討

3. エラーハンドリング

   • データ不足時の対応
   • 設定ミス時のフィードバック
   • トラブルシューティングガイド

次のステップ

1. 詳細設計の作成
2. プロトタイプの実装
3. ドキュメントの整備
4. ユーザーテストの実施

関連PR/Issue

• PR Dockerfileの改善 #57: Dockerfileの改善

[nishio]

カスタマイズのためのフォルダー(config, input, output, prompt)はすでに存在している上に現在のシステムはその存在を仮定して実装されているからボリュームマウントだけでは解決しないと思う。任意場所から各ファイルを読めるようにする設計変更が必要。それ自体は有益な気はする。

CUSTOM_PROMPT="プロンプト"

プロンプトは1つの分析でもいくつもあるし、その他の設計項目もあるし、階層化されているので、それをJSONでのconfigではなく環境変数でやるというのは無理があると思う。

どうすればdocker runだけで実行可能になるかに関してはあまり自明ではないのできちんと設計してから修正する必要がありそう。

[nishio]

ここの設計変更が終わった後で、そのイメージをどう公開するかについてはこちら
#60

[nishio]

考えたこと

• uvパッケージマネージャー採用の検討 #58 uvに変えて大丈夫かどうかなど誰もわからない
• 一旦mainにマージしないでCI用のブランチでCIしてpushするところまで作ってはどうか
• 現在進行中の新機能開発が落ち着いたらCI用のブランチ に mergeして、CIがこけないことを確認してからmainにmergeしなおす
• これによって、以降CIによってなんかおかしくなったときに気づきやすくなる

つまりエンドユーザに使いやすくすることの前にまず CI & test を作るという路線

[nishio]

上記の方向で良さそうとのことだったのでCI用のブランチを作ってそこにマージします

[nishio]

https://github.com/takahiroanno2024/anno-broadlistening/tree/feature-ci-docker