Docker のマルチステージイメージ構築を理解する

Docker テクノロジーは、2013 年の誕生以来 4 年以上にわたって存在しています。日常の開発作業で Docker テクノロジーを受け入れて使用してきた開発者にとって、Docker イメージの構築は当たり前のことになっています。しかし、これは Docker のイメージ構築メカニズムが比較的完璧であることを意味するのでしょうか?いいえ、Docker の担当者はイメージ構築メカニズムを継続的に最適化しています。今年リリースされた Docker 17.05 バージョン以降、Docker はコンテナ イメージのマルチステージ ビルドのサポートを開始しました。

多段階イメージ構築とは何ですか?概念を直接定義するのはあまりにも唐突なので、ここでは秘密にしておきましょう。まず、日常の開発で使用されるイメージ構築方法と、イメージ構築で遭遇する問題から始めましょう。

1. 同型画像の構築

イメージを構築する際の一般的なシナリオは、アプリケーションが開発者自身の開発マシンまたはサーバー上で直接コンパイルされ、コンパイルされたバイナリ プログラムがイメージにインストールされるというものです。このような状況では通常、コンパイル環境がイメージで使用されるベース イメージと互換性があることが必要です。たとえば、Ubuntu 14.04 でアプリケーションをコンパイルし、Ubuntu シリーズのベースイメージに基づいたイメージにアプリケーションを配置します。アプリケーションのコンパイル環境は、それがデプロイされ実行される環境と互換性があるため、私はこの種のビルドを「同型イメージ ビルド」と呼んでいます。つまり、Ubuntu 14.04 でコンパイルしたアプリケーションは、ubuntu:14.04 以降のバージョン (例: 16.04、16.10、17.10 など) に基づくベース イメージでほぼシームレスに実行できます。ただし、Centos などの互換性のないベース イメージでは実行に失敗する可能性があります。

1. 均質画像構築の例

ここでは、均質なイメージを構築する例を示します (以降の章もこの例に基づいています)。注: コンパイル環境は、Ubuntu 16.04 x86_64 仮想マシン、Go 1.8.3、Docker 17.09.0-ce です。

Go で最も一般的な http サーバーを例として使用してみましょう。

 // github.com/bigwhite/experiments/multi_stage_image_build/isomorphism/httpserver.go
パッケージメイン
 
輸入 （
 「ネット/http」  
 "ログ"  
 「fmt」  
 ） 
 
 func home(w http.ResponseWriter, req *http.Request) {
        w.Write([]byte( "このウェブサイトへようこそ！\n" ))
 } 
 
関数main() {
        http.HandleFunc( "/" , ホーム)
        fmt.Println( "Webサーバーの起動" )
        fmt.Println( " -> ポート:1111 でリッスン" )
        エラー:= http.ListenAndServe( ":1111" 、nil)
        err != nil の場合 {
                log.Fatal( "ListenAndServe:" , err)
        }
 }

このプログラムをコンパイルします:

 # ビルド -o myhttpserver httpserver.go
 # ./myhttpserver
ウェブサーバーの起動
  ->ポート:1111でリッスン

この例は、数行のコードしかないため単純に見えますが、Go の net/http パッケージは、多くのシステム コールを含む多くの作業を最下層で実行します。これは、アプリケーションとオペレーティング システム間の「結合」を反映するもので、以降の説明で反映されます。次に、このプログラム用の Docker イメージを構築し、このイメージに基づいて myhttpserver コンテナを起動します。ベースイメージとしてubuntu:14.04を選択します。

 // github.com/bigwhite/experiments/multi_stage_image_build/isomorphism/Dockerfile
 ubuntu:14.04から
 
コピー ./myhttpserver /root/myhttpserver
 chmod +x /root/myhttpserver を実行します。 
 
ワークディレクトリ /root
エントリポイント [ "/root/myhttpserver" ]

ビルドを実行します。

ビルドが成功すると、リポジトリは更新されます。
ビルド コンテキストを Docker デーモンに送信5.894MB
ステップ 1/5: ubuntu:14.04から
---> dea1945146b9  
ステップ 2/5: ./myhttpserver /root/myhttpserver をコピーします。
 ---> 993e5129c081  
