Docker Compose hay Dockerfile: giải pháp nào tốt hơn?

Bạn không phải người đầu tiên đứng trước câu hỏi: nên bắt đầu với Dockerfile hay Docker Compose? Nhiều đội ngũ phát triển đổi qua lại giữa hai công cụ này mà chưa có tiêu chí rõ ràng, dẫn đến cấu hình rối rắm, môi trường chạy kém ổn định, hoặc chi phí vận hành bị đội lên. Sự thật là: Dockerfile và Docker Compose không cạnh tranh, mà bổ trợ lẫn nhau. Vấn đề không phải "cái nào tốt hơn", mà là "dùng cái gì cho đúng lúc, đúng chỗ".

Bài viết này giúp bạn nhìn bức tranh tổng thể, so sánh sâu theo tiêu chí ra quyết định, kèm ví dụ thực tế, mẹo tối ưu và những sai lầm thường gặp. Cuối bài, bạn sẽ có một checklist ngắn gọn để chọn công cụ phù hợp cho từng tình huống.

Bức tranh tổng quan: Dockerfile vs Docker Compose

• Dockerfile: là công thức dựng image. Nó mô tả cách đóng gói ứng dụng của bạn thành một image bất biến: dùng base image nào, copy mã nguồn, cài phụ thuộc, build, expose port, thiết lập user, entrypoint, v.v. Kết quả là một image có thể chạy được ở bất cứ đâu có Docker Engine.
• Docker Compose: là công cụ khai báo và vận hành nhiều container như một stack. File docker-compose.yml (hoặc compose.yaml) định nghĩa các service (mỗi service là một container), mạng (networks), volume dữ liệu, biến môi trường, phụ thuộc giữa các service, chính sách restart, giới hạn tài nguyên, profiles môi trường, v.v.

Điểm mấu chốt:

• Dockerfile trả lời câu hỏi: "Làm thế nào để build ra một image chuẩn?"
• Docker Compose trả lời câu hỏi: "Triển khai một ứng dụng bao gồm nhiều container như thế nào?"

Chúng không loại trừ nhau. Trên thực tế:

• Compose thường "gọi" Dockerfile để build các service tùy chỉnh.
• Bạn có thể chạy một image mà không cần Compose (chỉ với docker run) nếu ứng dụng đơn lẻ.

Khi nào chỉ cần Dockerfile?

Chọn Dockerfile và bỏ qua Compose khi:

• Ứng dụng đơn giản, chạy đơn lẻ (CLI tool, service không có phụ thuộc ngoài, static site serve bằng Nginx, cron-job container).
• Bạn chỉ cần một image để publish lên registry và cho bên khác kéo về chạy.
• Mục đích là chuẩn hóa build và tối ưu kích thước/tốc độ build, chứ không phải điều phối nhiều container.
• Môi trường đích đã có sẵn hạ tầng điều phối khác (Kubernetes, ECS) và Dockerfile là đầu vào duy nhất.

Một Dockerfile tốt nên hướng tới: tái lập, nhỏ gọn, an toàn. Ví dụ: multi-stage build cho một API Go tối ưu kích thước, không cần Compose nếu nó dùng SQLite hoặc một dịch vụ bên ngoài đã có sẵn:

# syntax=docker/dockerfile:1.6
FROM golang:1.22 AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -o app ./cmd/api

FROM gcr.io/distroless/base-debian12
WORKDIR /app
COPY --from=build /src/app /app/app
USER nonroot
EXPOSE 8080
ENTRYPOINT ./app

Ưu điểm khi chỉ dùng Dockerfile:

• Tối giản: ít file, ít khái niệm.
• Build cache dễ kiểm soát, CI/CD đơn giản.
• Xuất bản image dùng ở nhiều nơi (K8s, serverless container) mà không phụ thuộc Compose.

Nhược điểm:

• Không giải quyết được dàn dựng phụ trợ (database, cache, message broker) cho local/dev/test.
• Khó chia sẻ quy trình khởi chạy môi trường đầy đủ cho cả đội.

