ارث از تنظیمات

1) چرا به وراثت پیکربندی نیاز دارم ؟

• استفاده مجدد از مقادیر مشترک (ورود به سیستم، retrays، timeouts).
• به اشتراک گذاشتن مسئولیت: پلت فرم مجموعه سیاست های اساسی، دستورات خدمات - تنها انحراف.
• اجتناب از تکرار و کاهش خطر سوء تفاهم.
• سرعت بخشیدن به انتشار: تغییرات به طور پیش فرض از درخت پخش می شوند.
• پشتیبانی از چند محیط و چند اجاره با یک رویکرد واحد.

2) الگوهای ارث

2. 1 سلسله مراتبی (پدر و مادر → فرزند)

Base (global) → environment (prod/stage/dev) → region/cluster → service → instance.
ساده و شفاف، اما می تواند منجر به زنجیره عمیق و اشکال زدایی پیچیده شود.

2. 2 لایه ای (پایه/پوشش)

لایه پایه + مجموعه پوشش (ویژگی-x، منطقه-اتحادیه اروپا، سخت شدن امنیت).
با GitOps و Kustomize به خوبی کار می کند ؛ پوشش ها مستقل و ترکیبی هستند.

2. 3 کامپوزیت (ماژول ها/بسته ها)

پیکربندی از ماژول ها جمع آوری شده است: «logging @ v2»، «metrics @ v1»، «http @ v3».
نسخه ماژول، سازگاری معنایی، وابستگی های صریح.

2. 4 سیاست به عنوان کد

محدود کننده ها و ثابت های پایه (OPA/Rego, Kyverno, Conftest)

ارزش ها خودشان به ارث برده نمی شوند، بلکه قوانین برای پذیرش آنها است.

3) الگوریتم های ادغام و اولویت ها

1. ترتیب منابع: از چپ به راست (پایه ENV منطقه سرویس).

• اسکالر: «آخرین نوشته برنده».
• شیء: ادغام بازگشتی روی کلیدها.

• 'اضافه کردن '/' آماده'
• 'uniqueBy (کلید)' (تنظیم شده توسط کلید)
• 'patch' (یافتن آیتم با 'نام' و ادغام جزئی).
• 3. کلیدهای رزرو شده (به عنوان مثال، '_ merge: replace '/' _ merge: deep' در سطح گره).

• Startup flags/ENV variables> runtime secrets> فایلهای روی دیسک> مقادیر پیشفرض در کد.

نمونه ای از ادغام 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: types, required fields, enum, patterns, constraints ('minimum', 'format', 'patternProperties').
نسخه بندی طرح (semver): عمده - شکستن، جزئی - زمینه های جدید، پچ - رفع.
چک های قبل از ادغام و بعد از ادغام: اعتبار هر دو قطعه و نتیجه.
پیش فرض ها: در سطح طرح قرار دهید (پیش نویس 07 + از «پیش فرض» پشتیبانی می کند).

5) محیط و ماتریس استقرار

• env: dev، test، stage، prod region: eu-central-1، us-east-1 tier: batch، realtime، مستاجر داخلی: A/B/C (برچسب سفید، B2B)
• ترکیبات درخت پوشش را تشکیل می دهند ؛ اجتناب از عمق بیش از حد (3-4 سطح کافی است).

6) چند اجاره ای

• تقسیم سخت: فایل ها/پوشه های جداگانه برای هر مستاجر.
• پارامتر سازی: یک قالب + مقادیر هر مستاجر.
• سیاست های ارثی: محدودیت منابع/سهمیه، SLO، حفظ ورود به سیستم.
• مهم: مرزهای امنیتی (اسرار/کلید) نباید بین مستاجران جریان یابد.

7) اسرار و امنیت

اسرار را صریحا به ارث نبرید. منابع موروثی: 'secretRef', 'vaultPath'.
KMS/Vault/SOPS: ذخیره مقادیر رمزگذاری شده در Git، کلیدهای خارج.
به اشتراک گذاشتن مسئولیت: پلت فرم مدیریت مسیرها و سیاست ها، تیم خدمات - آنچه شما واقعا نیاز دارید.
سیاست ها: اسرار «متن اصلی» را در چک های CI ممنوع کنید.
چرخش: «بازنویسی نکنید» - از نام مستعار/انتزاع استفاده کنید («db/primary/password @ 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) نسخه و مهاجرت

نسخه های ماژول پیکربندی: 'logging @ 2. 3. 1`.
تغییرات برای طرحوارهها: مهاجرت با استفاده از jsonnet/ytt/دستنوشتههای سفارشی.
مهاجرت بالا/پایین برای بازگشت امن.
شاخه های طولانی: جلوگیری از رانش ؛ به طور منظم پوشش سیخ به پایه.

9) ابزار و شیوه

9. 1 کوبرنتیز

Kustomize (پوشش): مدل ارث طبیعی از طریق «پایگاه »/« منابع»، «تکه های استراتژیک ادغام »/« تکه های JSON6902».
هلم (مقادیر): مقادیر سلسله مراتبی. yaml '+' -set '(اما در CI مراقب باشید).
Kyverno/OPA: سیاستمداران به عنوان «شبکه های ایمنی».

yaml overlays/prod/kustomization. yaml resources:
-../../base patchesStrategicMerge:
- patch-resources. yaml commonLabels:
env: prod

9. 2 زمینی

