Docker Build Args: डेटा प्रोफेशनलों के लिए परम मार्गदर्शिका

सुरक्षा निहितार्थ और जोखिम न्यूनीकरण

भले ही build arguments लचीलापन प्रदान करते हैं, वे संभावित सुरक्षा जोखिम भी लाते हैं जिन्हें आपको अपनी Docker इमेज को सुरक्षित रखने के लिए समझना जरूरी है।

आर्ग्युमेंट लीक होने के वेक्टर

Build arguments उतने निजी नहीं हैं जितना आप सोच सकते हैं। build args के मान कई ऐसे वेक्टरों से लीक हो सकते हैं जिन्हें कई डेवलपर्स नज़रअंदाज़ कर देते हैं। सबसे पहले, Docker इमेज हिस्ट्री आपके सभी build args उजागर करती है, यानी आपकी इमेज तक पहुंच वाले कोई भी व्यक्ति docker history चलाकर बिल्ड टाइम पर उपयोग किए गए मान देख सकता है—जिसमें API keys या tokens जैसी संवेदनशील जानकारी भी शामिल हो सकती है।

docker history flaskapp:dev

छवि 4 - Docker हिस्ट्री

इंटरमीडिएट लेयर्स भी build arguments लीक कर सकती हैं। भले ही आप मल्टी-स्टेज बिल्ड का उपयोग करें और संवेदनशील जानकारी वाली लेयर को कॉपी न करें, फिर भी बिल्ड मशीन पर लेयर कैश में build arg के मान बने रहते हैं। इसका अर्थ है कि आपके बिल्ड सर्वर पर Docker डेमन तक पहुंच रखने वाला कोई भी व्यक्ति संभवतः इस जानकारी को निकाल सकता है।

CI/CD लॉग्स एक और महत्वपूर्ण जोखिम हैं। अधिकांश CI/CD सिस्टम संपूर्ण बिल्ड कमांड लॉग करते हैं, जिसमें कमांड लाइन पर पास किए गए build args भी शामिल होते हैं।

उदाहरण के लिए, यह पूरी कमांड, जिसमें API_KEY भी शामिल है, CI/CD लॉग्स में दिखाई देगी:

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

ये लॉग्स अक्सर डेवलपर्स के व्यापक समूह के लिए सुलभ होते हैं या यहाँ तक कि थर्ड-पार्टी सिस्टम्स में संग्रहीत होते हैं, जिससे संवेदनशील मानों के एक्सपोज़र की संभावना बढ़ जाती है।

सुरक्षित विकल्प

संवेदनशील जानकारी के लिए, आपको build args के बजाय Docker BuildKit की secrets सुविधा का उपयोग करना चाहिए। BuildKit आपको बिल्ड प्रक्रिया के दौरान सीक्रेट्स माउंट करने देता है, बिना उन्हें अंतिम इमेज या हिस्ट्री में बनाए रखने के।

यहाँ Docker BuildKit secrets का उपयोग करने वाला एक उदाहरण Dockerfile है:

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

इस इमेज को किसी सीक्रेट के साथ बनाने के लिए, पहले api_key.txt फ़ाइल बनाएं:

echo "my-secret-api-key" > api_key.txt

और फिर सीक्रेट के साथ इमेज बनाएं:

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

छवि 5 - BuildKit सीक्रेट्स के साथ इमेज बनाना

ऐसी कॉन्फ़िगरेशन के लिए जो रनटाइम पर उपलब्ध होनी चाहिए, environment variables पसंदीदा तरीका बने रहते हैं। इन्हें कंटेनर शुरू करते समय सेट किया जा सकता है, बिना इमेज में बेक किए हुए:

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

प्रोडक्शन में संवेदनशील कॉन्फ़िगरेशन को सुरक्षित रूप से हैंडल करने के लिए, Kubernetes जैसे कंटेनर ऑर्केस्ट्रेशन प्लेटफॉर्म्स का उपयोग करने पर विचार करें, जो Secrets जैसी सुरक्षित विधियाँ प्रदान करते हैं। Docker Swarm भी अपने सीक्रेट्स मैनेजमेंट के साथ समान क्षमताएँ देता है।

