Moslamalarni meros qilib olish

1) Nega konfiguratsiyalarni meros qilib olish kerak

• Umumiy qiymatlarni qayta ishlatish (loging, retray, taymaut).
• Mas’uliyatni baham ko’rish: platforma asosiy siyosatni belgilaydi, xizmatlar buyruqlari faqat chetga chiqishdir.
• Bir-birini takrorlamaslik va sinxronizatsiya xavfini kamaytirish.
• Relizlarni tezlashtirish: andoza oʻzgarishlar yogʻochdan pastga uzatiladi.
• Ko’p muhitni va ko’p tenantlikni yagona yondashuv bilan qo’llab-quvvatlash.

2) Meros namunalari

2. 1 Ierarxik (ota-ona → bola)

Baza (global) → atrof-muhit (prod/stage/dev) → mintaqa/klaster → servis → instans.
Oddiy va shaffof, ammo «chuqur zanjirlar» va murakkab tuzatishlarga olib kelishi mumkin.

2. 2 Qatlamli (base/overlays)

Asosiy qatlam + overleylar to’plami (feature-x, region-eu, security-hardening).
GitOps va Kustomize bilan yaxshi mos keladi; overleylar mustaqil va kompozitsion.

2. 3 Kompozitsion (modullar/paketlar)

Moslamalar’logging @v2’,’metrics @v1’,’http @v3’modullaridan yigʻiladi.
Modullar versiyalarini boshqarish, semantik muvofiqlik, aniq qaramliklar.

2. 4 Qiymatlardan yuqori siyosat (Policy-as-Code)

Asosiy «cheklovchilar» va invariantlar (OPA/Rego, Kyverno, Conftest).
Maʼnolar oʻzidan emas, balki ularning maqbullik qoidalaridan kelib chiqadi.

3) Qo’shilish algoritmlari va ustuvorliklari

1. Manbalar tartibi: chapdan o’ngga (base ← env ← region ← service ← instance).

• Skalyar: «oxirgi g’alaba» (last-write-wins).
• Obyekt: kalitlar bo’yicha rekursiv merj.

• `append`/`prepend`
• ’uniqueBy (key)’ (kalit boʻyicha koʻp)
• ’patch’ (’name’elementini qidirish va qisman merj).
• 3. Zaxiralangan kalitlar (masalan, tugun darajasida’_ merge: replace ’/’ _ merge: deep’).

• Ishga tushirish bayroqlari/ENV oʻzgaruvchilari> rantaym sirlari> diskdagi fayllar> andoza koddagi qiymatlar.

YAML-merj misoli

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) Sxemalar va validatsiya

Sxemaning mavjudligi - xavfsiz meros bo’lishning majburiy shartidir.

JSON Schema/OpenAPI: turlari, majburiy maydonlari, enum, patternlari, cheklovlari (’minimum’,’format’,’patternProperties’).
Sxemalar versiyasi (semver): major - sinuvchi, minor - yangi maydonlar, patch - fikslar.
Pre-merge va Post-merge tekshiruvlari: parcha va natijalarni tasdiqlash.
Defoltlar: sxema darajasida belgilash (draft-07 +’default’ni qo’llab-quvvatlaydi).

5) Atrof-muhit va joylashtirish matritsasi

• env: dev, test, stage, prod region: eu-central-1, us-east-1 tier: batch, realtime, internal tenant: A/B/C (white-label, B2B)
• Kombinatsiyalar overleylar daraxtini hosil qiladi; ortiqcha chuqurlikdan qoching (3-4 darajalar etarli).

6) Ko’p tenantlik

• Qattiq boʻlish: tenant uchun alohida fayl/jildlar.
• Parametrlash: bitta shablon + values per tenant.
• Meros siyosati: resurslar/kvotalar limitlari, SLO, loglar retenshni.
• Muhimi: xavfsizlik chegaralari (sirlar/kalitlar) tenantlar orasidan chiqmasligi kerak.

7) Sirlar va xavfsizlik

Sirlarni oshkora meros qilib olmang. ’secretRef’,’vaultPath’havolalari meros qilib olingan.
KMS/Vault/SOPS: shifrlangan qiymatlarni Git’da saqlash, kalitlarni tashqarida saqlash.
Mas’uliyatni baham ko’ring: platforma yo’l va siyosatni boshqaradi, xizmat ko’rsatish jamoasi - haqiqatan ham kerak bo’lgan narsani.
Siyosat: CI tekshiruvlarida’plaintext’sirlarini taqiqlash.
Rotation: «pastga yozmang» - alias/abstraksiyalardan foydalaning (’db/primary/password @ 2025-Q4’).

Vault havolasi bilan misol

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) Versiyalash va migratsiya