ステップ 3/5: chmod +x /root/myhttpserver を実行します。
 ---> 104d84838ab2 で実行中 
 ---> ebaeca006490  
中間コンテナ 104d84838ab2 を削除
ステップ 4/5: WORKDIR /root
 ---> 7afdc2356149  
中間コンテナの取り外し 450ccfb09ffd
ステップ 5/5: ENTRYPOINT /root/myhttpserver
 ---> 3182766e2a68 で実行中 
 ---> 77f315e15f14  
中間コンテナ 3182766e2a68 を削除しています
77f315e15f14 を正常に構築しました
myrepo/myhttpserver:latest のタグ付けに成功しました
 
 # Docker イメージ
リポジトリ タグ イメージ ID 作成サイズ 
 myrepo/myhttpserver 最新 77f315e15f14 18 秒前 200MB 
 
 # docker 実行 myrepo/myhttpserver
ウェブサーバーの起動
  ->ポート:1111でリッスン

上記は最も基本的なイメージ構築方法です。

次に、次の要件に遭遇する可能性があります。

* Go プログラムのビルド環境の設定は、特に多くのサードパーティのオープンソース パッケージに依存する Go アプリケーションの場合、時間がかかることがあります。パッケージのダウンロードには長い時間がかかる場合があります。 Go プログラム構築のために、これらすべての変更可能なものをビルダー イメージにパッケージ化するのが最善です。

* 上記で作成した myrepo/myhttpserver イメージのサイズは 200 MB であり、少し「大きすぎる」ようです。各ホストノード上の Docker にはイメージレイヤーをキャッシュする機能がありますが、より簡潔でコンパクトなイメージを構築したいと考えています。

2. Golang ビルダーイメージの使用

Docker Hub は、Go 開発環境を備えた公式の Golang イメージ リポジトリを提供します。この Golang ビルダー イメージを直接使用して、アプリケーション イメージを構築できます。サードパーティのパッケージに大きく依存する一部の Go アプリケーションでは、この golang イメージをベース イメージとして使用して、専用のビルダー イメージをカスタマイズすることもできます。

golang:latest ベースイメージに基づいて golang-builder イメージをビルドします。 golang-builder イメージをビルドするために Dockerfile.build を記述します。

 // github.com/bigwhite/experiments/multi_stage_image_build/isomorphism/Dockerfile.build
 golang :latest から
 
ワークディレクトリ /go/src
 httpserver.go をコピーします。 
 
 go build -o myhttpserver ./httpserver.go を実行します。

同じディレクトリに golang-builder イメージをビルドします。

ビルドが成功すれば、Docker は再起動します。
ビルド コンテキストを Docker デーモンに送信5.895MB
ステップ 1/4: golang:latestから
---> 1a34fad76b34  
ステップ 2/4: WORKDIR /go/src
 ---> 2361824677d3  
中間コンテナ 01d8f4e9f0c4 を削除
ステップ 3/4: httpserver.go をコピーします。
 ---> 1ff14bb0bc56  
ステップ 4/4: go build -o myhttpserver ./httpserver.go を実行します。
 ---> 37a1b76b7b9e で実行中 
 ---> 2ac5347bb923  
中間コンテナ 37a1b76b7b9e を削除しています
2ac5347bb923 の構築に成功しました
myrepo/golang-builder:latest のタグ付けに成功しました
 
リポジトリ タグ イメージ ID 作成サイズ 
 myrepo/golang-builder 最新 2ac5347bb923 3 分前 739MB

次に、golang-builder で構築された myhttpserver に基づいて最終的なアプリケーション イメージを構築します。

 # docker作成  --name appsource myrepo/golang-builder:latest  
 # docker cp appsource:/go/src/myhttpserver ./
 # docker rm -f アプリソース
# docker rmi myrepo/golang-builder:latest
ビルドが成功すると、リポジトリは更新されます。

このコマンドのロジックは、golang-builder イメージに基づいて起動されたコンテナ appsource からビルドされた myhttpserver をホストの現在のディレクトリにコピーし、その後、上記でビルドされた一時コンテナ appsource と golang-builder イメージを削除することです。最後の手順は最初の例と同じで、ローカル ディレクトリに構築された myhttpserver に基づいて最終イメージを構築します。便宜上、この一連のコマンドを Makefile に入れることもできます。

