Docker Build Args: Panduan Utama untuk Profesional Data

Implikasi Keamanan dan Mitigasi Risiko

Meskipun build arguments menawarkan fleksibilitas, mereka juga memperkenalkan potensi risiko keamanan yang perlu Anda pahami untuk menjaga image Docker tetap aman.

Vektor kebocoran argumen

Build arguments tidak selangka yang Anda kira. Nilai build args dapat bocor melalui beberapa vektor yang sering diabaikan pengembang. Pertama, riwayat image Docker mengekspos semua build args Anda, artinya siapa pun yang memiliki akses ke image Anda dapat menjalankan docker history untuk melihat nilai yang digunakan saat build, termasuk informasi sensitif seperti API key atau token.

docker history flaskapp:devDidukung oleh

Gambar 4 - Riwayat Docker

Layer perantara juga dapat membocorkan build arguments. Meskipun Anda menggunakan multi-stage build dan tidak menyalin layer yang berisi informasi sensitif, nilai build arg tetap ada di cache layer pada mesin build. Ini berarti siapa pun yang memiliki akses ke Docker daemon di server build Anda berpotensi mengekstrak informasi tersebut.

Log CI/CD juga menimbulkan risiko signifikan. Sebagian besar sistem CI/CD mencatat seluruh perintah build, termasuk build args yang dilewatkan di command line.

Sebagai contoh, seluruh perintah ini, termasuk API_KEY, akan terlihat di log CI/CD:

docker build --build-arg API_KEY=secret123 -t myapp:latest .Didukung oleh

Log ini sering dapat diakses oleh lebih banyak pengembang atau bahkan disimpan di sistem pihak ketiga, yang meningkatkan permukaan eksposur nilai sensitif.

Alternatif yang aman

Untuk informasi sensitif, Anda sebaiknya menggunakan fitur secrets dari Docker BuildKit alih-alih build args. BuildKit memungkinkan Anda me-mount secrets saat proses build tanpa menyimpannya dalam image final atau riwayat.

Berikut contoh Dockerfile yang menggunakan secrets 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"]Didukung oleh

Untuk membangun image ini dengan secret, pertama buat file api_key.txt:

echo "my-secret-api-key" > api_key.txtDidukung oleh

Lalu bangun image dengan secret tersebut:

DOCKER_BUILDKIT=1 docker build \
  --secret id=api_key,src=api_key.txt \
  -t flaskapp:secure .Didukung oleh

Gambar 5 - Membangun image dengan BuildKit secrets

Untuk konfigurasi yang perlu tersedia saat runtime, environment variable tetap menjadi pendekatan yang disukai. Variabel ini dapat diatur saat menjalankan container tanpa dimasukkan ke dalam image:

# Set environment variables at runtime
docker run -e API_KEY=secret123 -p 5000:5000 flaskapp:latestDidukung oleh

Untuk menangani konfigurasi sensitif secara aman di produksi, pertimbangkan menggunakan platform orkestrasi container seperti Kubernetes, yang menyediakan metode aman seperti Secrets untuk mengelola informasi sensitif. Docker Swarm juga menawarkan kemampuan serupa dengan manajemen secrets.

> Docker bukan satu-satunya platform containerization. Baca tentang Podman untuk mengetahui alat mana yang lebih sesuai bagi Anda.

Ingat, aturan praktisnya: gunakan build args untuk konfigurasi saat build yang tidak sensitif, gunakan BuildKit secrets untuk kebutuhan sensitif saat build, dan gunakan environment variable atau secrets pada platform orkestrasi untuk konfigurasi runtime.

Integrasi dengan Ekosistem Container

Setelah memahami dasarnya, mari jelajahi cara memanfaatkan build arguments dalam ekosistem Docker yang lebih luas dan alat build modern.

Docker Compose

Docker Compose memudahkan pendefinisian dan pembagian build arguments di aplikasi multi-container Anda.

Jika Anda ingin mengikutinya, berikut struktur proyek lengkap untuk dua layanan Flask sederhana:

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 dependenciesDidukung oleh

Saya akan membahas cepat isi file satu per satu:

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)Didukung oleh

web/requirements.txt

flask==3.1.0Didukung oleh

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"]Didukung oleh

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)Didukung oleh