> Docker अकेला कंटेनराइज़ेशन प्लेटफॉर्म नहीं है। Podman के बारे में पढ़ें और जानें कि कौन सा टूल आपके लिए बेहतर है।

याद रखें, thumb का नियम यह है: गैर-संवेदनशील बिल्ड-टाइम कॉन्फ़िगरेशन के लिए build args का उपयोग करें, संवेदनशील बिल्ड-टाइम आवश्यकताओं के लिए BuildKit secrets का उपयोग करें, और रनटाइम कॉन्फ़िगरेशन के लिए environment variables या ऑर्केस्ट्रेशन प्लेटफॉर्म के secrets का उपयोग करें।

कंटेनर इकोसिस्टम के साथ एकीकरण

अब जब बुनियादी बातें हो गई हैं, तो देखते हैं कि व्यापक Docker इकोसिस्टम और आधुनिक बिल्ड टूल्स के भीतर build arguments का लाभ कैसे उठाया जाए।

Docker Compose

Docker Compose आपकी मल्टी-कंटेनर एप्लिकेशंस में build arguments को परिभाषित और साझा करना आसान बनाता है।

यदि आप साथ चलना चाहते हैं, तो यहाँ दो सरल Flask सेवाओं के लिए संपूर्ण प्रोजेक्ट संरचना है:

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

मैं फ़ाइलों की सामग्री पर एक-एक करके जल्दी नज़र डालूंगा:

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)

web/requirements.txt

flask==3.1.0

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

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)

api/requirements.txt

flask==3.1.0

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

.env

PYTHON_VERSION=3.10
ENVIRONMENT=development

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"

संक्षेप में, यह दोनों एप्लिकेशंस को अलग-अलग वातावरणों में, एक साथ, और एक विशिष्ट build args सेट के साथ शुरू करने का बहुत सरल तरीका है।

आप इस कमांड का उपयोग मल्टी-कंटेनर सेटअप चलाने के लिए कर सकते हैं:

docker compose up --build

छवि 6 - Docker Compose के साथ build args

कुछ सेकंड के बाद, आप दोनों सेवाओं को चलते हुए देखेंगे:

छवि 7 - Docker Compose के साथ build args (2)

ये दोनों एप्लिकेशन जितने सरल हैं, उसके लिए यह सेटअप काफ़ी वर्बोज़ है, लेकिन मूल बात स्पष्ट है—build arguments compose फ़ाइल में सेट होते हैं और व्यक्तिगत Dockerfiles में संदर्भित होते हैं।

एक साइड नोट पर, आप अपने environment से भी build args में वेरिएबल मान पास कर सकते हैं, जो CI/CD पाइपलाइनों के लिए सहायक है:

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

और docker-compose चलाते समय इन मानों को ओवरराइड करने के लिए, आप environment variables का उपयोग कर सकते हैं:

PYTHON_VERSION=3.10 docker-compose up --build

यह तरीका आपकी टीम में एकसमान बिल्ड्स बनाए रखते हुए, ज़रूरत पड़ने पर लचीलापन भी प्रदान करता है।

BuildKit की विशेषताएँ

BuildKit, Docker का आधुनिक बिल्ड इंजन, आपके बिल्ड प्रोसेस को ऐसी सुविधाओं के साथ सुपरचार्ज करता है जो build args के उपयोग को और भी शक्तिशाली बना देती हैं। जब आप BuildKit सक्षम करते हैं ( DOCKER_BUILDKIT=1 सेट करके), तो आप कुछ नई क्षमताएँ अनलॉक करते हैं।

Inline cache रिमोट इमेज के बिल्ड कैश का लाभ उठाकर बिल्ड प्रदर्शन में सुधार करती है। आप --cache-from फ़्लैग के साथ किसी सोर्स इमेज को कैश के रूप में निर्दिष्ट कर सकते हैं, और BuildKit उस इमेज की लेयर्स को बुद्धिमानी से उपयोग करेगा:

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

