コンテナイメージを小さくするために

CIの時間を短くする活動を行っており, 特にその一部のアプリケーションコンテナビルドの改善について書きたいと思います.

TL;DR

コンテナイメージを小さくするのは pull / push のコストを減らすため
ベースイメージを小さいものにする (ex. alpine linux, distroless)
Multi-stage Buildsを活用する
イメージに不要なファイルが含まれていないかを確認する. dlayer

コンテナイメージを小さくするために

なぜ小さくするのか

pull / pushのコストを減らすためです. CIの時間を短くするという文脈においては

成果物の push
依存イメージの pull (docker-compose を用いたテストなど)
docker build

が主な改善対象になります.

(1), (2) に関してはコンテナイメージを小さくすることで直接的な効果があります. とはいえマネージドなコンテナレジストリを使っていることが多いと思いますし, クラウド内の内部通信なのでそれなりに大きなイメージでない限りあまり効果はないかもしれません.

(3) が CI の中で結構な割合を占めることになると思います. docker には build のための cache 機構が存在しますが状態を保持しない CI においては使うことができません. 状態を保持しない環境においても cache を使えるように --cache-from というオプションが存在します. --cache-from は手元で build していないイメージを cache の対象とするためのオプションで pull と組み合わせると CI 上でも docker の build cache の機構を使うことができます.

詳しくは以下を参照ください.

コンテナの build については Container Buildの話
docker build cache についてはちゃんと理解するdocker build cache - 薄いブログ
cache-from についてはなぜ cache-from を指定しなければいけないか - 薄いブログ

どうやって小さくするか

(2018/12時点で)よくインターネット上で見られた方法として

ベースイメージを小さいものにする
- Alpine Linux
  - Alpine Linuxベースのイメージが提供されている場合も多いですが, glibc ではなく musl なので glibc でしか動かないソフトウェアや musl が嫌いな人間は使わない感じになっています.
- Distroless
  - こっちはglibcなどをgoogleがメンテナンスしてくれる軽量の実行環境のみが存在するイメージです. 基本的にタグは打たれずlatestのみのような運用がなされています. 思想に共感できたり, glibcを使いたい場合などに使う感じです.
apk --no-cacheをつけたり/tmpを最後に消すようにしたり, apk add --virtual fooを使ってコマンドの最後に削除したりする
Multi-stage Buildsを使う
レイヤーの数を少なくする

などがありました. しかし何故小さくなるかに触れている文献を当時(2018/12)はあまり見ることができませんでした.

ベースイメージを小さくする

ベースイメージを小さくするというのは比較的簡単にできる解決策です.

ですがAlpine等の環境は慣れ親しんでいない人が多いので思わぬ落とし穴にハマりがちです, 運用しやすさなどを考慮して選択すると良いです.

不要なキャッシュやパッケージを削除する

apk --no-cache などの環境ごとのパッケージマネージャーのキャッシュをオフにするオプションは毎回調べる, もしくは覚えることになります.

外部に公開するイメージでもない限り無視しても問題ない程度の大きさであることが多いです.

不要なパッケージの削除に関しては docker のレイヤーの仕組み上 RUN を一つにまとめないとレイヤーに残ってしまうので一つにまとめなければいけなくなります, これによる Dockerfile のメンテナンス性の低下を考えると後述の Multi-stage Buildsの活用のほうが良いと思います.

orisano/minid の様に RUN を自動でまとめるアプローチなどもありますがCIのパイプラインが複雑になりがちです.