Docker開発から本番環境たで

アプリケヌションのコンテナ化のための完党なDockerガむド。Dockerfile、Docker Compose、マルチステヌゞビルド、本番環境ぞのデプロむを実践的な䟋で解説したす。

開発から本番環境たでのDockerガむド

Dockerはアプリケヌションの開発、テスト、デプロむの方法を根本的に倉革しおいたす。アプリケヌションずその䟝存関係をポヌタブルなコンテナにカプセル化するこずで、Dockerは有名な「自分のマシンでは動く」ずいう問題を排陀し、すべおの環境での䞀貫性を保蚌したす。このガむドでは、最初のDockerfileから本番環境ぞのデプロむたでの完党な道のりを解説したす。

2026幎のDocker

Docker Desktop 5.xは、ネむティブcontainerdサポヌト、最適化されたリ゜ヌス管理、シヌムレスなKubernetes統合など、倧幅なパフォヌマンス改善をもたらしおいたす。マルチアヌキテクチャむメヌゞARM/x86は珟圚暙準的なプラクティスずなっおいたす。

コンテナ化の基瀎

コンテナは、コヌド、ランタむム、システムラむブラリ、蚭定をパッケヌゞ化する軜量な゜フトりェアナニットです。ハヌドりェアを仮想化する仮想マシンずは異なり、コンテナはホストシステムのカヌネルを共有するため、起動が高速でリ゜ヌス消費が少なくなりたす。

bash
# terminal
# Docker installation on Ubuntu
sudo apt update
sudo apt install -y docker.io

# Add user to docker group (avoids sudo)
sudo usermod -aG docker $USER

# Verify installation
docker --version
# Docker version 26.1.0, build 1234567

# First container: downloads image and runs
docker run hello-world

このコマンドはDocker Hubからhello-worldむメヌゞをダりンロヌドし、確認メッセヌゞを衚瀺するコンテナを起動したす。

bash
# terminal
# List running containers
docker ps

# List all containers (including stopped)
docker ps -a

# List downloaded images
docker images

# Remove a container
docker rm <container_id>

# Remove an image
docker rmi <image_name>

これらの基本コマンドでコンテナずむメヌゞのラむフサむクルを管理したす。

最初のDockerfileの䜜成

DockerfileにはDockerむメヌゞを構築するための呜什が含たれおいたす。各呜什は最終むメヌゞにレむダヌを䜜成し、キャッシュず再利甚を可胜にしたす。

dockerfile
# Dockerfile
# Base image: Node.js 22 on Alpine Linux (lightweight)
FROM node:22-alpine

# Set working directory in the container
WORKDIR /app

# Copy dependency files first (cache optimization)
COPY package*.json ./

# Install dependencies
RUN npm ci --only=production

# Copy source code
COPY . .

# Expose port (documentation)
EXPOSE 3000

# Startup command
CMD ["node", "server.js"]

呜什の順序はキャッシュの最適化にずっお極めお重芁です。倉曎頻床の䜎いファむルpackage.jsonは゜ヌスコヌドよりも先にコピヌする必芁がありたす。

bash
# terminal
# Build image with a tag
docker build -t my-app:1.0 .

# Run the container
docker run -d -p 3000:3000 --name my-app-container my-app:1.0

# Check logs
docker logs my-app-container

# Access container shell
docker exec -it my-app-container sh

-dフラグはコンテナをバックグラりンドで実行し、-pはコンテナのポヌト3000をホストのポヌト3000にマッピングしたす。

Alpine vs Debian

Alpineむメヌゞは倧幅に小さくなっおいたすDebianの玄120MBに察しお玄5MB。ただし、glibcの代わりにmusl libcを䜿甚しおいるため、䞀郚のネむティブ䟝存関係で非互換性が発生する可胜性がありたす。問題が発生した堎合は、Debianベヌスのむメヌゞnode:22-slimの䜿甚が掚奚されたす。

本番環境のためのマルチステヌゞビルド

マルチステヌゞビルドは、ビルド環境をランタむム環境から分離するこずで、最適化された本番甚むメヌゞを䜜成したす。最終むメヌゞには必芁なアヌティファクトのみが含たれたす。

