विन्यास का उत्तराधिकार
1) मुझे विन्यास विरासत की आवश्यकता क्यों है?
परिपक्व उत्पादों में, विन्यास मापदंडों की संख्या सेवाओं की संख्या की तुलना में तेजी से बढ़ ती है। इनहेरिटेंस अनुमति देता है:- सामान्य मानों (लॉगिंग, रीट्रे, टाइमआउट) का पुन: उपयोग करें।
- साझा जिम्मेदारी: मंच बुनियादी नीतियों, सेवा आदेशों को सेट करता है - केवल विचलन।
- दोहराव से बचें और गलतफहमी के जोखिम को कम करें।
- स्पीड अप रिलीज: परिवर्तन डिफ़ॉल्ट रूप से पेड़ के नीचे प्रसारित किए जाते
- एकल दृष्टिकोण के साथ बहु-वातावरण और बहु-किरायेदारी का समर्थन करें।
2) इनहेरिटेंस पैटर्न
2. 1 पदानुक्रमित (माता-पिता → बच्चा)
आधार (वैश्विक) → पर्यावरण (prod/stage/dev) → क्षेत्र/क्लस्टर → सेवा → उदाहरण।
सरल और पारदर्शी, लेकिन गहरी चेनिंग और जटिल डिबगिंग का कारण बन सकता है।
2. 2 स्तरित (आधार/ओवरले)
बेस लेयर + ओवरले सेट (फीचर-एक्स, क्षेत्र-यूरोपीय संघ, सुरक्षा-सख्ती)।
GitOps और Kustomize के साथ अच्छी तरह से काम करता है; ओवरले स्वतंत्र और रचना हैं।
2. 3 समग्र (मॉड्यूल/पैकेज)
कॉन्फ़िगरेशन मॉड्यूल से इकट्ठा किया गया है: 'लॉगिंग @ v2', 'मेट्रिक्स @ v1', 'http @ v3'।
मॉड्यूल वर्शनिंग, सिमेंटिक अनुकूलता, स्पष्ट निर्भरता।
2. 4 पॉलिसी-ए-कोड
बेसिक "लिमिटर्स" और इनवेरिएंट्स (OPA/Rego, Kyverno, Conftest)।
मूल्य स्वयं विरासत में नहीं मिले हैं, लेकिन उनकी स्वीकार्यता के नियम हैं।
3) विलय एल्गोरिदम और प्राथमिकताएं
मुख्य मुद्दा संघर्षों को हल करने की प्रक्रिया है। विनिर्देश में इसे ठीक करने की सिफारिश की गई है:1. स्रोतों का क्रम: बाएं से दाएं (आधार ← env ← क्षेत्र ← सेवा ← उदाहरण)।
2. प्रकार के लिए नियम:- स्केलर: "अंतिम-लेखन-जीत।"
- वस्तु: कुंजियों पर पुनरावर्ती विलयन।
- 'जोड़ें '/' तैयारी'
- 'Un By (कुंजी)' (कुंजी द्वारा सेट)
- 'पैच' ('नाम' और आंशिक विलय द्वारा आइटम खोजें)।
- 3. आरक्षित कुंजियाँ (उदाहरण के लिए, '_ merge: बदलें '/' _ merge: deep' नोड स्तर पर).
- 4. इंटरैक्टिव स्रोतों की प्राथ
स्टार्टअप फ्लैग्स/ENV चर> रनटाइम सीक्रेट> डिस्क> डिस्क पर तयशुदा मान कोड में.
YAML विलय का उदाहरण
yaml base. yaml http:
port: 8080 timeouts:
read: 2s write: 2s features:
- name: audit enabled: false
prod. yaml http:
timeouts:
read: 1s features:
- name: audit enabled: true
- name: billing enabled: true
Result (under policy: object = deep merge, array = uniqueBy (name) + patch)
http:
port: 8080 timeouts:
read: 1s write: 2s features:
- name: audit enabled: true
- name: billing enabled: true
4) योजनाएं और मान्यता
एक स्कीमा की उपस्थिति सुरक्षित विरासत के लिए एक शर्त है।
JSON Schema/OpenAPI: प्रकार, आवश्यक फ़ील्ड, एनम, पैटर्न, बाधाएँ ('न्यूनतम', 'प्रारूप', 'पैटर्नप्रॉपर्टी')।
स्कीमा वर्शनिंग (सेमवर): प्रमुख - ब्रेकिंग, मामूली - नए क्षेत्र, पैच - फिक्स।
प्री-मर्ज और पोस्ट-मर्ज चेक: टुकड़े और परिणाम दोनों को मान्य करें।
तयशुदा: स्कीमा स्तर पर सेट (ड्राफ्ट-07 + 'डिफ़ॉल्ट' समर्थन करता है).
5) वातावरण और तैनाती मैट्रिक्स
विशिष्ट मैट्रिक्स:- env: देव, परीक्षण, चरण, प्रोड क्षेत्र: यूरोपीय संघ-मध्य -1, यूएस-ईस्ट -1 टियर: बैच, रियलटाइम, आंतरिक किरायेदार: ए/बी/सी (व्हाइट-लेबल, बी 2 बी)
- संयोजन ओवरले ट्री बनाते हैं; अत्यधिक गहराई से बचें (3-4 स्तर पर्याप्त हैं)।
6) बहु-किरायेदारी
दृष्टिकोण:- हार्ड विभाजन: अलग फ़ाइल/फ़ोल्डर प्रति किरायेदार.
- पैरामेटराइजेशन: एक टेम्पलेट + मान प्रति किरायेदार।
- विरासत में मिली नीतियां: संसाधन/कोटा सीमा, एसएलओ, लॉग प्रतिधारण।
- महत्वपूर्ण: सुरक्षा सीमाएं (रहस्य/कुंजी) किरायेदारों के बीच नहीं बहनी चाहिए।
7) रहस्य और सुरक्षा
रहस्यों को स्पष्ट रूप से विरासत में न लें। इनहेरिटेड संदर्भ: 'Seters Ref', 'vaultPath'।
केएमएस/वॉल्ट/एसओपीएस: Git, कुंजी - आउट में गोपित मान भंडारित करें।
जिम्मेदारी साझा करें: मंच पथ और नीतियों, सेवा टीम का प्रबंधन करता है - आपको वास्तव में क्या चाहिए।
नीतियां: सीआई जांच में 'प्लेनटेक्स्ट' रहस्यों को प्रतिबंधित करें।
रोटेशन: "ओवरराइट डाउन" न करें - उर्फ/अमूर्त ('db/प्राथमिक/पासवर्ड @ 2025-Q4') का उपयोग करें।
वॉल्ट लिंक उदाहरण
yaml db:
host: postgres. service user: app passwordFrom:
vaultPath: "kv/prod/app-db"
key: "password" # secret is taken at the deploy stage, not stored in files
8) वर्शनिंग और माइग्रेशन
कॉन्फ़िगरेशन मॉड्यूल संस्करण: 'लॉगिंग @ 2। 3. 1`.
स्कीमा के लिए changelog: jsonnet/ytt/custom स्क्रिप्ट का उपयोग करके माइग्रेशन।
सुरक्षित रोलबैक के लिए अप/डाउन माइग्रेशन।
लंबी शाखाएँ: बहाव से बचें; नियमित रूप से कटार आधार पर ओवरले करता है।
9) उपकरण और व्यवहार
9. 1 कुबर्नेट्स
Kustomize (ओवरले): 'बेस्स '/' रिसोर्सेज', 'PatesterMerge '/' PatessyJSON6902' के माध्यम से प्राकृतिक विरासत मॉडल।
हेल्म (मूल्य): पदानुक्रम 'values। yaml '+' -- set '(लेकिन CI में ओवरराइड के साथ सावधान रहें)।
Kyverno/OPA: राजनेता "सुरक्षा जाल" के रूप में।
Kustomize उदाहरण:yaml overlays/prod/kustomization. yaml resources:
-../../base patchesStrategicMerge:
- patch-resources. yaml commonLabels:
env: prod
9. 2 टेराफॉर्म
+ 'चर मॉड्यूल। tf 'एक अनुबंध के रूप में।
गणना किए गए मानों के लिए 'लोकल्स', 'ओवरराइड' नो फ़ाइलें - निर्देशिका परतों और कार्यस्थान ('कार्यस्थान') का उपयोग करें।
स्रोत क्रम: 9. 3 एनीबल चर का एक स्पष्ट पदानुक्रम (आरोही प्राथमिकता में): भूमिका डिफ़ॉल्ट <इन्वेंट्री <<अतिरिक्त vars। विरासत के लिए - संरचना 'समूह _ vars/{ env }/{ क्षेत्र} .yml'। 9. 4 Jsonnet/ytt समृद्ध रचना, कार्य और "प्रमुख-इरादे" ('ओवरले। बदलें ',' ओवरले। विलय करें ')। 10) अनुबंध और बैटरी सीमा प्लेटफ़ॉर्म टीम-स्कीमा, नीतियों, आधार मूल्यों और तर्क को परिभाषित करता है। उत्पाद टीमें: केवल अनुबंध के भीतर ओवरले। एसआरई/सुरक्षा: ऑडिट, सत्यापन, हस्ताक्षर, प्रवर्तन। 11) CI/CD и GitOps 1. लिंट (प्रारूप, अज्ञात कुंजियों का निषेध)। 2. मान्य (JSON स्कीमा/OpenAPI)। 3. ड्राई-रन/रेंडर (पतवार टेम्पलेट/kustomize बिल्ड)। 4. नीति जाँच (OPA/Kyverno/Conftest)। 5. डिफ बनाम टारगेट क्लस्टर (kubectl diff/ArgoCD diff)। 6. प्रगतिशील वितरण: सीमित यातायात के साथ कैनरी ओवरले। 7. कलाकृतियों का हस्ताक्षर (Cosign, SLSA सत्यापन)। 12) अवलोकन और डिबगिंग प्रोवेंस ट्रेस: किसने क्षेत्र में योगदान दिया और कब, किस परत से अंतिम मूल्य आया। दृश्य विलय करें: "जीतने" कुंजियों की एक रिपोर्ट। सक्रिय विन्यास का रनटाइम- निर्यात (गुप्त मास्किंग के साथ समापन बिंदु '/कॉन्फिग '). बहाव अलर्ट: घोषित और वास्तविक के बीच विसंगतियां। 13) एंटी-पैटर्न स्पष्ट पूर्वता नियमों के बिना "जादू"। गहरी श्रृंखलाएं (> 4-5 परतें): संज्ञानात्मक भार बढ़ाएं। विरासत में मिली फ़ाइलों में रहस्य। सीआई में '-- सेट' के माध्यम से छिपा हुआ ओवरराइड. स्कीमा की कमी और प्रतिपादन परीक्षण। 14) कार्यान्वयन चेकलिस्ट 15) एफएक्यू प्रश्न: यह कैसे समझें कि परत बहुत गहरी है? A: यदि आपको पैरामीटर को बदलने के लिए> 3 फ़ाइलें और "स्क्रॉल"> 2 अमूर्त स्तर खोलने की आवश्यकता है, तो संरचना को संशोधित करें। प्रश्न: परस्पर विरोधी सरणियों का क्या करना है? A: स्पष्ट रणनीतियाँ दर्ज करें: 'बदलें', 'जोड़ें', ' By (कुंजी)', 'PatchBy (नाम)' - और उन्हें प्रलेखन में ठीक करें। प्रश्न: क्या रहस्य विरासत में मिल सकते हैं? A: नहीं। गुप्त दुकानों और पहुंच नीतियों के लिए केवल लिंक (URI/refs) विरासत में मिलते हैं। प्रश्न: विरासत का परीक्षण कैसे करें? A: प्रमुख ओवरले संयोजनों के लिए "स्लाइस" शूट करें और सुनहरी फाइलों के साथ जांच करें; प्रति पीआर सीआई में दौड़ प्रतिपादन। परिशिष्ट ए: मिनी स्पेक विलय 'स्केलर': अंतिम-राइट-विन्स 'ऑब्जेक्ट्स': कुंजी द्वारा गहरी-विलय परिशिष्ट बी: उदाहरण अंतिम फ़ाइल की प्राथमिकता 'values' है। prod। yaml '। 1. स्पष्ट मॉडल और प्राथमिकताएं, 2. सत्यापन योजनाएं और स्वतंत्र ओवरले, 3. वारिसों के लिए इनकार करना, 4. ड्राई-रन, पॉलिसी-चेक और डिफ्यूज़के साथ GitOps-पाइपलाइन, 5. अंतिम मूल्यों की उत्पत्ति की अवलोकन। इन सिद्धांतों का पालन करके, आपको सभी वातावरण और टोपोलॉजी के लिए अनुमानित, स्केलेबल और सुरक्षित कॉन्फ़िगरेशन मिलते हैं।hcl module "svc" {
source = "./modules/svc"
replicas = var. env == "prod"? 4: 2 logging = local. logging_base
}
अनुमत:
विशेष नोड लेबल:
B.1 हेल्म मूल्य (आधार पर प्रोड)
रेंडरिंग कमांड:
yaml values. base. yaml replicas: 2 resources:
requests:
cpu: "100m"
memory: "128Mi"
logging:
level: info
values. prod. yaml replicas: 4 logging:
level: warn
helm template svc chart/ -f values. base. yaml -f values. prod. yamlB.2 Kustomize ओवरले
yaml base/deployment. yaml apiVersion: apps/v1 kind: Deployment metadata:
name: app spec:
replicas: 2
overlays/prod/patch. yaml apiVersion: apps/v1 kind: Deployment metadata:
name: app spec:
replicas: 4B.3 Anible vars
group_vars/prod. yml # values of prod host_vars/prod-eu-1. yml # clarifications for extra vars host in CLI have highest priorityसारांश
कॉन्फ़िगरेशन विरासत एक अनुबंध + मर्ज एल्गोरिथ्म + सुरक्षा नीति है, न कि केवल "कई YAML फ़ाइलें। "सफलता द्वारा परिभाषित किया गया है: