Viết Dockerfile Tốt Hơn: Các Mẹo và Thủ Thuật

Chào mừng bạn đến với chặng tiếp theo trên “Docker Roadmap”! Sau khi đã tìm hiểu Container là gì, sự khác biệt giữa Container, VM và Bare Metal, hiểu rõ về Docker và tiêu chuẩn OCI, cũng như các nền tảng về Linux cơ bản (bao gồm quản lý package, người dùng và quyền hạn, các lệnh shell và shell scripting), chúng ta đã sẵn sàng đi sâu hơn vào trái tim của việc đóng gói ứng dụng với Docker: Dockerfile.

Dockerfile giống như một bản thiết kế, một kịch bản tự động hướng dẫn Docker cách xây dựng image cho ứng dụng của bạn. Viết một Dockerfile cơ bản thì dễ, nhưng viết một Dockerfile tốt – hiệu quả, an toàn, nhỏ gọn và dễ bảo trì – lại là cả một nghệ thuật và đòi hỏi những kỹ thuật nâng cao. Trong bài viết này, chúng ta sẽ cùng khám phá các mẹo và thủ thuật để nâng tầm Dockerfile của bạn, giúp quá trình làm việc với Docker trở nên mượt mà và chuyên nghiệp hơn.

Tại Sao Việc Tối Ưu Hóa Dockerfile Lại Quan Trọng?

Bạn có thể tự hỏi, “Chỉ cần chạy được ứng dụng trong container là đủ rồi, sao phải phức tạp hóa lên?”. Đúng, một Dockerfile đơn giản có thể giúp ứng dụng của bạn chạy được. Nhưng một Dockerfile được tối ưu hóa mang lại những lợi ích to lớn, đặc biệt trong môi trường sản xuất và khi làm việc nhóm:

• Kích thước ảnh nhỏ hơn: Ảnh (image) nhỏ hơn giúp đẩy/kéo (push/pull) nhanh hơn, tiết kiệm không gian lưu trữ, giảm chi phí bandwidth, và quan trọng nhất, giảm bề mặt tấn công (attack surface) tiềm tàng.
• Thời gian build nhanh hơn: Tối ưu hóa cách sử dụng cache của Docker giúp quá trình build lặp đi lặp lại diễn ra chớp nhoáng.
• Bảo mật cải thiện: Giảm thiểu số lượng gói (package) không cần thiết, chạy ứng dụng với người dùng không phải root là những biện pháp bảo mật cơ bản nhưng cực kỳ hiệu quả.
• Dễ bảo trì và mở rộng: Một Dockerfile rõ ràng, cấu trúc tốt sẽ giúp đồng nghiệp (hoặc chính bạn trong tương lai) dễ dàng hiểu, debug và sửa đổi.
• Hiệu suất tốt hơn: Tránh các cấu hình không cần thiết có thể ảnh hưởng đến hiệu suất của container.

Với những lợi ích này, việc đầu tư thời gian tìm hiểu và áp dụng các thực hành tốt nhất khi viết Dockerfile là hoàn toàn xứng đáng.

Các Lệnh Cơ Bản Cần Nắm Vững và Thực Hành Tốt Nhất

Hãy bắt đầu với việc xem xét lại một số lệnh Dockerfile phổ biến và cách sử dụng chúng một cách hiệu quả.

FROM: Nền Tảng Của Mọi Thứ

Lệnh FROM định nghĩa image cơ sở mà image của bạn sẽ được xây dựng dựa trên đó. Đây là lựa chọn quan trọng đầu tiên.

• Chọn image cơ sở tối thiểu: Thay vì sử dụng các image lớn như ubuntu hay debian đầy đủ, hãy cân nhắc các phiên bản “slim” hoặc các image siêu nhỏ như alpine. alpine dựa trên musl libc và BusyBox, rất nhẹ. Ví dụ: FROM alpine:3.18 thay vì FROM ubuntu:22.04. Điều này giúp giảm đáng kể kích thước ảnh cuối cùng. Tuy nhiên, hãy kiểm tra tính tương thích của các thư viện và công cụ bạn cần với image cơ sở tối thiểu.
• Sử dụng tag cụ thể: Luôn chỉ định tag phiên bản (ví dụ: python:3.9-slim, node:16-alpine) thay vì latest. Điều này đảm bảo tính lặp lại (reproducibility) cho bản build của bạn. Bạn có thể tham khảo thêm về việc sử dụng các image bên thứ ba an toàn.

# Nên làm:
FROM python:3.9-slim

