Compose File

Docker Compose Explained (With Best Practices & Scenarios)

A Docker Compose file (docker-compose.yml) is used to define and run multi-container Docker applications. It simplifies running multiple services together by defining them in a YAML file and managing them as a single unit.

---

1. Basic Structure of a Docker Compose File

version: '3.8'

services:
  web:
    image: nginx:latest
    ports:
      - "80:80"
    volumes:
      - ./html:/usr/share/nginx/html
    depends_on:
      - app

  app:
    build: .
    environment:
      - NODE_ENV=production
    volumes:
      - ./app:/usr/src/app
    depends_on:
      - db

  db:
    image: postgres:15
    restart: always
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: password
      POSTGRES_DB: mydatabase
    volumes:
      - db_data:/var/lib/postgresql/data

volumes:
  db_data:

---

2. Key Sections in Docker Compose File

2.1 version

• Specifies the Compose file format version.

• Example:

  version: '3.8'

• Best Practice: Use the latest stable version (3.8 or 4.x).

---

2.2 services

Defines the different containers needed for the application. Each service runs in its own isolated container.

Example:

services:
  app:
    build: .
    ports:
      - "5000:5000"

---

2.3 build vs image

Feature	build	image
Function	Builds image from Dockerfile	Pulls pre-built image from registry
Use Case	Custom application code	Using official/public images
Example	build: .	image: nginx:latest

Best Practice:

• Use build when working with custom applications.

• Use image for standard services like nginx, mysql.

---

2.4 ports (Exposing Ports)

Maps ports between host and container.

Example:

ports:
  - "8080:80"

• Format: "host_port:container_port"

Best Practice:

• Expose only necessary ports.

• Use docker network instead of exposing internal services.

---

2.5 volumes (Persistent Storage)

Used for data persistence.

Example:

volumes:
  - ./data:/var/lib/mysql

• Types:

  1. Named Volumes (Managed by Docker)

     volumes:
       db_data:

  2. Bind Mounts (Maps host directories)

     volumes:
       - ./app:/usr/src/app

Best Practice:

• Use named volumes for databases.

• Use bind mounts for development.

---

2.6 depends_on (Service Dependencies)

Specifies that one service depends on another.

Example:

depends_on:
  - db

🔹 Limitation: depends_on only ensures order, NOT service readiness. ✅ Solution: Use healthcheck to wait for the database.

db:
  image: postgres:15
  healthcheck:
    test: ["CMD", "pg_isready", "-U", "user"]
    interval: 10s
    retries: 5
    timeout: 5s

---

2.7 restart Policies

Policy	Description
no (default)	Do not restart the container
always	Restart the container always
unless-stopped	Restart unless manually stopped
on-failure	Restart only on non-zero exit codes

Example:

restart: always

Best Practice: Use unless-stopped for persistent services.

---

2.8 environment (Environment Variables)

Pass environment variables to the container.

Example:

environment:
  - POSTGRES_USER=user
  - POSTGRES_PASSWORD=pass

🔹 Alternative: Use .env file

env_file:
  - .env

Best Practice:

• Avoid storing sensitive values in docker-compose.yml.

• Use .env or Docker secrets instead.

---

3. Reducing Docker Compose Complexity

✅ Use .env Files for Configurations ✅ Minimize ports Exposure (Use Networks) ✅ Use Named Volumes Instead of Bind Mounts for Databases ✅ Use Multi-Stage Builds for Smaller Images ✅ Ensure Service Readiness Using healthcheck

---

4. Multi-Stage Docker Compose (Development vs Production)

Example: docker-compose.override.yml for Development

version: '3.8'

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile.dev
    volumes:
      - .:/usr/src/app
    environment:
      - NODE_ENV=development

Run Development Mode

docker-compose -f docker-compose.yml -f docker-compose.override.yml up

✅ Best Practice:

• Keep docker-compose.yml for production.

• Use docker-compose.override.yml for development.

---

5. Scenario-Based Questions on Docker Compose

Q1: How do you ensure a database service is ready before starting an application?

Answer: Use healthcheck instead of just depends_on.

db:
  image: postgres
  healthcheck:
    test: ["CMD", "pg_isready", "-U", "user"]
    interval: 10s
    retries: 5

---

Q2: How do you share data between containers?

Answer: Use named volumes.

volumes:
  db_data:

---

Q3: How do you override configurations for different environments?

Answer:

• Use .env files for environment variables.

• Use docker-compose.override.yml for dev configurations.

---

6. Summary

Topic	Key Takeaways
services	Defines different containers
build vs image	Use build for custom apps, image for standard services
volumes	Use named volumes for data persistence
depends_on	Ensures order but does not check service readiness (use healthcheck)
restart	Use unless-stopped for persistent services
.env File	Keep secrets/configurations separate

This covers Docker Compose, best practices, and interview scenarios! 🚀 Let me know if you need more details. 😊