Update: [Docker] Docker関連のいくつかの修正

[5ym]

変更の種類

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

チェックリスト:

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

説明

簡単な内容しか記載できていませんが、とりあえずDockerイメージをGitHub packagesに登録するymlを作成しました。 お役に立てば幸いです。

動機とコンテキスト

将来的に下記の様に中級者がより簡易になおかつ早く環境構築できるようなプロジェクトを別途作成したいです。(個人的な要望です。本家に取り込んでもらいたいという意図ではありません。)
https://github.com/l3tnun/docker-mirakurun-epgstation

[tsukumijima]

せっかく寄稿していただいたのに申し訳ないのですが、現時点ではこのプルリクリクエストをマージすることはできません。
KonomiTV 自体まだベータ版ですし、特に開発版 (master ブランチ) は頻繁に破壊的変更が行われたりと安定して使える状況ではありません。Linux (docker) 版も、あくまで”暫定的な”便宜のために用意しているものに過ぎません。

将来的には Docker イメージを GitHub Packages (or Docker Hub?) に公開したりも考えてはいますが、残念ながら現時点で取り組める状態にはないのが現状です…。
箇条書きで大雑把にまとめると、

• version 0.6.0 のリリースにはもうしばらく時間が掛かる
  • 不具合修正だけでもいくつかタスクが残っているほか、インストーラーの実装も進めなければならない
• Windows 版や Linux (non-docker) 版も並行してサポートする中、アーキテクチャや扱いが根本的に異なる Linux (docker) 版はどうしても実装を後手に回さざるを得ない
  • もとより多種多様な環境をきめ細やかにサポートする事自体、相当な開発上の重荷になっている
  • 私としてもできるだけ多くの環境をサポートしたいのは山々だが、もはや一個人では回しきれないキャパシティになっているのが正直なところで、時間も労力も足りない
  • ソースコードが手元にある状態で Dockerfile を docker-compose up -d で自ビルドする場合と異なり、ビルド済み Docker イメージを配布する形はリリース関連で考慮事項が多く、ただでさえパンク寸前のキャパシティを超えてしまう
• サポートコストや私が把握し切れる範囲のキャパシティなども考慮すると、docker-mirakurun-epgstation のような Docker 環境専用のリポジトリまで用意できそうにもない
• KonomiTV は『TVTest・EDCB を導入するだけで精一杯な方でも、かんたんに導入できて手軽に使えるもの』をコンセプトに開発しているため、できるだけメインターゲットである Windows 環境の方に実装リソースを割きたい
  • 実際、KonomiTV の前身である TVRemotePlus は Windows 環境でしか動かないものだった
  • KonomiTV の開発当初は私が Windows 環境での録画がメインなこともあり、Linux 環境のサポートはおまけ程度のつもりだった
  • 要望や過去のプルリクエストを受けて暫定的に Docker で構築できるようにしているが、今後のリリース時にどのように展開するかは何も決められていない
• インストールとアップデートを円滑に行い私に降り掛かってくるサポート量を可能な限り減らすことを目的に、Windows・Linux・Linux (docker) すべてでインストーラー/アップデーターを開発中
  • 開発中のインストーラー/アップデーターのコンセプトは、このプルリクエストの趣旨と衝突する
  • Docker で構築する場合は確かに環境構築は Docker イメージのビルドだけで終わるものの、円滑にインストールするには環境設定ファイル (config.yaml) の変更やマイグレーションなどを行う必要がある
  • インストーラー/アップデーターをこちらで用意してそれを使ってもらう手法が一番インストール成功率が高く、こちらは（トータルで見れば）サポートコストと実装コストを下げられ、ユーザーもかんたんにインストールできて Win-Win な最善策だと考えている

…といった理由になります。

---

GitHub Packages に Docker イメージをアップロードするワークフロー自体は、今後のリリースの展開方法を考える上で参考にさせていただくかもしれません。
ただ、Docker イメージをアップロードするとしても amd64 のみで、arm64 は当面の間未サポートとせざるを得ません。

FFmpeg などのサードパーティーライブラリの ビルドスクリプト が LInux (ARM) に対応できていないため、現状ラズパイなどの ARM Linux では KonomiTV は動作しません。
さらに QSVEncC / NVEncC / VCEEncC は ARM 環境では動作しないため、ARM 環境のみ、QSVEncC / NVEncC / VCEEncC を配置しなくても起動できるように改良しなければなりません。