# Tránh làm (trừ khi có lý do đặc biệt):
FROM ubuntu
FROM node:latest

RUN: Thực Thi Lệnh Trong Image

Lệnh RUN thực thi một lệnh trong một layer mới của image. Mỗi lệnh RUN sẽ tạo ra một layer mới, và số lượng layer ảnh hưởng đến kích thước ảnh và hiệu quả sử dụng cache.

• Kết hợp các lệnh RUN: Đây là một trong những mẹo quan trọng nhất để giảm số lượng layer và tận dụng cache hiệu quả. Thay vì viết nhiều lệnh RUN riêng lẻ để cài đặt các gói hoặc thực hiện các tác vụ liên quan, hãy kết hợp chúng thành một lệnh RUN duy nhất bằng cách sử dụng ký tự && và đặt mỗi lệnh con trên một dòng mới bằng ký tự \ để dễ đọc.

Ví dụ (Nên làm):

FROM ubuntu:22.04

RUN apt-get update && \
    apt-get install -y --no-install-recommends \
    curl \
    wget \
    git && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/*

So sánh với (Không nên làm):

FROM ubuntu:22.04

RUN apt-get update
RUN apt-get install -y curl
RUN apt-get install -y wget
RUN apt-get install -y git
RUN apt-get clean
RUN rm -rf /var/lib/apt/lists/*

Phiên bản “Nên làm” chỉ tạo ra 1 layer, trong khi phiên bản “Không nên làm” tạo ra 6 layer. Ít layer hơn thường dẫn đến ảnh nhỏ hơn.

• Dọn dẹp sau khi cài đặt: Ngay trong cùng một lệnh RUN cài đặt gói, hãy dọn dẹp các file cache không cần thiết. Ví dụ với APT, thêm apt-get clean && rm -rf /var/lib/apt/lists/* giúp thu nhỏ kích thước layer đó. Tương tự với các trình quản lý gói khác như YUM/DNF (link đến bài Package Managers 101).
• Sử dụng dạng exec cho lệnh RUN (ít phổ biến): Dạng RUN ["executable", "param1", "param2"] tránh các vấn đề với shell process, nhưng dạng shell RUN command param1 param2 (mặc định chạy với /bin/sh -c trên Linux) thường được dùng hơn khi cần kết hợp nhiều lệnh, pipe, hoặc sử dụng các tính năng của shell.

Việc hiểu về các lệnh shell và shell scripting là rất hữu ích khi làm việc với lệnh RUN.

COPY và ADD: Đưa File Vào Image

Cả hai lệnh này đều sao chép file/thư mục từ host vào image. Tuy nhiên, có sự khác biệt quan trọng.

• Ưu tiên COPY: Lệnh COPY đơn giản, rõ ràng và được khuyến khích sử dụng hơn. Nó chỉ sao chép file hoặc thư mục từ một vị trí cụ thể trên host (trong build context) đến một đích trong image.
• Sử dụng ADD khi cần giải nén: Lệnh ADD có thêm hai tính năng: tự động giải nén file nén (như tar, gzip, bzip2) và hỗ trợ sao chép file từ URL. Tuy nhiên, tính năng tự động giải nén có thể gây khó đoán, và sao chép từ URL không được khuyến khích vì nó tạo ra một layer mới mỗi lần URL thay đổi (hoặc nội dung thay đổi) và khó kiểm soát nguồn gốc file. Chỉ dùng ADD khi bạn thực sự cần giải nén một file nén cục bộ vào image.

Ví dụ:

# Nên dùng (đơn giản, rõ ràng):
COPY ./app /app

# Nên dùng (khi cần giải nén file nén cục bộ):
ADD ./app.tar.gz /app

# Tránh dùng (khi chỉ cần sao chép):
ADD ./app /app

# Tránh dùng (không kiểm soát được nguồn gốc và cache):
ADD https://example.com/archive.tar.gz /tmp/

• Build Context: Cần hiểu về build context – thư mục chứa Dockerfile và các file bạn muốn đưa vào image. Chỉ những file/thư mục trong context mới có thể được COPY hoặc ADD.
• Sử dụng .dockerignore: Tương tự như .gitignore, tệp .dockerignore liệt kê các file và thư mục mà Docker client nên bỏ qua khi gửi build context đến Docker daemon. Điều này giúp giảm kích thước context, tăng tốc độ build và tránh đưa các file nhạy cảm (như mật khẩu, file tạm) hoặc không cần thiết (như thư mục node_modules nếu bạn cài đặt nó trong Dockerfile, thư mục .git, file log…) vào build context.

Ví dụ tệp .dockerignore:

.git
.gitignore
node_modules
npm-debug.log
Dockerfile
README.md

WORKDIR: Thiết Lập Thư Mục Làm Việc

Lệnh WORKDIR thiết lập thư mục làm việc hiện tại cho các lệnh RUN, CMD, ENTRYPOINT, COPY và ADD tiếp theo. Sử dụng WORKDIR giúp Dockerfile của bạn rõ ràng hơn và tránh lặp lại việc chỉ định đường dẫn đầy đủ.

Ví dụ:

WORKDIR /app
COPY ./package.json ./
RUN npm install
COPY ./src ./src
CMD ["npm", "start"]

Thay vì:

COPY ./package.json /app/package.json
RUN cd /app && npm install
COPY ./src /app/src
CMD ["/app/node_modules/.bin/npm", "start"] # Hoặc phải đặt WORKDIR trước CMD

CMD và ENTRYPOINT: Định Nghĩa Lệnh Khi Container Chạy

Đây là hai lệnh dùng để chỉ định lệnh sẽ được thực thi khi container khởi động từ image. Sự khác biệt giữa chúng rất quan trọng.

• CMD: Lệnh mặc định – Cung cấp lệnh mặc định cho container đang chạy. Lệnh này có thể bị ghi đè bởi đối số dòng lệnh khi chạy docker run. Một Dockerfile chỉ nên có một lệnh CMD.
• ENTRYPOINT: Lệnh thực thi – Cung cấp một lệnh thực thi cho container. Đối số được truyền cho docker run sẽ được nối vào cuối lệnh ENTRYPOINT. Sử dụng ENTRYPOINT khi bạn muốn container chạy như một executable.
• Kết hợp ENTRYPOINT và CMD: Đây là mô hình phổ biến. ENTRYPOINT được đặt là executable chính, còn CMD cung cấp các tham số mặc định cho executable đó.

Ví dụ (ENTRYPOINT + CMD):

# Container chạy như một executable (ví dụ: `docker run my-image --help`)
ENTRYPOINT ["/app/my-app"]
CMD ["--help"]

Với cấu hình này, khi chạy docker run my-image, lệnh thực tế là /app/my-app --help. Khi chạy docker run my-image --config /etc/config.yaml, lệnh thực tế là /app/my-app --config /etc/config.yaml.

• Sử dụng dạng Exec (Exec form): Đối với cả CMD và ENTRYPOINT, khuyến khích sử dụng dạng Exec (["executable", "param1", "param2"]) thay vì dạng Shell (command param1 param2). Dạng Exec không chạy lệnh qua một shell process (/bin/sh -c), giúp tránh các tín hiệu bất ngờ (như SIGTERM) bị xử lý sai bởi shell phụ và đảm bảo process chính của ứng dụng là process PID 1 trong container, nhận tín hiệu trực tiếp từ Docker.

EXPOSE: Tài Liệu Hóa Cổng

Lệnh EXPOSE thông báo rằng container lắng nghe trên các cổng mạng được chỉ định. Lệnh này chỉ mang tính tài liệu, không thực sự publish cổng. Việc publish cổng được thực hiện khi chạy container với tùy chọn -p hoặc --publish của lệnh docker run.

Ví dụ:

EXPOSE 80 443

Giúp người dùng image của bạn biết cần publish cổng nào.

ENV và ARG: Biến Môi Trường và Biến Build-time

• ENV: Biến môi trường – Đặt biến môi trường trong image. Các biến này tồn tại khi container chạy.
• ARG: Biến build-time – Định nghĩa các biến chỉ có sẵn trong quá trình build Docker image. Chúng không tồn tại trong image cuối cùng. ARG thường được dùng để truyền thông tin nhạy cảm (tạm thời) hoặc cấu hình build (như phiên bản phần mềm, địa chỉ repository).

Ví dụ:

ARG APP_VERSION=1.0.0
ENV VERSION=${APP_VERSION}
ENV NODE_ENV=production

Bạn có thể truyền giá trị cho ARG khi build bằng docker build --build-arg APP_VERSION=1.2.0 ..

USER: Chạy Với User Không Phải Root

Theo mặc định, các lệnh RUN và container chạy với user root. Đây là một rủi ro bảo mật lớn. Luôn tạo một user không phải root và chuyển sang user đó bằng lệnh USER trước khi chạy ứng dụng.

Bạn có thể tham khảo lại bài viết về Người Dùng, Nhóm và Quyền Hạn trong Linux để hiểu rõ hơn.

Ví dụ:

# Tạo một nhóm và người dùng mới
RUN groupadd --gid 1000 appuser && useradd --uid 1000 --gid appuser --shell /bin/bash --create-home appuser

# Đặt quyền sở hữu cho thư mục ứng dụng
RUN chown -R appuser:appuser /app

# Chuyển sang user mới trước khi chạy ứng dụng
USER appuser

WORKDIR /app
COPY --chown=appuser:appuser ./app /app
CMD ["/app/my-app"]

VOLUME: Khối Lượng Dữ Liệu

Lệnh VOLUME chỉ định một mount point trong image, đánh dấu thư mục đó là nơi chứa dữ liệu có thể thay đổi hoặc dữ liệu bền vững. Nó giống như một tài liệu hướng dẫn rằng thư mục này nên được mount từ bên ngoài (thường là Docker Volume hoặc bind mount) khi chạy container. Điều này rất quan trọng cho việc lưu trữ dữ liệu bền vững và hiểu rõ về Volume và Bind Mounts.

Ví dụ:

VOLUME /app/data

Các Kỹ Thuật Nâng Cao Để Viết Dockerfile Hiệu Quả

Ngoài việc sử dụng đúng các lệnh cơ bản, có những kỹ thuật nâng cao giúp Dockerfile của bạn vượt trội.

Build Đa Tầng (Multi-stage Builds)

Đây là một trong những kỹ thuật mạnh mẽ nhất để tạo ra các image nhỏ gọn. Multi-stage build cho phép bạn sử dụng nhiều lệnh FROM trong một Dockerfile. Mỗi lệnh FROM có thể sử dụng một image cơ sở khác nhau và bắt đầu một “stage” build mới. Quan trọng là bạn có thể sao chép các artifacts (file thực thi, thư viện, v.v.) từ một stage trước đó sang stage hiện tại.

Ưu điểm: Tách biệt môi trường build (với tất cả các công cụ, SDK, dependencies cần thiết) và môi trường runtime (chỉ cần những gì để chạy ứng dụng). Kết quả là image cuối cùng chỉ chứa ứng dụng và các dependency cần thiết, không chứa các công cụ build hoặc mã nguồn đầy đủ, giúp giảm đáng kể kích thước và tăng bảo mật.

Ví dụ Multi-stage Build cho ứng dụng Go:

# Stage 1: Build code
FROM golang:1.20 AS builder

WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o /app/my-app ./cmd/api/main.go

# Stage 2: Run application
FROM alpine:3.18

WORKDIR /app

# Sao chép file thực thi từ stage builder
COPY --from=builder /app/my-app .

# Chạy với user không phải root (tạo user nếu cần, hoặc dùng user có sẵn trong alpine)
RUN adduser -D appuser
USER appuser

CMD ["./my-app"]

Trong ví dụ này, image cuối cùng chỉ dựa trên alpine:3.18 và chỉ chứa file thực thi my-app, rất nhỏ gọn so với việc build và chạy trong cùng một image golang:1.20.

Kỹ thuật này có thể áp dụng cho hầu hết các ngôn ngữ cần compile hoặc có nhiều dependency chỉ dùng khi build (Node.js với devDependencies, Java với Maven/Gradle, v.v.). Bạn có thể xem xét lại cách chọn ngôn ngữ lập trình và kiến trúc ứng dụng để thấy multi-stage build phù hợp như thế nào.

Tận Dụng Bộ Nhớ Cache Khi Build

Docker build xử lý Dockerfile từng lệnh một. Đối với mỗi lệnh, Docker kiểm tra xem có layer nào trong cache khớp với lệnh đó hay không. Nếu có, Docker sử dụng layer cache đó thay vì chạy lại lệnh, giúp quá trình build nhanh hơn.

Quy tắc là: nếu một lệnh khớp với cache, Docker sẽ sử dụng layer cache đó VÀ tất cả các lệnh tiếp theo cũng sẽ sử dụng cache (nếu khớp) cho đến khi gặp một lệnh KHÔNG khớp với cache. Từ lệnh không khớp đó trở đi, Docker sẽ phải chạy lại lệnh đó và tất cả các lệnh sau đó.

Để tối ưu hóa cache, hãy đặt các lệnh ít thay đổi ở phía trên Dockerfile (ví dụ: cài đặt các gói hệ thống, sao chép các file cấu hình tĩnh) và các lệnh thay đổi thường xuyên (ví dụ: sao chép mã nguồn ứng dụng) ở phía dưới.

Ví dụ (Tận dụng Cache):

FROM node:16-alpine

WORKDIR /app

# Các file dependency (package.json, package-lock.json) ít thay đổi hơn mã nguồn
# Sao chép và cài đặt dependency trước để tận dụng cache layer này
COPY package.json package-lock.json ./
RUN npm install --production # Cài đặt chỉ các dependency cần thiết cho runtime

# Sao chép toàn bộ mã nguồn ứng dụng (thường xuyên thay đổi) sau
COPY . .

CMD ["npm", "start"]

Nếu chỉ thay đổi mã nguồn trong thư mục ./src, Docker sẽ sử dụng cache cho các lệnh FROM, WORKDIR, COPY package.json... và RUN npm install.... Chỉ lệnh COPY . . và CMD cần chạy lại. Nếu bạn sao chép toàn bộ mã nguồn trước khi cài đặt dependency, mỗi lần thay đổi mã nguồn sẽ làm cache của lệnh COPY . . bị invalidate, buộc Docker phải chạy lại cả lệnh RUN npm install, tốn nhiều thời gian hơn.

Thực Hành Bảo Mật Tốt Nhất

Bảo mật là yếu tố không thể thiếu khi làm việc với Docker.

• Chạy với user không phải root: Như đã đề cập ở trên với lệnh USER. Đây là biện pháp cơ bản nhất.
• Chỉ cài đặt những gì cần thiết: Mỗi gói bổ sung là một nguy cơ tiềm tàng và làm tăng kích thước ảnh. Sử dụng tùy chọn --no-install-recommends với APT hoặc các cờ tương tự với các trình quản lý gói khác để tránh cài đặt các gói không cần thiết.
• Sử dụng các phiên bản cụ thể: Chỉ định phiên bản cụ thể cho các gói bạn cài đặt (ví dụ: apt-get install -y nginx=1.20.1).
• Không lưu trữ bí mật (secrets) trong Dockerfile: Tránh hardcode mật khẩu, khóa API, v.v. Sử dụng biến môi trường được truyền khi chạy container (cẩn thận với log), hoặc tốt hơn là sử dụng các giải pháp quản lý bí mật của orchestration system (Docker Swarm Secrets, Kubernetes Secrets). Tránh truyền bí mật qua ARG nếu không cần thiết, vì giá trị của ARG có thể hiển thị trong build history.
• Quét lỗ hổng bảo mật: Sử dụng các công cụ quét lỗ hổng cho Docker image (ví dụ: Trivy, Clair, Snyk) như một phần của pipeline CI/CD.

Cấu Trúc Thư Mục Dự Án cho Docker

Cách bạn cấu trúc dự án trên host cũng ảnh hưởng đến Dockerfile, đặc biệt là với lệnh COPY và build context. Thông thường, Dockerfile được đặt ở thư mục gốc của dự án. Các file/thư mục cần thiết cho image nên được tổ chức gần Dockerfile để dễ dàng sao chép vào image.

Tổng Kết: Các Mẹo Nhanh Để Nâng Tầm Dockerfile

Để dễ dàng tham khảo, đây là bảng tổng hợp các mẹo quan trọng nhất:

Kết Luận và Bước Tiếp Theo

Viết Dockerfile không chỉ là liệt kê các lệnh cần thiết mà còn là quá trình tối ưu hóa để tạo ra những image hiệu quả, an toàn và dễ quản lý. Bằng cách áp dụng các mẹo và kỹ thuật nâng cao như sử dụng base image tối thiểu, kết hợp lệnh RUN, tận dụng cache build, đặc biệt là kỹ thuật multi-stage build và đảm bảo chạy container với user không phải root, bạn sẽ tạo ra những image Docker chất lượng cao hơn nhiều.

Những kiến thức này là nền tảng vững chắc khi bạn tiến xa hơn trên “Docker Roadmap”. Chúng ta đã tìm hiểu cách “đóng gói” ứng dụng một cách chuyên nghiệp. Bước tiếp theo sẽ là làm thế nào để các container này có thể “giao tiếp” với nhau và với thế giới bên ngoài thông qua mạng. Chúng ta sẽ đi sâu vào chủ đề mạng trong Docker trong bài viết tiếp theo.

Chúc bạn thực hành thành công và hẹn gặp lại trong các bài viết tiếp theo của serie!