Docker Compose

Docker Compose is a tool for defining and running multi-container Docker applications.

It lets you manage multiple services declaratively in one YAML file.

docker-compose.yml (and Compose specification-compatible file names).

A containerized application component defined in Compose config.

A group of services/networks/volumes created from one Compose configuration.

Use docker compose up.

Use docker compose down.

stop halts containers; down removes containers/networks (and optionally volumes).

Starts services in detached (background) mode.

Use docker compose ps.

Use docker compose logs.

Use docker compose logs -f.

Use docker compose up --build.

Instructions for building image from local Dockerfile/context.

Specifies prebuilt image to run for a service.

Yes, commonly for tagging built result.

Maps host ports to container ports.

Documents/internally exposes ports to linked services without host publishing.

Sets environment variables in service containers.

Loads environment variables from external file(s).

File for variable substitution and/or env defaults in Compose context.

Like ${VAR} or ${VAR:-default}.

Virtual network enabling service-to-service communication.

Creates project-scoped default network; services can reach each other by service name.

Persistent storage managed by Docker and attachable to services.

Persist data across container restarts/recreation.

Bind mount uses host path; volume is Docker-managed storage.

Defines startup dependency order between services.

No, it does not guarantee dependency is fully ready.

Use docker compose run.

run starts new container; exec runs command in existing container.

Use docker compose exec <service> sh (or bash if available).

Use docker compose up --scale service=n (where applicable).

Custom fixed container name (often avoided in scalable setups).

Can cause naming collisions and reduce flexibility.

Controls automatic restart behavior (no, always, on-failure, unless-stopped).

Command-based liveness/readiness signal for container health.

Improve reliability and dependency coordination.

Override Dockerfile CMD per environment/service need.

Replace image entrypoint command.

Allocates TTY for interactive/debug workflows.

Keeps STDIN open for interactive containers.

Feature to enable optional service groups (e.g., debug, monitoring).

Use --profile flag.

Controls when images are pulled vs reused locally.

Putting secrets directly in compose YAML committed to git.

Using latest tags everywhere without version pinning.

Use minimal images, non-root users, and keep secrets outside source.

Use build cache and avoid oversized bind mounts.

Healthchecks + restart policies + persistent data volumes.

docker compose config.

Shows merged, resolved final configuration for debugging.

Use docker compose rm.

Use docker compose down -v carefully.

Keep compose files clear, versioned, and environment-specific via overrides/profiles.

Combining base and override files via multiple -f flags.

Separate common config from dev/test/ci-specific settings.

Later files override/extend earlier ones.

Reusable YAML fragments for DRY configuration.

Reuse repeated config blocks safely.

Use -p flag or environment variable to isolate stacks.

Avoid collisions across branches/teams on shared hosts.

Network not exposed externally; limits service reachability.

Declare multiple networks under service.

Segment traffic (frontend/backend/data-plane) for security/isolation.

Alternative DNS name for service on specific network.

Adds custom host-to-IP mappings inside container.

Customize resolvers/search domains/options for containers.

Runs tiny init process for signal forwarding/zombie reaping.

Improves process lifecycle behavior in containers.

Time allowed for graceful shutdown before force kill.

Stateful services may need extra flush/cleanup time.

Sets process resource limits (nofile, nproc, etc.).

Prevent runtime failures under high load.

Kernel parameter tweaks at container runtime (where supported).

Add/remove Linux capabilities for least-privilege tuning.

Reduce attack surface for compromised containers.

Mounts container root filesystem read-only.

Use writable volumes/tmpfs for specific paths.

In-memory filesystem mount for ephemeral data.

Inject secret material without hardcoding in image/environment.

Both inject data; secrets intended for sensitive values with stricter handling.

Auto-sync/rebuild behavior for local development iterations.

Host<->VM filesystem bridging overhead (especially desktop virtualization setups).

Use cached/delegated options (where supported), smaller mounts, sync tools.

Specifies target architecture/OS for image run.

Consistency across mixed-architecture developer machines.

Select specific Dockerfile multi-stage target.

Different images for dev/test/prod from one Dockerfile.

Leverage external build caches to speed CI builds.

Forces rebuild without using cached layers.

Dependency freshness debugging or cache corruption suspicion.

Can coordinate based on service_started/service_healthy semantics (spec/runtime dependent).

Infra ordering is insufficient for real readiness guarantees.

Entry command waits for dependency port/health before app start.

Dedicated service runs migrations/setup before app services.

Named volumes or object storage, depending workflow.

Configures log driver and options per service.

Control size/rotation and centralization behavior.

Limits local log file growth.

CPU/memory/pids limits to prevent host exhaustion.

