複数のコマンドを単一の RUN ステートメントにまとめてイメージ・サイズを小さくする

この例では、Node.jsなどのソフトウェアをコンテナー・イメージにインストールしなければなりません。Node.js の基本イメージを使用して、Node.js アプリケーションをビルドします。

Node.js を手動でインストールする場合は、次の Dockerfile 例を使用できます。

FROM ubuntu

RUN apt update
RUN apt upgrade -y
RUN apt install -y nodejs
RUN apt clean
RUN rm -rf /var/lib/apt/lists/\*

この例では、更新し、アップグレードし、Node.js をインストールし、クリーニングして、ファイルのキャッシュを削除するために、いくつもの RUN ステートメントが使用されています。 この一連のステートメントは正しいのですが、複数の RUN ステートメントを使用することは最良の実装方法ではありません。 Dockerfile ファイルが処理されるとき、Dockerfile ファイル内の各ステートメントが 1 つの層を形成します。 各層には、作成または更新されたファイルとともに、何が削除されたかについての情報も含まれています。 コンテナー・イメージはすべての層の集合です。 あるステートメントでファイルが追加され、2 つ目のステートメントでそのファイルが削除された場合、結果のイメージでは、最初のステートメントの層にまだファイルが含まれていて、2 つ目の層でそのファイルに削除済みのマークが付けられます。

ディスク・スペースを節約するには、単一の RUN ステートメントを指定することで、このコマンド・セットに対応する単一の層を作成するようにします。

FROM ubuntu

RUN apt update && apt upgrade -y && apt install -y nodejs && apt clean && rm -rf /var/lib/apt/lists/\*

1 行に 1 コマンドを記述する理解しやすい Dockerfile を維持するには、コードに改行を追加します。

FROM ubuntu

RUN \
    apt update && \
    apt upgrade -y && \
    apt install -y nodejs && \
    apt clean && \
    rm -rf /var/lib/apt/lists/\*

このタイプのステートメントを使用することにより、コンテナーのイメージ・サイズを約 174 MB から 147 MB ほどに縮小できます。 Ubuntu 基本イメージと Node.js パッケージは変わることがあるため、サイズ例は実際には異なる場合があります。

このタイプのベスト・プラクティスは、パッケージのインストールだけでなく、類似のタスクにも適用できます。 例えば、ソフトウェア・パッケージ (この場合も Node.js) のダウンロードと解凍は、次の例のようになります。

FROM ubuntu

RUN apt update
RUN apt upgrade -y
RUN apt install -y curl
RUN curl https://nodejs.org/dist/v16.14.2/node-v16.14.2-linux-x64.tar.gz -o /tmp/nodejs.tar.gz
RUN mkdir /opt/node
RUN tar -xzf /tmp/nodejs.tar.gz -C /opt/node --strip 1
RUN rm /tmp/nodejs.tar.gz
RUN apt remove -y curl
RUN apt clean
RUN rm -rf /var/lib/apt/lists/\*

rm コマンドは、ダウンロードされた nodejs パッケージを削除しますが、この場合も複数の RUN ステートメントが別々の層を形成します。 さらに、nodejs パッケージをダウンロードするために、curl パッケージが一時的にインストールされます。 curl パッケージ自体は後で削除されますが、暗黙的にインストールされたその依存関係は残り続けます。 より適切な Dockerfile は、次の例のようになります。

FROM ubuntu

RUN \
    apt update && \
    apt upgrade -y && \
    apt install -y curl && \
    curl https://nodejs.org/dist/v16.14.2/node-v16.14.2-linux-x64.tar.gz -o /tmp/nodejs.tar.gz && \
    mkdir /opt/node && \
    tar -xzf /tmp/nodejs.tar.gz -C /opt/node --strip 1 && \
    rm /tmp/nodejs.tar.gz && \
    apt remove -y curl && \
    apt auto-remove -y && \
    apt clean && \
    rm -rf /var/lib/apt/lists/\*

関連するコマンドは単一の RUN ステートメントにまとめられ、依存関係を削除するために apt auto-remove コマンドが追加されています。 この例では、イメージ・サイズが約 222 MB から 162 MB ほどに縮小されます。

ごく小さい基本イメージを使用する

前記の例では、Ubuntu を基本イメージとして使用しています。 このイメージには便利なユーティリティーが多数含まれていますが、基本イメージ内のユーティリティーが多いほど、基本イメージのサイズが大きくなります。 また、含めるユーティリティーが多いほど、セキュリティーの脆弱性が存在する可能性が高まり、そのためにイメージの再ビルドが必要になります。 この両方の問題を回避するために、より小さい基本イメージを使用してください。 以下に例を示します。

• Alpine はサイズの小さい公式 Docker イメージです。 Java や Node.js のようなプログラミング環境では、Alpine に基づいたタグがしばしば見つかります。

• Google Container Tools の Distroless イメージにはオペレーティング・システムのツールがまったく含まれていませんが、Java や Node.js などのさまざまな言語に必要なランタイム環境が含まれています。

program.js ファイル内の Node.js プログラムを実行するコンテナー・イメージをビルドして、これらの基本イメージを比較してください。 Ubuntu の場合、Dockerfile ファイルは次の例のようになります。

FROM ubuntu