Khi nào nên dùng Docker Compose?

Chọn Compose khi bạn cần một môi trường gồm nhiều thành phần phối hợp:

• Ứng dụng web + database + cache + message queue.
• Local development cần parity cao với staging/production.
• Tự động hóa môi trường test tích hợp (integration test) trong CI.
• Chạy các dịch vụ phụ trợ tạm thời (local-only) mà không muốn cài trực tiếp lên máy dev.

Compose mạnh ở các điểm:

• Khai báo nhiều service, network, volume trong một file dễ đọc.
• Định nghĩa biến môi trường, mount nguồn mã để hot-reload.
• Bật/tắt thành phần theo profiles (dev/test/prod) mà không sửa file chính.
• Quản lý vòng đời gọn: docker compose up -d để khởi chạy, docker compose down -v để dọn sạch cả network và volume nếu muốn.

Ví dụ một file Compose đơn giản cho web + PostgreSQL:

services:
  web:
    build: .
    ports:
      - 8080:8080
    environment:
      - DATABASE_URL=postgres://app:app@db:5432/app?sslmode=disable
    depends_on:
      - db

  db:
    image: postgres:16
    environment:
      - POSTGRES_USER=app
      - POSTGRES_PASSWORD=app
      - POSTGRES_DB=app
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:

Lưu ý: depends_on chỉ đảm bảo thứ tự khởi động, không đảm bảo "ứng dụng đã sẵn sàng". Dùng healthcheck và/hoặc script chờ (wait-for) nếu cần độ tin cậy cao.

Minh họa thực tế: API Go + Postgres trong 5 phút

Giả sử bạn có API Go cần Postgres. Chúng ta sẽ:

1. Viết Dockerfile tối ưu.
2. Viết Compose cho 2 service: api và db.
3. Thêm healthcheck và script chờ để tránh lỗi kết nối sớm.

Dockerfile (multi-stage, non-root, cache tốt):

# syntax=docker/dockerfile:1.6
FROM golang:1.22 AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -ldflags='-s -w' -o app ./cmd/api

FROM gcr.io/distroless/static-debian12
WORKDIR /app
COPY --from=build /src/app /app/app
USER nonroot
EXPOSE 8080
ENTRYPOINT ./app

File compose.yaml:

services:
  api:
    build:
      context: .
    environment:
      - DATABASE_URL=postgres://app:app@db:5432/app?sslmode=disable
    ports:
      - 8080:8080
    depends_on:
      - db
    healthcheck:
      test: ['CMD-SHELL', 'wget -qO- http://localhost:8080/health || exit 1']
      interval: 5s
      timeout: 2s
      retries: 10
      start_period: 10s

  db:
    image: postgres:16
    environment:
      - POSTGRES_USER=app
      - POSTGRES_PASSWORD=app
      - POSTGRES_DB=app
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ['CMD-SHELL', 'pg_isready -U app']
      interval: 5s
      timeout: 3s
      retries: 10
      start_period: 10s

volumes:
  pgdata:

Nếu API cần chờ DB sẵn sàng, thay vì trông cậy hoàn toàn vào depends_on, bạn có thể thêm một tiny init/wait:

#!/usr/bin/env sh
set -eu
until nc -z db 5432; do
  echo 'Waiting for Postgres...'
  sleep 1
done
exec ./app

Đóng gói script này vào image và ENTRYPOINT ./wait-and-run.sh để đảm bảo API chỉ chạy khi DB lắng nghe cổng 5432.

Chạy:

• docker compose up -d --build để build và khởi động.
• docker compose logs -f để theo dõi.
• docker compose down -v để dọn sạch cả volume (nếu muốn reset dữ liệu).

So sánh theo tiêu chí ra quyết định

• Mức độ phức tạp:
  • Dockerfile: tối giản, một chiều (build -> run).
  • Compose: thêm lớp orchestrate, phù hợp khi có từ 2 service trở lên.
