Externalized Configuration

Environment-Specific Values

💡 Externalized configuration ek TRAVELING MUSICIAN ka SETUP hai — INSTRUMENT (application JAR) SAME rehta hai HAR SHOW mein, LEKIN SOUND SETTINGS (configuration) HAR VENUE (environment) ke hisaab se ADJUST hoती hain — bina INSTRUMENT ko REBUILD kiye.

EXTERNALIZED configuration ka CORE IDEA hai — APPLICATION CODE (JAR file) EK BAAR BUILD hoti hai, aur SAME JAR, DIFFERENT ENVIRONMENTS (dev, staging, prod) mein, SIRF DIFFERENT CONFIGURATION ke saath, DEPLOY hoti hai. CODE mein KABHI bhi HARDCODED environment-specific VALUES (jaise database URL) NAHI honi chahiye.

Modern DEPLOYMENT (Docker, Kubernetes) mein, CONFIGURATION typically ENVIRONMENT VARIABLES ke through PASS hoti hai — Kubernetes ConfigMaps (non-sensitive data) aur Secrets (passwords, API keys) SEPARATELY manage kiye jaate hain, aur APPLICATION STARTUP par, CONTAINER mein INJECT ho jaate hain.

# Dockerfile mein, JAR file SAME rehta hai HAR environment ke liye:
FROM eclipse-temurin:17-jre
COPY target/myapp.jar app.jar
ENTRYPOINT ["java", "-jar", "app.jar"]

# docker run KE WAQT, environment-specific config PASS hoti hai:
docker run -e SPRING_DATASOURCE_URL=jdbc:postgresql://prod-db/app \
           -e SPRING_PROFILES_ACTIVE=prod \
           myapp:latest

🌍

Externalized configuration ek TRAVELING MUSICIAN ka SETUP hai — INSTRUMENT (application JAR) SAME rehta hai HAR SHOW mein, LEKIN SOUND SETTINGS (configuration) HAR VENUE (environment) ke hisaab se ADJUST hoती hain — bina INSTRUMENT ko REBUILD kiye.

1 / 2

⚡ झट से Recap

JAR EK BAAR build hota hai, DIFFERENT configs se, DIFFERENT environments mein deploy
Environment variables/Kubernetes ConfigMaps-Secrets = production PATTERN
"12-Factor App" principle — configuration KABHI code mein hardcode NAHI

इस page में (2 subtopics)

Container-based deployments (Docker, Kubernetes) mein, CONFIGURATION typically ENVIRONMENT VARIABLES ke through PASS ki jaati hai (ConfigMaps, Secrets) — JAR file KHUD CHANGE nahi hoती, environment DIFFERENT hone par bhi. Ye "BUILD ONCE, DEPLOY ANYWHERE" principle ENABLE karta hai.

# Kubernetes deployment.yaml mein:
env:
  - name: SPRING_DATASOURCE_URL
    value: jdbc:postgresql://prod-db:5432/app
  - name: SPRING_DATASOURCE_PASSWORD
    valueFrom:
      secretKeyRef:
        name: db-secret
        key: password

BADE, MULTI-SERVICE systems mein, Spring Cloud Config Server EK CENTRALIZED PLACE hai SAARI microservices ki configuration RAKHNE ke liye (typically ek GIT repository mein) — HAR service STARTUP par, Config Server SE APNI configuration FETCH karti hai.

Config Server = centralized configuration, typically Git-backed
HAR microservice startup par Config Server se config FETCH karti hai
Configuration CHANGES ke liye, REDEPLOY ki zaroorat NAHI (refresh endpoint se)

← पिछला🔗 Relaxed Binding अगला →🎭 Spring Boot Profiles in Practice

Code10x

Externalized Configuration

Environment-Specific Config via Docker/Kubernetes

Config Server — Centralized Configuration