Catch memory issues early and protect workstation stability.

Tuning for startup grace and transient failures.

Single compose file trying to cover all envs with heavy conditionals.

Base compose + targeted overrides/profiles per environment.

Pin explicit versions/digests for reproducible runs.

Can cause nondeterministic failures across runs.

Spin up integration dependencies for automated test suites.

Use unique project names and always teardown after tests.

Containers from old config no longer referenced by current compose set.

Use --remove-orphans when bringing stack up/down as appropriate.

Schema/data upgrades must be managed between image versions.

Protect state before destructive changes.

compose logs, exec, top, events, inspect, config output.

Excessive host mounts exposing sensitive filesystem paths.

Mount least required paths read-only where possible.

Design services to start independently and retry dependencies gracefully.

Team can reproduce full local stack with one command and deterministic behavior.

Standardize compose templates and document service contracts/ports/health.

Use Compose as declarative environment contract, not ad-hoc scripts.

A stable developer-facing contract abstracting infra complexity.

They define reproducible onboarding, testing, and incident-debug environments.

Differences in config/dependencies cause “works on my machine” failures.

Use shared images, pinned versions, and prod-like settings in dev profiles.

Different host CPUs (amd64/arm64) can change behavior/performance.

Buildx multi-platform images and explicit platform testing matrix.

Self-contained stack with controlled dependencies and deterministic inputs.

Reduce flaky tests caused by shared external services.

Per-branch isolated Compose stack for validation/review.

Shared host conflicts in container/network/volume names.

Unique project names plus automated lifecycle cleanup.

External secret store injection at runtime, not committed plaintext values.

Signed images, SBOMs, vulnerability scanning, trusted registries.

Prevent pulling tampered or untrusted artifacts.

Automated checks enforcing rules (no root, pinned tags, limits required).

Drop caps, read-only FS, non-root user, minimal mounts/networks.

Limit outbound access for sensitive services to reduce exfiltration risk.

Auxiliary container (proxy/agent/exporter) paired with main service.

Better modularity/observability but more operational complexity.

Local emulation of proxies/policies for integration testing.

Dependency graph with healthchecks + init jobs + retry-capable apps.

Real readiness depends on migrations, warmups, and external dependencies.

Inject failures (kill, delay, packet loss) to validate resilience behavior.

Traffic control/proxy tools can emulate latency/loss in local stacks.

Local Prometheus/Grafana/ELK/OTel services alongside app for diagnostics.

Catch telemetry gaps before production.

Local host limits may not reflect production infrastructure accurately.

Trend comparisons and bottleneck discovery under controlled scenarios.

Backup/restore/versioning/cleanup policies for persistent local/CI data.

Versioned migrations + compatibility checks + rollback plans.

Run old/new service versions concurrently and switch traffic route locally.

Route subset of test traffic to new container version.

Central policy for approved base images and versions.

Using Compose as production orchestrator substitute beyond its intended scope.

Use Compose for dev/test; use full orchestrator for large-scale production needs.

Recreate prod-like bug scenarios quickly on engineer machines.

Encode operational steps (init, debug, recovery) as repeatable service tasks.

Pre-merge CI validates compose config and referenced images.

Versioned configs, scan reports, signed artifacts, audit trails.

Optimize parallel stack counts, cache reuse, and teardown discipline.

Port collisions, shared resources, weak readiness checks, orphaned state.

Unique namespaces, health-gated startup, deterministic seeds, strict cleanup.

Capture full compose events/logs/config snapshot as CI artifacts.

Documented reset scripts plus optional seed data restore.

Provide golden templates, lint rules, and shared service definitions.

Stacks must be reproducible, restartable, and dependency-failure tolerant.

No plaintext secrets, least privilege everywhere, trusted artifacts only.

Keep Compose files modular, documented, and policy-validated.

One command up/down with predictable behavior across machines.

Compose excellence is deterministic multi-service environments with strong guardrails.

version: "3.9"

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - "8080:8080"
    environment:
      SPRING_PROFILES_ACTIVE: docker
      DB_HOST: db
    depends_on:
      db:
        condition: service_healthy
    healthcheck:
      test: ["CMD", "wget", "-qO-", "http://localhost:8080/actuator/health"]
      interval: 10s
      timeout: 3s
      retries: 10
    restart: unless-stopped

  db:
    image: postgres:16.4
    environment:
      POSTGRES_DB: app
      POSTGRES_USER: app
      POSTGRES_PASSWORD: app
    volumes:
      - db_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app -d app"]
      interval: 5s
      timeout: 3s
      retries: 20
    restart: unless-stopped

volumes:
  db_data: