docker-platform-guide

Docker のプラットフォーム別ガイド

このスキルでは、Windows、Linux、macOS プラットフォームにおける Docker の違い、考慮事項、最適化について詳しく説明します。

このスキルで使用するシェルとパスの規則

Docker コマンドはほとんどのプラットフォームで同じですが、周辺のシェルユーティリティは異なります。このガイドでは、次の規則を使用します。

• docker exec / docker run コンテナー内 — ホスト OS にかかわらず、コマンドは Linux シェルを対象とします（コンテナーは Linux を実行します）。
• ホスト（Linux / macOS / WSL2） — 例では /dev/null、grep、sed、awk、パッケージマネージャー（apt-get、brew）を使用する bash を使います。
• ホスト（Windows ネイティブ PowerShell） — 次のように置き換えます。/dev/null -> $null、grep pattern -> Select-String pattern、sed -i 's/a/b/' f -> (Get-Content f) -replace 'a','b' | Set-Content f。テキストではなく、オブジェクト出力をパイプします。
• Windows 上の Docker Desktop は WSL2 Linux VM を使用します。bash の例は WSL ディストリビューション内で動作します。PowerShell ユーザーも docker CLI 自体は実行できます。変換が必要なのは、補助的な Unix ツールのみです。

パスの引用符：Windows パスを Docker Desktop にバインドマウントするときは、スラッシュまたはエスケープしたバックスラッシュを使います（-v C:/Users/me/code:/app または -v "C:\Users\me\code:/app"）。PowerShell ホストのパスでは Windows の区切り文字を使いますが、コンテナーのパスは常に Linux 形式です。

Linux

利点

• ネイティブコンテナー： 仮想化レイヤーによるオーバーヘッドがありません
• 最高のパフォーマンス： カーネル機能（cgroups、名前空間）を直接利用します
• すべての機能を利用可能： Docker の全機能を利用できます
• 本番環境の標準： 本番環境へのデプロイのほとんどは Linux で実行されます
• 柔軟性： 複数のディストリビューションに対応しています

プラットフォームの機能

コンテナーテクノロジー：

• 名前空間：PID、ネットワーク、IPC、マウント、UTS、ユーザー
• リソース制御用の cgroups v1 および v2
• Overlay2 ストレージドライバー（推奨）
• 強制アクセス制御用の SELinux と AppArmor

ストレージドライバー：

# Check current driver
docker info | grep "Storage Driver"

# Recommended: overlay2
# /etc/docker/daemon.json
{
  "storage-driver": "overlay2"
}

Linux 固有の設定

デーモン設定（/etc/docker/daemon.json）：

{
  "storage-driver": "overlay2",
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  },
  "live-restore": true,
  "userland-proxy": false,
  "userns-remap": "default",
  "icc": false,
  "default-ulimits": {
    "nofile": {
      "Name": "nofile",
      "Hard": 64000,
      "Soft": 64000
    }
  }
}

ユーザー名前空間の再マッピング：

# Enable in daemon.json
{
  "userns-remap": "default"
}

# Restart Docker
sudo systemctl restart docker

# Result: root in container = unprivileged user on host

SELinux との統合

# Check SELinux status
sestatus

# Run container with SELinux enabled
docker run --security-opt label=type:svirt_sandbox_file_t myimage

# Volume labels
docker run -v /host/path:/container/path:z myimage  # Private label
docker run -v /host/path:/container/path:Z myimage  # Shared label

AppArmor との統合

# Check AppArmor status
sudo aa-status

# Run with default Docker profile
docker run --security-opt apparmor=docker-default myimage

# Create custom profile
sudo aa-genprof docker run myimage

Systemd との統合

# Check Docker service status
sudo systemctl status docker

# Enable on boot
sudo systemctl enable docker

# Restart Docker
sudo systemctl restart docker

# View logs
sudo journalctl -u docker -f

# Configure service
sudo systemctl edit docker

cgroup v1 と v2 の比較

# Check cgroup version
stat -fc %T /sys/fs/cgroup/

# If using cgroup v2, ensure Docker version >= 20.10