サードパーティーライブラリさえどうにかなれば動かせることは以前 Qua Station でざっくり確認していますが、多くの ARM シングルボードコンピューターの貧弱な CPU 性能では CPU のみでのリアルタイムエンコードは厳しいため、FFmpeg に渡すコマンドライン引数をラズパイ4などの HW エンコード機能に対応させる必要が出てきます。
私としても ARM 環境に対応したいのは山々なのですが（激安 SBC で KonomiTV が動くのは夢がある）、上記の通りすでにまったく手が回っておらずパンク寸前のため、サポート環境をこれ以上増やしたくないのが本音です…。

ある程度完成してきて、余裕が出てきたタイミングで ARM 対応はやる予定です。それがいつになるかはまったく見通せませんが…。

armv7l (arm32) に関してはクロスコンパイルなどの扱いが難しいため、対応予定はありません。
Rasberry Pi OS も数年前に 64bit が正式にサポートされましたし、ARM 環境は arm64 (aarch64) に統一したいところ…。

---

諸々すでに個人の範疇では手に負えなくなってきてしまっているので（つらい）、できるだけサポートする環境の範囲と実装範囲をミニマムに保ち、私が丁寧に整備した手順通り使っていただきたいという考えが念頭にあります。
申し訳ありませんが、何卒ご理解いただければ幸いです。

動かない！！！何もしてないのに壊れた！！！と外野から文句を言われても（無保証だし）無視すればいいのかもしれませんが、残念ながら良心がどうしても咎めてしまい、丁寧にサポートしてしまうんですよね……

特に Linux 環境で構築される方は我流にカスタマイズしようとする方が多いのですが、我流でやろうとした挙句うまくいかず泣きつかれるケースが過去に多くあり、内心かなりうんざりしているのもあります。
インストーラー/アップデーターを整備し、インストーラー/アップデーターが自動的に行う手順の通りに環境構築してもらえれば、そうした泣きつかれをだいぶ軽減できるのでは？という目論見もあります（もしインストーラーを使わないなら完全に自己責任でサポートはしないと突っぱねれるし）。

---

以下は蛇足と余談です。

このプルリクエストでは docker-compose.yaml が docker-compose.sample.yaml にリネームされ、docker-compose.override.example.yaml が削除されて内容が docker-compose.yaml に統合されていますが、これは受け入れられません。

私としてはもともと NVIDIA GPU 環境も含めて一つの docker-compose.yaml に統一したかったのですが、それを行うと、今度は NVIDIA GPU 非搭載の環境で Docker コンテナが起動できなくなってしまうことがわかりました。
そこで、docker-compose.override.yaml を配置すると docker-compose.yaml に記述された設定を上書きできる Docker の機能を使い、『docker-compose.yaml に記載しなければならないが、環境によって変更の必要がある設定』を docker-compose.override.example.yaml に書き出しました。

NVEncC を使いたい方のみ明示的に docker-compose.override.example.yaml を docker-compose.override.yaml にコピーしてもらってから、Intel CPU / iGPU のみ (QSVEncC) や AMD Radeon GPU (VCEEncC) の環境ではそのまま、docker-compose up -d すれば起動できるように配慮したファイル配置になっています。

KonomiTV の docker-compose.yaml は、QSVEncC / VCEEncC をコンテナ内から動かしたり、コンテナ内から全てのファイルシステムにアクセスできるように少々特殊な構成になっています。
docker-compose.yaml 本体を下手に弄って「動かない！！！！」と泣きつかれても困りますし、編集不要でファイルを一つコピーするだけで NVEncC (NVIDIA GPU) の利用のオプトインができる、この形態が最良だと判断しました。
ただ 0.6.0 以降のインストール方法自体をインストーラーに切り替えることを鑑みれば、再考の余地はあるかもしれません。

YAML の拡張子は yml が一般的なようですが、私のこだわりで KonomiTV では yaml に統一しています。
そのうち気が変わって yml にすることもあるかもしれませんが……

なお、ドキュメントはあえて version 0.5.2 のリリース後からほとんど更新していません。
version 0.6.0 以降からはインストーラー/アップデーターでのインストール手順に切り替える予定のため、今中途半端に書いても無駄になるためです。

---

