What is Docker Compose

In real-world applications, a system is rarely a single isolated container: a Java backend typically requires a PostgreSQL database, a Redis cache, an Apache Kafka broker, and a...

🟢 Junior Level

30-Second Interview Answer

Docker Compose is a declarative tool for orchestrating and managing multi-container applications on a single Docker host using a single configuration file named compose.yaml (or docker-compose.yml).

In real-world applications, a system is rarely a single isolated container: a Java backend typically requires a PostgreSQL database, a Redis cache, an Apache Kafka broker, and an observability stack.

Instead of manually executing dozens of complex docker run commands with custom network, volume, and environment flags, you declare the entire application topology in YAML.
Running docker compose up -d creates the virtual bridge networks, provisions persistent storage volumes, and launches all interdependent services in a synchronized sequence with a single command.

Real-World Analogy: The Orchestra Conductor

Docker CLI (docker run): Like walking up to individual musicians—the drummer, the violinist, the pianist—and shouting at each one separately when to start playing. If the pianist starts before the piano is tuned, the performance is ruined.
Docker Compose: The orchestra conductor. Following a single master musical score (compose.yaml), the conductor waves the baton to cue all musicians in perfect unison, ensuring everyone is in the same room (virtual bridge network) and that the instruments are tuned before the symphony begins (depends_on with healthchecks).

Clean Example: Spring Boot 3 & PostgreSQL

# compose.yaml (Note: top-level 'version' attribute is deprecated in Compose v2)
services:
  app:
    build: .
    ports:
      - "8080:8080"
    environment:
      # Services resolve each other by their declared service name:
      - SPRING_DATASOURCE_URL=jdbc:postgresql://postgres-db:5432/orders_db
      - SPRING_DATASOURCE_USERNAME=postgres
      - SPRING_DATASOURCE_PASSWORD=secret
    depends_on:
      postgres-db:
        condition: service_healthy # Waits for the database to be fully initialized!

  postgres-db:
    image: postgres:16-alpine
    environment:
      - POSTGRES_DB=orders_db
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=secret
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres -d orders_db"]
      interval: 5s
      timeout: 5s
      retries: 5

volumes:
  pgdata: # Named volume for persistent database storage

Core CLI Commands

# 1. Build images and start all containers in detached mode:
docker compose up -d

# 2. Inspect aggregate logs across all services (or specify service name):
docker compose logs -f app

# 3. Stop running containers and tear down networks (volumes preserved):
docker compose down

🟡 Middle Level

Internal Bridge Network & Embedded DNS

When Docker Compose initializes an application stack:

It automatically provisions an isolated virtual bridge network (named <project_name>_default).
It assigns an internal IP to each container and enables Docker’s Embedded DNS Server (listening on 127.0.0.11).
Service Names Become Hostnames: The Java application does not need to know or configure hardcoded IP addresses. Calling postgres-db:5432 is resolved transparently by Docker’s internal DNS to the private container IP of the PostgreSQL service.

`ports` vs `expose`

