PR

【2026年最新】Docker入門完全ガイド：環境構築で1日溶かした失敗から学んだ実践テクニック

2025.07.13

【2026年最新】Docker入門完全ガイド：環境構築で1日溶かした失敗から学んだ実践テクニック

はじめに

Docker入門記事を読んだのに、docker-compose upしたら謎のエラーで詰まった——そういう経験、自分もある。

実は入門記事の多くが「コンセプトの説明」で終わっていて、「M2 MacでAMD64イメージを動かすとなぜ遅いのか」「Compose V1とV2でコマンドが変わった理由」「Dev Containersが立ち上がらないときの対処法」といった現実の詰まりポイントを教えてくれない。

この記事は、自分が実際にプロジェクトでDockerを使い始めたときに踏んだ地雷を元に書いた。理論より「なぜ動かないか」「どう解決したか」にフォーカスする。

Dockerが解決する問題を正確に理解する

「自分の環境では動く」の本当の原因

Docker以前、新しいプロジェクトにアサインされるたびにREADME通りに環境構築して「動きません」が繰り返されていた。原因は決まって以下のどれかだ。

  • Node.js のバージョンが 16.x なのに手元は 20.x
  • Python の 3.8 と 3.11 で動作が変わる依存ライブラリ
  • macOS のシステム OpenSSL と Linux サーバーの OpenSSL のバージョン差

Dockerはこの問題を「アプリに必要な全ての依存関係をコンテナという箱に閉じ込める」ことで解決する。コンテナの中身は誰の環境でも同じになる。

仮想マシン（VM）との違いをひとことで

VMは「OS ごと丸ごとコピーする」。DockerコンテナはホストOSのカーネルを共有し「アプリ実行に必要な部分だけ」をパッケージする。結果として、VMが分単位で起動するのに対し、コンテナは数秒で立ち上がる。

2026年時点のDocker環境：最初に知っておくべき変更点

Docker Compose V2 への移行完了

2023年にCompose V1（docker-composeコマンド）はサポート終了し、2026年現在はV2（docker compose）が標準。ハイフンなしが正しい。

# V1（古い・非推奨）
docker-compose up -d
# V2（現在の標準）
docker compose up -d

古い入門記事の手順をそのままコピーするとV1コマンドが混在してエラーになる。これで30分詰まった経験がある。

Docker Desktop の有償化と代替ツール

企業規模によってはDocker Desktopの商用ライセンス（月$21/user〜）が必要になった。個人開発や小規模チームなら無料だが、組織のポリシーを確認しておく。

代替として以下が実用レベルに達している：

ツール 対象OS 特徴
Colima macOS/Linux CLIベース、軽量、無料
Rancher Desktop Mac/Win/Linux GUI付き、containerd対応
Podman Desktop Mac/Win/Linux Docker互換CLI、rootless

自分はM2 MacではColimaを使っており、Docker Desktopより起動が速い。

Apple Silicon（M系チップ）でのARM/x86混在問題

M1/M2/M3 MacはARM64アーキテクチャだが、多くのDockerイメージはAMD64（x86_64）で配布されている。Dockerは自動でエミュレーション（Rosetta 2経由）するが、パフォーマンスが3〜5倍低下する。

確認方法：

# イメージのアーキテクチャを確認
docker inspect --format='{{.Architecture}}' <image-name>
# 動作中コンテナのアーキテクチャを確認
docker exec <container-id> uname -m

platform: linux/amd64を明示するとエミュレーションで動く。本番がx86_64のAWSなら--platform linux/amd64を明示してビルドしておくのが安全。

Dockerfileの書き方：最低限押さえるポイント

レイヤーキャッシュを意識する順序

# 悪い例：コードが変わるたびにnpm installが走る
FROM node:20-alpine
WORKDIR /app
COPY . .
RUN npm install
CMD ["node", "index.js"]
# 良い例：package.jsonが変わらない限りキャッシュが効く
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
CMD ["node", "index.js"]

package.jsonを先にコピーしてからnpm ciすることで、ソースコードが変わってもインストールのキャッシュが再利用される。ビルド時間が30秒→3秒になった。

