JpsonicをDockerで稼働させるための導入記事です
環境によっては単体起動またはTomcat上に配備した方がコンパクトですが、Dockerの方が便利な場合もあります。
OSSのメディアサーバで動作環境について明言しているプロダクトはほぼなかったりします。まったく基準がないのは困るので、Jpsonicではある程度の目安を出すための試みが行われています。DS220+でJpsonicを動かすという記事にありますが、現時点で「音楽サブスクの契約料5年分で減価償却できるNAS」の性能を参考に見積もりを行っています。
詳細はWikiのRequirementsというページにまとめられています。お手数ですがGoogle翻訳でご覧ください。
この基準に従うと良好な動作をしますというものです。production.synology.ymlに要点はコメントしてあります。ですので、予備知識をお持ちの方はスルーして設定項目とコメントを見てみる、といった使い方でも問題ありません。
GithubのWikiページにInstallationという記事があります。主に「SSHのターミナルからdocker-composeを使用して導入する方法」と、Synology限定ですが「ターミナルなしでDockerを起動する方法」がまとめられています。お手数ですがGoogle翻訳でご覧ください。以下は目次です。
docker-composeというのは、設定ファイルを読み込ませてオーケストレーションを簡易化するためのDocker標準ツールです。Dockerコマンド直でドキュメントを書くと煩雑になります。そのためテンプレート的なものを提供するので、書き換えたうえでdocker-compose経由で起動してください、という形式をとっています。
もともとは複数のコンテナを取り扱うためのツールだったりするので、Jpsonicとnginxを連携させたい場合、それぞれのymlをドッキングしたサービス構成のファイルを作る、という形で利用されたりします。そのためそういったことをしたい場合には、docker-composeを使って複数コンテナを扱うような技術記事を探せばリーチできると思います。
Jpsonicのタグ規則は、大手のプロダクトと同じようなタグ規則になるかと思います。タグには大きく分けて2つのグループが存在し、タグに対してイメージの内容が固定されているものと、推移的なものがあります。
以下は利用例です。
推移的管理がされているタグは、下位セグメントでより新しいものがリリースされると上書きされます。Watchtowerの自動更新はタグのインクリメントには対応せず、ひとつのタグのハッシュのみを追跡します。そのためWatchtowerが稼働していてJpsonicのタグが「推移的」のいずれかである場合、自動更新が有効になります。
以下はタグの例です。
latest (推移的) 全てのバージョンの中で最新
113 (推移的) 113.x.x 最新
113.0.0 (固定)
112.2 (推移的) 112.2.x 最新
112.2.1 (固定)
112.2.0 (固定)
112.1 (推移的) 112.1.x 最新
112.1.2 (固定)
112.1.1 (固定)
112.1.0 (固定)
112 (推移的) 112.x.x 最新
112.0.0 (固定)
メジャーをまたいだ動作をしたときにデータベースはどうなっちゃうの?ということですが、新しいJpsonicを使っている限り、意識する必要はありません。起動時にデータベースが自動的にマイグレーションされるためです。問題となるのは新しいバージョンのデータベースに対して古いJpsonicでアクセスする場合です。こんなことをすることもあまりないので、やっぱりあまり意識する必要はありません。主に開発者が意識する内容であり、メジャーをまたいだコンテナを複数起動する場合はコンテナのVolomeでJpsonicのデータ領域を別々に定義することになります。
Jpsonicは基本的にAlpineを使用して動作確認やチューニングが行われていますが、Ubuntsを使用することも可能です。Ubuntsの場合はタグのお尻に「-jammy」を追加してください。タグとJava、OS、ARCHの関連性は以下のようになっています。
v112.2.8以降Java17からJava21に移行したため表の内容が変わっています。ただしDocker imageを更新すると中身は勝手に変わるので気づかない方もいらっしゃるかもしれません。やべえかっけえ。気づかないうちにJava17からJava21に移行します。
| TAG | JAVA | OS:ARCH (eclipse-temurin) |
|---|---|---|
| [1xx.x.x, latest] | 21-jre | Alpine:amd64 |
| ea | 21-jdk | |
| [1xx.x.x, latest]-jammy | 21-jre | Ubuntu: amd64, arm64/v8 |
| ea-jammy | 21-jdk | |
| [1xx.x.x, latest]-jammy-v7 | 17-jre | Ubuntu: arm/v7 |
v112.2.8より前ではjammyの接尾辞でarm/v7が使用可能でしたが、v112.2.8以降はarm/v7に限り「-jammy-v7」の接尾辞が必要です。これは上流のTemurinでまだarm/v7のJava21環境が提供されていないためです。需要の高いプラットフォームから順に整備されているので。arm/v7をご使用の方はご存じだと思いますが、arm/v7対応は結構時間がかかることが多いです。それと、arm/v7でJava21対応が行われるかどうか自体は私は知りません。とはいえ少なくともLTS Java17が利用可能な間はarm/v7でも使えるのではないかと思います。
v7なんて使う人いるのかな？と私も思っていましたが、Jpsonicのイメージを公開してから今まで普通に使われています。多分ラズパイなんだと思います。ラズパイでもSynologyのNASとそれほど変わらない環境は組めますし、Jpsonicはこのあたりの性能帯のユーザを切り捨てることはありません。いきなり高負荷処理をブチ込むということは、今後もないのでご安心を。
速度に関する要件というのはそれほど厳密に決めていませんが、v112.x以降ぼちぼち改善しているところです。ただしストリーミングサーバは極端な動作速度が必要かというとそういうものでもありません。(原初の目的は爆速通信させないためのリミッター的な役割でしょう)
今どきのメディアサーバの速度に関して話をするのであれば、「DLNA相当のレスポンス速度でUPnP通信ができ、FLACやDSDの直送が可能」という辺りが必要条件になってくるかと思います。音楽を聴くためのサーバです。OSSがいくら多様性に寛容とはいえ、コレができてないのにあまりにも関係がない機能の優先順位を上にしても、意味がないでしょうよと。
FLACの直演奏に問題を抱えているメディアサーバも多かったりするのですが、Jpsonicの場合は作者がメインでその使い方をしているため動作確認が手厚いです。どこのプロダクトでも「曲の途中で次に行く、再現性がない」のような報告がとても多いのですが、この症状で多い原因はWifiの瞬断だと思います。今まで気づいてないだけで、実は今まで定期的に瞬断が発生していた、または知らない間にファームが更新されていた、周囲に干渉する機器が増えた等々、ここ十年来の家庭用LANではありがちな変化かと思います。この場合「バージョン上げたらおかしくなった」「このアプリでは起きてこのアプリでは起きない」のような捉え方をしてもあまり意味はなく、まずは有線・無線で切り分けが必要になるかと思います。
JpsonicのDockerプロセスは、SIGTERMによる終了シグナル(kill -15 = 128 + 15 = 143)を受信しシャットダウンした場合に0を返します。それ以外のコードで終了した場合、SynologyのDSMでは通知欄に警告が表示されます。
シグナル143はkillコマンドのデフォルト値、いわゆる普通のシャットダウンであり I(1) love(4) you(3)と覚えると簡単です。よく使用されるkill -9は強制終了になります。どう違うかというと、I love youのときは進行中の処理を可能な限りお行儀よく中断し、一番最後にデータベースをシャットダウンして終了コードを返します。SynologyのDockerのコントロールパネルでJpsonicをオフにするとこの動作になります。
乱暴にシャットダウンをしたら必ずデータが壊れるというわけではありませんが、大事な更新をしている最中に強制終了をすればよくないことが起こる可能性はあります。データ編集を行うような他のアプリと同じです。Podcastはレガシーサーバ以来ほとんど修正されていないためキャンセルがまだ実装されていません。v113以降、処理中のPodcastもうまいことシャットダウンできるよう対応していく予定です。
Linuxを使ったことがない方でもWindowsで簡単にインストールできる、を実現したかったのですが無理でした。簡易確認用としてproduction.windows.ymlは存在します。Dockerはクロスプラットフォームと言われてはいますが、WindowsのDockerはトラブルも多く動作も遅いです。実運用は厳しいのではないかと思います。
致命的な点はネットワーク周りに互換性がなくHOSTモードがサポートされていない点です。仮想環境のネットワークはBRIDGEで動作させるのが一般的です。BRIDGEでは処理が無理というケースもあるので、仮想ネットワークにはHOSTモードというものが必ず存在します。JpsonicはこのHOSTモードでなければ動作しない機能が存在します。端的に言えばWindowsのDockerではUPnP/DLNAが活用できません。(スマホアプリを経由してSonosやChromecast、AllPlay、Openhomeなどを利用する、ということができなくなってしまう)
UPnPを使用しなくても良いのであれば動作自体はWindowsのDockerでも可能です。あるいは単体起動やTomcatであればWindowsでもUPnPが利用できます。
eaタグのついたイメージは、開発者向けEarly Accessです。常用ではなく未リリース機能のテスト用です。JREではなくJDKが入っているので、サイズは大きくなります。またJMX接続用にポートがひとつ多くEXPOSEされています。ジャーナルを出力したりメモリプロファイリングが必要な場合これを使用します。
以下のような特徴があります。
eaタグが使用されている開発版は、あくまで開発者の利用を前提としています。一般的なユーザのためのいわゆる「先行お試し版」ではないことに注意してください。Jpsonicの場合、マスターにマージされたものがユーザ向けリリース版であり、それ以外の全てのブランチは完全にアナザーストーリーです。「お試し」されてもかまいませんが、通常リリース版のデータディレクトリとの共用は避けるのが無難です。
開発版では次期リリースのためデータの仕様を変えていることがあります。取り扱いにはJavaやDB、使用されている各種フレームワークの知識が必要になる場合があります。滅多にないとは思いますが、開発版のブランチで大きな問題があれば予告なしに巻き戻しも行われる可能性もあります。
ユーザへのリーチを早くするといった観点からいえば、作ったものからリリースするのが理にかなっています。ただしいつもそれができるかというと、それほど話は単純ではありません。いくつかの修正をセットでリリースしなければならなかったり、データ仕様の変更がある場合リリースタイミングをずらしたり、といった調整が必要な場合もあります。開発版はリリース版と異なるルールで管理されていることに注意してください。
この記事を書き換えたときに以下に追記します。
jpsonicを使わせていただいております。
Ubuntu22.04でproduction.ymlでDocker起動する事を確認していますが、
CONTEXT_PATHの設定がデフォルトでは反映されないのではないかと思われたため、
コメントをさせていただきます。
こちらで暫定的に以下のような処置をする事で、動作確認出来ましたので、
連絡させていただきます。
Docker内に入ります。
sudo docker exec -it jpsonic bash
以下のように変更することで、サブディレクトリで起動可能になりましたが、
これをデフォルトで有効にしていだけないでしょうか。
cd /usr/local/bin
vi entry-point.sh
-Dserver.servlet.contextPath=”$CONTEXT_PATH” \
以上、宜しくお願い致します。
返信が大変遅くなり申し訳ありません。
間違ってますね! 近日中に修正版(111.5.7)をリリースしようと思います。
ご報告ありがとうございます。
修正版の111.5.7をリリースいたしました。
jpsonic/jpsonic:latest または
jpsonic/jpsonic:latest-jammy
で利用が可能です。
この修正は次期バージョンの111.6.0に含まれる予定です。
よろしくお願いいたします。
早々に対応頂きまして、ありがとうございます。
次期バージョンも含め、使用させて頂きます。
はじめまして
Synology NASにインストールできる日本語対応ミュージックサーバーを探してこのHPまで来たのですが、Linuxにはうとくシェルを使う方法ではなくタスクスケジューラーを使ってインストールする方法があれば教えていただけないでしょうか？
よろしくお願いします
参考サイト：https://mariushosting.com/how-to-install-mstream-on-your-synology-nas/
こんにちは
了解いたしました。近日中にまとめます。
実は最初、タスクスケジューラーも検討していました。比較的docker-compose.ymlのほうがよく知られていて普通のLinuxでもすぐ使えることと、コメント等が書き込みやすいという理由で現在の方法にしました。
回答ありがとうございます
タスクスケジューラー対応の件、ありがとうございます
楽しみにお待ちしています
大変遅くなりました。インストールドキュメントにDSM Task Schedulerの項目を追加しました。
With DSM Task Scheduler(docker run)
実際には少し下のほうにあるRun commandが問題なのかと思いますが・・・。ご不明点がありましたら、ご連絡ください
対応ありがとうございます
早速実行したところ、エラーで停止するようです
おかしなところがあればご指南ください
よろしくお願いします
NASのroot下にdockerを作成
dockerの下にjpsonicを作成
jpsonicの下にdata、music、playlists、podcastsを作成
エラー内容の一部
——————–
2023-10-01 18:17:12.441 ERROR — o.s.boot.SpringApplication : Application run failed stdout
2023-10-01 18:16 ln: /jpsonic/data/transcode/ffprobe: No such file or directory stderr
2023-10-01 18:16 ln: /jpsonic/data/transcode/ffmpeg: No such file or directory stderr
2023-10-01 18:16 mkdir: can’t create directory ‘/jpsonic/data/transcode’: Permission denied
——————–
以下タスクスケジューラー内容
——————–
docker run -d \
–name jpsonic \
–net=host \
–hostname=SynologyNAS \
–pid=host \
–label=com.centurylinklabs.watchtower.enable=true \
-v /volume1/docker/jpsonic/data:/jpsonic/data \
-v /volume1/Backup/FolderSync/Music:/jpsonic/music \
-v /volume1/Multimedia/Music/jpsonic/podcasts:/jpsonic/podcasts \
-v /volume1/Multimedia/Music/jpsonic/playlists:/jpsonic/playlists \
–memory=2g \
–memory-swappiness=1 \
-e JAVA_OPTS=’-Xms1536m -Xmx1536m -XX:+UseG1GC -XX:MaxGCPauseMillis=500′ \
-e JPSONIC_PORT=4040 \
-e UPNP_PORT=4041 \
-e USER_ID=$1026 \
-e GROUP_ID=$100 \
-e TIME_ZONE=Asia/Tokyo \
-e CONTEXT_PATH=/ \
-e BANNER_MODE=OFF \
-e TINI_SUBREAPER=true \
–stop-timeout=30 \
jpsonic/jpsonic:latest
——————–
見たところ起動はできているのでゴールは近いですが、典型的な権限エラーのように見えます。
– ディレクトリに正しい権限が与えられていない
– uid/gidが誤っている
これらの可能性が高いのではないかと思います。
-e USER_ID=$1026 \
-e GROUP_ID=$100 \
この行がちょっと怪しいかもしれません。
-e USER_ID=$(id -u jpsonic) \
-e GROUP_ID=$(id -g jpsonic) \
(jpsonicはデイレクトリに権限のあるユーザ名)と修正するとうまくいくかもしれません。Synologyの場合コンソールを全く使用しないという条件であれば、ユーザはuid/gidを知ることができません。ですので、あらかじめユーザに権限を与えておいて
-e USER_ID=$(id -u jpsonic) \
-e GROUP_ID=$(id -g jpsonic) \
の方式で実行するしかないはずです。
返信ありがとうございます
ユーザーIDもタスクスケジューラーでidを実行すれば取得できましたのでそれを使用していました
uid=1026(xxxxxx) gid=100(users) groups=100(users),101(administrators)
しかし、そのユーザーを使ってインストールをしてもエラーが出てしまいます
docker: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post “http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/create?name=jpsonic”: dial unix /var/run/docker.sock: connect: permission denied.
See ‘docker run –help’.
なので、rootでインストールしていました
インストールできました
ユーザーIDの前に付けていた”$”が必要なかったみたいです
無事ログイン画面を見ることが出来ました
ありがとうございます
また分からないことがあれば質問させてください
おかげさまでインストールに関する解説が少し進化しました。
ご不明点がありましたらフィードバックするのでご連絡ください。
インストール後色々いじってみて問題が解決しなかったので質問させてください
1つめの問題は-vで指定した音楽フォルダがjpsonicから見えていないようです
これはairsonicをjpsonicと同じ設定でインストールしてみてairsonicは音楽データを読み込めていたのでjpsonicの問題のような気がします もしかして隠しディレクトリは読み込めないとかあったりしますか？
2つめの問題は、スキャンするとずっとスキャンしたままになります スキャンを停止しても止まりません
よろしくお願いします
> airsonicは音楽データを読み込めていたのでjpsonicの問題のような気がします
それは憶測です。解決には情報が必要です。
1. ログファイルに何か出力されていますでしょうか? 空ディレクトリをVolume指定してみて試す。ディレクトリを足す。ファイルを足す。ライブラリの一部をスキャンしてみるなど段階的に試すと問題に気づきやすいです。設定画面でMusic FolderのEnabledが有効になっている点も確認してください。アクセスできないディレクトリをスキャンしようとするとそのフォルダは自動的に無効化されます。(試行錯誤中になにかトラブルがあり無効化されていてそのままになる、等の可能性)
2. Jpsonicでは非常に致命的なエラーが発生した場合、データ保護のためスキャンを停止します。(ただし画面は更新されない可能性があります。致命的なエラーが発生した場合にはその後の処理は何も保証されません)
2は結果です。1を先に解決すべきでしょう。「音楽フォルダがjpsonicから見えていない」という状態が具体的に何を指しているかが、曖昧です。
返信ありがとうございます
jpsonicから音楽ディレクトリが見えてないと判断しているのは、音楽ファイルが入っているディレクトリをインストール時に-vで指定しているのですが、adminでjpsonicにWeb画面からログインをしてホームに音楽ファイルが1つも表示されていないことで判断しました
airsonicの場合はインストールしてWeb画面にアクセスした段階でマウントしたディレクトリと音楽ファイルが確認出来たので、airsonicから派生したjpsonicでもそうなるものと思っていました
jpsonicはインストールが完了した段階でmusicディレクトリのスキャンは実行されているのでしょうか？
あと、スクリプトを見て疑問に思ったのですが、
–hostname=SynologyNAS \
は、他の文字列に変えると何かしら支障が出るのでしょうか？
よろしくお願いします
> jpsonicはインストールが完了した段階でmusicディレクトリのスキャンは実行されているのでしょうか？
設定画面・仕様 > 起動オプション という記事にありますが、Subsonic/Airsonicとは異なり起動時のスキャンは任意です。デフォルトでOFFです。起動時にスキャンを実行することが正しい動作なわけではありません。どちらかといえば設計としては悪手ですので、そのままお使いいただくことをお勧めします。
Subsonic/Airsonicが起動時にスキャンをするのは、ユーザビリティを考慮してそうなっているわけではありません。検索索引データを初期化するために起動時スキャンを行っています。スキャン前に検索するとエラーが出る、つまり不十分な実装の回避策です。Jpsonicでは改善されているので起動時に空スキャンを行う必要性がありません。
起動時にスキャンを行った場合、2点問題があります。ひとつはDocker(というよりその先)のマウントが非同期のためスキャンが先に始まる場合があります。条件によっては問題が発生します。非常に低速な環境で外部NASやHDDをマウントしスキャン、その後再起動を行った場合など。もうひとつは負荷の問題です。スキャンはシステム全体の中で処理のピークです。起動直後は負荷が集中しやすいので強制スキャンを行うのは不適当です。Subsonic/AirsonicとJpsonicとで仕様が変わっている箇所は、大体何か問題があったから変えられたというパターンが多いです。
> 他の文字列に変えると何かしら支障が出るのでしょうか？
支障ありません。ブログラム内から環境の固定文字のhost名を読み込んでどうこうするといった処理はありません。