ports: ["8080:8080"] (Host Port Binding): Binds container port 8080 to host interface port 8080. This makes the service accessible from outside the Docker virtual network (e.g., from a browser on http://localhost:8080 or external API clients).
expose: ["5432"] (Internal Exposure): Makes the port accessible only to neighboring containers sharing the same internal Docker network, without binding to the host’s physical network adapters. This is an enterprise security best practice for databases, caches, and internal queues to prevent unauthorized external access.

The `depends_on` Startup Race Condition Trap

A frequent beginner trap is relying on simple depends_on declarations:

# ❌ ANTI-PATTERN: Application crashes on cold start!
services:
  app:
    depends_on:
      - postgres-db

Why It Fails: By default, depends_on only verifies that the container process has started (PID created).
An enterprise database like PostgreSQL takes 3 to 10 seconds to read catalogs, run recovery, and bind its TCP socket.
Spring Boot starts up rapidly, attempts to establish a HikariCP database connection pool, receives Connection refused, and crashes immediately.
The Solution: Pair depends_on with condition: service_healthy and declare an active healthcheck (e.g. pg_isready).

🔴 Senior Level

Spring Boot 3.1+ Native Docker Compose Integration

Spring Boot 3.1 introduced native development-time orchestration via spring-boot-docker-compose:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-docker-compose</artifactId>
    <scope>runtime</scope>
    <optional>true</optional>
</dependency>

How It Operates Under the Hood:

Automatic Lifecycle: When you run mvn spring-boot:run or launch the application from your IDE, Spring Boot searches the project root for compose.yaml and executes docker compose up automatically.
Dynamic Connection Property Injection: Spring Boot inspects the running containers. It detects the mapped host port and automatically generates ConnectionDetails beans (JDBC URL, credentials, Kafka bootstrap servers, Redis connection factory) into the ApplicationContext without requiring any datasource configuration in application.yml!
Graceful Teardown: Stopping the application inside the IDE automatically shuts down the auxiliary containers.

Zero Trust Network Segmentation

In multi-service environments, placing all containers onto a single flat bridge network violates the principle of least privilege. Compose allows defining segmented network topologies:

services:
  api-gateway:
    image: nginx:alpine
    ports: ["80:80"]
    networks: [frontend-net]

  order-service:
    image: order-service:1.0
    networks: [frontend-net, backend-net]

  postgres-db:
    image: postgres:16-alpine
    networks: [backend-net] # Physically unreachable from api-gateway!

networks:
  frontend-net:
  backend-net:

If an attacker compromises the public-facing Nginx container via an edge vulnerability, they cannot establish TCP connections to the PostgreSQL database because the containers do not share an L2/L3 network.

Horizontal Scaling (`--scale`) & Port Collisions

Running docker compose up --scale order-service=3 allows running 3 concurrent replicas of a service.

The Port Collision Hazard: If compose.yaml specifies a static host port mapping (ports: ["8080:8080"]), scaling fails with: Bind for 0.0.0.0:8080 failed: port is already allocated.
Production Solutions:
1. Omit the host port to enable dynamic port assignment (ports: ["8080"]).
2. Or, better, eliminate external port binding entirely and route traffic through an internal reverse proxy (Nginx, Envoy, or Traefik) connected to the same network. Docker’s embedded DNS automatically round-robins requests across the 3 container IPs.

4 Tricky Questions with In-Depth Answers

1. Why does `docker compose up --scale service=3` fail if the service has `ports: ["8080:8080"]`, and how do you configure proper load balancing?

Answer: The host operating system kernel does not permit multiple independent sockets to bind to the identical TCP port (8080) on the same network interface (0.0.0.0). When Docker attempts to start the second replica, the kernel returns EADDRINUSE. To scale services properly:

Remove host port binding and place an internal reverse proxy (e.g. Nginx, Traefik) on the network, exposing only the proxy on port 80/443.
Configure the proxy to target http://service:8080. Docker Compose’s embedded DNS server (127.0.0.11) maintains an A-record list containing the IP addresses of all 3 running containers and distributes incoming connections using internal round-robin DNS.

2. What is the fundamental difference between `docker compose down` and `docker compose down -v`, and what catastrophe can occur if `-v` is accidentally added?

Answer:

docker compose down: Stops running containers and deletes the virtual bridge networks. Crucially, all named persistent volumes declared under volumes: remain completely untouched on the host disk. Data stored in databases is safe.
docker compose down -v (or --volumes): In addition to stopping containers, it permanently and irreversibly deletes all named storage volumes associated with the project. If executed in a production or shared staging environment, the entire database directory (/var/lib/postgresql/data) is unlinked from the host filesystem, resulting in total data loss.

3. Why can a Java application running locally in an IDE on the host machine not connect to `jdbc:postgresql://postgres-db:5432/mydb` from `compose.yaml`?

Answer: The DNS hostname postgres-db is registered exclusively within Docker’s internal embedded DNS server (127.0.0.11), which is only accessible to processes running inside that specific Docker bridge network. The host operating system resolves domain names through its local network resolver (e.g., systemd-resolved, local router DNS), which has no knowledge of Docker’s internal container names. To connect from an IDE running directly on the host:

Expose the port on the host interface in compose.yaml: ports: ["5432:5432"].
In your local IDE application.yml or run configuration, use localhost: jdbc:postgresql://localhost:5432/mydb.

4. What are Docker Compose override files (`docker-compose.override.yml`), and how does deep merging work?

Answer: By default, executing docker compose up automatically looks for two files in sequence: compose.yaml and docker-compose.override.yml. It applies a deep merge:

Scalar values (like image or container_name) in the override file overwrite values in the base file.
List and map elements (such as ports, environment, volumes) are concatenated and merged. This enables teams to maintain a clean, production-like compose.yaml in version control, while individual engineers maintain an uncommitted docker-compose.override.yml (added to .gitignore) to inject local debug ports (e.g. JVM remote debug port 5005), bind-mount local source directories for hot-reloading, or toggle verbose log levels.

🎯 Interview Cheat Sheet

Summary of Docker Compose

Definition: Single-host declarative multi-container orchestration using YAML.
Embedded DNS: Services resolve each other by service name over internal bridge networks (127.0.0.11).
Synchronized Startup: Always use depends_on: { service: { condition: service_healthy } } with healthcheck.
Spring Boot 3.1+: Use spring-boot-docker-compose for zero-configuration local infrastructure setup.
Storage Lifecycle: Persistent data must use named volumes:; avoid docker compose down -v in non-ephemeral environments.

Docker Compose vs Kubernetes Comparison

Red Flags (DO NOT Say)

❌ “depends_on: [postgres-db] guarantees the database is ready to accept queries.” (It only waits for the container process to spawn; you must use condition: service_healthy).
❌ “Docker Compose is used to orchestrate a 50-node production cluster.” (Compose is single-host only; use Kubernetes for cluster management).
❌ “I always use docker compose down -v to reset my containers.” (Fails to realize -v irreversibly wipes out persistent database volumes).
❌ “ports and expose do the exact same thing.” (ports binds to host network interfaces; expose allows container-to-container communication only).

What is Kubernetes and Why is It Needed — Transitioning from single-host to cluster orchestration
What is Service in Kubernetes — Service discovery and load balancing in clusters
Why are Health Checks Needed — Health checks and probes in production
What is Dockerfile — Defining individual container images