Update: [Dockerfile] 細かな調整

[5ym]

変更の種類

• 改善・リファクタリング（機能は追加されないが、動作やコードを改善する破壊的でない変更）

チェックリスト:

• 開発資料 と データベース設計 は読みましたか？
  • もともと自分用のメモですが、このプロジェクトの開発方針や設計などが記載されています。開発時の参考にしてください。
• Git のコミットメッセージは開発資料に記載のフォーマットになっていますか？（重要）
  • このプロジェクト上のコミットメッセージは、基本的に全てこのフォーマットに従って記述されています（文字数は問いません）。
  • 正しいフォーマットになっていない場合、force push で必ずコミットメッセージを変更してから送信してください。
• このプロジェクトのコーディング規約に従ったコードになっていますか？
  • コーディング規約は開発資料に記載されています。
  • そもそもコーディング規約と言えるほど大層なものではありませんが、一度目を通しておいてください。
• プルリクエストは master ブランチに送信されていますか？
  • release ブランチはリリースした時にしか更新されません。必ず master ブランチに送信してください。

説明

パスの記述が重複してましたので相対化しました。(WORKDIRを実行した時点でディレクトリが存在しなければ生成されるので先にWORKDIRを実行したほうがよいかと思われます)
dockerイメージ単体で利用した際アプリケーションのバージョンとあったconfigファイルがコンテナ側から取得できると便利なためコンフィグファイルをコンテナに追加しました。

動機とコンテキスト

[5ym]

@tsukumijima
別途ご相談なのですが、下記の個所をデフォルトでコメントアウトにしていただけないでしょうか。

そもそもintel iGPUすらない環境だと/dev/driすら存在しないためエラーで起動できません。デフォルトでコメントアウトが好ましいと思われます。

devices:
      - '/dev/dri:/dev/dri'

当方の環境だとdeploy以下を全てコメントアウトしないとmappingエラーが発生します。

    deploy:
      resources:
        reservations:
          devices:
            # - driver: nvidia
            #   capabilities: [compute, utility, video]

[tsukumijima]

再度のプルリクエストをありがとうございます。

Dockerfile に関しては私の書き方が悪かったですね…。
絶対パスで記述しているのはどこにコピーしているのかを一目で分かりやすくするための意図的なものだったと思いますが、追記を繰り返したからかコードフォーマットに一貫性がなくなってしまっていました。

815b05b にてコンテナ側のパスをすべて絶対パス指定に変更したほか、ディレクトリパスの末尾に / を付与するようにしました。また、プルリクエストでの変更のうち、WORKDIR の定義位置の調整と config.example.yaml をコピーする部分の変更を取り込んでいます。

当方の環境だとdeploy以下を全てコメントアウトしないとmappingエラーが発生します。

現状検証用の Linux 環境が Ubuntu 20.04 LTS (Intel Core i5-9400 (Intel UHD Graphics 630) / NVIDIA Quadro K2200) しかなく、実際に動作するかを検証しそびれていました…。
e6a190c にてインストーラーの実装とともに修正してあります。

そもそもintel iGPUすらない環境だと/dev/driすら存在しないためエラーで起動できません。デフォルトでコメントアウトが好ましいと思われます。

それはお使いの Linux PC 内に (Intel iGPU 含め) GPU が一つも搭載されていないということですか…？？？
VPS ですら /dev/dri には仮想グラフィックカードが置いてあったりしますし、/dev/dri には（NVIDIA GPU 含め）GPU が搭載されていれば例外なく何かしらのデバイスファイルが配置されるようなので、かなりイレギュラーな環境だと思います。

大半の Linux PC には GPU (Intel iGPU を含む) が最低ひとつは搭載されているであろうことを考慮すると、『デフォルトでコメントアウトが好ましい』とは到底考えられません。
最近のコミットで docker-compose.yaml 自体は Git 管理から外すようにしましたので、イレギュラーな環境で使っている人が手動でコメントアウトするべきと考えます。以前回答したようにリソースが足りないですし、イレギュラーな環境に合わせていたらキリがないので…。
インストーラーでの対応は確かにあった方がいいかもしれませんが、デフォルトでコメントアウトするつもりはありません。

プルリクエストとご報告ありがとうございました。

[5ym]

@tsukumijima
ご確認ありがとうございます。
確かに/dev/driにデバイスがないのは特殊な場合ですね自分の場合映像出力機構を持たないサーバなどで検証していたためエラーが発生していました。