+ 'متغیرها ماژول. به عنوان یک قرارداد.
'locals' برای مقادیر محاسبه شده، 'override' no files - use directory layers and workspaces ('workspaces').
ترتیب منبع: پیشفرض <tfvars-files <'-var '/' -var-file'.

hcl module "svc" {
source = "./modules/svc"
replicas = var. env == "prod"? 4: 2 logging = local. logging_base
}

9. 3 امکان پذیر است

یک سلسله مراتب روشن از متغیرها (در اولویت صعودی): پیش فرض های نقش <موجودی group_vars <host_vars <وارهای اضافی.
برای وراثت - ساختار 'group _ vars/{ env }/{ region} .yml'.

9. 4 Jsonnet/ytt

ترکیب غنی، توابع و «اهداف کلیدی» («پوشش»). جایگزین '،' پوشش. ادغام ').

10) قراردادها و محدودیت های باتری

تیم پلت فرم - طرح، سیاست ها، ارزش های پایه و منطق ادغام را تعریف می کند.
تیم های محصول: فقط در قرارداد پوشش داده می شود.
SRE/Security: ممیزی، اعتبار سنجی، امضا، اجرای.

11) CI/CD и GitOps

1. Lint (فرمت، ممنوعیت کلیدهای ناشناخته).

2. اعتبارسنجی (JSON Schema/OpenAPI).

3. اجرای خشک/رندر کردن) ساخت قالب فرمان/kustomize (.

4. بررسی سیاست (OPA/Kyverno/Conftest).

5. تفاوت در مقابل خوشه هدف (تفاوت kubectl/ArgoCD).

6. تحویل پیشرفته: پوشش قناری با ترافیک محدود.

7. امضای مصنوعات (Cosign، گواهی SLSA).

12) قابلیت مشاهده و اشکال زدایی

ردیابی منشأ: چه کسی به میدان کمک کرد و چه زمانی، از کدام لایه ارزش نهایی به دست آمد.
ادغام تجسم: یک گزارش از «برنده» کلید.
Runtime-export پیکربندی فعال (نقطه پایانی/پیکربندی با پوشش مخفی).
هشدار رانش: اختلاف بین اعلام و واقعی است.

13) ضد الگوهای

«سحر و جادو» بدون قوانین تقدم صریح.
زنجیره های عمیق (> 4-5 لایه): افزایش بار شناختی.

اطلاعات محرمانه در فایل های ارثی

از طریق «--set» در CI پنهان شده است.
عدم وجود طرح و تست های رندر.

14) چک لیست پیاده سازی

• تعریف مدل (سلسله مراتب/لایه ها/ترکیب).
• سفارش ادغام و استراتژی ها را بر اساس نوع تنظیم کنید.
• انتشار طرح و نسخه.
• اسرار را به اشتراک بگذارید (فقط لینک/refs).
• اضافه کردن سیاست چک و امضاهای مصنوعی.
• فعال کردن خشک اجرا، منتشر، و تجسم منبع.
• صادرات پیکربندی فعال در زمان اجرا.
• پیکربندی نسخه های پیشرو برای تغییرات پیکربندی.

15) سوالات متداول

س: چگونه می توان فهمید که لایه خیلی عمیق است ؟

A: اگر شما نیاز به باز کردن> 3 فایل و «scroll»> 2 سطح انتزاع برای تغییر پارامتر، ساختار را تجدید نظر کنید.

س: با آرایههای متناقض چه باید کرد ؟

A: استراتژی های صریح را وارد کنید: «جایگزین»، «اضافه کردن»، «منحصر به فرد توسط (کلید)»، «patchBy (نام)» - و آنها را در مستندات ثابت کنید.

س: آیا می توان اسرار را به ارث برد ؟

پاسخ: نه. فقط لینک ها (URI/refs) به فروشگاه های مخفی و سیاست های دسترسی به ارث برده می شوند.

س: چگونه ارث را آزمایش کنیم ؟

A: ساقه «برش» برای ترکیب کلیدی پوشش و بررسی با فایل های طلایی ؛ ارائه مسابقه در CI در PR.

ضمیمه A: ادغام مینی اسپک

'scalars': آخرین نوشتن برنده

'objects': ادغام عمیق با کلید

• «تعویض» پیشفرض

• «ظاهر»
• 'uniqueBy (کلید)'
• 'patchBy (key)' با ادغام عنصر بازگشتی

• '_ merge:' deep 'را جایگزین کنید
• استراتژي. array: replace 'append' uniqueBy (name) | patchBy (name) '

ضمیمه B: مثال ها

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

اولویت آخرین پرونده «values» است. دانلود کنید. «يامل».

B.2 پوشش های سفارشی

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: 4

B.3 نسخه های غیر ممکن

group_vars/prod. yml # values of prod host_vars/prod-eu-1. yml # clarifications for extra vars host in CLI have highest priority

خلاصه

1. مدل روشن و اولویت ها،

2. طرح های اعتبار سنجی و پوشش های مستقل،

3. امتناع از به ارث بردن اسرار

4. GitOps خط لوله با خشک اجرا، سیاست چک و منتشر،

5. قابل مشاهده بودن منشأ مقادیر نهایی.

با پیروی از این اصول، تنظیمات قابل پیش بینی، مقیاس پذیر و ایمن برای همه محیط ها و توپولوژی ها دریافت می کنید.