Posted:
| Categories:
docker
| Tags:
docker,
Dockerfile,
Ubuntu
前提
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...Posted:
| Categories:
docker
| Tags:
docker,
Dockerfile
リファレンス
オフィシャル
Dockerfile の見直す時に参考にする場所
Dockerfile のベストプラクティス
その 1
)
下記以外にもあるが私が忘れやすいポイントだけ
- .dockerignore ファイルを使う
- レイヤの数を最小に
- 複数行の引数 <= 引数はアルファベット順に
- 構築キャッシュ <= docker build で –no-cache=true とすると既存キャッシュを使わない
- CMD <= 常に CMD [“executable”, “param1”, “param2”…] のような形式で使うべきです。
- WORKDIR <= 明確さと信頼性のため、常に WORKDIR からの絶対パスを使うべきです。
- Distroless が使えないか検討する
その 2
- LABEL <= ロジェクト内でのイメージ管理をしやすくしたり、ライセンス情報の記録や自動化の助けとするなど、さまざまな目的があります。
レイヤー削減の考え方
Dockerfile の layer を減らす時は、単純に RUN や COPY を結合すればよい、という話ではない。
layer 数を減らすと見た目はきれいになるが、巨大な layer にまとまると push/pull 時の差分再利用や、docker history での原因調査が悪くなることがある。
特に日常利用の CLI image のように、apt package、language runtime、npm global tool、クラウド CLI などを大量に含む image では、layer 数と image size は別の問題として扱う。
Read more...