پیکربندی به عنوان داده

(بخش: معماری و پروتکل ها)

1) ایده و تفاوت از «پیکربندی به عنوان کد»

پیکربندی به عنوان داده (CaD) نمایشی از پیکربندی به عنوان یک مدل تایپ شده، اعلانی، معتبر، مستقل از کد اجرایی است و به عنوان داده های تجاری مدیریت می شود: با نسخه ها، طرح ها، مهاجرت ها، ممیزی ها و تست ها.
بر خلاف «پیکربندی به عنوان کد»، جایی که منطق تولید پیکربندی ها در قالب ها/اسکریپت ها زندگی می کند، CaD ضروری را از منبع حقیقت حذف می کند: بدون حلقه ها، شرایط و منطق پنهان در داخل پیکربندی ها. همه - داده های پاک + طرح دقیق + سیاست ها.

اهداف کلیدی: پیش بینی، توانایی تفاوت، تغییر ایمنی، بازگشت سریع، توانایی تحویل به تدریج و به طور خودکار کنترل انطباق.

2) اصول «پیکربندی به عنوان داده ها»

1. اعلام و عدم ابهام: ما وضعیت مطلوب را توصیف می کنیم، نه مراحل دستیابی.
2. نوع ایمنی و طرح: JSON Schema/Protobuf/Avro/OpenAPI برای قراردادهای سخت.
3. تغییرناپذیری Artifact: عکس های پیکربندی نسخه بندی شده و امضا می شوند (منبع).
4. اعتبار سنجی و سیاست: در خط لوله - نحو → معناشناسی → سیاست به عنوان کد (OPA، قوانین).
5. مشاهده از configs: اثر انگشت نسخه در سیاهههای مربوط/متریک/آثار.
6. به اشتراک گذاری مسئولیت: داده ها (پیکربندی)، طرح (قرارداد)، سیاست (محدودیت ها)، کنترل کننده (پیاده سازی).
7. مدولار و لایه: جهانی، منطقه ای، tenant-، محصول، سطح ویژگی، با ادغام قابل پیش بینی و اولویت.

3) شبیه سازی پیکربندی: طرح به عنوان قرارداد

خانواده های نهاد: مسیریابی، محدودیت ها، فیش فلاگ ها، تعرفه ها، بخش های AB، سهمیه ها، قوانین ریسک، تنظیمات مالی و غیره

انواع: enum/oneOf صریح، محدوده ها، regex، یکپارچگی ارجاعی (ref/ID).
versioning طرحواره: 'v1 → v1beta2 → v2' (طرح رد، مهاجرت).
پیش فرض/جهش: پیش فرض های امن در مرحله اعتبار سنجی ؛ نظم قطعی کاربرد.
محدودیت ها: محدودیت های کسب و کار (به عنوان مثال، 'rateLimit <= 2000 rps' در مستاجر).

yaml apiVersion: config. example. io/v1 kind: RateLimitPolicy metadata:
scope: tenant:acme spec:
targets:
- service: checkout endpoint: /api/pay method: POST limit:
unit: second value: 500 burst: 200 strategy: tokenBucket

4) لایه ها، ارث، و حل تعارض

Иерархия: «جهانی → منطقه → محیط → مستاجر → محصول → کوهورت → کاربر».
قوانین ادغام: اعلانی - «آخرین برنده» (لغو) یا استراتژیک (ادغام/پچ/جایگزینی در هر زمینه).
اعتبارسنجی در تقاطعها: کلیدهای متضاد را ممنوع میکند، نیاز به لغو صریح دارد.
تجسم پیکربندی مؤثر نهایی مورد نیاز است (پراکندگی قطعی).

5) چرخه عمر پیکربندی (پارادایم GitOps)

1. منبع حقیقت: مخزن با داده + طرح + سیاست.

