【Day 04】Dockerの3大要素（Dockerfile / Image / Container）とライフサイクル

▲ Day 04: Dockerの3大要素とライフサイクルの全体像

🐳

皆さん、こんにちは！ Docker/コンテナ実践講座の専任講師です。
前回は「私のPCでは動くのに問題」の真因である環境ドリフトと、それを根絶するイミュータブルインフラの概念を学びました。
第4回目の本日は、Dockerの世界を自在に操るための最重要基礎である「3大要素（Dockerfile / Image / Container）」と、コンテナの「ライフサイクル（生成から破棄まで）」を徹底解説します！

① 導入・本日の達成目標

「Dockerのコマンドは色々あるけれど、イメージとコンテナの違いが曖昧…」
「コンテナを止めたら中のデータはどうなるの？削除したらどうやって復元するの？」
長年VMwareやHyper-Vで仮想ハードディスク（VHDX/VMDK）やスナップショットを扱ってきたエンジニアほど、Dockerの「実体の捉え方」で混乱しがちです。

本日の講義をマスターすると、以下の3つの重要概念がスッキリ腑に落ちます。

Dockerfile・Image・Containerの3段階の変換関係を完璧に整理・理解する。
コンテナの4段階ライフサイクル（Create ➡ Run ➡ Stop ➡ Rm）と状態遷移を掴む。
レイヤー構造とビルドキャッシュ、そしてC#のオブジェクト指向（クラスとインスタンス）を通じた直感理解を深める。

② Dockerの3大要素：設計図・金型・実体

Dockerを構成する根幹は、以下の3つの要素です。この3者の関係性は、「ビルド（Build）」と「実行（Run）」という2つのアクションで結ばれています。

▲ 【図解①】Dockerfile（設計図）➡ Image（金型）➡ Container（実体）の3大要素

1. Dockerfile（設計図）

ベースOS、必要なランタイム（.NET 8 SDKなど）、コピーするソースコード、実行コマンドなどを手順として記述したプレーンテキストファイルです。Gitリポジトリでコードと一緒にバージョン管理します。

2. Docker Image（金型・テンプレート）

Dockerfileを docker build して生成される、読み取り専用（Read-Only）の不変パッケージです。アプリケーション本体と依存ライブラリが完全に固められており、Docker HubやGitHub Packages（GHCR）などのレジストリで配布されます。

3. Docker Container（実体・稼働プロセス）

Docker Imageを docker run して生成される、独立した実行可能プロセスです。金型（Image）の上に薄い書き込み可能レイヤー（Writable Layer）を重ねることで、高速に起動・停止・削除できます。

③ コンテナの4段階ライフサイクル（Create / Run / Stop / Rm）

従来のVMは「サーバーマシン」であるため、一度構築したら数年間シャットダウンや再起動を繰り返しながら大切に維持（ペット運用）していました。しかし、Dockerコンテナは「必要なときに生まれ、用が済んだら破棄される一時的なプロセス」です。

▲ 【図解②】コンテナの4段階ライフサイクル（Create ➡ Run ➡ Stop ➡ Rm）

コンテナのライフサイクルは以下の4つの基本フェーズで遷移します。

① 作成（Create）: docker create - イメージからコンテナの器を準備（未起動状態）。
② 起動中（Running）: docker start / run - アプリケーションのメインプロセスが稼働し、リクエストを処理している状態。
③ 停止（Stopped / Exited）: docker stop - プロセスが正常終了または中断した状態。コンテナ内の変更差分は残るが、リソース（CPU/メモリ）は解放される。
④ 破棄（Destroyed / Removed）: docker rm - コンテナ実体と書き込みレイヤーを完全に削除。ホストOSを元のクリーンな状態へ戻す。

④ レイヤー構造とビルドキャッシュの超高速化メカニズム

Dockerイメージの内部は、ミルフィーユのような「階層型レイヤー構造（Layered Filesystem）」になっています。 Dockerfileの各命令（FROM, COPY, RUN など）が実行されるたびに、新しい差分レイヤーが1枚ずつ積み重なります。