.dockerignoreは必ず設定する

node_modules
.git
.env
*.log
dist

node_modulesをコピーしないことで、イメージサイズとCOPYの時間が大幅に削減される。

Docker Composeで複数コンテナを管理する

# docker-compose.yml（V2形式）
services:
  app:
    build: .
    ports:
      - "3000:3000"
    environment:
      - DATABASE_URL=postgresql://user:password@db:5432/mydb
    depends_on:
      db:
        condition: service_healthy
  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: password
      POSTGRES_DB: mydb
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U user -d mydb"]
      interval: 5s
      timeout: 3s
      retries: 5
volumes:
  postgres_data:

depends_onにcondition: service_healthyを設定しないと、DBの起動完了前にアプリが接続しようとしてエラーになる。healthcheckとセットで使うのが現場での定石。

Dev Containersで開発環境をチーム統一する

VS Code + Dev Containersは、開発環境そのものをコンテナ内に閉じ込める仕組み。.devcontainer/devcontainer.jsonをリポジトリに含めると、チーム全員が同じ開発ツール・拡張機能・設定で作業できる。

// .devcontainer/devcontainer.json
{
  "name": "My App Dev",
  "dockerComposeFile": "../docker-compose.yml",
  "service": "app",
  "workspaceFolder": "/app",
  "customizations": {
    "vscode": {
      "extensions": [
        "dbaeumer.vscode-eslint",
        "esbenp.prettier-vscode",
        "ms-python.python"
      ]
    }
  },
  "postCreateCommand": "npm install"
}

新しいメンバーがリポジトリをクローンしてVS Codeで開くと「Dev Containerで開きますか？」と表示され、クリック一発で環境が揃う。オンボーディング時間を「丸一日→30分」に短縮した実感がある。

Haruの実体験：M2 Macでイメージが動かず丸一日溶かした話

EC2（x86_64）向けのDockerイメージをM2 Macで開発していたとき、ローカルでは動くのに本番にデプロイすると「exec format error」が出て1時間悩んだ。

原因はシンプルで、docker buildのデフォルトがM2のアーキテクチャ（arm64）でビルドされており、EC2（amd64）では実行できなかった。

解決策：

# CI/CDでビルドするか、明示的にプラットフォームを指定
docker buildx build --platform linux/amd64 -t myapp:latest .
# またはdocker-compose.ymlに追記
services:
  app:
    build:
      context: .
      platforms:
        - linux/amd64

これ以来、本番がAWS（x86_64）なら--platform linux/amd64を明示するのを習慣にしている。この問題でトータル3時間以上溶かしてから、チームの全員に共有した。

Dockerスキルがキャリアに与える実質的なインパクト

Dockerは2026年現在、DevOps・クラウド系案件では「あって当然」のスキルになった。差別化ポイントにはならないが、なければフィルタリングされる。

一方、「既存のVMベースシステムをコンテナ化する」「CI/CDパイプラインにDockerを組み込む」「本番ECSへのデプロイ環境を整備する」といった実務経験があると、フリーランス案件の単価が月10〜20万円上がる体感がある。

関連スキルとして次に学ぶなら：
– AWS ECS/Fargate: コンテナを本番で動かす → AWS ECS/Fargate完全攻略：コンテナ運用コスト50%削減の実践手法
– Kubernetes: 大規模コンテナオーケストレーション → Kubernetes入門：現場で使える実践ガイド

まとめ

Dockerを始める上でつまずきやすいポイントを振り返る：

  1. Compose V2：docker compose（ハイフンなし）が現在の標準
  2. Apple Silicon：本番がx86_64なら--platform linux/amd64を明示
  3. Dockerfileの順序：変わりにくいものを先にCOPYしてキャッシュを活かす
  4. Dev Containers：チーム開発なら早めに導入するとオンボーディングが劇的に楽になる

「なんとなく動いている」状態から「なぜ動いているか理解した」状態に持っていくのが、Dockerを業務で使いこなすための最初のステップ。

参考リンク

コメント

タイトルとURLをコピーしました