Docker イメージ構築のパフォーマンスを向上させ、効率を 2 倍にする 2 つのヒント!

ほとんどの企業と同様に、当社では製品で使用するすべてのコンポーネントに対して Docker イメージを構築しています。時間が経つにつれて、これらのイメージの一部はどんどん大きくなり、継続的インテグレーション (CI) ビルドはどんどん長くなりました。私の目標は、CI ビルドにかかる時間を 5 分以内にすることです。

生産性が低下する理由は次のとおりです。

• 開発者はビルドが完了するのを待って時間を無駄にします。
• 開発者は新しいタスクの作業を開始し、後で戻る必要があります。これにはより多くのコンテキスト切り替えが必要となり、一般的に非効率的です。

この記事では、ビルド時間を大幅に改善する 2 つの小さな改善を適用しました。 2 つの改善点を導入する前に、まず次のような Dockerfile の作成に関するベスト プラクティスに従っていることを確認してください。

• レイヤーの数を最小限に抑える
• マルチステージビルドの使用
• 最小限のベースイメージを使用する
• …

Buildkit と Buildx

Buildkit と Buildx について説明します。これら 2 つの用語は互換的に使用されることが多いですが、まったく同じではありません。この記事を書く前は、私もこの2つの違いを完全に理解していませんでした。

ビルドキット

Buildkit は、従来の Docker ビルダーに代わる改良されたバックエンドです。 2018 年から Docker にパッケージ化され、Docker Engine 23.0 のデフォルト ビルダーになりました。

Buildkit は多くの便利な機能を提供します:

• キャッシュ機能の改善
• 異なるレイヤーの同時構築
• ベースイメージの遅延プル (Buildkit 0.9 以上)

Buildkit を使用すると、docker build コマンドの出力がよりクリーンで構造化されていることに気づくはずです。

Docker バージョン 23.0 より前のバージョンの場合、Buildkit を使用する一般的な方法は、Buildkit パラメータを次のように設定することです。

 `--build-arg BUILDKIT_INLINE_CACHE=1`

これにより、インライン キャッシュが有効になり、ビルド プロセスが大幅に高速化されます。ただし、これは Docker バージョン 23.0 未満では使用できません。

 DOCKER_BUILDKIT=1 docker build --platform linux/amd64 . -t someImage:someVersion DOCKER_BUILDKIT=1 docker push someImage:someVersion

ビルドx

Buildx は Docker のプラグインであり、これを使用すると Docker で Buildkit の機能を最大限に活用できます。これは、Buildkit が多くの新しい構成オプションをサポートしており、そのすべてを下位互換性のある方法で docker build コマンドに統合できないために作成されました。

Buildx はイメージのビルドに加えて、複数のビルダーの管理もサポートしています。これは、共有 Docker デーモンを変更しないため、継続的インテグレーションにおいて、さまざまな構成を持つ適切にスコープ設定された環境を定義する場合に非常に役立ちます。

次の手順に従って Buildx の使用を開始できます。

 docker buildx create --bootstrap --name builder docker buildx use builder

1. リモートキャッシュのメリット

ビルドを高速化する最初の方法は、イメージをリモート レジストリにキャッシュすることです。この方法では、ビルドが異なるマシンで実行される場合でも (CI では一般的)、ビルド キャッシュのメリットを享受できます。ほとんどの人は、イメージの新しいバージョンをビルドする前に、イメージの最新バージョンを取得します。これには、変更されていないレイヤーをキャッシュするという利点がありますが、最初に完全なイメージを取得するという犠牲が伴います。完全なイメージを取得するには時間がかかる場合があり、レイヤーが再利用できる保証はありません。説明には次のコマンドを使用します。

 docker pull someImage:latest || true docker build --platform linux/amd64 . \ -t someImage:someVersion \ -f Dockerfile \ --cache-from someImage:latest

Buildx を使用すると、キャッシュ情報をリモートの場所 (コンテナー レジストリ、BLOB ストレージなど) に保存できます。ビルダーは、指定されたレイヤーがすでに存在するかどうかを確認し、存在する場合は、そのレイヤーを再作成するのではなく再利用します。この機能は、レイヤーをローカルにプルしなくても実行できます。以下のように表示されます。

 docker buildx build --platform linux/amd64 . \ -t someImage:someVersion - push \ --cache-to type=registry,ref=someCachedImage:someVersion,mode=max --cache-from type=registry,ref=someCachedImage:someVersion

モード「max」は、レイヤーが最終イメージで使用されていない場合でも (たとえば、マルチステージ ビルドを使用する場合)、各レイヤーのビルド情報を保存することを意味します。デフォルトでは、最終イメージに存在するレイヤーに関するビルド情報のみを保存するモード「min」が使用されます。

キャッシュの特殊なケースは、キャッシュされたデータを「インライン」で保存することです。つまり、イメージと一緒にキャッシュされるということです。このオプションは、Buildx なしで Buildkit を使用する場合にもサポートされます。これは、マルチステージ ビルドを使用する場合にはさらに困難であり、ビルド成果物の出力とキャッシュを明確に区別しません。キャッシュ データを「インライン」で保存するコマンドは次のとおりです。

 docker buildx build - platform linux/amd64 . \ -t someImage:someVersion --push \ --cache-to type=inline,mode=max \ --cache-from someImage:somePreviousVersion

2. 画像にファイルを追加する新しい方法

Docker は Dockerfile 構文の新しいバージョン、#syntax=docker/dockerfile:1.4 を導入しました。 COPY および ADD コマンドの追加のリンク オプションをサポートします。

以前は、COPY または ADD コマンドを使用すると、ビルダーは新しいスナップショットを作成し、新しいファイルを既存のファイル システムにマージしていました。そのため、この操作を実行する前に親レベルが存在している必要があります。そうでない場合、ターゲット ディレクトリがまだ存在しない可能性があります。最終イメージ (ビルド コマンドの結果) は、対応するスナップショット間の差異を含む各レイヤーの tarball で構成されます。

 FROM baseImage:version COPY binary /opt/

リンク オプションを使用すると、新しいファイルは独自のスナップショットに配置され、前のレイヤーに依存しなくなります。リンクされたファイルは独自の tarball に保存され、次の図に示すように、既存のファイル システムに依存せずに異なる tarball がリンクされます。

 # syntax=docker/dockerfile:1.4 FROM baseImage:version COPY [--chown=<user>:<group>] [--chmod=<perms>] --link binary /opt/

主な利点は、ファイルが以前のレイヤーに依存しなくなることです。ファイルが変更されていない限り、親レイヤーが変更されてもレイヤーを再利用できます。

これにより、複数レイヤーのデータコピーを並行して実行できるようになるため、ビルド速度も向上します。

結論は

上記2つの方法により、画像構築速度が1倍に向上しました。