# /etc/docker/daemon.json
{
  "exec-opts": ["native.cgroupdriver=systemd"]
}

Linux ディストリビューション固有の情報

Ubuntu/Debian：

# Install Docker
sudo apt-get update
sudo apt-get install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io

# Non-root user
sudo usermod -aG docker $USER

RHEL/CentOS/Fedora：

# Install Docker
sudo dnf -y install dnf-plugins-core
sudo dnf config-manager --add-repo https://download.docker.com/linux/fedora/docker-ce.repo
sudo dnf install docker-ce docker-ce-cli containerd.io

# Start Docker
sudo systemctl start docker
sudo systemctl enable docker

# Non-root user
sudo usermod -aG docker $USER

Alpine：

# Install Docker
apk add docker docker-compose

# Start Docker
rc-update add docker boot
service docker start

macOS

アーキテクチャ

• Docker Desktop： 必須です（macOS にはネイティブの Docker がありません）
• 仮想化： HyperKit（Intel）または Virtualization.framework（Apple Silicon）を使用します
• Linux VM： コンテナーは軽量な Linux VM 内で実行されます
• ファイル共有： バインドマウントには osxfs または VirtioFS を使用します

macOS 固有の考慮事項

リソースの割り当て：

Docker Desktop → Preferences → Resources → Advanced
- CPUs: Allocate based on workload (default: half available)
- Memory: Allocate generously (default: 2GB, recommend 4-8GB)
- Swap: 1GB minimum
- Disk image size: 60GB+ for development

ファイル共有のパフォーマンス：

従来の osxfs は低速です。改善方法：

1. VirtioFS： Docker Desktop の設定で有効にします（高速）
2. 委譲／キャッシュされたマウント：

volumes:
  # Host writes delayed (best for source code)
  - ./src:/app/src:delegated

  # Container writes cached (best for build outputs)
  - ./build:/app/build:cached

  # Default consistency (slowest but safest)
  - ./data:/app/data:consistent

ネットワークアクセス：

# Access host from container
host.docker.internal

# Example: Connect to host PostgreSQL
docker run -e DATABASE_URL=postgresql://host.docker.internal:5432/db myapp

Apple Silicon（M1/M2/M3）固有の情報

アーキテクチャに関する考慮事項：

# Check image architecture
docker image inspect node:20-alpine | grep Architecture

# M-series Macs are ARM64
# Some images only available for AMD64

# Build multi-platform
docker buildx build --platform linux/amd64,linux/arm64 -t myapp .

# Run AMD64 image on ARM (via emulation)
docker run --platform linux/amd64 myimage  # Slower

Rosetta 2 との統合：

Docker Desktop → Features in development → Use Rosetta for x86/amd64 emulation

Apple Silicon での AMD64 エミュレーションが高速になります。

macOS の Docker Desktop 設定

一般：

• ✅ ログイン時に Docker Desktop を起動する
• ✅ VirtioFS を使用する（パフォーマンスが向上）
• ✅ Virtualization framework を使用する（Apple Silicon）

リソース：

CPUs: 4-6 (for development)
Memory: 6-8 GB (for development)
Swap: 1-2 GB
Disk image size: 100+ GB (grows dynamically)

Docker Engine：

{
  "builder": {
    "gc": {
      "enabled": true,
      "defaultKeepStorage": "20GB"
    }
  },
  "experimental": false,
  "features": {
    "buildkit": true
  }
}

macOS のファイル権限

# macOS user ID and group ID
id -u  # Usually 501
id -g  # Usually 20

# Match in container
docker run --user 501:20 myimage

# Or in Dockerfile
RUN adduser -u 501 -g 20 appuser
USER appuser

macOS の開発ワークフロー

# docker-compose.yml for development
version: '3.8'

services:
  app:
    build: .
    volumes:
      # Source code with delegated (better performance)
      - ./src:/app/src:delegated
      # node_modules in volume (much faster than bind mount)
      - node_modules:/app/node_modules
    ports:
      - "3000:3000"
    environment:
      - NODE_ENV=development

volumes:
  node_modules:

macOS でよくある問題

