به گزارش از وبسایت cncf 🚀

تحویل نرم‌افزار مدرن امروز تنها به کد برنامه محدود نمی‌شود؛ بلکه پلتفرمی که آن را اجرا می‌کند نیز نقش تعیین‌کننده‌ای دارد. این مطلب طراحی یک پلتفرم توسعه‌دهنده داخلی (IDP) را شرح می‌دهد که بر پایه ابزارهای اکوسیستم Kubernetes و CNCF ساخته شده و نشان می‌دهد چگونه مفاهیمی مانند زیرساخت به‌عنوان کد (IaC)، GitOps و خطوط لوله‌ای که امنیت را در اولویت قرار می‌دهند، می‌توانند در یک پلت‌فرم منسجم و عملیاتی گردآوری شوند. ⚙️

در برخی پیاده‌سازی‌ها از AKS مدیریت‌شده استفاده شده است، اما الگوهای معماری مطرح‌شده به‌طور یکسان برای هر توزیع سازگار با CNCF قابل اعمال هستند. سیستم‌های توزیع‌شده مدرن معمولاً با چالش‌هایی روبه‌رو می‌شوند که انگیزه طراحی این پلتفرم بوده‌اند: عدم‌یکنواختی استقرار بین محیط‌ها به‌دلیل فرآیندهای دستی، فقدان نسخه‌سازی زیرساخت و کنترل دریفت که منجر به اختلاف وضعیت محیط‌ها می‌شود، اسرار رمزنگاری‌شده یا مدیریت‌نشده در خطوط لوله CI/CD و استراتژی‌های مقیاس ناکارآمد که هزینه‌های غیرضروری ایجاد می‌کنند. 🔍

اصول طراحی این پلتفرم با مجموعه‌ای از مبانی همسو با CNCF تعیین شده که هر تصمیم معماری را هدایت می‌کنند:

• زیرساخت اعلامی — همه منابع باید در کنترل نسخه باشند و قابل تکرار باشند.

• استقرار مبتنی بر GitOps با استفاده از Argo CD — Git تنها منبع حقیقت برای خوشه است.

• زیرساخت‌های تغییرناپذیر و بارهای کاری کانتینری — هیچ تغییر دستی در سیستم‌های در حال اجرا پذیرفته نمی‌شود.

• امنیت از ابتدا — مدل‌سازی تهدید در زمان طراحی، کنترل در CI/CD و حفاظت در زمان اجرا.

• قابلیت مشاهده به‌عنوان یک قابلیت پایه‌ای پلتفرم، نه یک ماژول اختیاری پس از استقرار.

• جداسازی نگرانی‌ها از طریق طراحی مدولار در لایه‌های زیرساخت، پلتفرم و برنامه. 🔐

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

لایه زیرساخت مسئول تهیه تمامی منابع ابری با Terraform است که به ماژول‌های قابل‌استفادهٔ مجدد تقسیم شده‌اند، مانند: شبکه‌های مجازی (VNet)، زیرشبکه‌ها و گروه‌های امنیت شبکه؛ مدیریت خوشه Kubernetes؛ رجیستری کانتینر؛ و هویت، تنظیمات دسترسی و فروشگاه‌های مخفی. ☁️

لایه پلتفرم بر ابزارهای اکوسیستم Kubernetes و CNCF استوار است و به‌صورت اعلامی در مخزن جداگانه یا در دایرکتوری‌های مشخص نصب و مدیریت می‌شود. اجزای کلیدی شامل Argo CD برای کنترل GitOps، Istio به‌عنوان service mesh برای کنترل ترافیک و mTLS و قابلیت مشاهده سطح سرویس، Prometheus برای جمع‌آوری معیارها و هشدارها، Grafana برای نمایش داشبوردها، Loki برای تجمع گزارش و Kyverno برای اجرای سیاست‌ها در زمان پذیرش هستند.

لایه کاربردی شامل میکروسرویس‌ها به‌عنوان بارهای کاری کانتینری است که به‌طور مستقل از طریق Git مدیریت می‌شوند: سرویس‌های قابل استقرار مستقل، بسته‌بندی مبتنی بر Helm برای سازگاری محیط‌ها، چرخه عمر استقرار مبتنی بر Git با دنباله حسابرسی کامل و فرایند استقرار انتها به انتها. ✅

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

مرحله 1: پیش‌نیازهای پلتفرم — گردش کار با مجموعه‌ای از اجزای پایه آغاز می‌شود: یک رجیستری تصاویر برای ذخیره مصنوعات نسخه‌شده و امضا شده، یک Backend از راه دور Terraform برای مدیریت دولت و همکاری تیمی، و یک اتصال سرویس امن به ارائه‌دهندهٔ ابر برای اجرای خطوط لوله. 🔗

