Linux用実行バイナリの自動ビルドを追加 (#95) #96

aoirint · 2021-09-15T17:36:01Z

ref: #95
ref: #85

内容

Docker内でLinux用実行バイナリを自動ビルドするGitHub Workflowを追加します。

run.pyをNuitkaでビルドし、成果物をGitHub ActionsのArtifactとして書き出します。

例: https://github.com/aoirint/voicevox_engine/actions/runs/1238234082

ビルドしたバイナリの動作には、CUDA/cuDNN（GPUの場合）とlibsndfileを別途インストールすることが必要です。

# On Ubuntu 20.04
sudo apt install libsndfile1

TODO

Docker内でビルドする利点

環境構築スクリプトを二重に実装する必要がない
- ちなみに、autoconfやcmakeを使ったビルドスクリプト構築の知見はもっていません
ビルド環境のキャッシュをDocker Hubに保管できる

（ネイティブビルドの方がよさそうであればCloseするかもです）

Dockerイメージのpushについて

*-buildcacheというビルド環境のキャッシュ用のDockerイメージのみpushします（--cache-toオプション）
バイナリを実行するDockerイメージがあってもいいかもしれませんが、その自動ビルドを実行するGitHub ActionsのJobは、役割的にbuild-docker.ymlの方に記述したほうがいいかもしれません
- 現在の公式Dockerイメージ Dockerfile (Linux)・GitHub Actionsによる自動pushの追加 #84 #88 はnuitkaビルドしていない状態でrun.pyを実行しています
- ひとまずbuild.ymlを実行バイナリビルド用のWorkflowと考えています

キャッシュについて

Nuitkaのccacheを使ったCコンパイル部分のキャッシュ機能を利用しようとしています
- https://nuitka.net/doc/user-manual.html#caching-compilation-results
- ccacheがインストールされていれば勝手に検出して使われます（Dockerイメージにインストールしています）
- ccacheによるキャッシュは~/.cache/Nuitka/ccacheに出力されるようです
- ~/.cache/Nuitka/module-cacheというのもあるので、まとめてキャッシュする予定です（ actions/cache@v2 を使用）
GitHub Actionsの実行時ディスク容量は14GB
- https://docs.github.com/ja/actions/using-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources
- docker/build-push-action@v2のload: trueというオプションを使っています
  - https://github.com/docker/build-push-action
- load: trueにより、docker-containerという仮想化されたDocker環境からDockerイメージを取り出し、あとのstepで使えるようにしているので、イメージサイズの2倍の容量が必要かもしれません
- つまり、イメージサイズが7GB（14GB/2）に近づくと自動ビルドに失敗するかもしれません
  - これは勘違いかもしれません

aoirint · 2021-09-17T05:05:47Z

NuitkaのキャッシュをうまくGitHub Actions上で保存できていなかったのでDraftにしていましたが、解決しました。
キャッシュ対象のファイルをみつけられていませんでしたが、キャッシュに使うディレクトリを作業ディレクトリから2階層深いサブディレクトリにするのをやめたら見つけられるようになったようです（ 12b806e ）。

aoirint · 2021-09-17T05:08:32Z

このPRは、masterブランチにpush、またはGitHub Release作成のタイミングで、
Ubuntu 20.04、Debian 11、Fedora 34で動くLinux用実行バイナリを自動ビルドできる状態です。
Ubuntu 18.04、Cent OS 8、Cent OS Stream 8では、工夫しないと動きません（工夫の例: https://github.com/Hiroshiba/voicevox_engine/pull/98#issuecomment-921240899 ）。

成果物は、master pushまたはRelease作成後、およそ1.5時間後にGitHub Artifact（GitHub Actionsの実行結果ページ）にアップロードされます。
デフォルトかつ最大の保持期間は90日で、保持期間を経過すると削除されます。

例: https://github.com/aoirint/voicevox_engine/runs/3624630654

バイナリの動作確認は各LinuxディストリビューションのDockerコンテナ内でしていますが、実環境では、テストしたDockerコンテナとディストリビューションは同じでも、動作する環境と動作しない環境が出てくる可能性はあります。
この場合、現在原因として想定しているのは、以下の2点です。

glibcやlibstdc++などの共有ライブラリのバージョンを手動で切り替えている（例: https://github.com/Hiroshiba/voicevox_engine/pull/98#issuecomment-921240899 ）
共有ライブラリがディストリビューションのバージョンに対応する最新版に更新されていない
- Ubuntu、Debianでは apt update && apt upgrade
- Fedoraではyum update

このPRで考慮していないディストリビューションやCPUの種類などへの対応に関する議論、
実環境での動作報告などは、
その都度IssueやPull Requestで対応する方向性で、いったんマージする形でも大丈夫でしょうか?
VOICEVOX ENGINEの正式リリースとしては、しばらくバイナリを含めなくてもいいかもしれません。

動作状況

amd64 (x86_64)

✔ Ubuntu 20.04（glibc 2.31）
❌ Ubuntu 18.04（glibc 2.27）
✔ Debian 11（glibc 2.31）
✔ Fedora 34（glibc 2.33）
❌ CentOS 8（glibc 2.28）
❌ CentOS Stream 8（glibc 2.28）

要求する共有ライブラリ・バージョン

glibc 2.29以降
- 調べ方: /lib/x86_64-linux-gnu/libc.so.6 または/lib64/libc.so.6を実行
libstdc++ GLIBCXX_3.4.26に対応するバージョン
- 調べ方: strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep GLIBCXXを実行
libsndfile:
- Ubuntu/Debian: sudo apt install libsndfile1
- Fedora: sudo yum install libsndfile
CUDA/cuDNN （GPU動作の場合）
- CUDA: https://developer.nvidia.com/cuda-downloads
- cuDNN: https://developer.nvidia.com/rdp/cudnn-download

aoirint · 2021-09-17T06:12:07Z

現在差分にはコマンドの実行ユーザを簡便に切り替えるためのgosuが含まれているので、 #105 とコンフリクトしています。

gosu: https://github.com/tianon/gosu

このPRでgosuを使っているのは、entrypoint.shをrootユーザで実行し、ビルドを一般ユーザで実行したいためです（依存関係は一般ユーザ用にインストールしている）。

Docker公式doc USER命令・gosu: https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#user

ホスト側のディレクトリをコンテナにマウントして成果物とキャッシュを取り出している関係で、entrypointでroot権限を使って、chown -Rでマウントしたディレクトリの所有者をコンテナ内の一般ユーザに書き換えています。

マウントされたディレクトリの所有者は、ホスト側にディレクトリが存在しない場合rootに、存在する場合もともとの所有者（ホスト側のUID・GID）になります。変更にはroot権限が必要です。

対応の候補として考えているもの

gosuを実行用イメージには含めず、ビルド用イメージには含める
ビルド用イメージでUSER命令を使用してあらためてrootユーザに切り替える
- entrypoint.sh内にスペースインデントが入ってしまう問題の対応と可読性の向上 #105 の意図としては、1よりはこちらの方がよさそう?
docker build中に実行バイナリをビルドする実装に切り替える（2の発展）
- https://github.com/Hiroshiba/voicevox_engine/pull/96#issuecomment-921534213

aoirint · 2021-09-17T06:28:07Z

一応、docker runではなく、docker buildの方で実行バイナリをビルドする実装も試そうと思っています。

例: aoirint/voicevox_engine@f3527e4...2c46c42

バイナリを実行するコンテナにも拡張できそうです。

ビルド成果物やNuitkaのキャッシュは、
イメージを1度コンテナとして起動する必要はありますが、docker cpで取り出す想定です。

ただ、Dockerイメージのキャッシュの扱いが難しそうです

aoirint · 2021-09-17T08:32:34Z

要点

Ubuntu 20.04, Debian 11, Fedora 34に対応し、Ubuntu 18.04やCentOS 8では動かない形でいったんマージして問題ないか
そのほか実環境での細かい動作確認
- 今後のIssueやPull Requestで対応する形で問題ないか
entrypoint.sh内にスペースインデントが入ってしまう問題の対応と可読性の向上 #105 とのコンフリクトをどう解消するか
- このPR内でgosuを使わないようにするべきか
- 現在のdocker runでディレクトリをマウントする実装をやめ、Dockerイメージビルド時に実行バイナリをビルドする実装に切り替えるべきかもしれない

ready for reviewにしていましたが、masterにマージされた変更が影響しそうなのでdraftに戻します

…ith-docker

Hiroshiba · 2021-09-17T17:52:24Z

詳細ありがとうございます！

Ubuntu 20.04, Debian 11, Fedora 34に対応し、Ubuntu 18.04やCentOS 8では動かない形でいったんマージして問題ないか

対応バージョンがわかるようになっていれば全く問題ないと思います。

今後のIssueやPull Requestで対応する形で問題ないか

こちらもその方針で大丈夫です。

gosuの削除 #105 とのコンフリクトをどう解消するか

こちら、僕自身よくわかっていなくて申し訳ないのですが、gosuを使うメリット・使わない場合のデメリットをご教示頂けると非常に助かります・・・。
（entrypoint.shをrootユーザで実行し、ビルドを一般ユーザで実行するメリット・そうしない場合のデメリットを知りたい感じです。）

aoirint · 2021-09-18T09:21:42Z

entrypoint.shをrootユーザで実行し、ビルドを一般ユーザで実行するメリット・そうしない場合のデメリット

実行用のイメージ runtime-env の実装を負債として? 引きずっているためで、メリット・デメリットについては考えていませんでした。

バイナリを実行する実行用のイメージを配布する可能性を想定していることも背景にあります（このイメージを配布するメリットはいまのところ思いつきませんが、バイナリにすることでプログラムの実行が高速になる、などがあれば意味があるかもしれません）。

デメリットについては、
依存するPythonパッケージやライブラリ・プログラムが悪意を持った場合に、root権限で実行されることくらいでしょうか。
gosuのバイナリは数MBで、容量については気にしなくていいと思っています。

メリットについては、 https://github.com/Hiroshiba/voicevox_engine/pull/105#issuecomment-922242197 の前半で言及した内容で、ビルド時ではありますが、ホスト側が影響を受ける可能性を予防しようとしています。

ちなみに、gosuの利用を継続するようであれば、gosuはディストリビューションのリポジトリからもインストールできる（apt install gosu）ようだったので、GitHub Releaseから取得するのではなく、ディストリビューションのリポジトリを信頼して、そちらを使うのもいいと思っています。
少しバージョンが古いですが、役割には影響しないと思います。
GitHub Releaseから取得する場合、厳密には、gosuのハッシュ値チェックもした方がいいかもしれません。

と、思ったのですが、 #105 の方でディストリビューションのリポジトリを使用する形に対応 e6d725d されていますね。

Hiroshiba · 2021-09-18T15:09:04Z

なるほどです！
#105 の議論の結果からもgosuを利用する方針で良さそうだと感じたので、gosu利用を継続する形で進めて頂ければと思います！

…ith-docker

aoirint · 2021-09-19T09:43:58Z

Dockerfileにおけるバイナリビルド用スクリプトの書き出しについて、
ヒアドキュメントが3重になっていて、すこし読みにくいように思いました。

ファイルに書き出してもいいのですが、Dockerの外部から使うことを想定していないスクリプトのため、
Dockerfile内に記述しています。

./docker/scripts/のようなディレクトリを作るというのも考えましたが、Dockerfileを
./docker/Dockerfileに配置したくなり、コンテキストの関係でDockerビルドコマンドが複雑になるので採用していません。

また、バイナリビルド用スクリプトをdocker runで呼び出す方法は、ビルド成果物を含むレイヤーが作成されないため、Dockerのキャッシュが利用できず、バイナリビルド後の処理を追加したときに、バイナリビルド自体も再実行されてしまうという問題を抱えています。

個人的には、これらは、それほど大きな問題ではないと思うので、希望、またはいい方法があれば、将来のPRで対応するのがよいと思っていますが、このPRで考えた方がよさそうでしょうか。

ちなみに、以前言及していたdocker buildのタイミングでバイナリビルドする方法（ビルド成果物を含むレイヤーを作成する方法、https://github.com/Hiroshiba/voicevox_engine/pull/96#issuecomment-921534213 ）は、GitHub Actionsの14GBの容量を使い切って、成果物の取り出しに失敗してしまうようだったので、むずかしそうです。複数のJobやWorkflowにDockerビルドとArtifactアップロードを分ければできるかも、とは思っています。

実環境での動作検証については、 #106 で募集し、 #95 はこのPRと一緒に閉じていいと思っています。

fork先での現在 Hiroshiba@28eba6e のビルド: https://github.com/aoirint/voicevox_engine/actions/runs/1250414693

Hiroshiba

LGTM！

./docker/scripts/のようなディレクトリを作るというのも考えましたが

VOICEVOXリポジトリと同じ用に、./build/ディレクトリを作る手もありそうです。
でも結局実行するのは数コマンドだけだし、Dockerfile内に記述されていてもあまり問題ではないかなと思いました！

docker runで呼び出す方法

僕も同意見で、docker buildとdocker runどちらでも良いと思っています。
軽量化されたり、よりよい方法が見つかったときに変更を考えましょう！

（artifactじゃなくreleasesにアップロードできるくらい軽量化したいですね・・・。）

Hiroshiba · 2021-09-19T14:53:56Z

ちなみにwindows版も自動ビルドを試される予定はありますか？
（ビルドスクリプトがとても参考になったので、もしよろしければぜひプルリクエストを頂ければなと思っています・・・！）

aoirint · 2021-09-19T18:46:29Z

ちなみにwindows版も自動ビルドを試される予定はありますか？

ビルドまでの道筋は整っていると思ったので、#107 を開いてみました。

coreの自動ビルド準備時のGitHub Workflowが似ていたので、参考にさせていただいています。

https://github.com/Hiroshiba/vv_core_build_check/blob/600e33d9567b4e500813a278e88c9941c464783f/.github/workflows/blank.yml

Hiroshiba · 2021-09-19T19:05:11Z

@aoirint はい、ぜひ参考にしてください！

また、CPU版やubuntu18ビルド版も用意してみました。もしよかったらお使いください！
https://github.com/Hiroshiba/voicevox_core/releases/tag/0.5.4

aoirint added 3 commits September 16, 2021 00:27

linux build workflow

c6eab9c

add note about GitHub Actions disk capacity

c163f96

fix typo (misreplace)

d1921c1

aoirint mentioned this pull request Sep 15, 2021

Ubuntu 18.04ベースのDockerイメージ自動ビルドを追加 #98

Merged

aoirint added 2 commits September 17, 2021 03:14

Nuitka cache working

12b806e

run build-linux on push master

3a4be5b

aoirint marked this pull request as ready for review September 17, 2021 07:55

aoirint marked this pull request as draft September 17, 2021 11:45

aoirint added 3 commits September 17, 2021 20:46

Merge remote-tracking branch 'origin/master' into patch-linux-build-w…

b0fc4c8

…ith-docker

follow upstream (added build args)

3b37338

rm speakers.json form build script in docker

ef99716

aoirint mentioned this pull request Sep 17, 2021

entrypoint.sh内にスペースインデントが入ってしまう問題の対応と可読性の向上 #105

Merged

aoirint added 10 commits September 19, 2021 01:09

nvidia build

cce85d9

Makefile: fix target name for nvidia build in docker

d8f1f74

fix gpu build: copy libtorch "*.so.*" instead "*.so"

5b8679a

add commit id to dist archive

ec4fac6

copy libtorch *.so and *.so.*

f17afd9

replace link path: libcore.so to libtorch

57fe734

install patchelf in build env

a8d2b85

Merge remote-tracking branch 'origin/master' into patch-linux-build-w…

5c35227

…ith-docker

fix libcore.so path to patchelf

fe390e6

add exec perm to run

2b2f335

aoirint added 6 commits September 19, 2021 06:10

versioned artifact name for release

76eac98

fix artifact name; variable

c23d49f

Makefile: compile-python-env base image arg

04b2463

artifact name as matrix

c2ded57

artifact name: linux-cpu and linux-nvidia

68cc154

add comment about artifact name.

28eba6e

aoirint mentioned this pull request Sep 19, 2021

Linux用実行バイナリの動作検証 #106

Closed

aoirint marked this pull request as ready for review September 19, 2021 10:43

Hiroshiba approved these changes Sep 19, 2021

View reviewed changes

Hiroshiba merged commit 3eed8e0 into VOICEVOX:master Sep 19, 2021

aoirint mentioned this pull request Sep 19, 2021

VOICEVOX ENGINEのLinux用実行バイナリを作る #95

Closed

aoirint mentioned this pull request Jun 18, 2023

バイナリビルドCI: 7zとVVPPが同時にCIストレージ容量を消費しないようにする #696

Merged

aoirint deleted the patch-linux-build-with-docker branch October 9, 2023 03:00

aoirint mentioned this pull request May 3, 2024

docker版/Dockerfileの扱いを考える #482

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Linux用実行バイナリの自動ビルドを追加 (#95) #96

Linux用実行バイナリの自動ビルドを追加 (#95) #96

aoirint commented Sep 15, 2021 •

edited

Loading

aoirint commented Sep 17, 2021 •

edited

Loading

aoirint commented Sep 17, 2021 •

edited

Loading

aoirint commented Sep 17, 2021 •

edited

Loading

aoirint commented Sep 17, 2021 •

edited

Loading

aoirint commented Sep 17, 2021 •

edited

Loading

Hiroshiba commented Sep 17, 2021

aoirint commented Sep 18, 2021 •

edited

Loading

Hiroshiba commented Sep 18, 2021

aoirint commented Sep 19, 2021 •

edited

Loading

Hiroshiba left a comment

Hiroshiba commented Sep 19, 2021

aoirint commented Sep 19, 2021 •

edited

Loading

Hiroshiba commented Sep 19, 2021

Linux用実行バイナリの自動ビルドを追加 (#95) #96

Linux用実行バイナリの自動ビルドを追加 (#95) #96

Conversation

aoirint commented Sep 15, 2021 • edited Loading

内容

TODO

Docker内でビルドする利点

Dockerイメージのpushについて

キャッシュについて

aoirint commented Sep 17, 2021 • edited Loading

aoirint commented Sep 17, 2021 • edited Loading

動作状況

amd64 (x86_64)

要求する共有ライブラリ・バージョン

aoirint commented Sep 17, 2021 • edited Loading

aoirint commented Sep 17, 2021 • edited Loading

aoirint commented Sep 17, 2021 • edited Loading

Hiroshiba commented Sep 17, 2021

aoirint commented Sep 18, 2021 • edited Loading

Hiroshiba commented Sep 18, 2021

aoirint commented Sep 19, 2021 • edited Loading

Hiroshiba left a comment

Choose a reason for hiding this comment

Hiroshiba commented Sep 19, 2021

aoirint commented Sep 19, 2021 • edited Loading

Hiroshiba commented Sep 19, 2021

aoirint commented Sep 15, 2021 •

edited

Loading

aoirint commented Sep 17, 2021 •

edited

Loading

aoirint commented Sep 17, 2021 •

edited

Loading

aoirint commented Sep 17, 2021 •

edited

Loading

aoirint commented Sep 17, 2021 •

edited

Loading

aoirint commented Sep 17, 2021 •

edited

Loading

aoirint commented Sep 18, 2021 •

edited

Loading

aoirint commented Sep 19, 2021 •

edited

Loading

aoirint commented Sep 19, 2021 •

edited

Loading