Hey there! Let’s cut through the noise of all those Docker tools you’re confused about—since you’re working with a single physical server, you don’t need Swarm Mode, Docker Cloud, or docker deploy. The simplest, most production-ready approach is doubling down on the docker-compose setup you already have, with a few key tweaks to make it robust.

First, let’s quickly clarify what those other tools do so you can stop wondering:

• Docker Hub: Just a registry to store/pull pre-built Docker images (like PostgreSQL or Nginx). You’ll use this, but it’s not a deployment tool.
• Docker Cloud: A managed orchestration service for scaling across multiple servers—total overkill for one machine.
• Swarm Mode / docker deploy: Docker’s built-in clustering tool for multi-host setups. Great if you need to scale later, but adds unnecessary complexity for a single server.
• docker-compose: Exactly what you need—designed to define and run multi-container apps on a single host. It’s perfect for your 12-service stack.

Step-by-Step Simplest Production Deployment #

1. Tune Your docker-compose.yml for Production #

You already have a working compose file—here’s how to make it production-ready:

• Environment Variables: Use a dedicated .env.prod file to manage production-specific values (avoid hardcoding secrets!). Load it with the --env-file flag when running commands:

  services:
    web:
      image: your-custom-web-image
      environment:
        - NODE_ENV=production
        - DB_HOST=db
      env_file:
        - .env.prod  # Stores DB_PASSWORD, API_KEY, etc.
  

• Kill Dev-Only Services: You mentioned webpack as a service—don’t run webpack as a long-running service in production. Instead, build your static assets locally (or in a CI pipeline) and copy them into your web server image. If you must build in-container, run it as a one-off job before starting the stack:

  docker-compose run --rm webpack npm run build
  

• Resource Limits: Prevent any service from hogging your server’s CPU/memory:

  web:
    resources:
      limits:
        cpus: '0.5'
        memory: 512M
      reservations:
        cpus: '0.25'
        memory: 256M
  

• Auto-Recover on Crash: Set restart: always for all production services to ensure they restart if they fail:

  web:
    restart: always
  

• Persistent Database Data: Double-check your database service uses a volume to avoid data loss:

  db:
    image: postgres:15
    volumes:
      - postgres_data:/var/lib/postgresql/data/
    restart: always
  volumes:
    postgres_data:
  

2. Build/Pull Your Images #

• For custom images (like your web app), build them locally on the server (or build elsewhere, push to Docker Hub, then pull):

  docker-compose build --no-cache  # Ensures you get a fresh, clean build
  

• Pre-built images (PostgreSQL, Nginx) will be pulled automatically by docker-compose if they’re not already on your server.

3. Start the Production Stack #

Run the stack in detached mode so it runs in the background:

docker-compose --env-file .env.prod up -d

Verify all services are running:

docker-compose ps

4. Manage Your Stack #

• View Logs: Troubleshoot issues with real-time logs:

  docker-compose logs -f  # Follow all service logs
  docker-compose logs -f web  # Only view web service logs
  

• Update Services: If you modify your compose file or images, refresh the stack:

  docker-compose down  # Stops containers (volumes stay intact)
  docker-compose build --no-cache
  docker-compose --env-file .env.prod up -d
  

• Or use docker-compose --env-file .env.prod up -d --force-recreate to restart containers without taking the whole stack down (ensure your app handles restarts gracefully!).

5. Critical Security Tips for Production #

• Don’t Run as Root: Update your Dockerfiles to create a non-root user and run the app with that user to reduce attack surface.
• Restrict Network Access: docker-compose creates a private network by default—only expose ports for your web service (never expose database ports directly to the internet).
• Use Secrets for Sensitive Data: For really sensitive info (like DB passwords), use Docker secrets instead of env files:

  services:
    db:
      secrets:
        - db_password
  secrets:
    db_password:
      file: ./db_password.txt  # Set file permissions to chmod 600
  

• Keep Images Updated: Regularly pull the latest base images (Node.js, PostgreSQL) to patch security vulnerabilities.

6. Handle Your Command-Line Tool #

• Run it inside a running container with docker-compose exec:

  docker-compose exec web ./your-cli-tool your-command
  

• If it’s a standalone tool, define it as a service in your compose file and run it as a one-off:

  services:
    cli:
      image: your-cli-image
      command: ["your-cli", "arg1", "arg2"]
      env_file:
        - .env.prod
  

  docker-compose run --rm cli
  

内容的提问来源于stack exchange，提问作者Dagrada