3. 小さめのアルプスの画像を使用する

ビルダー イメージは、最終的なアプリケーション イメージの重量を軽減するのに役立ちません。 myhttpserver イメージのサイズは 200 MB のままです。 「軽量化」するには、ベースイメージを小さくする必要があり、アルパインを選択しました。アルパイン画像のサイズは4M未満です。アプリケーションのサイズを追加すると、最終的なアプリケーション イメージのサイズは 20 MB 未満に縮小されると推定されます。

ビルダーイメージを結合するには、Dockerfile のベースイメージを alpine:latest に変更するだけです。

 // github.com/bigwhite/experiments/multi_stage_image_build/isomorphism/Dockerfile.alpine 
 
アルパインより:最新
 
コピー ./myhttpserver /root/myhttpserver
 chmod +x /root/myhttpserver を実行します。 
 
ワークディレクトリ /root
エントリポイント [ "/root/myhttpserver" ]

アルパイン バージョンのアプリケーション イメージをビルドします。

ビルド 1.0.1 以降を実行している場合は、次のコマンドを実行します。
ビルド コンテキストを Docker デーモンに送信6.151MB
ステップ 1/5: alpine:latestから
---> 053cde6e8953  
ステップ 2/5: ./myhttpserver /root/myhttpserver をコピーします。
 --->ca0527a62d39  
ステップ 3/5: chmod +x /root/myhttpserver を実行します。
 ---> 28d0a8a577b2 で実行中 
 ---> a3833af97b5e  
中間コンテナ 28d0a8a577b2 を削除しています
ステップ 4/5: WORKDIR /root
 ---> 667345b78570  
中間コンテナを削除しています fa59883e9fdb
ステップ 5/5: ENTRYPOINT /root/myhttpserver
 ---> adcb5b976ca3 で実行中 
 ---> 582fa2aedc64  
中間コンテナ adcb5b976ca3 を削除しています
582fa2aedc64 の構築に成功しました
myrepo/myhttpserver-alpine:latest のタグ付けに成功しました
 
 # Docker イメージ
リポジトリ タグ イメージ ID 作成サイズ 
 myrepo/myhttpserver-alpine 最新 582fa2aedc64 4 分前 16.3MB

16.3MB、確かにサイズが小さくなりました!このイメージに基づいてコンテナを起動し、アプリケーションの実行に問題がないか確認します。

 # docker run myrepo/myhttpserver-alpine:latest
 standard_init_linux.go:185:実行 ユーザープロセスにより「そのようなファイルまたはディレクトリはありません」というメッセージが表示されました 

コンテナの起動に失敗しました。なぜ？ alpine イメージは ubuntu 環境と同じではないためです。これについては以下で詳しく説明します。

2. 異種画像構築

私たちのイメージ ビルダー: myrepo/golang-builder:latest は、golang:latest イメージに基づいています。 golang ベースイメージには、Dockerfile-debain.template と Dockerfile-alpine.template の 2 つのテンプレートがあります。 golang:latest は Debian テンプレートに基づいており、Ubuntu と互換性があります。構築された myhttpserver には、動的共有リンク ライブラリに対して次の条件があります。

 # ldd myhttpserver
    linux-vdso.so.1 => (0x00007ffd0c355000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ffa8b36f000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ffa8afa5000)
    /lib64/ld-linux-x86-64.so.2 (0x000055605ea5d000)

Debian ベースの Linux ディストリビューションは glibc を使用します。しかしアルパインは違います。 Alpine は musl libc の実装を使用します。したがって、上記のコンテナを実行すると、myhttpserver が依存する libc.so.6 が見つからないため、ローダーは終了に失敗します。

このようにビルド環境と実行環境が互換性のない状態を「異種イメージビルド」と呼びます。では、この問題をどう解決すればよいのでしょうか?続けましょう:

1. 静的ビルド

