Docker Build Args: Hướng dẫn toàn diện dành cho Chuyên gia Dữ liệu

Hệ quả bảo mật và Biện pháp giảm thiểu rủi ro

Mặc dù build arguments mang lại sự linh hoạt, chúng cũng tiềm ẩn rủi ro bảo mật mà bạn cần hiểu rõ để giữ image Docker an toàn.

Các hướng rò rỉ tham số

Build arguments không riêng tư như bạn nghĩ. Giá trị của build args có thể rò rỉ qua nhiều kênh mà nhiều lập trình viên bỏ qua. Đầu tiên, lịch sử image Docker hiển thị tất cả build args của bạn, nghĩa là bất kỳ ai có quyền truy cập image đều có thể chạy docker history để xem các giá trị dùng lúc build, bao gồm thông tin nhạy cảm như API key hoặc token.

docker history flaskapp:devĐược hỗ trợ bởi

Hình 4 - Docker history

Các layer trung gian cũng có thể làm rò rỉ build args. Ngay cả khi bạn dùng build đa giai đoạn và không copy layer chứa thông tin nhạy cảm, giá trị build arg vẫn tồn tại trong bộ nhớ đệm layer trên máy build. Điều này có nghĩa bất kỳ ai có quyền truy cập Docker daemon trên máy chủ build đều có thể trích xuất thông tin này.

Log của CI/CD cũng là một rủi ro đáng kể khác. Hầu hết hệ thống CI/CD ghi lại toàn bộ lệnh build, bao gồm mọi build arg truyền trên dòng lệnh.

Ví dụ, toàn bộ lệnh này, bao gồm API_KEY, sẽ hiển thị trong log CI/CD:

docker build --build-arg API_KEY=secret123 -t myapp:latest .Được hỗ trợ bởi

Các log này thường được truy cập bởi nhiều lập trình viên hơn hoặc thậm chí lưu trữ trên hệ thống bên thứ ba, làm tăng bề mặt phơi lộ của các giá trị nhạy cảm.

Các lựa chọn thay thế an toàn

Với thông tin nhạy cảm, bạn nên dùng tính năng secrets của Docker BuildKit thay vì build args. BuildKit cho phép bạn mount secrets trong quá trình build mà không lưu chúng trong image cuối cùng hoặc lịch sử.

Dưới đây là ví dụ Dockerfile sử dụng secrets của Docker BuildKit:

FROM python:3.13-slim

WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .

# Use secret mount instead of build arg
RUN --mount=type=secret,id=api_key \
    cat /run/secrets/api_key > api_key.txt

EXPOSE 5000
CMD ["python", "app.py"]Được hỗ trợ bởi

Để build image này với secret, trước tiên tạo tệp api_key.txt:

echo "my-secret-api-key" > api_key.txtĐược hỗ trợ bởi

Sau đó build image kèm secret:

DOCKER_BUILDKIT=1 docker build \
  --secret id=api_key,src=api_key.txt \
  -t flaskapp:secure .Được hỗ trợ bởi

Hình 5 - Build image với BuildKit secrets

Với cấu hình cần có khi runtime, biến môi trường vẫn là cách tiếp cận ưu tiên. Chúng có thể được đặt khi khởi chạy container mà không bị nhúng vào image:

# Set environment variables at runtime
docker run -e API_KEY=secret123 -p 5000:5000 flaskapp:latestĐược hỗ trợ bởi

Để xử lý an toàn cấu hình nhạy cảm trong sản xuất, hãy cân nhắc dùng các nền tảng điều phối container như Kubernetes, nền tảng này cung cấp phương thức bảo mật như Secrets để quản lý thông tin nhạy cảm. Docker Swarm cũng có khả năng tương tự với quản lý secrets.

> Docker không phải nền tảng container duy nhất. Đọc về Podman để xem công cụ nào phù hợp hơn với bạn.

