Docker

Docker とは

Docker は、アプリケーションとその依存関係をコンテナとしてパッケージ化し、どの環境でも同じように実行できるプラットフォームである。2013 年に Solomon Hykes が公開し、コンテナ技術を普及させた。

VM との比較

VM との主な違いを以下に比較する。

観点	Docker コンテナ	仮想マシン (VM)
起動時間	ミリ秒	秒〜分
サイズ	MB	GB
OS	ホスト OS のカーネルを共有	ゲスト OS が必要
隔離	プロセスレベル	ハードウェアレベル
オーバーヘッド	小さい	大きい

基本コマンド

基本コマンドの例を示す。

# イメージのビルド
docker build -t myapp .

# コンテナの起動
docker run -d -p 3000:3000 myapp

# 実行中のコンテナ一覧
docker ps

# ログの確認
docker logs -f <container-id>

# コンテナに入る
docker exec -it <container-id> /bin/sh

# 停止・削除
docker stop <container-id>
docker rm <container-id>

# イメージの削除
docker image prune -a

Dockerfile

Dockerfile の例を示す。

FROM node:22-slim
WORKDIR /app
COPY package*.json ./
RUN npm ci --production
COPY dist/ dist/
EXPOSE 3000
CMD ["node", "dist/index.js"]

Docker の構成要素

Docker は Dockerfile (イメージのビルド手順)、イメージ (読み取り専用のテンプレート)、コンテナ (イメージの実行インスタンス)、レジストリ (イメージの保存場所、ECR や Docker Hub)、Docker Compose (複数コンテナの定義・起動) で構成される。

AWS でのコンテナ実行

AWS では ECS (Fargate) でサーバーレスコンテナ実行、EKS でマネージド Kubernetes、ECR でコンテナレジストリ、Lambda のコンテナイメージデプロイができる。2026 年時点で新しく組むなら、常時受け付ける Web アプリは ECS (Fargate)、イベントごとに動かす処理は Lambda のコンテナイメージが基本の選択肢になる。App Runner は 2026 年時点で新規の受付を終了しているため、これから選ぶ実行先には含めない。

ビルドしたイメージをどこで動かすか

Dockerfile から作ったイメージは、実行先によって「そのまま動くか」「イメージ側に作り込みが必要か」が変わる。AWS の主な実行先を Docker 側の視点で整理する。

実行先	イメージの置き場所	イメージ側に必要な作り込み	実行の単位
ECS (Fargate)	ECR、Docker Hub などのレジストリ	不要 (作ったイメージをそのまま実行)	タスク (CPU とメモリをタスク定義で指定)
EKS	ECR、Docker Hub などのレジストリ	不要 (同じイメージを Kubernetes 側の定義で実行)	Pod (マニフェストで定義)
Lambda (コンテナイメージ)	関数と同一リージョンの ECR	Lambda Runtime API への対応が必要 (AWS 提供のベースイメージか runtime interface client を同梱)・非圧縮 10 GB 以内・Linux のみ	イベント 1 件ごとの関数呼び出し

ECS と EKS は「Docker で動いたイメージがそのまま動く」側で、移行のために Dockerfile を書き換える必要はほとんどない。一方 Lambda のコンテナイメージは、イメージ自体が Lambda の呼び出し規約に応答できることが前提で、さらにルートファイルシステムが読み取り専用 (書き込めるのは /tmp のみ) という制約もあるため、既存のイメージをそのまま持ち込めるとは限らない。

基礎から学ぶなら関連書籍が手がかりになる。