主流のプログラミング言語の中で、Go はすでに移植性の点で最高の言語の 1 つです。特に、ランタイムのすべての C コードが Go で書き直され、libc への依存が最小限に抑えられた Go 1.5 以降では、移植性がさらに向上しました。ただし、一部の機能では、C 実装と Go 実装の 2 つの実装バージョンがまだ提供されています。デフォルトでは、つまり CGO_ENABLED=1 の場合、プログラムとプリコンパイルされた標準ライブラリの両方が C 実装を使用します。この点に関する詳細な議論については、私の以前の記事「Go の移植性についても」を参照してください。ここでは詳細には触れません。したがって、異なる libc 実装を使用する Debian システムと Alpine システムの間には、当然ながら非互換性があります。この問題を解決するために、まず Go プログラムを静的にビルドし、次に静的にビルドされた Go アプリケーションを alpine イメージに配置することを検討します。

Dockerfile.build を変更し、Go ソース ファイルをコンパイルするときに CGO_ENABLED=0 を追加しましょう。

 // github.com/bigwhite/experiments/multi_stage_image_build/heterogeneous/Dockerfile.build 
 
 golang :latest から
 
ワークディレクトリ /go/src
 httpserver.go をコピーします。 
 
 CGO_ENABLED=0 を実行して go build -o myhttpserver ./httpserver.go

このビルダーイメージをビルドします:

ビルドが1.0.0.1の場合、Docker は.
ビルドコンテキストを Docker デーモンに送信4.096kB
ステップ 1/4: golang:latestから
---> 1a34fad76b34  
ステップ 2/4: WORKDIR /go/src
 ---> 593cd9692019  
中間コンテナ ee005d487ad5 を削除
ステップ 3/4: httpserver.go をコピーします。
 ---> a095eb69e716  
ステップ 4/4: CGO_ENABLED=0 を実行します go build -o myhttpserver ./httpserver.go
 ---> d9f3b3a6c36c で実行中 
 ---> c06fe8dccbad  
中間コンテナ d9f3b3a6c36c を削除しています
c06fe8dccbad を正常に構築しました
myrepo/golang- static -builder:latest のタグ付けに成功しました
 
 # Docker イメージ
リポジトリ タグ イメージ ID 作成サイズ 
 myrepo/golang- static -builder 最新 c06fe8dccbad 31 秒前 739MB

次に、golang-static-builder で構築された静的に接続された myhttpserver に基づいて、最終的なアプリケーション イメージを構築します。

 # docker作成  --name appsource myrepo/golang-static-builder:latest  
 # docker cp appsource:/go/src/myhttpserver ./
 # ldd myhttpserver
動的実行ファイルではない
# docker rm -f アプリソース
# docker rmi myrepo/golang- static -builder:latest
ビルド 1.0.1 以降を実行している場合は、次のコマンドを実行します。

新しいイメージを実行します。

 # docker run myrepo/myhttpserver-alpine:latest
ウェブサーバーの起動
  ->ポート:1111でリッスン

注: strace を使用すると、Go が静的にリンクするときに独自のランタイム実装のみを使用し、libc.a のコードを使用しないことを証明できます。

 # CGO_ENABLED=0 strace -f go build httpserver.go 2>&1 | grepオープン| grep -o '/.*\.a' > go- static -build-strace-file- open .txt

go-static-build-strace-file-open.txt ファイルを開き、その内容を確認します。 libc.a ファイルは見つかりません (Ubuntu では、libc.a は通常 /usr/lib/x86_64-linux-gnu/ にあります)。これは、go build が libc.a ファイルを開いてその中のシンボル定義を取得しようとしなかったことを意味します。

2. alpine golangビルダーを使用する

私たちの Go アプリケーションは、alpine ベースのコンテナーで実行されます。 alpine golang ビルダーを使用してアプリケーションをビルドできます (静的リンクなし)。前述したように、golang には alpine テンプレートがあります。

リポジトリ タグ イメージ ID 作成サイズ 
 golang alpine 9e3f14138abd 7日前 269MB

golang ビルダーの alpine バージョンの Dockerfile の内容は次のとおりです。

 //github.com/bigwhite/experiments/multi_stage_image_build/heterogeneous/Dockerfile.alpine.build 
 
 golang:alpineより
 
ワークディレクトリ /go/src
 httpserver.go をコピーします。 
 
 go build -o myhttpserver ./httpserver.go を実行します。

以降の操作は、前の golang ビルダーと同じです。alpine golang ビルダーを使用してアプリケーションをビルドし、alpine イメージに配置します。ここでは詳細には触れません。

3. 多段階イメージ構築：開発者エクスペリエンスの向上