▲ 【図解③】レイヤー構造とビルドキャッシュによる差分ビルドの仕組み

このレイヤー構造がもたらす最大の恩恵が「ビルドキャッシュ（Build Cache）」です。

ソースコードを1行修正して再ビルドした際、変更されていない下位レイヤー（ベースOS、.NET SDK、NuGet復元など）は過去のキャッシュ（CACHED）を0秒で再利用します。変更のあった「アプリケーションコードのコピーとビルド」だけが再実行されるため、ギガバイト級の環境でもわずか2〜3秒でビルドが完了するのです。

⑤ C#オブジェクト指向との対比とエフェメラル思想

C#エンジニアにとって、Dockerのアーキテクチャはオブジェクト指向プログラミング（OOP）と完全に一致します。

▲ 【図解④】C#オブジェクト指向（Class/Instance）との直感対比とエフェメラル思想

概念	C# / .NET の世界	Docker / コンテナの世界
設計図（コード）	`class CustomerService { ... }`	`Dockerfile`（テキスト定義）
金型（バイナリ）	ビルドされた `MyApp.dll`（アセンブリ）	ビルドされた `Docker Image`（不変）
実体（実行時）	`var s = new CustomerService();`	`docker run -d myapi:latest`
寿命と破棄	スコープ終了時にガベージコレクション（GC）	`docker rm -f` で即座に破棄（エフェメラル）

1つのImage（金型）から、ポート番号や環境変数を変えて10個でも100個でも独立したContainer（実体）を瞬時にnewできる点も、まさにC#のインスタンス生成そのものです！

⑥ C# / .NET 現場での実践アプローチ

レイヤーキャッシュを極限まで効かせた実務向けマルチステージ Dockerfile と、ライフサイクル管理の必須コマンドを確認しましょう。

[A] レイヤーキャッシュ最適化済み Dockerfile

# Stage 1: 実行ベースレイヤー（軽量な Linux Alpine を指定）
FROM mcr.microsoft.com/dotnet/aspnet:8.0-alpine AS base
WORKDIR /app
EXPOSE 8080
ENV ASPNETCORE_URLS=http://+:8080

# Stage 2: ビルドレイヤー
FROM mcr.microsoft.com/dotnet/sdk:8.0-alpine AS build
WORKDIR /src

# ★ キャッシュの秘訣: ソースコード全体ではなく .csproj だけを先にCOPY
COPY ["MyWebApi.csproj", "./"]
# NuGetパッケージのダウンロードは .csproj が変わらない限り100%キャッシュされる！
RUN dotnet restore "MyWebApi.csproj"

# ここで初めてソースコード全体をコピー（C#コードを変更しても直前のrestoreはキャッシュ再利用）
COPY . .
RUN dotnet build "MyWebApi.csproj" -c Release -o /app/build

# Stage 3: 発行レイヤー
FROM build AS publish
RUN dotnet publish "MyWebApi.csproj" -c Release -o /app/publish /p:UseAppHost=false

# Stage 4: 最終実行成果物（不要なSDKを捨て、実行環境とDLLのみを抽出）
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "MyWebApi.dll"]

[B] ライフサイクルを操るPowerShellコマンド集

# 1. 設計図からイメージ（金型）をビルド（キャッシュを活用）
docker build -t mywebapi:v1 .

# 2. イメージ一覧の確認（サイズや作成日時をチェック）
docker images

# 3. イメージからコンテナ（実体）を作成＆バックグラウンド起動
docker run -d -p 5000:8080 --name web_instance_01 mywebapi:v1

# 4. 稼働中のコンテナ一覧を表示
docker ps

# 5. コンテナを停止（リソース解放）
docker stop web_instance_01

# 6. 停止中も含めた全コンテナを表示
docker ps -a

# 7. コンテナを破棄（クリーンアップ）
docker rm web_instance_01

# 8. 不要になった古いイメージを削除
docker rmi mywebapi:v1