Hãy nhớ nguyên tắc: dùng build args cho cấu hình lúc build không nhạy cảm, dùng BuildKit secrets cho nhu cầu nhạy cảm lúc build, và dùng biến môi trường hoặc secrets của nền tảng điều phối cho cấu hình lúc runtime.

Tích hợp với Hệ sinh thái Container

Giờ khi đã nắm vững cơ bản, hãy khám phá cách tận dụng build arguments trong hệ sinh thái Docker rộng hơn và các công cụ build hiện đại.

Docker Compose

Docker Compose giúp bạn dễ dàng định nghĩa và chia sẻ build arguments trên các ứng dụng đa container.

Nếu muốn thực hành theo, dưới đây là cấu trúc dự án hoàn chỉnh cho hai dịch vụ Flask đơn giản:

flask-project/
├── docker-compose.yml         # Main compose configuration
├── .env                       # Environment variables for compose
├── web/
│   ├── Dockerfile             # Web service Dockerfile
│   ├── app.py                 # Flask application
│   └── requirements.txt       # Python dependencies
├── api/
│   ├── Dockerfile             # API service Dockerfile
│   ├── app.py                 # API Flask application  
│   └── requirements.txt       # API dependenciesĐược hỗ trợ bởi

Tôi sẽ lướt nhanh nội dung từng tệp:

web/app.py

from flask import Flask, render_template

app = Flask(__name__)


@app.route("/")
def index():
    return render_template("index.html", title="Flask Web App")


@app.route("/about")
def about():
    return "About page - Web Service"


if __name__ == "__main__":
    app.run(host="0.0.0.0", port=5000, debug=True)Được hỗ trợ bởi

web/requirements.txt

flask==3.1.0Được hỗ trợ bởi

web/Dockerfile

# Web service Dockerfile
ARG PYTHON_VERSION=3.13

FROM python:${PYTHON_VERSION}-slim

# Redeclare the build arg to use it after FROM
ARG PYTHON_VERSION
ARG ENVIRONMENT=production

# Set environment variables
ENV PYTHONDONTWRITEBYTECODE=1
ENV PYTHONUNBUFFERED=1
ENV FLASK_ENV=${ENVIRONMENT}

WORKDIR /app

# Copy and install requirements
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Copy application code
COPY . .

# Create a simple template folder and file if not exists
RUN mkdir -p templates && \
    echo "<html><body><h1>Hello from Web Service</h1><p>Python version: ${PYTHON_VERSION}</p><p>Environment: ${ENVIRONMENT}</p></body></html>" > templates/index.html

EXPOSE 5000

CMD ["python", "app.py"]Được hỗ trợ bởi

api/app.py

from flask import Flask, jsonify

app = Flask(__name__)


@app.route("/api/health")
def health():
    return jsonify({"status": "healthy"})


@app.route("/api/data")
def get_data():
    return jsonify(
        {"message": "Hello from the API service", "items": ["item1", "item2", "item3"]}
    )


if __name__ == "__main__":
    app.run(host="0.0.0.0", port=8000, debug=True)Được hỗ trợ bởi

api/requirements.txt

flask==3.1.0Được hỗ trợ bởi

api/Dockerfile

ARG PYTHON_VERSION=3.13

FROM python:${PYTHON_VERSION}-slim

# Redeclare the build arg to use it after FROM
ARG PYTHON_VERSION
ARG ENVIRONMENT=production

# Set environment variables
ENV PYTHONDONTWRITEBYTECODE=1
ENV PYTHONUNBUFFERED=1
ENV FLASK_ENV=${ENVIRONMENT}

WORKDIR /app

# Copy and install requirements
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Copy application code
COPY . .

# Add metadata label based on build args
LABEL python.version="${PYTHON_VERSION}" \
      app.environment="${ENVIRONMENT}"

EXPOSE 8000

CMD ["python", "app.py"]Được hỗ trợ bởi

.env

PYTHON_VERSION=3.10
ENVIRONMENT=developmentĐược hỗ trợ bởi

docker-compose.yml