設定ファイルの取り込みのほうがありがとうございます。こちら活用してコンテナからconfigファイルを取得して本家のconfigファイルと齟齬なく運用できそうです。下記更新しています。参考になればと思います。
https://github.com/5ym/docker-mirakurun-konomitv

[tsukumijima]

@5ym
1ec7cd0 にて、/dev/dri が存在しない環境でもインストーラーが動作するように修正しました。
ビルド済みのバイナリは https://github.com/tsukumijima/KonomiTV/actions/runs/3240413173 にありますので、ご確認いただければと思います。

[5ym]

@tsukumijima
メンションありがとうございます。
インストーラーの方も見させていただいているのですが、一部分だけ活用してセットアップするのも考えたのですが、難しそうです。
下記の様にオプションで一部を設定済みにできたら便利だと思うのですが、いかがでしょうか。

docker compose run --rm --entrypoint sh -e backend=Mirakurun  konomitv -c '.venv/bin/python ../installer/Installer.py'

そのほかの実装もあると思いますが、ご検討いただければ幸いです。

[tsukumijima]

@5ym
このインストーラーは、Nuitka でコンパイルされたスタンドアローン実行ファイルを、ホスト側の OS でダウンロード&実行することを想定しています（使い方はこちら参照）。
Docker 上で動かすことは全く想定していません。

./KonomiTV-Installer.elf install --use-docker --use-mirakurun --mirakurun-url http://localhost:40772/ --use-encoder QSVEncC  --capture-upload-folder E:\TV-Capture

将来的には ./KonomiTV-Installer.elf の実行時に、通常対話的に取得されるパラメータを上記のようなコマンドライン引数で指定して、サイレントインストールできるようにしたいとは考えています。

---

私としては、docker-mirakurun-konomitv のようなアプローチには極めて否定的ということはお伝えしておきます。
KonomiTV は Docker Compose で動かす場合も単独で起動することを想定しています。
また、将来的な設定ファイルに変更があった際の自動マイグレーションや自動アップデートを実現するため、0.6.0 のリリース後は　Docker Compose で動かす場合もインストーラー/アップデーターを利用するように案内する予定です。

「設定ファイルを手動で編集する」「設定ファイルを新しいものにマイグレーションする」といったオペレーションが入ると、どうしても（主に事前知識を知らない事や、単純ミスが原因で）インストールに失敗しがちです。
そしてインストールに失敗した場合に泣きつかれる先は私なので、こちらでインストーラー/アップデーターを整備してインストール/アップデートプロセスを自動化し、私が一番最適だと考えるインストール構成で、そのまま使っていただきたいというのが本音です。

ユーザーにとっても、複雑なインストール/アップデートが自動化されることで、いくつかの項目を対話的に入力するだけで済みます。これによりインストールが簡単になり、インストール成功率は格段に向上します。
私（開発者）としてもユーザーへのサポートコストを大幅に減らせる上に、インストール方法を説明するための長いドキュメント執筆に時間を掛ける必要がなくなるため、Win-Win の関係です。

もちろん OSS プロダクトですから、カスタム構成にされるのは各々の自由です。
ただ、私がせっかく簡単にインストール/アップデートができる方法を（大量の時間と労力を投じて: インストーラーの開発には既に1ヶ月以上掛かっている）準備しているのに、それを使わずに独自の方法で構成して、そして上手くいかなかったらヘルプを求められるということをとても懸念しています。

要するに「想定していない使い方をしてうまく行かなかったのを私に報告されても困る」という話です。

---

KonomiTV は「開発者でなくてもインストールやアップデートが簡単にでき、簡単に使える」ことがコンセプトのひとつですから、自分の好きなように構成をカスタムしたがるタイプの開発者とはもとより相性が悪いと思います。
そういう点では、開発者以外が使う事自体を全く考慮していない Mirakurun / Chinachu / EPGStation とは根本から設計思想が異なります。
KonomiTV のメインターゲットは（サイレントマジョリティである）「TVTest のインストールですら苦労していて、一般ユーザー」ですから、開発者よりも母数の多い一般ユーザーを優先したいです。

そうした層が潜在的にかなり多いことは、私のブログからの TVTest のビルド済みアーカイブのダウンロード数が数千を超えていること、私のブログ記事に設定方法に関してのヘルプを求めるコメントが日々届くことなどから確信を得ています。

