ITエンジニアとして30年以上のキャリアを築き、物理サーバーのラッキング、Hyper-VやVMwareによる仮想化、IISやSQL Serverの手動セットアップを完璧にこなしてきたベテランの皆さん、心より歓迎いたします！
本日は記念すべき第1回として、「Dockerコンテナとは何なのか？」そして「なぜGitリポジトリと一緒に使うと開発環境革命が起きるのか」を、C#/.NET開発の現場視点から徹底解剖します！
① 導入・本日の達成目標
「Dockerという言葉は聞くけれど、要するに軽いVMware（仮想マシン）でしょ？」
長年サーバーやインフラを扱ってきたベテランエンジニアほど、最初にそう誤解してしまいがちです。しかし、Dockerの内部構造と設計思想は、従来の仮想マシンとは根本から180度異なります。
本日の講義を終える頃には、以下の3つの目標を完全にクリアできるようになります。
- 仮想マシン（VM）とコンテナ（Docker）のアーキテクチャ上の決定的差異を完全論理理解する。
- なぜGitリポジトリにDockerfileを同居させるのか？（環境のコード化：IaC）の絶大なメリットを掴む。
- Dockerを理解するための「3大要素（Dockerfile / Image / Container）」のライフサイクルをC#の概念と紐付けてマスターする。
② VM / 物理サーバー技術者のためのパラダイムシフト
長年私たちが親しんできた仮想マシン（Hyper-V / VMware / VirtualBox）は、「ハードウェアそのものを仮想化」する技術です。 ホストOSの上にハイパーバイザーを載せ、その上でWindows ServerやLinuxの「ゲストOS」を丸ごと1台分ブートさせます。
この方式は完全なOSレベルの独立性を持つ反面、以下のような重厚長大さ（オーバーヘッド）を抱えていました。
- 起動が遅い: ゲストOSの起動シーケンスが走るため、立ち上がりに1分〜数分かかる。
- サイズが巨大: OS丸ごとの仮想ディスク（VHDX/VMDK）は平気で20GB〜50GBに達し、Gitでの管理や配布が不可能。
- リソース浪費: アプリが動いていなくても、ゲストOSだけで数GBのメモリを固定占有する。
そこで誕生したのが、現代の標準技術であるDocker（コンテナ型仮想化）です。
Dockerには「ゲストOS」が存在しません。 ホストOSのLinuxカーネル（WindowsではWSL2）をすべてのコンテナで共有し、Linuxカーネルの標準機能である「Namespace（名前空間分離）」と「cgroups（リソース制限）」を使って、プロセス単位で安全に隔離壁を作ります。
📊 仮想マシン（VM）とDockerコンテナの完全対比表
③ なぜGitリポジトリにDockerfileを同居させるのか？（IaCの第一歩）
Dockerが現場で爆発的に普及した最大の理由は、「インフラのコード化（Infrastructure as Code: IaC）」がGitと完璧に噛み合ったからです。
従来は「Excelの環境構築手順書」を見ながら、SQL Serverをインストールし、接続文字列を設定し、IISを構成していました。 しかし手順書はすぐに陳腐化し、「私のPCでは動くのに、新人のPCでは動かない」という不毛なトラブルが日常茶飯事でした。
Dockerでは、サーバー構成をすべて Dockerfile や docker-compose.yml というただのテキストファイルに記述します。
これをC#のソースコードと一緒にGitリポジトリにコミットしておくことで、以下の劇的な効果が生まれます。
- オンボーディングが3分で完了: 新メンバーは
git cloneしてdocker compose upを叩くだけで、DBもキャッシュもWeb APIもすべて立ち上がる。 - インフラの変更もプルリクエストでレビュー: 「DBのバージョンを上げた」「ライブラリを追加した」という変更差分がGitコミット履歴として明確に残る。
- 過去の環境へいつでもタイムトラベル: 1年前のGitコミットにチェックアウトすれば、当時の実行環境ごと寸分違わずに再現可能。
④ Dockerの3大要素（Dockerfile / Image / Container）
Dockerを操作する上で絶対に覚えておきたいのが、以下の3大要素です。
C#エンジニアの皆さんにとって最も直感的なのは、「オブジェクト指向プログラミングのクラスとインスタンス」に対応させることです。
【C#との直感対比】
・Dockerfile ＝ C#のソースコード（.cs ファイル / クラスの設計図）
・Docker Image ＝ コンパイルされたアセンブリ（.dll / 配布可能な金型）
・Docker Container ＝ メモリ上にインスタンス化された実体（new MyService() で動くプロセス）
⑤ C# / .NET 現場での実践アプローチ
それでは、C#プロジェクトにおける超シンプルな Dockerfile の実例を見てみましょう。
[A] C# Web API の最小 Dockerfile
# 1. 実行用ベースイメージ（Microsoft公式の軽量.NET 8ランタイム） FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base WORKDIR /app EXPOSE 8080 # 2. ビルド用ステージ（SDKイメージでコンパイル） FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build WORKDIR /src COPY ["MyWebApi.csproj", "./"] RUN dotnet restore "MyWebApi.csproj" COPY . . RUN dotnet publish "MyWebApi.csproj" -c Release -o /app/publish # 3. 最終成果物を軽量実行環境へ配置 FROM base AS final WORKDIR /app COPY --from=build /app/publish . ENTRYPOINT ["dotnet", "MyWebApi.dll"]
[B] 基本コマンド（PowerShell）
# 1. Dockerイメージをビルド（-t で名前とタグを付与） docker build -t mywebapi:v1 . # 2. コンテナを起動（ホストの8080ポートをコンテナの8080ポートへ接続） docker run -d -p 8080:8080 --name web_app mywebapi:v1 # 3. 稼働中のコンテナ一覧を確認 docker ps # 4. ログを確認 docker logs -f web_app # 5. コンテナを停止して削除 docker stop web_app docker rm web_app
[C] 4大AIエージェントへの指示プロンプト例
「このC# Web APIソリューション（.NET 8）に対して、本番運用に最適なマルチステージビルドのDockerfileと、.dockerignoreを自動生成してください。また、ローカルでSQL Serverと一緒に起動するためのdocker-compose.ymlも作成してGitブランチ feature/docker-setup にコミットしてください。」
「コンテナの中にデータを保存してしまい、再起動でデータが消滅する事故」
従来のVMではOSのCドライブに保存したファイルはずっと残りましたが、Dockerコンテナは「使い捨て（エフェメラル）」が鉄則です。
DBのデータファイル（.mdf）やアップロード画像は、必ず「ボリューム（Volume）」と呼ばれるホスト領域にマウントして永続化する必要があります（第6部で詳しく解説します！）。
- VMはOS丸ごと仮想化（重い）、Dockerはプロセス分離（秒速・超軽量）。
- DockerfileをGit管理することで、チーム全員が1秒で同一開発環境を再現できる（IaC）。
- Dockerfile（設計図） ➡ Image（金型） ➡ Container（実体）のライフサイクルを押さえる。
『物理サーバー・Hyper-V・VMware経験者のための「プロセス分離」パラダイムシフト』〜Linuxカーネル共有とNamespaceの正体を徹底解剖〜
コメント
コメントを投稿