本当は誰かに開発を手伝ってほしいくらいの状況ですが、私がデザイン・UX・プロダクトの品質・細かなコードフォーマットなど細部にとてもこだわりがあるため、特にまだプロダクトの全体像も固まっていない or 大部分が未だ私の脳内イメージの域を出ない現段階では、他の方からのコントリビュートはなかなか受け取りづらい状況です。作業用の分身がほしい……。

[5ym]

@tsukumijima
実装大変な中わざわざご確認ありがとうございます。
現状の方把握いたしました。ご指摘いただきまいした分に関しては再度修正を行っております参考になればと思います。
こちらとしましてはオープンしたままでもクローズしていただいても大丈夫ですよろしくお願いします。

[5ym]

個人的には動作保証なしでもDockerイメージの登録だけはしていただければdocker環境構築用のプロジェクトをサードパーティとして提供することによって少しでも本体のメンテナーの負荷を軽くできればという意図もありました。
そのあたりご検討いただけると幸いです。

[tsukumijima]

個人的には動作保証なしでもDockerイメージの登録だけはしていただければdocker環境構築用のプロジェクトをサードパーティとして提供することによって少しでも本体のメンテナーの負荷を軽くできればという意図もありました。

現在のワークフローでは、master ブランチでコードを push した際に、毎回 Docker イメージがビルドされ ghcr.io (GitHub Container Registry) に公開されるようになっていると思います。
私自身、Docker Hub はまだしも GitHub Packages はどのように使うのかすらよくわかっていないのですが、push する毎に生成されたイメージが延々と ghcr.io に残り続けるのはちょっと気持ち悪いです。

最新の master ブランチの開発版 (:latest) と、バージョンがタグ付けされたリリース版のみが ghcr.io に公開されるようにしていただければ、マージしてもいいかなと思います。
もちろん master ブランチは開発版ですので、どこかのタイミングで Dockerfile が壊れるかもしれませんし、動作保証は一切できません（現状 ghcr.io に公開されたイメージを公式に使う予定はありませんし、動作確認するのは地味にかなり時間を食う…）。それでも良ければ、にはなりますが…。

---

このプルリクエストでは、しれっと docker-compose up -d が docker compose up -d に書き換えられています。おそらく docker-compose v2 向けに変更したのでしょうけど、これを採用していいのかどうかは迷います。

私もあまり把握できていないのですが、Python で書かれた docker-compose コマンドは将来的に非推奨になり、代わりに docker 本体に統合された docker compose (v2) を使うように公式では勧められているようですね。
互換性は一応あるようですが、すべての環境で docker compose (v2) コマンドが使えるようになっているか分からないですし…（確か別途プラグインを入れないと有効化されないとかいう話があったような……）。

Docker Desktop では自動アップデートの折にしれっと v2 が有効化されていたりするみたいですが、サーバー用途で v2 を使っていい段階にあるのかどうか…

---

あと、KonomiTV のプロジェクトでは、個人的なこだわりでコード (Vue SFC を除く) の先頭に空行を入れるようにしています。できれば合わせて頂けると助かります（こういうのも資料に書いておくべきなんだろうけど、もともと実装前のコンセプトメモレベルの代物なのでドキュメントを整備する時間と気力が…）。

[5ym]

@tsukumijima
たびたびありがとうございます。
先にdocker composeの件ですが、リリース自体は2021年6月だったと思います。現状Docker desktopはdocker-composeを打ってもdocker composeにエイリアスしており非推奨というのが公式の見解だそうです。
サーバ用途に関してはCompose V2にてECSのデプロイにも使用できるようになっており安定性などのめんで問題はないと思われます。
現状自分の環境でも使用していますが、公式のインストールステップに従った場合Compose V2のみがインストールされます。

またタグの件ですが、masterプッシュ時にlatestでタグを生成するように修正したのですが、どうにも勝手にDigestタグが生成されてしまうようです。もう少し調べてみます。不可能なようならタグを一から自分で記述する方法に使用と思います。

[5ym]

予期しないイメージが生成される件修正できました。
masterの変更分をlatest, リリースタグの分をリリースタグに応じてイメージが登録されるはずです。

[tsukumijima]

docker-compose はそろそろ v2 にしてもよさそうですね。マージします。
色々よしなにしていただいてすみません…… ありがとうございました！

[5ym]

@tsukumijima
こちらこそ取り込んでいただきありがとうございます。
まだほとんど個人用ですが、dockerでデプロイできる環境を作成してみました。参考になればと思います。
https://github.com/5ym/docker-mirakurun-konomitv