tmygt
2024年3月21日 11時56分
お世話になっております。
ATDE上でArmadillo IoT G4用のコンテナをビルドしているのですが、ビルド中にストレージを大量に消費し、ビルドに失敗することがあり困っています。
dockerfileではベースイメージをpython:3.11-bookworm-slimにしていて、python:3.11-bookwormを使ったマルチステージビルドも行っています。
ビルド後のイメージは400MB程度になります。
この時、ストレージが14GB程度空いている状態でもpodman build 中に "no space left on device"がでてビルドに失敗します。
ビルド前のストレージ
atmark@atde9:~/$ df -h ファイルシス サイズ 使用 残り 使用% マウント位置 udev 3.9G 0 3.9G 0% /dev tmpfs 795M 1.3M 794M 1% /run /dev/mapper/atde9--vg-root 81G 64G 14G 83% / tmpfs 3.9G 168K 3.9G 1% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock /dev/sda1 470M 175M 271M 40% /boot vm_share 952G 822G 130G 87% /media/sf_vm_share tmpfs 795M 120K 795M 1% /run/user/1000
ビルド中のストレージの例
atmark@atde9:~/$ df -h ファイルシス サイズ 使用 残り 使用% マウント位置 udev 3.9G 0 3.9G 0% /dev tmpfs 795M 1.3M 794M 1% /run /dev/mapper/atde9--vg-root 81G 72G 5.3G 94% / tmpfs 3.9G 168K 3.9G 1% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock /dev/sda1 470M 175M 271M 40% /boot vm_share 952G 822G 130G 87% /media/sf_vm_share tmpfs 795M 120K 795M 1% /run/user/1000
定期的に podman image prune コマンドで不要なデータを削除したり、仮想ディスクを拡張して対応していますが、それでも失敗することが多いです。
ここまでストレージを使うものなのでしょうか?
また、ATDEのpodmanが古いことに起因していないかと考えています。ATDEのpodmanの差し替えを検討しているのですが、ATDEのpodmanはdebianのpodmanに対して何らかの変更がされていますか? (aarch64向けのイメージが作成できる点など、何らかの変更がされているのではと考えています。)
以上、よろしくお願いいたします。
コメント
tmygt
2024年3月21日 17時26分
マルティネさん
> 変更せずに、debian の podman のままです。
> aarch64 向けのイメージを生成するために binfmt-support と qemu-user-static のパッケージがインストールされていれば生成できるようになります。
ありがとうございます。
> ちなみに podman image prune は去年の10月に vscode プロジェクトのスクリプトに追加しましたが、参考までにどのプロジェクトとバージョンで開発をはじめたか覚えていますか？
> （プロジェクトディレクトリに scripts/VERSION があるかもしれません。プロジェクトのスクリプトの更新は考えていますが、まだできてません）
ABOSDEが登場する前に開発し始めているので、ABOSDEを使っていません。makefileでコンテナイメージのtar生成～SWU生成を実施しています。
> 14GB があれば充分すぎるほどビルドできるはずですね。
やはり一般的にはここまでストレージを使わないんですね。
> お手数ですが、ビルドしているイメージについてもう少し教えていただけますでしょうか？
使っているDockerfileを抜粋したものを添付します。製品に関連する情報を消しているのであまり参考にならないかもしれません。。。
FROM --platform=arm64 docker.io/python:3.11-bookworm AS builder
WORKDIR /work
ENV LANG=C.UTF8
RUN { \
echo "deb http://ftp.jp.debian.org/debian/ bookworm main"; \
echo "deb http://security.debian.org/debian-security bookworm-security main"; \
echo "deb http://ftp.jp.debian.org/debian/ bookworm-updates main"; \
} > /etc/apt/sources.list
RUN apt-get update && apt-get install -y --no-install-recommends \
# ライブラリビルドに必要なパッケージをインストール
&& apt-get clean \
&& rm -rf /var/lib/apt/lists/*
# ソースコードからビルドする必要のあるPythonパッケージをビルド
COPY ./libs/hoge /work/hoge
COPY ./requirements.txt /work/requirements.txt
# wheelを作成し保存
RUN pip wheel --no-cache-dir --wheel-dir /work/wheels -r requirements.txt
FROM --platform=arm64 docker.io/python:3.11-slim-bookworm
ENV LANG=C.UTF8
RUN { \
echo "deb http://ftp.jp.debian.org/debian/ bookworm main"; \
echo "deb http://security.debian.org/debian-security bookworm-security main"; \
echo "deb http://ftp.jp.debian.org/debian/ bookworm-updates main"; \
} > /etc/apt/sources.list
# install runtime dependencies
RUN apt-get update && apt-get install -y --no-install-recommends \
# アプリケーション実行に必要なパッケージをインストール
&& apt-get clean \
&& rm -rf /var/lib/apt/lists/*
# builderからwheelをコピーしてインストール
COPY --from=builder /work/wheels /wheels
RUN pip install --no-cache /wheels/* && rm -r /wheelsただ、こちらの調査中にストレージが大量に空いたので、現象が発生しなくなりました。
調査の過程で、 buildah containers を実行したところ、大量にコンテナが残っていました。buildah rmi -f --pruneですべて削除したところ、ストレージがかなり空きました。
もともと podman image prune する際に -f を使っていなかったのがよくなかったかもしれません。
ストレージを大量に消費する問題は解決していないですが、ストレージの空け方はわかったので問題としては解決しそうです。
お騒がせしました。
at_dominique.m…
2024年3月21日 18時19分
tmygtさん
マルティネです。
> ABOSDEが登場する前に開発し始めているので、ABOSDEを使っていません。makefileでコンテナイメージのtar生成～SWU生成を実施しています。
了解です。
> > お手数ですが、ビルドしているイメージについてもう少し教えていただけますでしょうか？
> 使っているDockerfileを抜粋したものを添付します。製品に関連する情報を消しているのであまり参考にならないかもしれません。。。
そうですね、こちらでも確認しますが pip のビルドにすごくスペースが必要などなければ特に変わった内容はなさそうです…が、原因が分かりました。。ATDE では podman がデフォルトの 「vfs ドライバ」を使っていますが、それでは RUN/COPY 等のステップを実行する度にコンテナの全ストレージがコピーされますので、提供していただいた Dockerfile で docker.io/python:3.11-bookworm を使う場合にはすぐに 10GB を消費志手氏まします。
大変お手数をおかけしました、報告助かりました！今度の ATDE の更新で修正します。
overlayfs を使えば解決されますが、切り替えるとデーターを失いますのでコンテナイメージを一旦全て削除する必要があります。
以下の二つコマンドで切り替えできます：
$ podman system reset $ sudo apt install fuse-overlayfs # 確認 $ podman info | grep graphD graphDriverName: overlay
(新しい podman では fuse-overlayfs 無しで overlays を使えますがカーネル 5.13+ が必要なので ATDE では使用できません。現在の podman バージョンで fuse-overlayfs でいいです。参考 https://github.com/containers/storage/issues/1570 / https://github.com/containers/podman/issues/18968 )
ちなみにですが：
> # builderからwheelをコピーしてインストール > COPY --from=builder /work/wheels /wheels > RUN pip install --no-cache /wheels/* && rm -r /wheels
この COPY と RUN は別のレイヤーになってしまいますので、ファイルを削除してもスペースが戻りません。
新しい podman でしたら RUN --mount=type=bind,from=builder,source=/work/wheels,target=/wheels pip install ... でコピーせずにインストールできますが、今のバージョンでは buildah を使うしかないですね…
> > 調査の過程で、 buildah containers を実行したところ、大量にコンテナが残っていました。buildah rmi -f --pruneですべて削除したところ、ストレージがかなり空きました。
> > もともと podman image prune する際に -f を使っていなかったのがよくなかったかもしれません。
>
> 別の環境で確認しましたが、buildah containersで表示されるコンテナはpodman image prune -fでは削除されないようでした。
こちらについては正常です。
buildah containers は podman ps 同様な動作で、イメージではなく「起動中のコンテナ」として考えてください。
知っている限りでは削除は buildah でしかできません。
よろしくお願いします。
at_makoto.sato
2024年3月22日 9時27分
佐藤です。
> > 今度の ATDE の更新で修正します。
>
> ATDEに変更が入るとのことですが、既存のATDE環境でもapt での更新で適用されますか? 仮想マシンのリプレースが必要ですか?
以下のコマンドをあらかじめ実行済みのATDEをリリースするという意味でした。
ご自身の現在のATDE環境で手動で以下のコマンドを実行していただければ特に仮想マシンのリプレース等は不要です。
$ podman system reset $ sudo apt install fuse-overlayfs
> > ちなみにですが：
>
> buildah/新しいPodmanだとそういうことができるんですね。イメージサイズを小さくしたいと考えているので、利用を検討します。
at_dominique.m…
2024年3月21日 12時46分
tmygtさん
お世話になっています、
マルティネです。
逆順番で回答します
> また、ATDEのpodmanが古いことに起因していないかと考えています。ATDEのpodmanの差し替えを検討しているのですが、ATDEのpodmanはdebianのpodmanに対して何らかの変更がされていますか? (aarch64向けのイメージが作成できる点など、何らかの変更がされているのではと考えています。)
変更せずに、debian の podman のままです。
aarch64 向けのイメージを生成するために binfmt-support と qemu-user-static のパッケージがインストールされていれば生成できるようになります。
> 定期的に podman image prune コマンドで不要なデータを削除したり、仮想ディスクを拡張して対応していますが、それでも失敗することが多いです。
ちなみに podman image prune は去年の10月に vscode プロジェクトのスクリプトに追加しましたが、参考までにどのプロジェクトとバージョンで開発をはじめたか覚えていますか？
（プロジェクトディレクトリに scripts/VERSION があるかもしれません。プロジェクトのスクリプトの更新は考えていますが、まだできてません）
> ビルド後のイメージは400MB程度になります。
> この時、ストレージが14GB程度空いている状態でもpodman build 中に "no space left on device"がでてビルドに失敗します。
14GB があれば充分すぎるほどビルドできるはずですね。
参考までに、デフォルトの python-app の再ビルドをためしたところ手元の ATDE の空き状態は 5.8GB から、ビルド中に 5.3 まで下げて 5.8 に戻りました。イメージは 130MB なので 400MB のイメージに比べたら小さいですが、余裕を持って x4 にしても 2GB でビルドできるかなと考えています…
お手数ですが、ビルドしているイメージについてもう少し教えていただけますでしょうか？
（できれば再現できるディレクトリを共有いただければ一番ありがたいですが、ひとまず Dockerfile に変更を加えた場合の内容やパッケージリストがあれば試したみたいと思います）
よろしくお願いします。