Tag: Dockerfile

cli-tool-docker のイメージサイズ調査

前提

cli-tool-docker は日常作業用の CLI をまとめたコンテナなので、単純なアプリ実行用イメージより大きくなる。 ただし Dockerfile の構造上、builder から成果物以外をコピーしてしまうと、マルチステージビルドの利点を失いやすい。

調査対象は Ubuntu 26.04 版のローカルビルド。

docker build --progress=plain -t cli-tool-docker:ubuntu-26.04-test .

実測値

削減前:

content size: 4.58GB
Docker 29 local disk usage: 18.1GB

削減後:

image id: 83cff82c6680
inspect Size: 2921887630 bytes
rootfs layer count: 30
content size: 2.92GB
Docker 29 local disk usage: 11.9GB

低リスクな layer 数削減後:

image id: d5d9b0068ed3
rootfs layer count: 25
Docker 29 local disk usage: 11.9GB

artifacts stage 集約後:

Read more...

docker

リファレンス

オフィシャル

Dockerfile の見直す時に参考にする場所

Dockerfile のベストプラクティス その 1 ) 下記以外にもあるが私が忘れやすいポイントだけ

  • .dockerignore ファイルを使う
  • レイヤの数を最小に
  • 複数行の引数 <= 引数はアルファベット順に
  • 構築キャッシュ <= docker build で –no-cache=true とすると既存キャッシュを使わない
  • CMD <= 常に CMD [“executable”, “param1”, “param2”…] のような形式で使うべきです。
  • WORKDIR <= 明確さと信頼性のため、常に WORKDIR からの絶対パスを使うべきです。
  • Distroless が使えないか検討する

その 2

  • LABEL <= ロジェクト内でのイメージ管理をしやすくしたり、ライセンス情報の記録や自動化の助けとするなど、さまざまな目的があります。

レイヤー削減の考え方

Dockerfile の layer を減らす時は、単純に RUNCOPY を結合すればよい、という話ではない。 layer 数を減らすと見た目はきれいになるが、巨大な layer にまとまると push/pull 時の差分再利用や、docker history での原因調査が悪くなることがある。

特に日常利用の CLI image のように、apt package、language runtime、npm global tool、クラウド CLI などを大量に含む image では、layer 数と image size は別の問題として扱う。

Read more...