مرحله 2: خط لوله برنامه — با هر تعهد (commit) به مخزن برنامه، یک خط لوله اجرا می‌شود تا تصویر کانتینری امن، معتبر و قابل استقرار تولید کند. مراحل معمول شامل ساخت و کامپایل کد منبع، تست واحد و ادغام، تحلیل ایستا برای امنیت (SAST)، اسکن آسیب‌پذیری وابستگی با Trivy، ایجاد تصویر کانتینر، امضای تصویر با Cosign برای تضمین یکپارچگی و منشأ، و انتشار تصویر امضا شده در رجیستری است. تنها مصنوعات تأییدشده، نسخه‌گذاری‌شده و تغییرناپذیر وارد پلتفرم می‌شوند.

امضا و تأیید تصویر Cosign:

# مرحله 1: تصویر ظرف را بسازید
- وظیفه: Docker@2
  نمایش نام: "تصویر کانتینر ساخت"
  ورودی ها:
    دستور: ساخت
    مخزن: $(ACR_NAME).azurecr.io/$(IMAGE_NAME)
    برچسب‌ها: $(Build.BuildId)

# مرحله 2: توکن OIDC را از طریق فدراسیون هویت بار کاری واکشی کنید
- وظیفه: AzureCLI@2
  نمایش نام: «واکشی توکن OIDC»
  ورودی ها:
    اشتراک azure: '$(SERVICE_CONNECTION)'
    نوع اسکریپت: bash
    محل اسکریپت: inlineScript
    addSpnToEnvironment: درست است
    inlineScript: |
      echo "##vso[task.setvariable variable=AZURE_FEDERATED_TOKEN;issecret=true]$AZURE_FEDERATED_TOKEN"

# مرحله 3: امضای تصویر با Cosign (بدون کلید از طریق Azure Pipelines OIDC)
- فیلمنامه: |
    علامت نشانه 
      --بله 
      --identity-token=$AZURE_FEDERATED_TOKEN 
      $(ACR_NAME).azurecr.io/$(IMAGE_NAME):$(Build.BuildId)
  displayName: 'Sign Image with Cosign'
  env:
    AZURE_FEDERATED_TOKEN: $(AZURE_FEDERATED_TOKEN)

مرحله 3: خط لوله اعتبارسنجی امنیتی — پیش از هر استقرار یا تغییر زیرساخت، یک خط لوله مخصوص اعتبارسنجی امنیتی وارد عمل می‌شود تا یک مرز اعتماد اضافی ایجاد کند. این خط لوله هم مصنوعات و هم پیکربندی‌های استقرار را تأیید می‌کند: بررسی امضای تصاویر با Cosign، اسکن تصویر با Trivy علیه آستانه‌های شدت تعریف‌شده، و اعتبارسنجی مانیفست‌های Kubernetes با KubeSec برای شناسایی الگوهای پیکربندی ناامن. تنها بارهای کاری‌ای که از هر سه بررسی عبور کنند، برای استقرار پذیرفته می‌شوند. 🔒

مرحله 4: خط لوله تامین زیرساخت — پس از عبور از اعتبارسنجی امنیتی، خط لوله زیرساخت اجرا می‌شود و بنیاد Kubernetes را ایجاد می‌کند: فراهم‌سازی شبکه‌های مجازی، استقرار یک خوشه k8s مدیریت‌شده با استخرهای گره قابل مقیاس خودکار، نصب Argo CD به‌عنوان کنترلر GitOps و بوت‌استرپینگ CD برنامه‌های کاربردی Argo CD و اتصال مخازن زیرساخت Git به Argo CD.

ماژول خوشه Terraform k8s (نمونه پیکربندی):

منبع "azurerm_kubernetes_cluster" "اصلی" {
  name = var.cluster_name
  resource_group_name = var.resource_group_name
  default_node_pool {
    نام = "سیستم"
    auto_scaling_enabled = درست است
    min_count = 2
    max_count = 10
  }
  هویت {
    type = "SystemAssigned"
  }
  شبکه_پروفایل {
    network_plugin = "لاجورد"
    network_policy = "کالیکو"
  }
  key_vault_secrets_provider {
    Secret_rotation_enabled = درست است
  }
}

مرحله 5: مدل استقرار GitOps — پس از تأمین زیرساخت، پلتفرم بر اساس مدل GitOps عمل می‌کند که در آن Git تنها منبع حقیقت است. Argo CD به‌طور مداوم مانیفست‌های Kubernetes و نمودارهای Helm را نظارت و تطبیق می‌دهد؛ تغییرات در Git به‌صورت خودکار روی خوشه‌های زنده اعمال می‌شوند که امکان تطبیق خودکار، بازرسی کامل از طریق تاریخچه Git و بازگشت آسان با گردش‌کار استاندارد Git را فراهم می‌آورد.