services:
  web:
    build:
      context: ./web
      dockerfile: Dockerfile
      args:
        PYTHON_VERSION: ${PYTHON_VERSION:-3.13}
        ENVIRONMENT: ${ENVIRONMENT:-development}
    ports:
      - "5000:5000"
    depends_on:
      - api
    
  api:
    build:
      context: ./api
      dockerfile: Dockerfile
      args:
        PYTHON_VERSION: ${PYTHON_VERSION:-3.13}
        ENVIRONMENT: ${ENVIRONMENT:-production}
    ports:
      - "8000:8000"Được hỗ trợ bởi

Tóm lại, đây là cách rất đơn giản để khởi chạy hai ứng dụng trong các môi trường cách ly, đồng thời, với một bộ build args cụ thể.

Bạn có thể dùng lệnh này để chạy thiết lập đa container:

docker compose up --buildĐược hỗ trợ bởi

Hình 6 - Build args với Docker Compose

Sau vài giây, bạn sẽ thấy cả hai dịch vụ đều đang chạy:

Hình 7 - Build args với Docker Compose (2)

Thiết lập trên khá dài dòng với những ứng dụng đơn giản như thế này, nhưng bạn đã nắm được bức tranh lớn—build arguments được đặt trong tệp compose và được tham chiếu trong từng Dockerfile.

Ngoài ra, bạn cũng có thể truyền giá trị biến từ môi trường của mình vào build args, rất tiện cho pipeline CI/CD:

services:
  web:
    build:
      context: .
      args:
        - PYTHON_VERSION=${PYTHON_VERSION:-3.10}Được hỗ trợ bởi

Và để ghi đè các giá trị này khi chạy docker-compose, bạn có thể dùng biến môi trường:

PYTHON_VERSION=3.10 docker-compose up --buildĐược hỗ trợ bởi

Cách làm này giúp bạn duy trì bản dựng nhất quán trong toàn đội trong khi vẫn linh hoạt khi cần.

Tính năng của BuildKit

BuildKit, công cụ build hiện đại của Docker, tăng tốc quy trình build với các tính năng khiến việc dùng build args mạnh mẽ hơn nữa. Khi bật BuildKit (bằng cách đặt DOCKER_BUILDKIT=1), bạn mở khóa một vài khả năng mới.

Inline cache cải thiện hiệu năng build bằng cách tận dụng cache của image từ xa. Bạn có thể chỉ định image nguồn để dùng làm cache với cờ --cache-from, và BuildKit sẽ thông minh sử dụng các layer của image đó:

DOCKER_BUILDKIT=1 docker build \
  --build-arg PYTHON_VERSION=3.10 \
  --cache-from flaskapp:dev \
  -t flaskapp:latest .Được hỗ trợ bởi

Một tính năng giá trị khác của BuildKit là deterministic outputs, đảm bảo các bản dựng có thể tái tạo. Điều này rất quan trọng khi bạn muốn có đúng cùng một image bất kể thời điểm hay nơi build:

# Build with deterministic output
DOCKER_BUILDKIT=1 docker build \
  --build-arg PYTHON_VERSION=3.10 \
  --build-arg BUILD_DATE=2025-05-01 \
  --output type=docker,name=flaskapp:stable \
  .Được hỗ trợ bởi

Tính năng che giấu secret trong log của BuildKit bảo vệ thông tin nhạy cảm trong quá trình build.

Không giống build args thông thường, vốn xuất hiện trong log build, BuildKit tự động ẩn giá trị của secrets:

# Create a file with the API key
echo "my-api-key-value" > ./api-key.txt

# Build with secret (value won't appear in logs)
DOCKER_BUILDKIT=1 docker build \
  --secret id=api_key,src=./api-key.txt \
  -t flaskapp:secure .Được hỗ trợ bởi

Trong Dockerfile, bạn sẽ truy cập secret này như sau:

RUN --mount=type=secret,id=api_key \
    cat /run/secrets/api_key > /app/config/api_key.txtĐược hỗ trợ bởi

