Dockerビルドの最適化分析についてお話しましょう

この記事では、Docker イメージの開発とビルド プロセスを最適化するのに役立つ、見落とされがちな概念について説明します。

[[436579]]

まず、Docker ビルド プロセスの簡単な説明から始めましょう。これは、Docker CLI ツールを使用して docker build コマンドを実行することによってトリガーされるプロセスです。

docker build コマンドは、Dockerfile ファイルに指定された指示に従って Docker イメージを構築します。 Dockerfile は、イメージを組み立てるためにユーザーがコマンド ラインで呼び出すすべての順序付けられたコマンドが含まれるテキスト ドキュメントです。

Docker イメージは読み取り専用レイヤーで構成されています。各レイヤーは Dockerfile 命令を表します。レイヤーは互いに積み重ねられ、各レイヤーは前のレイヤーよりも段階的に改善されます。これらのレイヤーは、一般的にキャッシュの一種と考えることができます。変更ごとに更新するのではなく、変更されたレイヤーのみを更新します。

次の例は、Dockerfile の内容を示しています。

 registry.docker.com/baseimg/centos7-jdk8:latestから
 
メンテナー Luga "[email protected]" ;  
 
 mkdir -p /tools/apps/{microserice} を実行します。 
 
 mkdir -p /tools/apps/{microserice}/cache を実行します。 
 
 {microserice}.jar /tools/apps/{microserice}/{microserice}.jarを追加します
 
エクスポーズ9999 
 
 ENV TZ 「アジア/上海」   
 
 ENTRYPOINT [ "java" 、 "-Djava.security.egd=file:/dev/./urandom -Djava.awt.headless=true -Denv=DEV -Dapollo.cluster=DEFAULT -Dspring.profiles.active=prm -Dfile.encoding=utf-8" 、 "-jar" 、 "/tools/apps/{microserice}/{microserice}.jar" ]

このファイル内の各命令は、Docker イメージ内の個別のレイヤーを表します。各指示の簡単な説明は次のとおりです。

• FROM: JDK からレイヤー Docker イメージを作成します (ここでのイメージは Docker Hub から直接取得されるのではなく、ソース コードに基づいてカスタマイズされます)
• COPY: Dockerクライアントの現在のディレクトリからファイルを追加する
• 実行: makeを使用してアプリケーションをビルドする
• CMD: コンテナ内で実行するコマンドを指定します

上記のコマンドラインを元に、ビルドプロセス中に上記コマンドを実行すると、Docker イメージ内にレイヤーが作成され、完全な Docker イメージが誕生します。しかし、実際のプロジェクト活動においては、ビジネスシナリオのニーズを満たすために、パフォーマンス、安定性、セキュリティなどの面で、作成した Docker イメージを継続的に調整し、最適化する必要があります。

イメージを効率的にビルドするために、Docker ビルド プロセスの最適化のヒントをいくつか紹介します。

一時コンテナ

Dockerfile によって定義されたイメージは、短命のコンテナを生成します。この文脈では、エフェメラル コンテナーとは、一時停止して破棄し、その後再構築して、最小限のセットアップと構成を使用して新しく生成されたコンテナーに置き換えることができるコンテナーです。一時的な容器は使い捨てとみなすことができます。各インスタンスは新規であり、以前のコンテナ インスタンスとは接続されていません。 Docker イメージを開発するときは、できるだけ多くのアドホック パターンを活用する必要があります。

不要なパッケージを削減

不要なファイルやパッケージのインストールは避けてください。 Docker イメージはスリムに保つ必要があります。これにより、移植性が向上し、ビルド時間が短縮され、複雑さが軽減され、ファイル サイズが削減されます。たとえば、ほとんどの場合、コンテナーにテキスト エディターをインストールする必要はありません。不要なアプリケーションやサービスはインストールしないでください。

.dockerignore ファイルの実装

.dockerignore ファイルは、その中で宣言されたパターンに一致するファイルとディレクトリを除外します。これにより、不必要な大容量または機密性の高いファイルやディレクトリがデーモンに送信され、パブリック イメージに追加されることを回避できます。

ソース リポジトリを再構築せずにビルドに関係のないファイルを除外するには、.dockerignore ファイルを使用します。このファイルは、.gitignore ファイルと同様の除外パターンをサポートします。

複数行のパラメータの並べ替え

可能であれば、複数行のパラメータを英数字順に並べ替えて、後からの変更を簡素化します。これにより、パッケージの重複を回避し、リストの更新が容易になります。