api/requirements.txt

flask==3.1.0Didukung oleh

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"]Didukung oleh

.env

PYTHON_VERSION=3.10
ENVIRONMENT=developmentDidukung oleh

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"Didukung oleh

Intinya, ini adalah cara yang sangat sederhana untuk menjalankan dua aplikasi di lingkungan terisolasi, keduanya secara bersamaan, keduanya dengan serangkaian build args tertentu.

Anda dapat menggunakan perintah ini untuk menjalankan setup multi-container:

docker compose up --buildDidukung oleh

Gambar 6 - Build args dengan Docker Compose

Setelah beberapa detik, Anda akan melihat kedua layanan berjalan:

Gambar 7 - Build args dengan Docker Compose (2)

Cukup verbose untuk aplikasi sesederhana dua ini, tetapi inti pesannya jelas—build arguments ditetapkan di file compose dan direferensikan di Dockerfile masing-masing.

Sebagai catatan, Anda juga dapat meneruskan nilai variabel dari environment Anda ke build args, yang berguna untuk pipeline CI/CD:

services:
  web:
    build:
      context: .
      args:
        - PYTHON_VERSION=${PYTHON_VERSION:-3.10}Didukung oleh

Dan untuk menimpa nilai ini saat menjalankan docker-compose, Anda dapat menggunakan environment variable:

PYTHON_VERSION=3.10 docker-compose up --buildDidukung oleh

Pendekatan ini memungkinkan Anda mempertahankan build yang konsisten di seluruh tim sambil tetap menawarkan fleksibilitas saat diperlukan.

Fitur BuildKit

BuildKit, mesin build modern Docker, meningkatkan proses build Anda dengan fitur yang membuat penggunaan build args semakin kuat. Saat Anda mengaktifkan BuildKit (dengan menyetel DOCKER_BUILDKIT=1), Anda membuka sejumlah kemampuan baru.

Inline cache meningkatkan kinerja build dengan memanfaatkan cache build dari image jarak jauh. Anda dapat menentukan image sumber untuk digunakan sebagai cache dengan flag --cache-from, dan BuildKit akan secara cerdas menggunakan layer image tersebut:

DOCKER_BUILDKIT=1 docker build \
  --build-arg PYTHON_VERSION=3.10 \
  --cache-from flaskapp:dev \
  -t flaskapp:latest .Didukung oleh

Fitur BuildKit berharga lainnya adalah deterministic outputs, yang memastikan build Anda dapat direproduksi. Ini krusial saat Anda menginginkan image yang persis sama terlepas dari kapan atau di mana dibuat:

# 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 \
  .Didukung oleh

Redaksi secret pada log BuildKit melindungi informasi sensitif selama build. 

Tidak seperti build args biasa, yang muncul di log build, BuildKit secara otomatis menyembunyikan nilai 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 .Didukung oleh

Di Dockerfile Anda, secret ini diakses dengan:

RUN --mount=type=secret,id=api_key \
    cat /run/secrets/api_key > /app/config/api_key.txtDidukung oleh

Fitur-fitur BuildKit ini bekerja bersama build args untuk menciptakan sistem build yang lebih aman, efisien, dan dapat direproduksi yang dapat beradaptasi dengan hampir semua alur kerja containerization.

Praktik Terbaik untuk Adopsi di Perusahaan

Menerapkan Docker build arguments di tim besar memerlukan pendekatan yang terstandarisasi, setidaknya jika Anda ingin meminimalkan kebingungan dan memaksimalkan manfaat keamanan serta kinerja.

Saat mengadopsi build args di lingkungan perusahaan, mulailah dengan validasi argumen yang tepat. 

Selalu sediakan nilai default yang masuk akal untuk setiap build argument agar build tidak gagal secara tak terduga ketika argumen tidak diberikan. Anda juga sebaiknya menambahkan pemeriksaan validasi di Dockerfile untuk memastikan build args kritis memenuhi kebutuhan Anda.

Berikut contoh yang memvalidasi versi 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; \
    fiDidukung oleh

Optimalisasi caching layer sangat penting untuk mengurangi waktu build di pipeline CI/CD. 

Urutkan instruksi Dockerfile untuk memaksimalkan cache hit dengan menempatkan konten yang jarang berubah (seperti instalasi dependensi) sebelum konten yang sering berubah (seperti kode aplikasi). 