Các tính năng của BuildKit phối hợp với build args để tạo nên hệ thống build an toàn, hiệu quả và có thể tái tạo, phù hợp với hầu như mọi quy trình container hóa.

Thực tiễn tốt nhất cho Doanh nghiệp

Triển khai Docker build arguments trên các đội lớn đòi hỏi cách tiếp cận tiêu chuẩn hóa, ít nhất là nếu bạn muốn giảm nhầm lẫn và tối đa hóa lợi ích về bảo mật và hiệu năng.

Khi áp dụng build args trong môi trường doanh nghiệp, hãy bắt đầu với việc xác thực tham số hợp lý.

Luôn cung cấp giá trị mặc định hợp lý cho mọi build argument để đảm bảo bản dựng không thất bại bất ngờ khi tham số không được truyền. Bạn cũng nên thêm các kiểm tra xác thực trong Dockerfile để đảm bảo các build arg quan trọng đáp ứng yêu cầu của bạn.

Ví dụ sau xác thực phiên bản Python:

ARG PYTHON_VERSION=3.9
# Validate Python version
RUN if [[ ! "$PYTHON_VERSION" =~ ^3\.[0-9]+$ ]]; then \
      echo "Invalid Python version: ${PYTHON_VERSION}. Must be 3.x"; \
      exit 1; \
    fiĐược hỗ trợ bởi

Tối ưu hóa cache layer là yếu tố then chốt để giảm thời gian build trong pipeline CI/CD.

Sắp xếp các chỉ thị trong Dockerfile để tối đa hóa cache hit bằng cách đặt nội dung ít thay đổi (như cài đặt phụ thuộc) trước nội dung thường xuyên thay đổi (như mã ứng dụng).

Khi dùng build args có thể thay đổi thường xuyên, hãy đặt chúng sau các thao tác ổn định để tránh làm mất hiệu lực toàn bộ cache:

FROM python:3.13-slim

WORKDIR /app

# Dependencies change less frequently - good cache utilization
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Build args that might change often come AFTER stable operations
ARG BUILD_NUMBER
ARG COMMIT_SHA
# Now these args won't invalidate the dependency cacheĐược hỗ trợ bởi

Quản lý metadata thông qua build args giúp cải thiện khả năng truy vết và tuân thủ. Dùng build args để đưa metadata lúc build vào nhãn (labels):

ARG BUILD_DATE
ARG VERSION
ARG COMMIT_SHA
ARG BUILD_URL

LABEL org.opencontainers.image.created="${BUILD_DATE}" Can you please provide me with access to this document?
      org.opencontainers.image.version="${VERSION}" \
      org.opencontainers.image.revision="${COMMIT_SHA}" \
      org.opencontainers.image.url="${BUILD_URL}"Được hỗ trợ bởi

Các nhãn tiêu chuẩn hóa này tuân theo đặc tả của Open Container Initiative (OCI), nghĩa là image của bạn sẽ tương thích với nhiều công cụ quản lý container khác nhau.

Tài liệu thường bị xem nhẹ, nhưng lại rất quan trọng để áp dụng trong doanh nghiệp.

Hãy tạo một mục README rõ ràng ghi lại tất cả build args hiện có, mục đích, giá trị mặc định và ví dụ sử dụng. Ghi rõ build arg nào là bắt buộc và tùy chọn, và ghi chú mọi tương tác giữa các tham số. Cân nhắc thêm thông tin này vào tệp cấu hình pipeline CI/CD dưới dạng chú thích để giúp lập trình viên hiểu giá trị nào họ cần cung cấp:

# Example documented CI configuration
build_job:
  script:
    # BUILD_NUMBER: Unique identifier for this build (required)
    # ENVIRONMENT: Target deployment environment [dev|staging|prod] (required)
    # PYTHON_VERSION: Python version to use (optional, default: 3.9)
    - docker build
      --build-arg BUILD_NUMBER=${CI_PIPELINE_ID}
      --build-arg ENVIRONMENT=${DEPLOY_ENV}
      --build-arg PYTHON_VERSION=${PYTHON_VERSION:-3.9}
      -t myapp:${CI_PIPELINE_ID} .Được hỗ trợ bởi