BuildKit की एक और मूल्यवान सुविधा है deterministic outputs, जो सुनिश्चित करती है कि आपके बिल्ड्स पुनरुत्पाद्य हों। यह तब महत्वपूर्ण है जब आप चाहते हैं कि जहाँ या जब भी बिल्ड हो, इमेज बिल्कुल एक जैसी बने:

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

BuildKit के लॉग्स में secret redaction बिल्ड्स के दौरान संवेदनशील जानकारी की रक्षा करता है. 

सामान्य build args के विपरीत, जो बिल्ड लॉग्स में दिखाई देते हैं, BuildKit स्वतः ही सीक्रेट्स के मान छुपा देता है:

# 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 .

अपने Dockerfile में, आप इस सीक्रेट तक यूँ पहुँचेंगे:

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

ये BuildKit सुविधाएँ build args के साथ मिलकर एक अधिक सुरक्षित, कुशल और पुनरुत्पाद्य बिल्ड सिस्टम बनाती हैं जो लगभग किसी भी कंटेनराइज़ेशन वर्कफ़्लो के अनुरूप ढल सकता है।

एंटरप्राइज़ अपनाने के लिए सर्वोत्तम प्रथाएँ

बड़ी टीमों में Docker build arguments को लागू करने के लिए मानकीकृत दृष्टिकोणों की आवश्यकता होती है—कम-से-कम अगर आप भ्रम को न्यूनतम और सुरक्षा व प्रदर्शन लाभों को अधिकतम करना चाहते हैं।

एंटरप्राइज़ वातावरणों में build args अपनाते समय, उचित आर्ग्युमेंट वैलिडेशन से शुरुआत करें। 

हमेशा हर build argument के लिए समझदारी भरे डिफॉल्ट मान प्रदान करें ताकि आर्ग्युमेंट पास न होने पर बिल्ड्स अनपेक्षित रूप से फेल न हों। आपको अपने Dockerfile के भीतर वैलिडेशन चेक भी जोड़ने चाहिए ताकि महत्वपूर्ण build args आपकी आवश्यकताओं को पूरा करें।

यहाँ 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

लेयर कैशिंग ऑप्टिमाइज़ेशन CI/CD पाइपलाइनों में बिल्ड समय कम करने के लिए महत्वपूर्ण है. 

अपने Dockerfile निर्देशों को इस तरह ऑर्डर करें कि कैश हिट्स अधिकतम हों—कम बदलने वाली सामग्री (जैसे डिपेंडेंसी इंस्टॉलेशन) को अधिक बदलने वाली सामग्री (जैसे एप्लिकेशन कोड) से पहले रखें। 

जब आप ऐसे build args का उपयोग कर रहे हों जो अक्सर बदल सकते हैं, तो उन्हें स्थिर ऑपरेशंस के बाद रखें ताकि पूरा कैश अमान्य न हो:

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

Build args के माध्यम से मेटाडेटा मैनेजमेंट ट्रेसएबिलिटी और कम्प्लायंस में सुधार करता है। बिल्ड-टाइम मेटाडेटा को लेबल्स के रूप में इंजेक्ट करने के लिए build args का उपयोग करें:

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

ये मानकीकृत लेबल Open Container Initiative (OCI) स्पेसिफ़िकेशन का पालन करते हैं, यानी आपकी इमेज अलग-अलग कंटेनर मैनेजमेंट टूल्स के साथ संगत रहेंगी।

डॉक्युमेंटेशन को अक्सर नज़रअंदाज़ कर दिया जाता है, लेकिन एंटरप्राइज़ अपनाने के लिए यह महत्वपूर्ण है. 

एक स्पष्ट README सेक्शन बनाएँ जो सभी उपलब्ध build args, उनका उद्देश्य, डिफॉल्ट मान और उपयोग के उदाहरणों को डॉक्यूमेंट करे। यह भी शामिल करें कि कौन से build args आवश्यक हैं और कौन से वैकल्पिक, और अलग-अलग आर्ग्युमेंट्स के बीच किसी भी इंटरैक्शन को डॉक्यूमेंट करें। डेवलपर्स की मदद के लिए इस जानकारी को अपनी CI/CD पाइपलाइन कॉन्फ़िगरेशन फ़ाइलों में टिप्पणियों के रूप में जोड़ने पर भी विचार करें, ताकि वे समझ सकें कि उन्हें कौन से मान प्रदान करने हैं:

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