نمونه Argo CD Application CRD برای همگام‌سازی خودکار و فعال‌سازی self-heal و prune:

apiVersion: argoproj.io/v1alpha1
نوع: کاربرد
ابرداده:
  نام: microservice-api
  فضای نام: argocd
  برچسب ها:
    app.kubernetes.io/part-of:internal-developer-platform
مشخصات:
  پروژه: پیش فرض
  منبع:
    repoURL: https://github.com/your-org/gitops-repo
    targetRevision: اصلی
    مسیر: apps/microservice-api/overlays/production
  مقصد:
    سرور: https://kubernetes.default.svc
    فضای نام: تولید
  syncPolicy:
    خودکار:
      prune: true # منابع حذف شده از Git را حذف کنید
      selfHeal: true # برگرداندن تغییرات دستی به خوشه
    syncOptions:
      - CreateNamespace=true
      - PrunePropagationPolicy=پیش زمینه
    سعی مجدد:
      حد: 5
      عقب نشینی:
        مدت زمان: 5 ثانیه
        عامل: 2
        حداکثر مدت زمان: 3 متر

مرحله 6: جریان درخواست در زمان اجرا — پس از استقرار، درخواست‌های کاربران خارجی به متعادل‌کنندهٔ بار ابری می‌رسند که ترافیک را به API Gateway یا لایه Ingress هدایت می‌کند. این دروازه URLها و سرویس‌ها را به سرویس‌های مناسب در Kubernetes نگاشت می‌کند، که سپس ترافیک را به Pods سالم برنامه توزیع و پاسخ را تحویل می‌دهند.

امنیت به‌عنوان یک نگرانی فرابخشی در کل چرخهٔ حیات پلتفرم یکپارچه شده است و شامل حفظ یکپارچگی زنجیره تأمین، اجرای سیاست‌ها، حفاظت در زمان اجرا و مدیریت اسرار است. 🔐

1. امنیت زنجیره تأمین — اطمینان از ورود تنها اجزای قابل‌اعتماد به سیستم:

• Trivy برای اسکن تصاویر کانتینر و وابستگی‌ها به‌دنبال آسیب‌پذیری‌های شناخته‌شده است.

• KubeSec مانیفست‌های Kubernetes را بررسی می‌کند تا پیکربندی‌های ناامن را در آغاز چرخه عمر شناسایی کند.

• Cosign امضای رمزنگاری و تأیید تصاویر را فراهم می‌کند و با استفاده از امضای بدون کلید از طریق OIDC یکپارچگی و منشأ را تضمین می‌کند.

2. اجرای سیاست با Kyverno — در سطح خوشه، Kyverno خط‌مشی‌ها را در زمان پذیرش اعمال می‌کند تا از برنامه‌ریزی بارهای کاری ناسازگار جلوگیری کند. به‌عنوان مثال، یکی از خط‌مشی‌های پایه‌ای مانع استفاده از تگ «latest» برای تصاویر در پادها می‌شود.

نمونه Kyverno ClusterPolicy برای جلوگیری از استفاده از تگ latest:

apiVersion: kyverno.io/v1
نوع: ClusterPolicy
ابرداده:
  نام: Disallow-latest-tag
  حاشیه نویسی:
    Policyes.kyverno.io/title: عدم اجازه آخرین برچسب
    Policyes.kyverno.io/description: >-
      نیاز است که برچسب های تصویر به نسخه خاصی پین شوند.
      برچسب "آخرین" قابل تغییر است و می تواند منجر به استقرار غیرقابل پیش بینی شود.
مشخصات:
  validationFailureAction: اجرا شود
  پس زمینه: واقعی
  قوانین:
    - نام: نیاز-تگ-تصویر
      مطابقت:
        هر:
        - منابع:
            انواع:
              - غلاف
      اعتبارسنجی:
        پیام: >-
          "آخرین" برچسب تصویر مجاز نیست. یک تگ نسخه شده را مشخص کنید.
        الگو:
          مشخصات:
            ظروف:
            - تصویر: "*:*"

جمع‌بندی: این پلتفرم داخلی مبتنی بر اصول CNCF و ابزارهای بومی ابری، با تمرکز بر اعلامیت زیرساخت، استقرار GitOps و امنیت در همه مراحل، چارچوبی سازگار، قابل مشاهده و امن برای تحویل نرم‌افزار فراهم می‌آورد. اجرای چنین پلتفرمی به سازمان‌ها کمک می‌کند تا از تفاوت‌های محیطی جلوگیری کنند، سرعت توسعه را افزایش دهند و ریسک‌های امنیتی و عملیاتی را کاهش دهند. ✅