• بررسی نحو (lint),
• اعتبار سنجی با توجه به طرح،
• بررسی های معنایی/آزمون،
• سیاست به عنوان کد (به عنوان مثال،. OPA/رگو)،
• مهاجرت امن (§ 7 را ببینید)،
• امضا و انتشار عکس فوری.
• 3. ارتقاء: روابط عمومی بین دایرکتوری ها «dev/qa/staging/prod» یا حلقه «ring-0/.../ring-N».
• 4. تحویل: کنترل کننده ها/اپراتورها عکس های تازه را می گیرند، از طریق یک چرخه آشتی اعمال می شوند.
• 5. حسابرسی و برگشت پذیری: همه تغییرات ردیابی می شوند ؛ rollback - برگرداندن commit/rollback snapshot.

6) تحویل و توزیع پیکربندی

استاتیک (pull-on-start): بارگذاری عکس فوری در ابتدا، راه اندازی مجدد برای به روز رسانی.
پویا (تماشا/جریان): etcd/Consul/ZooKeeper، Kubernetes API/CRD، سرویس پیکربندی اختصاصی.
پروتکل ها: gRPC/REST با ETag/If-None-Match، نظرسنجی طولانی/تماشا، عکس های فوری + انتشار افزایشی.
ذخیره سازی: عکس های فوری محلی با TTL و امضا ؛ تغییر اتمی (دو بافر).
توالی: قوی (رهبر/حد نصاب) در مقابل نهایی (لبه/اینترنت اشیا). برای سیستم های بحرانی - quorum + RA.
نورد جهانی: توسط مناطق/حلقه (حلقه استقرار)، با محدودیت مناطق همزمان.

7) پیکربندی مهاجرت داده ها

• گسترش: ما زمینه های جدید را با پیش فرض معرفی می کنیم، بدون شکستن مصرف کنندگان.
• مهاجرت: backfills/مبدل (اسکریپت ارائه دهنده مهاجرت، idempotency).
• قرارداد: زمانی که تمام کنترل کننده ها در نسخه جدید طرح هستند، منسوخ را حذف کنید.
• قانون سازگاری: منطق قدیمی، جدید و قدیمی را در حال گذار درک می کند.

8) سیاست، انطباق و امنیت

Policy-as-code: Rego/Conftest/OPA Gatekeeper - ممنوعیت مقادیر خطرناک (به عنوان مثال، «timeout = 0»، غیرفعال کردن TLS، سهمیه های نامحدود).
RBAC/ABAC: چه کسی می تواند بخش ها و لایه ها را تغییر دهد.
چهار چشم برای بخش های حساس (پرداخت/محدودیت).
اسرار: ما از پیکربندی های مشترک (KMS، Vault، SOPS)، در پیکربندی - فقط لینک ها/مراجع نگهداری می کنیم.
امضا و اعتماد: تأیید تحویل (گواهینامه ها)، ممنوعیت عکس های بدون امضا.
Sanitizing: حفاظت در برابر تزریق در قالب ها و در طول رندر.

9) قابلیت مشاهده، SLO و مدیریت ریسک

پیکربندی برچسب ها در تله متری: '{config _ digest, config_version, ring, scope}' در سیاهههای مربوط/متریک/آهنگ.
معیارهای طلایی اسلحه پیکربندی: زمان برنامه، میزان موفقیت، تعداد رول بک ها، زمان سازگاری.
Gates when rolling configs: همانطور که برای کد - مراحل canary و توقف خودکار برای تخریب SLO.
Dogfooting: ابتدا کوهورت داخلی/بتا.

10) Hot-reload، transactionality و امنیت برنامه

Atomic switch: یک پیکربندی جدید در حافظه در حال آماده سازی است.
خشک اجرا: ما اعتبار و شبیه سازی برنامه (از جمله درگیری میدان/سیاست).
شکست جزئی: یک استراتژی همه یا هیچ برای اجزای مرتبط یا یک توصیف واضح از تخریب.
Backoff/Retry: on application error - بازگشت امن و تکرار با تاخیر نمایی.

11) Ficheflags به عنوان یک زیر مجموعه از تنظیمات

Ficheflags داده های پیکربندی با سیاست های خاص: هدف قرار دادن بخش, محدودیت شعاع گنجاندن, کشتن سوئیچ.
الزامات: هدف قطعی معناشناسی، حسابرسی، پیش فرض های امن، سازگاری نسخه مشتری/سرور.