वास्तव में एंटरप्राइज़-ग्रेड अपनाने के लिए, एक ऐसा build argument स्कीमा लागू करने पर विचार करें जिसे वर्शन किया जा सके और वैलिडेट किया जा सके। यह तरीका आपको समय के साथ अपने बिल्ड कॉन्फ़िगरेशन को विकसित करने देता है, जबकि बैकवर्ड कम्पैटिबिलिटी बनाए रखता है।

तुलनात्मक विश्लेषण: Build Args बनाम Environment Variables

यदि आप सर्वोत्तम प्रथाओं का पालन करते हुए सुरक्षित और लचीली Docker इमेज बनाना चाहते हैं, तो आपको समझना होगा कि build arguments कब उपयोग करने हैं और environment variables कब।

यहाँ एक तालिका है जिसे आप कभी भी संदर्भित कर सकते हैं:

मुख्य अंतर इस समय और उद्देश्य में निहित है। Build args बिल्ड प्रक्रिया को कॉन्फ़िगर करते हैं, जबकि environment variables चल रहे एप्लिकेशन को। उदाहरण के लिए, आप किस बेस इमेज का उपयोग करना है यह चुनने के लिए build arg का उपयोग करेंगे (ARG PYTHON_VERSION=3.10), लेकिन आपकी एप्लिकेशन किस पोर्ट पर सुने यह बताने के लिए environment variable का (ENV PORT=8080)।

सुरक्षा के दृष्टिकोण से, build args अधिक जोखिम पैदा करते हैं संवेदनशील जानकारी के लिए क्योंकि वे इमेज हिस्ट्री में रहते हैं। 

विभिन्न प्रकार की कॉन्फ़िगरेशन को हैंडल करने के लिए इस वर्कफ़्लो पर विचार करें:

# 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

व्यवहार में, एक सामान्य पैटर्न यह है कि जिन build args को रनटाइम पर उपलब्ध होना है, उन्हें environment variables में बदल दिया जाए:

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

एंटरप्राइज़ एप्लिकेशंस के लिए, यह विभाजन विभिन्न टीमों को एप्लिकेशन के लाइफसायकल के अलग-अलग पहलुओं को मैनेज करने देता है। DevOps टीमें इमेज कंस्ट्रक्शन के लिए build args में बदलाव कर सकती हैं, जबकि ऑपरेटर्स बिना इमेज को फिर से बनाए डिप्लॉयमेंट के दौरान environment variables समायोजित कर सकते हैं।

Docker Build Args का सार

Docker build args कोई साधारण तकनीकी फीचर नहीं हैं—ये आपकी टीम और वातावरणों में एकसमान रूप से काम करने वाली इमेज बनाने के लिए आपका पसंदीदा उपकरण हैं। 

मैंने आपको दिखाया कि कैसे इन्हें सरल Python प्रोजेक्ट्स में उपयोग करें, साथ ही अपनी संवेदनशील जानकारी को सुरक्षित रखें। आपने यह भी देखा कि Docker Compose जैसे टूल्स के साथ build args को कैसे इंटीग्रेट करें।

build args को लचीली कंटेनराइज़ेशन रणनीति की नींव के रूप में सोचें। अपने अगले प्रोजेक्ट में Python वर्ज़न को पैरामीट्राइज़ करके छोटा शुरू करें। जब यह सहज लगे, तो अलग-अलग वातावरणों के लिए कंडीशनल लॉजिक जोड़कर देखें। देखते ही देखते, आप परिष्कृत मल्टी-स्टेज बिल्ड्स बनाएँगे जिन्हें आपकी टीम Dockerfile बदले बिना कस्टमाइज़ कर सकेगी।

और गहराई में जाना चाहते हैं? DataCamp के ये कोर्स आपका अगला बेहतरीन पड़ाव हैं:

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