Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ubuntu22のdocker buildのCDが落ちてる #1525

Open
Hiroshiba opened this issue Feb 7, 2025 · 11 comments · May be fixed by #1533
Open

ubuntu22のdocker buildのCDが落ちてる #1525

Hiroshiba opened this issue Feb 7, 2025 · 11 comments · May be fixed by #1533
Assignees
Labels
OS 依存:linux Linux に依存した現象 バグ

Comments

@Hiroshiba
Copy link
Member

不具合の内容

タイトルのとおりです。なぜかubuntu22のdocker buildが落ちています。
https://github.com/VOICEVOX/voicevox_engine/actions/runs/13191733524/job/36847704280

現象・ログ

毎回エラーが違います。
例えば5回目のログはこんな感じです。

logs_34058244472.zip

再現手順

forkしてbuild-dockerworkflowを動かす

期待動作

buildがうまくいく。

その他

原因も課題もいろいろよくわかっていません・・・。

  • dockerのubuntu imageのアプデが怪しい?
  • ubuntu imageがアプデされてキャッシュが崩れたから?
  • arm64周りが原因?

Discordでの会話のコピーを貼ります。

takana_ — 今日 16:07
なんかエンジンのDockerビルドが落ちてる
https://github.com/VOICEVOX/voicevox_engine/actions/runs/13191733524/job/36830318546

DockerのUbuntuイメージのアプデ?がなんか怪しい気がしています
https://git.launchpad.net/cloud-images/+oci/ubuntu-base/?h=jammy-22.04

ちゅうこ — 今日 16:19
configure: error: cannot compute sizeof (long double)

ヒホ — 今日 16:40
むむ! nvidiaの方は通ってる・・・のはnvidiaのubuntu22コンテナがまだ古いからとかか。。
22.04でこうなることってあるんですねぇ どうしようかな。。。issue作って1週間くらい様子見する・・・?
 
takana_ — 今日 16:44
説1: imageのアプデで壊れた
説2: imageのアプデでキャッシュが消えたせいで壊れた
どっちもあり得そうなので困る...

