ہر تیزی سے ترقی کرنے والی انجینئرنگ ٹیم آخر کار ایک ہی دیوار سے ٹکراتی ہے۔
ڈویلپرز کو ایک نئے اسٹیجنگ ماحول کی ضرورت ہے اور ٹکٹ جمع کروائیں۔ پلیٹ فارم ٹیم اسے قطار میں رکھتی ہے۔
دو ہفتوں کے بعد، ماحول موجود ہے. پچھلے ماحول کا مشاہداتی اسٹیک غائب تھا کیونکہ اسے پچھلے ماحول سے قدرے مختلف طریقے سے ترتیب دیا گیا تھا، نام دینے کے کنونشن کے ساتھ جو پروڈکشن سیٹ اپ سے میل نہیں کھاتا تھا۔ ڈویلپرز کے ذریعہ تقسیم کیا گیا۔ کچھ ٹوٹ گیا ہے۔ کوئی نہیں جانتا کیوں؟
مسئلہ ٹکٹ کی قطار کا نہیں ہے۔ مسئلہ یہ ہے کہ کوئی پلیٹ فارم نہیں ہے۔ دوسرے لفظوں میں، یہ ایک پکی سڑک ہے جو ڈویلپرز کو ہر درخواست کے لیے پلیٹ فارم انجینئرز کی ضرورت کے بغیر مستقل، قابل سماعت، اور محفوظ انفراسٹرکچر، تعیناتیوں اور ماحول کی سیلف سروس کرنے کی اجازت دیتی ہے۔
اندرونی ڈویلپر پلیٹ فارم (IDP) اس مسئلے کو حل کرتا ہے۔ یہ تصویر سے پلیٹ فارم انجینئرز کو ہٹا کر نہیں کیا جاتا ہے، بلکہ ان کے کام کو انفرادی درخواستوں پر عمل درآمد کرنے سے ایسے نظاموں کی تعمیر میں منتقل کر کے کیا جاتا ہے جو ان درخواستوں کو خود بخود انجام دیتے ہیں۔
یہ ہینڈ بک تین CNCF ٹولز کا استعمال کرتے ہوئے پروڈکشن گریڈ IDPs بناتی ہے جو 2026 میں اس کا بنیادی حصہ بنیں گے: بیک اسٹیج، ایک ڈویلپر پورٹل اور سافٹ ویئر کیٹلاگ، ArgoCD، ایک GitOps مسلسل ڈیلیوری انجن، اور Crossplane، Kubernetes پر مبنی انفراسٹرکچر کنٹرول طیارہ۔
بالآخر، پلیٹ فارم پر موجود ڈویلپرز کلاؤڈ ڈیٹا بیس فراہم کر سکتے ہیں، ایپلیکیشنز کو سٹیجنگ پر تعینات کر سکتے ہیں، اور ایک ٹکٹ جمع کرائے بغیر کیٹلاگ میں نئی خدمات کو رجسٹر کر سکتے ہیں۔
انڈیکس
جو آپ سیکھیں گے۔
-
تین درجے کا IDP فن تعمیر اور کیوں ہر پرت کو ایک مخصوص ترتیب میں لاگو کیا جانا چاہیے۔
-
ملٹی انوائرمنٹ GitOps پروویژننگ کے لیے ApplicationSets کا استعمال کرتے ہوئے ArgoCD کو انسٹال اور کنفیگر کرنے کا طریقہ
-
Kubernetes حسب ضرورت وسائل کے طور پر کلاؤڈ انفراسٹرکچر کی وضاحت کرنے کے لیے کراس پلین کمپوزیشنز کا استعمال کیسے کریں۔
-
سافٹ ویئر کیٹلاگ اور سافٹ ویئر ٹیمپلیٹس کا استعمال کرتے ہوئے بیک اسٹیج کو کیسے تعینات اور ترتیب دیا جائے۔
-
بیک اسٹیج، آرگو سی ڈی، اور کراس پلین کو ایک ہی سیلف سروس سنہری راستے سے کیسے جوڑیں
-
IDP کے لیے لاگت کا انتساب کیسے لاگو کیا جائے تاکہ IDP کیری ٹیم اور لاگت سینٹر میٹا ڈیٹا کے ذریعے فراہم کردہ تمام وسائل۔
-
CNCF پلیٹ فارم انجینئرنگ میچورٹی ماڈل کا استعمال کرتے ہوئے IDP کی پختگی کی پیمائش کیسے کی جائے
آئیے اسے بنائیں۔
شرائط
پیروی کرنے سے پہلے، آپ کو ضرورت ہو گی:
علم:
-
Kubernetes کے ساتھ کام کرنے سے واقف ہوں: ایپلیکیشنز کو تعینات کریں، YAML مینی فیسٹ لکھیں، اور نام کی جگہوں اور RBAC کو سمجھیں۔
-
بنیادی GitOps کو سمجھیں: جانیں کہ "سچ کے ماخذ کے طور پر Git” کا اصل مطلب کیا ہے۔
-
پڑھنے کی سطح پر Helm، Terraform HCL، اور TypeScript کے ساتھ آرام۔
-
AWS خدمات کو سمجھنا: EKS, RDS, S3, IAM
اوزار اور رسائی:
-
کم از کم 3 نوڈس (m5.xlarge یا مساوی) کے ساتھ Kubernetes 1.28 یا اس سے زیادہ چلنے والا EKS کلسٹر۔
-
kubectlترتیب دینا اور ایک کلسٹر کی طرف اشارہ کرنا -
helm3.12 یا اس سے زیادہ انسٹال ہے۔ -
AWS CLI v2 انتظامی اقدامات کے لیے منتظم کی سطح کی اجازتوں کے ساتھ ترتیب دیا گیا
-
Node.js 18+ اور یارن (بیک اسٹیج کے لیے)
-
ایک GitHub تنظیم جسے آپ کنٹرول کرتے ہیں (GitOps ریپوزٹریز اور بیک اسٹیج GitHub انضمام کے لیے)
ساتھی ذخیرہ:
git clone https://github.com/aayostem/platform-toolkit
cd platform-toolkit
ریپوزٹری میں تمام مینی فیسٹس، ہیلم ویلیو فائلز، کراس پلین کمپوزیشنز، اور بیک اسٹیج ٹیمپلیٹس شامل ہیں جن کا اس گائیڈ میں حوالہ دیا گیا ہے۔ ہر حصہ ریپوزٹری میں ڈائرکٹری کا نقشہ بناتا ہے۔
تخمینی وقت: ایک تجربہ کار پلیٹ فارم انجینئر کے لیے، مکمل نفاذ میں 1-2 دن لگتے ہیں۔ کام کرنے والی GitOps ڈیلیوری پرت بنانے کے لیے حصے 1-3 کو صبح میں مکمل کیا جا سکتا ہے۔
حصہ 1: آئی ڈی پی آرکیٹیکچر – تھری لیئر ماڈل
1.1 آئی ڈی پی دراصل کیا ہے؟
اندرونی ڈویلپر پلیٹ فارم ایک ٹول نہیں ہے۔ یہ ایک پروڈکٹ ہے۔ پلیٹ فارم ٹیم کے ذریعے بنائے گئے اور برقرار رکھنے والے ٹولز، ورک فلو، اور تجریدوں کا ایک مجموعہ جو ایپلیکیشن ڈویلپرز کو خود انفراسٹرکچر کا انتظام کیے بغیر تیزی سے آگے بڑھنے کے قابل بناتا ہے۔
امتیاز اہم ہے کیونکہ یہ تمام تعمیراتی فیصلوں کو تشکیل دیتا ہے۔ ٹول انسٹال اور کنفیگر ہو چکا ہے۔ مصنوعات کو صارفین کے لیے ڈیزائن کیا گیا ہے، فیڈ بیک کی بنیاد پر دہرایا جاتا ہے، اور اس بات سے ماپا جاتا ہے کہ آیا صارفین اصل میں پروڈکٹ کو اپناتے ہیں۔ پلیٹ فارم ٹیم جو آئی ڈی پیز بناتی ہے جنہیں ڈویلپر پسند کرتے ہیں پروڈکٹ مینیجرز کی طرح سوچتے ہیں نہ کہ سسٹم ایڈمنسٹریٹرز۔
DORA 2025 کی رپورٹ میں پتا چلا ہے کہ تقریباً 90% کمپنیوں کے پاس اب کسی نہ کسی شکل کا اندرونی پلیٹ فارم ہے۔ لیکن ایک پلیٹ فارم ہونا اور ایک ایسا پلیٹ فارم ہونا جسے ڈویلپر درحقیقت استعمال کرتے ہیں دو مختلف چیزیں ہیں۔
سروے ظاہر کرتے ہیں کہ اندرونی پلیٹ فارمز کے ساتھ ڈویلپر کا اطمینان وسیع پیمانے پر مختلف ہوتا ہے۔ اور مطمئن اور غیر مطمئن ٹیموں کے درمیان فرق کا براہ راست تعلق اس بات سے ہے کہ آیا پلیٹ فارم ٹیم IDP کو روڈ میپ اور صارف کی تحقیق کے ساتھ ایک پروڈکٹ کے طور پر پیش کرتی ہے، یا ٹکٹوں کی قطار کے ساتھ انفراسٹرکچر پروجیکٹ کے طور پر۔
اس گائیڈ میں تین ٹولز – بیک اسٹیج، آرگو سی ڈی، اور کراسپلین – 2026 میں پروڈکشن آئی ڈی پیز کے لیے سب سے زیادہ وسیع پیمانے پر اپنائے جانے والے اوپن سورس اسٹیکس ہوں گے۔ لیکن ان کو جوڑنے والا فن تعمیر اتنا ہی اہم ہے جتنا کہ خود ٹولز۔
1.2 تین درجے کا فن تعمیر
ایک پیداواری IDP کے تین درجے ہوتے ہیں، ہر ایک کی ذمہ داری ہوتی ہے۔
Layer 1: Developer Interface (Backstage)
├── Software catalog — inventory of all services, APIs, and resources
├── Software Templates — self-service forms that trigger provisioning workflows
├── TechDocs — documentation co-located with each catalog entity
└── Plugins — integrations with ArgoCD, Kubernetes, PagerDuty, Grafana
Layer 2: Delivery Layer (ArgoCD)
├── GitOps sync — continuous reconciliation of cluster state to Git
├── ApplicationSets — multi-environment deployment from a single definition
├── Rollout management — progressive delivery with health checks
└── Audit trail — every deployment change linked to a Git commit
Layer 3: Infrastructure Layer (Crossplane)
├── Composite Resources — cloud resources defined as Kubernetes CRDs
├── Compositions — templates that expand a simple claim into full AWS infrastructure
├── ProviderConfigs — credentials and region configuration for each cloud provider
└── Usage tracking — every provisioned resource tagged with team and cost centre
ایک اہم تعمیراتی اصول: Backstage کبھی بھی Kubernetes یا کلاؤڈ APIs کے ساتھ براہ راست بات چیت نہیں کرتا ہے۔ جب کوئی ڈویلپر بیک اسٹیج میں سافٹ ویئر ٹیمپلیٹ جمع کرتا ہے، تو آؤٹ پٹ ایک گٹ کمٹ ہوتا ہے (یا تو کراس پلین کلیم یا ایک YAML فائل جو ArgoCD ایپلیکیشن مینی فیسٹ کی نمائندگی کرتی ہے)۔ ArgoCD اس کمٹ کو اٹھاتا ہے اور اسے کلسٹر پر لاگو کرتا ہے۔ کراسپلین کلسٹر وسائل کو حقیقی کلاؤڈ انفراسٹرکچر میں تبدیل کرتا ہے۔
یہ بالواسطہ راستہ پیچیدگی کی خاطر پیچیدگی نہیں ہے۔ اس کا مطلب یہ ہے کہ ہر بنیادی ڈھانچے کی تبدیلی مصنف، ٹائم اسٹیمپ، پل کی درخواست، اور جائزہ کے ساتھ ایک گٹ کمٹ ہے۔ آڈٹ کے راستے خودکار ہیں۔ رول بیک میکانزم مندرجہ ذیل ہے: git revert.
Developer → Backstage Template → Git commit → ArgoCD → Crossplane → AWS
↑
Single source of truth
Full audit trail
Rollback = git revert
غلط متبادلات میں شامل ہیں: اس کا مطلب ہے بادل API کو براہ راست بیک اسٹیج سے کال کرنا۔
// Bad: Backstage template calling AWS SDK directly
// No audit trail, no rollback, no reconciliation loop
// If the call fails halfway, you have partial infrastructure with no record
import { S3Client, CreateBucketCommand } from "@aws-sdk/client-s3";
const client = new S3Client({ region: "us-east-1" });
await client.send(new CreateBucketCommand({ Bucket: bucketName }));
اور صحیح نقطہ نظر – بیک اسٹیج سے گٹ پر کراسپلین کے دعووں کو کیسے آؤٹ پٹ کریں:
# Good: Backstage template output — a Crossplane claim committed to Git
# ArgoCD applies it, Crossplane reconciles it, AWS creates the bucket
# Every step is tracked, auditable, and reversible
apiVersion: platform.cloudfrugal.com/v1alpha1
kind: S3Bucket
metadata:
name: ${{ values.bucket_name }}
namespace: ${{ values.team_namespace }}
labels:
team: ${{ values.team_name }}
cost-centre: ${{ values.cost_centre }}
environment: ${{ values.environment }}
spec:
versioning: true
encryption: AES256
region: us-east-1
1.3 نفاذ کا حکم
اس ترتیب میں تعمیر کریں۔ اس سے انحراف کرنے کے نتیجے میں انضمام کے مسائل پیدا ہوں گے جن کو ڈیبگ کرنا مشکل ہے۔
Step 1: ArgoCD — the delivery foundation everything else depends on
Step 2: Crossplane — infrastructure control plane, delivered by ArgoCD
Step 3: Backstage — the portal, pointing at ArgoCD and Crossplane as backends
Step 4: Wire together — Software Templates that produce GitOps manifests
Step 5: FinOps layer — cost attribution metadata in every provisioned resource
حصہ 2: ArgoCD – GitOps فاؤنڈیشن
ArgoCD Kubernetes کے لیے ایک مسلسل ڈیلیوری ٹول ہے جو GitOps پیٹرن کو نافذ کرتا ہے۔ اگر آپ نے پہلے کبھی GitOps ٹول استعمال نہیں کیا ہے، تو بنیادی خیال آسان ہے۔ آپ کے کلسٹر پر کیا چلنا چاہئے اس کے لئے آپ کا Git ذخیرہ آپ کا واحد ذریعہ ہے، اور ArgoCD اس سے ملنے کے لئے اصل کلسٹر حالت کو مسلسل ایڈجسٹ کرتا ہے۔
اگر ڈویلپرز کلسٹر میں وسائل کو دستی طور پر تبدیل کرتے ہیں، تو ArgoCD بڑھے کا پتہ لگاتا ہے اور انہیں Git میں دوبارہ ہم آہنگ کرتا ہے۔ جب گٹ تبدیل ہوتا ہے تو، ArgoCD کلسٹر میں تبدیلیوں کا اطلاق کرتا ہے۔ انسانی مداخلت کی ضرورت نہیں ہے اور فعال طور پر حوصلہ شکنی کی جاتی ہے۔ مقصد ایک کلسٹر ہے جس کی حالت ہمیشہ گٹ میں موجود چیزوں کے ذریعہ پوری طرح سے بیان کی جاتی ہے۔
ArgoCD ایک CNCF گریجویشن پروجیکٹ ہے۔ اس کا مطلب یہ ہے کہ یہ پیداوار کے لیے تیار اور وسیع پیمانے پر دستیاب ہے۔ یہ ویب UI، CLI، اور REST API کا استعمال کرتے ہوئے کلسٹر میں پوڈز کے سیٹ کے طور پر چلتا ہے۔ ہر وہ چیز جس کی آپ کو متعدد ماحول میں تعیناتیوں کا انتظام کرنے کی ضرورت ہے ایک جگہ پر ہے۔
2.1 ArgoCD انسٹال کریں۔
# Create the ArgoCD namespace
kubectl create namespace argocd
# Install ArgoCD using the official manifest
kubectl apply -n argocd \
-f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
# Wait for all pods to be running before proceeding
kubectl wait --for=condition=Ready pods \
--all -n argocd --timeout=300s
# Get the initial admin password
argocd_password=$(kubectl -n argocd get secret argocd-initial-admin-secret \
-o jsonpath="{.data.password}" | base64 -d)
echo "ArgoCD initial password: $argocd_password"
echo "Save this somewhere secure before proceeding"
# Port-forward to access the ArgoCD UI locally
kubectl port-forward svc/argocd-server -n argocd 8080:443 &
# Login via CLI
argocd login localhost:8080 \
--username admin \
--password "$argocd_password" \
--insecure
# Change the password immediately
argocd account update-password \
--current-password "$argocd_password" \
--new-password "your-secure-password"
2.2 GitOps ذخیرہ کی ساخت
ArgoCD کلاک سٹوریج کا ڈھانچہ اس بات کا تعین کرتا ہے کہ متعدد ماحول کا انتظام کیسے کیا جاتا ہے۔ Kustomize کے زیر انتظام اوورلیز کا استعمال کرتے ہوئے ایک فی ڈائرکٹری ماحول جو سب سے بہتر پیمانہ کرتا ہے۔
Kustomize ایک Kubernetes پر مبنی کنفیگریشن مینجمنٹ ٹول ہے جو آپ کو ایک بار بیس کنفیگریشن کی وضاحت کرنے دیتا ہے اور اس کے اوپر ماحول سے متعلق مخصوص اوور رائیڈز کو پرت دیتا ہے۔ اس کا مطلب یہ ہے کہ سٹیجنگ اور پروڈکشن کنفیگریشنز ایک ہی YAML ڈھانچے کا اشتراک کرتے ہیں، لیکن نقل کی تعداد، تصویری ٹیگز، اور وسائل کی حدود مختلف ہیں۔
gitops-repo/
├── apps/
│ ├── base/ # Shared configuration across all environments
│ │ ├── payment-api/
│ │ │ ├── deployment.yaml
│ │ │ ├── service.yaml
│ │ │ └── kustomization.yaml
│ │ └── user-api/
│ │ ├── deployment.yaml
│ │ ├── service.yaml
│ │ └── kustomization.yaml
│ └── overlays/
│ ├── staging/ # Staging-specific overrides
│ │ ├── payment-api/
│ │ │ └── kustomization.yaml # Override: 1 replica, staging image tag
│ │ └── kustomization.yaml
│ └── production/ # Production-specific overrides
│ ├── payment-api/
│ │ └── kustomization.yaml # Override: 3 replicas, pinned image tag
│ └── kustomization.yaml
└── infrastructure/
├── crossplane/ # Crossplane installation and providers
├── monitoring/ # Prometheus, Grafana
└── ingress/ # NGINX or ALB ingress controller
2.3 ایپلیکیشن سیٹس – متعدد ماحول کا انتظام کرنا
ApplicationSet ایک ArgoCD وسیلہ ہے جو ایک ٹیمپلیٹ سے متعدد ایپلیکیشن آبجیکٹ بناتا ہے۔ ایک ایپلیکیشن مینی فیسٹ فی سروس فی ماحول بنانے کے بجائے، جس کا پیمانے پر انتظام کرنا مشکل ہے، ایپلی کیشنز کا ایک سیٹ متعین کریں جو تمام ماحول میں تمام سروسز کو شامل کرے۔ میٹرکس جنریٹر ماحولیات کی فہرست کو گٹ ڈائرکٹری اسکین کے ساتھ جوڑتا ہے تاکہ خود بخود تمام امتزاجات پیدا ہوں۔
# applicationset-apps.yaml
# This single resource generates one ArgoCD Application
# for each combination of environment and application directory
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: platform-apps
namespace: argocd
spec:
generators:
- matrix:
generators:
# Generator 1: environments
- list:
elements:
- environment: staging
cluster: https://staging.eks.cluster.local
- environment: production
cluster: https://production.eks.cluster.local
# Generator 2: application directories in the overlay
- git:
repoURL: https://github.com/your-org/gitops-repo
revision: HEAD
directories:
- path: apps/overlays/{{environment}}/*
template:
metadata:
name: "{{environment}}-{{path.basename}}"
labels:
environment: "{{environment}}"
app: "{{path.basename}}"
spec:
project: default
source:
repoURL: https://github.com/your-org/gitops-repo
targetRevision: HEAD
path: "apps/overlays/{{environment}}/{{path.basename}}"
destination:
server: "{{cluster}}"
namespace: "{{path.basename}}"
syncPolicy:
automated:
prune: true # Delete resources removed from Git
selfHeal: true # Revert manual cluster changes
syncOptions:
- CreateNamespace=true
- PrunePropagationPolicy=foreground
تصدیق کریں کہ ApplicationSet متوقع ایپلیکیشن تیار کرتا ہے۔
# List all generated Applications
kubectl get applications -n argocd
# Expected output: one Application per environment per app
# staging-payment-api Synced Healthy
# staging-user-api Synced Healthy
# production-payment-api Synced Healthy
# production-user-api Synced Healthy
# Check sync status for a specific application
argocd app get staging-payment-api
پلیٹ فارم ٹیموں کے لیے 2.4 ArgoCD RBAC
ایک کثیر ٹیم IDP کے لیے ہر ٹیم کو ArgoCD تک رسائی کی مختلف سطحوں کی ضرورت ہوتی ہے۔ ایپلیکیشن ٹیموں کو اپنی ایپلی کیشنز کو دیکھنے اور ہم آہنگ کرنے کے قابل ہونا ضروری ہے۔ پلیٹ فارم ٹیموں کو وسیع تر رسائی حاصل ہونی چاہیے۔ ArgoCD کے ذریعے کسی کے پاس لامحدود کلسٹر مینیجر نہیں ہونے چاہئیں۔
پہلے سے طے شدہ پالیسی ہے: readonly – کوئی بھی مستند صارف سب کچھ دیکھ سکتا ہے لیکن کچھ تبدیل نہیں کر سکتا۔
# argocd-rbac-configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: argocd-rbac-cm
namespace: argocd
data:
policy.default: role:readonly
policy.csv: |
# Platform team: full access to all applications
p, role:platform-team, applications, *, */*, allow
p, role:platform-team, clusters, get, *, allow
p, role:platform-team, repositories, *, *, allow
# Application teams: sync and get their own namespace only
p, role:app-team, applications, get, */staging-*, allow
p, role:app-team, applications, sync, */staging-*, allow
# Bind roles to GitHub teams
g, your-org:platform-engineers, role:platform-team
g, your-org:developers, role:app-team
scopes: '[groups]'
حصہ 3: کراس پلین – ایک Kubernetes وسائل کے طور پر انفراسٹرکچر
کراسپلین ایک CNCF- گریڈ اوپن سورس فریم ورک ہے جو Kubernetes کو عام مقصد کے بنیادی ڈھانچے کے کنٹرول والے جہاز میں پھیلاتا ہے۔
کلیدی خیال: کلاؤڈ وسائل کو منظم کرنے کے لیے اپنے کلسٹر سے باہر Terraform یا CloudFormation جیسے علیحدہ ٹولز استعمال کرنے کے بجائے، آپ کلاؤڈ ریسورسز (RDS ڈیٹا بیس، S3 buckets، VPCs، IAM رولز) کو Kubernetes کے حسب ضرورت وسائل کی تعریف کے طور پر بیان کرتے ہیں۔
جب آپ اپنے کلسٹر پر کراسپلین وسائل کا اطلاق کرتے ہیں، تو کراسپلین کا کنٹرولر مطلوبہ حالت پر قبضہ کرتا ہے اور اسے اصل AWS حالت سے مماثل کرنے کے لیے ایڈجسٹ کرتا ہے۔ بالکل اسی طرح Kubernetes چلتی ہوئی پوڈز کے سیٹ پر تعیناتیوں کو مربوط کرتا ہے۔
کراسپلین اس کے اوپر جو اہم تجرید کرتا ہے وہ جامع وسائل ہے۔ پلیٹ فارم ٹیم اعلی سطح کی وضاحت کرتی ہے۔ PostgreSQLDatabase ایک قسم جو حقیقی RDS مثال کے لیے درکار 30 سے زیادہ کنفیگریشن فیلڈز کا خلاصہ کرتی ہے۔
ڈویلپرز سادہ اقسام کے ساتھ تعامل کرتے ہیں۔ Crossplane اسے آپ کے AWS وسائل کی مکمل ترتیب تک بڑھاتا ہے، خود بخود پلیٹ فارم ٹیم کی سیکیورٹی اور آپریشنل معیارات کو نافذ کرتا ہے۔ یہ ایک ایسا معیار ہے جسے نظرانداز نہیں کیا جا سکتا کیونکہ ڈویلپر پہلے سے طے شدہ فیلڈز نہیں دیکھ سکتے۔
3.1 کراس پلین کی تنصیب
کراسپلین کو آرگو سی ڈی کے ذریعے کلسٹرز تک پہنچایا جاتا ہے، جو دو ٹولز کے درمیان پہلا انضمام ہے۔ کراس پلین کو چلانے کے بجائے ArgoCD ایپلیکیشن کے ذریعے انسٹال کریں۔ helm install کراس پلین کو براہ راست آپ کے GitOps مینجمنٹ انفراسٹرکچر کا حصہ بناتا ہے۔ کراس پلین کنفیگریشن میں تمام تبدیلیاں Git پرعزم ہیں اور ان کا جائزہ لیا گیا ہے۔
# infrastructure/crossplane/application.yaml
# ArgoCD Application that installs Crossplane via Helm
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: crossplane
namespace: argocd
spec:
project: default
source:
repoURL: https://charts.crossplane.io/stable
chart: crossplane
targetRevision: 1.15.0
helm:
values: |
provider:
packages:
# AWS provider — manages all AWS resources
- xpkg.upbound.io/upbound/provider-aws-s3:v1.2.0
- xpkg.upbound.io/upbound/provider-aws-rds:v1.2.0
- xpkg.upbound.io/upbound/provider-aws-iam:v1.2.0
destination:
server: https://kubernetes.default.svc
namespace: crossplane-system
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- CreateNamespace=true
# Apply the ArgoCD Application — ArgoCD installs Crossplane
kubectl apply -f infrastructure/crossplane/application.yaml
# Watch Crossplane pods come up
kubectl get pods -n crossplane-system -w
# Verify providers are installed and healthy
kubectl get providers
# Expected:
# NAME INSTALLED HEALTHY PACKAGE
# upbound-provider-aws-s3 True True xpkg.upbound.io/...
# upbound-provider-aws-rds True True xpkg.upbound.io/...
3.2 فراہم کنندہ کی اسناد
کراسپلین کو وسائل کی فراہمی کے لیے AWS اسناد کی ضرورت ہوتی ہے۔ EKS کے لیے تجویز کردہ طریقہ IAM رولز فار سروس اکاؤنٹس (IRSA) ہے۔ یہ طریقہ کار Kubernetes pods کو کلسٹر میں اسناد کو ذخیرہ کیے بغیر براہ راست IAM کے کردار سنبھالنے کی اجازت دیتا ہے۔
پوڈ کے Kubernetes سروس اکاؤنٹ کو IAM رول ARN کے ساتھ تشریح کیا جاتا ہے، اور جب پوڈ API کو کال کرتا ہے تو AWS خود بخود مختصر مدت کے اسناد فراہم کرتا ہے۔ رسائی کی کوئی چابیاں نہیں ہیں، تبدیل کرنے کے لیے کوئی راز نہیں ہیں، اور غلطی سے بے نقاب کرنے کے لیے کوئی اسناد نہیں ہیں۔
# Create the IAM role for Crossplane with the necessary AWS permissions
aws iam create-role \
--role-name CrossplaneProviderRole \
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::YOUR_ACCOUNT_ID:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/YOUR_OIDC_ID"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks.us-east-1.amazonaws.com/id/YOUR_OIDC_ID:sub":
"system:serviceaccount:crossplane-system:provider-aws"
}
}
}]
}'
# Attach the permissions policy (scope this to minimum required in production)
aws iam attach-role-policy \
--role-name CrossplaneProviderRole \
--policy-arn arn:aws:iam::aws:policy/AdministratorAccess
# provider-config.yaml
# Configure the AWS provider with IRSA — no static credentials
apiVersion: aws.upbound.io/v1beta1
kind: ProviderConfig
metadata:
name: default
spec:
credentials:
source: IRSA # Use the IAM role attached to the provider service account
3.3 جامع وسائل کی تعریف – PostgreSQL ڈیٹا بیس
یہ وہ جگہ ہے جہاں IDP تجرید کھیل میں آتا ہے۔ پلیٹ فارم ٹیم دو YAML فائلوں کی وضاحت کرتی ہے: CompositeResourceDefinition (XRD) اس فارمیٹ کی وضاحت کرتا ہے جس کی ڈویلپرز درخواست کر سکتے ہیں، Compositionاس بات کی وضاحت کرتا ہے کہ کس طرح درخواستیں اصل AWS وسائل تک پیمانے پر کی جاتی ہیں جن پر پلیٹ فارم کے معیارات لاگو ہوتے ہیں۔
XRD ڈویلپرز کے ساتھ ایک API معاہدہ ہے۔ اسے سادہ رکھیں۔ یہاں صرف وہی فیلڈز ظاہر ہونے چاہئیں جنہیں ڈیولپر کو کنٹرول کرنے کی ضرورت ہے۔
# xrd-postgresql.yaml
# Defines the PostgreSQLDatabase type that developers can request
# Developers never see the RDS-specific configuration below
apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
name: xpostgresqldatabases.platform.cloudfrugal.com
spec:
group: platform.cloudfrugal.com
names:
kind: XPostgreSQLDatabase
plural: xpostgresqldatabases
claimNames:
kind: PostgreSQLDatabase # This is what developers create
plural: postgresqldatabases
versions:
- name: v1alpha1
served: true
referenceable: true
schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
# Developer-facing fields only — simple and bounded
storageGB:
type: integer
minimum: 20
maximum: 1000
description: "Storage in GB. Min 20, max 1000."
instanceClass:
type: string
enum: ["small", "medium", "large"]
description: "small=db.t4g.medium, medium=db.r7g.large, large=db.r7g.2xlarge"
environment:
type: string
enum: ["staging", "production"]
ایک کمپوزیشن ایک پلیٹ فارم ٹیم کا نفاذ ہے۔ یہ سادہ ڈویلپر فیلڈز کو مکمل RDS کنفیگریشن میں نقشہ بناتا ہے اور پلیٹ فارم کے معیارات کو نافذ کرتا ہے جنہیں ڈویلپر اوور رائڈ نہیں کر سکتے۔
# composition-postgresql.yaml
# Defines what a PostgreSQLDatabase claim expands into
# Platform standards (encryption, backup, deletion protection) are applied here
# Developers cannot override them — the platform enforces them
apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
name: postgresql-aws-composition
labels:
provider: aws
spec:
compositeTypeRef:
apiVersion: platform.cloudfrugal.com/v1alpha1
kind: XPostgreSQLDatabase
resources:
# The actual RDS instance — expanded from the simple developer claim
- name: rds-instance
base:
apiVersion: rds.aws.upbound.io/v1beta1
kind: Instance
spec:
forProvider:
region: us-east-1
engine: postgres
engineVersion: "15.4"
# Platform standards — always applied, not developer-configurable
storageEncrypted: true # Always encrypted
backupRetentionPeriod: 7 # Always 7-day backup
deletionProtection: true # Always deletion-protected
multiAZ: false # Overridden to true for production (see patches)
dbSubnetGroupNameSelector:
matchLabels:
platform.cloudfrugal.com/subnet-group: private
patches:
# Map the developer's simple instanceClass to the actual RDS instance type
- type: CombineFromComposite
combine:
variables:
- fromFieldPath: spec.instanceClass
strategy: string
string:
fmt: |
%s
toFieldPath: spec.forProvider.dbInstanceClass
transforms:
- type: map
map:
small: db.t4g.medium
medium: db.r7g.large
large: db.r7g.2xlarge
# Enable Multi-AZ for production automatically
- type: FromCompositeFieldPath
fromFieldPath: spec.environment
toFieldPath: spec.forProvider.multiAZ
transforms:
- type: map
map:
staging: "false"
production: "true"
# Copy team labels from the claim to the RDS instance for cost attribution
- type: FromCompositeFieldPath
fromFieldPath: metadata.labels
toFieldPath: spec.forProvider.tags
PostgreSQL ڈیٹا بیس کی درخواست کرنے والے ڈویلپر اب لکھتے ہیں:
# Developer creates this in their team's namespace
# No RDS knowledge required. No IAM configuration. No subnet group lookup.
apiVersion: platform.cloudfrugal.com/v1alpha1
kind: PostgreSQLDatabase
metadata:
name: payment-service-db
namespace: payments-team
labels:
team: payments
cost-centre: payments-engineering
environment: staging
spec:
storageGB: 100
instanceClass: medium
environment: staging
کراس پلین اس درخواست کو منٹوں میں آپ کے پورے RDS مثال میں مربوط کرتا ہے، خودکار طور پر انکرپشن، بیک اپس، اور پلیٹ فارم کے تمام معیارات کو نافذ کرتا ہے۔
3.4 کراس پلین وسائل کی فراہمی کی تصدیق کریں۔
# Watch the claim status — it should transition to Ready=True
kubectl get postgresqldatabases -n payments-team -w
# Check the composite resource for detailed status
kubectl describe xpostgresqldatabases.platform.cloudfrugal.com
# Verify the actual AWS resource was created
aws rds describe-db-instances \
--query 'DBInstances[?TagList[?Key==`team` && Value==`payments`]].[DBInstanceIdentifier,DBInstanceStatus]' \
--output table
حصہ 4: بیک اسٹیج – ڈویلپر پورٹل
بیک اسٹیج ایک CNCF-انکیوبیٹڈ اوپن سورس فریم ورک ہے جو اصل میں Spotify کے ذریعے بنایا گیا تھا۔ یہ IDP پر ڈویلپرز کے لیے ایک انٹرفیس کے طور پر کام کرتا ہے، ایک واحد جگہ جہاں ڈویلپر خدمات کو دریافت کر سکتے ہیں، بنیادی ڈھانچے کی درخواست کر سکتے ہیں، اور یہ جاننے کے بغیر دستاویزات تلاش کر سکتے ہیں کہ کون سا بنیادی نظام فراہم کیا گیا ہے۔
بیک اسٹیج تین بنیادی خصوصیات پیش کرتا ہے:
-
ایک سافٹ ویئر کیٹلاگ جو آپ کی تنظیم کی تمام خدمات، APIs، لائبریریوں اور وسائل کی فہرست دیتا ہے۔
-
سافٹ ویئر ٹیمپلیٹس جو ڈویلپرز کو بنیادی ڈھانچے کی فراہمی اور نئی سروس اسکافولڈنگ کے لیے سیلف سروس فارم فراہم کرتے ہیں
-
TechDoc اس کیٹلاگ ہستی کے ساتھ مل کر واقع ہے جو دستاویز کو دستاویز کرتا ہے تاکہ دستاویز ہمیشہ اسی جگہ پر مل سکے جس میں اس سروس پر مشتمل ہے۔
بیک اسٹیج ٹائپ اسکرپٹ میں ری ایکٹ فرنٹ اینڈ اور Node.js بیک اینڈ کے ساتھ بنایا گیا ہے۔ یہ ترتیب شدہ ہے، انسٹال نہیں ہے۔ بیک اسٹیج ایپ بنائیں، اسے اپنی تنظیم کی تفصیلات کے مطابق ترتیب دیں، اور اسے اپنے کلسٹر میں تعینات کریں۔
4.1 بیک اسٹیج کی تخلیق اور ترتیب
# Create a new Backstage app
npx @backstage/create-app@latest
# When prompted:
# App name: platform-portal
# Choose SQLite for local development, PostgreSQL for production
cd platform-portal
اپنے ArgoCD مثال اور GitHub سے جڑنے کے لیے بیک اسٹیج کو ترتیب دیں۔
# app-config.production.yaml
app:
title: Cloudfrugal Platform Portal
baseUrl: https://platform.your-company.com
backend:
baseUrl: https://platform.your-company.com
database:
client: pg
connection:
host: ${POSTGRES_HOST}
port: 5432
user: ${POSTGRES_USER}
password: ${POSTGRES_PASSWORD}
database: backstage
# GitHub integration for catalog discovery and template scaffolding
integrations:
github:
- host: github.com
apps:
- appId: ${GITHUB_APP_ID}
webhookSecret: ${GITHUB_WEBHOOK_SECRET}
clientId: ${GITHUB_CLIENT_ID}
clientSecret: ${GITHUB_CLIENT_SECRET}
privateKey: ${GITHUB_PRIVATE_KEY}
# ArgoCD plugin configuration
argocd:
username: ${ARGOCD_USERNAME}
password: ${ARGOCD_PASSWORD}
appLocatorMethods:
- type: 'config'
instances:
- name: main
url: https://argocd.your-company.com
# Catalog auto-discovery — finds catalog-info.yaml files across your GitHub org
catalog:
providers:
github:
your-org:
organization: 'your-github-org'
catalogPath: '/catalog-info.yaml'
filters:
branch: 'main'
4.2 سافٹ ویئر کیٹلاگ – سروس رجسٹریشن
پلیٹ فارم پر موجود تمام خدمات، APIs، لائبریریاں، اور وسائل کو بیک اسٹیج کیٹلاگ میں درج کیا جانا چاہیے بذریعہ: catalog-info.yaml فائلیں سروس ریپوزٹری کے لیے پابند ہیں۔ بیک اسٹیج خود بخود ان فائلوں کو GitHub انضمام کے ذریعے دریافت کرتا ہے۔ اگر فائل موجود ہے تو اسے دستی طور پر رجسٹر کرنے کی ضرورت نہیں ہے۔
# catalog-info.yaml — committed to each service's repository root
# Backstage discovers this automatically via the GitHub integration
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
name: payment-api
title: Payment API
description: "Core payment processing service. Handles transaction initiation, authorisation, and settlement."
annotations:
# Links ArgoCD to show deployment status in the Backstage UI
argocd/app-name: production-payment-api
# Links GitHub Actions workflow status
github.com/project-slug: your-org/payment-api
# Links Grafana dashboard for this service
grafana/dashboard-selector: "title=Payment API"
# Links PagerDuty on-call schedule
pagerduty.com/service-id: P123456
tags:
- payments
- typescript
- critical
links:
- url: https://payment-api.docs.your-company.com
title: Documentation
- url: https://grafana.your-company.com/d/payment-api
title: Grafana Dashboard
spec:
type: service
lifecycle: production
owner: group:payments-team
system: payment-platform
dependsOn:
- component:user-api
- resource:payment-service-db
providesApis:
- payment-api-v2
4.3 سافٹ ویئر ٹیمپلیٹس – سیلف سروس انفراسٹرکچر
ایک سافٹ ویئر ٹیمپلیٹ ایک بیک اسٹیج فارم ہے جو جمع کرائے جانے پر ایک Git کمٹ بناتا ہے۔ ایک کمٹ میں کوئی بھی YAML، کوڈ، یا کنفیگریشن ہوتا ہے جس کی ٹیمپلیٹ وضاحت کرتی ہے۔
بنیادی ڈھانچے کی فراہمی کے لیے، آؤٹ پٹ ایک کراسپلین کلیم ہے۔ نئی سروس اسکافولڈنگ کے لیے، آؤٹ پٹ ایک مکمل سروس کنکال ہے جو نئے ریپوزٹری کے لیے پرعزم ہے۔
کلیدی ڈیزائن کا فیصلہ: ٹیمپلیٹس کو براہ راست ضم ہونے کی بجائے پل کی درخواستیں پیدا کرنی چاہئیں۔ PR پلیٹ فارم ٹیم کو مرئیت فراہم کرتا ہے، ڈیولپرز کے لیے لمحات کا جائزہ لیتا ہے، اور ہر ایک کے لیے ایک آڈٹ ٹریل فراہم کرتا ہے۔ خودکار انضمام کی پالیسیاں ٹیمپلیٹ آؤٹ پٹ پر اعتماد قائم کرنے کے بعد کم خطرے کی فراہمی کے لیے جائزے کے اقدامات کو ختم کر سکتی ہیں۔
# templates/postgresql-database/template.yaml
# This template gives developers a form to request a PostgreSQL database
# The output is a Crossplane PostgreSQLDatabase claim committed to the GitOps repo
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
name: postgresql-database
title: PostgreSQL Database
description: Provision a managed PostgreSQL database on AWS RDS. Encryption, backups, and deletion protection are configured automatically by the platform.
tags:
- database
- postgresql
- aws
spec:
owner: group:platform-team
type: infrastructure
# The form developers fill out in the Backstage UI
parameters:
- title: Database Configuration
required: [name, team, environment, storageGB, instanceClass]
properties:
name:
title: Database Name
type: string
description: "Lowercase, hyphens only. E.g. payment-service-db"
pattern: '^[a-z][a-z0-9-]*$'
team:
title: Owning Team
type: string
description: "Your team name. Used for cost attribution and ownership."
ui:field: OwnerPicker
ui:options:
catalogFilter:
kind: Group
environment:
title: Environment
type: string
enum: [staging, production]
default: staging
storageGB:
title: Storage (GB)
type: integer
minimum: 20
maximum: 1000
default: 50
instanceClass:
title: Instance Size
type: string
enum: [small, medium, large]
enumNames:
- "Small (db.t4g.medium) — dev/staging workloads"
- "Medium (db.r7g.large) — moderate production traffic"
- "Large (db.r7g.2xlarge) — high-throughput production"
default: small
# What the template does when submitted
steps:
- id: generate-claim
name: Generate Crossplane Claim
action: fetch:template
input:
url: ./skeleton # Contains the Crossplane claim YAML template
values:
name: ${{ parameters.name }}
team: ${{ parameters.team | parseEntityRef | pick('name') }}
environment: ${{ parameters.environment }}
storageGB: ${{ parameters.storageGB }}
instanceClass: ${{ parameters.instanceClass }}
- id: create-pr
name: Create Pull Request to GitOps Repo
action: publish:github:pull-request
input:
repoUrl: github.com?repo=gitops-repo&owner=your-org
title: "Platform: Provision PostgreSQL database ${{ parameters.name }} for ${{ parameters.team }}"
branchName: "provision-db-${{ parameters.name }}-${{ '' | now }}"
description: |
Requesting PostgreSQL database provisioned by Crossplane.
- **Name:** ${{ parameters.name }}
- **Team:** ${{ parameters.team }}
- **Environment:** ${{ parameters.environment }}
- **Storage:** ${{ parameters.storageGB }}GB
- **Instance:** ${{ parameters.instanceClass }}
Approve this PR to trigger provisioning. ArgoCD will pick up the change and Crossplane will create the RDS instance within ~5 minutes of merge.
sourcePath: ./skeleton
output:
links:
- title: View Pull Request
url: ${{ steps['create-pr'].output.remoteUrl }}
- title: Track Provisioning in ArgoCD
url: https://argocd.your-company.com/applications
ٹیمپلیٹ سکیلیٹن ڈائرکٹری ٹیمپلیٹ متغیر پلیس ہولڈرز کے ساتھ کراس پلین کلیمز پر مشتمل ہے۔
# templates/postgresql-database/skeleton/databases/${{ values.name }}.yaml
apiVersion: platform.cloudfrugal.com/v1alpha1
kind: PostgreSQLDatabase
metadata:
name: ${{ values.name }}
namespace: ${{ values.team }}-platform
labels:
team: ${{ values.team }}
cost-centre: ${{ values.team }}-engineering
environment: ${{ values.environment }}
managed-by: backstage-scaffolder
spec:
storageGB: ${{ values.storageGB }}
instanceClass: ${{ values.instanceClass }}
environment: ${{ values.environment }}
حصہ 5: ایک ساتھ جڑنا – سنہری راستہ
گولڈن پاتھ ایک مکمل اینڈ ٹو اینڈ ورک فلو ہے۔ ایک ڈویلپر بنیادی ڈھانچے کی درخواست کرنے کے لیے بیک اسٹیج کا استعمال کرتا ہے، وہ درخواست گٹ کمٹ بن جاتی ہے، ArgoCD کلسٹر پر کمٹ کا اطلاق کرتا ہے، کراس پلین اصل AWS وسائل فراہم کرتا ہے، اور نتائج بیک اسٹیج کیٹلاگ اور ArgoCD ڈیش بورڈ دونوں میں دکھائے جاتے ہیں۔
5.1 مجموعی بہاؤ
Developer fills form in Backstage
↓
Backstage Software Template renders the Crossplane claim YAML
↓
Backstage creates a Pull Request in the GitOps repository
↓
Platform engineer (or auto-merge policy) approves and merges the PR
↓
ArgoCD detects the new file in the GitOps repository
↓
ArgoCD applies the Crossplane claim to the cluster
↓
Crossplane reconciles the claim to an actual AWS RDS instance
↓
Developer receives the database endpoint via Kubernetes Secret
↓
Backstage catalog shows the new resource, owned by the requesting team
5.2 بیک اسٹیج میں وسائل کی حیثیت کو دوبارہ دکھائیں۔
Backstage Kubernetes پلگ ان آپ کے کلسٹر سے لائیو پوڈ اور وسائل کی حیثیت کو بازیافت کرتا ہے اور انہیں ہر کیٹلاگ ہستی کے صفحہ پر دکھاتا ہے۔ ڈویلپرز چیک کر سکتے ہیں کہ آیا کوئی سروس چل رہی ہے، کتنی نقلیں صحت مند ہیں، اور کیا آخری تعیناتی کو بیک اسٹیج چھوڑنے یا کچھ سیکھنے کے بغیر ہم آہنگ کیا گیا تھا۔ kubectl:
# Install the Kubernetes plugin packages
cd platform-portal
yarn --cwd packages/app add @backstage/plugin-kubernetes
yarn --cwd packages/backend add @backstage/plugin-kubernetes-backend
# app-config.production.yaml — add Kubernetes cluster configuration
kubernetes:
serviceLocatorMethod:
type: 'multiTenant'
clusterLocatorMethods:
- type: 'config'
clusters:
- name: production-eks
url: ${PRODUCTION_CLUSTER_URL}
authProvider: serviceAccount
serviceAccountToken: ${PRODUCTION_SA_TOKEN}
caData: ${PRODUCTION_CA_DATA}
- name: staging-eks
url: ${STAGING_CLUSTER_URL}
authProvider: serviceAccount
serviceAccountToken: ${STAGING_SA_TOKEN}
caData: ${STAGING_CA_DATA}
ہر کیٹلاگ ہستی کی تشریح کریں اور اسے Kubernetes وسائل سے مربوط کریں۔
# In each service's catalog-info.yaml
annotations:
backstage.io/kubernetes-label-selector: 'app=payment-api'
backstage.io/kubernetes-namespace: payments-team
5.3 ArgoCD پلگ ان کی تنصیب
ArgoCD پلگ ان تعیناتی کی تاریخ اور مطابقت پذیری کی حیثیت کو براہ راست بیک اسٹیج ہستی کے صفحہ پر دکھاتا ہے۔ جب ڈویلپرز کیٹلاگ میں بلنگ API کا صفحہ کھولتے ہیں، تو وہ آخری 10 تعیناتیوں، موجودہ مطابقت پذیری کی صورتحال، اور ArgoCD UI کو کھولے بغیر ایپلیکیشن صحت مند ہے یا نہیں۔
yarn --cwd packages/app add @roadiehq/backstage-plugin-argo-cd
// packages/app/src/components/catalog/EntityPage.tsx
import { EntityArgoCDOverviewCard } from '@roadiehq/backstage-plugin-argo-cd';
// Add to the service entity page layout
const serviceEntityPage = (
{/* ArgoCD deployment status — shows sync state and recent deployments */}
);
حصہ 6: FinOps انٹیگریشن – IDPs کے لیے لاگت کا انتساب
آئی ڈی پیز جو بغیر لاگت کے انتساب کے وسائل فراہم کرتے ہیں نئے چیلنجز پیدا کرتے ہیں۔ اب آپ کے پاس تیار کردہ بلوں کی واضح ملکیت کے بغیر خودکار بنیادی ڈھانچے کی فراہمی ہے۔ IDP کے ذریعے بنائے گئے تمام وسائل میں ٹیم اور لاگت کے مرکز کا میٹا ڈیٹا اس وقت سے لے جانا چاہیے جب سے وہ فراہم کیے گئے ہیں۔
6.1 تمام کراس پلین کنفیگریشنز کے لیے مطلوبہ لیبل
کراس پلین کمپوزیشنز وہ ہیں جہاں لاگت کا انتساب ایک پلیٹ فارم پرت پر نافذ کیا جاتا ہے جسے ڈیولپر درپیش دعووں کے بجائے ڈیولپرز کو روک نہیں سکتے۔ یہ لیبل اصل AWS وسائل میں بطور ٹیگ بھیجے جاتے ہیں۔ اس کا مطلب یہ ہے کہ یہ AWS Cost Explorer میں ظاہر ہوگا اور اسے ٹیم کی سطح کی لاگت کی رپورٹس بنانے کے لیے استعمال کیا جا سکتا ہے۔
# In every Composition, add mandatory cost attribution patches
patches:
# These labels flow to the actual AWS resource as tags
# They can't be omitted or overridden by the developer claim
- type: FromCompositeFieldPath
fromFieldPath: metadata.labels[team]
toFieldPath: spec.forProvider.tags[team]
- type: FromCompositeFieldPath
fromFieldPath: metadata.labels[cost-centre]
toFieldPath: spec.forProvider.tags[cost-centre]
- type: FromCompositeFieldPath
fromFieldPath: metadata.labels[environment]
toFieldPath: spec.forProvider.tags[environment]
# Add a managed-by tag to identify all IDP-provisioned resources
- type: FromCompositeFieldPath
fromFieldPath: metadata.name
toFieldPath: spec.forProvider.tags[managed-by]
transforms:
- type: string
string:
fmt: "idp-crossplane"
6.2 لاگت سے متعلق استفسار
تمام وسائل کے لیے مطلوبہ ٹیگز آپ کو AWS Cost Explorer سے براہ راست ٹیم کے ذریعے اصل اخراجات کے بارے میں استفسار کرنے کی اجازت دیتا ہے۔
# Monthly cost breakdown by team — all IDP-provisioned resources
aws ce get-cost-and-usage \
--time-period Start=$(date -d 'last month' +%Y-%m-01),End=$(date +%Y-%m-01) \
--granularity MONTHLY \
--filter '{
"Tags": {
"Key": "managed-by",
"Values": ["idp-crossplane"]
}
}' \
--group-by Type=TAG,Key=team \
--metrics UnblendedCost \
--query 'ResultsByTime[0].Groups[*].{Team:Keys[0],Cost:Metrics.UnblendedCost.Amount}' \
--output table
تمام ٹیمیں جو آئی ڈی پی کے ذریعے وسائل فراہم کرتی ہیں اب ان کی لاگت کی رپورٹوں پر ان کی ٹیم کے نام کے ساتھ ایک لائن ہوگی۔ یہ ایک چارج بیک ماڈل ہے جو FinOps کو پلیٹ فارم پیمانے پر پائیدار بناتا ہے۔ شراکتیں خودکار ہیں، دستی نہیں۔
حصہ 7: پلیٹ فارم میچورٹی ماڈل – آپ نے جو بنایا ہے اس کی پیمائش کریں۔
CNCF پلیٹ فارم انجینئرنگ میچورٹی ماڈل پلیٹ فارم کی پختگی کی پانچ سطحوں کی وضاحت کرتا ہے: آپ کہاں ہیں یہ جاننا آپ کو یہ فیصلہ کرنے میں مدد کرتا ہے کہ اگلا کیا بنانا ہے اور انجینئرنگ لیڈروں کو پیشرفت سے آگاہ کرنا ہے۔
| پانی کی سطح | نام | خصوصیات |
|---|---|---|
| 1 | عارضی | کوئی ایڈہاک اسکرپٹس نہیں، کوئی دستی فراہمی نہیں، کوئی معیاری ٹولز نہیں۔ |
| 2 | کام | معیاری ٹولز، کچھ آٹومیشن، Kubernetes کا استعمال کرتے ہوئے |
| 3 | قابل توسیع | سیلف سروس پورٹل، GitOps سے چلنے والا، دستاویزی گولڈن پاتھ |
| 4 | اصلاح | لاگت کا انتساب، خود پلیٹ فارم کا SLO، صارف کی رائے کا لوپ |
| 5 | آپٹمائزڈ | AI کی مدد سے فراہمی، پیشن گوئی کی پیمائش، اور مکمل FinOps انضمام |
آپ مکمل Backstage + ArgoCD + Crossplane نفاذ کے ساتھ لیول 3 تک پہنچ جائیں گے، لاگت کے انتساب اور سافٹ ویئر ٹیمپلیٹس کے ساتھ مکمل جو سب سے عام ڈویلپر کی درخواستوں کو پورا کرتے ہیں۔ لیول 4 پر جانے کے لیے پلیٹ فارم کی صحت کے بارے میں SLO الرٹس شامل کرنے، سہ ماہی ڈویلپر کے تجربے کے سروے چلانے، اور انتساب ٹیگز سے ٹیم کے لیے مخصوص لاگت کی رپورٹس تیار کرنے کی ضرورت ہوتی ہے۔
لیول 3 میں سب سے عام غلطی گود لینے کی پیمائش کرنے کے بجائے مزید خصوصیات بنانا ہے۔ ایک پلیٹ فارم جس میں 12 سافٹ ویئر ٹیمپلیٹس ہیں لیکن باقاعدگی سے استعمال ہونے والے صرف 2 لیول 3 تک نہیں پہنچے۔ ہم مزید YAML سمیت لیول 2 پر پہنچ گئے ہیں۔ پیمائش کریں کہ کون سے سنہری راستے استعمال کیے جا رہے ہیں، ڈویلپرز کا انٹرویو کریں جو پورٹل استعمال نہیں کر رہے ہیں، اور خصوصیات شامل کرنے سے پہلے رگڑ کو دور کریں۔
بہترین طریقوں کا خلاصہ
کرنا: انہیں ترتیب سے بنائیں۔ سب سے پہلے، یہ ArgoCD، Crossplane، اور Backstage پر مشتمل ہے۔ ہر پرت پچھلی پرت پر منحصر ہے۔
کرنا: بیک اسٹیج کو بطور گٹ کمٹ جنریٹر استعمال کریں، نہ کہ انفراسٹرکچر کالر کے طور پر۔ تمام بنیادی ڈھانچے کی تبدیلیاں قابل آڈٹ ہونی چاہئیں گٹ کمٹ۔
کرنا: کراس پلین کمپوزیشن لیئرز پر لاگت کے انتساب کے ٹیگز لگائیں، ڈویلپر کے دعووں پر نہیں۔ کوئی بھی انتساب جو ڈویلپر کے ذریعہ نظرانداز کیا جاسکتا ہے اسے نظرانداز کردیا جائے گا۔
کرنا: دو یا تین سافٹ ویئر ٹیمپلیٹس کے ساتھ شروع کریں اور مزید بنانے سے پہلے انہیں اچھا بنائیں۔ ٹیمپلیٹ کو اپنانا سب سے اہم ابتدائی اشارے ہے۔
کرنا: پہلے دن سے اپنی تمام خدمات کو بیک اسٹیج کیٹلاگ میں رجسٹر کریں۔ کیٹلاگ کی قدر اس کے دائرہ کار کے متناسب ہے۔
کرنا: ArgoCD کے ذریعے اپنے کلسٹر کو کراسپلین فراہم کریں۔ helm install. ہر وہ چیز جس کا IDP انتظام کرتا ہے خود IDP کے ذریعے انتظام کیا جانا چاہیے۔
مت کرو: Backstage کو براہ راست کلاؤڈ APIs سے مربوط کریں۔ کوئی آڈٹ ٹریل، رول بیکس، یا مفاہمتیں نہیں ہیں۔
مت کرو: Crossplane XRD براہ راست ڈویلپرز کو فراہم کریں۔ آر ڈی ایس کی مخصوص ساخت کو چھپانے اور پلیٹ فارم کے معیارات کو نافذ کرنے کے لیے کمپوزیشن خلاصہ موجود ہے۔ اس کو نظرانداز کرنے سے مقصد ختم ہو جاتا ہے۔
مت کرو: IDP کو آزادانہ طور پر بنائیں اور مکمل ہونے پر اسے مطلع کریں۔ پلیٹ فارم انجینئرنگ پروڈکٹ انجینئرنگ ہے۔ پہلے دو ٹیمپلیٹس کے فعال ہونے کے بعد صارف کے انٹرویوز کا شیڈول بنائیں۔
مت کرو: ArgoCD RBAC کنفیگریشن کو چھوڑ دیں۔ ڈیلیوری لیئر کے ذریعے ہر ڈویلپر کو کلسٹر مینیجر فراہم کرنے والے IDPs نے ان کے حل کیے جانے سے کہیں زیادہ سیکیورٹی کے مسائل پیدا کیے ہیں۔