单体仓库多微服务Docker化咨询：是否需为每个微服务配置Dockerfile及.dockerignore

Great question—Dockerizing a multi-microservice Node.js/TypeScript project does require more intentional structure than simple single-service setups, but it’s totally manageable once you break it down. Let’s walk through the best practices tailored to your project structure.

Core Answer: Do You Need Separate Dockerfiles & .dockerignore? #

• Dockerfiles: Yes, you absolutely want a dedicated Dockerfile for each microservice (request-manager, request-worker, rest-api). This keeps each service’s build process isolated, ensures minimal image sizes (only including what that service needs), and lets you deploy/scale services independently.
• .dockerignore: You can get away with a single root-level .dockerignore for most cases, since most ignored files (like node_modules, test folders, or local configs) are universal across all services. If a specific service has unique files to ignore, you can add a small supplementary .dockerignore in that service’s directory, but this is rarely necessary.

Step-by-Step Implementation #

1. Adjust Your Project Structure (Slightly) #

Keep your existing layout, but add a Dockerfile inside each microservice’s directory:

your-project/
├── node_modules/
├── src/
│   ├── request-manager/
│   │   ├── ...
│   │   └── Dockerfile  # New
│   ├── request-worker/
│   │   ├── ...
│   │   └── Dockerfile  # New
│   ├── rest-api/
│   │   ├── ...
│   │   └── Dockerfile  # New
│   └── shared/
├── test/
├── package.json
├── tsconfig.json
└── .dockerignore  # Root-level

2. Root-Level .dockerignore #

Add this to ignore universal clutter that shouldn’t end up in any of your images:

node_modules/
test/
.git/
.gitignore
.env
*.log
dist/  # Ignore local TypeScript builds
.vscode/

3. Example Dockerfile for a Microservice (TypeScript) #

Since you’re using TypeScript, we’ll use a multi-stage build to keep production images small (no dev dependencies or compile tools included). Here’s a template for src/request-manager/Dockerfile:

# Stage 1: Compile TypeScript to JavaScript
FROM node:20-alpine AS builder
WORKDIR /app

# Copy dependency files first to leverage Docker cache
COPY package*.json ./
COPY tsconfig.json ./

# Copy shared code (since all services depend on it)
COPY src/shared/ ./src/shared/

# Copy only this service's source code
COPY src/request-manager/ ./src/request-manager/

# Install all dependencies (including dev for compiling)
RUN npm ci
# Compile just this service's code
RUN npm run build -- --project src/request-manager

# Stage 2: Production-ready image (small, minimal dependencies)
FROM node:20-alpine AS production
WORKDIR /app

# Copy only production dependencies
COPY package*.json ./
RUN npm ci --only=production

# Copy compiled code from the builder stage
COPY --from=builder /app/dist/src/request-manager/ ./dist/
# Copy shared code (if it's used directly in runtime, or copy compiled shared code if applicable)
COPY --from=builder /app/src/shared/ ./src/shared/

# Set production environment
ENV NODE_ENV=production

# Expose the port your service uses (adjust as needed)
EXPOSE 3001

# Start the service
CMD ["node", "dist/index.js"]

Repeat this template for request-worker and rest-api, adjusting the port, build path, and start command to match each service.

4. Manage All Services with Docker Compose (Optional But Recommended) #

For local development and orchestrated deployment, add a docker-compose.yml at the root to spin up all services with one command:

version: '3.8'
services:
  request-manager:
    build: ./src/request-manager
    ports:
      - "3001:3001"
    environment:
      - NODE_ENV=development
    volumes:
      - ./src/request-manager:/app/src/request-manager  # Hot reload for local dev
      - ./src/shared:/app/src/shared
      - /app/node_modules  # Avoid overwriting container dependencies with local ones

  request-worker:
    build: ./src/request-worker
    ports:
      - "3002:3002"
    environment:
      - NODE_ENV=development
    volumes:
      - ./src/request-worker:/app/src/request-worker
      - ./src/shared:/app/src/shared
      - /app/node_modules

  rest-api:
    build: ./src/rest-api
    ports:
      - "3000:3000"
    environment:
      - NODE_ENV=development
    volumes:
      - ./src/rest-api:/app/src/rest-api
      - ./src/shared:/app/src/shared
      - /app/node_modules

Run docker-compose up --build to start all services with hot reloading for local development. For production, remove the volumes section to use the compiled code from the Docker image.

Key Mistakes to Avoid #

• Don’t copy the entire project root into each container: This bloats images with unused code from other services and wastes build time. Only copy what each service needs (its own code + shared code).
• Don’t skip multi-stage builds: Production images should only include runtime dependencies, not compile tools or dev packages—this drastically reduces image size and attack surface.
• Don’t ignore Docker cache: Always copy package*.json before your source code so Docker can reuse the dependency install layer when only code changes.

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