Moslamalar versiyasi:’logging @ 2. 3. 1`.
Sxemalar uchun Changelog: jsonnet/ytt/xususiy skriptlar yordamida koʻchirish.
Xavfsiz orqaga qaytish uchun ikki yo’nalishli migratsiya (up/down).
Uzun shoxlar: driftdan qochish; bazaga muntazam ravishda overleylar olib borish.

9) Asboblar va amaliyotlar

9. 1 Kubernetes

Kustomize (overlays):’bases ’/’ resources’,’patchesStrategicMerge ’/’ patchesJSON6902’orqali meros olishning tabiiy modeli.
Helm (values): iyerarxiya’values. yaml’+’--set’(lekin CI’dagi qayta belgilashlarga ehtiyot boʻling).
Kyverno/OPA: siyosatchilar «sug’urta to’rlari» sifatida.

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

9. 2 Terraform

Modullar +’variables. tf’kontrakt sifatida.
Hisoblanadigan qiymatlar uchun’locals’,’override’mavjud emas - katalog qatlamlari va ish joylaridan (’workspaces’) foydalaning.
Manba tartibi: andoza <tfvars-fayllar <’-var ’/’ -var-file’.

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

9. 3 Ansible

Oʻzgaruvchilarning aniq ierarxiyasi: role defaults <inventory group_vars <host_vars <extra vars.
Meros uchun’group _ vars/{ env }/{ region} .yml’.

9. 4 Jsonnet / ytt

Boy kompozitsiya, funksiyalar va «kalit niyat» (’overlay. replace`, `overlay. merge`).

10) Kontraktlar va javobgarlik chegaralari

Platforma (platform team): merj sxemasini, siyosatini, asosiy qiymatlarini, mantiqini belgilaydi.
Mahsulot buyruqlari: faqat kontrakt doirasidagi overleylar.
SRE/Xavfsizlik: audit, validatsiya, signatura, enforcement.

11) CI/CD и GitOps

1. Lint (formati, nomaʼlum kalitlarni taqiqlash).

2. Validate (JSON Schema/OpenAPI).

3. Dry-run/Render (helm template/kustomize build).

4. Policy check (OPA/Kyverno/Conftest).

5. Diff vs maqsadli klaster (kubectl diff/ArgoCD diff).

6. Progressive delivery: cheklangan trafikli kanar overleylari.

7. Artefaktlar imzosi (Cosign, SLSA-attestatsiyalar).

12) Kuzatish va sozlash

Kelib chiqish trasi (provenance): maydonni kim va qachon kiritgan, yakuniy qiymat qaysi qatlamdan kelgan.
Merjni vizuallashtirish: «g’olib» kalitlar hisoboti.
Aktiv konfiguratsiyaning Runtime-eksporti (sirlarni yashirgan holda endpoint ’/config’).
Driftga alertlar: deklaratsiya qilingan va amaldagi farqlar.

13) Anti-patternlar

«Sehr» aniq ustuvor qoidalarsiz.
Chuqur zanjirlar (> 4-5 qavat): kognitiv yuklamani oshiradi.
Meros fayllardagi sirlar.
’-set’ orqali CIda yashirin qayta belgilash.
Rendering sxemasi va testlarining yo’qligi.

14) Joriy etish chek-varaqasi

• Modelni aniqlang (ierarxiya/qatlamlar/kompozitsiya).
• Merj tartibi va strategiyalarni turlarga ko’ra belgilang.
• Sxema va versiyani nashr qiling.
• Sirlarni ajrating.
• Policy-checks va artefaktlarning imzolarini qo’shing.
• Dry-run, difflar va kelib chiqish vizualizatsiyasini kiriting.
• Rantaymda aktiv konfiguratsiyani eksport qiling.
• Ilgʻor relizlarni oʻzgartirish uchun moslashtiring.

15) FAQ

Q: Qatlamning juda chuqur ekanligini qanday tushunish mumkin?
A: Agar parametrni oʻzgartirish uchun> 3 faylni ochish va> 2 darajali mavhumlikni «aylantirish» kerak boʻlsa, tuzilmasini qayta koʻrib chiqing.

Q: Ziddiyatli massivlar bilan nima qilish kerak?
A: Aniq strategiyalarni kiriting:’replace’,’append’,’uniqueBy (key)’,’patchBy (name)’va ularni hujjatlarga kiriting.

Q: Sirlarni meros qilib olish mumkinmi?
A: Yo’q. Faqat maxfiy saqlash va foydalanish siyosatiga havolalar (URI/reflar) meros qilib qoldiriladi.

Q: Merosni qanday sinovdan o’tkazish kerak?
A: Asosiy overleys kombinatsiyalari uchun «kesmalar» ni olib tashlang va golden-fayllar bilan tekshiring; har bir PR uchun CIga rendering yuboring.

A ilovasi: Merj mini-speki

`scalars`: last-write-wins

’objects’: deep-merge

• Andoza’replace ’

• `append`
• `uniqueBy(key)`
• ’patchBy (key)’ element rekursiv merjem bilan

• `_merge: replace|deep`
• `_strategy. array: replace|append|uniqueBy(name)|patchBy(name)`

B ilovasi: Misollar

B.1 Helm values (prod ustiga base)

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

Oxirgi faylning ustuvorligi’values. prod. yaml`.

B.2 Kustomize overlays

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 Ansible vars

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

Yakunlar

1. aniq model va ustuvor yo’nalishlar,

2. tasdiqlovchi sxemalar va mustaqil overleylar,

3. sirlarni meros qilib olishdan voz kechish,

4. dry-run, policy-checks va difflar bilan GitOps-payplayn,

5. yakuniy qiymatlarning kelib chiqishi kuzatilganligi.

Ushbu printsiplarga amal qilib, siz har qanday muhit va topologiyalar uchun oldindan aytib bo’ladigan, ko’paytiriladigan va xavfsiz konfiguratsiyalarni olasiz.