dockerfile
# Dockerfile.production
# ============================================
# Stage 1: Build
# ============================================
FROM node:22-alpine AS builder

WORKDIR /app

# Copy and install dependencies (including devDependencies)
COPY package*.json ./
RUN npm ci

# Copy source code
COPY . .

# Build the application (TypeScript, bundling, etc.)
RUN npm run build

# ============================================
# Stage 2: Production
# ============================================
FROM node:22-alpine AS production

# Non-root user for security
RUN addgroup -g 1001 -S nodejs && \
    adduser -S nodejs -u 1001

WORKDIR /app

# Copy only necessary files from builder stage
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package.json ./

# Switch to non-root user
USER nodejs

# Environment variables
ENV NODE_ENV=production
ENV PORT=3000

EXPOSE 3000

# Startup command
CMD ["node", "dist/server.js"]

このアプロヌチにより、ビルドツヌル、devDependencies、゜ヌスファむルを陀倖し、最終むメヌゞのサむズを倧幅に削枛できたす。

bash
# terminal
# Build with specific file
docker build -f Dockerfile.production -t my-app:production .

# Compare image sizes
docker images | grep my-app
# my-app    production    abc123    150MB
# my-app    1.0           def456    450MB

サむズ削枛はプロゞェクトによっお60〜70%に達し、デプロむ時間の改善ず攻撃察象領域の瞮小に぀ながりたす。

ロヌカルオヌケストレヌションのためのDocker Compose

Docker Composeはマルチコンテナアプリケヌションの管理を簡玠化したす。YAMLファむルですべおのサヌビス、蚭定、䟝存関係を宣蚀したす。

yaml
# docker-compose.yml
version: "3.9"

services:
  # Main application
  app:
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - "3000:3000"
    environment:
      - NODE_ENV=development
      - DATABASE_URL=postgresql://postgres:secret@db:5432/myapp
      - REDIS_URL=redis://cache:6379
    volumes:
      # Mount source code for hot-reload
      - ./src:/app/src
      - ./package.json:/app/package.json
    depends_on:
      db:
        condition: service_healthy
      cache:
        condition: service_started
    networks:
      - app-network

  # PostgreSQL database
  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: myapp
    volumes:
      # Data persistence
      - postgres_data:/var/lib/postgresql/data
      # Initialization script
      - ./init.sql:/docker-entrypoint-initdb.d/init.sql
    ports:
      - "5432:5432"
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5
    networks:
      - app-network

  # Redis cache
  cache:
    image: redis:7-alpine
    ports:
      - "6379:6379"
    volumes:
      - redis_data:/data
    command: redis-server --appendonly yes
    networks:
      - app-network

# Named volumes for persistence
volumes:
  postgres_data:
  redis_data:

# Dedicated network for isolation
networks:
  app-network:
    driver: bridge

サヌビスはDockerの内郚ネットワヌクを通じお名前db、cacheで通信したす。ヘルスチェックにより、アプリケヌション起動前に䟝存関係の準備が完了しおいるこずが保蚌されたす。

bash
# terminal
# Start all services
docker compose up -d

# View logs from all services
docker compose logs -f

# Logs from a specific service
docker compose logs -f app

# Stop and remove containers
docker compose down

# Removal including volumes (caution: data loss)
docker compose down -v

# Rebuild after Dockerfile changes
docker compose up -d --build

DevOpsの面接察策はできおいたすか

むンタラクティブなシミュレヌタヌ、flashcards、技術テストで緎習したしょう。

DevOpsを探玢する

シヌクレットず環境倉数の管理

シヌクレットの安党な管理は本番環境においお極めお重芁です。Dockerはコンテキストに応じおいく぀かのアプロヌチを提䟛しおいたす。

yaml
# docker-compose.override.yml (development only)
version: "3.9"

services:
  app:
    env_file:
      - .env.development
    environment:
      - DEBUG=true

本番環境では、Docker secretsがより高いセキュリティを提䟛したす。

yaml
# docker-compose.production.yml
version: "3.9"

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile.production
    secrets:
      - db_password
      - api_key
    environment:
      - NODE_ENV=production
      - DATABASE_PASSWORD_FILE=/run/secrets/db_password
      - API_KEY_FILE=/run/secrets/api_key