ヒホ — 今日 17:40
よくわからないけど、ARM64ビルドで落ちてるっぽい・・・?
https://chatgpt.com/share/67a5c6e4-5e94-8008-b91e-ced65211e5d1
ChatGPT
[ChatGPT - Docker ビルド エラー](https://chatgpt.com/share/67a5c6e4-5e94-8008-b91e-ced65211e5d1)

サボ寝ルネ — 今日 17:41
libmが無いって書いてあるけれど…
build-essentialに入っていないとかあるかしら?

ヒホ — 今日 19:28
これってどこの行ですかね? 👀  (issueにまとめようかなと思い)

ヒホ — 今日 19:42
!!!! 3回目の失敗は418.4 configure: error: Python requires C99 compatible libmだ!!!
1回目の失敗は
#36 477.4 ./Include/pyport.h:596:2: error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)."

2回目は
#36 155.6 configure: error: cannot compute sizeof (long double)

3回目は↑

サボ寝ルネ — 今日 20:08
その通りです。
418.4 configure: error: Python requires C99 compatible libmが出た原因は#36 418.0 checking for log1p... noかもしれません。
コンパイラがC99のlog1p関数をサポートしていない?
そんなことはない気がするのだが…

ヒホ — 今日 20:13
ビルドするたびにエラーの原因が違う・・・・のは並列でコンパイルしてるからとかなんかな・・・・・
@Hiroshiba Hiroshiba added OS 依存:linux Linux に依存した現象 バグ labels Feb 7, 2025
@Hiroshiba
Copy link
Member Author

@Hiroshiba
Copy link
Member Author

なぜか直ったのでcloseします。
これからも直った状態であり続けるのか不明ですが、まあ再発したらreopenする感じで・・・。

@takana-v
Copy link
Member

同じ原因かどうかは不明ですが、再発した感じなのでReopenします。
#1528 (comment)

ざっくり調べてみた感じ、QEMU周りで問題が発生しているようです。
どうやらQEMU側で修正されたようなので、変更がリリースされたら直るかもしれません。
tonistiigi/binfmt#215 (comment)

@takana-v takana-v reopened this Feb 21, 2025
@Hiroshiba
Copy link
Member Author

Hiroshiba commented Feb 22, 2025

reopen感謝です!!

ちょっとちゃんと把握できてないのでもし知ってたら知りたいのですが、これ問題が起きてるのってクロスコンパイル周りなんですかね?
つまりx64環境でarm64をビルドしようとし、QEMUが必要になって落ちる、みたいな。
であれば、今はarm64環境があるので、arm64のGithub workflowでビルドしたら解決したりするのかな~と。

まあ待っても解決するかもですが、いずれまた同じ問題が出そうなのと、arm64でビルドした方が綺麗な気がするので・・・!
この認識が合ってそうであれば、arm64でarm64のdocker buildするというissueを建ててみようと思います!

@nanae772
Copy link
Contributor

私のfork先でもdocker buildが上手くいかない事象が起きたため共有させていただきます(完全に別問題だったらすみません)。
Dockerfileの該当箇所としては、download-onnxruntime-envのapt-get周りで失敗しているようでした。

# Download ONNX Runtime
FROM ${BASE_IMAGE} AS download-onnxruntime-env
ARG DEBIAN_FRONTEND=noninteractive
WORKDIR /work
RUN <<EOF
set -eux
apt-get update
apt-get install -y \
wget \
tar
apt-get clean
rm -rf /var/lib/apt/lists/*
EOF

Image

logs_34739694713.zip

@Hiroshiba
Copy link
Member Author

@aoirint いつも頼ってしまってすみません!!

今回ビルドが落ちてる所って、最近増えたGithub Actions環境のarm64環境でビルドすれば実は問題なく動いたりしそうですかね・・・?
だとしたら、ちょっともしよかったら挑戦してみていただけないかなーと思ってメンション飛ばさせていただきました!!!

ビルドするだけならそんなに難しくないと思うのですが、docker buildしたものを良い感じにプッシュできないといけないんですよね。
こう、arm64とx64バージョンをOS/ARCHだけ違う同じバージョンとして扱うとか。
(↓みたいなことを指してます)

あとビルドキャッシュ周りとかが難しく、もしよかったらお力お借りできればなと・・・・・!!!
お忙しくなければ、もしよかったら是非!!!

@aoirint
Copy link
Member

aoirint commented Feb 23, 2025

以前のエラーと今のエラーが同じ原因だとすると、amd64 CPUの上でarm64 CPUをエミュレートしてarm64バイナリを動作させるためのQEMUの不具合のようなので、QEMUを使わないネイティブarm64環境でビルドすれば問題なさそうですね。

docker buildしたものを良い感じにプッシュできないといけない

調べた感じできそうではあるんですが、地道に作る感じになりそうですね...。

  • config→build-docker→run-release-test-workflow

いまはamd64イメージとarm64イメージを1つのjob(build-docker)でまとめてビルドしていますが、

  • config→build-docker→build-docker-manifest→run-release-test-workflow

CPUを切り替えるために別々のjob(build-docker改)でビルドしたあと、後続のjob(新設build-docker-manifest)で1つのタグにまとめてpushする作りにする必要がありそうです。

だいたいの実装の流れは考えたので、これで取り組んでみます。

  • build-docker: 各CPUアーキテクチャごとにDockerイメージをビルドするjob(matrixでCPU切り替え。docker/build-push-action
  • build-docker-manifest: 各CPUアーキテクチャ向けのイメージをまとめるjob(Dockerコマンド直書き)
    • amd64用のタグ, arm64用のタグからそれぞれイメージをpullする
      • docker pull voicevox/voicevox:cpu-amd64-ubuntu22.04-latest
      • docker pull voicevox/voicevox:cpu-arm64-ubuntu22.04-latest
    • docker manifest createコマンドでマニフェストリストを作成して、イメージを1つのタグにまとめる
    • docker manifest annotateコマンドで、マニフェストリストに含まれるamd64用のタグ、arm64用のタグのそれぞれにOS・アーキテクチャの情報を追加する
      • docker manifest annotate --os linux --arch amd64 voicevox/voicevox:cpu-ubuntu22.04-latest voicevox/voicevox:cpu-amd64-ubuntu22.04-latest
      • docker manifest annotate --os linux --arch arm64 voicevox/voicevox:cpu-ubuntu22.04-latest voicevox/voicevox:cpu-arm64-ubuntu22.04-latest
      • https://docs.docker.com/reference/cli/docker/manifest/annotate/
    • マニフェストリストをpushする

docker/build-push-actionを2回実行するだけ(build-dockerでCPUごとに1回ずつ、build-docker-manifestで1回)で済んだら、それが一番いいかも?(docker/build-push-actionにいろいろメタデータを付ける機能があったりするので、細かいこと考えずにそれに乗っかれるから)

@aoirint aoirint self-assigned this Feb 23, 2025
@Hiroshiba
Copy link
Member Author

Hiroshiba commented Feb 23, 2025

おーなるほどです!!
ちょっとqemuは可能なら依存外しておきたい気持ちが強いので、実現できるならぜひ実装したいです!!!

それぞれのアーキテクチャでビルドしたあと、一度pushしないといけない感じなんですね!
本当はまとめたのだけで良いけど、各アーキテクチャのimageがレジストリに上がってしまいますね。でも仕方なそう…!

imageのタグを自動で決定する方法?も興味深いです。(メタデータを付ける機能の事を意図してます。僕が何か勘違いしてるかも)
それもありかも。
もし命名規則変わるなら案内しないとですが、コードが簡単になるのなら飲めそう。
あ、公式actionじゃなければ依存すべきか一考した方が良いかも…?

@aoirint
Copy link
Member

aoirint commented Feb 24, 2025

メタデータを付ける機能

imageのタグを自動で決定する方法とは意図が違っていて、あまり正確なことがわかっていないですが、Dockerの出所証明(Provenance Attestation)という機能で、ビルドに使ったDockerfileの内容や、ビルドに使ったプラットフォーム(ここではGitHub Actions)、バージョン管理システム上のバージョン(ここではGitHub上のリポジトリURLやコミットハッシュ)などを記録する仕組みがあるらしく、その記録方法を意図していました。

ビルドに使っているdocker/build-push-actionでは、なにかしらの出所証明がデフォルトで記録されるようなので、何も気にしなくてよさそうなんですが、手動でイメージをいじると消えてしまうかもしれないので、こっちのイメージには付いているけれどこっちには付いていない、というような状態にはなりそうです。

そのアンバランスがちょこっと気になるくらいで、自動で付いてこないならいったん消えていていいんじゃないかなと思っています。

# docker buildx imagetools inspect "docker.io/voicevox/voicevox_engine:cpu-ubuntu20.04-0.22.2"
Name:      docker.io/voicevox/voicevox_engine:cpu-ubuntu20.04-0.22.2
MediaType: application/vnd.oci.image.index.v1+json
Digest:    sha256:0ff77b7b763ce37a51e8216a6036636a1ced004538baaaa858220f2b584c8727

Manifests:
  Name:        docker.io/voicevox/voicevox_engine:cpu-ubuntu20.04-0.22.2@sha256:eb3dde9e5b12eb64dcac7e79d858a92b8b9fcbf6ae5fec9b4cf7945e05c430be
  MediaType:   application/vnd.oci.image.manifest.v1+json
  Platform:    linux/amd64

  Name:        docker.io/voicevox/voicevox_engine:cpu-ubuntu20.04-0.22.2@sha256:f025de81064a92c7a6d93fe068aec5a9e0776839740e0a718b34c281a00752e2
  MediaType:   application/vnd.oci.image.manifest.v1+json
  Platform:    linux/arm64

  Name:        docker.io/voicevox/voicevox_engine:cpu-ubuntu20.04-0.22.2@sha256:43f5df53a9561bae55d1c3c94b7acdb34e97ab5e1ecc1881c5528beb72895259
  MediaType:   application/vnd.oci.image.manifest.v1+json
  Platform:    unknown/unknown
  Annotations:
    vnd.docker.reference.digest: sha256:eb3dde9e5b12eb64dcac7e79d858a92b8b9fcbf6ae5fec9b4cf7945e05c430be
    vnd.docker.reference.type:   attestation-manifest

  Name:        docker.io/voicevox/voicevox_engine:cpu-ubuntu20.04-0.22.2@sha256:be32bd1c592822250f0a1a7e592e0604b771641db84a3e04e01442eff7d3821e
  MediaType:   application/vnd.oci.image.manifest.v1+json
  Platform:    unknown/unknown
  Annotations:
    vnd.docker.reference.digest: sha256:f025de81064a92c7a6d93fe068aec5a9e0776839740e0a718b34c281a00752e2
    vnd.docker.reference.type:   attestation-manifest

Image

PNG

Image

@aoirint
Copy link
Member

aoirint commented Feb 24, 2025

imageのタグを自動で決定する方法

Docker公式actionのdocker/metadata-actionを使って、いまの命名規則に沿ったルールを作ることができれば、configジョブとtools/generate_docker_image_names.pyを減らせそうではあります。

バージョン文字列がPEP440準拠、レジストリがghcr.ioの場合、こういうコードになると思います:

- name: Generate Docker metadata for ghcr.io
  id: meta-ghcr
  uses: docker/metadata-action@v5
  with:
    images: ghcr.io/${{ github.repository }}
    tags: |
      type=ref,event=branch,suffix=-{{sha}}
      type=ref,event=branch
      type=pep440,pattern={{version}}
      type=pep440,pattern={{major}}
      type=pep440,pattern={{major}}.{{minor}}
      type=raw,value=latest,enable={{is_default_branch}}

- name: Generate Docker build cache source metadata
  id: meta-buildcache-source
  uses: docker/metadata-action@v5
  with:
    images: ghcr.io/${{ github.repository }}
    tags: |
      type=raw,value=main-buildcache,enable=${{ startsWith(github.ref, 'refs/tags/v') }}
      type=ref,event=branch,suffix=-buildcache

- name: Generate Docker build cache destination metadata
  id: meta-buildcache-destination
  uses: docker/metadata-action@v5
  with:
    images: ghcr.io/${{ github.repository }}
    tags: |
      type=ref,event=branch,suffix=-buildcache

- name: Generate Docker build cache metadata vars
  id: meta-buildcache-vars
  shell: bash
  env:
    DOCKER_METADATA_BUILDCACHE_SOURCE_OUTPUT_JSON: ${{ steps.meta-buildcache-source.outputs.json }}
    DOCKER_METADATA_BUILDCACHE_DESTINATION_OUTPUT_JSON: ${{ steps.meta-buildcache-destination.outputs.json }}
  run: |
    {
      echo "cache-from<<EOF"
      for tag in $(jq -r '.tags[]' <<< "$DOCKER_METADATA_BUILDCACHE_SOURCE_OUTPUT_JSON"); do
        echo "type=registry,ref=${tag}"
      done
      echo "EOF"
    } >> $GITHUB_OUTPUT

    {
      echo "cache-to<<EOF"
      for tag in $(jq -r '.tags[]' <<< "$DOCKER_METADATA_BUILDCACHE_DESTINATION_OUTPUT_JSON"); do
        echo "type=registry,ref=${tag},mode=max"
      done
      echo "EOF"
    } >> $GITHUB_OUTPUT

@Hiroshiba
Copy link
Member Author

メタデータを付ける機能

おーなるほどです!!
おっしゃるとおり、まあ自動でメタデータを付けてくれるならそれに任せて、付けてくれないなら一旦放置でも良いのかなと思いました!!

imageのタグを自動で決定する方法

なるほどーーー!!
・・・・・・思った以上に複雑ですね!!!
actionsの出力を別のactionsに渡してー、ということをしないといけなくなってこうなるのかぁ。

個人的にはpythonだったほうがメンテしやすいかもとか思いました!!
もっとデフォルトの設定とかを使える命名規則だったら話が変わってたかもですが、まあ仕方なさそう。

検討してくださってありがとうございます!
特に拘りなければ今のpythonファイル+configステップが良いのかなと思いました・・・!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
OS 依存:linux Linux に依存した現象 バグ
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants