コンテナ — 「手元では動く」を構造的に潰す

What — 仮想マシンとの違い

┌─────────┬─────────┐
│  アプリ  │  アプリ  │
│ ライブラリ│ライブラリ │
│ ゲスト OS │ ゲスト OS │  ← OS ごと入っている
├─────────┴─────────┤
│   ハイパーバイザ    │
│     ホスト OS      │
│    ハードウェア     │
└───────────────────┘

イメージは層でできている

この順序が逆だと、ソースを1行変えるたびに npm ci が走ります。 ビルドが5分から30秒になるかどうかは、この数行の順序で決まります。

マルチステージビルド

ビルドに必要なものと、実行に必要なものは違います。

# ① ビルド用ステージ（コンパイラや devDependencies が必要）
FROM node:20 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# ② 実行用ステージ（成果物だけを持ってくる）
FROM node:20-slim
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY --from=builder /app/dist ./dist
USER node                      # root で動かさない
CMD ["node", "dist/main.js"]

最終イメージには、ビルドツールもソースコードも含まれません。 サイズが小さくなるだけでなく、攻撃対象も減ります。

イメージ

コンテナの雛形。読み取り専用の層の集まり。

コンテナ

イメージから起動した実行中のインスタンス。書き込み可能な層が1つ上に乗る。

レイヤー

Dockerfile の命令ごとに作られる差分。キャッシュの単位でもある。

ダイジェスト

イメージの内容から計算されるハッシュ（sha256:...）。タグと違い、絶対に変わらない。

タグ

イメージに付ける別名。上書きできるので、同じタグが別のイメージを指すことがある。

ボリューム

コンテナの外にデータを永続化する仕組み。コンテナを消してもデータは残る。

Why — なぜ「手元では動く」が起きなくなるのか

「手元では動く」の原因は、環境の差です。

• OS のバージョンが違う
• ライブラリのバージョンが違う
• 環境変数が違う
• そもそも入っているものが違う

コンテナは、アプリと、それが依存するもの全部を1つのイメージに固めることでこれを解消します。イメージが同じなら、どのホストで動かしても中身は同じです。

ただし、完全に同じにはなりません。

• ホストのカーネルバージョンは共有される
• CPU アーキテクチャ（arm64 / amd64）は違いうる
• 環境変数・シークレット・接続先は外から注入される
• ボリュームでマウントされたデータは環境ごとに違う

**「差分をゼロにする」のではなく、「差分を環境変数とボリュームだけに絞る」**というのが正確な理解です。

コンテナは使い捨て

コンテナの設計思想は「いつ消えてもよい」です。

• ログはファイルではなく標準出力に書く（コンテナが消えても収集済み）
• 状態はコンテナ内に持たない（DB やオブジェクトストレージに置く）
• 起動に時間をかけない（スケールアウトの速さが利点）
• 停止シグナルを受けたら、処理中のリクエストを終えてから終了する（graceful shutdown）

この前提が守られていないと、オートスケールもローリングデプロイも安全に使えません。

演習 — まず自分で判断する

解説を読む前に、まず自分で判断してみてください。ここで一度詰まっておくと、 次の節の判断軸が「なるほど」ではなく「そう来たか」に変わります。