943MBから6.34kBへ、コンテナサイズを縮小する課題

コンテナは私たちの生活に大きな利便性をもたらし、誰もがコンテナを気に入っています。ただし、コンテナも大量のスペースを消費し、数百メガバイトになることが多く、G を超えるイメージも一般的です。この記事では、コンテナの合理化の事例について学びます。一連の操作により、最終的に画像のサイズを 943 MB から 6.32 k に削減できます。

[[396110]]

概要

コンテナは、オペレーティングソフトウェアのバージョンとパッケージの依存関係に関連するすべての問題を解決する実用的な方法です。誰もがコンテナを好みますが、コンテナを使用すると、さまざまな大きくて乱雑な画像に直面することになります。スペースが限られている場合は、すぐにいっぱいになります。実際、画像サイズを縮小するためにいくつかの効果的な戦略を使用できます。

基本的な手順

指定されたポートを通じて Web サービスを提供できる HTTP アプリケーションコンテナー。

ボリュームのマウントは実行されません。

当初の計画

ベースライン画像サイズを取得するには、node.js を使用して、index.js へのアクセスのみを提供するシンプルなサーバーを作成します。

index.js コード:

定数fs = require ("fs");
定数http = require ('http');
 const server = http .createServer((req, res) = > {
 res.writeHead(200, { 'コンテンツタイプ': 'text/html' })
 fs.createReadStream('index.html').pipe(res)
 })
 server.listen(ポート, ホスト名, () = > {
 console.log(`サーバー: http://0.0.0.0:8080/`);
 });

このファイルは、公式の Node ベースイメージに基づいてイメージに組み込まれます。

ノード:14から
コピー 。 。
コマンド ["ノード", "index.js"]

コンパイル

docker build -t cchttp:01 ./

画像サイズは943MBです

合理化されたベースイメージ

画像をスリム化するための最も一般的で、最も単純で、最も明白な戦略の 1 つは、小さいベース画像を使用することです。 Node イメージには、スリムバリアント (Debian ベースですが、プリインストールされた依存関係が少ない) と Alpine Linux ベースの alpine バリアントがあります。

2 つのベースイメージは node:14-slim と node:14-alpine であり、イメージサイズはそれぞれ 167 MB と 116 MB に削減されます。

Docker イメージは階層化されているため、node.js は多くのレイヤーのイメージに依存する必要があります。現時点では、ソリューションを簡素化する以外にサイズを縮小する方法はありません。

言語を変更

さらに最適化するには、実行時の依存関係が少ないコンパイル言語が必要です。このとき、まず思い浮かぶのは間違いなく静的にコンパイルされる言語である Golang であり、これは一般的で良い選択肢です。 Golang での基本的な Web サービスコードは次のとおりです。

ウェブゴー:

パッケージメイン
輸入 （
 「fmt」
 "ログ"
 「ネット/http」
 ）
関数main() {
ファイルサーバー: = http .FileServer(http.Dir("./"))
 http.Handle("/", ファイルサーバー)
 fmt.Printf("ポート 8080 でサーバーを起動しています\n")
エラーの場合: = http .ListenAndServe(":8080", nil);エラー != ゼロ {
ログ.致命的(エラー)
 }
 }

次に、golang の公式ベースイメージを使用して、それをイメージにパッケージ化します。

 golang:1.14より
コピー 。 。
 go build -o server を実行します。
 CMD ["./server"]

Golang ベースのソリューションのイメージサイズは 818 MB で、それでもまだ非常に大きいです。

分析により、golang 基本イメージに多くの依存パッケージがインストールされていることがわかりました。これらの依存パッケージは、Go ソフトウェアを構築するときに便利ですが、すべてのランタイムに必要なわけではないので、ここで最適化を開始できます。

多段階ビルド

Docker は、必要なすべての依存関係を備えた環境でコードを簡単にビルドし、生成された実行可能パッケージを他のイメージに直接パッケージ化して使用できるようにするマルチステージビルドメカニズムをサポートしています。これにより、コンパイル時にはツールとパッケージが必要になるが、実行時にはパッケージは必要なくなるという問題が解決され、イメージサイズを大幅に削減できます。

注: Docker マルチステージビルドメカニズムは、Docker 17.05 で導入された新しい機能です。この機能を使用したい場合は、Docker バージョンを Docker 17.05 以上にアップグレードする必要があります。

マルチステージビルド Dockerfile へ:

 ＃＃＃コンパイル＃＃＃
 golang:1.14-alpine AS ビルダーから
コピー 。 。
 go build -o server を実行します。
 ＃＃＃走る＃＃＃
アルパインより:3.12
コピー--from = builder /go/server ./server
コピー index.html index.html
 CMD ["./server"]

 Docker イメージ

(⊙o⊙)おお、この戦略は効果的で、生成された画像はわずか13.2MBです。

スクラッチベースイメージと組み合わせた静的コンパイル

13M の画像はすでに非常に優れていますが、他の最適化手法もあります。 Docker の世界には、いくつかのベースイメージが存在します。これは 0 から始まるベースイメージです。このイメージには依存関係がなく、完全に 0 から始まるため、サイズも 0 から始まります。Linux には LFS と呼ばれるディストリビューションがあり、その正式名称は Linux From Scratch で、完全な OS をゼロからコンパイルすることを意味します。このスクラッチベース画像もこれを意味します。

スクラッチベースイメージで web.go の実行をサポートするには、コンパイルされたイメージに静的コンパイルフラグを追加して、すべての依存関係を実行中のイメージにパッケージ化できるようにする必要があります。

 ### コンパイル ###
 golang:1.14 からビルダーとして
コピー 。 。
 go build -o server を実行する \
 -ldflags "-linkmode 外部 -extldflags -static" \
 -ウェブゴー
＃＃＃走る＃＃＃
ゼロから
コピー--from = builder /go/server ./server
コピー index.html index.html
 CMD ["./server"]

上記のビルドプロセスでは、コードリンクプロセス中にモードが外部に設定され、-static によって外部リンカーがリンクされます。

最適化後の画像サイズは 8.65MB になります。

究極のキラー - アセンブリ言語

Golang で書かれたプログラムは少なくとも M 程度のサイズがあり、10 MB のイメージは合理化できる限界に達しているはずです。ただし、サイズを大幅に削減するために使用できる他のトリックはありますが、究極のキラーであるアセンブリ言語を使用する必要があります。最終的な解決策は、アセンブリで記述されたフル機能の http サーバー assmttpd を使用することです。そのソースコードは GitHub (github/nemasu/asmttpd) でホストされています。

また、マルチステージコンパイルアプローチを使用して、Ubuntu ベースイメージで依存関係をコンパイルし、それらを Scratch ベースイメージにパッケージ化して実行します。

 ＃＃＃コンパイル＃＃＃
 ubuntu:18.04 からビルダーとして
apt updateを実行する
apt install -y make yasm as31 nasm binutilsを実行します。
コピー 。 。
 RUN メイクリリース
＃＃＃走る＃＃＃
ゼロから
コピー--from = builder /asmttpd /asmttpd
コピー /web_root/index.html /web_root/index.html
コマンド ["/asmttpd", "/web_root", "8080"]

結果の画像サイズはわずか 6.34kB です。

次に、このイメージを使用してコンテナを実行します。