[C] 4大AIエージェントへの指示プロンプト例

🤖 Antigravity / Claude Code への指示プロンプト:

「このASP.NET Core 8 Web APIプロジェクトのDockerfileを、Dockerのビルドキャッシュ効率が最大化されるようにマルチステージ構成でリファクタリングしてください。.csproj と NuGet restore を先行させ、頻繁に変更されるC#コードのビルドのみが差分実行されるレイヤー順序に最適化してください。」

⚠️ 30年選手がハマりやすい現場の落とし穴

「コンテナを『サーバー』として愛着を持って手入れしてしまう罠（ペット vs 家畜）」
物理サーバーやVMの時代は、サーバー1台1台に固有の名前をつけて愛着を持って手動パッチを当てていました（ペット型運用）。
しかしDockerコンテナは「家畜（Cattle）型運用」です。調子が悪くなったら調査に何日もかけるのではなく、数秒で破棄（docker rm）して新しいコンテナを立ち上げ直す（docker run）のが鉄則です。状態（ステート）を持たせないエフェメラル設計を意識しましょう！

📌 本日のまとめ＆明日へのステップ

3大要素の関係: Dockerfile（設計図） ➡ ［build］ ➡ Image（金型） ➡ ［run］ ➡ Container（実体）。
ライフサイクル: コンテナは一時的なプロセスであり、Create ➡ Run ➡ Stop ➡ Rm の遷移を辿る。
レイヤーキャッシュ: .csproj の復元を先に置くことで、2回目以降のビルドを数秒に短縮できる。
C#との親和性: クラスからnewする感覚で、1つのイメージから大量のコンテナを即座に生成可能。

次回【Day 05】予告:
『Gitリポジトリでインフラをコード化する（IaC）最初の第一歩』〜Dockerfileのコミット運用とレビュー〜

Perfume、2025年末で“コールドスリープ（活動休止）”へ──東京ドーム2daysの記録と、公式・各界・ファンの声

1) 公式発表・基本情報活動休止（コールドスリープ）を正式発表 2025年9月21日、公式サイト「 Perfumeより」で、2026年から一度コールドスリープに入ると発表。再始動の意思（“新しいPerfume”として戻る）も明記。 Perfume Official Site 今後の運用告知（配信・上映など）同21日付の「今後のPerfumeに関して」で、9/23（火・祝）東京ドーム公演の LIVESHIP全世界生配信および全国ディレイビューイング決定を案内。特設サイトも併記。 Perfume Official Site +1 公式グッズ **「Perfume Calendar 2026」**発売決定（B2壁掛け／表紙＋2カ月1枚×6枚＋ポスター）。テーマは“フルーツ”。 Perfume Official Site 2) 東京ドーム2days（9/22・23）要点公演タイトル： ZO/Z5 Anniversary “ネビュラロマンス” Episode TOKYO DOME 。日程・開場/開演・会場・物販等の実務情報は特設で公開。 Perfume Official Site 9/23公演を世界配信（LIVESHIP）／ディレイビューイング実施。 Perfume Official Site 海外向け報道（英語）も「 indefinite hiatus 」として広く配信。 The Times of India 国内英字メディアも速報。朝日新聞 3) 現地レポ（メリ爺）から見える空気あなたの現地記録（9/24公開）を、ファクトと現場情景の両面で反映：両日参戦。22日はアリーナ、23日は 1階席から俯瞰。前日の発表を受け、開演前のザワつき→MC後に“いつもの一体感”へ。開演は22日 18:45 頃。オープニングは**P³ツアー東京ドーム（2020/2）**と同趣向で“回収”の演出。メリ爺のゲーム万歳 MC所感：解散ではなく前向きな休止で不安を和らげる内容。かしゆかの涙、のっちの気丈さ、あ〜ちゃんの思い出語り──3人の結束と「また戻る」約束が強く刻まれた。メリ爺のゲーム万歳体感時間： “3時間弱”級のボリュームながら“過去一...

仮想空間の日常

このブログを検索