12) ابزار و رسانه

رسانه ها: JSON/YAML/TOML/Protobuf/Avro (برای تحویل شبکه - اغلب Protobuf/JSON).
رندر/ترکیب: Kustomize/Helm/Jsonnet (مانند ژنراتور، اما نتیجه داده های پاک است).
ذخیره سازی/اتوبوس: Git، ثبت OCI (به عنوان مصنوعات)، ذخیره سازی S3-compatible، etcd/Consul/KV.
کنترل کننده ها: اپراتورهای اختصاصی، عوامل GitOps، ارائه دهندگان پیکربندی Sidecar.
سیاست: OPA/Rego، مکانیسم های مشابه Kyverno.

13) چک لیست

طراحی سایت

• طرح می آید برای اولین بار (JSON طرح/پروتو)، انواع/محدودیت/پیش فرض شرح داده شده است.
• نسخه بندی طرح و مهاجرت مستند شده است.
• سلسله مراتب لایه و استراتژی ادغام تعریف و تست شده است.

خط لوله

• Lint → schema-validate → آزمونهای معنایی → policy-check → sign → publish.
• تجسم خشک و موثر برای داوران.
• Canary rolling of configs with auto-gates via SLO.

پیشنهاد

• یک 'config _ digest' در سیاههها/معیارها وجود دارد.
• بازگشت پیکربندی - همان دکمه به عنوان سپرده کد.
• پیکربندی عکس های فوری/پشتیبان گیری و تاریخچه حسابرسی در دسترس و تایید شده است.

14) ضد الگوهای مکرر

ضروری در پیکربندی: شرایط/اسکریپت/قالب با منطق معتبر و غیر قابل پیش بینی نیست.
مخلوط اسرار و تنظیمات به اشتراک گذاشته شده در یک فایل/مخزن.
ادغام مبهم: مشخص نیست که خط پایین از کجا آمده است.
فقدان یک طرح: «همه چیز معتبر است» ⇒ اشکالات در فروش.

ویرایش جهانی حلقه/قناری رایگان: تخریب فوری برای همه

رانش محیط اطراف: ویرایش دستی در زمان اجرا گذشته از منبع حقیقت است.
TTL های طولانی در حافظه پنهان پیکربندی بدون مکانیسم غیرفعال اجباری.

15) سناریوها (طرح ها)

A. تنظیم محدودیت های ترافیکی بر اساس منطقه

1. PR با تغییرات «RateLimitPolicy» به «ring-0» (مشتریان داخلی).
2. AutoChecks طرح/سیاست (2k rps ≤ حد).
3. ارتقاء در «حلقه-1» (5٪ از کاربران)، نظارت بر p95/میزان خطا.
4. گسترش به «حلقه-N»، رفع یک عکس فوری، بسته شدن یک کار.

B. به روز رسانی برنامه تعرفه (تنظیمات مالی)

معناشناسی قوی و سیاست های کسب و کار: بررسی دو، ارتقاء دو مرحله ای، ورود به پنجره زمان، حسابرسی و قابلیت بازگشت فوری.

C. پرچم پیکربندی fifflag پرداخت جهانی با سوئیچ kill-switch: هدف قرار دادن «کارکنان → بتا → 10٪ → 100٪»، توقف خودکار زمانی که نرخ پرداخت موفق زیر آستانه است.

16) ادغام با صفر خرابی و تحویل مترقی

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

17) خلاصه

رویکرد پیکربندی به عنوان داده، تنظیمات را از فایل های شکننده به مدل های دامنه قوی با قراردادهای روشن، اعتبار سنجی و سیاست ها تبدیل می کند. این اساس نورد قابل پیش بینی، آزمایش های ایمن و واکنش سریع به حوادث است. طرح های رسمی، اسرار جداگانه، پیاده سازی GitOps و pooches config canary - و پیکربندی متوقف خواهد شد به یک خطر، تبدیل شدن به یک دارایی پلت فرم مدیریت شده است.