小規模〜中規模開発に適したDocker Compose

Docker Composeは、開発者が複数のDockerコンテナを簡単に構成・起動できるツールです。

YAMLファイルを使ってサービスやネットワーク、ボリュームなどを記述し、1コマンドで一括管理できます。

基本構成例

yamlCopy code# docker-compose.yml
version: '3.9'
services:
  app:
    image: node:18
    volumes:
      - .:/app
    working_dir: /app
    command: ["npm", "start"]
    ports:
      - "3000:3000"
  db:
    image: postgres:15
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: pass
      POSTGRES_DB: example
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:

起動コマンド

bashCopy codeyarn docker:up
# または
docker-compose up -d

特徴と利点

公式ドキュメント：https://docs.docker.com/compose/

本番環境・スケーラビリティ重視ならKubernetes

Kubernetesは、複数ノード上のコンテナを自動的にスケール・復旧・展開するための本格的なオーケストレーションシステムです。

複雑な構成を前提としており、大規模なプロダクション環境に適しています。

基本構成例（Deployment + Service）

yamlCopy code# app-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: node-app
  template:
    metadata:
      labels:
        app: node-app
    spec:
      containers:
        - name: node-app
          image: node:18
          ports:
            - containerPort: 3000

yamlCopy code# app-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: app-service
spec:
  selector:
    app: node-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 3000
  type: LoadBalancer

適用コマンド

bashCopy codekubectl apply -f app-deployment.yaml
kubectl apply -f app-service.yaml

特徴と利点

公式ドキュメント：https://kubernetes.io/ja/docs/home/

YAML構文の違いから見る構成の複雑性

ローカル vs クラウド

たとえば、EKS（AWS）、GKE（GCP）、AKS（Azure）といったKubernetesのマネージドサービスを活用することで、運用の負担を軽減できます。

公式リンク：

• Amazon EKS
• Google GKE
• Azure AKS

開発から運用への移行を考えると…

開発初期はDocker Composeでシンプルに始め、
スケールや信頼性が求められるフェーズに入った段階でKubernetesへ移行するのが一般的です。

以下のようなステップを取ることでスムーズに移行できます。

bashCopy code# Komposeを使ってCompose → Kubernetesへ変換
kompose convert -f docker-compose.yml

ユースケースで見る適切な選択指針

実際のプロジェクトでは、どちらを選ぶべきかは利用シーンによって大きく異なります。

ここでは、代表的なユースケースごとに適した選択を紹介いたします。

ローカル開発：Docker Composeが優位

• 単一リポジトリでの開発
• バックエンド＋フロントエンド＋DBの組み合わせが中心
• ローカルでのホットリロードやデバッグを重視

実例：React + Node.js + PostgreSQL

yamlCopy code# docker-compose.yml
version: '3.8'
services:
  frontend:
    build: ./frontend
    ports:
      - "3000:3000"
    volumes:
      - ./frontend:/app
      - /app/node_modules
    environment:
      - CHOKIDAR_USEPOLLING=true
  backend:
    build: ./backend
    ports:
      - "4000:4000"
    depends_on:
      - db
  db:
    image: postgres:15
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: devdb
      POSTGRES_USER: devuser
      POSTGRES_PASSWORD: devpass

volumes:
  pgdata:

これだけで3つのコンテナが一斉に起動し、連携可能です。学習コストも低く、数分で開発開始できます。

本番運用：Kubernetesが圧倒的に有利

• スケールが必要
• 自動復旧・セルフヒーリングが求められる
• CI/CD・GitOpsと連携した高度な運用が必要

実例：3つのアプリをKubernetesで運用

yamlCopy code# frontend-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
spec:
  replicas: 2
  selector:
    matchLabels:
      app: frontend
  template:
    metadata:
      labels:
        app: frontend
    spec:
      containers:
        - name: frontend
          image: myregistry.com/frontend:latest
          ports:
            - containerPort: 3000

このようにアプリごとに Deployment、Service を分けて管理し、Ingress や HorizontalPodAutoscaler を追加することで大規模なアーキテクチャへ拡張可能です。

Docker ComposeからKubernetesへの移行戦略

開発段階でComposeを使っていた場合でも、後からKubernetesに移行可能です。

Komposeを使った自動変換

bashCopy codekompose convert -f docker-compose.yml

これにより、Deployment / Service / PersistentVolumeClaim などが自動生成されます。

ただし、以下のような差異には注意が必要です：

Skaffoldなどによる両対応環境の構築

Googleが提供するSkaffoldを利用することで、ComposeでもK8sでもビルド・デプロイが一貫して行えます。

yamlCopy code# skaffold.yaml（抜粋）
deploy:
  kubectl:
    manifests:
      - k8s/*

CI/CD環境でもそのまま流用でき、学習→運用の橋渡しが可能になります。

Kubernetesを学ぶためのロードマップ

Kubernetesは複雑なため、段階的な学習が必要です。

ステップ別ロードマップ

最初は minikube などローカルK8sから始めると良いでしょう。

両者を組み合わせるアプローチ

実はDocker ComposeとKubernetesは併用可能です。

例：開発はCompose、本番はK8s

• docker-compose.dev.yml でローカル開発
• helm chart + GitOpsでK8sにデプロイ

CI環境では Dockerfile を共通で使い回すこともでき、構成の重複を避けられます。

まとめ

Docker ComposeとKubernetesは、競合ではなく補完関係にあります。

無理にどちらかに統一せず、段階的な導入と併用の戦略を取ることで、スムーズな運用体験が得られます。

今後は、Helm・Argo CD・Kustomizeなどと連携した拡張にも注目することで、さらに強力なオーケストレーション環境が構築できるようになります。