分離されたアプリケーション

他のアプリケーションに依存するアプリケーションは、「結合」されているとみなされます。場合によっては、同じホストまたはコンピューティング ノードでホストされることもあります。これはコンテナ以外のデプロイメントでは一般的ですが、マイクロサービスでは、各アプリケーションは独自の個別のコンテナ内に存在する必要があります。アプリケーションを複数のコンテナに分離すると、水平方向のスケーリングとコンテナの再利用が容易になります。たとえば、分離された Web アプリケーション スタックは、それぞれ独自のイメージを持つ 3 つの個別のコンテナー (Web アプリケーションの管理用、データベースの管理用、メモリ内キャッシュ用) で構成される場合があります。各コンテナを 1 つのプロセスに制限するのが良い経験則です。ビジネス ルールに従って、コンテナーをクリーンかつモジュール化された状態に保ちます。次に、コンテナが相互に依存している場合は、Docker コンテナ ネットワークを使用して、それらのコンテナが通信できることを確認できます。

レイヤーの数を最小限に抑える

レイヤーは、RUN、COPY、ADD コマンドのみを使用して作成できます。その他の手順は一時的な中間イメージを作成するだけであり、最終的にはビルドのサイズが増加することはありません。可能であれば、最終イメージのサイズを増やすことなく、ビルド プロセス中に追加のツールやデバッグ情報を含めることができます。

ビルドキャッシュを活用する

イメージをビルドする際、Docker は Dockerfile 内の命令をステップ実行し、各命令を順番に実行します。各命令ごとに、Docker は新しい重複イメージを作成する代わりに、使用する既存のイメージをキャッシュで検索します。

Docker イメージは通常、構築プロセス中に次の基本ルールに従います。

1. すでにキャッシュ内にある親イメージから開始し、次の命令をそのベースイメージから派生したすべての子イメージと比較し、そのうちの 1 つがまったく同じ命令を使用して構築されたかどうかを確認します。そうでない場合、キャッシュは無効になります。ほとんどの場合、Dockerfile 内の指示をサブイメージの 1 つと比較するだけで十分です。

2. ADD および COPY 命令の場合、イメージ内のファイルの内容がチェックされ、各ファイルのチェックサムが計算されます。通常、これらの検証マークでは、ファイルの最終変更時刻と最終アクセス時刻は考慮されません。キャッシュ検索中に、チェックサム フラグが既存のイメージ内のチェックサム フラグと比較されます。ファイル内の何か（コンテンツやメタデータなど）が変更されると、キャッシュは無効になります。

3. ADD コマンドと COPY コマンドを除き、キャッシュ チェックではコンテナー内のファイルを調べてキャッシュが一致するかどうかは判断されません。たとえば、RUN apt-get -y update コマンドを処理する場合、コンテナ内の更新されたファイルはチェックされず、キャッシュ ヒットがあるかどうかが判断されません。この場合、コマンド文字列を使用して一致を検索します。

4. キャッシュが無効化されると、後続のすべての Dockerfile コマンドは新しいイメージを生成し、キャッシュを使用しなくなります。

CI パイプラインでの Docker イメージ ビルドの最適化

前のセクションで説明したすべての最適化の概念は、CI パイプラインでの実装に有効です。特にキャッシュ。 Dockerfile が変更された場合でも、キャッシュを活用することがビルド時間を短縮する最善の方法です。これは CI パイプラインの一部としてどのように機能しますか?ビルド ジョブのランタイムとして Docker Executor を使用する場合、Docker Layer Cache (DLC) と呼ばれる機能を利用してビルドを高速化できます。

DLC は、Docker イメージの構築が CI プロセスの通常の一部である場合に最適な機能です。 DLC はジョブで作成されたイメージ レイヤーを保存します。 DLC は、ジョブ中に構築された Docker イメージの個々のレイヤーをキャッシュし、毎回イメージ全体を再構築するのではなく、後続の CircleCI 実行で変更されていないイメージ レイヤーを再利用します。

Dockerfile がコミットされる回数が少ないほど、イメージのビルド ステップの実行速度が速くなります。 DLC は、マシン エグゼキュータとリモート Docker 環境 (setup_remote_docker) の両方で使用できます。 DLC は、 docker build 、 docker compose 、または同様の Docker コマンドを使用して独自の Docker イメージを作成する場合にのみ役立ち、すべてのビルドの初期環境の起動にかかる時間を短縮するものではないことに注意してください。