問題： ファイル同期が遅い 解決策：

• VirtioFS を使用する
• 委譲／キャッシュされたマウントを使用する
• 依存関係はバインドマウントではなく、ボリュームに保存する

問題： CPU 使用率が高い 解決策：

• ファイル監視を減らす
• 大きなディレクトリをファイル共有から除外する
• より多くのリソースを割り当てる

問題： ポートがすでに使用中 解決策：

# Find process using port
lsof -i :PORT
kill -9 PID

Windows

Windows の Docker に関する詳細（コンテナの種類、WSL2、イメージのバリエーション nanoserver / windowsservercore、ライセンス、ネットワーク、マウントの動作、Visual Studio との統合）については、references/windows-platform-detail.md を参照してください。主なポイント：

• コンテナの種類： Windows Server Containers（プロセス分離）と Hyper-V Containers（カーネル分離）。
• WSL2 バックエンド： Docker Desktop のデフォルトです。Linux に近いネイティブ性能が得られます。
• イメージのバリエーション： mcr.microsoft.com/windows/nanoserver（最小）と windowsservercore（完全な API）。
• マウント： Git Bash では S:\repos\x を /s/repos/x に変換するか、MSYS_NO_PATHCONV=1 を設定します。

プラットフォームの比較

機能	Linux	macOS	Windows
パフォーマンス	優秀（ネイティブ）	良好（VM のオーバーヘッドあり）	良好（WSL2）～普通（Hyper-V）
ファイル共有	ネイティブ	遅い（VirtioFS により改善中）	遅い（WSL2 では改善）
リソース効率	最良	良好	良好（WSL2）
機能セット	完全	完全	完全（LCOW）
本番環境	標準	開発のみ	開発のみ（LCOW）
使いやすさ	普通	簡単（Docker Desktop）	簡単（Docker Desktop）
コスト	無料	無料（Docker Desktop Personal）	無料（Docker Desktop Personal）

クロスプラットフォームのベストプラクティス

マルチプラットフォームイメージ

# Create buildx builder
docker buildx create --name multiplatform --driver docker-container --use

# Build for multiple platforms
docker buildx build \
  --platform linux/amd64,linux/arm64,linux/arm/v7 \
  -t myimage:latest \
  --push \
  .

プラットフォームに依存しない Dockerfile

# Works on all platforms
FROM node:20-alpine

# Use COPY with --chmod (not RUN chmod, which is slower)
COPY --chmod=755 script.sh /usr/local/bin/

# Use environment variables for paths
ENV APP_HOME=/app
WORKDIR ${APP_HOME}

# Use exec form for CMD/ENTRYPOINT (works on Windows containers too)
CMD ["node", "server.js"]

クロスプラットフォームの Compose ファイル

version: '3.8'

services:
  app:
    build: .
    volumes:
      # Relative paths work everywhere
      - ./src:/app/src
      # Named volumes (platform-agnostic)
      - data:/app/data
    environment:
      # Use environment variables
      - NODE_ENV=${NODE_ENV:-development}

volumes:
  data:

各プラットフォームでのテスト

# Test on different platforms with buildx
docker buildx build --platform linux/amd64 -t myapp:amd64 --load .
docker run --rm myapp:amd64

docker buildx build --platform linux/arm64 -t myapp:arm64 --load .
docker run --rm myapp:arm64

プラットフォーム選択ガイド

Linux を選ぶ場合：

• 本番環境へのデプロイ
• 最大限のパフォーマンス
• Docker の全機能
• オーバーヘッドの最小化
• CI/CD パイプライン

macOS を選ぶ場合：

• Mac ハードウェアでの開発
• macOS のツールが必要な場合
• Docker Desktop の使いやすさ
• M1/M2/M3 での開発

Windows を選ぶ場合：

• Windows ハードウェアでの開発
• Windows 固有のアプリケーション
• チームで Windows を使用している場合
• Linux コンテナのサポート向上に WSL2 を使用

このプラットフォームガイドでは、主な違いを説明しています。本番環境に移行する前に、必ずデプロイ先のプラットフォームでテストしてください。