• Tính tái lập:
  • Dockerfile: tái lập build, sản phẩm là image bất biến.
  • Compose: tái lập cả môi trường (network, volume, env), giảm "it works on my machine".
• Tốc độ phát triển:
  • Dockerfile: build cache tốt nếu sắp xếp lệnh hợp lý; chạy đơn lẻ nhanh.
  • Compose: bật/tắt toàn bộ stack trong một lệnh; docker compose build --parallel tận dụng BuildKit.
• Khả năng mở rộng:
  • Dockerfile: không bàn về scale.
  • Compose: có --scale cho service, nhưng không phải orchestrator phân tán; production ở quy mô lớn nên dùng K8s/ECS/Swarm.
• Tính di động:
  • Dockerfile: di động cao; image chạy được ở nhiều nền tảng.
  • Compose: tốt cho local/dev/test, có thể deploy prod ở quy mô nhỏ-vừa; chuyển sang K8s dùng kompose để chuyển đổi sơ khởi.
• Bảo mật:
  • Dockerfile: có thể dùng BuildKit secrets (RUN --mount=type=secret), chạy non-root, minimize surface.
  • Compose: quản lý biến môi trường qua env_file, gắn secrets (tích hợp Swarm) hoặc BuildKit secrets trong phần build; cô lập network.
• Chi phí vận hành:
  • Dockerfile: nhẹ, ít công cụ.
  • Compose: chuẩn hóa quy trình local/dev/test, giảm thời gian onboard và lỗi do lệch môi trường.

Kết luận theo tiêu chí: nếu bạn chỉ cần một image tốt, Dockerfile là trung tâm. Nếu bạn cần một "môi trường chạy" hoàn chỉnh với nhiều dịch vụ, Compose là công cụ bạn muốn.

Các mẫu sử dụng khuyến nghị (patterns)

• Phát triển local:

  • Dùng Compose với bind mount mã nguồn để hot-reload (ví dụ với Node.js, Python). Ví dụ:

    services:
      web:
        build: .
        volumes:
          - .:/app
        command: npm run dev
        ports:
          - 3000:3000
    

  • Sử dụng profiles: ['dev'] cho những service chỉ cần ở môi trường dev (adminer, mailhog, jaeger...).
  • Dùng docker compose up --profile dev khi cần.

• Kiểm thử tích hợp (CI):

  • Spin-up stack tạm thời, chạy test, dọn sạch:

    docker compose -f compose.yaml -f compose.test.yaml up -d --build
    npm test || { code=$?; docker compose down -v; exit $code; }
    docker compose down -v
    

  • Dùng healthcheck và --wait (nếu dùng plugin) hoặc script chờ để đảm bảo service đã sẵn sàng trước khi test.

• Sản xuất quy mô nhỏ-vừa (VM/bare metal):

  • Build image qua Dockerfile trong CI, tag bất biến (ví dụ app:1.4.2, không dùng latest).
  • Deploy bằng Compose với image đã build sẵn; thiết lập restart: unless-stopped và giới hạn tài nguyên deploy.resources.limits (trong Compose spec) hoặc mem_limit.
  • Sao lưu volume (database) định kỳ.

• Monorepo nhiều service:

  • Chia nhỏ file Compose theo thư mục, dùng x- extension fields để tái sử dụng cấu hình.
  • Tạo các profile theo nhóm dịch vụ (core, observability, demo).

Tối ưu Dockerfile: nhẹ, nhanh, an toàn

• Multi-stage build: tách giai đoạn build (nặng) và runtime (nhẹ) để giảm kích thước image và bề mặt tấn công.
• Sắp xếp lệnh để tối đa cache: cài dependency (go mod, npm ci, pip install) trước khi copy toàn bộ mã nguồn.
• .dockerignore: loại bỏ thư mục build, cache, node_modules, .git để không phá cache và giảm context.
• Dùng base image tối giản: distroless, alpine (cân nhắc glibc/musl), hoặc images chuyên biệt.
• Không chạy root:

  RUN adduser -D appuser
  USER appuser
  

