この実験では、Dockerfile のテクニックをさらに深く掘り下げ、より効率的で柔軟な Docker イメージを作成するための高度な概念を探索します。詳細な Dockerfile 命令、マルチステージビルド（multi-stage builds）、および .dockerignore ファイルの使用方法について説明します。また、Docker イメージにおけるレイヤー（layers）という極めて重要な概念についても学びます。この実験を終える頃には、これらの高度な Dockerfile テクニックを包括的に理解し、自身のプロジェクトに応用できるようになります。
この実験は初心者向けに設計されており、詳細な説明を提供し、混乱しやすいポイントを解消します。すべてのファイル編集作業には WebIDE（VS Code）を使用するため、ブラウザ上で直接ファイルを簡単に作成・修正できます。
まずは、さまざまな命令を活用した Dockerfile を作成することから始めましょう。Flask を使用した Python Web アプリケーションのイメージを構築し、その過程で各命令が Docker イメージのレイヤーにどのように寄与するかを詳しく見ていきます。
mkdir -p ~/project/advanced-dockerfile && cd ~/project/advanced-dockerfileこのコマンドは、project フォルダ内に advanced-dockerfile という新しいディレクトリを作成し、そのディレクトリに移動します。
次に、アプリケーションファイルを作成します。WebIDE のファイルエクスプローラー（通常は画面の左側）で、advanced-dockerfile フォルダを右クリックし、「New File」を選択します。ファイル名を app.py とします。
app.py を開き、以下の Python コードを追加します：
from flask import Flask
import os
app = Flask(__name__)
@app.route('/')
def hello():
return f"Hello from {os.environ.get('ENVIRONMENT', 'unknown')} environment!"
if __name__ == '__main__':
app.run(host='0.0.0.0', port=5000)これは、実行されている環境名を含む挨拶メッセージを返すシンプルな Flask アプリケーションです。
requirements.txt ファイルを作成する必要があります。同じディレクトリに requirements.txt という名前の新しいファイルを作成し、以下の内容を追加します：Flask==2.0.1
Werkzeug==2.0.1ここでは、互換性を確保するために Flask と Werkzeug の両方に正確なバージョンを指定しています。
Dockerfile（先頭の 'D' は大文字）という名前の新しいファイルを作成し、以下の内容を追加します：## ベースイメージとして公式の Python ランタイムを使用
FROM python:3.9-slim
## コンテナ内の作業ディレクトリを設定
WORKDIR /app
## 環境変数を設定
ENV ENVIRONMENT=production
## requirements ファイルをコンテナにコピー
COPY requirements.txt .
## 必要なパッケージをインストール
RUN pip install --no-cache-dir -r requirements.txt
## アプリケーションのコードをコンテナにコピー
COPY app.py .
## コンテナ起動時に実行するコマンドを指定
CMD ["python", "app.py"]
## アプリが動作するポートを公開
EXPOSE 5000
## メタデータ用のラベルを追加
LABEL maintainer="Your Name <your.email@example.com>"
LABEL version="1.0"
LABEL description="Flask app demo for advanced Dockerfile techniques"ここで、これらの命令を分解して、Docker イメージのレイヤーにどのように影響するかを理解しましょう：
FROM python:3.9-slim: これは常に最初の命令です。構築のベースとなるイメージを指定します。これにより、Python ランタイムを含むイメージの最初のレイヤーが作成されます。WORKDIR /app: 以降の命令のための作業ディレクトリを設定します。新しいレイヤーは作成しませんが、後続の命令の動作に影響を与えます。ENV ENVIRONMENT=production: 環境変数を設定します。環境変数は新しいレイヤーを作成しませんが、イメージのメタデータに保存されます。COPY requirements.txt .: ホストからイメージに requirements ファイルをコピーします。これにより、このファイルのみを含む新しいレイヤーが作成されます。RUN pip install --no-cache-dir -r requirements.txt: ビルドプロセス中にコンテナ内でコマンドを実行します。ここでは Python の依存関係をインストールしています。これにより、インストールされたすべてのパッケージを含む新しいレイヤーが作成されます。COPY app.py .: アプリケーションのコードをイメージにコピーし、別のレイヤーを作成します。CMD ["python", "app.py"]: コンテナ起動時に実行するコマンドを指定します。レイヤーは作成しませんが、コンテナのデフォルトコマンドを設定します。EXPOSE 5000: これは実際にはドキュメントの一種です。コンテナが実行時にこのポートでリッスンすることを Docker に伝えますが、実際にポートを公開（パブリッシュ）するわけではありません。レイヤーは作成しません。LABEL ...: イメージにメタデータを追加します。ENV 命令と同様に、新しいレイヤーは作成せず、イメージのメタデータに保存されます。Dockerfile 内の各 RUN、COPY、ADD 命令は、新しいレイヤーを作成します。レイヤーは Docker の基本的な概念であり、イメージの効率的な保存と転送を可能にします。Dockerfile を変更してイメージを再構築すると、Docker は変更されていないキャッシュされたレイヤーを再利用し、ビルドプロセスを高速化します。
docker build -t advanced-flask-app .このコマンドは、advanced-flask-app というタグを付けて新しい Docker イメージをビルドします。末尾の . は、現在のディレクトリにある Dockerfile を探すよう Docker に指示しています。
ビルドプロセスの各ステップを示す出力が表示されます。各ステップが Dockerfile の命令に対応していること、およびビルドコマンドを複数回実行した場合に変更のないステップで Docker が「Using cache」と表示することを確認してください。
docker run -d -p 5000:5000 --name flask-container advanced-flask-appこのコマンドは以下のことを行います：
-d: コンテナをデタッチドモード（バックグラウンド）で実行します。-p 5000:5000: ホストのポート 5000 をコンテナのポート 5000 にマッピングします。--name flask-container: 新しいコンテナに名前を付けます。advanced-flask-app: コンテナ作成に使用するイメージ名です。実行中のコンテナリストを確認することで、コンテナが動作しているか検証できます：
docker pscurl コマンドを使用します：curl http://localhost:5000「Hello from production environment!」というメッセージが表示されるはずです。
curl で問題が発生した場合は、新しいブラウザタブを開いて http://localhost:5000 にアクセスすることもできます。同じメッセージが表示されるはずです。
問題が発生した場合は、以下のコマンドでコンテナのログを確認できます：
docker logs flask-containerこれにより、Flask アプリケーションからのエラーメッセージや出力が表示されます。
基本的な Dockerfile の命令とレイヤーについて理解したところで、より高度なテクニックであるマルチステージビルド（multi-stage builds）を探索しましょう。マルチステージビルドを使用すると、Dockerfile 内で複数の FROM ステートメントを使用できます。これは、あるステージから別のステージへ必要な成果物のみをコピーすることで、最終的なイメージサイズを小さくするのに非常に役立ちます。
実際にイメージサイズを小さくするマルチステージビルドを使用するように Dockerfile を修正してみましょう：
Dockerfile を開きます。## ビルドステージ
FROM python:3.9-slim AS builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --user --no-cache-dir -r requirements.txt
## 最終ステージ
FROM python:3.9-slim
WORKDIR /app
## ビルダー（builder）ステージからインストール済みパッケージのみをコピー
COPY --from=builder /root/.local /root/.local
COPY app.py .
ENV PATH=/root/.local/bin:$PATH
ENV ENVIRONMENT=production
CMD ["python", "app.py"]
EXPOSE 5000
LABEL maintainer="Your Name <your.email@example.com>"
LABEL version="1.0"
LABEL description="Flask app demo with multi-stage build"このマルチステージ Dockerfile で何が起きているのか分解してみましょう：
builder ステージから開始します：
python:3.9-slim イメージを使用します。pip install --user を使用して、このステージで Python の依存関係をインストールします。これにより、パッケージはユーザーのホームディレクトリにインストールされます。次に最終ステージがあります：
python:3.9-slim イメージで新しく開始します。builder ステージから、pip install --user によって配置された /root/.local 内のインストール済みパッケージのみをコピーします。PATH に追加します。ここでの主な利点は、最終的なイメージに pip のインストールプロセスで使用されたビルドツールやキャッシュが含まれないことです。最終的に必要な成果物のみが含まれます。これにより、イメージサイズが小さくなるはずです。
docker build -t multi-stage-flask-app .docker images | grep flask-appmulti-stage-flask-app latest 7bdd1be2d1fb 10 seconds ago 129MB
advanced-flask-app latest c59d6fa303cc 10 minutes ago 136MBmulti-stage-flask-app が、以前にビルドした advanced-flask-app よりも小さくなっていることが確認できるはずです。
docker run -d -p 5001:5000 --name multi-stage-container multi-stage-flask-app前のコンテナとの衝突を避けるために、別のホストポート（5001）を使用していることに注意してください。
curl http://localhost:5001引き続き「Hello from production environment!」というメッセージが表示されるはずです。
docker history コマンドを使用できます。以下のコマンドを実行してください：docker history advanced-flask-app
docker history multi-stage-flask-app出力を比較してください。マルチステージビルドの方がレイヤー数が少なく、一部のレイヤーのサイズが小さくなっていることに気づくでしょう。
マルチステージビルドは、効率的な Docker イメージを作成するための強力なテクニックです。最終的なイメージを肥大化させることなく、ビルドプロセスでツールやファイルを使用できます。これは、コンパイルが必要な言語や、複雑なビルドプロセスを持つアプリケーションで特に有用です。
今回のケースでは、ビルド時の成果物やキャッシュを残さず、必要なインストール済みパッケージとアプリケーションコードのみをコピーすることで、より小さな Python アプリケーションイメージを作成しました。
Docker イメージをビルドする際、Docker はディレクトリ内のすべてのファイルを Docker デーモンに送信します。イメージ構築に不要な大きなファイルがある場合、ビルドプロセスが遅くなる可能性があります。.dockerignore ファイルを使用すると、Docker イメージをビルドする際に除外すべきファイルやディレクトリを指定できます。
.dockerignore ファイルを作成して、その仕組みを確認しましょう：
advanced-dockerfile ディレクトリに .dockerignore という名前の新しいファイルを作成します。.dockerignore ファイルに以下の内容を追加します：**/.git
**/.gitignore
**/__pycache__
**/*.pyc
**/*.pyo
**/*.pyd
**/.Python
**/env
**/venv
**/ENV
**/env.bak
**/venv.bakこれらのパターンの意味を分解してみましょう：
**/.git: ディレクトリ構造のどこにあっても、.git ディレクトリとそのすべての内容を無視します。**/.gitignore: .gitignore ファイルを無視します。**/__pycache__: Python のキャッシュディレクトリを無視します。**/*.pyc, **/*.pyo, **/*.pyd: コンパイルされた Python ファイルを無視します。**/.Python: .Python ファイル（仮想環境でよく作成される）を無視します。**/env, **/venv, **/ENV: 仮想環境のディレクトリを無視します。**/env.bak, **/venv.bak: 仮想環境ディレクトリのバックアップコピーを無視します。各行の先頭にある ** は「任意のディレクトリ内」を意味します。
.dockerignore ファイルの効果を実証するために、無視したいファイルをいくつか作成してみましょう。ターミナルで以下を実行します：mkdir venv
touch venv/ignore_me.txt
touch .gitignoreこれらのコマンドは、ファイルを含む venv ディレクトリと .gitignore ファイルを作成します。これらは Python プロジェクトで一般的ですが、通常 Docker イメージには含めたくない要素です。
docker build -t ignored-flask-app .docker history コマンドを使用できます：docker history ignored-flask-appvenv ディレクトリや .gitignore ファイルをコピーするステップが表示されないはずです。
.dockerignore ファイルは、Docker イメージをクリーンに保ち、ビルドプロセスを効率化するための強力なツールです。最終的なイメージに不要なファイルが多数存在する可能性がある大規模なプロジェクトでは特に役立ちます。
この最後のステップでは、Docker イメージをより安全でメンテナンスしやすく、使いやすくするための追加の Dockerfile 命令とベストプラクティスを探索します。また、プロセスの各ステップのトラブルシューティングと検証にも焦点を当てます。
WebIDE で、再度 Dockerfile を開きます。
内容を以下のものに置き換えます：
## ビルドステージ
FROM python:3.9-slim AS builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --user --no-cache-dir -r requirements.txt
## 最終ステージ
FROM python:3.9-slim
## 非ルートユーザーを作成
RUN useradd -m appuser
## ヘルスチェック用に curl をインストール
RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/*
WORKDIR /app
## Python バージョンと site-packages パスを動的に決定
RUN PYTHON_VERSION=$(python -c 'import sys; print(f"{sys.version_info.major}.{sys.version_info.minor}")') && \
SITE_PACKAGES_PATH="/home/appuser/.local/lib/python${PYTHON_VERSION}/site-packages" && \
mkdir -p "${SITE_PACKAGES_PATH}" && \
chown -R appuser:appuser /home/appuser/.local
## 変数を使用して site-packages とバイナリをコピー
COPY --from=builder /root/.local/lib/python3.9/site-packages "${SITE_PACKAGES_PATH}"
COPY --from=builder /root/.local/bin /home/appuser/.local/bin
COPY app.py .
ENV PATH=/home/appuser/.local/bin:$PATH
ENV ENVIRONMENT=production
## アプリケーションを実行するユーザーを設定
USER appuser
## ENTRYPOINT を CMD と組み合わせて使用
ENTRYPOINT ["python"]
CMD ["app.py"]
EXPOSE 5000
HEALTHCHECK --interval=30s --timeout=3s \
CMD curl -f http://localhost:5000/ || exit 1
ARG BUILD_VERSION
LABEL maintainer="Your Name <your.email@example.com>"
LABEL version="${BUILD_VERSION:-1.0}"
LABEL description="Flask app demo with advanced Dockerfile techniques"この Dockerfile で導入された新しい概念を分解してみましょう：
RUN useradd -m appuser: コンテナ内に appuser という名前の新しいユーザーを作成します。アプリケーションが侵害された場合の潜在的な被害を制限するため、非ルートユーザーとしてアプリケーションを実行することはセキュリティ上のベストプラクティスです。-m フラグはユーザーのホームディレクトリを作成します。RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/*: HEALTHCHECK 命令を動作させるために必要な curl パッケージをインストールします。また、イメージサイズを削減するために apt キャッシュをクリーンアップします。RUN PYTHON_VERSION=$(python -c 'import sys; print(f"{sys.version_info.major}.{sys.version_info.minor}")') && ...: この一連のコマンドは、コンテナ内の Python バージョンを動的に特定し、appuser 用の正しい site-packages ディレクトリを作成します。また、ユーザーのローカルディレクトリに対して正しい権限を設定します。COPY --from=builder /root/.local/lib/python3.9/site-packages "${SITE_PACKAGES_PATH}": この命令は、インストールされた Python パッケージを builder ステージから最終イメージ内の動的に決定された site-packages パスにコピーし、appuser が使用できる正しい場所にパッケージが配置されるようにします。COPY --from=builder /root/.local/bin /home/appuser/.local/bin: pip によってインストールされた実行可能スクリプト（Flask のコマンドラインインターフェースなど）を、builder ステージから appuser のローカル bin ディレクトリにコピーします。ENTRYPOINT ["python"] と CMD ["app.py"]: これらを組み合わせて使用すると、ENTRYPOINT はコンテナのメインの実行ファイル（この場合は python）を定義し、CMD はその実行ファイルへのデフォルト引数（app.py）を提供します。このパターンは柔軟性を高めます。ユーザーはデフォルトで app.py を実行することも、CMD を上書きして他の Python スクリプトやコマンドを実行することもできます。HEALTHCHECK: この命令はコンテナのヘルスチェックを設定します。Docker は指定されたコマンド（curl -f http://localhost:5000/）を定期的に実行して、コンテナが正常（healthy）かどうかを判断します。--interval=30s と --timeout=3s フラグは、それぞれチェックの間隔とタイムアウトを設定します。curl コマンドが失敗（ゼロ以外の終了コードを返す）した場合、コンテナは異常（unhealthy）とみなされます。ARG BUILD_VERSION: BUILD_VERSION という名前のビルド引数を定義します。ビルド引数を使用すると、ビルド時に Docker イメージに値を渡すことができます。LABEL version="${BUILD_VERSION:-1.0}": Docker イメージに version という名前のラベルを設定します。これには BUILD_VERSION ビルド引数を使用します。ビルド中に BUILD_VERSION が提供されればその値が使用され、提供されなければデフォルトの 1.0（:- デフォルト値構文を使用）が使用されます。docker build -t advanced-flask-app-v2 --build-arg BUILD_VERSION=2.0 .--build-arg BUILD_VERSION=2.0 フラグにより、イメージのビルドプロセス中に BUILD_VERSION 引数に 2.0 という値を渡すことができます。この値は Docker イメージの version ラベルを設定するために使用されます。
docker images | grep advanced-flask-app-v2docker images コマンドの出力に、新しいイメージ advanced-flask-app-v2 がタグ、イメージ ID、作成日、サイズとともに表示されるはずです。
docker run -d -p 5002:5000 --name advanced-container-v2 advanced-flask-app-v2このコマンドは、コンテナをデタッチドモード（-d）で実行し、ホストのポート 5002 をコンテナのポート 5000 にマッピング（-p 5002:5000）し、コンテナに advanced-container-v2 という名前を付け（--name advanced-container-v2）、advanced-flask-app-v2 イメージを使用してコンテナを作成します。
docker ps | grep advanced-container-v2コンテナが正常に動作していれば、docker ps コマンドの出力に表示されます。コンテナが表示されない場合は、終了してしまった可能性があります。停止したコンテナも含めて確認してみましょう：
docker ps -a | grep advanced-container-v2docker ps -a の出力にコンテナはあるが実行されていない（ステータスが "Up" ではない）場合は、ログを確認してエラーを調べます：
docker logs advanced-container-v2このコマンドは advanced-container-v2 コンテナのログを表示し、Flask アプリケーションの起動時の問題や実行時エラーの診断に役立ちます。
docker inspect --format='{{.State.Health.Status}}' advanced-container-v2少し待つと（ヘルスチェックが少なくとも 1 回実行されるまで）、出力として "healthy" が表示されるはずです。最初に "unhealthy" と表示された場合は、さらに 30 秒（ヘルスチェックの間隔）待ってから再度コマンドを実行してください。もし "unhealthy" のままの場合は、docker logs advanced-container-v2 を使用して Flask アプリケーションに問題がないか確認してください。明らかな問題がなければ、"unhealthy" ステータスは無視しても構いません。
docker inspect -f '{{.Config.Labels.version}}' advanced-container-v2このコマンドは advanced-container-v2 コンテナから version ラベルの値を取得して表示します。出力に "2.0" と表示されれば、BUILD_VERSION ビルド引数がラベルの設定に正しく使用されたことが確認できます。
curl http://localhost:5002出力に "Hello from production environment!" というメッセージが表示されるはずです。これは、Flask アプリケーションが Docker コンテナ内で正常に動作しており、ホストのポート 5002 からアクセス可能であることを示しています。
これらの高度なテクニックにより、より安全で設定可能、かつ本番環境に適した Docker イメージを作成できます。非ルートユーザーはセキュリティを向上させ、HEALTHCHECK はコンテナのオーケストレーションと監視を助け、ビルド引数はより柔軟でバージョン管理されたイメージ構築を可能にします。
この実験では、より効率的で安全、かつメンテナンスしやすい Docker イメージを作成するための高度な Dockerfile テクニックを探索しました。学んだ内容は以下の通りです：
これらのテクニックにより、以下のことが可能になります：
この実験を通じて、ファイルの編集には WebIDE（VS Code）を使用しました。これにより、ブラウザ上で Dockerfile やアプリケーションコードを直接作成・修正することが容易になりました。このアプローチは、Docker を使用した開発においてシームレスな体験を提供します。