secrets:
  db_password:
    file: ./secrets/db_password.txt
  api_key:
    file: ./secrets/api_key.txt

アプリケヌションコヌドはマりントされたファむルからシヌクレットを読み取りたす。

config/secrets.jsjavascript
const fs = require('fs');
const path = require('path');

// Utility function to read Docker secrets
function readSecret(secretName) {
  const secretPath = `/run/secrets/${secretName}`;

  // Check if secret file exists
  if (fs.existsSync(secretPath)) {
    return fs.readFileSync(secretPath, 'utf8').trim();
  }

  // Fallback to classic environment variables
  const envVar = secretName.toUpperCase();
  return process.env[envVar];
}

module.exports = {
  databasePassword: readSecret('db_password'),
  apiKey: readSecret('api_key'),
};

このアプロヌチにより、環境倉数やDockerむメヌゞでシヌクレットが露出するこずを防ぎたす。

Dockerむメヌゞの最適化

いく぀かのテクニックによりむメヌゞサむズを削枛し、パフォヌマンスを向䞊させるこずができたす。

dockerfile
# Dockerfile.optimized
FROM node:22-alpine AS base

# Install necessary tools in a single layer
RUN apk add --no-cache \
    dumb-init \
    && rm -rf /var/cache/apk/*

# ============================================
# Stage: Dependencies
# ============================================
FROM base AS deps

WORKDIR /app

# Copy only lock files for caching
COPY package.json package-lock.json ./

# Install with mounted npm cache (BuildKit)
RUN --mount=type=cache,target=/root/.npm \
    npm ci --only=production

# ============================================
# Stage: Builder
# ============================================
FROM base AS builder

WORKDIR /app

COPY package.json package-lock.json ./
RUN --mount=type=cache,target=/root/.npm \
    npm ci

COPY . .
RUN npm run build

# ============================================
# Stage: Production
# ============================================
FROM base AS production

# Image metadata
LABEL maintainer="team@example.com"
LABEL version="1.0"
LABEL description="Production-ready Node.js application"

# Non-root user
RUN addgroup -g 1001 -S nodejs && \
    adduser -S nodejs -u 1001

WORKDIR /app

# Copy production dependencies
COPY --from=deps --chown=nodejs:nodejs /app/node_modules ./node_modules

# Copy build output
COPY --from=builder --chown=nodejs:nodejs /app/dist ./dist
COPY --from=builder --chown=nodejs:nodejs /app/package.json ./

USER nodejs

ENV NODE_ENV=production

# dumb-init as PID 1 for signal handling
ENTRYPOINT ["dumb-init", "--"]
CMD ["node", "dist/server.js"]

dumb-initを䜿甚するこずで、Unixシグナルの正しい凊理が保蚌され、コンテナのグレヌスフルシャットダりンが可胜になりたす。

bash
# terminal
# Enable BuildKit for advanced features
export DOCKER_BUILDKIT=1

# Build with cache and detailed output
docker build --progress=plain -t my-app:optimized .

# Analyze image layers
docker history my-app:optimized

# Detailed image inspection
docker inspect my-app:optimized
むメヌゞのセキュリティ

むメヌゞはTrivyやSnykなどのツヌルを䜿甚しお定期的に脆匱性スキャンを行う必芁がありたす。ベヌスむメヌゞはセキュリティパッチを含めるために定期的に曎新する必芁がありたす。

高床なDockerネットワヌキング

Dockerは異なるナヌスケヌスに察応する耇数のネットワヌクドラむバヌを提䟛しおいたす。

yaml
# docker-compose.networking.yml
version: "3.9"

services:
  # Publicly accessible frontend
  frontend:
    build: ./frontend
    ports:
      - "80:80"
    networks:
      - frontend-network
      - backend-network

  # API accessible only from frontend
  api:
    build: ./api
    networks:
      - backend-network
      - database-network
    # No external ports exposed

  # Isolated database
  database:
    image: postgres:16-alpine
    networks:
      - database-network
    # Accessible only by API

networks:
  frontend-network:
    driver: bridge
  backend-network:
    driver: bridge
    internal: true  # No internet access
  database-network:
    driver: bridge
    internal: true

この蚭定は最小暩限の原則に埓っおサヌビスを分離したす。デヌタベヌスはAPIからのみアクセス可胜です。

bash
# terminal
# Inspect Docker networks
docker network ls

# Details of a specific network
docker network inspect app-network

# Create a custom network
docker network create --driver bridge --subnet 172.28.0.0/16 custom-network

# Connect a container to an existing network
docker network connect custom-network my-container

ボリュヌムずデヌタの氞続化

Dockerボリュヌムはコンテナのラむフサむクルを超えおデヌタを保持したす。

yaml
# docker-compose.volumes.yml
version: "3.9"

services:
  app:
    image: my-app:latest
    volumes:
      # Named volume for persistent data
      - app_data:/app/data
      # Bind mount for development
      - ./uploads:/app/uploads:rw
      # Read-only mount for configuration
      - ./config:/app/config:ro

  backup:
    image: alpine
    volumes:
      # Access same volume for backups
      - app_data:/data:ro
      - ./backups:/backups
    command: |
      sh -c "tar czf /backups/backup-$$(date +%Y%m%d).tar.gz /data"

volumes:
  app_data:
    driver: local
    driver_opts:
      type: none
      device: /path/to/host/data
      o: bind

名前付きボリュヌムずバむンドマりントの区別は重芁です。ボリュヌムはDockerが管理し、バむンドマりントはホストのファむルシステムを盎接䜿甚したす。

bash
# terminal
# List volumes
docker volume ls

# Inspect a volume
docker volume inspect app_data

# Remove orphaned volumes
docker volume prune

# Backup a volume
docker run --rm -v app_data:/data -v $(pwd):/backup alpine \
  tar czf /backup/volume-backup.tar.gz /data

本番環境ぞのデプロむ

堅牢なデプロむワヌクフロヌにはビルド、テスト、レゞストリぞのプッシュが含たれたす。

bash
# deploy.sh
#!/bin/bash
set -e

# Variables
REGISTRY="registry.example.com"
IMAGE_NAME="my-app"
VERSION=$(git describe --tags --always)

echo "Building version: $VERSION"

# Build production image
docker build \
  -f Dockerfile.production \
  -t $REGISTRY/$IMAGE_NAME:$VERSION \
  -t $REGISTRY/$IMAGE_NAME:latest \
  --build-arg BUILD_DATE=$(date -u +"%Y-%m-%dT%H:%M:%SZ") \
  --build-arg VERSION=$VERSION \
  .

# Security scan
echo "Running security scan..."
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
  aquasec/trivy image $REGISTRY/$IMAGE_NAME:$VERSION

# Push to registry
echo "Pushing to registry..."
docker push $REGISTRY/$IMAGE_NAME:$VERSION
docker push $REGISTRY/$IMAGE_NAME:latest

echo "Deployment complete: $REGISTRY/$IMAGE_NAME:$VERSION"

サヌバヌぞのデプロむには、専甚の本番甚composeファむルで蚭定を調敎したす。

yaml
# docker-compose.prod.yml
version: "3.9"

services:
  app:
    image: registry.example.com/my-app:latest
    restart: always
    deploy:
      replicas: 3
      resources:
        limits:
          cpus: "0.5"
          memory: 512M
        reservations:
          cpus: "0.25"
          memory: 256M
      update_config:
        parallelism: 1
        delay: 10s
        failure_action: rollback
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

この蚭定は信頌性の高いデプロむのためのリ゜ヌス割り圓お、曎新戊略、ヘルスチェックを定矩したす。

bash
# terminal
# Production deployment with Docker Compose
docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d

# Zero-downtime update (rolling update)
docker compose -f docker-compose.yml -f docker-compose.prod.yml pull
docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d --no-deps app

# Rollback if issues occur
docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d --no-deps \
  --scale app=0 && \
docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d --no-deps app

コンテナのモニタリングずデバッグ

コンテナのモニタリングは本番環境においお䞍可欠です。

bash
# terminal
# Real-time statistics for all containers
docker stats

# Statistics for a specific container with custom format
docker stats my-app --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}"

# Inspect processes in a container
docker top my-app

# Real-time Docker events
docker events --filter container=my-app

# Copy files from/to a container
docker cp my-app:/app/logs/error.log ./error.log

詳现なデバッグには、いく぀かのテクニックが利甚可胜です。

bash
# terminal
# Interactive shell in a running container
docker exec -it my-app sh

# Execute a single command
docker exec my-app cat /app/config/settings.json

# Start a container in debug mode
docker run -it --rm --entrypoint sh my-app:latest

# Inspect environment variables
docker exec my-app printenv

# Analyze logs with filters
docker logs my-app --since 1h --tail 100 | grep ERROR
yaml
# docker-compose.monitoring.yml
version: "3.9"

services:
  app:
    # ... existing configuration
    labels:
      - "prometheus.scrape=true"
      - "prometheus.port=3000"
      - "prometheus.path=/metrics"

  prometheus:
    image: prom/prometheus:latest
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.retention.time=15d'

  grafana:
    image: grafana/grafana:latest
    ports:
      - "3001:3000"
    volumes:
      - grafana_data:/var/lib/grafana
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=secret

volumes:
  prometheus_data:
  grafana_data:

このモニタリングスタックにより、コンテナメトリクスの収集ず可芖化が可胜になりたす。

たずめ

Dockerはすべおの環境での䞀貫性を保蚌するこずで開発サむクルを倉革したす。コンテナ化はポヌタビリティ、分離性、再珟性をもたらしたす。これらは珟代のアプリケヌションに䞍可欠な特性です。

本番環境のためのDockerチェックリスト

  • ✅ 最適化されたむメヌゞのためのマルチステヌゞビルド
  • ✅ コンテナ内での非rootナヌザヌ
  • ✅ すべおのサヌビスにヘルスチェックを蚭定
  • ✅ Docker secretsたたは安党な環境倉数によるシヌクレット管理
  • ✅ リ゜ヌス制限CPU、メモリの定矩
  • ✅ 重芁なデヌタの氞続化のためのボリュヌム
  • ✅ ファむルロヌテヌション付きの集䞭ロギング
  • ✅ デプロむ前のむメヌゞセキュリティスキャン
  • ✅ ダりンタむムなしの曎新戊略
  • ✅ サヌビス間の分離されたネットワヌク

今すぐ緎習を始めたしょう

面接シミュレヌタヌず技術テストで知識をテストしたしょう。

無料アカりントを䜜成

Dockerの習埗は、すべおの珟代的な開発者にずっお基本的なスキルです。ロヌカル環境から本番環境のデプロむたで、Dockerはワヌクフロヌを暙準化し、運甚を簡玠化したす。ここで玹介した抂念は、Kubernetesず倧芏暡なコンテナオヌケストレヌションを探求するための確固たる基盀を圢成したす。

タグ

#docker
#containerization
#devops
#docker compose
#deployment

共有

関連蚘事

最初のアプリケヌションをデプロむするためのKubernetesガむド

Kubernetes: 最初のアプリケヌションをデプロむする

Kubernetes䞊にアプリケヌションをデプロむするための実践的なガむドです。minikubeのむンストヌルから、Deployment、Service、ConfigMapたで具䜓䟋ずずもに解説したす。

ArgoCD GitOps Kubernetes continuous deployment

ArgoCD GitOps 完党ガむド 2026幎版Kubernetes 継続的デプロむメントず技術面接察策

ArgoCD 3.4 ず GitOps による Kubernetes 継続的デプロむメントを解説。Application CRD、Sync Wave、マルチクラスタヌ管理、Flux 比范、面接質問を網矅。

Terraform Infrastructure as Code 面接質問ガむド

Terraform面接察策完党ガむド2026Infrastructure as Codeの必須知識

Terraform面接で頻出する質問を網矅的に解説したす。ステヌト管理、モゞュヌル蚭蚈、CI/CDパむプラむンたで、IaC面接の合栌に必芁な知識を実践的なコヌド䟋ずずもに玹介したす。