Saat menggunakan build args yang mungkin sering berubah, letakkan setelah operasi yang stabil untuk menghindari invalidasi seluruh 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 cacheDidukung oleh

Manajemen metadata melalui build args meningkatkan keterlacakan dan kepatuhan. Gunakan build args untuk menyuntikkan metadata saat build sebagai label:

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}"Didukung oleh

Label standar ini mengikuti spesifikasi Open Container Initiative (OCI), yang berarti image Anda akan kompatibel dengan berbagai alat manajemen container.

Dokumentasi sering diabaikan, tetapi sangat penting untuk adopsi di perusahaan. 

Buat bagian README yang jelas yang mendokumentasikan semua build args yang tersedia, tujuannya, nilai default, dan contoh penggunaan. Sertakan argumen mana yang wajib dan opsional, serta dokumentasikan interaksi antarargumen. Pertimbangkan juga menambahkan informasi ini ke file konfigurasi pipeline CI/CD sebagai komentar agar pengembang memahami nilai apa yang perlu mereka sediakan:

# 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} .Didukung oleh

Untuk adopsi kelas perusahaan yang sesungguhnya, pertimbangkan menerapkan skema build argument yang dapat di-versi dan divalidasi. Pendekatan ini memungkinkan Anda mengembangkan konfigurasi build seiring waktu sambil mempertahankan kompatibilitas mundur.

Analisis Perbandingan: Build Args vs. Environment Variables

Jika Anda ingin membuat image Docker yang aman dan fleksibel serta mengikuti praktik terbaik, Anda harus memahami kapan menggunakan build arguments dan kapan menggunakan environment variables.

Berikut tabel referensi yang dapat Anda lihat kapan saja:

Perbedaan utama terletak pada waktu dan tujuan penggunaannya. Build args mengonfigurasi proses build itu sendiri, sedangkan environment variables mengonfigurasi aplikasi yang berjalan. Misalnya, Anda akan menggunakan build arg untuk memilih base image yang digunakan (ARG PYTHON_VERSION=3.10), namun menggunakan environment variable untuk memberi tahu aplikasi port mana yang harus didengarkan (ENV PORT=8080).

Dari sudut pandang keamanan, build args menimbulkan risiko lebih tinggi untuk informasi sensitif karena tetap ada di riwayat image. 

Pertimbangkan alur berikut untuk menangani berbagai jenis konfigurasi:

# 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 myimageDidukung oleh

Dalam praktiknya, pola umum adalah mengonversi build args tertentu menjadi environment variables saat dibutuhkan pada runtime:

ARG APP_VERSION=1.0.0
# Make the version available at runtime
ENV APP_VERSION=${APP_VERSION}Didukung oleh

Untuk aplikasi perusahaan, pemisahan ini memungkinkan tim berbeda mengelola aspek berbeda dari siklus hidup aplikasi. Tim DevOps dapat memodifikasi build args untuk pembuatan image, sementara operator dapat menyesuaikan environment variable saat deployment tanpa membangun ulang image.

Merangkum Docker Build Args

Docker build args bukan sekadar fitur teknis lain — ini adalah alat andalan Anda untuk membuat image yang bekerja konsisten di seluruh tim dan lingkungan. 

Saya telah memandu cara menggunakannya dalam proyek Python sederhana, sambil tetap menjaga informasi sensitif tetap aman. Anda juga telah melihat cara mengintegrasikan build args dengan alat seperti Docker Compose.

Anggap build args sebagai fondasi strategi containerization yang fleksibel. Mulailah dari hal kecil dengan memparametrisasi versi Python pada proyek berikutnya. Setelah terasa nyaman, coba tambahkan logika kondisional untuk environment yang berbeda. Tanpa terasa, Anda akan membuat multi-stage build canggih yang dapat dikustomisasi tim tanpa mengubah Dockerfile.

Siap menyelami lebih dalam? Kursus-kursus dari DataCamp berikut adalah langkah terbaik selanjutnya:

• Introduction to Docker
• Intermediate Docker
• Containerization and Virtualization Concepts
• Containerization and Virtualization with Docker and Kubernetes
• CI/CD for Machine Learning