Để áp dụng ở cấp độ doanh nghiệp thực sự, hãy cân nhắc triển khai một schema cho build argument có thể phân phiên bản và xác thực. Cách làm này cho phép bạn phát triển cấu hình build theo thời gian trong khi vẫn duy trì tương thích ngược.

Phân tích so sánh: Build Args vs. Biến môi trường

Nếu bạn muốn tạo các Docker image an toàn và linh hoạt theo thực tiễn tốt nhất, bạn phải hiểu khi nào nên dùng build arguments và khi nào dùng biến môi trường.

Dưới đây là bảng tham chiếu nhanh:

Điểm khác biệt chính nằm ở thời điểm và mục đích. Build args cấu hình chính quá trình build, trong khi biến môi trường cấu hình ứng dụng khi chạy. Ví dụ, bạn sẽ dùng build arg để chọn base image (ARG PYTHON_VERSION=3.10), còn dùng biến môi trường để cho ứng dụng biết cổng cần lắng nghe (ENV PORT=8080).

Xét về bảo mật, build args rủi ro cao hơn với thông tin nhạy cảm vì chúng tồn tại trong lịch sử image.

Hãy cân nhắc quy trình sau để xử lý các loại cấu hình khác nhau:

# Build-time configuration (non-sensitive)
ARG PYTHON_VERSION=3.13
FROM python:${PYTHON_VERSION}-slim

# Build-time secrets (use BuildKit secrets)
RUN --mount=type=secret,id=build_key \
    cat /run/secrets/build_key > /tmp/key && \
    # Use the secret for build operations
    rm /tmp/key

# Runtime configuration (non-sensitive)
ENV LOG_LEVEL=info

# Runtime secrets (should be injected at runtime, not here)
# This would be provided at runtime with:
# docker run -e API_KEY=secret123 myimageĐược hỗ trợ bởi

Trong thực tế, một mẫu phổ biến là chuyển một số build args thành biến môi trường khi chúng cần khả dụng lúc runtime:

ARG APP_VERSION=1.0.0
# Make the version available at runtime
ENV APP_VERSION=${APP_VERSION}Được hỗ trợ bởi

Với ứng dụng doanh nghiệp, sự tách bạch này cho phép các đội khác nhau quản lý những khía cạnh khác nhau của vòng đời ứng dụng. Nhóm DevOps có thể chỉnh build args cho quá trình tạo image, trong khi đội vận hành có thể điều chỉnh biến môi trường khi triển khai mà không cần rebuild image.

Tổng kết về Docker Build Args

Docker build args không chỉ là một tính năng kỹ thuật khác - chúng là công cụ chủ lực để tạo image hoạt động nhất quán giữa đội ngũ và các môi trường.

Tôi đã hướng dẫn cách dùng chúng trong các dự án Python đơn giản, đồng thời vẫn bảo vệ thông tin nhạy cảm. Bạn cũng đã thấy cách tích hợp build args với các công cụ như Docker Compose.

Hãy xem build args như nền móng của chiến lược container hóa linh hoạt. Bắt đầu nhỏ bằng cách tham số hóa phiên bản Python trong dự án tiếp theo. Khi đã quen, hãy thử thêm logic điều kiện cho các môi trường khác nhau. Chẳng mấy chốc, bạn sẽ tạo được các bản dựng đa giai đoạn tinh vi mà đội ngũ có thể tùy biến mà không cần sửa Dockerfile.

Sẵn sàng tìm hiểu sâu hơn? Các khóa học từ DataCamp dưới đây là điểm dừng chân tiếp theo tốt nhất:

• Giới thiệu về Docker
• Docker trung cấp
• Các khái niệm về Containerization và Virtualization
• Containerization và Virtualization với Docker và Kubernetes
• CI/CD cho Machine Learning