『優れた技術へのアクセスが、一部の技術に詳しい人やエンジニアに制限されているのは純粋にもったいないし、一般の人でも優れた技術の恩恵が享受できるようにしたい』という思想から、かねてからビルド済みアーカイブの配布や、ブログでの解説記事の執筆などを善意で行ってきました。

---

さらに、KonomiTV はその性質上かなりトリッキーな技術や構成を多用しています。
できればトリッキーにはしたくなかったのですが、1年以上試行錯誤した結果、どうしてもトリッキーな構成にせざるを得ませんでした。
どう動作するのかをしっかり理解した上で、自己で完結する範囲で（私に頼らず）カスタムされる分には構いませんが、何も理解していないのにカスタムしようと試み、私に頼ろうとすることには正直憤りを感じざるを得ません。

たとえばこのリプライを書くのにもそれなりの時間を割いていますし、ブログのコメントしかり応対にはかなり時間を取られます。
もちろん返答する義務はないので適当に返したり無視することもできます。ただあいにく何か来たら中々断れないタイプなので、結局届いたコメントに対してすべて詳細にリプライを返してしまうことが多いです。
もとよりそうしたヘルプが届く状態自体が良いとは思えませんから、できるだけユーザーが私にヘルプを求めることなく使える方法の検討を重ねた結果、行き着いた先がインストーラー/アップデーターの開発と配布、という訳です。

---

…閑話休題。

上記（あるいは以前のプルリクでのコメント）のとおり、私は (Linux (Docker) も含めて) インストーラー/アップデーターを使って KonomiTV のインストール/アップデートを行うことが、ユーザーにとっても私にとっても一番最善だと考えています。

以前のプルリクでのコメントで説明したようにキャパシティの問題がありますから、ほかのインストール方法を公式にサポートすることはできません。
プルリクのマージも、（特にまだ安定しておらず、開発中の段階においては）プロジェクト全体に有益な変更でなければ受け取りづらいです。そちらからすればマージしてくれればそれで終わりかもしれませんが、私はマージした後もその機能が引き続く動作するように保守し続ける必要があるためです。
もちろん有益な変更であれば取り込みますが、使わない機能を追加されても保守がしんどくなるだけなので…。

申し訳ありませんが、ご了承いただければと思います。

[5ym]

@tsukumijima
リプライありがとうございます。
そこまで真面目に検討していただくことを想定した機能提案ではありません。

構築に関してなのですが、結局Linuxユーザはmirakurunを別途設定しなければいけないのですが、その点についてどうお考えなのでしょうか。
windowsに関してもEDCBなどの構築が必要であるのですが、どうでしょうか。

[tsukumijima]

@5ym

構築に関してなのですが、結局Linuxユーザはmirakurunを別途設定しなければいけないのですが、その点についてどうお考えなのでしょうか。

KonomiTV は DTV 関連のソフトウェアの中では最後発ですから、KonomiTV のインストールを試みる Linux ユーザーの大半は、すでに Mirakurun と EPGStation (あるいは Chinachu) を構築して稼働させていることが予想されます。
そうしたユーザーにとっては、docker-mirakurun-konomitv のようなアプローチだと docker-mirakurun-epgstation などで構築した環境を一度手放す必要があるため、むしろインストールしずらいでしょう。

今後新規に Linux (Docker) で DTV 環境構築を行う際も、今まで通り Mirakurun や EPGStation をインストールしたあと、別途 KonomiTV をインストールすれば良いだけの話です。実用上の問題はないと考えます。

windowsに関してもEDCBなどの構築が必要であるのですが

Linux 同様に、KonomiTV のインストールを試みる Windows ユーザーの大半はすでに EDCB を構築済みであることが予想されるため、さほど問題はないと考えます。
確かに EDCB 側のアップデートや事前の設定が必要にはなりますが、それはユーザー自身が行うべき領域で、いずれにせよ私（インストーラー）が関与すべき領域ではありません。

そもそも EDCB は Docker (Windows コンテナ) ではまず動作しないでしょうし、Docker (Windows コンテナ) の構築には Windows の Pro エディション以上が必要です。
HW エンコーダーもおそらく動作しないため、Windows 環境での Docker 利用は現実的ではありません。安定性の面でもメリットが皆無です。