RUN \
    apt update && \
    apt upgrade -y && \
    apt install -y nodejs && \
    apt clean && \
    rm -rf /var/lib/apt/lists/\*

COPY program.js /app/program.js

WORKDIR /app

ENTRYPOINT ["node", "program.js"]

Alpine の場合、イメージは Node.js から直接取得します。

FROM node:16-alpine

COPY program.js /app/program.js

WORKDIR /app

ENTRYPOINT ["node", "program.js"]

Distroless の場合は、次の例を使用します。

FROM gcr.io/distroless/nodejs:16

COPY program.js /app/program.js

WORKDIR /app

CMD ["program.js"]

Ubuntu ベースのイメージは 147 MB ですが、Alpine に基づいたイメージは 90 MB、Distroless に基づいたイメージは 94 MB です。

イメージ・サイズを小さくするためにソースとビルド・ツールを含めない

前記の Node.js ベースの例では、単一のソース・ファイルがコンテナー・イメージに追加されています。 この例では、コンパイルが不要だったため、単一のソース・ファイルを使用できます。 一方、コンパイルが必要な場合は、必要なツールをビルドだけに使用し、それらのツールを結果のイメージに含めないでください。 例えば、Maven を使用する Java アプリケーションを指定するとします。 まずいコーディングの Dockerfile は、次の例のようになります。

FROM maven:3-jdk-11-openj9

WORKDIR /app
COPY . /app

RUN mvn package

EXPOSE 8080
ENTRYPOINT ["java", "-jar", "/app/target/java-application-1.0-SNAPSHOT-fat.jar"]

結果のコンテナー・イメージには、Maven からのすべてのソース・コードとすべての中間ファイル (成果物キャッシュ、後で JAR ファイルにパッケージ化されるクラス・ファイルなど)、および Maven ビルド・ツールが含まれます。 さらに、実行時に必要とされる Java ランタイム環境 (JRE) ははるかに小さいのに、Java Development Kit (JDK) も含まれます。 結果として、イメージ・サイズは 466 MB になります。

イメージを小さくするには、マルチステージ・ビルドという機能を使用します。 Docker ビルドのステージごとにそれ専用の基本イメージがあり、そのステージ内でコマンドを実行できます。 最後に最終イメージがビルドされ、それまでのステージの成果物内でコピーされます。 ソース・コードからコンテナー・イメージをビルドする場合、一般的なパターンは次の 2 つのステージを使用することです。

1. ソース・コードをランタイムのバイナリーにコンパイルするために必要なすべてのツールを含む基本イメージを使用するビルダー・ステージ。
2. ランタイム・ステージ: バイナリーを実行するために必要なランタイム環境を含む基本イメージを使用します。 ビルダー・ステージのバイナリーは、このステージにコピーされます。

Maven プロジェクトの場合、結果は次の例のようになります。

FROM maven:3-jdk-11-openj9 AS builder

WORKDIR /app
COPY . /app

RUN mvn package

FROM adoptopenjdk:11-jre-openj9

WORKDIR /app
COPY --from=builder /app/target/java-application-1.0-SNAPSHOT-fat.jar /app/java-application.jar

EXPOSE 8080
ENTRYPOINT ["java", "-jar", "/app/java-application.jar"]

この例では、ビルダー・ステージでは、Maven 基本イメージを使用してアプリケーションの JAR ファイルをビルドしています。 ランタイム・ステージでは、より小さい JRE 基本イメージを使用しています。 COPY --from=STAGE_NAME コマンドを使用することにより、ビルダー・ステージの JAR ファイルがランタイム・ステージにコピーされます。 結果のイメージのサイズは 242 MB で、約 48% の節約になります。

このパターンは、コンパイルを行う必要がある他のプログラミング言語にも使用できます。

• ビルド (例えば Angular ビルドや React ビルド) を必要とする Node アプリケーション。 この場合、ビルダーとランタイムの基本イメージは最終的に同じ (両方ともノード) になる可能性がありますが、ビルド時の成果物とソースをすべてランタイム・イメージにコピーする必要があるわけではありません。
• ランタイム環境なしで実行されるネイティブ実行可能ファイルにソース・コードをコンパイルするプログラミング言語 (例えば Go や Rust)。

ネイティブ実行可能ファイルを生成し、ランタイム環境をまったく必要としない言語の場合は、別の Docker 機能 (scratch) をランタイム・ステージに使用します。 scratch は FROM コマンドで基本として使用できますが、最終的なコンテナー・イメージではありません。 むしろそれは、Docker ビルドで基本イメージをまったく使用しないように指示します。 基本イメージからのオペレーティング・システム・ファイルを全く含めず、ただ単一ファイル (ビルダー・ステージからコピーされたバイナリー) のみを結果のイメージに含めることができます。 プログラミング言語とコードによっては、バイナリー・ファイルが存在するためにいくつかのオペレーティング・システム・ファイルが必要な場合があるため、コンパイラー・オプションをさらに調整しなければならない可能性があります。

イメージをクリーンにしておく

初めて Dockerfile を開発してその動作をデバッグする場合、一時的なツールをいくつかインストールしたり、最終的なコンテナー・イメージには必要のない他のワークロードを適用したりすることがあります。 こうした一時的なファイルやワークロードを削除すれば、イメージをクリーンにし、小さくして、よりセキュアにしておくことができます。