Docker 17.05 より前では、上記のようにイメージを構築していました。異種イメージ ビルダー モードを使用する場合でも、2 つの Dockerfile を維持し、コンテナーからのアプリケーションのコピー、ビルド コンテナーのクリーンアップ、イメージのビルドなど、docker build コマンドの外部でいくつかの操作を実行する必要があることがわかります。 Docker コミュニティはこの問題を認識し、マルチステージ イメージ構築メカニズム (マルチステージ) を実装しました。

まず、上記の例のマルチステージ ビルドに使用される Dockerfile を見てみましょう。

 //github.com/bigwhite/experiments/multi_stage_image_build/multi_stages/Dockerfile  
 golang:alpineからビルダーとして 
ワークディレクトリ /go/src
 httpserver.go をコピーします。  
 go build -o myhttpserver ./httpserver.go を実行します。  
アルパインより:最新 
ワークディレクトリ /root/
 --from=builder /go/src/myhttpserver にコピーします。  
 chmod +x /root/myhttpserver を実行します。  
エントリポイント [ "/root/myhttpserver" ]

この Dockerfile の内容を読んだ後の第一印象は、前の 2 つの Dockerfile が結合され、各 Dockerfile が個別の「ステージ」になっているということです。確かにその通りですが、この Docker には、さまざまな「ステージ」間の接続を確立するための新しい構文形式もいくつかあります。このような Dockerfile については、次の点を知っておく必要があります。

• マルチステージ ビルドをサポートする Dockerfile は、複数のビルド ステージ間に内部接続を確立し、次のビルド ステージで前のビルド ステージの成果物を使用できるようにして、ビルド ステージのチェーンを形成します。
• マルチステージ ビルドの最終結果は 1 つのイメージのみであり、複数の冗長な一時イメージまたは一時コンテナー オブジェクトの生成を回避します。これはまさに必要なことであり、必要なのは結果だけです。

上記の例をマルチステージを使用して構築してみましょう。

ビルドが 0x80000000 の場合、このコマンドは実行されません。
ビルドコンテキストを Docker デーモンに送信3.072kB
ステップ 1/9: golang:alpineからビルダーとして
---> 9e3f14138abd  
ステップ 2/9: WORKDIR /go/src
 ---> キャッシュの使用 
 ---> 7a99431d1be6  
ステップ 3/9: httpserver.go をコピーします。
 ---> 43a196658e09  
ステップ 4/9: go build -o myhttpserver ./httpserver.go を実行します。
 ---> 9e7b46f68e88 で実行中 
 ---> 90dc73912803  
中間コンテナ 9e7b46f68e88 を削除しています
ステップ 5/9: alpine:latestから
---> 053cde6e8953  
ステップ 6/9: WORKDIR /root/
 ---> キャッシュの使用 
 ---> 30d95027ee6a  
ステップ 7/9: COPY --from=builder /go/src/myhttpserver.  
 ---> f1620b64c1ba  
ステップ 8/9: chmod +x /root/myhttpserver を実行します。
 ---> e62809993a22 で実行中 
 ---> 6be6c28f5fd6  
中間コンテナ e62809993a22 を削除
ステップ 9/9: ENTRYPOINT /root/myhttpserver
 ---> e4000d1dde3d で実行中 
 ---> 639cec396c96  
中間コンテナ e4000d1dde3d を削除
639cec396c96 の構築に成功しました
myrepo/myhttserver-multi-stage:latest のタグ付けに成功しました
 
 # Docker イメージ
リポジトリ タグ イメージ ID 作成サイズ 
 myrepo/myhttserver-multi-stage 最新 639cec396c96 約1時間前 16.3MB

この画像を実行してみましょう:

 # docker run myrepo/myhttserver-multi-stage:latest
ウェブサーバーの起動
  ->ポート:1111でリッスン

IV.まとめ

マルチステージイメージ構築により、開発者は Dockerfile を使用して一度に小さなイメージをより簡単に構築できるようになり、優れたユーザーエクスペリエンスが提供され、CI/CD などの自動化システムへの接続が容易になります。ただし、現在、マルチステージ ビルドは Docker 17.05 以降のバージョンでのみサポートされています。この機能を学習して練習したいが環境がない場合は、play-with-docker が提供する実験環境を使用できます。