• Healthcheck ở image (tuỳ nhu cầu chia sẻ):

  HEALTHCHECK --interval=10s --timeout=2s --retries=5 CMD wget -qO- http://localhost:8080/health || exit 1
  

• BuildKit secrets, tránh bake secrets vào layer:

  # syntax=docker/dockerfile:1.6
  RUN --mount=type=secret,id=npm_token sh -c 'npm config set //registry.npmjs.org/:_authToken=$(cat /run/secrets/npm_token) && npm ci'
  

• Reproducible builds: pin phiên bản base image và dependencies; tránh latest.

Tối ưu Docker Compose: linh hoạt, đáng tin cậy

• Profiles: bật/tắt thành phần theo ngữ cảnh:

  services:
    jaeger:
      image: jaegertracing/all-in-one:1.57
      profiles: ['dev', 'obs']
  

• Nhiều file Compose: compose.yaml + compose.override.yaml (tự động áp dụng) + các file chuyên biệt (compose.prod.yaml). Kết hợp bằng -f theo nhu cầu.
• Healthcheck + wait-for: đừng trông chờ depends_on cho readiness. Xây chiến lược chờ chủ động ở service phụ thuộc.
• Volumes:
  • Dùng named volumes để giữ dữ liệu qua các lần up/down.
  • Dev: mount bind cho source, nhưng tránh mount đè thư mục build nội bộ gây xung đột (ví dụ node_modules). Có thể dùng "delegated" hoặc tách mount có chọn lọc.
• Environment:
  • Dùng env_file: .env để tách cấu hình nhạy cảm khỏi repo (nhưng .env không phải secret vault!).
  • Biến chung để trong .env, biến riêng service đặt tại environment.
• Giới hạn tài nguyên:

  services:
    api:
      deploy:
        resources:
          limits:
            cpus: '1.0'
            memory: 512M
  

  Lưu ý: một số tuỳ chọn deploy có hiệu lực khác nhau trên Docker Engine so với Swarm; kiểm tra phiên bản Compose/Docker bạn dùng.
• Build secrets với Compose:

  services:
    web:
      build:
        context: .
        secrets:
          - npm_token
  secrets:
    npm_token:
      file: .secrets/npm_token
  

  Kết hợp với RUN --mount=type=secret,id=npm_token trong Dockerfile.

Các sai lầm thường gặp và cách tránh

• Tin rằng depends_on bảo đảm readiness: thực ra nó chỉ là thứ tự start. Cách khắc phục: healthcheck và/wait-for.
• Dùng latest ở mọi nơi: dẫn tới build/run không tái lập. Khắc phục: pin phiên bản base image và service phụ trợ (postgres:16.2).
• Quên .dockerignore: làm context to đùng, cache vỡ, build chậm. Khắc phục: thêm các thư mục nặng và không cần thiết vào .dockerignore.
• Chạy root trong container production: tăng rủi ro bảo mật. Khắc phục: tạo user không đặc quyền và USER rõ ràng.
• Trộn dev và prod trong một Compose duy nhất: cấu hình phức tạp, dễ lẫn. Khắc phục: profiles và file override riêng cho môi trường.
• Mount bind đè thư mục build: ví dụ mount toàn bộ repo vào /app trong container Node.js có thể che mất node_modules trong image. Khắc phục: chỉ mount mã nguồn, hoặc sử dụng kỹ thuật two-volume; hoặc cài node_modules trên host qua volumes chuyên biệt.
• Không đặt healthcheck: khó tự động hóa chờ đợi và giám sát. Khắc phục: thêm healthcheck cho service quan trọng.
• Không giới hạn tài nguyên: container có thể ăn hết RAM và bị OOM kill. Khắc phục: đặt giới hạn hợp lý theo môi trường.
• Lạm dụng Compose cho production lớn: thiếu tính năng orchestration phân tán, rolling updates phức tạp. Khắc phục: chuyển sang Kubernetes/ECS/Swarm khi cần.

