docker slimでイメージサイズ軽量化
コンテナの中の色々不要なものを除いて新しくイメージを作ってくれたり分析してくれる
使い方:
code:bash
$ slim build --http-probe-off --include-bin /usr/local/bin/php <image>
--http-probe-off オンになってるとExposeされているポートに対して GET / をし、成功しないとビルド出来ないので必要ないアプリケーションならoffにしておく（大抵のアプリケーションは必要ない気もするが）
--include-bin では任意のバイナリを含めることができる
実際実行すると元のimage名に.slimを足した <image>.slim という名前のimageが作成される
code:bash
$ docker images
~~~
local/php.slim latest bd647cd78061 11 minutes ago 108MB local/php latest 6023214b9801 About an hour ago 1.31GB
実際に1GB程あるイメージをslim buildしたら108MB程になった
ほとんどCMDで指定されている実行ファイルのみで cd や ls もない割り切った構成となっている
code:bash
sh: 2: cd: can't cd to /root
基本的なコマンドもないのでDevContaienrで起動したらエラーになった
使用シチュエーションとしてベースイメージはそこそこのサイズがあるけどデプロイする時に最小化したいという用途が考えられる
ただ割り切りすぎて何か起こった時に調査もほとんど出来ないのはやはり最小化イメージの辛いところではある
またデプロイ前とデプロイ後が環境として大きく異なるとそれも切り分けの難しさに繋がりどうなんだろうなというところ
ローカル開発では多くのツールが通常必要であり本番環境に含まれない様々な依存が含まれる
環境一致と再現性の原則で開発と本番環境は可能な限り近くなることが望まれる
DevContainerのように開発ツールとコンテナランタイムの分離を行うのは開発ツールの分離という意味では正しい方向性ではあって、その包括的な仕組みを提供するのがコンテナベースでの開発の進むべき方向性だとは思う
ただDevContainerの体験は悪くないけどまだ重かったりツールチェインとして成熟しきっていないのでVSCodeだけでなくDevContainerの体験をよくするツールチェインが必要
恐らく用途としては単機能でデプロイされるようなコマンドやツールの最小化で一般的なそれなりの規模感の依存が絡み合ったサービスという感じはしない
ほどよく半分くらいに削減しつつ, アタックサーフェスを減らしセキュリティを向上しつつ機能性は損なわない程度のツールという落としどころのツールが世の中の大半のイメージ肥大アプリケーションでは需要があるところではある