Docker + Kubernetes入門2026：最小構成から始めるコンテナ化

#Docker #Kubernetes #インフラ #DevOps #クラウド

Dockerがなぜ2026年も必須なのか

コンテナ技術は「流行」ではなくインフラの標準になりました。

2026年のコンテナ採用率：
- 大企業：約80%がコンテナを本番利用
- スタートアップ：約70%がDockerを採用
- フリーランス案件：「Docker経験必須」が急増

Docker基礎：最小構成のWebアプリをコンテナ化

# ✅ 本番用Dockerfile（マルチステージビルド）
# ビルドステージ
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# 実行ステージ（軽量化）
FROM node:20-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production

# セキュリティ：rootで実行しない
RUN addgroup -g 1001 -S nodejs && \
    adduser -S nextjs -u 1001

COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static

USER nextjs
EXPOSE 3000
CMD ["node", "server.js"]
# docker-compose.yml（開発環境）
version: '3.8'
services:
  app:
    build: .
    ports:
      - "3000:3000"
    environment:
      - DATABASE_URL=${DATABASE_URL}
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: myapp
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s
      timeout: 5s
      retries: 5
    volumes:
      - postgres_data:/var/lib/postgresql/data

volumes:
  postgres_data:

Kubernetes：本番運用の最小構成

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
      - name: web-app
        image: your-registry/web-app:v1.2.3
        ports:
        - containerPort: 3000
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"
        livenessProbe:
          httpGet:
            path: /health
            port: 3000
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: 3000
          initialDelaySeconds: 5
          periodSeconds: 5
---
# service.yaml
apiVersion: v1
kind: Service
metadata:
  name: web-app-service
spec:
  selector:
    app: web-app
  ports:
    - port: 80
      targetPort: 3000
  type: LoadBalancer

セキュリティベストプラクティス

# ✅ セキュアなDockerfile作成の原則

# 1. ベースイメージは公式・最小版を使う
FROM node:20-alpine  # alpine は最小構成

# 2. 脆弱性スキャン
# $ docker scout cves your-image:latest

# 3. シークレットをビルドに含めない
# ❌ 悪い例
ENV API_KEY=secret123  # イメージ履歴に残る

# ✅ 良い例：実行時に環境変数で渡す
# docker run -e API_KEY=secret123 your-image

# 4. .dockerignoreで不要なファイルを除外
# .dockerignore の内容:
# node_modules
# .env
# .env.local
# .git

CI/CD連携（GitHub Actions）

# .github/workflows/deploy.yml
name: Build and Deploy

on:
  push:
    branches: [main]

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build Docker image
        run: |
          docker build -t ${{ secrets.REGISTRY }}/app:${{ github.sha }} .

      - name: Push to registry
        run: |
          echo ${{ secrets.REGISTRY_PASSWORD }} | docker login \
            -u ${{ secrets.REGISTRY_USERNAME }} --password-stdin
          docker push ${{ secrets.REGISTRY }}/app:${{ github.sha }}

      - name: Deploy to Kubernetes
        run: |
          kubectl set image deployment/web-app \
            web-app=${{ secrets.REGISTRY }}/app:${{ github.sha }}

GitHub Actionsの詳細な活用法はGitHub Actions AI自動化2026で解説しています。

クラウド別Kubernetesサービス比較

サービスクラウド特徴コスト（3ノード）
EKSAWS最も採用例多¥15,000〜/月
GKEGCP管理コスト低¥13,000〜/月
AKSAzureMicrosoft製品連携¥14,000〜/月

AWS・GCP・Azureの詳細比較はAWS vs GCP vs Azure比較2026をご覧ください。

Dockerを使ったローカル開発環境の構築

# よく使うDockerコマンド集

# コンテナ起動（バックグラウンド）
docker compose up -d

# ログ確認
docker compose logs -f app

# コンテナ内でシェル実行
docker compose exec app sh

# ボリュームごと削除（完全リセット）
docker compose down -v

# イメージのサイズ最適化確認
docker images --format "table {{.Repository}}\t{{.Tag}}\t{{.Size}}"

# 脆弱性スキャン
docker scout cves your-image:latest

ヘルスチェックの設計パターン

本番環境では、コンテナの健全性を適切に監視することが不可欠です。

Dockerのヘルスチェック

# Dockerfile — ヘルスチェック付き
FROM node:20-alpine
WORKDIR /app
COPY . .
RUN npm ci && npm run build

# ヘルスチェック設定
HEALTHCHECK --interval=30s --timeout=5s --start-period=10s --retries=3 \
  CMD wget -qO- http://localhost:3000/health || exit 1

CMD ["node", "dist/server.js"]

ヘルスチェックエンドポイントは2つ用意します。

  • /health（Liveness）: プロセスの生存確認。常に200を返す
  • /ready（Readiness）: DB・Redis等の接続確認。依存サービスが使えない場合は503を返す

Kubernetesでは3種類のProbeを使い分けます。

Probe目的失敗時の動作
startupProbe起動完了の確認起動待ち（他のProbe開始を遅延）
livenessProbeプロセス生存確認コンテナ再起動
readinessProbeトラフィック受付可否Serviceから切り離し

リソース制限の設計

コンテナのリソース制限は、安定した本番運用に不可欠です。

Kubernetesでは requests（確保量）と limits（上限）の2つを設定します。limits のmemoryを超えるとOOMKillされ、CPUを超えるとスロットリングが発生します。

アプリケーション種別ごとの推奨値

用途requests (memory/cpu)limits (memory/cpu)
APIサーバー256Mi / 250m512Mi / 1000m
バッチ処理512Mi / 500m2Gi / 2000m
フロントエンド（SSR）512Mi / 500m1Gi / 1000m

Namespaceレベルで ResourceQuota（全体上限）と LimitRange（デフォルト値）を設定すると、リソース設定漏れを防止できます。

監視環境の構築

本番Kubernetes環境には、Prometheus + Grafanaの組み合わせが定番です。

監視の実装手順

  1. アプリケーションで /metrics エンドポイントを公開（prom-client ライブラリ使用）
  2. Prometheusでメトリクスを15秒間隔で収集
  3. Grafanaでダッシュボードを構築
  4. AlertManagerで閾値超過時にSlack通知

Node.jsの場合、prom-client でHTTPリクエスト数・レスポンスタイム・エラー率などのメトリクスを簡単に公開できます。

まとめ：Docker/Kubernetesの習得ロードマップ

Week 1: Docker基礎
  → docker run / build / compose
  → Dockerfile の書き方

Week 2-3: Docker Compose
  → 複数サービスの連携
  → 開発環境の完全コンテナ化

Month 2: Kubernetes基礎
  → minikube でローカルクラスター
  → Deployment / Service / Ingress

Month 3: 本番運用
  → クラウドKubernetes (EKS/GKE/AKS)
  → Helm でパッケージ管理
  → Monitoring (Prometheus / Grafana)

関連記事