Quy trình ra quyết định nhanh

• Bước 1: Ứng dụng của bạn có hơn một thành phần chạy cùng lúc không (DB, cache, queue, reverse proxy...)?
  • Không: chỉ cần Dockerfile. Dùng docker run hoặc tích hợp vào hạ tầng có sẵn.
  • Có: dùng Compose để định nghĩa stack. Mỗi thành phần là một service.
• Bước 2: Bạn có cần chia sẻ môi trường dev/test cho cả đội một cách nhất quán không?
  • Có: Compose là lựa chọn mặc định. Check-in compose.yaml vào repo, thêm hướng dẫn 1 lệnh chạy toàn bộ.
• Bước 3: Production của bạn ở quy mô nào?
  • Nhỏ-vừa trên 1- vài VM: Compose vẫn ổn nếu có quy trình chuẩn (image bất biến, healthcheck, backup volume, restart policy).
  • Lớn, nhiều máy: giữ Dockerfile để build image; dùng orchestrator (K8s/ECS). Compose vẫn hữu ích cho dev/staging.
• Bước 4: Mục tiêu tối ưu là gì?
  • Tối ưu kích thước/tốc độ build: tập trung Dockerfile (multi-stage, cache, .dockerignore, BuildKit).
  • Tối ưu tốc độ bật/tắt môi trường: Compose với profiles, file override, healthcheck chuẩn.

Một lưu ý quan trọng: nếu câu trả lời cho Bước 1 là "Có", thường không có lý do chính đáng để né Compose ở dev/test. Compose giảm lỗi thiết lập máy local và rút ngắn thời gian onboard.

Hỏi nhanh đáp gọn (FAQ)

• Dockerfile có thể thay Docker Compose không?

  • Không. Dockerfile đóng gói ứng dụng; Compose điều phối nhiều container. Bạn có thể chỉ dùng Dockerfile nếu ứng dụng đơn lẻ.

• Có thể dùng cả hai cùng lúc?

  • Có. Phổ biến nhất: Compose gọi Dockerfile để build service tùy chỉnh, đồng thời kéo các image phụ trợ (DB, cache) từ registry.

• Compose có phù hợp production không?

  • Cho quy mô nhỏ-vừa, có. Với quy trình chặt chẽ (image bất biến, giám sát, backup, restart policy) Compose hoạt động tốt. Quy mô lớn nên dùng orchestrator.

• Làm sao đảm bảo DB sẵn sàng trước khi app kết nối?

  • Dùng healthcheck ở DB và cơ chế chờ ở app (wait-for). Đừng dựa hoàn toàn vào depends_on.

• Compose có làm build chậm hơn không?

  • Không đáng kể. Compose tận dụng Docker BuildKit, có thể build song song bằng docker compose build --parallel. Tốc độ phụ thuộc chủ yếu vào Dockerfile và cache.

• Khi nào nên tách nhiều file Compose?

  • Khi bạn có nhu cầu kết hợp cấu hình theo bối cảnh (dev/test/prod), hoặc monorepo nhiều nhóm dịch vụ. Dùng -f để merge.

• Có thể chuyển Compose sang Kubernetes?

  • Dùng kompose để chuyển đổi sơ khởi; sau đó tinh chỉnh manifest cho phù hợp thông số K8s.

Chìa khóa để chọn đúng không nằm ở việc tuyên bố một "người thắng cuộc", mà là hiểu đúng vai trò của từng công cụ. Dockerfile giúp bạn đóng gói ứng dụng thành một image chuẩn, tối ưu và an toàn. Docker Compose giúp bạn lắp ghép nhiều container thành một hệ thống vận hành trơn tru, có thể bật/tắt trong một lệnh, và chia sẻ được cho cả đội. Khi kết hợp đúng lúc đúng chỗ, bạn sẽ có vòng đời phát triển mượt mà: build nhanh, môi trường nhất quán, và triển khai đủ linh hoạt cho mọi giai đoạn từ local đến production.