Homelab سے AWS تک پروڈکشن کے لیے تیار DevSecOps پلیٹ فارم کیسے بنایا جائے۔ [Full Book]

اس کتاب میں، آپ شروع سے فنٹیک ٹرانزیکشن لیجر بناتے ہیں اور آہستہ آہستہ اسے پروڈکشن کے لیے تیار DevSecOps پلیٹ فارم میں تبدیل کرتے ہیں۔ ہم اسے AWS پر بھی تعینات کرتے ہیں۔

ایپ کریڈٹ اور ڈیبٹ لین دین پر کارروائی کرتی ہے، تعمیل کے انتباہات کو بڑھاتی ہے، اور ہر چیز کو ڈیٹا بیس میں اسٹور کرتی ہے۔ آپ بنیادی ڈھانچہ خود بنائیں گے، بشمول آٹومیشن، دریافت، پالیسی کا نفاذ، راز کا انتظام، خطرے کا پتہ لگانا، اور مشاہدہ۔

انٹرویو کے اختتام تک، آپ انٹرویو میں کیے گئے تمام فیصلوں کے بارے میں بات کر سکیں گے۔ کیونکہ ہر فیصلہ آپ نے کرنا ہے۔

یہ گائیڈ پہلے سے تیار کردہ حل فراہم نہیں کرتا ہے۔ یہ مجھے بہتر محسوس کرتا ہے۔ ہر مسئلے کو حل کرنے والے ٹول کو متعارف کرانے سے پہلے سمجھیں۔

تمام کوڈ، مینی فیسٹس، اسکرپٹس، اور مرحلہ وار READMEs ساتھ والے ذخیرے میں ہیں۔ شروع کرنے سے پہلے کلون کریں۔

git clone https://github.com/Osomudeya/clearledger.git
cd clearledger

اس کتاب کی ہر چیز اس ذخیرہ کے اندر موجود فائلوں کا حوالہ دیتی ہے۔

شرطیں

مرحلہ 0 سے پہلے، آپ کو اپنے کمپیوٹر پر درج ذیل ٹولز انسٹال کرنا ہوں گے۔

• ملٹی پاس: ایک ہلکا پھلکا Ubuntu VM بنائیں تاکہ یہ یقینی بنایا جا سکے کہ Kubernetes کے پاس کافی وسائل ہیں۔

• kubectl: ٹرمینل سے اپنے Kubernetes کلسٹر کے ساتھ بات چیت کریں۔

• کنٹرول: Kubernetes پر ایپ انسٹال کریں۔

• ڈاکر ڈیسک ٹاپ: کنٹینر کی تصویر بنائیں

• jq: JSON آؤٹ پٹ کو فارمیٹ کریں تاکہ یہ پڑھنے کے قابل ہو۔

GitHub اور Docker Hub کو بھی مفت اکاؤنٹس کی ضرورت ہوتی ہے۔

آپ کو درج ذیل علم اور ہنر میں بھی ماہر ہونا چاہیے:

• بنیادی لینکس کمانڈ لائن: ڈائریکٹریز براؤز کریں، فائلیں پڑھیں، سکرپٹ چلائیں۔

• خوش ہونا: کلون، کمٹ، پش

• کنٹینرز کیا ہیں اور ڈوکر انہیں کیسے بناتا ہے؟

کوئی سابقہ ​​Kubernetes، سیکورٹی، یا کلاؤڈ تجربہ درکار نہیں ہے۔ یہ گائیڈ اسے اسٹیج 0 سے بناتا ہے۔

آپ کی مشین کو کم از کم 24 GB RAM، 6 CPU کور، اور 80 GB مفت ڈسک کی جگہ درکار ہے۔ تنصیب کی درست ہدایات کے لیے، اپنے کمپیوٹر کو سیٹ اپ کرنے کا طریقہ دیکھیں۔

ساتھی ذخیرہ github.com/Osomudeya/clearledger پر ہے۔ اسے ستارہ بنائیں، اسے نقل کریں، اور جاری رکھیں۔

انڈیکس

آپ کیا بنا رہے ہیں

ClearLedger ایک فنٹیک ٹرانزیکشن لیجر ہے جو تین FastAPI مائیکرو سروسز، PostgreSQL، Redis، اور ایک ویب فرنٹ اینڈ کے ساتھ بنایا گیا ہے۔

صارف رجسٹر کر سکتے ہیں، لاگ ان کر سکتے ہیں، کریڈٹ اور ڈیبٹ لین دین کو ریکارڈ کر سکتے ہیں، اکاؤنٹ بیلنس دیکھ سکتے ہیں، اور جب بھی لین دین پہلے سے طے شدہ حد سے تجاوز کر جائے تو تعمیل کی اطلاعات موصول کر سکتے ہیں۔

درخواست جان بوجھ کر آسان ہے۔ مقصد فنٹیک کو پڑھانا نہیں ہے۔ یہ ایک حقیقت پسندانہ نظام فراہم کرتا ہے جسے پروڈکشن پلیٹ فارم کی طرح محفوظ اور چلایا جا سکتا ہے۔

یہ منصوبہ چار اجزاء پر مشتمل ہے:

• تصدیق کی خدمات: صارف کی رجسٹریشن، لاگ ان، اور JWT تصدیق کو ہینڈل کرتا ہے۔

• لیجر خدمات: لین دین پر کارروائی کرتا ہے، اکاؤنٹ کے بیلنس کو برقرار رکھتا ہے، اور لین دین کی تاریخ کو اسٹور کرتا ہے۔

• اطلاع کی خدمت: Redis کے ذریعے بڑے لین دین حاصل کریں اور تعمیل کے انتباہات تیار کریں۔

• فرنٹ اینڈ: لاگ ان کرنے، بیلنس دیکھنے، لین دین جمع کرانے اور اطلاعات کا جائزہ لینے کے لیے ایک ویب انٹرفیس۔

اس کتاب کے اختتام تک، یہ تمام خدمات اب بھی موجود رہیں گی۔ جو تبدیلی آئی ہے وہ یہ ہے کہ ہم کس طرح تعمیر، تعینات، محفوظ اور کام کرتے ہیں۔

درخواست صرف ایک گاڑی ہے۔ DevSecOps منزل ہے۔

پلیٹ فارم کیسے تیار ہوتے ہیں۔

ہم پہلے دن تمام ٹولز انسٹال نہیں کرتے ہیں۔ اس کے بجائے، پلیٹ فارم عام طور پر اسی طرح بڑھتے ہیں جیسے پروڈکشن سسٹم۔ یعنی مسئلہ پہلے ظاہر ہوتا ہے پھر حل پیش کیا جاتا ہے۔

دستی طور پر تعینات Kubernetes ایپلیکیشن کے ساتھ شروع کریں۔ وہاں سے، ہر قدم ایک حقیقی آپریشنل مسئلہ حل کرتا ہے۔

مرحلہ 0: خام کبرنیٹس

اپنی ایپلیکیشنز کو دستی طور پر تعینات اور چلائیں تاکہ آپ آٹومیشن متعارف کرانے سے پہلے سسٹم کو سمجھ سکیں۔

مرحلہ 1: مسلسل انضمام

کنٹینر امیج بلڈنگ خود بخود ہوتی ہے جب بھی کوڈ کو آگے بڑھایا جاتا ہے، دستی تعمیراتی مراحل کی ضرورت کو ختم کرتا ہے۔

مرحلہ 2: GitOps

تعیناتیاں اب kubectl کے استعمال سے نہیں کی جاتی ہیں۔ گٹ سچائی کا واحد ذریعہ بن کر ترتیب کے بڑھنے کو روکتا ہے۔

مرحلہ 3: سیکیورٹی گیٹ

ہر کمٹ سیکیورٹی چیک پاس کرتا ہے، لہذا تعیناتی سے پہلے کمزور کوڈ، راز اور غلط کنفیگریشنز کو روک دیا جاتا ہے۔

مرحلہ 4: داخلہ کنٹرول

یہاں تک کہ اگر آپ پائپ لائن کو نظرانداز کرتے ہیں، تو Kubernetes کی پالیسیاں غیر محفوظ کام کے بوجھ کو آپ کے کلسٹر میں داخل ہونے سے روکتی ہیں۔

مرحلہ 5: خفیہ انتظام

Git اور کلسٹر اسٹوریج سے حساس ڈیٹا کو ہٹاتے ہوئے، ایپلیکیشن کی اسناد کوبرنیٹس سیکرٹس سے والٹ میں منتقل کر دیا گیا ہے۔

مرحلہ 6: رن ٹائم سیکیورٹی

Falco چلتے ہوئے کنٹینرز کی مسلسل نگرانی کرتا ہے اور تعیناتی کے بعد مشکوک رویے کا پتہ لگاتا ہے۔

مرحلہ 6.5 (اختیاری): افراتفری انجینئرنگ

صرف مسائل کا پتہ لگانے کے بجائے، ہم جان بوجھ کر غلطیاں متعارف کراتے ہیں تاکہ یہ یقینی بنایا جا سکے کہ پلیٹ فارم ٹھیک ہو سکتا ہے۔

مرحلہ 7: مشاہدہ

میٹرکس، لاگز، اور ڈیش بورڈز آپ کے پلیٹ فارم کی صحت، کارکردگی، اور سیکیورٹی میں مرئیت فراہم کرتے ہیں۔

مرحلہ 7.5 (اختیاری): OpenTelemetry

تقسیم شدہ ٹریسنگ تمام سروسز سے درخواستوں کو ٹریک کرتا ہے، جس سے یہ ظاہر ہوتا ہے کہ سسٹم کے ذریعے ایک ہی لین دین کیسے چلتا ہے۔

مرحلہ 8: AWS مائیگریشن

اسی فن تعمیر کو AWS پر EKS, ECR, RDS، اور ایپلیکیشن لوڈ بیلنسر کا استعمال کرتے ہوئے تعینات کیا جاتا ہے بغیر یہ کہ ایپلی کیشن خود کیسے کام کرتی ہے۔

اگر آپ Kubernetes استعمال کرنے سے پہلے صرف ایپلی کیشنز کو تلاش کرنا چاہتے ہیں، اختیاری Docker Compose stack آپ کو اپنے کمپیوٹر پر ہر چیز کو مقامی طور پر چلانے دیتا ہے۔

اس کتاب کے بنیادی اصول سادہ ہیں۔ ہر قدم پر، آپ کو اس مسئلے کا احساس ہوتا ہے اس سے پہلے کہ آپ اسے حل کرنے والے ٹولز سے متعارف کرائے جائیں۔

اس لیب کو کیسے کرنا ہے۔

ہر مسئلے کو حل کرنے کے اوزار متعارف کرانے سے پہلے اسے سمجھنے کے پورے عمل کے دوران، تین عادات آپ کو ہر قدم پر حاصل کریں گی۔

1. ایسا کرنے سے پہلے اسے پڑھیں۔ ہر کمانڈ کی وضاحت اس سے پہلے والے پیراگراف میں کی گئی ہے۔ کیوں آپ اسے چلا رہے ہیں۔ اس کو چھوڑنے کا مطلب ہے کہ آپ اقدامات کو دوبارہ پیش کر سکتے ہیں لیکن ان کی وضاحت نہیں کر سکتے، اور اگر آپ ان کی وضاحت کرتے ہیں تو آپ کو ملازمت پر رکھا جا سکتا ہے۔ احکام اس بات کا ثبوت ہیں کہ آپ سمجھتے ہیں۔

2. براہ کرم ایک وجہ منتخب کریں: یہاں ہر ٹول ایک مخصوص مسئلہ حل کرتا ہے۔ کبرنیٹس سیکریٹ کے بجائے والٹ کیوں استعمال کریں؟ اپنے کوڈ اور مینی فیسٹ کو دو ذخیروں میں کیوں تقسیم کریں؟ صرف ان اقدامات پر عمل نہ کریں، پوچھیں۔ اگر میں اسے چھوڑ دوں تو کیا ہوگا؟ مسئلہ کو سمجھنے سے آپ کو حل یاد رکھنے میں مدد ملتی ہے۔

3. ترتیب سے ان کے ذریعے جائیں اور تمام چوکیوں کو چیک کریں۔ ہر قدم پچھلے مرحلے پر منحصر ہے۔ اگر آپ کو مسائل درپیش ہیں تو غلطیاں پڑھیں۔ پھنس جانا اور ڈیبگ کرنا سیکھنے کا حصہ ہے۔ آجر سننا چاہتے ہیں، "X کی خرابی پیش آ گئی اور ہم نے اسے Y کر کے ٹھیک کر دیا۔”

ہر پریکٹس چیک پوائنٹ پر:

1. کمانڈ چلائیں:

2. اپنی توقعات کے ساتھ آؤٹ پٹ کا موازنہ کریں۔

3. اگر وہ مماثل نہیں ہیں، تو جاری رکھنے سے پہلے انہیں درست کریں۔

4. جب make check-N گزرنا: make snapshot STAGE=N && make snapshots. دیکھنے کے بعد ہی جاری رکھیں۔ clearledger.stageN.

ان غلطیوں سے بچیں:

• کسی چوکی کو صرف اس لیے نہ چھوڑیں کہ آپ اسے پہلے گزر چکے ہیں۔

• مت بھاگو make restore پہلے دستیاب سنیپ شاٹس کی جانچ کیے بغیر

• تبدیلی your-username اپنا اصل Docker Hub یا GitHub صارف نام جہاں بھی ظاہر ہوتا ہے استعمال کریں۔

• VM کے اندر لانچر کمانڈ چلائیں (ڈسپلے پرامپٹ) ubuntu@clearledger)، میک پر نہیں۔

ہر ایک کا اسکرین شاٹ لیں۔ پورٹ فولیو چیک پوائنٹس. یہ لمحات ثبوت ہیں۔ اس بات کا ثبوت کہ پلیٹ فارم حقیقی دنیا کی سرگرمیوں کو انجام دیتا ہے، پتہ لگاتا ہے، بلاک کرتا ہے، ہم آہنگی کرتا ہے اور مشاہدہ کرتا ہے۔

اگر آپ کو کوئی نیا نام نظر آتا ہے اور تجسس پیدا ہوتا ہے تو نیچے دیے گئے ٹیبل پر واپس آئیں۔ اب کیوں؟. ہر آئٹم کی ایک لائن ہوتی ہے جو بتاتی ہے کہ یہ کیا کرتا ہے اور کب ظاہر ہوگا۔

آپ کے لیپ ٹاپ پر:

• ملٹی پاس ایک Ubuntu VM بناتا ہے۔

• ڈوکر تصویر بناتا ہے۔

• make لمبے حکموں کو اس کے ساتھ لپیٹیں: make setup / make check-N.

• /etc/hosts اشیاء جیسے clearledger.local اپنے براؤزر کو اپنے کلسٹر تک پہنچنے دیں۔

ایپ:

• تین Python APIs (تصدیق، لیجر، اطلاع) + ویب فرنٹ اینڈ۔

• پوسٹگریس ڈیٹا اسٹور کرتا ہے۔

• ریڈیس لیجر کو نوٹیفیکیشن کو براہ راست طلب کیے بغیر اطلاعات شائع کرنے کی اجازت دیتا ہے۔

• nginx ingress براؤزر ٹریفک کو درست سروس کی طرف لے جاتا ہے۔

سامان	ایک لائن کردار	قدم
MicroK8s/kubectl	VM کے اندر Kubernetes کلسٹر: kubectl اس کے بارے میں بات کریں۔	0
clearledger (ریپو)	ایپ کوڈ + CI ورک فلو: آپ کیا بناتے ہیں۔	1
clearledger-infra (ریپو)	Kubernetes YAML صرف: کلسٹر کو چلانے کی کیا ضرورت ہے۔ CI اسے اپ ڈیٹ کرتا ہے اور ArgoCD اسے تقسیم کرتا ہے۔	1
GitHub ایکشنز + خود میزبان لانچر	ہر دھکا امیج بناتا ہے اور انفراسٹرکچر ریپوزٹری کو اپ ڈیٹ کرتا ہے۔ دوڑنے والے VMs پر رہتے ہیں اور مقامی کلسٹر تک پہنچتے ہیں۔	1
آرگو سی ڈی	گھڑی clearledger-infraاپنے کلسٹر کو Git سے ملنے اور غیر مجاز تبدیلیوں کو واپس کرنے کے لیے مطابقت پذیر بنائیں۔	2
گٹلیکس	رازوں پر مشتمل کمٹ کو بلاک کریں (API کیز، ٹوکنز)۔	3
شیمگریب	SAST: Python کے غیر محفوظ نمونوں کو پکڑتا ہے (ایمبیڈڈ، ہارڈ کوڈ شدہ اسناد)۔	3
چیکر	IaC اسکیننگ: Dockerfiles اور Kubernetes YAML کی غلط کنفیگریشن۔	3
کوئز	تصویری اسکیننگ: پائپ/npm پیکجوں اور بلٹ کنٹینرز میں معلوم CVEs۔	3
سیفٹ + گرپ	SBOM تیار کریں اور نمونے میں ہی کمزوریوں کی جانچ کریں۔	3
مشترکہ نشان	کنٹینر کی تصاویر پر دستخط کریں: مرحلہ 4 تعینات ہونے پر غیر دستخط شدہ تصاویر کو مسترد کرتا ہے۔	3
کیبرنو	داخلہ کنٹرول: کلسٹر گیٹ پر نان کمپلائنٹ پوڈز کو بلاک کریں (روٹ کنٹینر، گمشدہ پابندیاں، غیر دستخط شدہ تصاویر)۔	4
والٹ	Git اور etcd کے باہر اسناد کو اسٹور کریں۔ اسناد کو سٹارٹ اپ پر سائڈ کار کے ذریعے پوڈ میں داخل کیا جاتا ہے۔	5
فالکو	ای بی پی ایف رن ٹائم کا پتہ لگانا: جب کوئی شیل چلتے ہوئے کنٹینر کے اندر حساس فائلوں کو شروع یا پڑھتا ہے تو الرٹ۔	6
نیٹ ورک کی پالیسی	انٹر پوڈ کبرنیٹس فائر وال: اگر ایک سروس سے سمجھوتہ کیا جاتا ہے تو دھماکے کے رداس کو محدود کرتا ہے۔	6
LitmusChaos	یہ ثابت کرنے کے لیے پوڈ کو جان بوجھ کر ختم کر دیں کہ ایپ بازیافت ہو گئی ہے (اختیاری)۔	6.5
پرومیتھیس/گرافانا/لوکی	میٹرکس، ڈیش بورڈز، اور لاگ سرچز: سیکیورٹی ایونٹس کو ثبوت میں تبدیل کریں۔	7
اوپن ٹیلی میٹری + ٹیمپو	تقسیم شدہ ٹریکنگ: دکھاتا ہے جہاں ایک درخواست اپنا وقت تمام سروسز میں صرف کرتی ہے (اختیاری)۔	7.5
Terraform/EKS/ECR/RDS	AWS منتقلی کے لیے بنیادی ڈھانچہ بطور کوڈ: وہی ایپس، کلاؤڈ مینجمنٹ سپورٹ سروسز۔	8

ہر قدم سیکورٹی کی ایک نئی پرت کا اضافہ کرتا ہے۔ اوزار قابل تبادلہ نہیں ہیں۔ سکینر تعیناتی سے پہلے کوڈ اور امیجز کو چیک کرتا ہے، ArgoCD کلسٹرز کو Git سے ہم آہنگ کرتا ہے، Vault رازوں کو سنبھالتا ہے، Kyverno غیر محفوظ کام کے بوجھ کو چلانے سے پہلے روکتا ہے، اور Falco عملدرآمد کے بعد مشکوک رویے پر نظر رکھتا ہے۔

اس لیے آرڈر اہم ہے۔ یہ ایک وقت میں ایک تہہ کی گہرائی میں دفاع کی تعمیر کے بارے میں ہے۔

راستے کا انتخاب کیسے کریں۔

کلسٹر کی فراہمی سے پہلے میزبان RAM سے ایک راستہ منتخب کریں۔ اگر OOM کے خاتمے یا ڈسک کے دباؤ کی وجہ سے ایک دن ضائع ہوتا ہے، تو ہم لیبز کو درمیان میں تبدیل کر دیں گے، اس لیے پہلے سے انتخاب کریں۔

آپ کی حالت	سڑک	آپ کو کیا ملتا ہے
8 جی بی ریمیا، مجھے یقین نہیں ہے کہ آیا یہ لیپ ٹاپ لیب لے جا سکتا ہے۔	پہلے ڈوکر کمپوز کریں۔	اصلی ایپ: رجسٹریشن، پوسٹ لین دین، اور تعمیل کے الرٹس کو متحرک کریں۔ پھر کلسٹر کا فیصلہ کریں۔ make integration-up · مقامی انضمام اسٹیک
16 جی بی ریم میزبان سے	ہلکا مقامی کلسٹر (سطح 0~5)	ایک VM پر چل رہا ہے: اس سیٹ اپ میں Kubernetes، CI/CD، GitOps، سیکیورٹی چیک، داخلہ کنٹرول، اور والٹ شامل ہیں۔ کم وسائل استعمال کرنے کے لیے ترمیم کریں۔ scripts/setup-cluster.local.env چلانے سے پہلے make setup.
16GB سے کم اگر آپ RAM کی میزبانی کرتے ہیں اور آپ کو Kubernetes کی ضرورت ہے یا آپ تمام 8 مراحل چاہتے ہیں۔	کلاؤڈ VM	ایک ریموٹ مشین فراہم کریں (4-8 vCPU، 16-32 GB RAM)، اسٹوریج کو کلون کریں، اور وہاں لیب چلائیں۔ make teardown ایک بار مکمل۔ مراحل 6.5/7/7.5 (Chaos + مکمل مشاہداتی) میزبان پر 24GB کی ضرورت ہے۔ اگر آپ کا لیپ ٹاپ اس کا متحمل نہیں ہے تو اس راستے پر جائیں۔

اس گائیڈ میں طے شدہ راستہ کم از کم 24 GB RAM اور مکمل طور پر مقامی VM (آپ کے شروع کرنے سے پہلے) فرض کرتا ہے۔ اگر یہ آپ نہیں ہیں، تو اس لائن سے شروع کریں جو آپ کے کمپیوٹر سے ملتی ہے۔

اپنی ترقی کو کیسے بچایا جائے۔

صرف میک + ملٹی پاس: make snapshot اور make restore ملٹی پاس کی ضرورت ہے۔ اگر آپ ملٹی پاتھ کے بغیر لینکس استعمال کر رہے ہیں، تو سنیپ شاٹ کو چھوڑ دیں اور اگر آپ کو پریشانی ہو تو پاتھ B استعمال کریں۔

اس لیب کو مکمل ہونے میں کئی دن لگیں گے۔

چونکہ سورس کوڈ آپ کے کمپیوٹر پر موجود ہے، اس لیے VM کو دوبارہ بنانے یا حذف کرنے سے آپ کے Git ذخیرہ، کمٹ، مینی فیسٹ، یا کنفیگریشن فائلیں حذف نہیں ہوتی ہیں۔

VM عملدرآمد کے ماحول کو ذخیرہ کرتا ہے، بشمول تعینات پوڈز، والٹ سیکرٹس، پوسٹگریس ڈیٹا، اور گرافانا ڈیش بورڈز۔

اپنی ترقی کو بچائیں۔

ہر مرحلہ مکمل کرنے کے بعد، جاری رکھنے سے پہلے اسنیپ شاٹ بنائیں۔ مثال کے طور پر:

make snapshot STAGE=7
make snapshots

ہمیشہ چلائیں make snapshots تصدیق کریں کہ سنیپ شاٹ بن گیا تھا۔

اپنی ترقی کو بحال کریں۔

اگر آپ کا VM تھوڑی دیر کے بعد دستیاب نہ ہو جائے تو تازہ ترین ورکنگ اسنیپ شاٹ کو بحال کریں۔

make snapshots
make restore STAGE=7

export KUBECONFIG=~/.kube/clearledger-config
make check-7

اگر VM نیچے چلا جائے تو کیا ہوتا ہے؟

آپ برقرار رکھتے ہیں:

آپ آخری اسنیپ شاٹ کے بعد سے VM کے اندر ذخیرہ کردہ ہر چیز کو کھو دیں گے، بشمول:

• چلنے والی پھلی

• والٹ سیکریٹ

• پوسٹگریس ڈیٹا

• گرافانا اور ڈیٹا روم

اس لیے ہر قدم مکمل ہونے کے بعد اسنیپ شاٹ بنانا اچھا خیال ہے۔

راستہ A: اسنیپ شاٹ لیں (تجویز کردہ)

تازہ ترین ورکنگ اسنیپ شاٹ کو بحال کریں اور اس مرحلے سے جاری رکھیں۔

make snapshots
make restore STAGE=6

export KUBECONFIG=~/.kube/clearledger-config
make check-6

پاتھ بی: کوئی سنیپ شاٹ نہیں۔

اپنی لیبارٹری کو دوبارہ بنائیں۔

make teardown
make setup

export KUBECONFIG=~/.kube/clearledger-config

آپ کا Git ذخیرہ برقرار رہے گا، لیکن آپ کا Kubernetes کلسٹر خالی ہونا شروع ہو جائے گا۔ کتاب کو اس سطح سے جاری رکھیں جس سطح پر آپ پہنچے اور وہاں سے اپنا پلیٹ فارم دوبارہ بنائیں۔

اگر آپ کو ڈسک کی جگہ کے مسائل، اسنیپ شاٹ کی ناکامی، میک سلیپنگ یا دوبارہ شروع کرنے کے مسائل، والٹ کی توثیق کی خرابیاں، یا CrashLoopBackOff میں پھنسے ہوئے Pods جیسے مسائل کا سامنا ہے، تو تفصیلی بحالی کے اقدامات کے لیے Troubleshooting.md دیکھیں۔

یہ کس کے لیے ہے؟

جونیئر ڈی او اوپس (0-2 سال): ترتیب میں تمام مراحل پر عمل کریں۔ مسائل کے سیکشن کو مت چھوڑیں۔ لیول 0 سے 2 میں ہر ایک کو پورا دن لگنے کی امید ہے، لیول 3 سے 7 میں ہر ایک کو آدھا دن لگنے کی امید ہے، اور لیول 8 میں کئی گھنٹے لگنے کی امید ہے۔ یہ عام بات ہے، اس لیے جلدی نہ کریں۔

مڈ لیول ڈی اوپس (2-4 سال): ایپ کو سمجھنے کے لیے 0-2 کے مراحل کو ختم کریں، پھر 3-7 مراحل پر توجہ مرکوز کریں جہاں حفاظتی پرتیں واقع ہیں۔

انٹرویو کی تیاری: مرحلہ 4 مکمل کرنے کے بعد پڑھیں۔ docs/interview-prep.md. سوالات بالکل اس لیب کے مواد پر مبنی ہیں۔

اپنے آلے کو کیسے ترتیب دیں۔

ضروریات اوپر دی گئی شرائط میں ہیں۔ انسٹال کرنے سے پہلے، یقینی بنائیں کہ آپ کے پاس 24 جی بی ریم، 6 سی پی یو کور، اور 80 جی بی فری ڈسک ہے۔

مطلوبہ ٹولز انسٹال کریں۔

سامان	فنکشن	macOS	لینکس	کھڑکیاں
کثیر پاس	اپنے لیپ ٹاپ پر ہلکا پھلکا Ubuntu VM بنائیں۔	brew install --cask multipass	sudo snap install multipass	ملٹی پاس۔ چلائیں/انسٹال کریں۔
کیوبیکٹل	ٹرمینل سے اپنے Kubernetes کلسٹر کے ساتھ بات چیت کریں۔	brew install kubectl	sudo snap install kubectl --classic	winget install Kubernetes.kubectl
کنٹرول	کبرنیٹس کے لیے پیکیج مینیجر (اپٹ/بریو کی طرح، لیکن کلسٹر ایپس کے لیے)	brew install helm	sudo snap install helm --classic	winget install Helm.Helm
ڈاکر ڈیسک ٹاپ	اپنی مشین پر کنٹینر کی تصویر بنائیں۔	docker.com	docker.com	docker.com
jq	JSON آؤٹ پٹ کو فارمیٹ کریں تاکہ یہ پڑھنے کے قابل ہو۔	brew install jq	sudo apt install jq	winget install jqlang.jq

ونڈوز صارفین: WSL2 Ubuntu کے اندر سے تمام کمانڈز چلائیں۔ سیٹ اپ پاور شیل کا استعمال کرتا ہے، لہذا اس لیب میں پاور شیل استعمال نہ کریں۔ make اور ایک باش اسکرپٹ۔

جاری رکھنے سے پہلے سب کچھ چیک کریں۔

multipass --version
kubectl version --client
helm version
docker --version
jq --version

اگر کمانڈ ناکام ہو جاتی ہے تو جاری رکھنے سے پہلے کوئی گمشدہ ٹولز انسٹال کریں۔

پریکٹس کیسے شروع کی جائے۔

پہلے سے طے شدہ لیب کا راستہ مرحلہ 0 سے شروع ہوتا ہے: رننگ سسٹم۔

ایک بار مرحلہ وار سیٹ اپ چلانے کے بعد، آپ اگلی بار اس شارٹ کٹ کو استعمال کر سکتے ہیں۔

make setup
export KUBECONFIG=~/.kube/clearledger-config
kubectl get nodes

متوقع: 1 نامزد نوڈ clearledger STATUS پر مشتمل ہے۔ Ready.

make setup ملٹی پاس VMs کی فراہمی، MicroK8s انسٹال کریں، ڈسک کی حفاظت کی پابندیوں کو نافذ اور اپ ڈیٹ کریں /etc/hosts. اس میں تقریباً 3 سے 5 منٹ لگتے ہیں۔

ڈسک کی جگہ کا انتظام کیسے کریں۔

لیب ایک فکسڈ ڈسک (80GB بذریعہ ڈیفالٹ) کے ساتھ سنگل نوڈ MicroK8s VM پر چلتی ہے۔ کنٹینر کی تصاویر، لاگز، اور جرائد روٹ فائل سسٹم کو کئی دنوں یا ہفتوں تک بھر سکتے ہیں (خاص طور پر CI کی تعمیر، ہیلم اپ گریڈ، اور مرحلہ 7 کا مشاہدہ کرنے کے بعد)۔ پھر پوڈ اس کے ساتھ ناکام ہوجاتا ہے: Evicted, ImagePullBackOffیا پراسرار؟ Pending صورت حال

make setup خود بخود روک تھام کی حدود (لاگ روٹیشن، امیج جی سی تھریشولڈ، جرنلنگ کی حدود) کو نافذ کرتا ہے۔ مکمل جدول اور بحالی کے اقدامات کے لیے، Disk Health in Troubleshooting.md دیکھیں۔

ڈسک کی حیثیت کو چیک کریں۔

make doctor    # PASS / WARN / FAIL + PVC and Prometheus TSDB sizes

ایپ ڈیٹا کو حذف کیے بغیر VM کے اندر غیر استعمال شدہ فائلوں کو صاف کرتا ہے۔

make reclaim

اگر make doctor یہ ضروری ہو سکتا ہے اگر یہ یاد کرنے کے بعد بھی FAIL کی اطلاع دیتا ہے۔ make teardown && make setup سنیپ شاٹ سے بحال کریں۔ مکمل ہدایات: Troubleshooting.md. VM ڈسک بھری ہوئی ہے۔

کبرنیٹس کے بغیر ایپ کو آزمانے کا طریقہ

اگر آپ کی مشین میں Kubernetes کے لیے کافی وسائل نہیں ہیں، تو آپ Docker Compose کا استعمال کرکے ClearLedger چلا سکتے ہیں۔

docker compose -f docker-compose.integration.yml up --build -d

http://localhost:3000 کھولیں۔

جب آپ تیار ہوں تو اسٹیک کو روکیں اور مرحلہ 0 کے ساتھ جاری رکھیں۔

docker compose -f docker-compose.integration.yml down

پہلی بار لاگ ان کرنے کا طریقہ

سب سے پہلے، آپ کو رجسٹر کرنا ہوگا. جب بھی میں ریفریش کرتا ہوں، ڈیٹا بیس خالی ہونا شروع ہو جاتا ہے۔ up (یا down -v)۔ ایک ایسا ای میل استعمال کریں جو حقیقی نظر آئے (Pydantic اسے مسترد کرتا ہے) @*.local)، مثال کے طور پر test@clearledger.io ای میل اور SecurePass123 پاس ورڈ کے لیے۔

پھر انہی اسناد کے ساتھ لاگ ان کریں۔

غلط پاس ورڈ ظاہر ہوتا ہے۔ غلط ای میل یا پاس ورڈ. اگر آپ کو پرانی غلطیاں نظر آتی ہیں تو ریفریش کریں یا چلائیں۔ localStorage.removeItem('cl_token') براؤزر کنسول میں۔

ڈیمو فلو کو کیسے چلایا جائے۔

پہلے، http://localhost:3000 پر رجسٹر ہوں اور لاگ ان کریں۔ چند کریڈٹ اور ڈیبٹ جمع کروائیں (جیسے تنخواہ +$5000، کرایہ −$1200)۔

پھر بیلنس اپ ڈیٹس اور ہسٹری لسٹ آئٹمز کی جانچ کریں۔

اپنا لین دین ابھی جمع کروائیں۔ ≥ $10,000: ایک انتباہی پینل ظاہر ہونا چاہیے۔ LARGE_TRANSACTION.

یہاں اسی بنیادی URL کے لیے ایک اختیاری دھواں ٹیسٹ ہے:

BASE_URL=http://localhost:3000 bash scripts/dast/smoke.sh

مقامی ڈومین نام کی تشکیل کیسے کریں۔

ClearLedger میزبان نام کو میزبان فائل میں شامل کریں۔

ملٹی پاتھ سپورٹ کے ساتھ macOS یا Linux

چلائیں:

sudo bash scripts/setup-hosts.sh

یا اسے دستی طور پر کریں۔

VMIP=$(multipass info clearledger | grep IPv4 | awk '{print $2}')

echo "$VMIP  clearledger.local argocd.local grafana.local vault.local falco.local litmus.local" | sudo tee -a /etc/hosts

مرحلہ 0 کے بعد چیک کریں:

curl -s -o /dev/null -w "%{http_code}n" http://clearledger.local/auth/health

متوقع: 200.

ڈبلیو ایس ایل 2

اپنا WSL IP تلاش کریں۔

ip -4 addr show eth0 | grep inet

دکھایا گیا IP استعمال کریں (یا 127.0.0.1 (اگر یہ آپ کے کمپیوٹر پر کام کرتا ہے)۔ /etc/hosts:

LAB_IP=

echo "$LAB_IP  clearledger.local argocd.local grafana.local vault.local falco.local litmus.local" | sudo tee -a /etc/hosts

اگر آپ WSL کے بجائے ونڈوز پر کروم یا ایج استعمال کر رہے ہیں، تو اسی لائن میں شامل کریں:

C:WindowsSystem32driversetchosts

چیک کریں:

curl http://clearledger.local/auth/health

مرحلہ 0 – عمل درآمد کا نظام

نقطہ آغاز: چونکہ ہمارے پاس ابھی تک کچھ بھی تعینات نہیں ہے، ہم ایک Kubernetes کلسٹر بنانے جا رہے ہیں اور ClearLedger کو دستی طور پر تعینات کریں گے۔

ہدف: ان اقدامات کے بعد، ClearLedger Kubernetes پر چلائے گا۔ آپ صارفین کو رجسٹر کر سکتے ہیں، لین دین جمع کر سکتے ہیں، اور تعمیل کی اطلاعات سب کو بغیر آٹومیشن کے براہ راست تقسیم کر سکتے ہیں۔

تمام تعیناتیاں، اپ ڈیٹس، اور ترمیم دستی طور پر کی جاتی ہیں۔ یہ جان بوجھ کر ہے۔ اپنے پلیٹ فارم کو خودکار کرنے سے پہلے، آپ کو یہ سمجھنا ہوگا کہ یہ آٹومیشن کے بغیر کیسے کام کرتا ہے۔

0.1: کلسٹر پروویژننگ

اگلا، ہم اپنے لیپ ٹاپ پر ایک ورچوئل مشین بنائیں گے جو ہمارا اپنا Kubernetes کلسٹر چلا رہی ہے۔ اسے اپنے کمپیوٹر کے اندر ایک منی ڈیٹا سینٹر سمجھیں۔

ملٹی پاس ایک ہلکا پھلکا Ubuntu VM بناتا ہے۔ MicroK8s ایک کم سے کم Kubernetes ڈسٹری بیوشن ہے جو اس VM کے اندر چلتی ہے۔ وہ ایک ساتھ مل کر کلاؤڈ وسائل کی ضرورت کے بغیر ایک فزیکل کلسٹر فراہم کر سکتے ہیں۔

تجویز: ایک حکم (یہ کریں):

make setup
export KUBECONFIG=~/.kube/clearledger-config
kubectl get nodes

متوقع:

NAME          STATUS   ROLES    AGE   VERSION
clearledger   Ready       2m    v1.29.x

make setup چلائیں scripts/setup-cluster.sh (VM + MicroK8s + ڈسک سیفٹی کیپ) اور scripts/setup-hosts.sh (/etc/hosts آئٹم)۔ اس میں تقریباً 3 سے 5 منٹ لگتے ہیں۔

ڈسک کی حفاظت (لاگ روٹیشن، امیج جی سی تھریشولڈ، جرنلنگ کیپ) خود بخود کنفیگر ہو جاتی ہے۔ مزید معلومات کے لیے، Disk Health in Troubleshooting.md دیکھیں۔

اگر حیثیت ہے: NotReadyبراہ کرم 60 سیکنڈ انتظار کریں اور دوبارہ کوشش کریں۔

دستی ترتیبات مندرجہ ذیل ہیں: make setup ناکام ہوا اور مرحلہ وار ڈیبگ کرنے کی ضرورت ہے):

multipass launch 
  --name clearledger 
  --cpus 6 --memory 12G --disk 80G 
  22.04

VM IP حاصل کریں (اگلا درکار ہے) /etc/hosts):

multipass info clearledger | grep IPv4

میزبان اندراج شامل کریں۔ اوپر ڈومین نام کا سیکشن دیکھیں، یا چلائیں: sudo bash scripts/setup-hosts.sh.

multipass shell clearledger

VM کے اندر:

sudo snap install microk8s --classic --channel=1.29/stable
sudo usermod -aG microk8s ubuntu && newgrp microk8s
microk8s enable dns ingress storage helm3 rbac
echo "alias kubectl="microk8s kubectl"" >> ~/.bashrc
echo "alias helm='microk8s helm3'" >> ~/.bashrc
source ~/.bashrc
kubectl get nodes
exit   # back to your host machine

میزبان سے kubectl کو جوڑیں۔

multipass exec clearledger -- microk8s config > ~/.kube/clearledger-config
export KUBECONFIG=~/.kube/clearledger-config
kubectl get nodes

0.2: اپنی درخواست کو تعینات کرنے سے پہلے اسے سمجھیں۔

اس فائل کو ایک بار چلانے سے پہلے کھولیں۔ kubectl حکم سب سے پہلے کوڈ کو پڑھنا ہر چیز کو سمجھنے کے لیے سیاق و سباق تیار کرتا ہے۔

ہر ڈاکر فائل میں درج ذیل لائنوں کو چیک کریں: USER appuser. اس کا مطلب ہے کہ تصویر کو روٹ کے بجائے عام صارف کے طور پر چلانے کے لیے ڈیزائن کیا گیا ہے۔ Kubernetes مینی فیسٹ بھی ترتیب دیا گیا ہے۔ runAsNonRoot: true. بعد میں، مرحلہ 4 میں، Kyverno اس اصول کو نافذ کرتا ہے اور Pods کو مسترد کرتا ہے جو غیر جڑ صارف کے طور پر چلانے کا اعلان نہیں کرتے ہیں۔ چونکہ آپ کی ایپ جلد تیار ہے، یہ اس پالیسی کو بعد میں پاس کر دے گی۔

یہ بھی دیکھیں infra/manifests/auth-service/secret.yaml. ڈیٹا بیس کا پاس ورڈ ہے۔ changeme-stage0 بیس 64 کو انکوڈ کیا گیا۔ ضابطہ کشائی:

echo "Y2hhbmdlbWUtc3RhZ2Uw" | base64 -d
# changeme-stage0

وہ پاس ورڈ YAML فائل میں ہے جسے اسٹوریج تک رسائی رکھنے والا کوئی بھی شخص پڑھ سکتا ہے۔ base64 انکوڈنگ ہے، انکرپشن نہیں۔ اسے آسانی سے پلٹا جا سکتا ہے۔ اس لمحے کو یاد رکھیں۔ یہی وجہ ہے کہ مرحلہ 5 موجود ہے۔

0.3: ڈوکر ہب سیٹ اپ

آپ کو ایک کنٹینر رجسٹری کی ضرورت ہے، تعمیر شدہ تصاویر کو ذخیرہ کرنے کی جگہ تاکہ آپ کا کلسٹر انہیں کھینچ سکے۔ Docker Hub سب سے آسان آپشن ہے۔ مرحلہ 8 اسے پرائیویٹ رجسٹری (ECR) سے بدل دیتا ہے۔

Docker Hub (مفت اکاؤنٹ، hub.docker.com) پر چار عوامی ذخیرے بنائیں۔

1. تحریک hub.docker.com

2. کلک کریں ایک ذخیرہ بنائیں

3. نام کی جگہ کے طور پر اپنا Docker Hub صارف نام منتخب کریں۔

4. براہ کرم ذیل کی فہرست میں سے ایک مخزن کا نام درج کریں۔

5. مرئیت کو اس پر سیٹ کریں۔ عوامی

6. کلک کریں بنانا

7. چاروں خدمات کے لیے دہرائیں۔

YOUR_USERNAME/clearledger-auth-service
YOUR_USERNAME/clearledger-ledger-service
YOUR_USERNAME/clearledger-notification-service
YOUR_USERNAME/clearledger-frontend

اگلا، ایک رسائی ٹوکن تیار کریں۔ hub.docker.com پر جائیں، پھر اکاؤنٹ کی ترتیبات، سیکیورٹی، نیا رسائی ٹوکن (پڑھیں/لکھیں/حذف کریں)۔ اسے محفوظ کریں۔ آپ اسے دوبارہ کبھی نہیں دیکھیں گے۔

docker login
# Username: your Docker Hub username
# Password: the access token (NOT your account password)

چاروں خدمات کو بنائیں اور آگے بڑھائیں۔

# Replace your-username with your Docker Hub username, the same string everywhere in this lab
export DOCKER_USERNAME=your-username
echo "Using DOCKER_USERNAME=$DOCKER_USERNAME"

لیب چیک پوائنٹ: Docker Hub صارف نام

# Must print your real username, not the literal text "your-username"
echo "$DOCKER_USERNAME"

متوقع: ایک لائن جس میں Docker Hub کا نام ہے، جیسے veeno-demo)۔ اگر آپ دیکھتے ہیں your-username اس کے بجائے اسے روکیں اور ٹھیک کریں۔ export تعمیر کرنے سے پہلے۔

چاروں خدمات کو بنائیں اور آگے بڑھائیں۔

docker build -t $DOCKER_USERNAME/clearledger-auth-service:v0.1.0 ./app/auth-service
docker build -t $DOCKER_USERNAME/clearledger-ledger-service:v0.1.0 ./app/ledger-service
docker build -t $DOCKER_USERNAME/clearledger-notification-service:v0.1.0 ./app/notification-service
docker build -t $DOCKER_USERNAME/clearledger-frontend:v0.1.0 ./app/frontend

# Push

docker push $DOCKER_USERNAME/clearledger-auth-service:v0.1.0
docker push $DOCKER_USERNAME/clearledger-ledger-service:v0.1.0
docker push $DOCKER_USERNAME/clearledger-notification-service:v0.1.0
docker push $DOCKER_USERNAME/clearledger-frontend:v0.1.0

لیب چیک پوائنٹ: ڈوکر ہب کی تصاویر

hub.docker.com کھولیں، اپنے پروفائل پر جائیں، اور پھر ذخیرہ. پھر چاروں کو چیک کریں۔ clearledger-* ذخیرے موجود ہیں اور ہر ذخیرہ کو ٹیگ کیا گیا ہے۔ v0.1.0.

اپنے لیپ ٹاپ پر چلائیں:

docker pull $DOCKER_USERNAME/clearledger-auth-service:v0.1.0

متوقع: Status: Downloaded newer image یا Image is up to dateنہیں repository does not exist یا denied.

0.4: درخواست دینے سے پہلے مینی فیسٹ پر ایک نظر ڈالیں۔

Kubernetes ہے ظاہر ایک فائل (YAML) جو ان وسائل کی وضاحت کرتی ہے جنہیں تخلیق کرنے کی ضرورت ہے۔ بٹن پر کلک کرنے کے بجائے، آپ اپنی مطلوبہ حالت کا اعلان کرتے ہیں اور Kubernetes اسے بناتا ہے۔

ClearLedger کو تعینات کرنے سے پہلے، درج ذیل مینی فیسٹ پر ایک سرسری نظر ڈالیں:

• infra/manifests/namespace.yaml: تخلیق کرنا clearledger نام کی جگہ۔

• infra/manifests/postgres/: PostgreSQL تعینات کریں۔

• infra/manifests/redis/redis.yaml: Redis تعینات کریں۔

• infra/manifests/auth-service/: توثیق کی خدمت تعینات کریں۔

• infra/manifests/ledger-service/: لیجر سروس تعینات کریں۔

• infra/manifests/notification-service/: نوٹیفکیشن سروس تعینات کریں۔

• infra/manifests/frontend/: ویب ایپلیکیشن تعینات کریں۔

• infra/manifests/ingress.yaml: درخواست کو دستیاب کرتا ہے: clearledger.local.

• infra/manifests/rbac/rbac.yaml: اس بات کی وضاحت کرتا ہے کہ کلسٹر کے اندر کون کیا کرسکتا ہے۔

آپ کو ابھی تک تمام شعبوں کو سمجھنے کی ضرورت نہیں ہے۔ مقصد صرف یہ دیکھنا ہے کہ کبرنیٹس کے تخلیق کرنے سے پہلے آپ کی درخواست کی وضاحت کیسے کی جاتی ہے۔

§0.6 کے بعد کے دو اختیاری حصوں میں، آپ سمجھ جائیں گے کہ انگریس روٹنگ اور RBAC کیسے کام کرتے ہیں۔ ابھی کے لیے، آئیے دیکھتے ہیں کہ کبرنیٹس کے تخلیق کرنے سے پہلے کسی ایپ کو کیسے بیان کیا جاتا ہے۔

0.5: ClearLedger کی تعیناتی (درجہ وار)

تعیناتی کا مقام 6 منزلیں۔. اگلی پرت شروع کرنے سے پہلے ہر پرت کو مکمل کریں۔ چلائیں kubectl get pods -n clearledger تہوں 2، 3، اور 6 کے بعد ترقی کی جانچ کریں۔

مختصر راستہ متغیر سیٹ کریں اور یقینی بنائیں کہ صارف نام ابھی بھی سیٹ ہے۔

export DOCKER_USERNAME=your-username   # skip if already set in §0.3
STAGE0=stages/stage-0-raw-kubernetes/infra/manifests

0.5.1 — پرت 1: نام کی جگہیں اور RBAC

جب تک نام کی جگہ موجود نہ ہو کوئی اور چیز نہیں بن سکتی۔ مزید برآں، RBAC کا موجود ہونا ضروری ہے اس سے پہلے کہ کام کا بوجھ کسی ServiceAccount کا حوالہ دے سکے۔

kubectl apply -f infra/manifests/namespace.yaml
kubectl apply -f infra/manifests/rbac/rbac.yaml

چیک کریں:

kubectl get namespace clearledger
kubectl get serviceaccount -n clearledger
# Expected: auth-service, ledger-service, notification-service, clearledger-viewer

0.5.2 — پرت 2: PostgreSQL

auth-service یا ledger-service شروع ہونے سے پہلے ڈیٹا بیس کا چلنا ضروری ہے۔ دونوں سروسز ہجرت کو چلانے اور درخواستوں پر کارروائی کرنے کے لیے سٹارٹ اپ پر پوسٹگریس سے منسلک ہوتی ہیں، اور اگر ڈیٹا بیس پہلے سے موجود نہیں ہے، تو کریش لوپ ہوتا ہے۔

kubectl apply -f infra/manifests/postgres/postgres-secret.yaml
kubectl apply -f infra/manifests/postgres/postgres.yaml

kubectl wait --for=condition=ready pod -l app=postgres 
  -n clearledger --timeout=120s

کے بعد متوقع kubectl apply:

secret/postgres-secret created
persistentvolumeclaim/postgres-pvc created
statefulset.apps/postgres created
service/postgres created

میں کب اس کی توقع کر سکتا ہوں؟ kubectl wait کامیابی: کمانڈ آؤٹ پٹ کے بغیر نکلتی ہے (ایگزٹ کوڈ 0)۔ اگر وقت ختم ہو جائے تو دیکھیں: اگر پوسٹگریس زیر التواء ہے۔ جاری رکھنے سے پہلے اسے نیچے چیک کریں۔

چیک کریں:

kubectl get pods -n clearledger -l app=postgres
kubectl get pvc -n clearledger

متوقع:

NAME         READY   STATUS    RESTARTS   AGE
postgres-0   1/1     Running   0          45s

NAME           STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS        AGE
postgres-pvc   Bound    pvc-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx   5Gi        RWO            microk8s-hostpath   45s

اگر پوسٹگریس زیر التواء ہے۔ (kubectl wait ٹائم آؤٹ، فورڈ شو 0/1 Pendingپیویسی شو Pending):

پوسٹگریس میں مستقل حجم کا دعوی: کلسٹر میں ڈسک کی جگہ۔ MicroK8s اسے فراہم کرتا ہے: hostpath-storage ایڈ آن۔ اگر make setup دستی سیٹ اپ بغیر کسی رکاوٹ کے استعمال کیا گیا تھا۔ microk8s enable storageپیویسی کے پاس پابند ہونے کے لیے کچھ نہیں ہے اور پوڈز شیڈول نہیں ہیں۔

تقریب کو دیکھیں۔ عام طور پر آپ کو کچھ اس طرح نظر آئے گا:

Warning  FailedScheduling  ...  pod has unbound immediate PersistentVolumeClaims
Normal   FailedBinding     ...  no persistent volumes available for this claim and no storage class is set

VM پر مسئلہ حل کرنے کے بعد، پوسٹگریس پوڈ کو دوبارہ شروع کریں۔ یہ چلائیں میزبان سے: macOS، Linux، یا Windows PowerShell میں ایک ہی کمانڈ (ملٹی پاس میزبان پر انسٹال ہے اور VM کے اندر چلتا ہے):

# Enable storage (and ingress/rbac if make setup skipped them)
multipass exec clearledger -- microk8s enable storage ingress rbac

# Confirm a default StorageClass exists
kubectl get storageclass
# Expected: microk8s-hostpath (default)

# Kick the pod so it reschedules against the new storage class
kubectl delete pod postgres-0 -n clearledger

kubectl wait --for=condition=ready pod -l app=postgres 
  -n clearledger --timeout=120s
kubectl get pods -n clearledger -l app=postgres
# Expected: postgres-0   1/1   Running

پوسٹگریس مکمل ہونے تک توثیق کی خدمت یا لیجر سروس کے ساتھ جاری نہ رکھیں۔ Running. اگر ڈیٹا بیس موجود نہیں ہے تو کریش ہو جائے گا۔

0.5.3 — پرت 3: ریڈیس

Redis کیوں موجود ہے (فوری منظرنامہ): فرض کریں کہ ایک گاہک $15,000 کی ڈیبٹ رقم جمع کرتا ہے۔ لیجر سروس اسے پوسٹگریس میں اسٹور کرتی ہے اور پھر اس پیغام کو ریڈیس کو شائع کرتی ہے۔ "بڑا ٹرانزیکشن، صارف X، رقم 15000۔” نوٹیفکیشن سروس اس چینل کو سن رہی ہے۔ پیغام کو منتخب کریں اور تعمیل کا انتباہ لاگ ان کریں۔ یہ انتباہ بعد میں UI میں ظاہر ہوگا جب آپ کرل کریں گے۔ /notifications/alerts.

لیجر سروس اور نوٹیفکیشن سروس ایک دوسرے کو براہ راست کال نہیں کرتے ہیں۔ ریڈیس مرکزی طور پر واقع ہے۔ پیغام بس: لیجر شائع ہو گیا ہے اور اطلاعات سبسکرائب ہو گئی ہیں۔ اسی لیے آپ کو نوٹیفکیشن سروس کو تعینات کرنے سے پہلے Redis کو چلانے کی ضرورت ہے (اور اب آپ اسے پوسٹگریس کے ساتھ ایپ لیئر سے پہلے کیوں تعینات کر رہے ہیں)۔

kubectl apply -f infra/manifests/redis/redis.yaml

چیک کریں:

kubectl get pods -n clearledger -l app=redis

متوقع:

NAME                     READY   STATUS    RESTARTS   AGE
redis-xxxxxxxxxx-xxxxx   1/1     Running   0          30s

0.5.4 — پرت 4: درخواست کے راز

اسناد مرحلہ 0 میں Kubernetes Secrets میں ہیں (مرحلہ 5 اسناد کو والٹ میں لے جاتا ہے)۔

kubectl apply -f infra/manifests/auth-service/secret.yaml
kubectl apply -f infra/manifests/ledger-service/secret.yaml

چیک کریں:

kubectl get secrets -n clearledger | grep -E 'auth-service|ledger-service'

متوقع (عمر مختلف ہو سکتی ہے؛ ڈیٹا (شمار ​​ملنا چاہیے):

auth-service-secret     Opaque   2      64s
ledger-service-secret   Opaque   1      8s

auth-service-secret اس میں دو چابیاں ہیں (database_url, jwt_secret)۔ ledger-service-secret ایک پکڑو (database_url)۔ مرحلہ 5 اسے Vault سے بدل دیتا ہے۔ یہ فی الحال کلسٹر میں کبرنیٹس سیکریٹ کے طور پر موجود ہے۔

0.5.5 – پرت 5: درخواست کے کام کا بوجھ

ہم چار ایپ سروسز شروع کرنے جا رہے ہیں: تصدیق، لیجر، نوٹیفکیشن، اور فرنٹ اینڈ۔ پوسٹگریس، ریڈیس، اور آخری دو پرتوں کے راز پہلے سے موجود ہیں۔ کوبرنیٹس کو اب ڈوکر ہب کی تصویر کھینچنے اور اسے پوڈ کے طور پر چلانے کی ضرورت ہے۔

2 فائلیں فی خدمت (زیادہ سے زیادہ): تعیناتی Kubernetes کو بتاتی ہے۔ چلانے کے لیے کنٹینر کی تصویر اور کتنی کاپیاں؟. کوئی راستہ نہیں سروس کلسٹر کے اندر اس ایپ کے لیے ایک مستحکم نام فراہم کریں، جیسے auth-service لہذا، لیجر پوڈ آئی پی ایڈریس کو جانے بغیر سرٹیفکیٹ تلاش کرسکتا ہے۔ پہلے تعیناتیوں کا اطلاق کریں، پھر خدمات۔

پھر ہم کیوں sed نیچے کمانڈ؟ Git کی تعیناتی YAML فائل پلیس ہولڈرز پر مشتمل ہے۔ DOCKER_USERNAMEاس کی وجہ یہ ہے کہ ہر ایک کا Docker Hub صارف نام مختلف ہے۔ پہلے سے ہی §0.3 میںexport DOCKER_USERNAME=YOUR_DOCKERHUB_USERNAME)۔ کہ sed جب مینی فیسٹ کوبرنیٹس کو بھیجا جاتا ہے، تو لائن فوری طور پر ان پلیس ہولڈرز کو اصل صارف نام سے بدل دیتی ہے۔ گٹ فائلوں میں ترمیم نہیں کرتا ہے۔ اگر آپ اسے چھوڑ دیتے ہیں۔ sed خام فائل کو لاگو کرنا Kubernetes کا سبب بنتا ہے۔ DOCKER_USERNAME/clearledger-auth-serviceیہ موجود نہیں ہے۔

اسٹیج 0 فولڈر کیوں استعمال کریں؟ یہ ذخیرہ Kubernetes مینی فیسٹ کی ایک سے زیادہ کاپیوں پر مشتمل ہے۔ اس دستی تعیناتی کے لیے، استعمال کریں: stages/stage-0-raw-kubernetes/infra/manifests/. فائل اسٹیج 0 کے لیے تیار کی گئی ہے اور اس میں شامل ہیں: DOCKER_USERNAME یہ پلیس ہولڈرز ہیں جو نیچے دیے گئے کمانڈز کو بدل دیتے ہیں۔ استعمال نہ کریں infra/manifests/ تاہم، وہ فائل بعد کے GitOps اقدامات کے لیے ہے۔

ہر ایک سروس کو ترتیب سے لگائیں۔ اسے استعمال کرتے ہوئے ریپو روٹ سے چلائیں: DOCKER_USERNAME ابھی تک برآمد نہیں ہوا:

1. تصدیق کی خدمت: لاگ ان کریں اور رجسٹر کریں۔

sed "s|DOCKER_USERNAME|${DOCKER_USERNAME}|g" 
  "$STAGE0/auth-service/deployment.yaml" | kubectl apply -f -
kubectl apply -f infra/manifests/auth-service/service.yaml

2. لیجر سروس: لین دین اور بیلنس (پوسٹگریس + §0.5.4 میں تخلیق کردہ راز کی ضرورت ہے)

sed "s|DOCKER_USERNAME|${DOCKER_USERNAME}|g" 
  "$STAGE0/ledger-service/deployment.yaml" | kubectl apply -f -
kubectl apply -f infra/manifests/ledger-service/service.yaml

3. اطلاع کی خدمت: Redis سے بڑے لین دین کی وارننگ وصول کریں (اس معاملے میں کوئی ڈیٹا بیس خفیہ نہیں)۔

sed "s|DOCKER_USERNAME|${DOCKER_USERNAME}|g" 
  "$STAGE0/notification-service/deployment.yaml" | kubectl apply -f -
kubectl apply -f infra/manifests/notification-service/service.yaml

4. فرنٹ اینڈ: ویب UI (یہاں تعیناتی اور سروس ایک فائل میں ہیں)

sed "s|DOCKER_USERNAME|${DOCKER_USERNAME}|g" 
  "$STAGE0/frontend/deployment.yaml" | kubectl apply -f -

چیک کریں (تمام ایپ پوڈز Running: توثیق اور لیجر کو پوسٹگریس سے منسلک ہونے میں 30 سیکنڈ تک لگ سکتے ہیں):

kubectl get pods -n clearledger

متوقع آپ کو پچھلی پرت سے پوسٹگریس اور ریڈیس کے ساتھ ساتھ ہر ایپ کے لئے نئے پوڈز دیکھنا چاہئے (پوڈ کے صحیح نام مختلف ہوں گے)۔

NAME                                      READY   STATUS    RESTARTS   AGE
postgres-0                                1/1     Running   0          15m
redis-xxxxxxxxxx-xxxxx                    1/1     Running   0          10m
auth-service-xxxxxxxxxx-xxxxx             1/1     Running   0          45s
auth-service-xxxxxxxxxx-xxxxx             1/1     Running   0          45s
ledger-service-xxxxxxxxxx-xxxxx           1/1     Running   0          40s
ledger-service-xxxxxxxxxx-xxxxx           1/1     Running   0          40s
notification-service-xxxxxxxxxx-xxxxx     1/1     Running   0          35s
frontend-xxxxxxxxxx-xxxxx                 1/1     Running   0          30s

اگر آپ کی تصدیق کی خدمت یا لیجر سروس یہ ہے: CrashLoopBackOffلاگ چیک کریں۔

kubectl logs -n clearledger deploy/auth-service --tail=20

عام وجوہات: آپ نے درخواست دی infra/manifests/*/deployment.yaml اوپر دی گئی اسٹیج 0 فائل کے بجائے، آپ دیکھ سکتے ہیں: لاگز۔ DATABASE_URL is not set. دوبارہ چلائیں sed + kubectl apply اس سیکشن میں احکامات۔

چیک پوائنٹ پر عمل کریں: رسید سے پہلے کام کا بوجھ

kubectl get deployment -n clearledger
kubectl get pods -n clearledger --field-selector=status.phase!=Running

متوقع: 4 تعیناتیاں (auth-service, ledger-service, notification-service, frontend) کے ساتھ READY مطلوبہ نقل سے ملائیں (تصدیق اور لیجر مارکنگ) 2/2)۔ دوسری کمانڈ پرنٹ کرتی ہے۔ کچھ نہیں: کوئی پوڈ زیر التواء یا CrashLoopBackOff حالت میں نہیں پھنسا ہے۔

0.5.6 — پرت 6: داخل

اپنے کلسٹر کو اس پر ظاہر کریں: http://clearledger.local.

kubectl apply -f infra/manifests/ingress.yaml

چیک کریں:

kubectl get ingress -n clearledger
curl -s -o /dev/null -w "%{http_code}n" http://clearledger.local/
# Expected: 200

0.5.7: مستحکم ہونے تک مشاہدہ کریں۔

kubectl get pods -n clearledger -w

متوقع حتمی حالت (جب تمام پوڈز نظر آئیں تو دیکھنا بند کرنے کے لیے Ctrl+C دبائیں) Running):

NAME                                  READY   STATUS    RESTARTS
auth-service-xxx                      1/1     Running   0
auth-service-yyy                      1/1     Running   0
frontend-xxx                          1/1     Running   0
ledger-service-xxx                    1/1     Running   0
ledger-service-yyy                    1/1     Running   0
notification-service-xxx              1/1     Running   0
postgres-0                            1/1     Running   0
redis-xxx                             1/1     Running   0

پوڈ پھنس گیا ہے۔ Pending یا CrashLoopBackOff? درج ذیل دو کمانڈز ظاہر کرتے ہیں کہ کیا غلط ہے:

kubectl describe pod POD_NAME -n clearledger
kubectl logs POD_NAME -n clearledger --previous

0.6: چلانے کے نظام کو چیک کریں۔

استعمال کریں 1 ٹیسٹ اکاؤنٹ براؤزر اور کرل دونوں کے لیے کوئی تنازعات نہیں ہیں۔

میدان	قدر
ای میل	test@clearledger.io
پاس ورڈ	SecurePass123

اگر آپ پہلے ہی اپنے براؤزر کے ساتھ رجسٹرڈ ہیں۔ مختلف اپنا پاس ورڈ درج کرنے کے لیے، اس پاس ورڈ کے ساتھ لاگ ان کریں یا ایک نیا ای میل منتخب کریں۔ ذیل میں curl کمانڈ ہے۔ ایک ہی ای میل اور پاس ورڈ جس کے ساتھ آپ نے اصل میں رجسٹر کیا ہے۔

اپنا براؤزر چیک کریں (تجویز کردہ):

کھلا http://clearledger.local آپ کے براؤزر میں۔ ClearLedger لاگ ان اسکرین ظاہر ہوتی ہے۔

کلک کریں رجسٹر کریں پھر اس کے ساتھ ایک اکاؤنٹ بنائیں test@clearledger.io / SecurePass123 (نیچے دیے گئے کرل بلاک کی طرح۔ Pydantic واضح طور پر اس طرح کی جعلی ای میلز کو مسترد کر دے گا: test@test.com)۔

اپنے ای میل اور پاس ورڈ کے ساتھ لاگ ان کریں۔ جب آپ پہلی بار لاگ اِن ہوں گے، ڈیش بورڈ خود بخود ڈیمو ٹرانزیکشن سیڈ کر دے گا۔ اس کے ظاہر ہونے کے لیے چند سیکنڈ انتظار کریں۔

دیکھو موجودہ توازن کارڈ اسپارک لائن چارٹ میں ڈالر کی مقدار ظاہر ہونی چاہیے۔

دیکھو لین دین کی تاریخ. آپ کو "تنخواہیں (Acme Corp”)، "لیز مئی 2026” جیسی چیزیں نظر آئیں گی۔

اور دیکھیں انتباہ نیچے والا پینل۔ آپ کو دیکھنا چاہئے LARGE_TRANSACTION سرخ بیجز کے ساتھ اطلاعات۔ آپ کے دو ڈیمو ٹریڈز $10,000 سے زیادہ ہونے پر تعمیل کا انتباہ خود بخود متحرک ہو جاتا ہے۔

پھر $10,000 یا اس سے زیادہ کی تجارت جمع کروائیں اور حقیقی وقت میں الرٹس کی تعداد میں اضافہ دیکھیں۔

کیا تلاش کرنا ہے:

• ہر ٹرانزیکشن کے فوراً بعد بیلنس اپڈیٹس

• کریڈٹ سبز رنگ میں ظاہر ہوتے ہیں۔ +$ رقم اور ڈیبٹ سرخ رنگ میں دکھائے جاتے ہیں۔ −$ رقم

• جب آپ $10,000 یا اس سے زیادہ کی ٹرانزیکشنز جمع کراتے ہیں تو نوٹیفکیشن بیجز کی تعداد بڑھ جاتی ہے۔

• ہر اطلاع ایک رقم، سمت اور ٹائم اسٹیمپ دکھاتی ہے۔

اپنے ڈیش بورڈ کا اسکرین شاٹ لیں جو آپ کے لین دین اور ایک یا زیادہ الرٹس کو دکھاتا ہے۔ یہ آپ کے پورٹ فولیو میں پہلا ٹکڑا ہے۔

یا curl کے ذریعے (ایک ہی اکاؤنٹ: مفید ہے اگر براؤزر تعاون نہ کریں):

# Register (skip if you already registered in the browser with the same email)
curl -s -X POST http://clearledger.local/auth/register 
  -H "Content-Type: application/json" 
  -d '{"email":"test@clearledger.io","password":"SecurePass123"}' | jq .

متوقع: {"user_id":"...","email":"test@clearledger.io"}یا یہ کہنے میں غلطی کہ آپ کا ای میل پہلے ہی رجسٹرڈ ہے (اگر آپ نے پہلے براؤزر استعمال کیا تو یہ ٹھیک ہے)۔

# Login — save the token (must match the password you registered with)
TOKEN=$(curl -s -X POST http://clearledger.local/auth/login 
  -H "Content-Type: application/json" 
  -d '{"email":"test@clearledger.io","password":"SecurePass123"}' 
  | jq -r .access_token)
echo "Token: ${TOKEN:0:30}..."

اگر TOKEN خالی یا لاگ ان لوٹاتا ہے۔ 401براؤزر کے پاس ورڈ مماثل نہیں ہیں۔ براہ کرم اوپر والے جدول میں دوبارہ رجسٹر ہوں یا نیچے اپنا اصل پاس ورڈ استعمال کریں۔ -d JSON.

# Create a large transaction (triggers notification alert)
curl -s -X POST http://clearledger.local/ledger/transactions 
  -H "Authorization: Bearer $TOKEN" 
  -H "Content-Type: application/json" 
  -d '{"amount":15000,"direction":"debit","description":"Property payment"}' | jq .

متوقع: ٹرانزیکشن آبجیکٹ پر مشتمل ہے: id, amount: 15000, direction: "debit":

# Check balance
curl -s http://clearledger.local/ledger/balance 
  -H "Authorization: Bearer $TOKEN" | jq .

# Confirm the notification alert fired
curl -s http://clearledger.local/notifications/alerts | jq .

متوقع (صرف کرل روٹ، کوئی براؤزر ڈیمو سیڈ نہیں): $15,000 ٹرانزیکشن پر کم از کم ایک انتباہ ہے۔ مثال کے طور پر: {"total":1,"alerts":[{"type":"LARGE_TRANSACTION","amount":15000,...}]}. اگر آپ پہلے سے ہی براؤزر استعمال کرتے ہیں، total شاید 3 یا اس سے زیادہ (دو ڈیمو اطلاعات اور آپ کی)، یہ بھی درست ہے۔

اگر آپ دیکھتے ہیں {"detail":"Unauthorized"}: آپ کے ٹوکن کی میعاد ختم ہو گئی ہے۔ سیکورٹی وجوہات کی بنا پر JWT مختصر مدت کے لیے ہے۔ یہ جان بوجھ کر ہے۔ نیا ٹوکن حاصل کرنے کے لیے مندرجہ بالا لاگ ان کمانڈ کو دوبارہ چلائیں اور پھر ناکام کمانڈ کو دوبارہ آزمائیں۔

یہ صرف متاثر کرتا ہے: $TOKEN موجودہ ٹرمینل سیشن کے لیے متغیر۔ اگر آپ نیا ٹرمینل کھولتے ہیں، تو آپ کو دوبارہ لاگ ان کمانڈ چلانے کی ضرورت ہوگی۔ $TOKEN یہ تمام سیشنوں میں برقرار نہیں رہتا ہے۔

make check-0

استقبال کو سمجھیں (اختیاری)

یہ سمجھنے کے لیے §0.6 کے بعد پڑھیں۔ clearledger.local پھلی تک پہنچیں۔

کلسٹر چار ایپلیکیشن سروسز چلاتا ہے: فرنٹ اینڈ، تصدیق کی خدمت، لیجر سروس، اور نوٹیفکیشن سروس۔ ہر ایک اندر سروس کلسٹر کے اندر پتے ہیں، لیکن ان میں سے کوئی بھی براؤزر کے ذریعے قابل رسائی نہیں ہے۔ داخلہ بیرونی ٹریفک کا راستہ۔

داخل ہونا آپ کا سامنے کا دروازہ ہے۔ جب درخواست ماری جاتی ہے۔ clearledger.localKubernetes URL کے راستے کو حل کرتا ہے اور اسے درست سروس پر بھیج دیتا ہے۔ درخواست /auth توثیق کی خدمات پر جائیں۔ /ledger لیجر خدمات کے لیے، /notifications نوٹیفکیشن سروس کے لیے / سامنے والے سرے پر۔

کھلا infra/manifests/ingress.yaml اور کمنٹس پڑھیں۔ API کا راستہ ہے۔ دوبارہ لکھنا: /auth/login بن جاتا ہے۔ /login توثیق کی خدمت تک پہنچنے سے پہلے پسدید کا راستہ سادہ رکھا جاتا ہے۔

آپ بعد میں مزید میزبان نام شامل کریں گے (grafana.local, argocd.localوغیرہ): ہر ایک کو بعد کے مراحل میں اپنا انگریس ظاہر ہوتا ہے۔ یہ فائل صرف ClearLedger ایپ کے لیے ہے۔

RBAC کو سمجھیں (اختیاری)

اندراج کلسٹر کے باہر سے آنے والی ٹریفک کو کنٹرول کرتا ہے۔ RBAC کلسٹر کے اندر اجازتوں کو کنٹرول کرتا ہے۔

یہ فائل اس کے لیے IDs اور اجازتیں بناتی ہے: clearledger نام کی جگہ۔

کھلا infra/manifests/rbac/rbac.yaml. اوپر کی تفصیل اس مشق کی عکاسی کرتی ہے۔

کوئی راستہ نہیں سروس اکاؤنٹ پوڈ کی شناخت۔ مثال کے طور پر، auth-service, ledger-serviceاور notification-service ہر شخص کو اپنی شناخت ملتی ہے۔

کوئی راستہ نہیں کردار اس سے مراد ہے کہ آپ اس شناخت کے ساتھ کیا کر سکتے ہیں۔ ریپوزٹری میں ایپ کا کردار بہت محدود ہے۔ get اور list Kubernetes اختتامی نقطہ۔ آپ راز نہیں پڑھ سکتے، پوڈز کو حذف نہیں کر سکتے، وسائل نہیں بنا سکتے، یا دیگر نام کی جگہوں تک رسائی حاصل نہیں کر سکتے۔

کوئی راستہ نہیں رول بائنڈنگ شناخت کو اجازتوں سے جوڑیں۔ رول بائنڈنگ کے بغیر، رول موجود ہے لیکن کسی پوڈ کو اس کی اجازت نہیں ملتی ہے۔

کہ clearledger-viewer سروس اکاؤنٹ صرف پڑھنے کے لیے ڈیبگنگ کے لیے ہے۔ یہ پوڈز، سروسز، اینڈ پوائنٹس، ایونٹس، اور کنفیگ میپس کا معائنہ کر سکتا ہے، لیکن راز نہیں پڑھ سکتا۔

ڈیفالٹ سروس اکاؤنٹ غیر مراعات یافتہ کردار کا پابند ہے۔ اس طرح، اگر پھلی سیٹ کرنا بھول جائے۔ serviceAccountNameیہ ایک ایسی شناخت کی طرف لوٹتا ہے جس کے بارے میں آپ کچھ نہیں کر سکتے۔

نقطہ کم از کم استحقاق ہے۔ یہاں تک کہ اگر کسی پوڈ سے سمجھوتہ کیا جاتا ہے، تو Kubernetes وسیع کلسٹر رسائی فراہم نہیں کرتا ہے۔

0.7: آپ دستی تعیناتی پر کیوں اعتماد نہیں کر سکتے

فیز 0 میں، آپ نے ایپ کو خود بنایا اور تعینات کیا۔ اب آئیے کوڈ کے ایک چھوٹے سے ٹکڑے کو تبدیل کریں اور دوبارہ تعینات کریں۔ یہ دستی تعیناتی کے ساتھ مسئلہ کو ظاہر کرتا ہے۔ ٹریک کرنا مشکل، پیچھے ہٹنا مشکل، ثابت کرنا مشکل۔ فیز 1 اور 2 CI اور GitOps کا استعمال کرتے ہوئے اس مسئلے کو حل کرتے ہیں۔

مرحلہ 1: قابل توجہ تبدیلیاں کریں۔

کھلا app/auth-service/main.py اور تلاش کریں /health اختتامی نقطہ آپ کو یہ بتانے کے لیے واپسی کی قدر کو تبدیل کریں کہ نیا ورژن چل رہا ہے۔

# Before
return {"status": "ok", "service": settings.service_name}

# After — add a version field
return {"status": "ok", "service": settings.service_name, "version": "0.2.0"}

فائل کو محفوظ کریں۔ یہ چھوٹے اصلاحات فراہم کرنے والے ایک ڈویلپر کی نقل کرتا ہے۔

مرحلہ 2: دستی طور پر بنائیں، دھکیلیں اور تعینات کریں۔

docker build -t $DOCKER_USERNAME/clearledger-auth-service:v0.2.0 ./app/auth-service

docker push $DOCKER_USERNAME/clearledger-auth-service:v0.2.0
kubectl set image deployment/auth-service 
  auth-service=$DOCKER_USERNAME/clearledger-auth-service:v0.2.0 
  -n clearledger

نئی تصویر کھینچنے اور Pod کو دوبارہ شروع کرنے کے لیے Kubernetes کے لیے تقریباً 30 سیکنڈ انتظار کریں۔

kubectl rollout status deployment/auth-service -n clearledger

مرحلہ 3: تصدیق کریں کہ آپ کی تبدیلیاں لاگو ہو گئی ہیں۔

curl -s http://clearledger.local/auth/health | jq .

متوقع: {"status":"ok","service":"auth-service","version":"0.2.0"}

اگر آپ اب بھی پرانا جواب دیکھیں "version"براہ کرم کچھ اور سیکنڈ انتظار کریں اور دوبارہ کوشش کریں۔ Kubernetes اب بھی نئے pods جاری کر رہا ہے.

مرحلہ 4: اس بات کا تعین کریں کہ کون سی دستی تعیناتی پیش نہیں کرتی ہے۔

آپ نے اپنی تبدیلیاں تعینات کر دی ہیں۔ یہ کام کرتا ہے۔ لیکن سوچو کہ ابھی کیا ہوا ہے۔

• یہ کس نے تقسیم کیا؟ کوئی ریکارڈ نہیں ہے۔ تم بھاگ گئے kubectl اپنے لیپ ٹاپ پر۔ اگر تین لوگوں کو کلسٹر تک رسائی حاصل ہے، تو کوئی نہیں جان سکے گا کہ کس نے کیا بدلا۔

• کیا بدلا ہے؟ واحد ثبوت ڈوکر ہب ٹیگ ہے۔ v0.2.0. اس ٹیگ کو کسی مخصوص کمٹ یا کوڈ کے جائزے سے جوڑنے والی کوئی چیز نہیں ہے۔

• اگر v0.2.0 کیا یہ ٹوٹ گیا ہے؟ آپ کو پچھلا ٹیگ یاد رکھنے اور پھر اس پر عمل کرنے کی ضرورت ہے۔ kubectl set image دوبارہ رول بیک کریں۔ اگر آپ کو ٹیگ یاد نہیں ہے تو کیا ہوگا؟ اگر میری پرانی تصویر کو حذف کر دیا جائے تو کیا ہوگا؟

• اگر کوئی اور بھاگے تو کیا ہوگا؟ kubectl apply کے ساتھ v0.1.0 جب آپ زور دے رہے ہیں۔ v0.2.0? آپ کا کلسٹر خود بخود پچھلے ورژن پر واپس آجائے گا۔ کوئی غلطیاں نہیں ہیں۔ کوئی اطلاعات نہیں ہیں۔ میں نے سوچا کہ فکس لاگو کیا گیا تھا، لیکن یہ نہیں تھا.

• آڈٹ ٹریل کہاں ہے؟ یہ کہیں نہیں ہے۔ ریگولیٹڈ ماحول (بینکنگ، ہیلتھ کیئر، گورنمنٹ) کو اس بات کا ثبوت درکار ہوتا ہے کہ کس نے کیا اور کب تقسیم کیا۔ اب کچھ نہیں ہے۔

ڈیمو میں دستی تعیناتی ممکن ہے۔ تاہم، وہ ٹیموں یا ریگولیٹڈ ماحول کو برداشت نہیں کرتے ہیں۔ ان خلا کو ذہن میں رکھیں۔ اس لیے اگلا مرحلہ موجود ہے۔

مرحلہ 5: جاری رکھنے سے پہلے اپنی تبدیلیاں واپس کریں۔

اسٹیٹ اینڈ پوائنٹ کی تبدیلیوں کو کالعدم کریں۔ app/auth-service/main.py (ہٹائیں "version": "0.2.0")۔ دوبارہ تعمیر نہ کریں۔ کلسٹر چلتا رہے گا۔ v0.2.0 اب، میں فیز 1 میں امیج مینجمنٹ کا انچارج ہوں۔

مرحلہ 1 تعمیر کو خودکار کرتا ہے۔ مرحلہ 2 میں، آپ اپنی تعیناتی میں ترمیم کرتے ہیں۔

ہم نے مرحلہ 0 میں کیا سیکھا۔

• ملٹی پاس اور مائیکرو کے 8 کا استعمال کرتے ہوئے مقامی کبرنیٹس کلسٹر کی فراہمی کیسے کریں۔

• کس طرح ایک Kubernetes مینی فیسٹ مطلوبہ نظام کی حالت کو بیان کرتا ہے۔

• داخلی خدمات کی طرف بیرونی ٹریفک کو کیسے داخل کرتا ہے۔

• کنٹینر کی تصاویر کو دستی طور پر بنانے، دھکیلنے اور تعینات کرنے کا طریقہ

• آپ دستی تعیناتی پر اعتماد کیوں نہیں کر سکتے: کوئی آڈٹ ٹریل نہیں، کوئی رول بیک نہیں، کوئی مستقل مزاجی نہیں۔

اب آپ اپنے تجربے کی فہرست میں کیا ڈال سکتے ہیں/ایک انٹرویو میں کہہ سکتے ہیں:

آپ ملٹی سروس ایپلی کیشنز بشمول نیم اسپیسز، RBAC، StatefulSet ڈیٹا بیس، ڈسٹری بیوشنز، سروسز، اور پاتھ پر مبنی انگریس روٹنگ کو براہ راست Kubernetes پر تعینات کر سکتے ہیں اور وضاحت کر سکتے ہیں کہ ہر پرت کو اس ترتیب میں کیوں تعینات کیا گیا ہے۔

make snapshot STAGE=0 && make snapshots. چیک کریں clearledger.stage0. دیکھیں کہ اپنی ترقی کو کیسے بچایا جائے۔

مرحلہ 1 — CI پائپ لائن (GitHub ایکشنز + خود میزبانی کرنے والا)

مرحلہ 0 میں، ہم نے اسے خود بنایا اور تعینات کیا۔ مرحلہ 1 تعمیر کو خودکار کرتا ہے۔ git push ایک پائپ لائن چلائیں جو امیج بناتی ہے، اسے اسکین کرتی ہے، اسے Docker Hub میں دھکیلتی ہے، اور نئے ٹیگز ریکارڈ کرتی ہے۔ clearledger-infra.

ہدف: ہر بار جب آپ GitHub کی طرف دھکیلتے ہیں، ایک تصویر خود بخود بن جاتی ہے اور Docker Hub کی طرف دھکیل جاتی ہے، اور امیج ٹیگ کو اپ ڈیٹ کر دیا جاتا ہے۔ clearledger-infra.

کیا میں مرحلہ 1 لینے کے لیے تیار ہوں؟

یہ چلائیں اپنے آپ کو §1.1 سے پہلے:

make check-0
echo "$DOCKER_USERNAME"    # must not be empty or "your-username"
curl -s -o /dev/null -w "%{http_code}" http://clearledger.local/auth/health

متوقع: صحت کی جانچ سبز؛ echo Docker Hub صارف کو پرنٹ کریں اور پرنٹ کو ختم کریں۔ 200.

اس سیکشن کے لیے آپ کو کیا ضرورت ہے:

• ایک Docker Hub اکاؤنٹ جس میں چار Clearledger repositories ہیں (دیکھیں QuickSTART.md §1b)

• GitHub اکاؤنٹ: آپ کو ایک ذخیرہ اور ذاتی رسائی ٹوکن بنانے کی اجازت دیتا ہے۔

• پہلی گرین پائپ لائن کے لیے رنر کی تنصیب + ~ 2-4 گھنٹے (ابتدائی افراد کے لیے سب سے مشکل مرحلہ)

• مکمل ہونے پر: چیک 1 پاس کیا اور نیچے §1.7 میں 5 آئٹمز کو دستی طور پر چیک کیا۔ پھر محفوظ کریں: اسنیپ شاٹ بنائیں STAGE=1 → اسنیپ شاٹ بنائیں (clearledger.stage1 کو چیک کریں)۔

آپ کو پہلے کیا جاننے کی ضرورت ہے۔

فیز 0 میں، ایک لیپ ٹاپ تعیناتی کا نظام تھا۔

آپ نے داخل کیا docker build, docker pushاور kubectl set image اپنے آپ کو اس نے ڈیمو کے لیے کام کیا، لیکن یہ نہیں ہے کہ ٹیم کس طرح سافٹ ویئر جاری کرتی ہے۔

دستی تعمیرات بہت سارے جواب طلب سوالات پیدا کرتی ہیں۔

• کیا یہ تصویر تازہ ترین کوڈ سے ہے؟

• کیا کسی نے اسے گندی ورکشاپ کی لکڑی سے بنایا ہے؟

• کیا تعمیر دوسرے کمپیوٹرز پر بھی اسی طرح کام کرتی تھی؟

• فی الحال چل رہی امیج کو کس عہد نے بنایا؟

• تصویر کو کس نے اور کب دھکیل دیا؟

مسلسل انضمام (CI) مسئلے کے تعمیراتی پہلو کو درست کریں۔ اس کا مطلب یہ ہے کہ جب بھی کوڈ کو آگے بڑھایا جاتا ہے، خودکار نظام اسے اسی طرح بناتے، تصدیق کرتے اور پیک کرتے ہیں۔

CI کو فیکٹری لائن کے طور پر سوچیں۔

Developer pushes code
        ↓
GitHub detects the push
        ↓
GitHub Actions starts the pipeline
        ↓
Runner executes the jobs
        ↓
Docker images are built and pushed
        ↓
Infra manifests are updated with the new image tags  (in clearledger-infra — §1.3)

اہم خیال یہ ہے کہ آپ کی تعمیر اب آپ کے لیپ ٹاپ پر منحصر نہیں ہے۔ نوٹ بک کوڈ لکھتی ہیں اور پائپ لائنیں ریلیز کے نمونے تیار کرتی ہیں۔

CI نظام تین حصوں پر مشتمل ہے:

1. پائپ لائن میزبان: کنٹرول طیارہ۔ ایک پش کا پتہ لگائیں اور فیصلہ کریں کہ کون سا ورک فلو عمل میں لانا ہے۔ اس لیب میں گٹ ہب آپریشنز.

2. پائپ لائن فائل: رہنما خطوط YAML فائل یہاں واقع ہے: .github/workflows/ci.yaml یہ آپ کو بتاتا ہے کہ کون سا عمل چلانا ہے۔

3. رنر: ورکر مشین۔ دراصل پائپ لائن میں کمانڈ پر عمل کرتا ہے۔

GitHub ایکشنز عام طور پر کلاؤڈ میں GitHub کی میزبانی کرنے والے رنرز کا استعمال کرتی ہے۔ اس لیب میں، یہ کافی نہیں ہے۔ Kubernetes کلسٹر مقامی Multipass VM کے اندر ہے، اور GitHub کا کلاؤڈ رنر اس تک نہیں پہنچ سکتا۔ مزید برآں، اگر آپ مقامی ڈوکر ڈیمون کا استعمال کرتے ہوئے ڈوکر امیجز بنانا چاہتے ہیں، تو آپ کو VM کے اندر لانچر کی ضرورت ہوگی۔

لہذا، ہم VM کے اندر ایک خود میزبان ایگزیکیٹر انسٹال کرتے ہیں۔ آؤٹ باؤنڈ کو GitHub سے جوڑیں، نوکری کا انتظار کریں، اور پھر پائپ لائن کا کام مقامی طور پر چلائیں جہاں ہر چیز پہنچ سکتی ہے۔

دو ذخیرے، clearledger (کوڈ + CI) اور clearledger-infra (صرف Kubernetes YAML) §1.3 میں دوسری اندراج بنائیں۔

GitHub — clearledger (app repo)
  stores your code
  starts the workflow on git push
        ↓
Self-hosted runner (inside Multipass VM)
  builds Docker images
  pushes images to Docker Hub
  updates image tags in clearledger-infra  ← you create this in §1.3
        ↓
GitHub — clearledger-infra (infra repo)
  stores Kubernetes YAML with the new image tags
  ArgoCD watches this repo in Stage 2 (not yet)

مراحل 1-7 کے لیے، لیب استعمال کرتی ہے: .github/workflows/ci.yaml خود میزبان رنر کے ساتھ۔ تصویر بنائیں، اسے Docker Hub پر پش کریں، اور اسے اپ ڈیٹ کریں۔ clearledger-infra. مرحلہ 8 ایک علیحدہ AWS ورک فلو شامل کرتا ہے۔ .github/workflows/ci-aws.yamlاس کے بجائے، اسے ECR پر دھکیل دیا جاتا ہے۔ آپ کو AWS ورک فلو کو ترتیب دینے کی ضرورت نہیں ہے جب تک کہ آپ مرحلہ 8 تک نہ پہنچ جائیں۔

1.1: اپنے ایپ ریپو کو GitHub پر پش کریں۔ clearledger-infra ابھی تک)

یہ مرحلہ ہے۔ ذخیرہ نمبر 1، clearledger (ایپلی کیشن کوڈ + CI ورک فلو)۔ میں اپنے لیپ ٹاپ سے ایک نقل نکال رہا ہوں۔ وہی فولڈر جہاں آپ نے اسٹیج 0 چلایا (make setup, kubectl applyوغیرہ)۔

clearledger-infra یہ بعد میں §1.3 میں ظاہر ہوتا ہے۔ دوسرا ذخیرہ صرف Kubernetes مینی فیسٹ رکھتا ہے۔ اسے یہاں مت بنائیں۔

سب سے پہلے، اپنی ایپلیکیشن ریپوزٹری کو ایسی جگہ پر رکھیں جہاں GitHub ایکشنز دیکھ سکیں۔

GitHub پر جائیں اور پھر اپنے نئے ذخیرے پر جائیں۔

• مخزن کا نام: clearledger (یہ صحیح نام نہیں ہے۔ clearledger-infra)

• گھڑی: عوامی یا نجی؟. دونوں خود میزبان لانچرز اور GitHub ایکشنز کے ساتھ کام کرتے ہیں۔ ArgoCD اس ذخیرہ کو نہیں پڑھتا ہے (نجی ذخیرے: §1.3 میں مطابقت پذیری کے مقامات دیکھیں)۔

• کرو ~ نہیں README یا پر ری سیٹ کریں۔ .gitignore

ریپوزٹری میں پہلے سے ہی وہ فائل مقامی طور پر موجود ہے۔ اگر GitHub اپنے آپ کو دھکا دیتا ہے، تو پہلا دھکا ناکام ہو سکتا ہے کیونکہ ریکارڈز مماثل نہیں ہیں۔

آپ کا مقامی clearledger منصوبے کی جڑ لیپ ٹاپ (کہاں؟ app/, infra/اور .github/workflows/ci.yaml لائیو):

cd ~/Desktop/clearledger   # your clone path
git remote add origin https://github.com/YOUR_USERNAME/clearledger.git
git branch -M main
git push -u origin main

اگر git remote add کیونکہ یہ ناکام ہو جاتا ہے۔ origin پہلے سے موجود ہے:

git remote -v
git remote set-url origin https://github.com/YOUR_USERNAME/clearledger.git
git push -u origin main

اسے اپنے براؤزر میں چیک کریں: https://github.com/YOUR_USERNAME/clearledger.

آپ کو دیکھنا چاہئے app/, infra/manifests/, docs/اور .github/workflows/ci.yaml. یہ اس بات کی تصدیق کرتا ہے کہ گٹ ہب اگلے دھکے پر پائپ لائن کو متحرک کرسکتا ہے۔

جو آپ نے ثابت کیا ہے: کہ ایپ اسٹور یہ GitHub پر ہے۔ CI یہاں چلتا ہے۔ GitOps زمین کے لیے تعیناتی کا منشور clearledger-infra §1.3 میں۔

1.2: VM کے اندر سیلف ہوسٹڈ ایگزیکیوٹر انسٹال کریں۔

ورک فلو فائل GitHub کو مطلع کرتی ہے۔ کیا چلائیں رنر کہاں یہ چلتا ہے۔

چونکہ بنیادی ڈھانچہ مقامی ہے، اس لیے یہ لیب ایک خود میزبان ایگزیکٹو کا استعمال کرتی ہے۔ GitHub کے کلاؤڈ سرورز ایک Multipass VM کے اندر MicroK8s کلسٹر یا Docker ڈیمون سے منسلک نہیں ہو سکتے۔ رنرز VM کے اندر رہ کر اس مسئلے کو حل کرتے ہیں۔ GitHub سے جڑیں، کاموں کو منتخب کریں، اور پھر ہر چیز کو مقامی طور پر چلائیں۔

اگر ایگزیکیوٹر غائب یا آف لائن ہے تو پائپ لائن نہیں چل سکتی۔ ورک فلو ناکام ہو سکتا ہے کیونکہ یہ قطار میں ہے یا کوئی مماثل ایگزیکیوٹر نہیں ہے۔

مرحلہ 1: GitHub کے لانچر کی ترتیبات کا صفحہ کھولیں (اس ٹیب کو کھلا رکھیں)

GitHub ایک صفحے پر کاپی پیسٹ انسٹالیشن گائیڈ فراہم کرتا ہے۔ اس سے فائدہ اٹھائیں۔ کہیں اور یو آر ایل یا ٹوکن تلاش نہ کریں۔

1. کھلا https://github.com/YOUR_USERNAME/clearledger

2. سیٹنگز، ایکشنز، لانچرز اور نئے سیلف ہوسٹڈ لانچر پر جائیں۔

3. لینکس اور x64 کا انتخاب کریں۔

صفحہ کا عنوان ہونا چاہیے: نیا خود میزبان لانچر YOUR_USERNAME/clearledger شامل کیا گیا۔.

اس صفحہ پر استعمال کرنے کے لیے تین حصے ہیں:

گٹ ہب سیکشن	اس کے ساتھ کیا کرنا ہے؟
ڈاؤن لوڈ	کاپی mkdir, curlاور tar مرحلہ 4 میں VM کے لیے کمانڈز (نیچے جیسا ورژن)
مرکب	کاپی ٹوکن پر ./config.sh ... --token ... line: کرنا ~ نہیں GitHub چلائیں۔ ./config.sh جیسا کہ ہے
خود میزبان لانچر استعمال کریں۔	اسے فی الحال نظر انداز کریں۔ لیب ورک فلو کی ضرورت ہے: clearledger لیبل (4 مراحل)

اگلے پر سکرول کریں۔ مرکب. آپ کو کچھ اس طرح نظر آئے گا:

./config.sh --url https://github.com/YOUR_USERNAME/clearledger --token AXXXXXXXXXXXXXXXXXXXXXXXXX
./run.sh

ایک ٹوکن ایک لمبی تار ہے: --token (کے ساتھ شروع کریں۔ Aتقریباً 26 حروف)۔ صرف اس تار کو کاپی کریں۔

مرحلہ 4 مکمل ہونے تک اس ٹیب کو کھلا رکھیں۔ ٹوکن کی میعاد تقریباً ختم ہو جاتی ہے۔ 1 گھنٹہ. اس کی میعاد ختم ہونے کے بعد، نیا ٹوکن حاصل کرنے کے لیے نئے خود میزبان لانچر پر دوبارہ کلک کریں۔

مرحلہ 2: VM درج کریں۔

multipass shell clearledger

اس کمانڈ کے بعد، پرامپٹ اس طرح نظر آنا چاہیے: ubuntu@clearledger:~$. اس کا مطلب ہے کہ آپ Ubuntu VM کے اندر ہیں۔ اگر پرامپٹ اب بھی آپ کا میک صارف نام یا MacBook نام دکھاتا ہے، تو آپ اب بھی میزبان سسٹم پر ہیں اور لانچر سیٹ اپ ناکام ہو جائے گا۔

اشارہ کرنے پر ہی جاری رکھیں۔ ubuntu@clearledger.

مرحلہ 3 کے بعد سب کچھ VM کے اندر چلتا ہے، آپ کے میک پر نہیں۔

مرحلہ 3: VM کے اندر ڈوکر انسٹال کریں۔

لانچر ڈوکر امیج بناتا ہے۔ اس کا مطلب یہ ہے کہ جہاں ایگزیکیوٹر چلتا ہے وہاں ڈوکر کا موجود ہونا ضروری ہے۔

curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker ubuntu
newgrp docker

docker --version

متوقع: Docker ورژن نمبر پرنٹ کرے گا، جیسے Docker version 29.x.x)۔

یقینی بنائیں کہ ڈوکر اس کے ساتھ کام کر رہا ہے: ubuntu اب صارف: رنر ابھی موجود نہیں ہے۔ (مرحلہ 4 میں بنایا گیا ہے۔ ~/actions-runner):

docker ps

متوقع: ٹیبل ہیڈر (کنٹینر ID، IMAGE، …) چاہے کنٹینر درج نہ ہو۔ نہیں permission denied while trying to connect to the Docker API.

اگر docker ps یہ ناکام ہوجاتا ہے کیونکہ اجازت سے انکار کردیا جاتا ہے۔ docker گروپ نے ابھی تک درخواست نہیں دی ہے۔ چلائیں newgrp docker VM سے دوبارہ چلائیں یا لاگ آؤٹ کریں (exit) اور multipass shell clearledger براہ کرم دوبارہ درج کریں اور دوبارہ کوشش کریں۔ docker ps.

جو آپ نے ثابت کیا ہے: VMs میک پر ڈوکر ڈیسک ٹاپ کے بغیر ڈوکر چلا سکتے ہیں۔ رنر کو انسٹال کرنے کے لیے مرحلہ 4 پر جاری رکھیں۔

مرحلہ 4: لانچر کو انسٹال اور رجسٹر کریں۔

ابھی بھی VM کے اندر (ubuntu@clearledger فوری):

ڈاؤن لوڈ کریں: آپ کمانڈ کو یہاں سے کاپی کر سکتے ہیں: ڈاؤن لوڈ GitHub لانچر صفحہ پر سیکشن (مرحلہ 1) چلائیں یا نیچے بلاک کو چلائیں۔ انہیں میچ کرنا چاہئے۔ اسے میک میں نہیں بلکہ VM میں چسپاں کریں۔

ترکیب: براہ کرم ذیل میں لیب کمانڈز کا استعمال کریں، نہ کہ GitHub کے کمانڈز۔ ./config.sh لائن مرحلہ 1 سے ٹوکن کو چسپاں اور تبدیل کریں۔ YOUR_USERNAME.

mkdir -p ~/actions-runner && cd ~/actions-runner

curl -o actions-runner-linux-x64-2.335.1.tar.gz -L 
  https://github.com/actions/runner/releases/download/v2.335.1/actions-runner-linux-x64-2.335.1.tar.gz

tar xzf ./actions-runner-linux-x64-2.335.1.tar.gz

./config.sh 
  --url https://github.com/YOUR_USERNAME/clearledger 
  --token YOUR_RUNNER_TOKEN 
  --name clearledger-runner 
  --labels clearledger,self-hosted,linux 
  --work _work 
  --unattended

sudo ./svc.sh install
sudo ./svc.sh start

کرو ~ نہیں GitHub چلائیں۔ ./run.sh معمول کے استعمال کے لیے: لیبارٹریوں میں ہم استعمال کرتے ہیں: sudo ./svc.sh لہذا ایگزیکیوٹر VM ریبوٹس پر برقرار رہے گا۔ گٹ ہب شو ./run.sh صرف فوری جانچ کے لیے۔

کے بعد متوقع ./config.sh: Runner successfully added (یا اسی طرح). اگر آپ کو کوئی غلط یا ختم شدہ ٹوکن نظر آتا ہے، تو اپنے براؤزر میں مرحلہ 1 پر واپس جائیں اور ایک نیا ٹوکن کاپی کریں۔

کہ clearledger GitHub پر لیبل ڈیفالٹ کی ضرورت ہے۔ ./config.sh اسے ترتیبات کے صفحہ میں شامل نہیں کیا گیا ہے۔ ورک فلو استعمال کرتا ہے:

runs-on: [self-hosted, clearledger]

GitHub ایگزیکیوٹر لیبل کی بنیاد پر کاموں کو شیڈول کرتا ہے، ایگزیکیوٹر کے نام پر نہیں۔ ایک دوڑنے والا نام clearledger بغیر clearledger لیبل آن لائن رہتا ہے، لیکن کام قطار میں رہتا ہے۔ Waiting for a runner to pick up this job.

آخری دو احکام کا مفہوم یہ ہے:

sudo ./svc.sh install
  Registers the runner with systemd inside the VM.
  Without this, `sudo ./svc.sh status` says: not installed.

sudo ./svc.sh start
  Starts the runner service in the background.
  After this, it keeps running even when you close the terminal.

VM کے اندر اسی فولڈر میں اسے مقامی طور پر چیک کریں۔

cd ~/actions-runner
sudo ./svc.sh status

متوقع: سروس انسٹال اور چل رہی ہے۔

اگر docker ps مرحلہ 3 نے کام کیا، لیکن بعد میں ڈوکر ساکٹ کی اجازت سے انکار کے ساتھ CI آپریشن ناکام ہوگیا۔ یہ شاید لانچر کے شروع ہونے سے پہلے شروع ہوا تھا۔ docker گروپ کو اپلائی کر دیا گیا ہے۔ مرحلہ 4 کے بعد دوبارہ شروع کریں۔ ~/actions-runner موجود ہے):

cd ~/actions-runner
sudo ./svc.sh stop
sudo ./svc.sh start
docker ps    # must work without sudo

یا، اگر آپ نے لانچر کو دستی طور پر استعمال کرتے ہوئے شروع کیا ہے: ./run.sh سسٹم کے بجائے:

cd ~/actions-runner
pkill -f "Runner.Listener|Runner.Worker|./run.sh" || true
nohup ./run.sh > _diag/manual-runner.log 2>&1 &
docker ps

اگر آپ یہ دیکھتے ہیں:

not installed

پھر sudo ./svc.sh install یہ کامیابی سے نہیں چل سکا۔ چلائیں:

cd ~/actions-runner
sudo ./svc.sh install
sudo ./svc.sh start
sudo ./svc.sh status

اگر install ناکام، دوبارہ کوشش کریں۔ ./config.sh نئے GitHub رنر ٹوکن کا استعمال کرتے ہوئے install/start کمانڈ کو دوبارہ چلائیں۔

مرحلہ 5: VM کو بند کریں۔

exit

مرحلہ 6: تصدیق کریں کہ رنر منسلک ہے۔

github.com/YOUR_USERNAME/clearledger پر جائیں اور پھر سیٹنگز، ٹاسکس اور لانچرز پر جائیں۔

آپ کو دیکھنا چاہئے clearledger-runner سبز نقطہ اور حیثیت سست. رنر کی تفصیلات کھولیں اور یقینی بنائیں کہ لیبل میں شامل ہیں:

self-hosted
Linux
X64
clearledger

اگر clearledger اگر آپ اسے کھو دیتے ہیں، تو ورک فلو کو دوبارہ چلانے سے پہلے اسے اپنے لانچر کی ترتیبات میں شامل کریں۔ صرف رنر کا نام کافی نہیں ہے۔

چیک پوائنٹ کی مشق کریں: رنرز کارروائی کے لیے تیار ہیں۔

GitHub، ترتیبات، کاموں، اور رنرز کو چیک کرنا جاری رکھیں:

میدان	متوقع
صورت حال	سست (سبز)
لیبل	شامل self-hosted اور clearledger
آپریٹنگ سسٹم	لینکس

پھر اپنے لیپ ٹاپ پر ٹیسٹ رن چلائیں۔

git commit --allow-empty -m "test: verify runner picks up jobs"
git push

کھلا https://github.com/YOUR_USERNAME/clearledger/actions. 30 سیکنڈ کے اندر، ورک فلو پر عمل درآمد انتظار اور پیش رفت کے طور پر ظاہر ہونا چاہیے، نہ کہ "انتظار کرنے والے کا انتظار”۔ اگر آپ 2 منٹ سے زیادہ انتظار کرتے ہیں، تو لیبل غلط ہے۔ GitHub پر لانچرز میں ترمیم کریں اور شامل کریں۔ clearledger.

اگر یہ آف لائن ظاہر ہوتا ہے:

multipass exec clearledger -- sudo systemctl status actions.runner.*.service
multipass exec clearledger -- journalctl -u actions.runner.*.service --lines=50

جو آپ نے ثابت کیا ہے: GitHub اب آپ کے مقامی لیب ماحول میں کام بھیج سکتا ہے۔

1.3: GitHub پر انفرا ریپو بنائیں

اب الگ سے درخواست کوڈ سے تعیناتی کی حیثیت. مرحلہ 1 دوسرا GitHub ذخیرہ متعارف کراتا ہے۔ clearledger ایپ اسٹور کو §1.1 میں دھکیل دیا گیا۔

لیب کا باقی حصہ دو ذخیرے استعمال کرتا ہے۔

ریپو	وہاں کیا رہتا ہے؟	اسے کون بدلتا ہے؟	یہ کیوں موجود ہے
clearledger	ایپ سورس کوڈ، ڈاکر فائل، ٹیسٹنگ، .github/workflows/ci.yamlہاتھ پر دستاویزات	آپ، ڈویلپر	یہیں سے کوڈ کی تبدیلیاں شروع ہوتی ہیں۔
clearledger-infra	Kubernetes صرف ظاہر کرتا ہے: deployment.yaml, service.yamlآنے والا، خفیہ ٹیمپلیٹ	CI پائپ لائن، ArgoCD، اسے پڑھتی ہے۔	یہ کلسٹر کی مطلوبہ حالت ہے۔

سوچو clearledger ایک سوال کے طور پر "درخواست کیا ہے؟”. ازگر کی خدمات، ڈاکر فائلز، ٹیسٹنگ اور CI ورک فلوز۔ سوچو clearledger-infra پسند "آج مجھے کبرنیٹس کا بالکل کون سا ورژن چلانا چاہئے؟”. تعیناتی، سروس، رسید کے قواعد، اور تصویری ٹیگز جو Docker Hub کی طرف اشارہ کرتے ہیں۔

ٹیم نے جان بوجھ کر اسے الگ کر دیا۔ ترمیم کرتے وقت README.md کو clearledgerیہ دستاویز کی تبدیلی ہے۔ اسے تعیناتی کو متحرک نہیں کرنا چاہئے۔
اگر آپ تبدیل کرتے ہیں auth-service جب آپ اپنا کوڈ استعمال کرتے ہیں، تو پائپ لائن ایک نئی تصویر بناتی ہے، جیسے کہ ٹیگ abc123) اور اسکین گزر جانے کے بعد ہی clearledger-infra:

image: $DOCKER_USERNAME/clearledger-auth-service:abc123

وہ لائن تقسیم کا معاہدہ ہے۔ گٹ اب کلسٹرز سے مراد ہے۔ ضروری ہے چلائیں abc123. مرحلہ 1 میں، کلسٹرز ابھی تک تبدیل نہیں ہوئے ہیں (اور ہم اسے §1.6 میں ثابت کریں گے)۔
مرحلہ 2 میں، ArgoCD گھڑی clearledger-infraجو چل رہا ہے اس سے گٹ کا موازنہ کریں، اور اگر مختلف ہو تو کلسٹر کو ہم آہنگ کریں۔ ایپ اسٹور وہ جگہ ہے جہاں کام شروع ہوتا ہے۔ انفراسٹرکچر اسٹوریج وہی ہے جو پیداوار کی طرح لگتا ہے۔

نجی اسٹوریج: میں کیا اور کہاں مطابقت پذیر ہوں؟

یہ لیب دو GitHub ذخیرے استعمال کرتی ہے۔ clearledger یہ پروجیکٹ کا مرکزی ذخیرہ ہے، جس میں ایپ کوڈ، CI پائپ لائن، دستاویزات، پالیسیاں، اور لیب فائلیں شامل ہیں۔ یہ ذخیرہ نجی ہو سکتا ہے۔

clearledger-infra صرف Kubernetes مینی فیسٹ شامل ہیں۔ ArgoCD اس ذخیرہ کی نگرانی کرتا ہے اور اسے ایپس کی تقسیم کے لیے استعمال کرتا ہے۔ ابتدائیوں کے لیے، اس ذخیرہ کو عوامی بنائیں تاکہ ArgoCD اسے بغیر کسی اضافی تصدیق کے پڑھ سکے۔

بہاؤ مندرجہ ذیل ہے:

clearledger
app code + infra/manifests/
        ↓
CI copies infra/manifests/
        ↓
clearledger-infra
Kubernetes manifests only
        ↓
ArgoCD syncs from this repo
        ↓
Kubernetes cluster

ArgoCD مرکزی متن نہیں پڑھ سکتا۔ clearledger ریپو صرف پڑھیں clearledger-infra. اگر clearledger یہ ٹھیک ہے کیونکہ یہ نجی ہے۔ اگر clearledger-infra اگر یہ نجی ہے، تو آپ کو بعد میں اپنے ArgoCD GitHub کی اسناد فراہم کرنے کی ضرورت ہوگی۔ بصورت دیگر، آپ ArgoCD دیکھ سکتے ہیں۔ ComparisonError.

GitHub پر انفراسٹرکچر کا ذخیرہ بنائیں۔

1. GitHub پر جائیں اور پھر نیا ذخیرہ

2. براہ کرم اس کا نام دیں۔ clearledger-infra

3. منتخب کریں عوامی

4. README شامل نہ کریں۔

5. کلک کریں بنانا

CI پائپ لائن کو بعد میں اپ ڈیٹ کیا جائے گا۔ clearledger-infra خود بخود پائپ لائن مرحلے 1 میں نہیں چلتی ہے۔ kubectl apply – Git کو اپ ڈیٹ کریں۔ مرحلہ 2 میں، ArgoCD متعلقہ Git ذخیرہ کو پڑھتا ہے اور اسے کلسٹر پر لاگو کرتا ہے۔

دبانے سے پہلے: Kustomize میں اپنا Docker Hub صارف نام سیٹ کریں (تصویری ٹیگز یہاں حل کیے جاتے ہیں، آپ کی تعیناتی YAML میں نہیں)۔

# Replace YOUR_DOCKERHUB_USERNAME with the same value as $DOCKER_USERNAME from §0.3
sed -i.bak "s/YOUR_DOCKERHUB_USERNAME/${DOCKER_USERNAME}/g" infra/manifests/kustomization.yaml
rm -f infra/manifests/kustomization.yaml.bak

صرف Kubernetes مینی فیسٹ کو پش کریں۔ infra/manifests/ (نیچے سب کچھ نہیں۔ infra/):

mkdir -p /tmp/clearledger-infra
cp -r infra/manifests /tmp/clearledger-infra/
cd /tmp/clearledger-infra
git init
git remote add origin https://github.com/YOUR_USERNAME/clearledger-infra.git
git add . && git commit -m "feat: initial manifests" && git push -u origin main
cd -

لیب چیک پوائنٹ: GitHub پر انفراسٹرکچر ذخیرہ (§1.4 سے پہلے کیا گیا)

آپ کے لیپ ٹاپ پر:

grep "docker.io/${DOCKER_USERNAME}/" infra/manifests/kustomization.yaml | wc -l
grep YOUR_DOCKERHUB_USERNAME infra/manifests/kustomization.yaml || echo "OK: placeholder replaced"

متوقع: پہلا کمانڈ پرنٹ کیا گیا ہے۔ 4 (4 تصویری لائنیں)۔ دوسری پرنٹنگ OK: placeholder replacedیہ ابھی تک لائن 4 نہیں ہے، لیکن یہ کہتا ہے: YOUR_DOCKERHUB_USERNAME.

اپنے براؤزر میں، کھولیں: https://github.com/YOUR_USERNAME/clearledger-infra/tree/main/manifests چیک کریں اور اپنی آنکھوں سے:

فائل/فولڈر	موجود ہونا ضروری ہے
kustomization.yaml	ہاں اسے کھولیں: newName: لائن کا استعمال کریں آپ کا ڈوکر ہب صارف
auth-service/secret.yaml	ہاں لیول 2 سے 4 تک، آپ کو لیول 5 تک اس آئٹم کی ضرورت ہوگی۔
ledger-service/secret.yaml	ہاں
auth-service/deployment.yaml	ہاں اسے کھولیں: اس میں درج ذیل چیزیں ہونی چاہئیں۔ secretKeyRef, ~ نہیں vault.hashicorp.com
netpol/	نہیں. اگر فولڈر موجود ہے تو اسے مرحلہ 2 سے پہلے GitHub سے حذف کر دیں۔
vault/	نہیں. والٹ کی گردش صرف مرحلہ 5 پر لاگو ہوتی ہے۔

کون سے فولڈرز اہم ہیں؟ تم نے صرف دھکا دیا infra/manifests/ GitHub پر، یہ ٹھیک ہے. اس ذخیرہ میں باقی سب کچھ فی الحال مقامی ہے۔

بعد کے مراحل کے لیے کچھ ظاہر (نیٹ ورک کی پالیسیاں، والٹ اضافہ) infra/deferred-by-stage/ پر clearledger ریپو ایک بار جب آپ اس مرحلے پر پہنچ جائیں گے، آپ اسے براہ راست لاگو کریں گے۔ کرو ~ نہیں وہ فولڈر clearledger-infraیا ArgoCD اسے بہت جلد تقسیم کرے گا۔

آپ نے محسوس کیا ہوگا۔ stages/stage-1-ci-pipeline/ مینی فیسٹ کی کوئی کاپی نہیں ہے۔ یہ عام بات ہے۔ ہماری لیب میں، ہم YAML کی نقل نہیں بناتے ہیں۔ یہاں مکمل کاپی ہے: infra/manifests/ یہ اس ذخیرہ میں ہے، اور ایک لائیو GitOps کاپی یہ ہے: clearledger-infra GitHub پر۔

جو آپ نے ثابت کیا ہے: Kubernetes کنفیگریشنز کے پاس اب آپ کے ایپلیکیشن کوڈ سے الگ ان کے اپنے ذخیرے اور Git کی تاریخ ہے۔ CI کو اپ ڈیٹ کر دیا گیا ہے۔ clearledger-infra ہر تعمیر کے بعد، کوڈ اور پائپ لائن فائلوں کے لیے ایک ایپ ریپوزٹری کو برقرار رکھا جاتا ہے۔

1.4: GitHub خفیہ ترتیبات

تحریک github.com/YOUR_USERNAME/clearledger پھر Settings, Secrets and Variables, Actions, New Storage Secret کو منتخب کریں۔

ورک فلو کو Docker Hub، GitHub، اور امیج پر دستخط کرنے کے لیے اسناد درکار ہیں۔

• Docker Hub – آپ کو تصاویر کو آگے بڑھانے کی اجازت دیتا ہے۔

• GitHub، آپ کو GitHub پر امیج ٹیگ اپ ڈیٹس کو آگے بڑھانے کی اجازت دیتا ہے۔ clearledger-infra.

• Cosign – آپ تصویر کو دبانے کے بعد اس پر دستخط کر سکتے ہیں۔

کرو ~ نہیں ان اقدار کو اپنی YAML فائل میں چسپاں کریں۔ GitHub ایکشنز کو بطور خفیہ محفوظ کریں۔

راز 1، DOCKER_USERNAME

یہ آپ کا Docker Hub صارف نام ہے۔

ہاں:

veeno-demo

اسے Docker Hub (hub.docker.com، پروفائل مینو، اکاؤنٹ کی ترتیبات) سے حاصل کریں۔

راز 2، DOCKER_PASSWORD

Docker Hub ہونا ضروری ہے۔ رسائی ٹوکنیہ ایک عام Docker Hub پاس ورڈ نہیں ہے۔

اسے یہاں بنائیں:

hub.docker.com
→ Account Settings
→ Security
→ New Access Token
→ Description: clearledger-github-actions
→ Access permissions: Read, Write, Delete or Read/Write
→ Generate

فوری طور پر ٹوکن کاپی کریں۔ Docker Hub اسے صرف ایک بار دکھاتا ہے۔

راز 3، INFRA_REPO_TOKEN

یہ GitHub پرسنل ایکسس ٹوکن (PAT) ہے۔ پائپ لائن اسے دوسرے ذخیرے میں کمٹ کو آگے بڑھانے کے لیے استعمال کرتی ہے۔ clearledger-infra.

اسے یہاں بنائیں:

GitHub profile settings
→ Settings
→ Developer settings
→ Personal access tokens
→ Tokens (classic)
→ Click "Generate new token"
→ Choose "Generate new token (classic)"
→ If GitHub asks for your password or 2FA, complete it
→ Note: clearledger-infra-ci
→ Expiration: choose a lab-friendly value
→ Select scope: repo
   This allows the pipeline to push to clearledger-infra.
→ Generate token

فوری طور پر ٹوکن کاپی کریں۔ GitHub اسے صرف ایک بار دکھاتا ہے۔

اس لیب میں repo دائرہ کار سب سے آسان آپشن ہے۔ پروڈکشن میں، سخت اجازتوں کا استعمال کریں جیسے کہ باریک ٹوکن تک محدود: clearledger-infra.

راز 4 اور 5 COSIGN_PRIVATE_KEY اور COSIGN_PASSWORD

آپ کی پائپ لائن نے ڈوکر ہب کی طرف دھکیلنے کے بعد کنٹینر کی تصاویر کو سائن سائن کریں۔ بعد میں، مرحلہ 4 میں، ہم Kyverno کے ساتھ عوامی کلید استعمال کرتے ہیں، تاکہ کلسٹر اس بات کی تصدیق کر سکے کہ تصویر قابل اعتماد پائپ لائن سے ہے۔

ملٹی پاس VM کے اندر نہیں، میزبان سسٹم پر کلیدی جوڑا بنائیں۔

# macOS: brew install cosign
# Linux/WSL2: curl -sSL -o cosign https://github.com/sigstore/cosign/releases/latest/download/cosign-linux-amd64 && chmod +x cosign && sudo mv cosign /usr/local/bin/
cosign generate-key-pair

یہ پیدا کرتا ہے:

cosign.key   # private key — never commit this
cosign.pub   # public key — keep for later Kyverno verification

جب Cosign آپ سے پاس ورڈ مانگے تو اسے درج کریں اور اسے اپنے پاس ورڈ مینیجر میں محفوظ کریں۔ اگر آپ نے پہلے ہی بغیر پاس ورڈ کے کلید بنائی ہے تو اس مشق کے لیے اسے پاس ورڈ کے ساتھ دوبارہ تخلیق کریں۔

یہ پانچ راز clearledger ریپو، نہیں clearledger-infra:

خفیہ نام	قدر	مقصد
DOCKER_USERNAME	Docker Hub صارف نام	تصاویر کو آگے بڑھانے کے لیے اپنی پائپ لائن میں لاگ ان کریں۔
DOCKER_PASSWORD	ڈاکر حب تک رسائی کا ٹوکن	پائپ لائن Docker Hub کے ساتھ تصدیق کرتی ہے۔
INFRA_REPO_TOKEN	GitHub PAT اوپر	پائپ لائن امیج ٹیگ اپ ڈیٹس کو Clearledger-infra پر دھکیلتی ہے۔
COSIGN_PRIVATE_KEY	تفصیل cosign.key	پائپ لائن کی نمائندگی کے ساتھ کنٹینر کی تصویر کو آگے بڑھایا گیا۔
COSIGN_PASSWORD	Cosign کلید بناتے وقت پاس ورڈ استعمال کیا جاتا ہے۔	دستخط کرنے کے دوران نجی کلید کو غیر مقفل کرتا ہے۔

ذخیرہ متغیر (خفیہ نہیں) (اختیاری) اگلے مرحلے پر جائیں۔ ذیل میں شامل کریں ترتیبات، راز اور متغیرات، اعمال، متغیرات:

متغیر	مرحلہ 1	کب چالو کرنا ہے۔
ENABLE_ARGOCD_SYNC	چھوڑ دو مقرر نہیں	مرحلہ 2 – ارگو سی ڈی کی پہلی ہم آہنگی کے بعد نارمل ہے (دیکھیں CI ایکٹیویشن → ArgoCD ہینڈ آف)
ENABLE_DAST	چھوڑ دو مقرر نہیں	مرحلہ 3 – ایپ کے فعال ہونے کے بعد clearledger.local (DAST ایکٹیویشن دیکھیں)

مرحلہ 1 میں کوئی متغیرات شامل نہ کریں۔ اگر آپ اسے ابھی ترتیب دیتے ہیں، تو CI آرگو سی ڈی کو ریفریش کرنے کی کوشش کرے گا یا کلسٹر کے تیار ہونے سے پہلے ZAP کو چلانے کی کوشش کرے گا، جس سے آپ کی پائپ لائن آؤٹ پٹ کو پڑھنا مشکل ہو جائے گا۔ گائیڈ آپ کو ہر ڈیوائس کو آن کرنے کا صحیح لمحہ بتاتا ہے۔ بس یاد رکھیں کہ دونوں موجود ہیں۔

جو آپ نے ثابت کیا ہے: ریپوزٹری میں اسناد کو ہارڈ کوڈ کیے بغیر پائپ لائنز بیرونی سسٹمز کی توثیق کر سکتی ہیں۔

1.5: پائپ لائن کو چالو کرنے سے پہلے اسے سمجھنا

ورک فلو فائلوں کے ساتھ جادو کی طرح سلوک نہ کریں۔ کھلا .github/workflows/ci.yaml چلانے سے پہلے پڑھیں۔

پائپ لائنوں کی دو ذمہ داریاں ہیں:

1. ثابت کریں کہ آپ کا کوڈ اور تصاویر شائع کرنے کے لیے محفوظ ہیں۔

2. نئے امیج ٹیگز کے ساتھ اپنے انفراسٹرکچر ریپوزٹری کو اپ ڈیٹ کریں۔

سب سے پہلے، سیکورٹی کا بہاؤ مندرجہ ذیل ہے:

Developer pushes code to GitHub
        ↓
GitHub Actions starts workflow
        ↓
Self-hosted runner inside the Multipass VM picks up the job
        ↓
1. Scan secrets (Gitleaks)
        ↓
2. Run code security scans (Semgrep) + IaC scan (Checkov) — parallel
        ↓
3. Prepare scanners (install Trivy/Syft/Grype/Cosign once; refresh Trivy DB once)
        ↓
4. BUILD: docker build all four services (local tags only; nothing hits Docker Hub yet)
        ↓
5. SCAN: Trivy on all images; Syft + Grype SBOM on auth-service; upload evidence
        ↓
6. PUBLISH: push to Docker Hub + Cosign sign (only if scan passed)
        ↓
7. UPDATE MANIFESTS: commit new image tags to clearledger-infra

بنائیں، اسکین کریں، شائع کریں (فراڈ اسٹائل گیٹ)

اصلی ٹیمیں پہلے نہیں دھکیلتی ہیں اور بعد میں اسکین کرتی ہیں۔ پائپ لائن تین مسائل کو تین کاموں میں الگ کرتی ہے۔ .github/workflows/ci.yaml:

نوکری	فنکشن	اگر آپ ناکام ہو گئے تو…
build-images	docker build ٹیگ کے ساتھ تمام خدمات ${{ github.sha }}	رجسٹری کی کوئی آلودگی نہیں ہے اور تصاویر کبھی بھی ایگزیکیوٹر کو نہیں چھوڑتی ہیں۔
scan-images	ٹریوی (تمام 4 تصاویر)؛ Syft + Grype (صرف تصدیق)	شائع کرنا چھوڑیں: خراب تصاویر کبھی بھی Docker Hub تک نہیں پہنچ پائیں گی۔
publish-images	پھانسی scripts/ci-publish-image.sh ٹیگ کریں، پش کریں، کو-سائن کریں۔	اسکین گزر جانے کے بعد ہی چلتا ہے۔

تم ہو ~ نہیں چلائیں scripts/ci-publish-image.sh اپنے کوڈ کو آگے بڑھانے سے پہلے خود کو چیک کریں۔ GitHub ایکشنز ریپوزٹری کو چیک کریں اور اسے اندر سے کال کریں۔ publish-images.

ایسا کیوں ممکن ہے؟ build-images اور scan-images کیا آپ کے پاس کوئی الگ کام ہے؟ ہر کام GitHub پر میزبانی کرنے والے رنر کے لیے ایک نیا چیک آؤٹ ہے۔ وہ ڈسک کا اشتراک نہیں کرتے ہیں۔ کو آپ کا خود میزبانی کرنے والا تینوں کام چلاتا ہے۔ ایک ہی ملٹی پاتھ VM اور وہی ڈوکر انجن.

ٹاسک 1 رنز۔ docker build اس تصویر کو کمپیوٹر پر چھوڑ دیں۔ جاب 2 اسی مقامی تصویر کے خلاف ٹریوی چلاتا ہے۔ کوئی اپ لوڈ یا ڈاؤن لوڈ نہیں ہے۔ ٹاسک 3 کو صرف اس صورت میں ڈوکر ہب کی طرف دھکیل دیا جاتا ہے جب اسکین گزر جائے۔

یہ ایک عملی لیب سیٹ اپ ہے جس میں ایک مستقل تعمیراتی مشین شامل ہوتی ہے جس میں Docker انسٹال ہوتا ہے، جیسے کسی فزیکل آفس میں ایک سرشار CI کارکن۔ میں مرحلہ 8 (AWS)پائپ لائن اس کے بجائے گٹ ہب پر میزبان ایک ایگزیکیوٹر کا استعمال کرتی ہے۔ build-images تصویر کو فائل میں محفوظ کریں (images.tar) اور اس فائل کو ورک فلو آرٹفیکٹ کے طور پر اگلے کام میں منتقل کریں۔ اس کی وجہ یہ ہے کہ ایگزیکیوٹر ایک ڈسپوزایبل VM ہے جس میں کوئی مشترکہ Docker کیش نہیں ہے۔

پھر GitOps ہینڈ آف آتا ہے۔

Secure images now exist in Docker Hub
        ↓
Runner checks out clearledger-infra from GitHub
        ↓
Deployment YAML image tags are updated
        ↓
Runner commits and pushes back to clearledger-infra
        ↓
Stage 1 ends here

یہاں یہ ہے کہ تصویر کا ٹیگ آپ کے کوڈ سے کیسے جڑتا ہے: تمام پائپ لائن پر عملدرآمد گٹ کمٹ کے ذریعہ شروع کیا جاتا ہے۔ GitHub اس عہد کے لیے درج ذیل منفرد ID فراہم کرتا ہے: SHA (ایک لمبی ہیکساڈیسیمل تار جیسے a1b2c3d4e5f6789…)۔ ورک فلو سیٹ IMAGE_TAG اس SHA سے ​​جڑیں اور اسے کہیں بھی استعمال کریں۔

1. تحریر: docker build -t clearledger-auth-service:a1b2c3d4…

2. میں پوسٹ کیا گیا: ڈاکر حب کو اس طرح دبائیں: YOUR_DOCKERHUB_USERNAME/clearledger-auth-service:a1b2c3d4…

3. اپ ڈیٹ مینی فیسٹ: kustomize edit set image …:a1b2c3d4… کو clearledger-infra

4. عہد کا پیغام: ci: deploy a1b2c3d4… — all gates passed

اگر پیداوار جاری ہے۔ YOUR_DOCKERHUB_USERNAME/clearledger-auth-service:a1b2c3d4آپ اسے کاپی کر سکتے ہیں۔ a1b2c3d4 بس اسے ٹیگ کریں، GitHub کھولیں، اور آپ کو فوری طور پر وہی کمٹ مل جائے گا جس نے اس تصویر کو بنایا تھا۔ اندازہ لگانے یا تعجب کرنے کی ضرورت نہیں۔ latest یہ بدل گیا ہے۔ ہر تعینات کردہ تصویر آپ کے کوڈ کے مخصوص ورژن کی طرف اشارہ کرتی ہے، جس سے رول بیکس اور ڈیبگنگ بہت آسان ہوتی ہے۔

پلیس ہولڈر کو حسب ضرورت بنائیں

auth-service/deployment.yaml اصل تصویری پتوں کے بجائے لیبل استعمال کریں۔

image: clearledger/auth-service:gitops

وہ لیبل Docker Hub پر نہیں ہے۔ کسٹمائز کو بتائیں کہ کہاں فال بیک کرنا ہے۔ میرا جسمانی پتہ درج ذیل پتے پر رہتا ہے: kustomization.yaml:

images:
  - name: clearledger/auth-service          # matches the label above
    newName: docker.io/YOUR_DOCKERHUB_USERNAME/clearledger-auth-service
    newTag: abc123def456…                   # real commit SHA — CI writes this

ایک بار جب ArgoCD تقسیم ہو جائے، kustomize build لیبل کو پورے پتے سے بدل دیں۔

آپ ترمیم کریں kustomization.yaml اپنا Docker Hub صارف نام §1.3 میں ایک بار سیٹ کریں۔ newName:. اس کے بعد، سی آئی لکھتا ہے: newTag: جب بھی آپ سبز دبائیں تو خود بخود۔ اسے اپنے ہاتھوں سے کبھی نہ چھوئے۔

مرحلہ 1: CI GitHub کو اپ ڈیٹ کرتا ہے، کلسٹر کو نہیں۔

ایک بار جب آپ کے پاس گرین پائپ لائن چلتی ہے، تو تین چیزیں لاگو ہوتی ہیں:

• Docker Hub پر ایک نئی تصویر ہے۔

• clearledger-infra GitHub کے پاس ایک نیا SHA ہے۔ kustomization.yaml

• آپ کا Kubernetes کلسٹر ہے۔ غیر تبدیل شدہ. جو مرحلہ 0 کا باقی ہے وہ اب بھی چل رہا ہے۔

سی آئی نہیں چلتی kubectl apply. یہ صرف ہے clearledger-infra. یہ پورا مرحلہ 1 سبق ہے۔ تعمیر اور اسکین خودکار ہیں، لیکن تقسیم ابھی تک نہیں۔ مرحلہ 2 ArgoCD انسٹال کرتا ہے۔ clearledger-infra اپنے کلسٹر کو اپ ڈیٹ کریں۔

Kubernetes معائنہ یہ مرحلہ 1 میں چلتا ہے، لیکن ~ نہیں پائپ لائن کو بلاک کریں۔ اپنی بہتریوں کا جائزہ لینے کے لیے اپنے نتائج اپ لوڈ کریں۔ مرحلہ 4 اس قسم کے قواعد کو کلسٹر نفاذ میں تبدیل کرنے کے لیے Kyverno کا استعمال کرتا ہے۔

یہ کام خود میزبانی کرنے والے پر انجام دیا جاتا ہے (runs-on: [self-hosted, clearledger])۔ دونوں ENABLE_ARGOCD_SYNC اور ENABLE_DAST مرحلہ 1 میں سیٹ نہیں کیا گیا ہے۔ §1.4 دیکھیں ان صورتوں کے لیے جہاں ہر آئٹم کو پلٹایا گیا ہو۔

اگر کام ناکام ہوجاتا ہے، تو اگلا شروع کریں۔ docs/troubleshooting.md ورک فلو میں ترمیم کرنے سے پہلے

لیول 1 سیکیورٹی کرنسی: بلاک بمقابلہ انتظار کریں۔

لیول 1 "سیکیورٹی آف” حالت نہیں ہے۔ کچھ دروازے پائپ لائن کو روکتے ہیں، جبکہ دیگر کو ثبوت تلاش کرنے کے لیے پھانسی دی جاتی ہے اور بعد کے مراحل میں مضبوط کیے جاتے ہیں۔

آج ہی پائپ لائن بلاک کریں۔

• Gitleaks (گٹ کے راز)

• Semgrep (Python میں SAST)

• ڈاکر فائل میں چیکوف

• ٹریوی (ہائی/کریٹیکل CVE تصویر میں قابل ترمیم)

• گریپ برائے تصدیقی خدمت SBOM (چپچپا ہائی +)

• مینی فیسٹ اپ ڈیٹ clearledger-infra (کامیاب ہونا ضروری ہے)

یہ چلتا ہے، لیکن ابھی تک مسدود نہیں ہوا ہے۔

• کبرنیٹس مینی فیسٹ میں چیکوف – نفاذ مرحلہ 4 (کیبرنو)

• شریک دستخط + SLSA تصدیق – نفاذ مرحلہ 4 (غیر دستخط شدہ تصاویر کو مسترد کر دیا جاتا ہے)

• Syft SBOM بنانا – سپلائی چین ثبوت۔ تم جان بوجھ کر دروازہ توڑو گے۔ مرحلہ 3۔

• ArgoCD ریفریش کریں – مرحلہ 2 (ENABLE_ARGOCD_SYNC=true)

• DAST/ZAP – مرحلہ 3 (ENABLE_DAST=true)

اگر آپ بھول جاتے ہیں کہ کن اقدامات سے کیا حل ہوتا ہے۔"لیول 1 سیکیورٹی ہیلتھ” تلاش کریں یا اس گائیڈ میں درج مراحل کی ترتیب پر عمل کریں۔ مرحلہ 3 جان بوجھ کر گیٹ کو تباہ کرتا ہے، مرحلہ 4 چیکوف کے نتائج کو کیورنو سے جوڑتا ہے، مرحلہ 5 گٹ میں رازوں کو منتقل کرتا ہے، مرحلہ 6 رن ٹائم کا پتہ لگاتا ہے، اور مرحلہ 7 ایک مانیٹرنگ ڈیش بورڈ کا اضافہ کرتا ہے۔

چلائیں make check-3 اور make check-4 اس قدم کے بعد، یقینی بنائیں کہ علاج ہوا ہے.

ڈیزائن کا ارادہ: فیز 1 یہ ظاہر کرتا ہے کہ سی آئی ڈوکر کو دستی طور پر چھوئے بغیر گٹ کو بنا سکتا ہے، اسکین کر سکتا ہے، پش اور اپ ڈیٹ کر سکتا ہے۔ بعد کے مراحل ثبوت کو پھانسی میں تبدیل کرتے ہیں۔ یہاں وقفہ جان بوجھ کر کیا گیا ہے۔

1.6: پائپ لائن ایکٹیویشن

یہ چلائیں clearledger ایپ اسٹور نہیں۔ clearledger-infra.

§1.3 بنایا گیا۔ clearledger-infra صرف Kubernetes مینی فیسٹ استعمال کریں۔ یہ وہاں نہیں ہے .github/workflows/ اور کوئی پائپ لائن نہیں ہے۔ اگر آپ کے پاس شیل پرامپٹ پر درج ذیل ہیں: clearledger-infraیا آپ استعمال کرتے ہیں /tmp/clearledger-infraآپ غلط جگہ پر ہیں۔

cd /path/to/clearledger    # the app repo you pushed in §1.1

git remote -v              # must show .../clearledger.git — NOT clearledger-infra

ls .github/workflows/ci.yaml   # must exist before you commit

پائپ لائن فائلیں پہلے سے موجود ہیں: .github/workflows/ci.yaml. چھوٹی تبدیلیوں کو اس پر دبائیں: clearledger کو main:

echo "# Pipeline activated $(date)" >> README.md
git add README.md
git commit -m "ci: activate GitHub Actions pipeline"
git push origin main

اسے یہاں عمل میں دیکھیں: https://github.com/YOUR_USERNAME/clearledger/actions (ایپ اسٹور آپریشنز ٹیب، انفراسٹرکچر اسٹور نہیں)

جب یہ کامیاب ہوجاتی ہے تو پائپ لائن کو اپ ڈیٹ کیا جاتا ہے۔ clearledger-infra آپ کے لیے۔ اس مرحلے پر کسی بھی چیز کو براہ راست انفراسٹرکچر کے ذخیرے میں دھکیلنے کی ضرورت نہیں ہے۔

متوقع آؤٹ پٹ: سب کچھ تقریباً 8 منٹ میں مکمل ہو جائے گا۔

✓ Build + Scan auth-service
✓ Build + Scan ledger-service
✓ Build + Scan notification-service
✓ Build + Scan frontend
✓ Update manifests → GitHub

DAST اور ArgoCD ریفریش کے مراحل درج ذیل دکھائے گئے ہیں: چھوڑ دیا: یہ ایک متوقع رجحان ہے۔ اس کی وجہ یہ ہے کہ دونوں ٹوگلز کو بعد میں سیٹ نہیں کیا جائے گا (§1.4 دیکھیں)۔

میمو: اس لیبارٹری میں شامل ہیں: .gitleaksignore کیونکہ گٹ کی تاریخ میں کچھ جان بوجھ کر ڈیمو راز پہلے سے موجود ہیں۔ Gitleaks اب بھی عام طور پر چلتا ہے. نظر انداز فائل صرف معروف لیب فنگر پرنٹس کو دباتی ہے۔ نئے نتائج شامل نہ کریں جب تک کہ آپ کو یقین نہ ہو کہ یہ جان بوجھ کر ٹیسٹ ڈیٹا ہے۔

ایکشن لاگ پر کلک کریں اور اپنی کہانی تلاش کریں۔ سبز کے باہر آنے کا انتظار نہ کریں۔

• ڈاکر لاگ ان کامیاب

• ہر سروس امیج کو ڈوکر ہب میں بنایا اور آگے بڑھایا گیا۔

• clearledger-infra چیک آؤٹ کیا۔

• تعیناتی YAML کو نئے SHA ٹیگز کے ساتھ اپ ڈیٹ کیا گیا۔

• عہد کو آگے بڑھایا گیا ہے: clearledger-infra

اگر پائپ لائن کامیاب ہوجاتی ہے، کھولیں: https://github.com/YOUR_USERNAME/clearledger-infra اپنے تعیناتی مینی فیسٹ پر ایک نظر ڈالیں۔ تصویری ٹیگز کو اب موجودہ کمٹ SHA استعمال کرنا چاہیے۔

اب اپنے کلسٹر کو چیک کریں۔

kubectl get deployment auth-service -n clearledger 
  -o jsonpath="{.spec.template.spec.containers[0].image}" && echo

پرانی تصاویر اب بھی ظاہر ہو سکتی ہیں۔ اس کی توقع ہے۔ مرحلہ 1 میں سیکھنے کے لیے سب سے اہم چیزیں یہ ہیں:

GitHub pipeline succeeded.
Docker Hub has new images.
clearledger-infra has new image tags.
The Kubernetes cluster did not update automatically.

یہ ناکامی نہیں ہے۔ تقسیم کا فرق ہے۔ مرحلہ 1 میں، ہم نے تعمیر کو خودکار بنایا، لیکن ہمارے پاس ابھی تک انفراسٹرکچر کے ذخیرے کو دیکھنے والا کوئی کنٹرولر نہیں ہے۔ مرحلہ 2 ArgoCD انسٹال کرکے اس خلا کو پورا کرتا ہے۔

1.7 — پریکٹس چیک پوائنٹ: ثابت کریں کہ مرحلہ 1 اصل میں مکمل ہوا تھا۔

صرف گرین ورک فلو بیج پر انحصار نہ کریں۔ ہر ایک ٹیسٹ خود چلائیں۔

1. انفراسٹرکچر اسٹوریج میں ابھی بھی ایپ کے راز موجود ہیں (مرحلہ 2 کے لیے اہم)۔

کھلا https://github.com/YOUR_USERNAME/clearledger-infra/tree/main/manifests/auth-service, secret.yaml اسے ظاہر کرنا چاہیے۔

آپ کے لیپ ٹاپ پر:

git clone --depth 1 https://github.com/YOUR_USERNAME/clearledger-infra.git /tmp/verify-infra
grep secretKeyRef /tmp/verify-infra/manifests/auth-service/deployment.yaml
grep secret.yaml /tmp/verify-infra/manifests/kustomization.yaml
rm -rf /tmp/verify-infra

متوقع: secretKeyRef تعیناتی آؤٹ پٹ سے۔ حسب ضرورت فہرست auth-service/secret.yaml اور ledger-service/secret.yaml. اگر راز غائب ہیں، تو مرحلہ 2 سے پہلے §1.3 مینی فیسٹ کو دوبارہ دبا دیں۔

2. CI کے ذریعے اپ ڈیٹ کردہ تصویری ٹیگز کو حسب ضرورت بنائیں

git clone --depth 1 https://github.com/YOUR_USERNAME/clearledger-infra.git /tmp/verify-infra
grep newTag /tmp/verify-infra/manifests/kustomization.yaml
rm -rf /tmp/verify-infra

متوقع: newTag ایک 40-کردار گٹ SHA (یا کمٹ ہیش)۔ ابھی تک نہیں۔ v0.1.0 صرف: اگر آپ نے §0.3 سے آگے نہیں بڑھایا ہے۔

3. Docker Hub نے اس پائپ لائن کے لیے تصاویر پر دستخط کیے ہیں۔

پھر hub.docker.com کھولیں۔ clearledger-auth-service پھر ٹیگ. تازہ ترین ٹیگ کا مرحلہ 2 سے SHA سے ​​مماثل ہونا چاہیے۔

4. (کوئی کلسٹر تبدیلیاں نہیں (تعیناتی وقفہ) جان بوجھ کر)

kubectl get deployment auth-service -n clearledger 
  -o jsonpath="{.spec.template.spec.containers[0].image}" && echo

متوقع: پھر بھی مرحلہ 0 ٹیگز، جیسے veeno-demo/clearledger-auth-service:v0.1.0)، نیا SHA نہیں۔ اس سے ثابت ہوتا ہے کہ CI نے کلسٹر کو متاثر نہیں کیا۔

5. رنر ابھی تک بیکار ہے۔

GitHub، ترتیبات، کام، لانچر، clearledger-runner, سست.

make check-1

مرحلہ 2 میں داخل ہونے کے لیے پانچوں کو پاس کریں۔

آپ نے مرحلہ 1 میں کیا سیکھا۔

• CI تعمیراتی عمل سے نوٹ بک کو ہٹاتا ہے۔ تعمیرات دہرائی جا سکتی ہیں، دکھائی دیتی ہیں اور گٹ کمٹ کے ساتھ منسلک ہیں۔

• چلانے والے کارکن ہیں، خود پائپ لائن نہیں۔ GitHub کاموں کو شیڈول کرتا ہے اور خود میزبان ایگزیکٹو انہیں VM کے اندر چلاتا ہے۔

• نمونے اور مطلوبہ حالتیں مختلف ہیں۔ Docker Hub اسٹورز نے بنائی ہوئی تصاویر۔ clearledger-infra GitHub ایک Kubernetes مینی فیسٹ اسٹور کرتا ہے جو آپ کو بتاتا ہے کہ کون سی تصویر چلانی ہے۔

• ایک اچھی پائپ لائن خفیہ طور پر کلسٹر کو تبدیل نہیں کرتی ہے۔ یہ پائپ لائن گٹ کو چلانے کے بجائے اپ ڈیٹ کرتی ہے۔ kubectl.

• باقی خلا: بنیادی ڈھانچے کا ذخیرہ بدل گیا ہے، لیکن کلسٹر نہیں بدلا ہے۔ کسی کو ابھی بھی تبدیلیاں دستی طور پر لاگو کرنی ہیں۔ مرحلہ 2 میں، آپ اس مسئلے کو حل کرنے کے لیے GitOps استعمال کریں گے۔

اب آپ اپنے تجربے کی فہرست میں کیا ڈال سکتے ہیں/ایک انٹرویو میں کہہ سکتے ہیں:

ہم نے سیلف ہوسٹڈ GitHub ایکشن رنر پر ایک CI پائپ لائن بنائی ہے جو ہر پش پر کنٹینر امیجز بناتی اور دھکیلتی ہے اور ہمیں نوکریاں پیدا ہونے سے پہلے ناکام ورک فلو کو ڈیبگ کرنے کی اجازت دیتی ہے۔

make snapshot STAGE=1 && make snapshots. چیک کریں clearledger.stage1. دیکھیں کہ اپنی ترقی کو کیسے بچایا جائے۔

مرحلہ 2 – ArgoCD کے ساتھ GitOps

اب سے، گٹ انچارج ہے۔ انفراسٹرکچر سٹوریج پر لکھی گئی ہر چیز پر عمل درآمد ہونا چاہیے۔ جب کوئی دستی طور پر کلسٹر کو تبدیل کرتا ہے، تو ArgoCD فرق محسوس کرتا ہے اور اسے واپس Git سے ملنے کے لیے تبدیل کرتا ہے۔

ہدف: دیکھنے کے لیے ArgoCD انسٹال کریں۔ clearledger-infra اپنی تبدیلیاں اپنے کلسٹر میں لگائیں۔ CI پائپ لائن صرف Git ریپوزٹریوں کو اپ ڈیٹ کرتی ہے اور Kubernetes سے منسلک یا چلتی نہیں ہے۔ kubectl حکم

یہاں ایک زیادہ انٹرایکٹو، گاڑھا ورژن ہے۔

کیا میں مرحلہ 2 کے لیے تیار ہوں؟

جاری رکھنے سے پہلے ختم کریں۔ §1.6چلائیں:

make check-1

grep secretKeyRef infra/manifests/auth-service/deployment.yaml

grep vault.hashicorp infra/manifests/auth-service/deployment.yaml && echo "STOP: Vault annotations present" || echo "OK"

آپ کو درج ذیل کو چیک کرنا چاہئے:

فوری چیک لسٹ:

• clearledger-infra شامل auth-service/secret.yaml اور ledger-service/secret.yaml

• آپ کا خود میزبان رنر سست کے ساتھ clearledger برانڈ

• ENABLE_ARGOCD_SYNC یہ ابھی تک سیٹ اپ نہیں ہوا ہے (آپ اسے ArgoCD انسٹال کرنے کے بعد فعال کر دیں گے)۔

مرحلہ 2 مکمل ہونے کے بعد make check-2 پاس اور http://argocd.local ArgoCD مطابقت پذیری دکھاتا ہے۔ clearledger.

آخر میں، اپنی ترقی کو محفوظ کریں.

make snapshot STAGE=2
make snapshots

اسے چیک کریں۔ clearledger.stage2 یہ سنیپ شاٹ کی فہرست میں ظاہر ہوگا۔

آپ کو پہلے کیا جاننے کی ضرورت ہے۔

مرحلہ 1 سے فرق: CI پہلے سے ہی تصاویر اور اپ ڈیٹس بنا رہا ہے۔ clearledger-infra. جب تک کوئی اسے چلاتا ہے کلسٹر میں کوئی تبدیلی نہیں ہوتی۔ kubectl. یہ قدم آخری مرحلے کو بند کرتا ہے۔

ڈبلیو ایچ او	نوکری
C.I (مرحلہ 1)	تعمیر → اسکین → پش امیج → اپڈیٹ امیج ٹیگ clearledger-infra
آرگو سی ڈی (مرحلہ 2)	دیکھیں clearledger-infra → مینی فیسٹ کا اطلاق کریں → کلسٹر چلائیں جیسا کہ گٹ آپ کو بتاتا ہے۔

push code → CI updates clearledger-infra → ArgoCD syncs cluster

پری سنک چیک لسٹ: پہلے چلائیں۔ argocd app sync

ArgoCD کسی بھی چیز کو اپناتا ہے۔ clearledger-infra. غلط مواد سرخ پھلیوں کا سبب بنتا ہے۔ §1.7 چیک پوائنٹ ٹیبل کو دوبارہ چلائیں تاکہ یہ یقینی بنایا جا سکے کہ GitHub سائیڈ پر موجود مواد اب بھی درست ہے، پھر نوٹ بک کی طرف چیک کریں۔

# Application manifest must point at YOUR infra repo
grep repoURL stages/stage-2-gitops/argocd/clearledger-app.yaml

# Stage 0 workloads still healthy before ArgoCD takes over
kubectl get pods -n clearledger
curl -s -o /dev/null -w "%{http_code}" http://clearledger.local/auth/health

متوقع: repoURL آپ کے GitHub صارف نام، اور تمام ایپ پوڈز پر مشتمل ہے۔ Runningcurl 200. صرف اس صورت میں جب دونوں پاس ہوں آپ کو نیچے ارگو سی ڈی انسٹال کرنے اور مطابقت پذیری کرنے کی ضرورت ہوگی۔

kubectl create namespace argocd 2>/dev/null || true

kubectl apply -n argocd --server-side --force-conflicts -f 
  https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

kubectl wait --for=condition=ready pod 
  -l app.kubernetes.io/name=argocd-server -n argocd --timeout=180s

کیوں --server-side --force-conflicts? Argo CDs اضافی بڑے سائز میں بھیجے جاتے ہیں۔ applicationsets.argoproj.io سی آر ڈی عام طور پر kubectl apply میں تبصروں میں سب کچھ چھپانے کی کوشش کرتا ہوں اور 256KiB کی حد کو مارتا ہوں اور ایک غلطی ہوتی ہے: metadata.annotations: Too long. سرور سائیڈ انفورسمنٹ اسے روکتا ہے۔ اس طرح آرگو سی ڈی آپ سے انسٹال کرنے کی توقع رکھتی ہے۔

اپنا ایڈمنسٹریٹر پاس ورڈ حاصل کریں:

kubectl -n argocd get secret argocd-initial-admin-secret 
  -o jsonpath="{.data.password}" | base64 -d && echo

NGINX استقبالیہ کے لیے Argo CD کنفیگریشن

براؤزر HTTPS کو اندراج سے جوڑتا ہے، اور اندراج سادہ HTTP کو ارگو سی ڈی سرور پر بھیجتا ہے۔ اس کے بغیر، UI اکثر کریش ہو جائے گا۔ 503 یا ERR_TOO_MANY_REDIRECTS ریئل ٹائم اپ ڈیٹ URL (/api/v1/stream/*)۔

kubectl apply -f stages/stage-2-gitops/infra/argocd-cmd-params.yaml

kubectl apply -f stages/stage-2-gitops/infra/argocd-ingress.yaml

kubectl rollout restart deployment/argocd-server -n argocd

kubectl rollout status deployment/argocd-server -n argocd --timeout=180s

سے متوقع argocd-cmd-params-cm: server.insecure: "true", server.grpc.web: "true", server.url: https://argocd.local.

کھلا https://argocd.local. لاگ ان: admin اور اوپر سے پاس ورڈ۔ اگر آپ کا براؤزر خود دستخط شدہ سرٹیفکیٹ وارننگ دکھاتا ہے تو اسے قبول کریں۔

متوقع: درخواست کا صفحہ لوڈ ہو جاتا ہے۔ براؤزر کنسول (F12 کنسول) کو ظاہر نہیں ہونا چاہئے: 401 یا ERR_HTTP2_PROTOCOL_ERROR. اگر UI باقاعدہ ونڈو میں اچھا لگتا ہے، تو آپ کا کام ہو گیا۔ پوشیدگی وضع کی ضرورت نہیں۔

اگر لاگ ان ناکام ہوجاتا ہے۔ 401 Unauthorized (اکثر کنفیگریشن میں تبدیلی یا سابقہ ​​لاگ ان کی خرابی کے بعد) نجی/پوشیدہ ونڈو استعمال کرنے یا سائٹ کا ڈیٹا حذف کرنے کی کوشش کریں۔ argocd.localٹیپ کریں، پھر دوبارہ لاگ ان کریں۔ کیا آپ اب بھی منسلک ہیں؟ Troubleshooting.md دیکھیں۔ آرگو سی ڈی۔

ArgoCD کو اپنے انفراسٹرکچر ریپوزٹری سے جوڑیں اور ایپلیکیشن مینی فیسٹ کو لاگو کریں۔

1. ترمیم کریں۔ stages/stage-2-gitops/argocd/clearledger-app.yaml

سیٹ spec.source.repoURL آپ کا انفراسٹرکچر ذخیرہ (آپ کا GitHub صارف نام نہیں) git config user.name)۔

2. ArgoCD کو اپنے انفراسٹرکچر اسٹوریج سے جوڑیں۔

ArgoCD کو دیکھنے کی اجازت دیں۔ clearledger-infra ایک نئے عہد کے لیے۔ جب بھی تعیناتی مینی فیسٹ میں تبدیلی آتی ہے تو ArgoCD خود بخود آپ کے کلسٹر کو اپ ڈیٹ کرتا ہے۔

# macOS: brew install argocd
argocd login argocd.local --username admin --password YOUR_PASSWORD --insecure --grpc-web

# Public repo
argocd repo add https://github.com/YOUR_USERNAME/clearledger-infra.git --grpc-web

# Private repo — PAT from Stage 1 §1.4 (you saved it as GitHub secret INFRA_REPO_TOKEN)
export INFRA_REPO_TOKEN='ghp_...'   # paste here; GitHub only shows it once at creation
argocd repo add https://github.com/YOUR_USERNAME/clearledger-infra.git 
  --username git --password "$INFRA_REPO_TOKEN" --grpc-web

تصدیق کریں کہ آرگو سی ڈی ریپوزٹری تک پہنچ سکتی ہے۔ (براہ کرم درخواست دینے سے پہلے یہ کریں):

argocd repo list --grpc-web

آپ کی تلاش clearledger-infra URL پر مشتمل ہے: زمرہ git کنکشن کامیاب رہا۔ اگر آپ ناکام نظر آتے ہیں یا ذخیرہ غائب ہے، تو آرگو سی ڈی مطابقت پذیر نہیں ہوسکتی ہے۔ مرحلہ 4 یا GitOps پر انحصار کرنے والے کسی بھی قدم سے پہلے اپنی اسناد میں ترمیم کریں۔

VM کو بحال کرنے یا Argo CD کو دوبارہ انسٹال کرنے کے بعد، آپ کو چلانے کی ضرورت ہو سکتی ہے: argocd repo add ایک بار پھر ( اسناد کلسٹر پر محفوظ ہیں، گٹ پر نہیں)

3. لاگو کریں اور مطابقت پذیری کریں:

kubectl apply -f stages/stage-2-gitops/argocd/clearledger-app.yaml

argocd app sync clearledger --grpc-web

Argo CD UI کو کیسے پڑھیں

مطابقت پذیری کے بعد، کھولیں: لیکوئیڈیٹر ٹری ویو میں ایپلیکیشنز دکھاتا ہے۔ اوپر والے تین بیجز آپ کو سب کچھ بتاتے ہیں۔

ایپ کی حیثیت: ٹھیک ہے۔. Kubernetes کے خیال میں کام کا بوجھ چل رہا ہے۔ پوڈ چل رہا ہے (یا اب بھی شروع ہو رہا ہے اگر یہ کہتا ہے کہ جاری ہے)۔

مطابقت پذیری کی حیثیت: مطابقت پذیر: کلسٹر میچ۔ clearledger-infra دکھایا گیا کمٹ GitHub پر ہے، جیسے main (2c88aa1))۔ گٹ سچائی کا ذریعہ ہے اور آرگو سی ڈی اس کا اطلاق کرتا ہے۔

آخری مطابقت پذیری: کامیابی: Git کی تازہ ترین ایپلیکیشن نے کام کیا۔ اگر یہ ناکام ہوجاتا ہے، تو غلطی پر کلک کریں۔

ذیل میں ریسورس ٹری وہی ایپ ہے جسے ٹکڑوں میں تقسیم کیا گیا ہے: نیم اسپیس، سیکرٹ، سروس، ڈیپلائمنٹ، انگریس وغیرہ۔ گرین چیک مارک = Git کے ذریعے نافذ۔ کسی بھی باکس پر کلک کریں، جیسے deploy/auth-service) پھر زندہ ظاہر بڑا خواہش مند دیکھیں کہ آرگو سی ڈی کے خیال میں اسے کیا کرنا چاہیے۔

ایک فوری "کیا ایپ واقعی کام کر رہی ہے؟” ٹیسٹ (آرگو سی ڈی سے بیرونی):

curl -s -o /dev/null -w "%{http_code}n" http://clearledger.local/auth/health

200 = ایپ اینڈ ٹو اینڈ کنیکٹیویٹی کے ساتھ ساتھ "آرگو سی ڈی پر سبز” کے قابل ہے۔

اگر آپ کو پریشانی ہو رہی ہے: اچھی صحت گر گیا یا جاری ہے۔ ایک طویل عرصے سے SYNC مطابقت پذیر نہیں ہے۔درخت میں وسائل بدل جاتے ہیں۔ سرخ. وسائل پر کلک کریں اور پھر واقعہ یا لاگ. ٹرمینل میں اسے دوبارہ دیکھنے کے لیے kubectl ذیل میں چیک کرتا ہے:

یقینی بنائیں کہ ArgoCD تمام کام کے بوجھ کو دیکھ رہا ہے، نہ کہ صرف داخل ہونا۔

argocd app resources clearledger --grpc-web | grep Deployment

پاس آؤٹ پٹ کے برابر ہے۔

apps    Deployment    clearledger    auth-service            No
apps    Deployment    clearledger    frontend                No
apps    Deployment    clearledger    ledger-service          No
apps    Deployment    clearledger    notification-service  No
apps    Deployment    clearledger    redis                   No

یہ کمانڈ اس تقسیم کو ظاہر کرتی ہے جس کا انتظام ArgoCD ClearLedger کے لیے کرتا ہے۔ آپ کو دیکھنا چاہئے auth-service, ledger-service, notification-service, frontendاور redis. اس کا مطلب ہے کہ ArgoCD پورا مواد پڑھتا ہے۔ kustomization.yaml سے clearledger-infra/manifestsیہ صرف ایک فائل نہیں ہے۔

آخری کالم ہے۔ ORPHANED. No شب بخیر اس کا مطلب ہے کہ ArgoCD جانتا ہے کہ یہ وسیلہ ClearLedger ایپ سے تعلق رکھتا ہے۔ آپ کو صرف اس صورت میں فکر کرنے کی ضرورت ہے جب آپ اپنی تقسیم میں سے ایک غائب کر رہے ہیں یا ArgoCD دیکھیں۔ OutOfSync, Degradedیا UI میں ایک سرخ وسیلہ۔

لیب چیک پوائنٹ: پہلے مطابقت پذیری ٹھیک ہے۔

درج ذیل چار ٹیسٹ چلائیں: پاس درج ذیل ہیں:

kubectl get pods -n clearledger
# Every app pod 1/1 Running (postgres/redis may show older RESTARTS from VM reboots — OK)

kubectl get application clearledger -n argocd 
  -o jsonpath="sync={.status.sync.status} health={.status.health.status}{"n"}"
# sync=Synced health=Healthy

curl -s -o /dev/null -w "%{http_code}n" http://clearledger.local/auth/health
# 200

kubectl logs -n clearledger deploy/auth-service --tail=5 2>/dev/null | head -3
# Lines like: GET /health HTTP/1.1" 200 OK
# Bad sign: DATABASE_URL is not set

اگر چاروں پاس ہو جاتے ہیں، تو مرحلہ 2 کی پہلی ہم آہنگی مکمل ہو جاتی ہے۔ پھر، CI اور ArgoCD ہینڈ آف کو فعال کرنے کے لیے نیچے جاری رکھیں make check-2 اور make snapshot STAGE=2.

ArgoCD ہینڈ آف کے ساتھ CI کو کیسے فعال کیا جائے۔

فیز 1 میں، پائپ لائن کو اپ ڈیٹ کیا گیا تھا۔ clearledger-infraتاہم، کلسٹر کو اپ ڈیٹ نہیں کیا گیا تھا۔ یہ جان بوجھ کر تھا۔

اب جب کہ ArgoCD انسٹال ہو گیا ہے، پائپ لائن ہر کامیاب رن کے بعد ArgoCD کو تبدیلیوں کی جانچ کرنے کی ہدایت کر سکتی ہے۔

GitHub پر clearledger ریپوزٹری کو کھولیں اور Settings, Secrets & Variables, Actions, Variables, New Repository Variable پر جائیں۔

شامل کریں:

نام	قدر
ENABLE_ARGOCD_SYNC	true

اب سے، گرین پائپ لائن دو چیزیں کرے گی:

1. اپ ڈیٹ clearledger-infra نئے امیج ٹیگ کے ساتھ

2. کلسٹر کو سنکرونائز کرنے کے لیے ArgoCD سے درخواست کریں۔

اگر آپ کی پائپ لائن فوری طور پر ArgoCD کو متحرک نہیں کرسکتی ہے، تو یہ عام طور پر ٹھیک ہے۔ ArgoCD چیک کریں۔ clearledger-infra یہ ہر چند منٹوں میں خود ہی چلتا ہے، لہذا آپ کو ابھی بھی نئی Git تبدیلیاں لاگو کرنے کی ضرورت ہے۔

چھوڑ دو ENABLE_DAST یہ ابھی سیٹ اپ نہیں ہے۔ ایپ کے مستحکم ہونے کے بعد، اسے مرحلہ 3 میں فعال کریں۔ clearledger.local.

اگر آپ Argocd UI میں سرخ پوڈز یا "ترقی میں” دیکھتے ہیں (اسکرین شاٹ سے پہلے پڑھیں)

یہ ٹوٹی ہوئی تنصیب نہیں ہے، یہ صرف ایک عام پہلی مطابقت پذیری کا سرپرائز ہے۔

یہ مرحلہ 2 میں کیوں ہوتا ہے؟

ArgoCD ہر چیز کو اندر سے ہم آہنگ کرتا ہے۔ clearledger-infra. تعیناتی کے لیے آپ کو استعمال کرنا چاہیے: secretKeyRef (مرحلہ 2-4)، والٹ انجیکشن نہیں۔ اگر انفراسٹرکچر اسٹور میں پرانی لیب کاپی سے والٹ تشریحات ہوں تو توثیق/لیجر میں تضاد ہے۔ DATABASE_URL is not set لیول 5 تک۔

نیٹ ورک کی پالیسیاں لیول 6 سے تعلق رکھتی ہیں۔ بنیادی طور پر clearledger ریپو، وہ رہتے ہیں infra/deferred-by-stage/stage-6-runtime-security/netpol/نہیں infra/manifests/. نقل نہ کریں۔ clearledger-infra مرحلہ 2 کے دوران۔

اگر manifests/netpol/ یہ اب بھی تمہارے اندر ہے۔ clearledger-infra GitHub (پرانی لیب کاپی) پر ریپو میں، ArgoCD اسے نافذ کرنا جاری رکھے ہوئے ہے۔ پالیسی ہے۔ پہلے سے طے شدہ انکار اگر آپ نئے پوڈ کے لیے DNS توڑتے ہیں تو آپ کو سرخ رنگ نظر آئے گا۔ 0/1 پھلیوں کے ساتھ جاری ہے۔ صحت

مرحلہ 2 درست کریں۔

کرو دونوں قدم صرف کلسٹر سے حذف کرنا کافی نہیں ہے۔ اگلی مطابقت پذیری پر ArgoCD Git سے پالیسی کو دوبارہ تخلیق کرتا ہے۔

مرحلہ 1: سے ہٹا دیں۔ clearledger-infra GitHub پر

فولڈر کو حذف کریں۔ manifests/netpol/ اور عہد کریں: chore: defer network policies to Stage 6.

مرحلہ 2: مطابقت پذیری اور دوبارہ شروع کریں۔

argocd app sync clearledger --grpc-web
kubectl delete networkpolicy -n clearledger --all   # safe once Git no longer has netpol
kubectl rollout restart deployment/auth-service deployment/ledger-service -n clearledger
argocd app get clearledger --grpc-web | grep -E "Sync Status|Health Status"

نیٹ ورک کی پالیسیاں وہی رہیں۔ clearledger نیچے infra/deferred-by-stage/ جب تک کہ آپ اسے مرحلہ 6 میں لاگو نہ کریں۔

اگر کوئی مسئلہ نہیں ہے تو نیچے جاری رکھیں۔

ایک بار جب ArgoCD کی مطابقت پذیری ختم ہو جائے تو، کھولیں: clearledger ArgoCD UI سے ایپ۔ آپ کو سبز رنگ دیکھنا چاہئے۔ Healthy اور Synced بیج آپ کی ایپ کی طرف اشارہ کرنا چاہیے: clearledger-infra ذخیرہ، استعمال manifests راستے کی وضاحت کریں clearledger نام کی جگہ۔

پھر ایپ ٹائل کھولیں۔ وسائل کے درخت کو کسی بھی سرخ وسائل کے بغیر تعیناتی، سروس، اور داخل ہونا چاہئے.

آپ اسے ٹرمینل میں بھی چیک کر سکتے ہیں۔

argocd app get clearledger --grpc-web

اسے تلاش کریں۔ Sync Status: Synced اور Health Status: Healthy.

ArgoCD OutOfSync پھنس گیا۔

عام راستہ: CI پورے مینی فیسٹ کو کاپی کرتا ہے، Kustomize ٹیگز کو اپ ڈیٹ کرتا ہے، اور ArgoCD خود بخود 3 منٹ تک مطابقت پذیر ہوجاتا ہے۔

اگر OutOfSync 10 منٹ سے زیادہ کے بعد بھی ہوتا ہے:

make fix-argocd

اس کے بعد کینونیکل مینی فیسٹ کو دوبارہ اس طرح ہم آہنگ کیا جائے گا: clearledger-infra (کسٹمائز SHA تحفظ) ایپلیکیشن کو دوبارہ لاگو کرتا ہے اور جبری ریفریش کو متحرک کرتا ہے۔ نہیں کرتے kubectl apply تعیناتی: Git میں ترمیم کریں اور ArgoCD کو مطابقت پذیر بنائیں۔

kubectl annotate application clearledger -n argocd 

argocd.argoproj.io/refresh=hard --overwrite

argocd app sync clearledger --grpc-web --prune

kubectl get application clearledger -n argocd -o jsonpath="sync={.status.sync.status} health={.status.health.status}{"n"}"

اس منظر کا اسکرین شاٹ لیں۔: ایپ ٹائلز یا ریسورس ٹری ٹھیک ہیں۔ یہ پورٹ فولیو ثبوت ہے کہ GitOps ایکشن میں ہے۔

ArgoCD خود شفا یابی ثابت

اب ثابت کریں کہ گٹ سچائی کا سرچشمہ ہے۔

اس ڈیمو میں، ہم براہ راست چلتے ہوئے کلسٹر میں تبدیلیاں کرتے ہیں۔ آپ کریں گے ~ نہیں گٹ کو تبدیل کریں۔ ArgoCD کو اس بات کا تعین کرنا چاہئے کہ کلسٹرز اب مماثل نہیں ہیں۔ clearledger-infraمنتخب کریں، پھر دوبارہ تبدیل کریں۔

شروع کرنے سے پہلے، یقینی بنائیں کہ آپ کی ایپ صحت مند ہے اور ArgoCD تعیناتی کا انتظام کر رہا ہے۔

argocd app resources clearledger --grpc-web | grep Deployment

اپنے کلسٹر پر تصدیقی خدمت کی تصویر کو دستی طور پر تبدیل کریں۔

# Manually change the image in the cluster only (Git stays the same)
kubectl set image deployment/auth-service 
  auth-service=$DOCKER_USERNAME/clearledger-auth-service:fake-tag 
  -n clearledger

ArgoCD چیک کریں:

# ArgoCD should flip to OutOfSync within a minute or two
argocd app get clearledger --grpc-web | grep -E "Sync Status|Health Status"

کلسٹر میں ترمیم کرنے کے لیے ArgoCD کا انتظار کریں۔ جعلی تصویری ٹیگز مختصر امیج امپورٹ کی خرابیوں کا سبب بن سکتے ہیں۔ اس ڈیمو میں اس کی توقع ہے۔

# Wait for selfHeal (default sync interval is ~3 minutes)
sleep 180

تصدیق کریں کہ تصویر کو واپس گٹ ورژن میں تبدیل کر دیا گیا ہے۔

# Cluster image should match clearledger-infra again — Git was never edited
kubectl get deployment auth-service -n clearledger 
  -o jsonpath="{.spec.template.spec.containers[0].image}"

اگر تصویر دوبارہ تبدیل ہوتی ہے تو، ArgoCD خود شفا یابی نے کام کیا ہے۔ میں نے کلسٹر کو دستی طور پر تبدیل کیا، لیکن ArgoCD نے اسے میچ میں بحال کیا۔ clearledger-infra.

یہ GitOps ہے۔ Git آپ کو بتاتا ہے کہ کیا چلنا ہے، اور ArgoCD ایک کلسٹر کو برقرار رکھتا ہے جو Git سے ملتا ہے۔

make check-2

خراب تعیناتی کو کیسے روکا جائے۔

ہم نے ابھی یہ ظاہر کیا ہے کہ ArgoCD غیر مجاز کلسٹر تبدیلیوں کو واپس کرتا ہے۔ اب اسے پلٹائیں: کیا ہوگا اگر آپ نے اپنے آپ کو برا کام کرنے پر زور دیا؟ GitOps رول بیک بٹن نہیں ہے۔ یہ ایک Git آپریشن ہے۔ یہ سیکشن وضاحت کرتا ہے کہ کیوں، آپ کو دونوں طریقے دکھاتا ہے، اور آپ کو دباؤ محسوس کرنے سے پہلے ہر ایک پر عمل کرنے دیتا ہے۔

میں کیسے جان سکتا ہوں کہ رول بیک کی ضرورت ہے؟

یہ علامات دھکا لگانے کے چند منٹوں میں ظاہر ہوتی ہیں۔ clearledger-infra یہ غلط عہد کی نشاندہی کرتا ہے۔

• پوڈ پھنس گیا ہے۔ CrashLoopBackOff یا Error. اسے چیک کریں kubectl get pods -n clearledger.

• kubectl logs -n clearledger --previous آپ کو اسٹارٹ اپ کی خرابیاں نظر آئیں گی جو پہلے نہیں تھیں۔

• ArgoCD صحت اس میں پلٹ جاتی ہے: Healthy کو Degraded یا خاموش رہو Progressing. اسے چیک کریں argocd app get clearledger --grpc-web.

• ایپ 5xx کی غلطی لوٹاتی ہے یا لاگ ان کام کرنا بند کر دیتا ہے۔ اسے چیک کریں curl -I http://clearledger.local/health.

اگر یہ ایک دھکے کے فوراً بعد ہوتا ہے تو پہلے رول بیک کریں۔ ایک بار ایپ کے دوبارہ مستحکم ہونے کے بعد، خراب کمٹ کی چھان بین کریں۔

کیوں ArgoCD رول بیک صرف ایک بٹن نہیں ہے۔

ArgoCD میں UI میں ایک رول بیک بٹن ہے اور argocd app rollback حکم دونوں کام کرتے ہیں۔ لیکن آپ selfHeal.

آپ کی درخواست (stages/stage-2-gitops/argocd/clearledger-app.yaml) کی تشکیل اس طرح کی گئی ہے:

syncPolicy:
  automated:
    selfHeal: true

ArgoCD آپ کے کلسٹر کو Git کے ساتھ مطابقت رکھتا ہے۔ اس لیب میں، Git کا مطلب ہے: clearledger-infra.

اگر کوئی آپ کے کلسٹر کو دستی طور پر تبدیل کرتا ہے، تو ArgoCD اسے ایک بڑھے ہوئے سمجھے گا اور اسے واپس Git سے ملنے کے لیے تبدیل کرے گا۔

یہ رول بیکس کو بھی متاثر کرتا ہے۔ ArgoCD UI رول بیک کلسٹر کو تبدیل کرتا ہے لیکن Git کو نہیں۔ اگر clearledger-infra یہ اب بھی غلط ورژن کی طرف اشارہ کرتا ہے اور خود علاج آپ کو غلط ورژن پر واپس لا سکتا ہے۔

ایک محفوظ GitOps رول بیک یہ ہے کہ Git کو اس میں تبدیل کیا جائے: git revert کو clearledger-infra. ArgoCD پھر کلسٹر کو اچھے ورژن میں ہم آہنگ کرتا ہے۔

اگر آپ کو ہنگامی UI رول بیک کی ضرورت ہے تو پہلے آٹو سنک کو بند کریں، ArgoCD سے رول بیک کریں، اور پھر بعد میں Git کو ٹھیک کریں۔

طریقہ 1: Git Revert (ترجیحی، ہمیشہ یہ طریقہ پہلے آزمائیں)

یہ GitOps طریقہ ہے۔ کلسٹر کو مت چھونا۔ جب آپ Git میں تبدیلیاں کرتے ہیں تو ArgoCD آپ کی ترمیم کو ہم آہنگ کرتا ہے۔

کب استعمال کریں: صرف چند منٹ لینے سے آپ کو برے کاموں کی شناخت میں مدد مل سکتی ہے۔ clearledger-infra.

یہ کیسے کام کرتا ہے:

Bad commit pushed to clearledger-infra
        ↓
ArgoCD auto-synced it (cluster is now broken)
        ↓
You run: git revert  && git push
        ↓
ArgoCD auto-syncs the revert (cluster is fixed, selfHeal works with you)
        ↓
Git history shows the bad deploy AND the revert, full audit trail

مرحلہ وار:

# 1. Go to your clearledger-infra repo (wherever you cloned it)
cd ~/clearledger-infra  # adjust path if you cloned elsewhere
git pull                # make sure you are up to date

# 2. Find the bad commit
git log --oneline -10

# Output looks like:
# abc1234 update ledger-service image to v1.4.0   ← this broke prod
# def5678 update auth-service image to v1.3.1     ← was fine
# 9a1b2c3 add vault rotation cronjob

# 3. Revert it — this creates a NEW commit, it does not delete history
git revert abc1234 --no-edit

# 4. Push — ArgoCD picks it up automatically within ~3 minutes
git push

# 5. Confirm the cluster recovered
kubectl get pods -n clearledger
argocd app get clearledger --grpc-web | grep -E "Sync Status|Health Status"
# Expected: Sync Status: Synced, Health Status: Healthy

اس طریقہ کو ترجیح دی جاتی ہے کیونکہ یہ سچائی کے ماخذ کو ٹھیک کرتا ہے۔ clearledger-infra.

جب آپ ریورٹ کو دبائیں گے، تو ArgoCD نئی گٹ حالت کو چیک کرے گا اور آپ کے کلسٹر کو اس سے ہم آہنگ کرے گا۔ یہ کوئی مسئلہ نہیں ہے کیونکہ گٹ اور کلسٹر کا مماثل ہونا ضروری ہے۔

اس نے ایک واضح تاریخ بھی چھوڑی ہے۔ گٹ آپ کو غلط تعیناتی، واپسی، دونوں تبدیلیاں کس نے کیں، اور وہ کب کی گئیں۔ ڈیبگ کرنا آسان، جائزہ لینا آسان اور تعمیل کے لیے بہتر ہے۔

طریقہ 2: ایمرجنسی ArgoCD رول بیک (اگر کلسٹر میں آگ لگ جائے)

یہ طریقہ استعمال کریں اگر آپ کا کلسٹر ابھی ٹوٹ گیا ہے اور آپ کے پاس گٹ فکسز کو آگے بڑھانے کا وقت نہیں ہے۔ فوری طور پر کلسٹر کو پہلے سے معلوم اچھی تعیناتی پر لنگر انداز کرتا ہے۔ آپ بعد میں Git میں ترمیم کریں گے۔ یہ کوئی مستقل حل نہیں ہے۔

کب استعمال کریں: مقدمہ چل رہا ہے۔ ایک پوڈ کریش ہو جاتا ہے، صارفین متاثر ہوتے ہیں، اور کلسٹر کو 30 سیکنڈ کے اندر اچھی حالت میں واپس جانا چاہیے۔

شروع کرنے سے پہلے: چیک کریں کہ آیا آپ کا ArgoCD CLI سیشن اب بھی درست ہے۔ اگر اس کی میعاد ختم ہو گئی ہے، تو براہ کرم پہلے دوبارہ لاگ ان کریں۔ ایک میعاد ختم ہونے والا سیشن خود بخود نیچے دیے گئے تمام کمانڈز کو ناکام بنا دے گا۔

argocd account get-user-info --grpc-web
# If you see "Unauthenticated", re-login:
ARGOCD_PASSWORD=$(kubectl -n argocd get secret argocd-initial-admin-secret 
  -o jsonpath="{.data.password}" | base64 -d)

argocd login argocd.local --username admin --password "$ARGOCD_PASSWORD" 
  --insecure --grpc-web

مرحلہ 1: خودکار مطابقت پذیری کو غیر فعال کریں۔ (تنقیدی) اگر آپ اس قدم کو چھوڑ دیتے ہیں، تو SelfHeal 3 منٹ کے اندر رول بیک کو منسوخ کر دے گا۔

argocd app set clearledger --sync-policy none --grpc-web
# Confirm: automated sync is now off
argocd app get clearledger --grpc-web | grep "Sync Policy"
# Expected: Sync Policy: 

مرحلہ 2: آخری معلوم اچھی تعیناتی ID تلاش کریں۔

argocd app history clearledger --grpc-web

# Output looks like:
# ID   DATE                           REVISION
# 9    2026-06-05 10:12:00 +0000 UTC  abc1234  ← bad deploy (current)
# 8    2026-06-04 14:46:06 +0000 UTC  def5678  ← known good
# 7    2026-06-01 20:53:19 +0000 UTC  9a1b2c3

# Or check via kubectl (no argocd CLI needed):
kubectl get application clearledger -n argocd 
  -o jsonpath="{range .status.history[*]}{.id}{"t"}{.deployedAt}{"t"}{.revision}{"n"}{end}"

ID (بائیں طرف کا نمبر) استعمال کریں، SHA کا نہیں۔

مرحلہ 3: ایک اچھی ID پر واپس جائیں۔

argocd app rollback clearledger 8 --grpc-web

مرحلہ 4: تصدیق کریں کہ آپ کا کلسٹر مستحکم ہے۔

kubectl get pods -n clearledger
# All pods should be Running

argocd app get clearledger --grpc-web | grep -E "Sync Status|Health Status"
# Sync Status:   OutOfSync  ← expected — cluster is at rev 8, Git is still at the bad HEAD
# Health Status: Healthy    ← this is what matters right now

OutOfSync اس وقت، یہ درست اور متوقع ہے۔ کلسٹر ایک پچھلا، اچھا ورژن چلا رہا ہے۔ گٹ میں اب بھی بری کمٹمنٹ ہیں۔ ہم بعد میں اس مسئلے کو ٹھیک کریں گے۔

مرحلہ 5: گٹ کو درست کریں (اسے ٹوٹا نہ چھوڑیں)

cd ~/clearledger-infra
git pull
git revert  --no-edit
git push

مرحلہ 6: خودکار مطابقت پذیری کو دوبارہ فعال کریں۔

argocd app set clearledger 
  --sync-policy automated 
  --self-heal 
  --auto-prune 
  --grpc-web

# Trigger an immediate sync so you do not wait for the next auto-check
argocd app sync clearledger --grpc-web

# Confirm everything is clean
argocd app get clearledger --grpc-web | grep -E "Sync Status|Health Status"
# Expected: Sync Status: Synced, Health Status: Healthy

خودکار مطابقت پذیری کو واقعے سے زیادہ دیر تک غیر فعال نہ چھوڑیں۔ یہ بہاؤ کا پتہ لگانے اور چھیڑ چھاڑ کرنے کا طریقہ کار ہے۔ اس کے بغیر آپ کو منظور نہیں کیا جائے گا۔ kubectl کسی تبدیلی کا پتہ نہیں چلا۔ جب آپ Git ترمیم کو آگے بڑھاتے ہیں تو اسے دوبارہ فعال کریں۔

ابھی اپنے رول بیک کی مشق کریں (اس سے پہلے کہ آپ دباؤ محسوس کریں)

اس وقت تک انتظار نہ کریں جب تک کہ اصل واقعہ پہلی بار نہیں چلتا۔ نیچے دیے گئے اقدامات غلط تصویری ٹیگ کی تعیناتی کی تقلید کرتے ہیں اور طریقہ 1 (پہلے سے طے شدہ راستہ) کے ذریعے آپ کی رہنمائی کرتے ہیں۔

مرحلہ 1: غلط امیج ٹیگ کو دھکیلیں۔ clearledger-infra

cd ~/clearledger-infra
git pull

# Edit manifests/notification-service/deployment.yaml
# Change the image tag to a tag that does not exist, e.g.:
#   image: docker.io/$DOCKER_USERNAME/clearledger-notification-service:broken-tag

# Commit and push it
git add manifests/notification-service/deployment.yaml
git commit -m "test: simulate bad deploy with nonexistent image tag"
git push

مرحلہ 2: چیک کریں کہ آیا ArgoCD غلط حالت میں مطابقت پذیر ہے۔

# Give ArgoCD ~3 minutes to pick it up, or trigger immediately:
argocd app sync clearledger --grpc-web

# Watch the notification-service pod fail
kubectl get pods -n clearledger -w
# You will see: notification-service pod stuck in ImagePullBackOff or ErrImagePull

مرحلہ 3: طریقہ 1 کا استعمال کرتے ہوئے واپس رول کریں۔

cd ~/clearledger-infra

# Revert the bad commit
git revert HEAD --no-edit
git push

# ArgoCD will auto-sync — or trigger it:
argocd app sync clearledger --grpc-web

# Watch pods recover
kubectl get pods -n clearledger -w
# notification-service should return to Running

مرحلہ 4: تصدیق کریں۔

argocd app get clearledger --grpc-web | grep -E "Sync Status|Health Status"
# Expected: Sync Status: Synced, Health Status: Healthy

kubectl get pods -n clearledger
# All pods Running, no ImagePullBackOff

اب آپ نے اینڈ ٹو اینڈ رول بیک کی مشق کر لی ہے۔ کہ git revert آپ کے بنیادی ڈھانچے کے ذخیرے کی تاریخ میں کمٹ مستقل طور پر شامل ہیں۔ یعنی، نقلی وصولی کا ایک حقیقی آڈٹ ٹریل۔

فوری حوالہ

طریقہ 1 استعمال کریں (گٹ ریورٹ) اگر:

• ایک غلط تصویری ٹیگ یا مینی فیسٹ کو دھکیل دیا گیا تھا۔ clearledger-infra اور چند منٹ باقی ہیں۔

• بنیادی ڈھانچے کی دکان میں ترتیب میں تبدیلی کی وجہ سے پوڈ کو ختم کر دیا گیا تھا۔

• یہ تقریباً ہمیشہ صحیح جواب ہوتا ہے۔ یہ تیز، محفوظ ہے، اور ایک صاف آڈٹ ٹریل چھوڑتا ہے۔

طریقہ 2 استعمال کریں (ایمرجنسی آرگو سی ڈی رول بیک) اگر:

• کلسٹر فی الحال ڈاؤن ہے، صارفین کو متاثر کر رہا ہے، اور 30 ​​سیکنڈ کے اندر مستحکم ہونا چاہیے۔

• مجھے ابھی تک یقین نہیں ہے کہ کس کمٹ کی وجہ سے مسئلہ ہوا اور مجھے تحقیقات کے لیے کچھ وقت درکار ہے۔ استعمال کرنے سے پہلے مستحکم ہونے کے لیے واپس رول کریں۔ git log مجرم کو تلاش کرنے کے لیے، مسئلہ حل کرنے کے لیے طریقہ 1 استعمال کریں۔

کوئی بھی طریقہ لاگو نہیں ہوتا ہے۔ ایک پوڈ کریش ہو جاتا ہے، لیکن حال ہی میں انفراسٹرکچر اسٹور پر کچھ بھی نہیں دھکیلا گیا ہے۔ یہ رول بیک مسئلہ نہیں ہے۔ چیک کریں kubectl logsاس کی بجائے والٹ کنکشن اور نیٹ ورک کی پالیسیاں لاگو ہوتی ہیں۔

revisionHistoryLimit: 10 کو stages/stage-2-gitops/argocd/clearledger-app.yaml اس کا مطلب ہے کہ ArgoCD کے پاس ہمیشہ ہنگامی رول بیکس کے لیے 10 پچھلی تقسیمیں دستیاب ہوتی ہیں۔ اگر آپ کی رہائی کا چکر زیادہ ہے تو اسے بڑھائیں۔

آپ نے مرحلہ 2 میں کیا سیکھا۔

• GitOps کا کیا مطلب ہے: Git سچائی کا واحد ذریعہ ہے اور ٹولز اسے نافذ کرتے ہیں۔

• ArgoCD خصوصیات: گٹ کا مشاہدہ کریں اور اس کا اپنے کلسٹر سے موازنہ کرکے خود بخود بڑھے ہوئے کو درست کریں۔

• اب پورا بہاؤ اس طرح کام کرتا ہے: پش کوڈ، سی آئی بلڈ امیج، سی آئی اپ ڈیٹ انفراسٹرکچر ریپوزٹری، اور آرگو سی ڈی سنک کلسٹر۔

• کوئی نہیں چل رہا ہے kubectl یہ اب تقسیم کے لیے دستیاب نہیں ہے۔ پائپ لائن Git کو اپ ڈیٹ کرتی ہے اور ArgoCD باقی کام کرتی ہے۔

• محفوظ طریقے سے واپس جانے کا طریقہ: git revert انفرا ریپو جواب ہے اور ArgoCD ایمرجنسی رول بیک بریک گلاس آپشن ہے۔ پہلے آپ کو خودکار مطابقت پذیری کو غیر فعال کرنے کی ضرورت ہے۔ بصورت دیگر سیلف ہیل خود بخود مطابقت پذیری کو منسوخ کردے گا۔

اب آپ اپنے تجربے کی فہرست میں کیا ڈال سکتے ہیں/ایک انٹرویو میں کہہ سکتے ہیں:

GitOps کو ArgoCD کے ساتھ لاگو کیا گیا تاکہ یہ یقینی بنایا جا سکے کہ کلسٹر سٹیٹ Git کے ذریعے ڈرفٹ ڈیٹیکشن، آٹومیٹک سنکرونائزیشن، اور غلط تعیناتیوں کے Git پر مبنی رول بیک کے ساتھ چلتی ہے۔

make snapshot STAGE=2 && make snapshots. چیک کریں clearledger.stage2. دیکھیں کہ اپنی ترقی کو کیسے بچایا جائے۔

مرحلہ 3 – سیکیورٹی گیٹ

ہر دھکا سیکیورٹی چیک چلاتا ہے۔ کچھ خرابیاں پائپ لائن کو فوری طور پر روک دیتی ہیں۔ دوسروں کو ابھی سیکھا جائے گا اور بعد میں کلسٹر پر لاگو کیا جائے گا (مرحلہ 4)۔

ہدف: 6 اسکینرز کو سمجھیں۔ ہر اسکینر سمجھتا ہے کہ وہ کیا دیکھتا ہے، کیا پکڑتا ہے، اور غلطیوں کو کیسے پڑھنا ہے۔ چونکہ ہر گیٹ کو جان بوجھ کر توڑا جا سکتا ہے (§3.4)، ایک ناکام CI آپریشن حیران کن نہیں ہے۔

کیا آپ مرحلہ 3 شروع کرنے کے لیے تیار ہیں؟

• make check-2 پاس

• ENABLE_ARGOCD_SYNC=true GitHub پر (مرحلہ 2 میں سیٹ اپ)

• ENABLE_DAST ابھی تک مقرر نہیں (اگر آپ چاہیں تو اس مرحلے میں بعد میں اسے آن کریں)

• آرگو سی ڈی http://argocd.local دکھائیں مطابقت پذیر

• اختیاری: مرحلہ 1 اپنی حفاظتی کرنسی کو براؤز کریں۔ فیز 1 میں، ہم پہلے ہی ان میں سے بہت سے ٹولز کو لاگو کر چکے ہیں۔

مکمل ہونے پر: make check-3 ہر گیٹ کو ایک بار پاس کیا اور ٹرگر کیا (§3.4)۔ پھر make snapshot STAGE=3 اور make snapshots.

آپ کو پہلے کیا جاننے کی ضرورت ہے۔

ایک ٹول کافی نہیں ہے۔ ہر اسکینر ایک مختلف پرت کی حفاظت کرتا ہے۔

• گٹلیکس: کوڈ یا گٹ ریکارڈ کا راز (API کلید، ٹوکن)

• Semgrep (SAST): Python/JS سورس میں کیڑے (انجیکشن، غیر محفوظ پیٹرن)

• Trivy (SCA + تصویر): Python/Node.js پیکجز اور Docker امیجز میں معلوم سیکیورٹی کمزوریاں (جسے CVEs کہا جاتا ہے) تلاش کریں۔ Common Vulnerability and Exposures (CVE) سافٹ ویئر سیکیورٹی کی خامیاں ہیں جن کو عوامی طور پر ایک منفرد شناخت کنندہ کے ذریعے ٹریک کیا جاتا ہے۔

• چیک کریں (IaC): Dockerfile، Kubernetes manifest، اور Stage 8 Terraform کی غلط کنفیگریشن۔

• مشترکہ نشان: ثابت کرتا ہے کہ تصویر پائپ لائن کے ذریعے بنائی گئی تھی اور اس پر دستخط کیے گئے تھے۔

آج CI کو کیا روکتا ہے: راز، خراب کوڈ (SAST)، کمزور تصاویر، پروڈکشن امیجز میں ڈاکر فائل کے مسائل۔

بعد میں انتظار کرنا: Kubernetes کے کچھ مسائل صرف مرحلہ 1 میں رپورٹ کیے گئے ہیں۔ یہ ظاہر کرتا ہے کہ کس چیز کو مضبوط کرنے کی ضرورت ہے۔ مرحلہ 4 میں، Kyverno اہم اصولوں کا اصل کلسٹر نفاذ میں ترجمہ کرتا ہے، لہذا غیر محفوظ کام کے بوجھ کو چلنے سے پہلے ہی روک دیا جاتا ہے۔

آپ git commitنوٹ بک کا ہک پہلے اسکین کر سکتا ہے (کمٹ کرنے سے پہلے)۔ آپ git pushGitHub ایکشن لانچر سے دوبارہ اسکین کرتا ہے۔ ایک ہی خیال دو بار ظاہر ہوتا ہے۔ آپ کی 10 منٹ کی پائپ لائن کو ضائع کرنے سے پہلے غلطیوں کو پکڑیں۔ CI ہمیشہ کسی بھی طرح سے پش پر چلتا ہے، لہذا انسٹالیشن کے لیے precommit اختیاری ہے۔

DAST کو فعال کریں (مرحلہ 2 کے بعد اختیاری)

ڈائنامک ایپلیکیشن سیکیورٹی ٹیسٹنگ (DAST) ہے۔ چل رہا ہے ایپ http://clearledger.local. فیز 1 اور 2 کو جان بوجھ کر بند کر دیا گیا تھا۔ مرحلہ 1 کلسٹر میں تعینات نہیں کیا گیا تھا، مرحلہ 2 پہلے GitOps کو معمول پر لانا تھا۔

اگر make check-2 پاس اور curl http://clearledger.local/auth/health رپورٹ 200آپ DAST کو آن کر سکتے ہیں۔

GitHub پر جائیں۔ clearledger ریپو پھر ترتیبات، راز اور متغیرات، اعمال، متغیراتاور نیا ذخیرہ متغیر:

نام	قدر
ENABLE_DAST	true

ایک چھوٹی کمٹ کو دبائیں یا اپنے آخری ورک فلو کو دوبارہ چلائیں۔ main)۔ کہ DAST (OWASP ZAP + Fintech API ٹیسٹ) اس کے بجائے، آپ کو کام چلانے کی ضرورت ہے۔ چھوڑ دیا. ایک ناکام ZAP اسکین ایک ایسی تلاش ہے جس کی واقعی تحقیقات کی ضرورت ہے۔ اس قدم سے پہلے کسی بھی چیز کو چھوڑنے کا مطلب ہے ٹوگل آف ہے۔

3.1: پری کمٹ ہک انسٹال کرنا

# macOS (Homebrew — avoids PEP 668 "externally-managed-environment" from pip3):
brew install pre-commit

# Linux/WSL2:
# sudo apt install -y pre-commit
# or: python3 -m pip install --user pre-commit

pre-commit install
pre-commit run --all-files

اگر آپ کا ہک ناکام ہوجاتا ہے، تو پہلے غلطی کو پڑھیں۔ گٹلیکس اور رف کو ارتکاب کرنے سے پہلے گزرنا چاہیے۔ کچھ YAML یا Terraform ہک کے مسائل بعد کے مرحلے کی فائلوں میں ہو سکتے ہیں۔ اس صورت میں، اسٹیج ہدایات کے ساتھ جاری رکھیں اور troubleshooting.md Gitleaks یا CI سکینر کی خرابیوں کی صورت میں۔

ایسا کرنے سے پہلے ٹیسٹ کریں کہ آپ کا CI مقامی طور پر راز کو پکڑتا ہے۔

echo 'AWS_SECRET = "'$(printf '%s%s' 'AKIA' 'IOSFODNN7EXAMPLE')'"' >> app/auth-service/main.py
git add app/auth-service/main.py && git commit -m "test"

# Gitleaks fires and blocks the commit — see "What you should see" below

git restore --staged app/auth-service/main.py

git checkout app/auth-service/main.py

کمٹ کو گٹ تک پہنچنے سے پہلے ہی بلاک کر دیا گیا تھا۔ اگر آپ کے پاس پری کمٹ ہک انسٹال نہیں ہے تو، وہ جعلی AWS کلید آپ کی گٹ ہسٹری میں مستقل طور پر موجود رہے گی (چاہے آپ اس لائن کو بعد میں حذف کردیں، گٹ اسے یاد رکھے گا)۔

اگر آپ پہلے ہی مرحلہ 1 میں سائن کر چکے ہیں، یہ ضروری ہے۔ مرحلہ 3 کلیدی تخلیق نو کی ضرورت نہیں ہے۔ اسے چیک کریں۔ infra/cosign.pub یہ موجود ہے اور GitHub پر ہے۔ COSIGN_PRIVATE_KEY + COSIGN_PASSWORD. مرحلہ 4 لاگ ان کرنے پر سوئچ کرتا ہے۔ نفاذ کلسٹر گیٹ پر۔

ہینڈ آن چیک پوائنٹ: قبل از کمٹ دراصل راز کو روکتا ہے۔

انسٹال لیکن منسلک نہیں ایک کلاسک خاموش ناکامی ہے۔ ثابت کریں کہ ہک کام کرتا ہے۔

echo 'AWS_SECRET='"$(printf '%s%s' 'AKIA' 'IOSFODNN7EXAMPLE')" > leak-test.env

git add leak-test.env

pre-commit run --all-files; echo "exit=$?"

git reset leak-test.env >/dev/null; rm -f leak-test.env

متوقع: خفیہ سکیننگ ہک ناکام پھانسی (exit=1) اور جھنڈے leak-test.env. اگر exit=0ہک نصب ہے، لیکن یہ کچھ بھی نہیں پکڑتا. دوبارہ چلائیں۔ pre-commit install چیک کریں اور .git/hooks/pre-commit یہ موجود ہے۔

اگر آپ اسے چھوڑ دیتے ہیں، تو آپ بغیر اسکین کے سفر کریں گے اور یقین کریں گے کہ مرحلہ 3 آپ کی حفاظت کرتا ہے جب ایسا نہیں ہوتا ہے۔

3.2: شریک دستخط کلید بنائیں

اگر آپ نے Cosign کلید کو مرحلہ 1 (§1.4) میں بنایا ہے، تو اسے بنانا چھوڑ دیں اور سیدھے داخل کرنے پر جائیں۔ cosign.pub ذیل میں GitHub راز کو اپنی Kyverno پالیسی میں شامل کریں۔

مشترکہ نشان اپنی انکرپشن کلید سے ڈاکر امیج پر دستخط کریں۔ کلسٹر میں تعیناتی Kyverno (مرحلہ 4) کو دستخط کی تصدیق کرنے اور پائپ لائن سے غیر دستخط شدہ تصاویر کو مسترد کرنے کی اجازت دیتی ہے۔ یہ کسی کو نقصان دہ تصویر کو Docker Hub پر آگے بڑھانے اور اسے آپ کے کلسٹر پر چلانے سے روکتا ہے۔

# macOS: brew install cosign

# Linux/WSL2: curl -O -L https://github.com/sigstore/cosign/releases/download/v2.2.4/cosign-linux-amd64 && chmod +x cosign-linux-amd64 && sudo mv cosign-linux-amd64 /usr/local/bin/cosign

cosign generate-key-pair   # enter a password when prompted

اس سے دو فائلیں بنیں گی۔ cosign.key (نجی، دستخط کرنے کے لیے پائپ لائن میں استعمال کیا جاتا ہے) اور cosign.pub (عوامی، تصدیق کے لیے Kyverno کے ذریعے استعمال کیا جاتا ہے)

اپنی Kyverno پالیسی میں اپنی عوامی کلید داخل کریں (پلیس ہولڈر بلاک کو یہاں تبدیل کریں)۔ infra/policies/require-signed-images.yaml کے مشمولات کے ساتھ cosign.pub)۔

GitHub میں ایک راز شامل کریں (github.com/YOUR_USERNAME/clearledger → ترتیبات → راز اور متغیرات → اعمال):

خفیہ	قدر
COSIGN_PRIVATE_KEY	تفصیل cosign.key
COSIGN_PASSWORD	کلید بناتے وقت پاس ورڈ درج کیا گیا۔

لیب چیک پوائنٹ: آپ کی کو-سائننگ کلید تیار ہے۔

مرحلہ 4 استعمال کریں۔ cosign.pub دستخط شدہ تصویر کو چیک کریں۔ جاری رکھنے سے پہلے، یقینی بنائیں کہ آپ کی کلیدی فائل موجود ہے اور آپ کی نجی کلید کو Git میں ٹریک نہیں کیا گیا ہے۔

test -f cosign.key && echo "private key present"
test -f cosign.pub && echo "public key present"
grep -q "BEGIN PUBLIC KEY" cosign.pub && echo "public key valid"
git check-ignore cosign.key && echo "private key correctly ignored"

متوقع: تمام چار لائنیں پرنٹ ہونی چاہئیں۔

اگر git check-ignore cosign.key کچھ بھی پرنٹ کیے بغیر شامل کریں۔ cosign.key کو .gitignore کچھ کرنے سے پہلے۔ آپ کی نجی کلید Git سے باہر ہونی چاہیے۔

اس امتحان کو نہ چھوڑیں۔ مرحلہ 4 کے لیے Kyverno امیج پر دستخط کرنے کی پالیسی کے لیے عوامی کلید کی ضرورت ہے اور نجی کلید کو مقامی طور پر رکھا جانا چاہیے۔

3.3: پوری سیکیورٹی پائپ لائن کو چالو کریں۔

سیکیورٹی گیٹ پہلے ہی اندر ہے۔ .github/workflows/ci.yaml. پوری پائپ لائن کو متحرک کرنے کے لیے اپنی تبدیلیوں کو آگے بڑھائیں۔

git add . && git commit -m "ci: full DevSecOps pipeline" && git push origin main

3.4: جان بوجھ کر ہر دروازے کو توڑنا

ہر گیٹ کے لیے، آپ جان بوجھ کر کسی چیز کو توڑنا چاہیں گے، پڑھیں کہ ٹول اسے کیسے رپورٹ کرتا ہے، واپس لوٹنا، اور پھر سبز رنگ کی دوبارہ جانچ کرنا چاہیں گے۔ پہلے مقامی کمانڈ آزمائیں، پھر ایک بار دبائیں اگر آپ GitHub ایکشنز میں اسکرین شاٹ چاہتے ہیں۔

# 1. Break it   2. Run locally or push   3. Read the failure
# 4. git checkout -- path/to/file   5. pre-commit run --all-files (optional)   6. git push

سے شروع کریں۔ گیٹ 1 کسی بھی چیز سے پہلے آخر تک۔

گیٹ 1: گٹلیکس (خفیہ)

انجکشن: AWS کلید Python فائل میں ہارڈ کوڈ کی گئی ہے۔

مقصد یہ ثابت کرنا ہے کہ خفیہ سکینر کام کرتا ہے۔

یہ کمانڈ ایک جعلی AWS کی شکل والی کلید کا اضافہ کرتی ہے۔ app/auth-service/main.py:

echo 'AWS_KEY = "'$(printf '%s%s' 'AKIA' 'IOSFODNN7EXAMPLE')'"' >> app/auth-service/main.py

git add app/auth-service/main.py && git commit -m "test: trigger gitleaks"
# pre-commit blocks this commit locally — that is the test.
# For a CI screenshot only: git commit --no-verify -m "test: trigger gitleaks" && git push

تکمیل اس طرح نظر آتی ہے (ٹرمینل: پری کمٹ):

🔑 Secrets scan (Gitleaks)...............................................Failed
- hook id: gitleaks
- exit code: 1

Finding:     AWS_KEY = "REDACTED"
RuleID:      aws-access-token
File:        app/auth-service/main.py
Line:        316

متوقع: عزم کو ناکام ہونا چاہیے۔ Gitleaks کو اپنی ایک خفیہ دریافت کی اطلاع دینے کی ضرورت ہے۔ app/auth-service/main.py.

یہ ناکامی اچھی چیز ہے۔ اس کا مطلب ہے کہ مقامی پری کمٹ ہک نے گٹ تک پہنچنے سے پہلے ہی اس راز کو پکڑ لیا۔

ارد گرد کیا ہوتا ہے:

git restore --staged app/auth-service/main.py 2>/dev/null
git checkout app/auth-service/main.py
pre-commit run gitleaks --all-files   # → Passed

گیٹ 2: Semgrep (SAST)

مقامی خشک رن (ذخیرہ میں کوئی تبدیلی نہیں):

python3 -m venv /tmp/sec-gates-venv && /tmp/sec-gates-venv/bin/pip install semgrep
cat > /tmp/semgrep-bad.py << 'EOF'
import subprocess
from fastapi import Request
def bad(request: Request):
    subprocess.run(request.query_params.get("cmd"), shell=True)
EOF
/tmp/sec-gates-venv/bin/semgrep 
  --config=p/python --config=p/security-audit --config=p/owasp-top-ten --error 
  /tmp/semgrep-bad.py

بریکنگ CI: Semgrep کو اسکین کرنے، کمٹ کرنے اور آگے بڑھانے کے لیے عارضی فائلیں شامل کریں۔

cat > app/auth-service/gate_test_semgrep.py << 'EOF'
import subprocess
from fastapi import Request
def bad(request: Request):
    subprocess.run(request.query_params.get("cmd"), shell=True)
EOF

git add app/auth-service/gate_test_semgrep.py && git commit -m "test: trigger semgrep" && git push

متوقع نتائج: سیمگریپ رپورٹ subprocess-shell-true پسند Blocking. کہ SAST (Semgrep) کام سرخ ہو جاتا ہے اور امیج بنانے کا کام نہیں چلتا ہے۔

ارد گرد کیا ہوتا ہے:

rm -f app/auth-service/gate_test_semgrep.py
git add -A && git commit -m "revert: semgrep gate test" && git push

گیٹ 3: چیکوف (IaC/Dockerfile)

چیکوف غیر محفوظ کنفیگریشنز کے لیے Dockerfiles اور Kubernetes ظاہر کرتا ہے۔

سب سے پہلے، مقامی ڈیمو چلائیں. اگر آپ ایسا کرتے ہیں۔ HEALTHCHECK ایک کاپی شدہ ڈاکر فائل دکھاتی ہے کہ چیکوف اس کی اطلاع کیسے دیتا ہے۔

python3 -m venv /tmp/sec-gates-venv && /tmp/sec-gates-venv/bin/pip install checkov
sed '/^HEALTHCHECK/,+1d' app/auth-service/Dockerfile > /tmp/Dockerfile-nohc
mkdir -p /tmp/checkov-demo/app/auth-service
cp /tmp/Dockerfile-nohc /tmp/checkov-demo/app/auth-service/Dockerfile
/tmp/sec-gates-venv/bin/checkov --directory /tmp/checkov-demo --framework dockerfile

اب ہم CI میں چیکوف کے نتائج کو متحرک کرنے کے لیے SSH پورٹ کو بے نقاب کرتے ہیں۔ 22 توثیق کی خدمت Dockerfile میں:

echo 'EXPOSE 22' >> app/auth-service/Dockerfile
git add app/auth-service/Dockerfile && git commit -m "test: trigger checkov" && git push

متوقع نتائج: آپ کو چیکوف لاگز یا نمونے دیکھنا چاہیے۔ CKV_DOCKER_1اس کا مطلب ہے کہ آپ کا SSH پورٹ بے نقاب ہے۔

کہ IaC Scan (Checkov) چیکوف کی طرف سے تفویض کردہ شدت پر منحصر ہے، کام سرخ ہو سکتا ہے یا نہیں۔ اس مشق کے لیے یہ ٹھیک ہے۔ مقصد چیکوف کے نتائج کو تلاش کرنا اور سمجھنا ہے۔

اگر آپ کو ناکام GitHub ایکشنز کے اسکرین شاٹس کی ضرورت ہے تو گیٹ 1، گیٹ 2، یا گیٹ 4 استعمال کریں۔ یہ آپ کے ورک فلو کو سرخ کرنے کے لیے ڈیزائن کیا گیا ہے۔ چیکوف سبز رہ سکتا ہے کیونکہ یہ بنیادی طور پر نتائج کو پڑھنے کے لیے استعمال ہوتا ہے۔

ارد گرد کیا ہوتا ہے:

git checkout app/auth-service/Dockerfile
git commit -am "revert: checkov gate test" && git push

گیٹ 4: ٹریوی (تصویر CVE)

مقامی خشک رن: پچھلی بنیادی تصویر کو اسکین کریں (کوئی تعمیر نہیں):

trivy image --exit-code 1 --severity CRITICAL,HIGH --ignore-unfixed python:3.8-slim

بریکنگ CI: پرانے بیس کو ڈاکر فائل میں پن کریں، دبائیں اور انتظار کریں۔ Scan images:

sed -i.bak 's/FROM python:3.13-slim/FROM python:3.8-slim/' app/auth-service/Dockerfile
git add app/auth-service/Dockerfile && git commit -m "test: trigger trivy" && git push

پاس: Scan images → ٹریوی تمام تصاویر کو اسکین کرتا ہے۔ CVE ٹیبل کے ساتھ 1 باہر نکلیں (HIGH / CRITICAL)۔ Publish images اور Update Manifests چھوڑیں۔

ارد گرد کیا ہوتا ہے:

git checkout app/auth-service/Dockerfile
git commit -am "revert: trivy gate test" && git push

3.5: جب غیر انجکشن شدہ CVEs کی جانچ پڑتال ناکام ہوجاتی ہے۔

§3.4 جان بوجھ کر ہے۔ یہ سیکشن ایک اور کیس کے بارے میں ہے جہاں آپ نے عام کوڈ کو آگے بڑھایا، لیکن ایک نئی کمزوری دریافت ہوئی اور امیج اسکین ناکام ہوگیا۔
یہ عام بات ہے۔ CVE ڈیٹا بیس ہمیشہ اپ ڈیٹ ہوتا ہے۔ اسکین کو کمزور نہ کریں۔ کمزور پیکجوں یا تصاویر کو درست کریں۔

سب سے پہلے، اصل CVE تلاش کریں۔ GitHub ایکشنز میں، کھولیں: تصویر اسکین پھر جاؤ ٹریوی تمام تصاویر کو اسکین کرتا ہے۔ اس کا استعمال کرتے ہوئے ٹیبل تلاش کریں:

اس ریڈ ہیرنگ کو نظر انداز کریں۔ لاگ کے نیچے:

Version 0.71.2 of Trivy is now available
Error: Process completed with exit code 1.

ورژن کی اطلاعات کام کو ناکام نہیں کرتی ہیں۔ یہ ایک قابل اصلاح ہائی/کریٹیکل CVE ہے۔ شامل نہ کریں --skip-version-check اسے "ٹھیک" کرنے کے لیے۔

اس کے بجائے، استعمال کریں:

• پائپ پیکج: اگلے فکسڈ ورژن پر جائیں۔ requirements.txt (ہاں: python-multipart==0.0.30 CVE-2026-53539 کے لیے)۔ بہن بھائیوں کی خدمات کو وہی ٹکرائیں اگر وہ اس پن کا اشتراک کرتے ہیں۔

• OS پیکیج: تازہ ترین بیس تصویر یا ہدف کی تصویر apt/apk Dockerfile سے اپ گریڈ کریں۔

• ابھی تک کوئی مستحکم حل نہیں ہے۔ صرف مستثنیات دستاویزی: CVE کو اس میں شامل کریں: .trivyignore اور .grype.yaml تبصروں کے ساتھ (دیکھیں۔ CVE-2026-7210)۔

نہ ہٹائیں --exit-code 1شدت کے اصول کو کم کریں یا چیک کو غیر فعال کریں۔ مدد کے لیے، Trivy ورژن کی اطلاعات اور Trivy blocks Python سروس کی تصاویر دیکھیں۔

مرحلہ 3 مکمل ہوا۔

اسکرین شاٹس کے لیے، ایک واضح ناکام گیٹ استعمال کریں۔

§3.4 میں ہر ٹیسٹ کے بعد، ٹیسٹ کی تبدیلی کو کالعدم کریں، Revert دبائیں، اور چیک کریں کہ ورک فلو دوبارہ سبز ہے۔ آپ کے پورٹ فولیو کے لیے ایک سرخ GitHub ایکشن اسکرین شاٹ کافی ہے۔

ایک مرحلہ چیک چلائیں۔

make check-3   # must end: All checks passed. Ready for the next stage.

متوقع: All checks passed. Ready for the next stage.

مزید برآں، §3.4 میں کم از کم ایک گیٹ کو متحرک کیا جانا چاہیے۔ مقامی Gitleaks کی ناکامیاں اہم ہیں۔

ENABLE_DAST=true اختیاری اس کی ضرورت صرف اس صورت میں ہے جب آپ بعد میں ZAP چلانا چاہتے ہیں۔

ابھی ضرورت نہیں ہے: چیکوف بلاکنگ کبرنیٹس مینی فیسٹ یا کوسائن بلاکنگ تعیناتی۔ مرحلہ 4 اسے Kyverno کا استعمال کرتے ہوئے کلسٹر تعیناتی میں بدل دیتا ہے۔

اگلا، اپنی ترقی کو محفوظ کریں۔

make snapshot STAGE=3 && make snapshots

مرحلہ 4 — داخلہ کنٹرول (Kyverno)

یہاں تک کہ اگر CI پاس ہو جاتا ہے، تب بھی کلسٹر اسے مسترد کر سکتا ہے۔

CI کوڈ اور امیجز کو GitOps تک پہنچنے سے پہلے اسکین کرتا ہے، لیکن یہ کلسٹر کے اندر ہونے والی ہر چیز پر نظر نہیں رکھ سکتا۔ کوئی بھی kubectl رسائی مینی فیسٹ کو براہ راست لاگو کر سکتی ہے۔

ہیلم چارٹس جو آپ انسٹال کرتے ہیں وہ پوڈ بنا سکتے ہیں جو سیکورٹی کے معیارات کی خلاف ورزی کرتے ہیں۔ چونکہ یہ راستے پائپ لائن تک نہیں پہنچتے ہیں، اس لیے مرحلہ 4 داخلہ کنٹرول کا اضافہ کرتا ہے، یہ ایک چیک پوائنٹ ہے جو خود Kubernetes میں بنایا گیا ہے۔

جب بھی کوئی وسیلہ بنانے یا اپ ڈیٹ کرنے کی کوشش کی جاتی ہے، درخواست لاگو ہونے سے پہلے قبولیت کے ویب ہک سے گزر جاتی ہے۔ اگر ویب ہک درخواست کو مسترد کرتا ہے تو کوئی وسیلہ نہیں بنایا جاتا ہے۔

کیبرنو ایک Kubernetes پر مبنی پالیسی انجن جو ان ویب ہکس کو استعمال کرتا ہے۔ آپ اپنی پالیسی کو YAML فائل میں لکھتے ہیں (ایپلی کیشن کوڈ نہیں)، اور Kyverno پالیسی کو آپ کے کلسٹر میں تمام مماثل وسائل پر لاگو کرتا ہے۔ مثال کے طور پر، جڑ کے طور پر چلنے والے تمام پوڈز سے انکار کریں یا تمام کنٹینرز پر CPU اور میموری کی حد کی ضرورت ہے۔

CI کے ساتھ فرق وقت کا ہے: CI اسکین پہلے کوڈ بھیج دیا گیا ہے اور Kyverno کلسٹر گیٹ. وہ مل کر دفاع کی دو پرتیں فراہم کرتے ہیں۔

اس قدم کا مقصد Kyverno کو انسٹال کرنا اور پالیسیاں لاگو کرنا ہے۔ infra/policies/اور §4.4 میں، ثابت کریں کہ کنٹینر کے رن ٹائم کے ذریعے چیک کیے جانے سے پہلے غیر تعمیل پوڈز کو مسترد کر دیا جاتا ہے۔

شروع کرنے سے پہلے، یقینی بنائیں کہ پچھلے مراحل کی بنیاد اب بھی مضبوط ہے۔ make check-3 پاس ہونا ضروری ہے (پری کمٹ ہک اور سی آئی سیکیورٹی گیٹ فعال)۔ infra/cosign.pub یہ مرحلہ 3 سے موجود ہونا چاہئے اور ArgoCD مطابقت پذیر رہنا چاہئے لہذا ایپ کو جواب دینا چاہئے۔ http://clearledger.local. اگر ان میں سے کوئی سرخ ہے تو پہلے اسے درست کریں۔ Kyverno ایک صحت مند جھرمٹ پر بیٹھتا ہے، نہ کہ ٹوٹے ہوئے جھرمٹ پر۔

§4.4 میں بند ہونے والے تینوں منظرناموں کو مسترد کر دیا گیا ہے اور make check-4 یہ گزر جاتا ہے۔

فیز 3 میں تبدیلی نفاذ ہے، معائنہ نہیں۔ CI میں، Checkov نے Kubernetes کنفیگریشن کی خرابی کی اطلاع دی لیکن پائپ لائن کو بلاک نہیں کیا۔ Kyverno اب کلسٹر گیٹ پر اسی قسم کے مسئلے کو روکتا ہے۔

Cosign مرحلہ 1 سے آپ کی تصاویر پر دستخط کر رہا ہے۔ اب Kyverno ضرورت ClearLedger امیج کو تقسیم کرنے سے پہلے اس پر دستخط کریں۔ یہ وہ جگہ ہے جہاں مرحلہ 1 ثبوت کو پھانسی دی جاتی ہے۔ فیز 1 میں کیا بلاک کیا گیا تھا اور فیز 4 میں کیا انتظار کیا جا رہا تھا اس کے مکمل نقشے کے لیے وہ سیکشن دیکھیں۔

Kyverno انسٹال کرنے کے لیے، §4.1 سے شروع کریں۔ تنصیب، پالیسی، بندش کا منظر، یا make check-4 ناکام، پڑھیں troubleshooting.md اور مرحلہ 4: داخلہ کنٹرول (Kyverno) ہیلم کی اقدار یا پالیسی YAML کو تبدیل کرنے سے پہلے۔

Kyverno کیا لاگو کرتا ہے

تمام پالیسی فائلیں یہاں موجود ہیں: infra/policies/. Kyverno خود ہیلم کے ذریعے انسٹال ہوتا ہے: stages/stage-4-admission-control/infra/kyverno/values.yaml.

پالیسی	جس پر عمل کیا جاتا ہے۔	کنکال
disallow-root-containers	runAsNonRoot: true	CIS K8s 5.2.6
require-resource-limits	CPU/میموری کی درخواستیں اور حدود	CIS K8s 5.2.4
disallow-privilege-escalation	allowPrivilegeEscalation: false	CIS K8s 5.2.5
drop-all-capabilities	capabilities.drop: [ALL]	CIS K8s 5.2.7
require-signed-images	ClearLedger امیجز پر مشترکہ دستخط کرنا	SLSA لیول 2

پلیٹ فارم کا استحکام: سطح 4 سے

مرحلہ 4 کے بعد سے، آپ ایک ہی نوڈ VM پر مزید کنٹرولرز چلا رہے ہوں گے۔ Kyverno، اسٹوریج فراہم کرنے والا، اور بعد میں Prometheus اور Loki. پھلیاں نظر آسکتی ہیں۔ Running حقیقت میں، کریش لوپ پس منظر میں ہوتا ہے۔

پلیٹ فارم پوڈ (کیورنو کنٹرولر، hostpath-provisionerپرومیتھیس آپریٹرز وغیرہ) بہت زیادہ جمع ہیں۔ RESTARTSAPI سرور کا وقت ختم ہونا شروع ہو جاتا ہے۔ kubectl یہ غیر مستحکم محسوس ہوتا ہے اور میں غلط اجزاء کو ڈیبگ کرنے میں دن ضائع کر سکتا ہوں کیونکہ ایپ پوڈ ٹھیک لگ رہا ہے۔

یہاں سے تمام اقدامات کے بعد، کلسٹر کے مستحکم ہونے کے لیے تقریباً 10 منٹ انتظار کریں اور پھر سٹیپ اسٹیٹس چیک کو چلائیں۔

bash scripts/health-check.sh     # for example, 4, 7, 7.5
# or the Makefile shortcut:
make check-4

اسکرپٹ پلیٹ فارم کے استحکام والے حصے کے ساتھ ختم ہوتا ہے جو پوڈز کو مشکوک دوبارہ شروع کرنے کی گنتی کے ساتھ جھنڈا لگاتا ہے۔ یہاں تک کہ آپ بدترین مجرموں کو خود بھی اسکین کر سکتے ہیں۔ اس میں 15 پوڈز کی فہرست دی گئی ہے جن میں کلسٹر میں دوبارہ شروع ہونے کی سب سے زیادہ تعداد ہے۔ یہ اس وقت مفید ہے جب آپ کو لگتا ہے کہ چیزیں سست ہیں، لیکن آپ کو یقین نہیں ہے کہ کون سی نام کی جگہ جدوجہد کر رہی ہے۔

kubectl get pods -A --sort-by='.status.containerStatuses[0].restartCount' 
  -o custom-columns="NS:.metadata.namespace,NAME:.metadata.name,RESTARTS:.status.containerStatuses[0].restartCount" 
  | tail -15

گیٹ: آپ کو Kyverno کنٹرولر اور دیگر پلیٹ فارم پوڈز دیکھنا چاہیے۔ 5 سے کم عمر دوبارہ شروع کریں۔ اسٹیج ختم ہونے کے بعد۔ اگر آپ کے پلیٹ فارم کی پوڈز 10 سے زیادہ ہیں، تو دستاویزی ہیلم ویلیوز یا ٹربل شوٹنگ ڈاٹ ایم ڈی کا استعمال کرتے ہوئے انہیں روکیں اور ٹھیک کریں۔ نہیں کرتے kubectl patch ادھر ادھر دیکھو اور آگے بڑھو۔ ایک مستحکم پلیٹ فارم پرت تمام بعد کے مراحل کے لیے ایک شرط ہے۔

4.1: Kyverno انسٹال کرنا

helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update

helm upgrade --install kyverno kyverno/kyverno 
  --version 3.2.8 
  --namespace kyverno 
  --create-namespace 
  -f stages/stage-4-admission-control/infra/kyverno/values.yaml 
  --wait --timeout=600s

ویلیوز فائل ہماری لیب میں تین اہم کام انجام دیتی ہے:

1. CronJob کی صفائی کو غیر فعال کریں۔: پچھلے Kyverno چارٹس درآمد کریں۔ bitnami/kubectlاسے Docker Hub سے ہٹا دیا گیا ہے اور اس کا سبب بنتا ہے۔ ImagePullBackOff کلین اپ پوڈ میں۔

2. وہ نقطہ جہاں ہیلمٹ جڑتا ہے۔ bitnamilegacy/kubectlتو مستقبل helm uninstall گمشدہ تصاویر پر مت لٹ جائیں۔

3. سرگرمی کی تحقیقات کا وقت ختم کریں۔: پہلے سے طے شدہ timeoutSeconds: 5, failureThreshold: 2 یہ بھری ہوئی سنگل نوڈ VM کے لیے کافی نہیں ہے۔ CPU دباؤ کے تحت، ہیلتھ اینڈ پوائنٹ کو جواب دینے میں 5 سیکنڈ سے زیادہ کا وقت لگ سکتا ہے، جو مسلسل دوبارہ شروع ہونے کو متحرک کرتا ہے جو نوڈ کو سیر کرتا ہے اور API سرور کو وقفے وقفے سے ناقابل رسائی بنا دیتا ہے۔ ویلیو فائل سیٹ timeoutSeconds: 30, failureThreshold: 5 لہذا، Kyverno بار بار ہونے والے کریشوں کے بغیر لوڈ اسپائکس کو برداشت کرتا ہے۔

آپ کو کیا دیکھنا چاہئے:

Release "kyverno" does not exist. Installing it now.
NAME: kyverno
NAMESPACE: kyverno
STATUS: deployed
...
Kyverno version: v1.12.6

یقینی بنائیں کہ چاروں کنٹرولرز چل رہے ہیں (اگر آپ کا کنکشن سست ہے تو پہلی پولنگ میں کئی منٹ لگ سکتے ہیں)۔

kubectl get pods -n kyverno

NAME                                             READY   STATUS    RESTARTS   AGE
kyverno-admission-controller-bd685cd4b-f6kl6     1/1     Running   0          2m
kyverno-background-controller-66fcfc6d87-59wgt   1/1     Running   0          2m
kyverno-cleanup-controller-5c5bf8bc6b-7kspq      1/1     Running   0          2m
kyverno-reports-controller-5cdd6f4c48-qf5wc      1/1     Running   0          2m

اگر پھلی وہی رہتی ہے۔ ContainerCreating ایک طویل عرصے سے نوڈ اب بھی تصاویر حاصل کر رہا ہے۔ ghcr.io/kyverno. انتظار کرو ہیلم کی جزوی تنصیب کے اوپر دوسری ہیلم کی تنصیب شروع نہ کریں۔

استحکام گیٹ: صرف Kyverno تنصیبات کے لیے (§4.2 سے پہلے):

جاری رکھنے سے پہلے یقینی بنائیں کہ آپ کا کیورنو پوڈ صحت مند ہے۔

kubectl get pods -n kyverno

متوقع: Kyverno کنٹرولر فورڈ شو 1/1 Runningکم دوبارہ شروع: 0, 1یا 2دوبارہ شروع کرنے کی تعداد میں اضافہ نہیں ہوا ہے۔

مت بھاگو make check-4 ابھی تک یہ چیک ان پالیسیوں کی بھی تلاش کرتا ہے جو بعد میں §4.3 میں لاگو ہوتی ہیں، اس لیے یہ اس مقام پر ناکام ہو سکتی ہے چاہے Kyverno کو صحیح طریقے سے انسٹال کیا گیا ہو۔

4.2: تصدیق کریں کہ Cosign پبلک کلید پالیسی میں ہے۔

مرحلہ 3 بنایا گیا ہے۔ infra/cosign.pub. Kyverno Pod بننے پر تصویر کے دستخط کی تصدیق کے لیے وہی کلید استعمال کرتا ہے۔ پالیسی فائل پلیس ہولڈرز کے ساتھ آتی ہے۔ آپ کو §4.3 میں پالیسی لاگو کرنے سے پہلے اسے کلید سے تبدیل کرنا ہوگا۔

مرحلہ 1: کلید دکھائیں (VM کے اسٹوریج روٹ سے چلائیں)

cd ~/clearledger    # or wherever you cloned the repo
cat infra/cosign.pub

آپ کو درج ذیل تین لائنیں نظر آئیں گی۔ -----BEGIN PUBLIC KEY-----لمبی بیس 64 لائن اور -----END PUBLIC KEY-----. پورے بلاک کو کاپی کریں (آپ اسے اگلے مرحلے میں پیسٹ کریں گے)۔

مرحلہ 2: کلید کو پالیسی میں چسپاں کریں۔

کھلا infra/policies/require-signed-images.yaml ایڈیٹر میں (nano, vimیا VS کوڈ)۔

درج ذیل لائن تلاش کریں:

                      PASTE_YOUR_COSIGN_PUBLIC_KEY_HERE

حذف کریں صرف وہ پلیس ہولڈر لائن درج کریں اور اگلی تین لائنیں چسپاں کریں۔ cosign.pub موقع پر۔ نتیجہ اس طرح نظر آنا چاہئے (بیس 64 لائنیں مختلف ہوسکتی ہیں):

                - keys:
                    publicKeys: |-
                      -----BEGIN PUBLIC KEY-----
                     JFkwEwYHKoZIzj0CAQYIKoFIzj0DAQcDQgZEI...
                      -----END PUBLIC KEY-----

فائل کو محفوظ کریں۔ چسپاں کلید کو نیچے حاشیہ میں رکھیں۔ publicKeys: |-. کہ BEGIN PUBLIC KEY اور END PUBLIC KEY بیس 64 لائنوں کی طرح لائنوں سے پہلے ایک جگہ ہونی چاہیے۔

مرحلہ 3: چیک کریں (3 فوری چیک)

ریپوزٹری روٹ سے ایک وقت میں ان کو چلائیں۔

# Check A — placeholder must be gone
grep PASTE_YOUR_COSIGN_PUBLIC_KEY_HERE infra/policies/require-signed-images.yaml 
  && echo "❌ FAIL: placeholder still in file — edit and save again" 
  || echo "✓ OK: placeholder removed"

# Check B — key block must be present exactly once
grep -c "BEGIN PUBLIC KEY" infra/policies/require-signed-images.yaml

چیک B کے لیے متوقع آؤٹ پٹ: 1 (اگر آپ دیکھیں 0چابی چسپاں نہیں کی گئی۔ اگر 2دو بار چسپاں کیا گیا)۔

# Check C — policy key must match cosign.pub byte-for-byte
diff infra/cosign.pub 
  <(sed -n '/-----BEGIN PUBLIC KEY-----/,/-----END PUBLIC KEY-----/p' 
      infra/policies/require-signed-images.yaml | sed 's/^[[:space:]]*//')

چیک سی کی متوقع پیداوار: کچھ نہیں. کوئی فرق نہیں لائنوں کا مطلب ہے کہ چابیاں مماثل ہیں۔ اگر diff اختلافات کو پرنٹ کریں، پالیسی فائل کھولیں اور پیسٹ میں ترمیم کریں۔

اگر آپ تینوں پاس کرتے ہیں تو §4.3 کے ساتھ جاری رکھیں۔

اگر آپ اسے چھوڑ دیتے ہیں۔§4.4 میں منظر نامہ 3 ایک الجھے ہوئے طریقے سے ناکام ہو جاتا ہے۔ چونکہ Kyverno غلط کلید کی تصدیق کر رہا ہے، غیر دستخط شدہ تصاویر بچ سکتی ہیں یا دستخط شدہ پوڈز کو مسترد کیا جا سکتا ہے۔

4.3: پانچ بنیادی پالیسیوں کو لاگو کرنا

اب ہم پانچ پالیسیاں لاگو کریں گے جو CIS کنٹرولز کو نقشہ بناتی ہیں۔ لاگو نہ کریں verify-slsa-provenance.yaml ابھی تک مستقبل میں اضافہ کے لیے اختیاری SLSA تصدیقی پالیسی (آڈٹ موڈ)۔

مرحلہ 4 درخواست infra/policies/require-signed-images.yaml. یہ پالیسی failurePolicy: Failلہذا، اگر Kyverno تصویر کے دستخط کی تصدیق نہیں کرسکتا ہے، تو پوڈ کو اجازت کے بجائے بلاک کردیا جائے گا۔ ای سی آر پالیسی مندرجہ ذیل ہے: failurePolicy: Ignore یہ مرحلہ 8 کے لیے ہے، یہ قدم نہیں۔

kubectl apply 
  -f infra/policies/disallow-root.yaml 
  -f infra/policies/disallow-privilege-escalation.yaml 
  -f infra/policies/drop-all-capabilities.yaml 
  -f infra/policies/require-resource-limits.yaml 
  -f infra/policies/require-signed-images.yaml

چند سیکنڈ انتظار کریں اور چیک کریں کہ آیا تمام پالیسیاں ظاہر ہوتی ہیں۔ READY: True اور VALIDATE ACTION: Enforce:

kubectl get clusterpolicy

NAME                            ADMISSION   BACKGROUND   VALIDATE ACTION   READY   AGE
disallow-privilege-escalation   true        true         Enforce           True    10s
disallow-root-containers        true        true         Enforce           True    10s
drop-all-capabilities           true        true         Enforce           True    10s
require-resource-limits         true        true         Enforce           True    10s
require-signed-images           true        false        Enforce           True    10s

اگر READY یہ خالی ہے۔ Kyverno لاگز کو چیک کریں۔ kubectl logs -n kyverno -l app.kubernetes.io/component=admission-controller --tail=50.

4.4: جان بوجھ کر توڑنا

اب آئیے ایک غلط Pod بنا کر پالیسی کی جانچ کریں۔

اس پوڈ کے ناکام ہونے کی امید ہے۔ یہی بات ہے۔

چیکوف جیسے CI ٹولز آپ کو اپنی رپورٹس میں خبردار کریں گے۔ Kyverno مزید آگے بڑھتا ہے اور غیر محفوظ پھلیوں کو روکتا ہے اس سے پہلے کہ Kubernetes ان پر عمل درآمد کر سکے۔

ہر ٹیسٹ کے لیے غلطی کے پیغامات پڑھیں۔ اس کی وجہ یہ ہے کہ یہ آپ کو بتاتا ہے کہ کس پالیسی نے پوڈ کو بلاک کیا اور کون سے فیلڈز غلط تھے۔ یہ غلطی کا پیغام اس بات کا ثبوت ہے کہ داخلہ کنٹرول کام کر رہا ہے۔

سکرپٹ	کیا نقلی ہے	پالیسی کی جانچ کی جا رہی ہے۔	کامیابی یہ ہے:
1	حملہ آور ننگی پھلی لگاتا ہے (کوئی سختی نہیں)۔	جڑ، بڑے، اجازت، پابندیاں	4 پالیسی فائر، فورڈ NotFound
2	ڈویلپر نے securityContext میں ترمیم کی لیکن پابندیوں کو بھول گیا۔	صرف وسائل کی حدود	1 پالیسی چل رہی ہے، پوڈ NotFound
3	ایک حملہ آور ایک غیر دستخط شدہ تصویر کو Docker Hub کی طرف دھکیلتا ہے۔	شریک دستخط	require-signed-images مسترد، فورڈ NotFound

منظر نامہ 1: روٹ کنٹینر (کوئی سیکیورٹی سیاق و سباق نہیں)

کیا نقل کیا جا رہا ہے: کوئی بھی kubectl رسائی CI کو نظرانداز کرتی ہے اور کم سے کم پوڈز کو نافذ کرتی ہے۔ نہیں securityContextوسائل کی کوئی حد نہیں ہے۔

یہ بالکل وہی ہے جسے مرحلہ 1 چیکوف نے بطور ثبوت نشان زد کیا ہے۔ اب مرحلہ 4 اسے روکتا ہے۔

اس منشور میں کیا حرج ہے؟ ایک کنٹینر میں صرف ایک نام اور ایک تصویر ہوتی ہے۔ یہ مقامی طور پر جڑ کے طور پر چلتا ہے، تمام لینکس کی فعالیت کو برقرار رکھتا ہے، اور اس کی کوئی CPU/میموری کی حدود نہیں ہیں۔

cat <

آپ کو کیا دیکھنا چاہئے:

Error from server: error when creating "STDIN": admission webhook "validate.kyverno.svc-fail" denied the request:

resource Pod/clearledger/root-test was blocked due to the following policies

disallow-privilege-escalation:
  check-allowPrivilegeEscalation: 'validation error: allowPrivilegeEscalation must
    be set to false. rule check-allowPrivilegeEscalation failed at path /spec/containers/0/securityContext/'
disallow-root-containers:
  check-runAsNonRoot: |-
    validation error: Root containers are blocked in the clearledger namespace. Set securityContext.runAsNonRoot: true on the pod or container.
    . rule check-runAsNonRoot failed at path /spec/containers/0/securityContext/
drop-all-capabilities:
  check-capabilities: 'validation error: All containers must drop ALL capabilities.
    rule check-capabilities failed at path /spec/containers/0/securityContext/'
require-resource-limits:
  check-resources: 'validation error: Resource requests and limits are required for
    all containers. rule check-resources failed at path /spec/containers/0/resources/limits/'

اس آؤٹ پٹ کو کیسے پڑھیں:

اہم لائنیں ہیں:

resource Pod/clearledger/root-test was blocked due to the following policies

اس کا مطلب یہ ہے کہ کیورنو نے پوڈ کو بننے سے پہلے ہی روک دیا۔

اس لائن کے نیچے، Kyverno ان تمام پالیسیوں کی فہرست دیتا ہے جن کے ساتھ پوڈ ناکام ہوا۔ مثال کے طور پر:

disallow-root-containers:
  check-runAsNonRoot:

اس کا مطلب ہے کہ پوڈ ناکام ہو گیا ہے۔ disallow-root-containers پالیسی، خاص طور پر check-runAsNonRoot حکمرانی تبدیلیاں بھی پیغام میں نظر آئیں گی۔

Set securityContext.runAsNonRoot: true

یہی طرز دیگر پالیسیوں پر بھی لاگو ہوتا ہے۔

• disallow-privilege-escalation اس کا مطلب ہے کہ پوڈ سیٹ اپ نہیں ہے۔ allowPrivilegeEscalation: false

• drop-all-capabilities اس کا مطلب ہے کہ پوڈز نے لینکس کی درج ذیل خصوصیات کو نہیں چھوڑا ہے۔ capabilities.drop: [ALL]

• require-resource-limits اس کا مطلب ہے کہ پوڈ نے کوئی سی پی یو اور میموری کی درخواستیں/حدیں متعین نہیں کی ہیں۔

کہ path حصہ Kubernetes کو بتاتا ہے کہ اسے کہاں گم شدہ ترتیبات کی توقع تھی۔ مثال کے طور پر، /spec/containers/0/securityContext/ مطلب: پھلی کی قیاس کے اندر دیکھو، پھر پہلے کنٹینر، پھر securityContext.

اور /spec/containers/0/resources/limits/ مطلب: پہلے کنٹینر کے وسائل کی حدود کو دیکھیں۔

تو یہ ایک برا پوڈ ایک ہی وقت میں چار کنٹرولوں میں ناکام رہا۔ یہ سبق ہے۔ Kyverno صرف "نہیں" نہیں کہتے ہیں۔ یہ آپ کو بتاتا ہے کہ کون سی پالیسی ناکام ہوئی اور YAML کو کہاں ٹھیک کرنا ہے۔

اس بات کو یقینی بنائیں کہ عمل درآمد مناسب طریقے سے کیا گیا ہے۔

kubectl get pod root-test -n clearledger
# Error from server (NotFound): pods "root-test" not found

جب آپ ایک پھلی دیکھتے ہیں۔ Running یا Pendingپالیسی پر عمل درآمد نہیں ہوتا۔ براہ کرم دوبارہ چیک کریں۔ kubectl get clusterpolicy پانچوں کو دکھائیں۔ READY: True.

اسکرین شاٹ لیں۔ یہ CIS Kubernetes بینچ مارک 5.2.6 کے خلاف پورٹ فولیو ثبوت ہے۔ یہ صرف تعمیر نہیں ہے، یہ عمل درآمد ہے.

منظر نامہ 2: وسائل کی حدیں غائب ہیں۔

کیا نقل کیا جا رہا ہے: میں ایک ڈویلپر ہوں جس نے securityContext کی ضروریات کو پڑھا اور روٹ/کیپٹلائزیشن/اجازت میں ترمیم کی۔ تاہم، وسائل کی حدود کو چھوڑ دیا گیا تھا۔

یہ حقیقی ٹیموں میں ایک عام واقعہ ہے۔ آپ نے "کنٹینر کو سخت کیا" لیکن CPU/میموری کی حد بھول گئے۔

اس منشور میں کیا حرج ہے؟ securityContext یہ سچ ہے لیکن یہ وہاں نہیں ہے۔ resources.requests یا resources.limits. غیر پابند کنٹینرز نوڈ پر دوسرے کام کے بوجھ میں خلل ڈال سکتے ہیں۔

cat <

آپ کو کیا دیکھنا چاہئے:

Error from server: error when creating "STDIN": admission webhook "validate.kyverno.svc-fail" denied the request:

resource Pod/clearledger/nolimits-test was blocked due to the following policies

require-resource-limits:
  check-resources: 'validation error: Resource requests and limits are required for
    all containers. rule check-resources failed at path /spec/containers/0/resources/limits/'

اہم مشاہدات: اس بار صرف ایک پالیسی چلائی گئی ہے۔ SecurityContext فیلڈ نے دیگر چار اصولوں کو پورا کیا۔ Kyverno آزادانہ طور پر قوانین کا جائزہ لیتا ہے۔ ہر کنٹینر پراپرٹی ایک علیحدہ گیٹ ہے۔

چیک کریں:

kubectl get pod nolimits-test -n clearledger
# Error from server (NotFound): pods "nolimits-test" not found

منظر نامہ 3: غیر دستخط شدہ ClearLedger تصویر

کیا نقل کیا جا رہا ہے: سپلائی چین اٹیک: کوئی آپ کے ذخیرے کے نام کے تحت ایک بدنیتی پر مبنی تصویر کو ڈوکر ہب پر دھکیلتا ہے (clearledger-auth-service) کاسائن سائننگ مرحلہ 3 میں دستخط شدہ CI پائپ لائن سے گزرے بغیر ممکن ہوا، اور مرحلہ 4 میں کلسٹر گیٹ پر لازمی ہو گیا۔

آپ کو اس ترتیب کی ضرورت کیوں ہے: Kyverno Docker Hub پر موجود تصویر کے خلاف تصویری دستخطوں کی تصدیق کرتا ہے، آپ کے لیپ ٹاپ پر موجود تصویر کے خلاف نہیں۔ سب سے پہلے، آپ کا ٹیسٹ امیج ٹیگ Docker Hub میں موجود ہونا چاہیے۔

اگر آپ جعلی ٹیگ استعمال کرتے ہیں جیسے: :unsigned اگر اسے آگے نہیں بڑھایا جاتا ہے تو، کبرنیٹس بعد میں ناکام ہو سکتے ہیں۔ ImagePullBackOff. اس کا مطلب صرف یہ ہے کہ تصویر کو درآمد نہیں کیا جا سکتا۔ اس سے یہ ثابت نہیں ہوتا ہے کہ Kyverno نے غیر دستخط شدہ تصاویر کو بلاک کیا ہے۔

مرحلہ 1: جان بوجھ کر بغیر دستخط شدہ ٹیسٹ امیج کو دبائیں (ایک بار):

export DOCKER_USERNAME=your-dockerhub-username

docker pull nginx:alpine
docker tag nginx:alpine ${DOCKER_USERNAME}/clearledger-auth-service:unsigned-test
docker push ${DOCKER_USERNAME}/clearledger-auth-service:unsigned-test

# Must fail — proves the image has no Cosign signature from your pipeline key:
cosign verify --key infra/cosign.pub 
  index.docker.io/${DOCKER_USERNAME}/clearledger-auth-service:unsigned-test
# Error: no signatures found

مرحلہ 2: ایک مطابقت پذیر Pod تفصیلات کا استعمال کرتے ہوئے تعینات کرنے کی کوشش کریں۔

پوڈ مینی فیسٹ مکمل طور پر سخت ہے (securityContext + restrictions)، اس لیے صرف دستخط کرنے کی پالیسی ناکام ہو سکتی ہے۔ استعمال کریں index.docker.io/ تصویری URL: Kyverno 1.12 سے؛ docker.io/... متحرک نہیں ہو سکتا verifyImages ملاپ

cat <

آپ کو کیا دیکھنا چاہئے:

Error from server: error when creating "STDIN": admission webhook "mutate.kyverno.svc-fail" denied the request:

resource Pod/clearledger/unsigned-test was blocked due to the following policies

require-signed-images:
  verify-cosign-signature: 'failed to verify image index.docker.io/veeno-demo/clearledger-auth-service:unsigned-test:
    .attestors[0].entries[0].keys: no signatures found'

اس آؤٹ پٹ کو کیسے پڑھیں:

• ویب ہک کا نام ہے: mutate.kyverno.svc-failنہیں validate: تصویر کی توثیق پوڈ کی منظوری سے پہلے Kyverno کے mutate پاس (ڈائجسٹ + دستخطی تصدیق) پر چلائی جاتی ہے۔

• no signatures found اس کا مطلب ہے کہ Kyverno Docker Hub پہنچا، تصویر ملی، اور تصدیق کی کہ یہ صحیح تصویر ہے۔ ~ نہیں آپ کے ساتھ دستخط کریں infra/cosign.pub کلید

• فورڈ موجود نہیں ہے۔ یہاں تک کہ اگر تصویر کھینچی جا سکتی ہے، حملہ آور گولہ حاصل نہیں کر سکتا۔

چیک کریں:

kubectl get pod unsigned-test -n clearledger
# Error from server (NotFound): pods "unsigned-test" not found

کیا نہیں دیکھنا ہے۔ (اس کا مطلب ہے کہ ٹیسٹ نے دستخط کے نفاذ کا مظاہرہ نہیں کیا):

علامت	کیا غلط ہے؟
پھلی بننے کے بعد ImagePullBackOff	Docker Hub میں کوئی ٹیگ نہیں ہیں۔ پہلے مرحلہ 1 مکمل کریں۔
پھلی بنائی گئی ہے۔ Running	تصویر استعمال کی گئی۔ docker.io/... اس کے بجائے index.docker.io/...
نہیں require-signed-images غلطی سے	پالیسی لاگو نہیں ہوتی ہے یا cosign.pub YAML پالیسی میں شامل نہیں ہے۔

کنٹراسٹ: دستخط شدہ تصاویر قابل قبول ہیں۔

پچھلے ٹیسٹوں میں، Kyverno نے انہیں بلاک کر دیا کیونکہ انہوں نے غیر دستخط شدہ تصاویر استعمال کیں۔

اصل ClearLedger امیج پر CI پائپ لائن کے ذریعے دستخط ہونا ضروری ہے۔ اگر پوڈ بھی حفاظتی اصولوں کی تعمیل کرتا ہے، تو Kyverno پوڈ کو چلانے کی اجازت دے گا۔

آپ فی الحال زیر استعمال تصویر کو چیک کر سکتے ہیں۔ auth-service:

# Your deployed tag (signed in CI) should start if spec is compliant:
kubectl get deployment auth-service -n clearledger 
  -o jsonpath="{.spec.template.spec.containers[0].image}"
# docker.io/veeno-demo/clearledger-auth-service:v0.1.0

مثال آؤٹ پٹ:

docker.io/veeno-demo/clearledger-auth-service:v0.1.0

جو پوڈز پالیسی لاگو ہونے سے پہلے ہی چل رہے تھے وہ چلتے رہیں گے۔ اہم امتحان یہ ہے کہ جب Kubernetes ایک نئی پوڈ بناتا ہے تو کیا ہوتا ہے۔ دستخط شدہ ClearLedger امیجز استعمال کرنے والے نئے پوڈز کو Kyverno تصدیق پاس کرنا ضروری ہے۔

سیناریو 3 مسترد ہونے کا اسکرین شاٹ لیں۔ اس سے ثابت ہوتا ہے کہ کلسٹر بلاکس نہ صرف CI کی دستخط شدہ تصاویر بلکہ غیر دستخط شدہ تصاویر کو بھی روکتا ہے۔

4.5: چیک کریں کہ آیا ClearLedger اب بھی کام کرتا ہے۔

Kyverno ایک نئی پوڈ کی تخلیق کو نافذ کرتا ہے۔ موجودہ تعیناتیاں جو پہلے ہی منظوری پاس کر چکی ہیں (یا پالیسی کے موجود ہونے سے پہلے مطابقت پذیر ہو چکی ہیں) چلتی رہیں گی۔ چیک کریں کہ آیا ایپ پوڈ صحت مند ہے۔

kubectl get pods -n clearledger

NAME                                    READY   STATUS    RESTARTS   AGE
auth-service-...                        1/1     Running   0          ...
frontend-...                            1/1     Running   0          ...
ledger-service-...                      1/1     Running   0          ...
notification-service-...                1/1     Running   0          ...
postgres-0                              1/1     Running   0          ...
redis-...                               1/1     Running   0          ...

اگر استقبالیہ ترتیب دیا گیا ہے:

curl -s http://clearledger.local/auth/health | jq .
# {"status": "ok", "service": "auth-service"}

آپ کو اب بھی ArgoCD دیکھنا چاہیے۔ مطابقت پذیر اور صحت مند: GitOps اور داخلہ کنٹرول مل کر کام کرتے ہیں، ایک دوسرے کے خلاف نہیں۔

4.6: پالیسی مستثنیات (جب جائز کام کے بوجھ کو بائی پاس کی ضرورت ہوتی ہے)

Kyverno اس کی پالیسیوں کی خلاف ورزی کرنے والے کسی بھی پوڈ کو روکتا ہے۔ لیکن کیا ہوتا ہے جب ایک جائز کام کے بوجھ کو کچھ اصولوں کو نظرانداز کرنے کی ضرورت ہوتی ہے؟

PostgreSQL ایک مثال ہے۔ آفیشل پوسٹگریس الپائن امیج ڈیٹا ڈائرکٹری کو منظم کرنے کے لیے ایک مخصوص اندرونی صارف (UID 70) کا استعمال کرتی ہے۔ کہ disallow-root-containers تمام پوڈز کو پالیسی کے مطابق ترتیب دیا جانا چاہیے۔ runAsNonRoot: true.

پوسٹگریس آپ کے لیے اسے ترتیب دیتا ہے۔ تاہم، اگر Kyverno کو مخصوص UID رینجز کی جانچ کرنے کے لیے بھی ترتیب دیا گیا ہے، یا اگر پوڈ کا سیکیورٹی سیاق و سباق کسی بھی وجہ سے قواعد پر پورا نہیں اترتا ہے، تو Kyverno اسے روک دے گا۔ ڈیٹا بیس شروع نہیں کیا جا سکتا اور پوری ایپلیکیشن ناکام ہو جاتی ہے۔

آپ ایک ڈیٹا بیس کو ایڈجسٹ کرنے کے لیے کلسٹر میں پالیسیوں کو کمزور نہیں کر سکتے۔ یہ کسی بھی پوڈ کو اصول کو نظرانداز کرنے کی اجازت دے گا۔ اس کے بجائے پالیسی استثناء: بالکل مطلوبہ پوڈ کے لیے ہدفی استثناء۔

کھلا infra/policies/exceptions/postgres-root-exception.yaml اور کمنٹس پڑھیں۔ ہر سیکشن کا کردار درج ذیل ہے:

کہ spec.exceptions بلاک بائی پاس کرنے کے لیے پالیسیوں اور قواعد کی شناخت کریں۔

exceptions:
  - policyName: disallow-root-containers
    ruleNames:
      - check-runAsNonRoot

دوسرے الفاظ میں، "بس اسے چھوڑ دیں۔ check-runAsNonRoot سے حکمرانی disallow-root-containers پالیسی۔ اس پالیسی کے دیگر تمام قواعد (اور کلسٹر میں دیگر تمام پالیسیاں) اب بھی معمول کے مطابق لاگو ہوں گے۔

کہ spec.match بلاک ان وسائل کو محدود کریں جن پر مستثنیات واقع ہوں۔

match:
  any:
    - resources:
        kinds:
          - Pod
        namespaces:
          - clearledger
        names:
          - postgres-*

صرف نام کی پھلیاں postgres-* (مماثل postgres-0, postgres-1وغیرہ) clearledger صرف نام کی جگہ کے لیے Pod وسائل کی قسم۔ کلسٹر میں باقی سب کچھ اب بھی سخت پالیسی پر عمل پیرا ہے۔

تشریح آپ کی ٹیم اور آڈیٹرز کے لیے کچھ دستاویزات یہ ہیں:

annotations:
  reason: "Postgres alpine image requires UID 70 for data directory ownership"
  approved-by: "platform-team"
  review-date: "2026-01-01"

کوئی تکنیکی اثر نہیں ہے۔ Kyverno اس کو نظر انداز کرتا ہے۔ یہ اس لیے ہے کہ اب سے چھ ماہ بعد، اگر کوئی پوچھے کہ "پوسٹگریس اس اصول کو کیوں نظرانداز کر رہا ہے؟"، تو جواب فائل پر موجود ہوگا۔

محفوظ استثناء کے قواعد:

1. تنگ کریں: اپنی ضرورت کے عین مطابق وسائل کو نشانہ بنائیں۔ اس سے زیادہ نہیں۔

2. Git کا عہد کریں۔: مستثنیات کا پل کی درخواست میں جائزہ لیا جاتا ہے، ورژن کی تاریخ میں ٹریک کیا جاتا ہے، اور قابل سماعت ہیں۔

3. خود پالیسی کو کمزور نہ کریں۔: باقی تمام چیزوں کے لیے قوانین کو سختی سے برقرار رکھا جاتا ہے۔

4. باقاعدگی سے جائزہ لیں۔: جب بھی ممکن ہو مستثنیات عارضی ہوں اور شیڈول کے مطابق ان کا دوبارہ جائزہ لیا جائے۔

مستثنیات لاگو ہوتے ہیں۔ صرف اگر Kyverno بلاکس Postgres pods.

kubectl apply -f infra/policies/exceptions/postgres-root-exception.yaml

تصدیق کریں کہ Kyverno اب بھی دیگر غیر تعمیل پوڈز کو روکتا ہے (منظر 1 کی طرح مسترد)۔

cat <

4.7: CIS بینچ مارک ثبوت kube-bench)

ہم پہلے ہی Kyverno انسٹال کر چکے ہیں اور ثابت کر چکے ہیں کہ یہ غیر محفوظ پوڈز کو روکتا ہے۔

یہ مرحلہ مختلف ہے۔ kube-bench یہ کسی بھی پوڈ کو بلاک نہیں کرتا اور کلسٹر کو تبدیل نہیں کرتا ہے۔ CIS بینچ مارکس کے خلاف صرف Kubernetes نوڈس کی جانچ کی جاتی ہے اور ثبوت محفوظ کیے جاتے ہیں۔

مندرجہ ذیل اختلافات پر غور کریں:

سامان	معائنہ کا مواد	آپ کے سوالات کے جوابات
کیبرنو	پھلی اور کام کا بوجھ	"کیا میں اس پوڈ کو چلا سکتا ہوں؟"
کیوب بینچ	Kubernetes نوڈس ترتیب دینا	"کیا یہ کبرنیٹس نوڈس سخت ہیں؟"

دونوں مفید ہیں، لیکن اس لیب میں صرف Kyverno کام کے بوجھ کو روکتا ہے۔

کیوب بینچ چلائیں۔

bash stages/stage-4-admission-control/scripts/run-kube-bench.sh

اسکرپٹ kube-bench کو Kubernetes ٹاسک کے طور پر چلاتا ہے اور وہاں رپورٹس اسٹور کرتا ہے۔

stages/stage-4-admission-control/scripts/kube-bench-report.json

ہم اپنے نتائج کا اس بیس لائن سے بھی موازنہ کرتے ہیں۔

stages/stage-4-admission-control/scripts/kube-bench-baseline.json

مائیکرو کے 8 میں دیکھنے کے لیے بہت کچھ ہے۔ FAIL اور WARN سموچ اس کی توقع ہے۔ لیب آپ کو سنگل نوڈ مقامی VMs پر تمام CIS انتباہات کو ٹھیک کرنے کی ضرورت نہیں ہے۔

جو چیز اہم ہے وہ حتمی نتیجہ ہے۔

پاسز درج ذیل ہیں:

kube-bench: 1 FAIL control(s) present (documented in baseline — no regressions).
kube-bench: no regressions vs baseline.

اس کا مطلب ہے کہ مائیکرو کے 8 کے معلوم مسائل کو دستاویزی شکل دی گئی ہے اور کلسٹر مزید خراب نہیں ہوا ہے۔

اگر آپ دیکھتے ہیں REGRESSION یا make check-4 اگر کیوب بینچ ناکام ہوجاتا ہے، تو روکیں اور مرحلہ 5 سے پہلے تحقیق کریں۔

اختیاری: تصدیق کریں کہ رپورٹ فائل موجود ہے۔

ls -la stages/stage-4-admission-control/scripts/kube-bench-report.json

پیداوار CIS کی غلطیوں یا دستاویزات سے منظور شدہ مستثنیات کو درست کرتی ہے۔ اس لیب میں، بیس لائن متوقع مائیکرو کے 8 کی حالت کو ریکارڈ کرتی ہے۔

4.8: اسٹیٹس چیک

make check-4

آپ کو کیا دیکھنا چاہئے:

▶ Stage 4 — Admission Control (Kyverno)
  ✓ Kyverno is running
  ✓ Policy disallow-root-containers — Enforce mode
  ✓ Policy require-resource-limits — Enforce mode
  ✓ Policy require-signed-images — Enforce mode
  ✓ Policy disallow-privilege-escalation — Enforce mode
  ✓ Policy drop-all-capabilities — Enforce mode
  ✓ Kyverno correctly rejects pods without securityContext
  ✓ kube-bench baseline exists (...)

All checks passed. Ready for the next stage.

اگر کیوب بینچ رجعت کی اطلاع دیتا ہے تو دستی طور پر اسکرپٹ کو چلائیں، جائزہ لیں اور بیس لائن کو اپ ڈیٹ کریں۔ فرق آڈٹ ثبوت کا ہے۔

اگر آپ Kyverno انسٹال کر رہے ہیں، تو آپ کو پالیسیوں، بندش کے حالات، یا make check-4 اگر یہ ناکام ہو جاتا ہے تو، Troubleshooting.md دیکھیں۔ مرحلہ 4۔

مرحلہ 4 مکمل ہوا: تکمیلی چیک لسٹ (مرحلہ 5 پر جائیں)

تم ہو مرحلہ 4 تک مکمل کریں۔ جب یہ سب سچ ہے:

#	چیک کریں	چیک کرنے کا طریقہ
1	Kyberno چل رہا ہے	kubectl get pods -n kyverno - 4 کنٹرولرز Running
2	لاگو پالیسی	kubectl get clusterpolicy - پانچ پالیسیاں؛ READY: True, Enforce
3	روٹ پوڈ مسدود ہے۔	ٹرمینل میں منظر نامے 1 کو مسترد کریں (پورٹ فولیو اسکرین شاٹ)
4	غیر دستخط شدہ تصاویر مسدود ہیں۔	منظر 3 مسترد - دھکا unsigned-test پہلے اسے ٹیگ کریں اور پھر استعمال کریں۔ index.docker.io/
5	ایپ اب بھی صحت مند ہے۔	kubectl get pods -n clearledger - تمام ایپ پوڈز Running
6	صحت کی جانچ سبز	make check-4 کے ساتھ ختم ہوتا ہے All checks passed. Ready for the next stage.

پورٹ فولیو اسکرین شاٹ (اختیاری): روٹ پوڈز کو مسترد کریں (§4.4 منظر نامہ 1)، غیر دستخط شدہ تصاویر کو مسترد کریں (§4.4 منظر نامہ 3) kubectl get clusterpolicy دکھائیں 5 Enforce پالیسی

ابھی تک نہیں: SLSA تصدیق (اختیاری)، والٹ سیکریٹ (مرحلہ 5)، نیٹ ورک پالیسی (مرحلہ 6)۔ پاس ورڈ اب بھی Kubernetes Secrets میں ہے۔ مرحلہ 5 آپ کو والٹ پر لے جاتا ہے۔

آپ نے مرحلہ 4 میں کیا سیکھا۔

• CI اسکیننگ (پری مرج) اور داخلہ کنٹرول (کلسٹر گیٹ پر) کے درمیان فرق

• Kyverno کیا ہے: ایک پالیسی انجن جو تمام Kubernetes API درخواستوں کو روکتا ہے؟

• اس نفاذ کا مطلب ہے کہ ناقص وسیلہ موجود نہیں ہے اور یہ "حقیقت کے بعد" دریافت نہیں ہے۔

• Kyverno انکار کو کیسے پڑھیں: پالیسی کا نام → اصول کا نام → JSON راستہ جو ناکام ہوگیا۔

• YAML میں کلسٹر وائیڈ سیکیورٹی پالیسیاں کیسے لکھیں اور نافذ کریں۔

• ہر کسی کے لیے پالیسی کو کمزور کیے بغیر PolicyException کا دائرہ کار کیسے بنایا جائے۔

• آپریشنل مسائل (ہیلم، امیج امپورٹ، رجسٹری یو آر ایل فارمیٹ) اس بات پر اثر انداز ہوتے ہیں کہ آیا کنٹرول واقعی چلتا ہے۔

• آپ کو CI اور داخلہ کنٹرول دونوں کی ضرورت کیوں ہے: CI آپ کے کوڈ میں مسائل کو پکڑتا ہے، اور Kyverno ہر وہ چیز پکڑتا ہے جو آپ کے کلسٹر کو چھوتی ہے۔

• ثبوت ٹرمپ کی تعمیر: گٹ کی پالیسی فائلوں کا کوئی مطلب نہیں ہے۔ مداخلت کی تردید اس بات کا ثبوت ہے کہ CIS کنٹرولز موجود ہیں، نہ صرف دستاویزی۔

اب آپ اپنے تجربے کی فہرست میں کیا ڈال سکتے ہیں/ایک انٹرویو میں کہہ سکتے ہیں:

Kyverno کے ساتھ لاگو داخلہ کنٹرول: روٹ کنٹینرز کو مسدود کرنا، مراعات کو بڑھانا، غیر دستخط شدہ امیجز غائب کرنا، اور تعیناتی پر وسائل کی حدود: CIS Kubernetes بینچ مارکس پر نقشہ لگانا۔

make snapshot STAGE=4 && make snapshots. چیک کریں clearledger.stage4. دیکھیں کہ اپنی ترقی کو کیسے بچایا جائے۔

مرحلہ 5: خفیہ انتظام (والٹ)

اس قدم کے بعد، حساس قدر Git یا etcd کی حمایت یافتہ Kubernetes Secret میں مزید موجود نہیں رہے گی۔ والٹ ان اقدار کو مرکزی طور پر رکھتا ہے اور انہیں Pod میں صرف اس وقت داخل کرتا ہے جب یہ شروع ہوتا ہے۔

آپ کے مقاصد: ہٹا دیں auth-service-secret اور ledger-service-secret جھرمٹ میں۔

Vault پوڈ اسٹارٹ اپ پر اسناد کو انجیکشن کرتا ہے، لہذا لاگ ان اور API کالز کو کام کرنا جاری رکھنا چاہیے۔ اس وقت جب خفیہ انتظام کلک کرتا ہے۔

اس سے پہلے کہ آپ شروع کریں۔یقینی بنائیں کہ مرحلہ 4 ٹھوس ہے۔ make check-4 منظور ہونے پر، تمام پانچ Kyverno پالیسیاں نافذ ہو جائیں گی اور ایپ اس کے ساتھ جواب دے گی: http://clearledger.local. والٹ انسٹال کرنے سے پہلے کریش ہونے والے ریپیٹ پوڈز کو درست کریں۔

اس مرحلے پر کیا تبدیلیاں آتی ہیں؟

موجودہ ڈیٹا بیس پاس ورڈ اور JWT کلید ہیں۔ secret.yaml GitHub پر اور آپ کے کلسٹر کے اندر Kubernetes Secrets میں فائلیں۔ مرحلہ 5 میں، قدر ہے۔ ہاشی کارپ والٹ ایپ آپ کو مختلف طریقے سے پڑھنا سکھا سکتی ہے۔

جب تصدیق یا لیجر پوڈ شروع ہوتا ہے۔ بولٹ ایجنٹ انجیکٹر ایک چھوٹا سا سائیڈ کار کنٹینر شامل کریں۔ سائڈ کار والٹ میں لاگ ان کرنے کے لیے پوڈ کا اپنا سروس اکاؤنٹ استعمال کرتا ہے، پاس ورڈ اور JWT لیتا ہے، اور انہیں نیچے کی فائل میں لکھتا ہے۔ /vault/secrets/.

ایپ پہلے ہی جانتی ہے کہ اس راستے کو کیسے پڑھنا ہے۔ یہ وہی ڈیٹا ہے جو کے ذریعے پہنچا ہے۔ secretKeyRefاسے Kubernetes سیکریٹ آبجیکٹ سے بازیافت کرنے کے بجائے رن ٹائم پر منتقل کیا جاتا ہے۔

منتقلی مکمل ہونے کے بعد حساس اقدار کو محفوظ کر لیا جاتا ہے۔ والٹ (طویل مدتی سٹور) مختصر طور پر وضاحت کی. پوڈ فائل سسٹم جبکہ کنٹینر چل رہا ہے۔ وہ اب گٹ میں نہیں ہیں۔ آپ ہٹا دیں secret.yaml سے clearledger-infra ArgoCD تقسیم کی مطابقت پذیری کرتا ہے جو اس کے بجائے والٹ کی طرف اشارہ کرتی ہے۔

پہلی بار Vault لوڈ کرنے کے لیے، ٹیمپلیٹ کو مقامی طور پر کاپی کریں۔ .env فائلیں (§5.1)۔ ان فائلوں کو نظر انداز کر دیا جائے گا۔ تم دوڑو seed-vault-secrets.sh اگر آپ اس قدر کو والٹ میں کاپی کرنا چاہتے ہیں، تو آپ کو اسے صرف ایک بار کرنے کی ضرورت ہے۔

اصل خفیہ قدر کمٹڈ اسکرپٹ پر نہیں لکھی جاتی ہے۔ سکرپٹ مقامی طور پر راز کو پڑھتا ہے۔ .env یہ فائل یا ٹرمینل میں محفوظ ہے، لہذا آپ کا پاس ورڈ اور ٹوکن گٹ میں نہیں جاتے ہیں۔

اس ترتیب میں اقدامات پر عمل کریں:

ہر قدم پچھلے مرحلے پر منحصر ہے۔ سرخ توثیق/لیجر پوڈ حاصل کرنے کا سب سے عام طریقہ آگے بڑھانا ہے جو کہ سمجھوتہ شدہ ایپ کی طرح لگتا ہے لیکن اس کا اصل مطلب ہے "والٹ ابھی تیار نہیں ہے"۔

1. §5.1: نقل stages/stage-5-secrets-management/.env.example کو .envاپنا کلسٹر پاس ورڈ درج کریں۔

2. §5.2: ہیلم کا استعمال کرتے ہوئے والٹ اور ایجنٹ انجیکٹر انسٹال کریں۔

3. §5.3. چلائیں setup.shپھر seed-vault-secrets.sh (پاس ورڈ اب والٹ میں ہے)

4. §5.4: والٹ کے قابل تعیناتی کو اس پر پش کریں: clearledger-infra. اپنے ArgoCD کو ہم آہنگ کریں۔

5. §5.5. انتظار کرو 2/2 Pod (app + Vault sidecar) کو حذف کرنے کے بعد، پرانے Kubernetes Secrets کو حذف کر دیں۔

6. §5.5b: ArgoCD مطابقت پذیر / ٹھیک ہے۔ (راز کو حذف کرنے کے بعد۔ حذف کرنے سے پہلے OutOfSync معمول کی بات ہے)

7. §5.6. ایک بار جب آپ تصدیق کر لیتے ہیں کہ آپ کا لاگ ان کام کر رہا ہے، آپ کی اسناد نیچے ظاہر ہوں گی۔ /vault/secrets/ پھلی کا داخلہ

وقت شروع §5.1. اگر آپ کے پاس کوئی ناکامی ہے، تو انہیں پڑھیں. troubleshooting.md. مینی فیسٹ کو تبدیل کرنے سے پہلے۔

5.1: تخلیق .env (صرف مقامی، کوئی عہد نہیں)

اس فائل میں دو آئٹمز ہیں: ہیلم (§5.2) کے لیے ڈیولپر والٹ روٹ ٹوکن اور §5.3 میں والٹ میں لوڈ کرنے کے لیے پاس ورڈ۔

یہ صرف آپ کے کمپیوٹر پر رہتا ہے۔ کبھی عہد نہ کریں۔ کہ SEED_* قدر اس سے مماثل ہونی چاہیے جو آپ کی ایپ فی الحال استعمال کرتی ہے تاکہ سائن ان کام کرتا رہے چاہے آپ بعد میں Kubernetes Secret کو حذف کر دیں۔

دو مختلف فائلیں۔ الجھن میں نہ پڑو۔

فائل	یہ کیا ہے
stages/stage-5-secrets-management/.env.example	اسے اپنے ریپوزٹری میں خالی ٹیمپلیٹ (خالی فیلڈز) کے مرحلہ 1 سے کاپی کریں۔
stages/stage-5-secrets-management/.env	یہ آپ کی اصل فائل ہے (gitignored)۔ مرحلہ 2 اور 3 میں بنائیں اور آباد کریں۔

اس سیکشن کے نچلے حصے میں نمونے کے بلاکس صرف اس کی مثالیں ہیں جو کیا گیا ہے۔ .env یہ مندرجہ ذیل ہے: پلیس ہولڈر پاس ورڈ کاپی نہ کریں جب تک کہ یہ آپ کے کلسٹر سے مماثل نہ ہو۔

مرحلہ 1: ٹیمپلیٹ کو درج ذیل مقام پر کاپی کریں: .env

cp stages/stage-5-secrets-management/.env.example 
   stages/stage-5-secrets-management/.env

یہ آپ کو ایک خالی فائل دے گا۔ VAULT_TOKEN= اور SEED_*= سموچ اسے ایڈیٹر میں 2 اور 3 مراحل کے لیے کھولیں۔

مرحلہ 2: کلسٹر سے موجودہ پاس ورڈ پڑھیں

اسے ریپو روٹ سے چلائیں۔ ہر کمانڈ ایک قدر پرنٹ کرتا ہے۔ آؤٹ پٹ کو درج ذیل مقام پر کاپی کریں: .env مرحلہ 3 میں۔

# → paste as SEED_AUTH_DATABASE_URL
kubectl get secret auth-service-secret -n clearledger 
  -o jsonpath="{.data.database_url}" | base64 -d; echo

# → paste as SEED_AUTH_JWT_SECRET
kubectl get secret auth-service-secret -n clearledger 
  -o jsonpath="{.data.jwt_secret}" | base64 -d; echo

# → paste as SEED_LEDGER_DATABASE_URL
kubectl get secret ledger-service-secret -n clearledger 
  -o jsonpath="{.data.database_url}" | base64 -d; echo

مرحلہ 3: لکھیں۔ .env

متغیر	میں اس میں کیا ڈالوں؟
VAULT_TOKEN	آپ کی پسند کی صرف ترقی کی تار، جیسے my-dev-root-token): §5.2 ہیلم کی تنصیب جیسی قدر
SEED_AUTH_DATABASE_URL	اوپر کی پہلی کمانڈ کا آؤٹ پٹ
SEED_AUTH_JWT_SECRET	دوسری کمانڈ کا آؤٹ پٹ
SEED_LEDGER_DATABASE_URL	تیسری کمانڈ کا آؤٹ پٹ

صرف نمونہ: مکمل شکل .env (جب تک وہ مماثل نہ ہوں، ان مثال کے تاروں کے بجائے مرحلہ 2 سے kubectl آؤٹ پٹ استعمال کریں):

VAULT_TOKEN=my-dev-root-token
SEED_AUTH_DATABASE_URL=postgresql://clearledger:changeme-stage0@postgres:5432/clearledger
SEED_AUTH_JWT_SECRET=stage0-jwt-secret-change-in-production
SEED_LEDGER_DATABASE_URL=postgresql://clearledger:changeme-stage0@postgres:5432/clearledger

اگر auth-service-secret اسے پہلے ہی حذف کر دیا گیا ہے (آگے چھوڑ دیا گیا، مندرجہ ذیل کے طور پر بازیافت کریں)۔

# Database URL from Postgres bootstrap secret (lab default password is often changeme-stage0)
PG_PASS=$(kubectl get secret postgres-secret -n clearledger 
  -o jsonpath="{.data.password}" | base64 -d)
echo "postgresql://clearledger:${PG_PASS}@postgres:5432/clearledger"
# Use that line for both SEED_AUTH_DATABASE_URL and SEED_LEDGER_DATABASE_URL

# JWT: same value you used at Stage 0, or read from Vault if you already seeded:
kubectl exec -n vault vault-0 -- vault kv get -field=jwt_secret clearledger/auth-service 2>/dev/null 
  || echo "(set SEED_AUTH_JWT_SECRET manually — must match tokens already issued)"

جاری رکھیں §5.2 ایک بار .env تمام چار متغیرات سیٹ ہیں۔

5.2: والٹ اور ایجنٹ انجیکٹر کی تنصیب

set -a && source stages/stage-5-secrets-management/.env && set +a

helm repo add hashicorp https://helm.releases.hashicorp.com && helm repo update

# First install:
helm install vault hashicorp/vault 
  --namespace vault --create-namespace 
  --set server.dev.enabled=true 
  --set server.dev.devRootToken="${VAULT_TOKEN}" 
  --set ui.enabled=true 
  --set injector.enabled=true

# If helm install fails with "cannot re-use a name", use upgrade instead:
# helm upgrade --install vault hashicorp/vault 
#   --namespace vault --create-namespace 
#   --set server.dev.enabled=true 
#   --set server.dev.devRootToken="${VAULT_TOKEN}" 
#   --set ui.enabled=true 
#   --set injector.enabled=true

kubectl wait --for=condition=ready pod 
  -l app.kubernetes.io/name=vault -n vault --timeout=120s
kubectl wait --for=condition=ready pod 
  -l app.kubernetes.io/name=vault-agent-injector -n vault --timeout=120s

kubectl apply -f stages/stage-5-secrets-management/infra/vault-ingress.yaml

کھلا http://vault.local آپ کے براؤزر میں۔ درج ذیل ترتیبات کے ساتھ لاگ ان کریں: VAULT_TOKEN کو stages/stage-5-secrets-management/.env. مثال کے طور پر، آپ کے معاملے میں .env ہے VAULT_TOKEN=my-dev-root-tokenاستعمال کریں my-dev-root-token اپنے والٹ لاگ ان ٹوکن کے ساتھ۔

چیک کریں: والٹ پوڈز کی فہرست بنائیں:

kubectl get pods -n vault

توقع کریں: والٹ پوڈ:

NAME                                   READY   STATUS    RESTARTS   AGE
vault-0                                1/1     Running   0          1m
vault-agent-injector-8d6b668b4-xxxxx   1/1     Running   0          1m

اگر helm install خرابی: "نام دوبارہ استعمال نہیں کیا جا سکتا": والٹ پہلے سے انسٹال ہے۔ استعمال کریں helm upgrade --install اوپر بلاک.

5.3: والٹ کنفیگریشن (پلیٹ فارم + سیڈ KV)

دونوں اسکرپٹ کو ترتیب سے چلائیں۔ ہر ایک کو پڑھیں VAULT_TOKEN آپ کا .env.

bash stages/stage-5-secrets-management/infra/vault/setup.sh
bash stages/stage-5-secrets-management/infra/vault/seed-vault-secrets.sh

setup.sh: کلسٹر کے لیے والٹ کی تیاری: Kubernetes توثیق، KV خفیہ اسٹور، پالیسیاں اور کردار (تصدیق/لیجر پوڈز) ~ کر سکتے ہیں۔ راز بعد میں حاصل کریں۔ ہم ابھی تک ڈیٹا بیس کا پاس ورڈ نہیں لکھتے ہیں، اور گٹ کو کچھ بھی نہیں دیا گیا ہے۔

seed-vault-secrets.sh: لے لو SEED_* لائن .env اسے والٹ میں محفوظ کریں۔ clearledger/data/auth-service اور clearledger/data/ledger-service. قدر ٹرمینل میں ظاہر نہیں ہوتی ہے۔

کسی بھی اسکرپٹ کو دوبارہ چلانا مشق کے لیے محفوظ ہے۔

متوقع، setup.sh (دم):

==> Enabling Kubernetes auth method...
==> Configuring Kubernetes auth...
==> Enabling KV secrets engine...
==> Creating Vault policies...
==> Creating Kubernetes auth roles...
==> Applying RBAC + ServiceAccounts...

✓ Vault platform setup complete (no secrets written yet).
  Next: bash stages/stage-5-secrets-management/infra/vault/seed-vault-secrets.sh

متوقع، seed-vault-secrets.sh:

==> Logging into Vault...
==> Writing secrets to Vault KV (values are not printed)...
======== Secret Path ========
clearledger/data/auth-service
======= Metadata =======
Key                Value
---                -----
created_time       2026-06-01T15:31:53.538991153Z
version            1
✓ Secrets stored at clearledger/data/auth-service and clearledger/data/ledger-service

صرف میٹا ڈیٹا چیک کریں۔ (خفیہ قیمت پرنٹ نہیں ہے):

kubectl exec -n vault vault-0 -- vault kv metadata get clearledger/auth-service

Key                     Value
---                     -----
cas_required            false
created_time            2026-06-01T15:31:53.538991153Z
current_version         1
delete_version_after    0s
max_versions            0
oldest_version          0
updated_time            2026-06-01T15:31:53.538991153Z

5.4: GitOps: اپ ڈیٹ کریں۔ clearledger-infra (فکسڈ ArgoCD OutOfSync)

ArgoCD کی تقسیم کی جاتی ہے: clearledger-infra غیر طے شدہ GitHub ذخیرہ clearledger ایپ ریپوزٹری جس پر میں فی الحال کام کر رہا ہوں۔ پہلے یہاں مینی فیسٹ میں ترمیم کریں اور پھر وہی تبدیلیاں کریں۔ clearledger-infra تاکہ ArgoCD مطابقت پذیر ہو سکے۔ آہستہ سے کام کریں اور ہر ذیلی قدم کے بعد چیک کریں۔

5.4a ایپ اسٹور میں اپ ڈیٹ مینی فیسٹ (clearledger)

cp stages/stage-5-secrets-management/infra/manifests/auth-service/deployment.yaml 
   infra/manifests/auth-service/deployment.yaml

cp stages/stage-5-secrets-management/infra/manifests/ledger-service/deployment.yaml 
   infra/manifests/ledger-service/deployment.yaml

mkdir -p infra/manifests/vault

cp infra/deferred-by-stage/stage-5-secrets-management/vault/rotation-cronjob.yaml 
   infra/manifests/vault/rotation-cronjob.yaml

rm -f infra/manifests/auth-service/secret.yaml infra/manifests/ledger-service/secret.yaml

5.4b ترمیم کریں infra/manifests/kustomization.yaml ہاتھ سے

فائل کو ایڈیٹر میں کھولیں۔ پر resources: انوینٹری:

• ہٹا دیں ایپ کے راز: ان دو لائنوں کو حذف کریں یا ان کا استعمال کرتے ہوئے تبصرہ کریں: # (دونوں کام کریں گے کیونکہ کسٹمائز ان کو نظر انداز کرتا ہے۔ # سموچ):

  - auth-service/secret.yaml
  - ledger-service/secret.yaml
  

• شامل کریں یہ لائن (دیگر وسائل کے ساتھ):

  - vault/rotation-cronjob.yaml
  

چھوڑ دو postgres/postgres-secret.yamlیہ صرف پوسٹگریس بوٹسٹریپنگ کے لیے ہے، ایپ کی اسناد نہیں۔

حاصل کریں چیک کریں:

# Active (uncommented) app secret lines must be gone — postgres-secret is OK
grep -E '^[[:space:]]*-[[:space:]]+(auth-service|ledger-service)/secret.yaml' 
  infra/manifests/kustomization.yaml && echo "STOP: app secrets still active" || echo "OK"

grep vault/rotation-cronjob.yaml infra/manifests/kustomization.yaml
grep vault.hashicorp infra/manifests/auth-service/deployment.yaml | head -1
kustomize build infra/manifests >/dev/null && echo "OK: kustomize build"

متوقع: OKگھومنے والی کرون جابز درج ہیں، پہلی سطر پر ظاہر ہوتے ہیں۔ vault.hashicorp.com/agent-injectکسٹمائز کی تعمیر کامیاب رہی۔

عزم ایپ جب آپ تیار ہوں تو، ذخیرہ: git add infra/manifests && git commit -m "feat(stage-5): Vault deployments in canonical manifests".

5.4c انہی تبدیلیوں کو پش کریں: clearledger-infra

git clone https://github.com/YOUR_USERNAME/clearledger-infra.git /tmp/clearledger-infra

اگر کلون ناکام ہوجاتا ہے۔ destination path '/tmp/clearledger-infra' already exists اس فولڈر کو دوبارہ استعمال کریں (اگر آپ نے اسے §1.3 یا پچھلے مراحل میں کلون کیا ہے)۔ اسے دوبارہ نقل نہ کریں۔

cd /tmp/clearledger-infra && git pull && cd -

یا تازہ شروع کریں: rm -rf /tmp/clearledger-infra پھر دوڑو git clone دوبارہ

پھانسی cp مین سے کمانڈ clearledger ایپ اسٹورسے نہیں /tmp/clearledger-infra. آپ کا شیل پرامپٹ اس طرح نظر آنا چاہئے: clearledgerنہیں clearledger-infra. ذریعہ راستہ infra/manifests/... یہ صرف ایپ اسٹور میں موجود ہے۔

cd ~/clearledger    # main app repo — adjust path if yours differs

cp infra/manifests/auth-service/deployment.yaml /tmp/clearledger-infra/manifests/auth-service/
cp infra/manifests/ledger-service/deployment.yaml /tmp/clearledger-infra/manifests/ledger-service/
mkdir -p /tmp/clearledger-infra/manifests/vault
cp infra/manifests/vault/rotation-cronjob.yaml /tmp/clearledger-infra/manifests/vault/
cp infra/manifests/kustomization.yaml /tmp/clearledger-infra/manifests/kustomization.yaml
rm -f /tmp/clearledger-infra/manifests/auth-service/secret.yaml
rm -f /tmp/clearledger-infra/manifests/ledger-service/secret.yaml

cd /tmp/clearledger-infra
git add -A
git status
git commit -m "feat(stage-5): Vault injection; remove app secrets from GitOps"
git push
cd -

چیک پوائنٹس کی مشق کریں۔ مرحلہ 5 لینڈنگ گٹ اوپس

git clone --depth 1 https://github.com/YOUR_USERNAME/clearledger-infra.git /tmp/verify-s5
test ! -f /tmp/verify-s5/manifests/auth-service/secret.yaml && echo "OK: app secret removed from Git"
grep vault.hashicorp /tmp/verify-s5/manifests/auth-service/deployment.yaml | head -1
grep vault/rotation-cronjob.yaml /tmp/verify-s5/manifests/kustomization.yaml
rm -rf /tmp/verify-s5

متوقع: OKمیرے پاس والٹ تشریح ہے، اور کوٹومائزیشن میں سرکلر ایکشن ہے۔

متوقع، git status کمٹ کرنے سے پہلے (مرحلہ 5.4c):

modified:   manifests/auth-service/deployment.yaml
modified:   manifests/ledger-service/deployment.yaml
modified:   manifests/kustomization.yaml
new file:   manifests/vault/rotation-cronjob.yaml
deleted:    manifests/auth-service/secret.yaml
deleted:    manifests/ledger-service/secret.yaml

بعد میں git pushArgoCD خود بخود والٹ سے چلنے والی تقسیم کو جاری کرتا ہے۔ §5.5 تک جاری رکھیں. توقع نہ کرو مطابقت پذیر تاہم، ایپ کے راز اس وقت تک کلسٹر میں رہتے ہیں جب تک کہ آپ انہیں کلسٹر سے حذف نہیں کر دیتے۔

عام لانچ کی ناکامیاں:

علامت	ٹھیک کریں
Duplicate value: "vault-secrets"	کرو ~ نہیں اعلان vault-secrets حجم deployment.yaml: انجیکٹر کے ذریعہ تیار کردہ۔
Service appeared 2 times	برقرار رکھنا Service صرف میں service.yamlیہ نیچے نہیں ہے۔ deployment.yaml
کیبرنو containers/0 runAsNonRoot	شامل کریں runAsNonRoot: true کو ایپ کنٹینر securityContextہاں spec.securityContext
فورڈ رک گیا۔ 1/1 (کوئی سائڈ کار نہیں)	چیک کریں injector.enabled=true اور تقسیم کے لیے vault.hashicorp.com/agent-inject: "true"
permission denied والٹ ایجنٹ کے آغاز میں	چلائیں setup.sh : K8s کی توثیق کا کردار سروس اکاؤنٹ کا پابند نہیں ہے۔
آرگو سی ڈی مطابقت پذیری ناکام ہوگئی کو CronJob/vault-secret-rotation	Kyverno نے آپریشن کو روک دیا ہے۔ infra/manifests/vault/rotation-cronjob.yaml شامل ہونا چاہیے۔ runAsNonRoot, allowPrivilegeEscalation: false, capabilities.drop: [ALL]اور CPU/میموری کی حدود۔ اپنی ترامیم کو آگے بڑھائیں: clearledger-infra.

5.5: والٹ میں پوڈ لگائے جانے کے انتظار کے بعد K8s ایپ کے راز کو حذف کرنا

والٹ سائڈ کار کو ظاہر کرنے کے لیے تصدیق/لیجر کا انتظار کریں۔ (READY 2/2 = ایپ + والٹ ایجنٹ):

kubectl get pods -n clearledger -l app=auth-service
kubectl get pods -n clearledger -l app=ledger-service

متوقع:

NAME                            READY   STATUS    RESTARTS   AGE
auth-service-5756d9fcb9-bmdlr   2/2     Running   0          2m
auth-service-5756d9fcb9-jtgss   2/2     Running   0          2m

سائڈ کار کے ذریعے حاصل کردہ رازوں کا معائنہ کریں (کنٹینر لاگ کو شروع کریں)۔

kubectl logs -n clearledger 
  $(kubectl get pod -n clearledger -l app=auth-service -o name | head -1) 
  -c vault-agent-init
# ... Authentication successful, rendering templates ...

پھلی کے 2/2 ہونے کے بعد ہیایپ کے راز کو حذف کریں:

kubectl delete secret auth-service-secret ledger-service-secret -n clearledger

پیشین گوئیاں: باقی راز:

kubectl get secret -n clearledger

NAME              TYPE     DATA   AGE
postgres-secret   Opaque   2      6d

postgres-secret یہ صرف پوسٹگریس بوٹسٹریپنگ کے لیے ہے، ایپ کی اسناد کے لیے نہیں۔ یہ اس وقت تک اثر میں رہے گا جب تک کہ آپ پوسٹگریس کو الگ سے سخت نہیں کرتے۔

جب آپ کہتے ہیں حذف کریں۔ NotFound: راز پہلے ہی حذف کر دیا گیا ہے۔ §5.6 کے ساتھ جاری رکھیں۔

5.5b: خفیہ حذف کرنے کے بعد ArgoCD کو مطابقت پذیر ہونا چاہیے۔

§5.5 کے بعد چلائیں، §5.4 کے فوراً بعد نہیں۔ OutOfSync معمول کی بات ہے جب تک کہ آپ ایپ کے راز کو حذف نہیں کر دیتے۔ Git مزید درج نہیں ہے۔ auth-service-secret / ledger-service-secretتاہم، یہ کلسٹر میں موجود رہے گا جب تک کہ آپ اسے اوپر والے مرحلے میں حذف نہیں کر دیتے۔

kubectl get application clearledger -n argocd 
  -o jsonpath="sync={.status.sync.status} health={.status.health.status}{"n"}"

رازوں کو حذف کرنے سے پہلے: توقع sync=OutOfSync health=Healthy یا Progressing جبکہ والٹ پوڈز جاری کیے جا رہے ہیں۔ اگر آپ کے پاس سرٹیفیکیشن/لیجر ہے تو یہ ٹھیک ہے۔ 2/2.

خفیہ پیغام کو حذف کرنے کے بعدریفریش کریں اور مطابقت پذیری کریں اگر ابھی بھی آؤٹ آف سنک ہے:

kubectl annotate application clearledger -n argocd argocd.argoproj.io/refresh=hard --overwrite
argocd app sync clearledger --grpc-web --prune

اگر آپ کی مطابقت پذیری اس طرح نظر آتی ہے: دیگر کام پہلے ہی جاری ہیں۔براہ کرم ایک لمحے کے لیے انتظار کریں۔ ArgoCD آٹو سنکرونائزیشن پہلے سے چل رہی ہے۔

براہ کرم اس وقت تک انتظار کریں:

kubectl get application clearledger -n argocd 
  -o jsonpath="{.status.sync.status} {.status.health.status}{"n"}"
# Synced Healthy

اگلا، اپنی ایپ کی تقسیم کو اپ ڈیٹ نہ کریں۔ kubectl apply ArgoCD کی طرف سے منظم ہونے کے بعد. ArgoCD کلسٹرز کو اس کے ساتھ مطابقت رکھتا ہے: clearledger-infra. اگر آپ خود اپنی تقسیم کو تبدیل کرتے ہیں، تو ArgoCD اسے واپس کر سکتا ہے۔ مرحلہ 5 کے لیے، Git میں مینی فیسٹ کو اپ ڈیٹ کریں اور ArgoCD کو اپنی والٹ سے چلنے والی تعیناتی کو سنکرونائز کریں۔

5.6: لاگ ان اور انجیکشن فائلز

kubectl exec -n clearledger 
  $(kubectl get pod -n clearledger -l app=auth-service -o name | head -1) 
  -c auth-service -- ls /vault/secrets/

database_url
jwt_secret

curl -s -X POST http://clearledger.local/auth/login 
  -H "Content-Type: application/json" 
  -d '{"email":"test@clearledger.io","password":"SecurePass123"}' | jq .

متوقع:

{
  "access_token": "",
  "token_type": "bearer"
}

اسکرین شاٹ لیں: جاب لاگ ان JSON + kubectl get secret -n clearledger نمبر دکھا رہا ہے auth-service-secret / ledger-service-secret.

5.7: اسٹیٹس چیک

make check-5

آپ کو کیا دیکھنا چاہئے:

make check-5 توقع ہے کہ لیول 4 اسکین پہلے دوبارہ چلایا جائے گا۔ یہ دیکھنے کے لیے کہ آیا والٹ کام کر رہا ہے نیچے 5 قدمی بلاک کو تلاش کریں۔

▶ Stage 4: Admission Control (Kyverno)
  ✓ Kyverno is running
  ✓ Policy disallow-root-containers — Enforce mode
  ...
  ✓ kube-bench matches baseline (no new FAIL regressions)

▶ Stage 5: Secrets Management (Vault)
  ✓ Vault pod is running
  ✓ Vault agent injector is running
  ✓ Vault is unsealed
  ✓ Vault Kubernetes auth method is enabled
  ✓ auth-service-secret removed — Vault is the secret source
  ✓ Vault injected /vault/secrets/database_url into auth-service

All checks passed. Ready for the next stage.

اگر والٹ اندراج یا ArgoCD مطابقت پذیری ناکام ہوجاتی ہے، تو درج ذیل دیکھیں: troubleshooting.md.

مرحلہ 5 مکمل: مرحلہ 6 پر جانے سے پہلے چیک لسٹ

#	چیک کریں	چیک کرنے کا طریقہ
1	راز صرف والٹ میں پائے جاتے ہیں۔	vault kv metadata get clearledger/auth-service دکھائیں current_version >= 1
2	انفراسٹرکچر گٹ کے پاس کوئی ایپ راز نہیں ہے۔	secret.yaml غیر موجودگی clearledger-infra/manifests/auth-service/ اور ledger-service/
3	ArgoCD مطابقت پذیر	Synced Healthy درخواست دیتے وقت clearledger
4	K8s ایپ کا راز حذف کر دیا گیا۔	kubectl get secret -n clearledger کوئی توثیق/لیجر ایپ راز نہیں۔
5	انجکشن آپریشن	تصدیق پوڈ 2/2; ls /vault/secrets/ دکھائیں database_url, jwt_secret
6	ایپ کام کرتی ہے۔	لاگ ان curl واپسی access_token
7	صحت کی جانچ	make check-5 کے ساتھ ختم ہوتا ہے All checks passed. Ready for the next stage.

مرحلہ 5 ایپ کی اسناد کو Git اور Kubernetes Secrets سے منتقل کرتا ہے۔ ہم ابھی تک والٹ پروڈکشن گریڈ نہیں بنا رہے ہیں۔ اس لیب کے لیے، ہم HA یا آٹو انلاک کے بجائے والٹ ڈیولپمنٹ موڈ کا استعمال جاری رکھیں گے۔

مزید برآں، چلنے والی پوڈز نیچے کی فائلوں کو پڑھنا جاری رکھ سکتی ہیں۔ /vault/secrets/ اس کی وجہ یہ ہے کہ ایپ کو کام کرنے کے لیے ان اسناد کی ضرورت ہے۔ یہ عام بات ہے۔ مرحلہ 6 مشکوک رن ٹائم رسائی کا پتہ لگانے کے لیے Falco کو شامل کرتا ہے۔

آپ نے مرحلہ 5 میں کیا سیکھا۔

• Kubernetes کے راز حقیقی خفیہ انتظام کے لیے کافی نہیں ہیں۔

• Vault اب ایپ کی اسناد کو اسٹور کرتا ہے۔

• .env والٹ میں پہلا راز لوڈ کرنے کے لیے صرف مقامی طور پر استعمال کیا جاتا ہے۔ اس کا ارتکاب کبھی نہیں ہوا۔

• جب ایپ شروع ہوتی ہے تو والٹ پوڈز میں رازوں کو داخل کرتا ہے۔

• clearledger-infra آپ کو بچت کو روکنا ہوگا۔ secret.yamlکیونکہ ArgoCD اس ذخیرہ سے تقسیم کیا جاتا ہے۔

• آرڈر اہم ہے۔ Vault انسٹال کریں، راز کو سیڈ کریں، GitOps کو اپ ڈیٹ کریں، صحت مند پوڈ کا انتظار کریں، اور پھر Kubernetes کے پرانے راز کو حذف کریں۔

اب آپ ایک انٹرویو میں کیا کہہ سکتے ہیں:

ہم نے HashiCorp Vault ایجنٹ انجیکشن سے Kubernetes Secrets کو تبدیل کیا، Git اور Kubernetes Secrets سے ایپ کی اسناد کو ہٹا دیا، اور اس بات کو یقینی بنایا کہ رن ٹائم پر Vault کی جانب سے اسناد کے انجیکشن کے بعد بھی ایپ کام کرتی رہے۔

اپنی ترقی کو بچائیں۔

make snapshot STAGE=5 && make snapshots

چیک کریں clearledger.stage5 یہ سنیپ شاٹ کی فہرست میں ظاہر ہوگا۔

مرحلہ 6 - رن ٹائم سیکیورٹی (فالکو)

مرحلہ 1 سے 5 تک محفوظ کیا جاتا ہے کہ کیا تقسیم کیا جاتا ہے اور راز کو کیسے محفوظ کیا جاتا ہے۔ مرحلہ 6 میں، ہم دیکھتے ہیں کہ چلنے والے کنٹینر کے شروع ہونے کے بعد اس کے اندر کیا ہوتا ہے۔

آپ کا مقصد یہ جاننا ہے کہ رن ٹائم سیکیورٹی کیا پکڑتی ہے اور یہ کیوں ضروری ہے، اور پھر Falco الرٹ کو متحرک کرکے اور اسے اس طرح پڑھ کر جس طرح کال پر ایک انجینئر اسے پڑھتا ہے اسے ثابت کریں۔

CI، Kyverno، اور Vault سبھی پوڈ کے آغاز سے پہلے یا اس پر کام کرتے ہیں۔ Falco اس خلا کو پُر کرتا ہے جسے انہوں نے کھلا چھوڑ دیا تھا۔ مانیٹر کرتا ہے کہ چلانے والا سافٹ ویئر دراصل کنٹینر کے اندر کیا کر رہا ہے۔ یہ انسٹال کرنے کے لیے صرف ایک اور چارٹ نہیں ہے، یہ واقعہ کے ردعمل اور فرانزک کے لیے دلچسپی کا ایک علاقہ ہے۔

مرحلہ 6 شروع کرنے سے پہلے:

مرحلہ 6 مکمل ہے اگر:

پھر VM کو محفوظ کریں۔

make snapshot STAGE=6
make snapshots

اس ترتیب میں اقدامات پر عمل کریں:

ہر قدم پچھلے مرحلے پر منحصر ہے۔ مت بھاگو make check-6 §6.4 تک۔ کسی بھی نیٹ ورک کی پالیسیوں کو چیک کریں جن کا آپ نے ابھی تک اطلاق نہیں کیا ہے۔

1. §6.1: bash stages/stage-6-runtime-security/scripts/install-falco.sh. چیک کریں falco-* پھلی 2/2 Running اپنی مرضی کے قوانین کو لوڈ کر دیا گیا ہے.

2. §6.2: make demo-6:پڑھنا ✓ Runtime detection confirmed ٹرمینل میں

3. §6.3 (اختیاری) دستی اسقاط حمل کا منظر (اگر چھوڑ دیں) make demo-6 پہلے ہی کام کر چکے ہیں)

4. §6.4: kubectl apply -f infra/deferred-by-stage/stage-6-runtime-security/netpol/network-policies.yaml. چیک کریں curl http://clearledger.local/ 200 لوٹاتا ہے۔

5. §6.6: make check-6

وقت شروع §6.1. اگر کچھ ناکام ہو جائے تو براہ کرم اس سے رجوع کریں۔ troubleshooting.md.

پڑھنے کا انتخاب کریں: مرحلہ 6 کس طرح مجموعی اسٹیک میں فٹ بیٹھتا ہے: Falco اور netpol کیوں موجود ہیں اور وہ 3-5 مراحل سے کیسے مختلف ہیں۔

اگر آپ مرحلہ 6 پر پھنس جاتے ہیں۔

مرحلہ 6 میں تین کام ہیں:

1. فالکو کی تنصیب

2. 1 ٹیسٹ نوٹیفکیشن ٹرگر

3. نیٹ ورک پالیسی کا اطلاق کریں۔

Falco UI میں ہر قطار کے بارے میں فکر نہ کریں۔ UI شور دکھا سکتا ہے۔ اگر مجھے ٹرمینل میں یا UI میں ڈیمو میں ایک انتباہ مل سکتا ہے، تو میں Falco کے حصے کو پاس کروں گا۔

پورٹ فولیو اسکرین شاٹس دیکھنے کے لیے، کھولیں:

http://falco.local

لاگ ان:

• صارف کا نام: admin

• پاس ورڈ: admin

ڈیمو نوٹیفکیشن دیکھنے کے بعد ہی اسکرین شاٹس لیں۔

عام رکاوٹ پوائنٹس

آپ سوچتے ہیں…	اصل میں کیا سچ ہے
"UI 200 سے زیادہ اہم انتباہات دکھاتا ہے۔ ہو سکتا ہے میں نے کچھ توڑا ہو۔"	نہیں postgres-0 پڑھیں /etc/passwd لوپ میں، Falco جھنڈے. اس لائن کو نظر انداز کریں۔
"ڈیمو اطلاع نہیں ملی۔"	اگلا، UI تلاش کریں۔ Command+F → Shell Spawnedیا ٹرمینل grep اوپر مرحلہ 4 سے۔ جب grep دکھاتا ہے۔ auth-service + id && exitآپ پاس ہو گئے۔
"make check-6 "نیٹ ورک پالیسی ناکام ہوگئی۔"	آپ نے چیک چلایا §6.4 سے پہلے. پہلے نیٹ پول لگائیں اور پھر اسے دوبارہ چلائیں۔
"§6.3 اور §6.2 — مجھے کس پر عمل کرنا چاہئے؟"	چلائیں make demo-6 (§6.2) صرف §6.3 وہی حملہ ہے جیسا کہ دستی کمانڈ ہے۔ اگر Demo-6 پہلے ہی کام کر چکا ہے تو اسے چھوڑ دیں۔
"شیل تخلیق کیا ہے؟"	فالکو نے دیکھا sh عمل شروع کریں۔ اندر auth-service. پیداواری عمل مشکوک ہے۔ لیب میں آپ میں نے جان بوجھ کر ایسا کیا۔ §6.2 دیکھیں۔
"منظر نامہ 4 ختم کر دیا گیا ہے یا 137 کو ختم کر دیا گیا ہے۔"	قابل احترام wget کمانڈ + بند ہو رہا ہے۔ پی او ڈی منظر نامہ 4 کو چھوڑیں یا Python3 §6.4 میں آرڈرز۔ چیک پوائنٹ+ make check-6 کافی

6.1: Falco اور Falcosidekick UI انسٹال کریں۔

bash stages/stage-6-runtime-security/scripts/install-falco.sh

یہ چلتا ہے۔ helm upgrade --install کے ساتھ modern_ebpfFalcosidekick + Web UI کو چالو کریں، k8s - میٹا کلیکٹر (collectors.kubernetes.enabled: true) تاکہ حسب ضرورت اصول مل سکیں۔ k8smeta.ns.name = clearledgerسے لوڈ قوانین: infra/falco/clearledger-rules-content.yamlConfigMap اور اندراج کے قواعد کا اطلاق کریں۔

اگر آپ کے پاس پہلے سے Falco انسٹال ہے، تو اسکرپٹ کو دوبارہ چلانا (اپ گریڈ) کرنا محفوظ ہے۔

فالکو پوڈ کو چیک کریں۔

kubectl get pods -n falco

متوقع پیداوار:

NAME                                      READY   STATUS    RESTARTS   AGE
falco-w4fh6                               2/2     Running   0          2m
falco-falcosidekick-...                   1/1     Running   0          2m
falco-falcosidekick-ui-...                1/1     Running   0          2m
falco-falcosidekick-ui-redis-0            1/1     Running   0          2m

آپ کو اپنے Falco DaemonSet میں درج ذیل کو دیکھنا چاہیے: 2/2 رن. آپ کو بالترتیب Sidekick، UI، اور Redis pods دیکھنا چاہیے۔ 1/1 رن. کلسٹر کا پوڈ نام کا لاحقہ مثال سے مختلف ہے۔

کھلا http://falco.local. Falcosidekick UI ڈسپلے کیا جائے گا۔ چارٹ ڈیفالٹس کے ساتھ لاگ ان کریں۔

میدان	قدر
لاگ ان	admin
پاس ورڈ	admin

اگر آپ لیب ڈیفالٹس پر بھروسہ کرنے کے بجائے اپنے کلسٹر سے اسناد پڑھنا چاہتے ہیں تو ان ہدایات پر عمل کریں:

kubectl get secret falco-falcosidekick-ui -n falco 
  -o jsonpath="{.data.FALCOSIDEKICK_UI_USER}" | base64 -d && echo
# admin:admin

Falcosidekick UI: فوری واقفیت سیٹ اپ

لاگ ان کرنے کے بعد واقعہ ٹیگ ڈیمو چلانے سے پہلے ٹیبل مصروف نظر آ سکتا ہے۔ یہ عام بات ہے۔

• حکمرانی: دریافت کا نام (پھانسی شدہ شے)

• ترجیحات: تنقیدی / انتباہ / نوٹس (یہ لیب تنقیدی اور انتباہ پر مرکوز ہے۔)

• حساب: پوڈ کا نام، فائل، یا کمانڈ کی تفصیلات

• ٹیگ: تلاش کریں۔ clearledger لیب الرٹ پر

ناقابل توجہ پس منظر کا شور: ArgoCD پر قطاریں دیکھیں۔ تنقیدی حساس فائلیں پڑھیں لائن postgres-0 پڑھنا /etc/passwd (ہر چند سیکنڈ میں دہرائیں)۔ ڈیمو اطلاعات مختلف ہیں۔ §6.2 دیکھیں۔

بھری ہوئی حسب ضرورت قواعد کو چیک کریں۔ (§6.2 سے پہلے کیا گیا):

kubectl get pods -n falco                                    # Falco pod 2/2 Running
kubectl get configmap clearledger-falco-rules -n falco
kubectl logs -n falco -l app.kubernetes.io/name=falco -c falco --tail=200 
  | grep 'rules.d/clearledger_rules'

متوقع: clearledger_rules.yaml | schema validation: ok

خالی grep --tail=30 آپ اکیلے ناکام نہیں ہیں۔ استعمال کریں --tail=200. اگر آپ دیکھتے ہیں LOAD_ERR_COMPILE_CONDITIONدیکھیں troubleshooting.md.

اگر قوانین کو لوڈ نہیں کیا جاتا ہے تو، §6.2 اور §6.3 گزرتے ہوئے دکھائی دیں گے جب کچھ بھی نہیں کیا گیا ہے۔

6.2: گائیڈڈ ڈیمو (make demo-6)

یہ چلائیں ~ بعد §6.1 (فالکو انسٹال کریں، رولز چیک کریں، UI کھولیں: http://falco.local)۔

make demo-6
# or:
bash stages/stage-6-runtime-security/scripts/demo-falco-alerts.sh

ڈیمو اسکرپٹ کی خصوصیات

ڈیمو یہ ظاہر کرتا ہے کہ Falco چلتے ہوئے کنٹینر کے اندر مشکوک سرگرمی کا پتہ لگا سکتا ہے۔

اسکرپٹ چیک کرتا ہے کہ آیا Falco چل رہا ہے اور اسے کھولتا ہے۔ http://falco.localاس کا استعمال کرتے ہوئے لاگ ان ہونے تک انتظار کریں:

• صارف کا نام: admin

• پاس ورڈ: admin

پھر اس ٹیسٹ کمانڈ کو اندر چلائیں: auth-service کنٹینر:

kubectl exec -n clearledger 
  auth-service- 
  -c auth-service -- /bin/sh -c 'id && exit'

اسکرپٹ اصل پوڈ کا نام لیتا ہے۔

غیر انٹرایکٹو (کوئی CI یا Enter پرامپٹ نہیں): SKIP_PROMPT=1 make demo-6.

یہ ایپ کنٹینر کے اندر ایک شیل شروع کرتا ہے۔ ایپ کنٹینرز پروڈکشن میں قابل اعتراض ہیں کیونکہ انہیں شیل کھولے بغیر ایپ کو چلانے کی ضرورت ہوتی ہے۔ Falco کو اس کا پتہ لگانا چاہئے اور اس طرح ایک انتباہ پیدا کرنا چاہئے:

Shell Spawned in ClearLedger Container

جب اسکرپٹ پرنٹ کیا جاتا ہے:

✓ Runtime detection confirmed

Falco UI کو ریفریش کریں۔

درج ذیل تلاش کریں: تنقیدی انتباہ:

درج ذیل اطلاعات کو نظر انداز کریں: postgres-0خاص طور پر Sensitive File Read. یہ اس مشق کے پس منظر کا شور ہے۔

اگر آپ کا UI شور والا ہے تو اپنے صفحہ پر درج ذیل کو تلاش کریں: Shell Spawned یا اسے ٹرمینل میں چیک کریں۔

kubectl logs -n falco -l app.kubernetes.io/name=falco -c falco --tail=500 
  | grep 'Shell Spawned'

اسکرین شاٹس کے لیے Shell Spawned خبردار کرنا auth-service.

6.3: بریکیٹ سیناریو (دستی، اختیاری)

یہ §6.2 جیسا ہی پتہ ہے، لیکن ہر کمانڈ کو براہ راست عمل میں لاتا ہے۔ اگر آپ پہلے ہی یہ کر چکے ہیں تو اس سیکشن کو چھوڑ دیں۔ make demo-6.

اصول کا نام	آپ اسے متحرک کرتے ہیں…
ClearLedger کنٹینر سے تیار کردہ شیل	منظرنامہ 1 - kubectl exec … /bin/sh
ClearLedger میں حساس فائلوں کو پڑھنا	منظر نامہ 2 - cat /etc/passwd
پیکیج مینیجر / آؤٹ باؤنڈ کنکشنز	منظر نامہ 3 - wget یا curl

ہر کمانڈ کے بعد ریفریش کریں۔ http://falco.local متبادل طور پر، §6.2 سے تلاش کا طریقہ استعمال کریں۔

منظر نامہ 1 - چلتی ہوئی پوڈ کا شیل (سمپلیٹنگ کمانڈ انجیکشن):

kubectl exec -n clearledger 
  $(kubectl get pod -n clearledger -l app=auth-service -o name | head -1) 
  -c auth-service -- /bin/sh -c "id && exit"

Falco UI/logs سے متوقع (~10 سیکنڈ یا اس سے کم):

CRITICAL: Shell spawned in ClearLedger container
  user=... container=auth-service pod=auth-service-... cmd=sh -c id && exit

اس کا کیا مطلب ہے: فیز 4 کی اجازت شدہ پوڈز (تعمیل)۔ سطح 6 کا پتہ چلا اندرونی کارروائی پوڈ: یہ بالکل وہی ہے جو ایک حملہ آور کمانڈ انجیکشن کے بعد کرے گا۔

اگر آپ کو کوئی اطلاع نظر نہیں آتی ہے: استعمال شدہ exec کو چیک کریں۔ -c auth-service (والٹ ایجنٹ سائڈکار نہیں)، قواعد دکھائیں۔ schema validation: okپوڈ تصویری ناموں میں شامل ہیں: clearledger.

منظر نامہ 2 - حساس فائلوں کو پڑھنا (ریکنیسنس):

kubectl exec -n clearledger 
  $(kubectl get pod -n clearledger -l app=auth-service -o name | head -1) 
  -c auth-service -- cat /etc/passwd

متوقع:

CRITICAL: Sensitive file read in ClearLedger
  file=/etc/passwd container=auth-service pod=auth-service-...

منظر نامہ 3 - رن ٹائم پر ٹولز ڈاؤن لوڈ کریں (اختیاری):

kubectl exec -n clearledger 
  $(kubectl get pod -n clearledger -l app=auth-service -o name | head -1) 
  -c auth-service -- sh -c "wget -q ifconfig.me -O - 2>/dev/null || true"

اس کے نتیجے میں پیکیج مینیجر چل سکتا ہے اور/یا غیر متوقع آؤٹ باؤنڈ کنکشن (انتباہات)۔

منظرنامے 1 اور 2 کے اسکرین شاٹس لیں: رن ٹائم کا پتہ لگانے کے لیے پورٹ فولیو ثبوت۔

6.4: نیٹ ورک پالیسی انفورسمنٹ (زیرو ٹرسٹ سیگمنٹیشن)

نیٹ ورک کی پالیسیاں پوڈ کے درمیان فائر وال کے اصول ہیں۔ Falco ڈیمو کے بعد درخواست دیں۔

make check-6 براہ کرم صرف اس سیکشن کے بعد چلائیں کیونکہ آپ ان پالیسیوں کی جانچ کر رہے ہوں گے۔ کہ default-deny-all پالیسی ٹریفک کو بطور ڈیفالٹ بلاک کرتی ہے۔

کہ allow-* پالیسیاں صرف وہ راستے کھولتی ہیں جن پر ClearLedger کو کام کرنے کی ضرورت ہوتی ہے۔ Falco مشکوک رویے کا پتہ لگاتا ہے۔ نیٹ ورک کی پالیسیاں محدود کرتی ہیں کہ پوڈ کہاں جڑ سکتے ہیں۔

لاگو کریں:

kubectl apply -f infra/deferred-by-stage/stage-6-runtime-security/netpol/network-policies.yaml
kubectl get networkpolicy -n clearledger

متوقع: 7 پالیسیاں: default-deny-all پلس 6 allow-* (auth-service, ledger-service, notification-service, postgres, redis, frontend)۔

چیک کریں کہ آیا ایپ اب بھی کام کرتی ہے۔

curl -s http://clearledger.local/auth/health | jq .
# {"status":"ok","service":"auth-service"}

curl -s http://clearledger.local/notifications/health | jq .
# {"status":"ok",...}

چیک پوائنٹ (ضروری): ثابت کرتا ہے کہ نیٹ پول نے اصل ایپ سے سمجھوتہ نہیں کیا۔

kubectl get networkpolicy -n clearledger
curl -s -o /dev/null -w "%{http_code}n" http://clearledger.local/
kubectl get pods -n clearledger --field-selector=status.phase!=Running

نتیجہ	معنی
7 پالیسیاں درج ہیں۔	نیٹ پول لگائیں۔
200 curl سے	صارفین اب بھی آپٹ ان کر کے ایپ تک رسائی حاصل کر سکتے ہیں۔
تیسری کمانڈ پرنٹ کریں۔ کچھ نہیں	کوئی پوڈ کریش نہیں ہوا۔

اگر نیٹ پول کے بعد تصدیق یا لیجر دوبارہ شروع ہوتا ہے، تو آپ کے اخراج کے اصول بہت سخت ہیں۔ دیکھیں troubleshooting.md.

منظر نامہ 4 - بلاک کراس سروس ٹریفک (اختیاری)

اگر آپ چوکی سے گزرے ہیں اور اسے چلانا چاہتے ہیں تو اسے چھوڑ دیں۔ make check-6. اس سے ثابت ہوتا ہے کہ لیجر نوٹیفکیشن کو براہ راست کال نہیں کر سکتا (اس راستے کے لیے اجازت کے کوئی اصول نہیں ہیں)۔ کنکشن کی ناکامی ایک کامیابی ہے۔

پرانے استعمال نہ کریں wget ایک لائنر: لیجر امیج میں نہیں ہے۔ wget/curlاور head -1 آپ پوڈ کو ختم کرنے کا انتخاب کر سکتے ہیں (exec یا تو لٹک جائے گا یا ختم ہو جائے گا)۔ 137)۔

LEDGER_POD=$(kubectl get pods -n clearledger -l app=ledger-service --no-headers 
  | awk '$2=="2/2" && $3=="Running" {print $1; exit}')

echo "Using pod: $LEDGER_POD"

kubectl exec -n clearledger "$LEDGER_POD" -c ledger-service -- python3 -c "
import urllib.request
try:
    urllib.request.urlopen('http://notification-service/', timeout=5)
    print('UNEXPECTED: connection succeeded')
except Exception as e:
    print('BLOCKED (expected):', e)
"

متوقع:

BLOCKED (expected): 

یا Connection refused, ~ نہیں UNEXPECTED: connection succeeded.

6.6: اسٹیٹس چیک

یہ چلائیں §6.4 آگے (نیٹ ورک پالیسی)۔ یقینی بنائیں کہ Falco، کسٹم رولز، اور نیٹ پول انسٹال ہیں۔ ہاں ~ نہیں ثابت کریں کہ ایک انتباہ ہوا ہے (یعنی §6.2)۔

make check-6

آپ کو کیا دیکھنا چاہئے:

▶ Stage 6 — Runtime Security (Falco)
  ✓ Falco DaemonSet: 1/1 nodes
  ✓ ClearLedger custom Falco rules ConfigMap exists
  ✓ NetworkPolicy default-deny-all exists
  ✓ NetworkPolicy allow-auth-service exists
  ✓ NetworkPolicy allow-ledger-service exists
  ✓ NetworkPolicy allow-notification-service exists
  ✓ auth-service reachable after network policies
  ✓ notification-service reachable after network policies

All checks passed. Ready for the next stage.

مرحلہ 6 آپ کے پورے اسٹیک کو کیسے فٹ کرتا ہے (اختیاری پڑھنا)

ہر مرحلہ زندگی کے چکر میں ایک مختلف نقطہ کی حفاظت کرتا ہے۔ پوڈ اسٹارٹ اپ سے پہلے یا اس کے دوران مراحل 1-5 کام کرتے ہیں۔ مرحلہ 6 میں، ہم مشاہدہ کرتے ہیں کہ پہلے سے چلنے والے کنٹینر کے اندر کیا ہوتا ہے۔

• مرحلہ 3 میں CI خراب کوڈ اور تصاویر پکڑتا ہے۔ git push.

• مرحلہ 4، Kyverno داخلہ کے بعد بدمعاش پھلیوں کو روکتا ہے۔

• مرحلہ 5، والٹ سٹارٹ اپ میں راز کو انجیکشن دیتا ہے۔

• مرحلہ 6، فالکو پوڈ کے چلنے کے بعد سیسکالز کو دیکھتا ہے (شیل سپون کرتا ہے، حساس فائلوں کو پڑھتا ہے)۔

• مرحلہ 6، نیٹ ورک کی پالیسیاں پھلیوں کے درمیان ٹریفک کو فلٹر کرتی ہیں۔

وہ تین مختلف سوالوں کے جواب دیتے ہیں۔ Kyverno پوچھے گا کہ کیا یہ اس پوڈ کو بنا سکتا ہے۔ فالکو پوچھتا ہے کہ فورڈ اب کیا کر رہا ہے۔ نیٹ ورک پالیسی پوچھتی ہے کہ پوڈ کس سے بات کر سکتا ہے۔

Falco CI یا Kyverno کی جگہ نہیں لیتا ہے۔ اگر آپ 3-5 مراحل کو چھوڑتے ہیں، Falco پھر بھی آپ کو متنبہ کرے گا، لیکن آپ Git کو پہلے ہی کمزور کوڈ اور راز فراہم کر چکے ہیں۔

مرحلہ 6 مکمل ہو گیا ہے۔ مرحلہ 6.5 یا مرحلہ 7 پر جائیں۔

#	چیک کریں	چیک کرنے کا طریقہ
1	فالکو رن	kubectl get pods -n falco - ڈیمن سیٹ 2/2
2	اپنی مرضی کے قوانین کو لوڈ کر دیا گیا ہے.	`kubectl log -n falco -l app.kubernetes.io/name=falco -c falco --tail=200
3	شیل وارننگ جاری کی گئی۔ اور آپ اسے پڑھتے ہیں	make demo-6 → اہم لائنز cmd=sh -c id && exitفورڈ auth-service-… — §6.2
4	نیٹ ورک پالیسی لاگو ہو گئی۔	kubectl get networkpolicy -n clearledger — §6.4
5	ایپ اب بھی صحت مند ہے۔	curl توثیق + نوٹیفکیشن اسٹیٹس ریٹرن 200
6	صحت کی جانچ	make check-6 سبز — §6.6

پورٹ فولیو اسکرین شاٹ (اختیاری): کنٹینر کے اندر شیل وارننگ · Falco UI میں حساس فائل ریڈ وارننگ۔

اگلے مراحل: مرحلہ 6 Falco الرٹس اور بنیادی نیٹ ورک پالیسیاں فراہم کرتا ہے۔ آپ اپنی نیٹ ورک پالیسی کو بعد میں بہتر کر سکتے ہیں۔ مرحلہ 6.5 لٹمس کا استعمال کرتے ہوئے ایک اختیاری افراتفری کا امتحان ہے، اور مرحلہ 7 وقت کے ساتھ سیکیورٹی کے واقعات دیکھنے کے لیے گرافانا ڈیش بورڈ کا اضافہ کرتا ہے۔

آپ نے مرحلہ 6 میں کیا سیکھا۔

• رن ٹائم سیکیورٹی جسے CI اور داخلہ کنٹرول نہیں پکڑتے: کنٹینرز کے اندر سے خطرات

• Falco کیا ہے: اپنی مرضی کے مطابق YAML قواعد کا استعمال کرتے ہوئے eBPF سیسکال کی نگرانی کرنا

• نیٹ ورک پالیسی کیا ہے؟ پھلیوں کے درمیان Kubernetes فائر وال کے اصول

• انتباہات کو متحرک کرنے اور ان کی تشریح کرنے کا طریقہ: واقعہ کے جواب کی تکنیک

• مکمل اسٹیک: رن ٹائم کا پتہ لگانے سے کوڈ اسکیننگ، داخلہ کنٹرول، خفیہ انتظام، اور (اگلا) مشاہدہ ہوتا ہے۔

اب آپ اپنے تجربے کی فہرست میں کیا ڈال سکتے ہیں/ایک انٹرویو میں کہہ سکتے ہیں:

آپ اپنی مرضی کے اصولوں کا استعمال کرتے ہوئے رن ٹائم خطرے کا پتہ لگانے کے لیے Falco کو تعینات کر سکتے ہیں اور کنٹینرز کے اندر شیلز یا حساس فائل ریڈنگ پر الرٹس کو متحرک کرنے کے لیے آن کال انجینئرز کے ذریعے پڑھتے ہیں۔

make snapshot STAGE=6 && make snapshots. چیک کریں clearledger.stage6. دیکھیں کہ اپنی ترقی کو کیسے بچایا جائے۔

مرحلہ 6.5 — افراتفری انجینئرنگ (اختیاری)

زیادہ تر سیکھنے والے اسے چھوڑ دیتے ہیں۔ مرحلہ 6 مکمل ہونے کے بعد make check-6 اگر آپ گزر جاتے ہیں، تو آپ سیدھے قدم 7 پر جائیں گے۔ 7 اور 8 مرحلے کے لیے لٹمس کی ضرورت نہیں ہے۔

اگر آپ افراتفری / اچھال چاہتے ہیں (~ 1 گھنٹہ): LitmusChaos ایک کو حذف کرتا ہے۔ auth-service فورڈ اور ثبوت /auth/health قیام 200 Kubernetes اس کی جگہ لے لیتا ہے۔

اس ترتیب میں اقدامات پر عمل کریں:

قدم	پارٹ ٹائم نوکری	آپ کیا کرتے ہیں
1	§6.5.0	make fix-65-prereqs - تصدیقی پوڈ 2/2 تیاری
2	§6.5.1	bash ...install-litmus.sh - UI شو فعال 1
3	§6.5.2	UI: پوڈ ڈیلیٹ کرنے کا تجربہ + curl 200 رکھیں
4	§6.5.7	make check-65سنیپ شاٹ

اختیاری: §6.5.3: اسی ٹیسٹ کے ذریعے make demo-65 UI وزرڈ کے بجائے (ٹرمینل پاتھ) استعمال کریں۔

6.5.0: شروع کرنے سے پہلے (توثیق پوڈز 2/2 ہونے چاہئیں)

افراتفری پھلی کو حذف کرتی ہے۔ اگر متبادل شروع نہیں ہوتا ہے تو لچک سیکھنے کے بجائے CrashLoopBackOff کو ڈیبگ کریں۔

export GITHUB_OWNER=YOUR_GITHUB_USERNAME   # required — without this, fix-argocd breaks ArgoCD repoURL
make fix-65-prereqs
kubectl get pods -n clearledger -l app=auth-service

پاس: دو پھلی، دونوں 2/2 تیاری. جب تک ایسا نہ ہو لٹمس کو انسٹال نہ کریں۔

اگر کچھ ناکام ہوجاتا ہے:

علامت	ٹھیک کریں
آرگو سی ڈی موازنہ کی غلطی ~ بعد fix-65-prereqs	kubectl apply -f stages/stage-2-gitops/argocd/clearledger-app.yaml
سرٹیفیکیشن ری سیٹ کریں: 0/1محفوظ permission denied	مرحلہ 5 دوبارہ چلائیں۔ setup.sh + seed-vault-secrets.shتصدیق/لیجر پوڈ کو حذف کریں۔
سرٹیفیکیشن 1/2 یا پوسٹگریس ٹائم آؤٹ	make fix-65-prereqs دوبارہ (netpol + start probe شامل کریں)

6.5.1: LitmusChaos انسٹال کریں (آپریٹر، UI، کلسٹر کنکشن)

bash stages/stage-6.5-chaos-engineering/scripts/install-litmus.sh
kubectl get pods -n litmus
open http://litmus.local    # login: admin / litmus

§6.5.2 سے پہلے پاس کیا گیا: جائزہ بنیادی ڈھانچہ دکھاتا ہے: ایکٹو 1 (0 نہیں، زیر التواء نہیں)۔

اپنا پوڈ چیک کریں:

kubectl get pods -n litmus
# litmus-core, chaos frontend/server, mongodb, subscriber — all Running

اگر جائزہ 0 انفراسٹرکچر یا زیر التواء دکھاتا ہے۔

UI اس وقت تک خالی ہے جب تک کہ سبسکرائبر ایجنٹ کلسٹر سے منسلک نہ ہو جائے۔

export LITMUS_PASSWORD='litmus'   # only if you changed the default
bash stages/stage-6.5-chaos-engineering/scripts/connect-litmus-infra.sh

اپنے براؤزر کو ریفریش کریں۔ وقت شروع http://litmus.local بس بوڑھا نہیں۔ /account/.../settings بک مارک۔

UI نیویگیشن (§6.5.2 میں آرڈر پر کلک کریں)

1. خاکہ: چیک کریں۔ فعال 1

2. افراتفری کا مرکز, پوڈ کو حذف کریں, تجربہ شروع کریں۔

3. افراتفری کا تجربہ:دیکھنا تکمیل کی طرف دوڑ رہا ہے۔

بائیں نیویگیشن: خاکہ, ماحول, افراتفری کا مرکز, افراتفری کا تجربہ. چھوڑیں لچک کی تحقیقات اور گہرا ترتیب یہ اس لیب کا URL ہے۔

6.5.2: اپنا پہلا تجربہ چلائیں (پوڈ کو حذف کریں)

ہدف: ایک کو مار ڈالو auth-service فورڈ اور ثبوت /auth/health قیام 200.

UI میں چلائیں پر کلک کرنے سے پہلےدو ٹرمینلز کھولیں:

# Terminal A — watch pods
kubectl get pods -n clearledger -l app=auth-service -w

# Terminal B — watch health every 5 seconds
while true; do
  date +%H:%M:%S
  curl -s -o /dev/null -w "health=%{http_code}n" http://clearledger.local/auth/health
  sleep 5
done

UI(http://litmus.local): بائیں نیویگیشن → ChaosHubs → Delete Pod card → تجربہ شروع کریں۔

لٹمس UI نوٹس: ChaosCenter کے لیبل ورژن سے دوسرے ورژن میں تبدیل ہوتے ہیں (جیسے "کوآرڈینیشن ایرر"، "ٹارگٹ سلیکشن"، "Chaos Experiment")۔ فیلڈ میچنگ کا معیار تصوریہ درست بٹن متن نہیں ہے۔ اگر نیچے دیے گئے جدول میں کوئی قدر درج نہیں ہے تو وزرڈ ڈیفالٹ کو قبول کریں۔

لٹمس UI میں، کھولیں:

ChaosHubs → Pod Delete → Launch Experiment

اس سے تجرباتی وزرڈ کھل جائے گا۔ جب وزرڈ پوچھے تو درج ذیل اقدار کا استعمال کریں:

• بنیادی ڈھانچہ: clearledger-cluster اور یہ ہونا ضروری ہے Active

• نام کی جگہ: clearledger

• ہدف کا لیبل: app=auth-service

• ہدف کی قسم: Deployment

• متاثرہ پھلیاں: 50%

• جاری رکھیں: 30 موم بتی

• غلطی/تجربہ کا نام: pod-delete

محفوظ کریں یا تخلیق کا استعمال کرتے ہوئے وزرڈ کو مکمل کریں، اور پھر چلائیں پر کلک کریں۔ منتخب نہ کریں شیڈول.

کامیابی کیسی نظر آتی ہے:

کہاں	اچھی علامت
ٹرمینل اے	1 پھلی بند ہو رہا ہے۔پھر دوبارہ 2/2 تیاری
ٹرمینل بی	health=200 یہاں تک کہ جب ایک پوڈ نیچے ہے۔
لٹمس UI	تجربہ چل رہا ہے → مکمل

کیا آپ UI پر ٹرمینل کو ترجیح دیتے ہیں؟ وزرڈ کو چھوڑیں اور دیکھیں §6.5.3(make demo-65اس کے بجائے۔

6.5.3 — ٹرمینل میں ایک ہی تجربہ (make demo-65) - اختیاری۔

لٹمس UI پر کلک کیے بغیر پوڈ ڈیلیٹ کرنے کے ٹیسٹ چلانے کے لیے اس اختیار کا استعمال کریں۔

سب سے پہلے، چیک کریں کہ تصدیقی پوڈ صحت مند ہے.

make fix-65-prereqs

پھر ڈیمو چلائیں۔

make demo-65

سکرپٹ ہے auth-service-pod-delete افراتفری کا انجن litmus نام کی جگہ۔ لٹمس ایک کو حذف کریں۔ auth-service اگر کوئی Pod موجود ہے تو Kubernetes اسے بدل دے گا اور اسکرپٹ اس کی جانچ کرے گا۔ /auth/health واپس آتے رہیں 200.

ایک بار مکمل ہونے کے بعد، نتائج کو چیک کریں۔

kubectl get chaosresult -n litmus
kubectl get pods -n clearledger -l app=auth-service

اگر اسکرپٹ اس کے ساتھ ختم ہوتا ہے: PASS, ChaosResult ہے Completed / Passاور دو auth-service پھلی دوبارہ چل رہی ہے۔

آپ اسے لٹمس UI میں بھی دیکھ سکتے ہیں۔ افراتفری کا تجربہ → ریفریش → تازہ ترین رن کھولیں۔

جب ایک نئے تصدیقی پوڈ میں خلل پڑتا ہے۔ Init:0/1مرحلہ 6 نیٹ ورک پالیسی کو دوبارہ لاگو کریں۔

kubectl apply -f infra/deferred-by-stage/stage-6-runtime-security/netpol/network-policies.yaml

6.5.3a: اصل آؤٹ پٹ مثال (جیسا کہ لیب کلسٹر پر دیکھا گیا ہے)

یہ نمونہ کام کے بوجھ کے درج ذیل کلسٹر سے لیا گیا تھا۔ make fix-65-prereqs, make connect-litmusاور make demo-65.

make check-65

▶ Stage 6.5 — Chaos Engineering (LitmusChaos)
  ✓ litmus namespace exists
  ✓ litmus-admin ServiceAccount exists in litmus
  ✓ pod-delete ChaosExperiment installed in litmus
  ✓ Litmus chaos operator is running
  ✓ Litmus ChaosCenter reachable at http://litmus.local
  ✓ Litmus subscriber running (UI connected to cluster)
  ✓ auth-service healthy (baseline before chaos)
  ✓ auth-service has 2/2 Ready replicas (stable for chaos)
  ✓ allow-postgres NetworkPolicy exists (Stage 6 fix)

All checks passed. Ready for the next stage.

make demo-65 اصل دوڑ سے پکڑا گیا (2026-06-01)

Stage 6.5 — auth-service pod-delete

Preflight: 2 auth-service pods Running

Applying ChaosEngine auth-service-pod-delete (namespace litmus)

Watching http://clearledger.local/auth/health

  10s  health=200  pods=2
  20s  health=200  pods=1
  30s  health=200  pods=1
  40s  health=200  pods=2
  50s  health=200  pods=2
  60s  health=200  pods=2

Result:
  ChaosResult: Completed / Pass
  Recovery:    2 auth-service pod(s) Running
  Health:      6/6 checks returned 200

PASS

اگر آپ کو ہیلتھ لائن نظر آتی ہے۔ 000چلائیں bash scripts/setup-hosts.sh اسے اپنے میک پر دوبارہ چلانے کی کوشش کریں۔ میں اسکرپٹ کو بھی آزماتا ہوں: multipass exec clearledger -- curl جب VM موجود ہو۔

ٹرمینل بی (اسٹیٹ لوپ، متوقع آؤٹ پٹ)

22:05:01
health=200
22:05:06
health=200
22:05:11
health=200

پھلی کی گنتی ظاہر کی جا سکتی ہے۔ 1 یہ اس وقت متوقع ہے جب متبادل پوڈ لانچ کیا جا رہا ہے۔

ٹرمینل A افراتفری میں (kubectl get pods -w)

NAME                            READY   STATUS        RESTARTS   AGE
auth-service-84cc988c4d-hdb45   2/2     Running       0          67m
auth-service-84cc988c4d-b59sj   2/2     Terminating   0          15m    ← killed
auth-service-84cc988c4d-dxz9q   0/2     Pending       0          0s     ← replacement
auth-service-84cc988c4d-dxz9q   0/2     Init:0/1      0          2s
auth-service-84cc988c4d-dxz9q   2/2     Running       0          90s

ڈیمو کے بعد: ٹھیک ہے۔

kubectl get chaosresult -n litmus
# auth-service-pod-delete-pod-delete   Completed   Pass

kubectl get pods -n clearledger -l app=auth-service
# auth-service-84cc988c4d-xxxxx   2/2   Running
# auth-service-84cc988c4d-yyyyy   2/2   Running

kubectl get cm subscriber-config -n litmus -o jsonpath="{.data.IS_INFRA_CONFIRMED}"
# true

سبسکرائبر منسلک (UI میں بنیادی ڈھانچہ فعال)

kubectl logs -n litmus -l app.kubernetes.io/name=subscriber --tail=3
level=info msg="AgentID: a63c2a2c-... has been confirmed"
level=info msg="Server connection established, Listening...."

6.5.4: YAML فائلوں کو سمجھنا (عمل درآمد سے پہلے پڑھیں)

ہر فائل ہے۔ ChaosEngine: لٹمس سے درخواست: "ایپ Y کے لیے Z سیکنڈز کے لیے X تجربہ چلائیں۔"

litmus-install.yaml

یہ ہے litmus صرف نام کی جگہ۔ پلیٹ فارم کے کام کا بوجھ یہاں سے الگ سے موجود ہے: clearledger ایپ پوڈ۔

litmus-rbac.yaml

مرضی	فنکشن
ServiceAccount litmus-admin (نام کی جگہ litmus)	لٹمس رنر پوڈ کی شناخت
ClusterRoleBinding → cluster-admin	پوڈ کو حذف کرنے / غلطی کے انجیکشن کی اجازت دیں۔ clearledger (لیب کی آسانیاں۔ پیداوار میں کم سے کم استحقاق کا استعمال کریں)

auth-service-pod-delete.yaml (تجربہ 1: ڈیمو میں استعمال کیا گیا)

metadata:
  namespace: litmus          # engine lives here (Kyverno-safe)
spec:
  appinfo:
    appns: clearledger       # target app namespace
    applabel: app=auth-service
    appkind: deployment
  experiments:
    - name: pod-delete
      spec:
        components:
          env:
            - name: PODS_AFFECTED_PERC
              value: "50"    # 50% of 2 replicas = 1 pod killed
            - name: TOTAL_CHAOS_DURATION
              value: "30"    # chaos window in seconds

جب میں اسے لاگو کرتا ہوں تو کیا ہوتا ہے؟

1. آپریٹر پڑھتا ہے۔ ChaosEngine اور تخلیق کریں auth-service-pod-delete-runner نیچے اور litmus

2. رنر ایک کا انتخاب کریں۔ auth-service نیچے اور clearledger SIGTERM/delete بھیجیں۔

3. Kubernetes تعیناتی کنٹرولر 1/2 نقلوں کی جانچ پڑتال کرتا ہے اور متبادل پوڈز کو شیڈول کرتا ہے۔

4. سروس ٹریفک کو اس طرف لے جاتی ہے: زندہ رہنا بازیافت میں نقل

5. ChaosResult لٹمس کے نقطہ نظر سے پاس/فیل CR ریکارڈ

ledger-service-network-latency.yaml (تجربہ 2 - دستی)

اضافہ 2000ms نیٹ ورک کی تاخیر ledger-service پوڈ کو 60 سیکنڈ تک استعمال کریں۔ ثابت کرتا ہے کہ ٹائم آؤٹ واپس آ گیا ہے۔ 503 UI کو معلق چھوڑنے کے بجائے۔

notification-service-memory-hog.yaml (تجربہ 3 - دستی)

بھرنا 80% پوڈ میموری کی حدیں 60 سیکنڈ کے لیے لاگو ہوتی ہیں۔ OOMKill + دوبارہ شروع کرنے کے رویے کو ظاہر کرتا ہے۔

ایک ہی وقت میں تینوں کا اطلاق نہ کریں۔ ایک تجربہ چلائیں، بازیابی کی تصدیق کریں، اور پھر اگلا تجربہ کریں۔

6.5.5: ڈیمو کے بعد کیا دیکھنا ہے (اسے نہ چھوڑیں)

1. افراتفری میں: دستیابی

سگنل	اچھا	برا
curl http://clearledger.local/auth/health	200 جبکہ ایک پوڈ نیچے ہے۔	502/503/وقت ختم
kubectl get pods -l app=auth-service	1 چل رہا ہے + 1 ری سیٹ/زیر التواء (متبادل شروع)	0 چل رہا ہے۔

2. افراتفری کے بعد: بحالی

سگنل	اچھا	برا
پھلیوں کی تعداد	2/2 تیار (اس میں 1-2 منٹ لگ سکتے ہیں — والٹ ایجنٹ کی شروعات)	1 نقل پر پھنس گیا۔
واقعہ	Killing پھر Scheduled / Started ایک نئی پوڈ میں	بار بار کریش لوپ بیک آف
آرگو سی ڈی	مطابقت پذیر	-

3. لٹمس ChaosResult فیصلہ

kubectl get chaosresult -n litmus

پاس کرنے کا معیار:

• /auth/health واپسی 200 افراتفری کے نیزے کے دوران کم از کم ایک بار

• پھلیاں درج ذیل ہیں: مر رہا ہے (واقعہ دیکھیں)

• تعیناتی واپس آتی ہے۔ 2 نقلیں

6.5.6 دستی تجربہ (کامیاب تجربہ 1 کے بعد)

دونوں تصدیقی سروس پوڈ ظاہر ہونے تک انتظار کریں۔ 2/2 تیاریپھر دوڑو ایک اسے ایک بار آزمائیں:

# Experiment 2 — 2s network latency on ledger-service (60s)
kubectl delete chaosengine ledger-service-network-latency -n litmus --ignore-not-found
kubectl apply -f stages/stage-6.5-chaos-engineering/infra/chaos/ledger-service-network-latency.yaml

# Experiment 3 — memory pressure on notification-service (60s)
kubectl delete chaosengine notification-service-memory-hog -n litmus --ignore-not-found
kubectl apply -f stages/stage-6.5-chaos-engineering/infra/chaos/notification-service-memory-hog.yaml

تجربہ	فائل	کیا چیک کرنا ہے۔
پوڈ کو حذف کریں	auth-service-pod-delete.yaml	قتل کے دوران 200 صحت، پھر 2 کلون۔
نیٹ ورک کی تاخیر	ledger-service-network-latency.yaml	API لامحدود ہینگ کے بجائے 503/ٹائم آؤٹ واپس کرتا ہے۔
میموری سور	notification-service-memory-hog.yaml	Pod OOMKill اور دوبارہ شروع کریں، Redis سبسکرپشن بازیافت کریں۔

تجربے کو منظم کریں۔

kubectl delete chaosengine auth-service-pod-delete -n litmus

6.5.7: اسٹیٹس چیک

make check-65

متوقع: مکمل نمونہ §6.5.3a میں دیکھیں (make check-65 بلاک)۔ کم از کم:

▶ Stage 6.5 Chaos Engineering (LitmusChaos)
  ✓ Litmus subscriber running (UI connected to cluster)
  ✓ auth-service has 2/2 Ready replicas (stable for chaos)
  ...
All checks passed. Ready for the next stage.

مرحلہ 6.5 مکمل: چیک لسٹ

#	چیک کریں	چیک کرنے کا طریقہ
1	لٹمس آپریٹر چل رہا ہے۔	kubectl get pods -n litmus - litmus-* چل رہا ہے
2	نصب تجربہ	kubectl get chaosexperiment pod-delete -n litmus
3	Pod Deletion Demo چلائیں۔	make demo-65 افراتفری کے دوران اسٹیمینا 200
4	بحالی کا مشاہدہ کیا گیا۔	تصدیقی خدمت کی دو نقلیں تیار ہیں۔ قتل/پہلے سے طے شدہ کیس
5	شواہد محفوظ کر لیے گئے ہیں۔	ٹرمینل آؤٹ پٹ run-chaos.sh (DORA artifact)
6	صحت کی جانچ	make check-65 سبز
7	UI انفراسٹرکچر منسلک ہے۔	جائزہ → فعال: 1 (§6.5.2)

ہم نے مرحلہ 6.5 میں کیا سیکھا۔

• پتہ لگانا ≠ لچک: Falco وارننگ HA ثابت نہیں کرتی۔

• نقل + سروس + تحقیقات: کیوں؟ replicas: 2 یہ کاسمیٹک نہیں ہے۔

• افراتفری کا انجن YAML: کوڈ میں اعلانیہ ناکامیوں کا انجیکشن لگانا

• پلیٹ فارم اور ایپ کی نام کی جگہ: Kyverno بلاکس Chaos Runners. clearledgerانجن چل رہا ہے۔ litmus

• ایم ٹی ٹی آر: پوڈ مارنے سے لے کر 2/2 تک تیار وقت (مرحلہ 7 میں گراف کیا گیا ہے)

اب آپ اپنے تجربے کی فہرست میں کیا ڈال سکتے ہیں/ایک انٹرویو میں کہہ سکتے ہیں:

ہم نے LitmusChaos (پوڈ ڈیلیٹیشن، نیٹ ورک لیٹنسی، میموری پریشر) کا استعمال کرتے ہوئے افراتفری کے تجربات کیے تاکہ یہ ظاہر کیا جا سکے کہ سسٹم ٹھیک ہو سکتا ہے اور پتہ لگانے اور لچک کے درمیان فرق کر سکتا ہے۔

make snapshot STAGE=65 && make snapshots. چیک کریں clearledger.stage65. دیکھیں کہ اپنی ترقی کو کیسے بچایا جائے۔

مرحلہ 7 - حفاظتی مشاہدہ

سیکورٹی کی پیمائش یا ثابت نہیں کیا جا سکتا.

یہاں مقصد یہ سمجھنا ہے کہ میٹرکس، لاگز اور ڈیش بورڈز ایک ساتھ کیسے فٹ ہوتے ہیں۔ پھر ٹرمینل میں کمانڈ چلا کر اور گرافانا میں ظاہر ہونے والے انہی واقعات کا مشاہدہ کرکے، ہر پینل کا مطلب بتاتے ہوئے اسے ثابت کریں۔

یہ مرحلہ "Grafana انسٹال کریں اور آگے بڑھیں" مرحلہ نہیں ہے۔ مرحلہ 7 اس وقت تک مکمل نہیں ہوتا جب تک کہ ڈیش بورڈ اصل Kyverno کی خلاف ورزی اور Falco الرٹ جو کہ مرحلہ 7.4 میں متحرک نہیں ہوتا، نیز پورٹ فولیو اسکرین شاٹ (§7.6) دکھاتا ہے۔ make check-7 یہ صرف ثابت کرتا ہے کہ اسٹیک کام کر رہا ہے۔ یہ ثابت نہیں کرتا کہ سیکورٹی کے واقعات کا پتہ لگایا جا سکتا ہے۔

شروع کرنے سے پہلے: make check-6 آپ کو پاس کرنا ہوگا (مرحلہ 6.5 اختیاری ہے؛ بلا جھجھک اسے چھوڑ دیں)۔ یقینی بنائیں کہ VM اوورلوڈ نہیں ہے۔ multipass exec clearledger -- uptime. اگر آپ نے اسٹیج 6.5 چلایا ہے، تو لٹمس کو کم کرنے کے لیے پہلے §7.0 پرفارم کریں۔ تقریباً آدھے دن کا منصوبہ بنائیں۔ یہ واحد نوڈ VM پر سب سے بھاری قدم ہے۔

§7.6 مکمل ہونے کے بعد، آپ کا کام ہو گیا۔ ڈیش بورڈ خالی پینل کے بجائے Kyverno مسترد اور Falco وارننگ دکھاتا ہے۔ پھر make check-7 (§7.7)، make snapshot STAGE=7اور make snapshots (چیک کریں clearledger.stage7)۔

پہلے سے انسٹال ہے؟ اگر kubectl get pods -n monitoring مجھے گرافانا دکھائیں۔ 3/3 اور لوکی 1/1§7.1 کو چھوڑیں۔ §7.2 (اسٹیک چیک) سے شروع کریں اور پھر §7.4 (ہینڈز آن لیب) پر جائیں۔

آپ کو پہلے کیا جاننے کی ضرورت ہے۔

اب تک، کلسٹر کے لیے ہر قدم کی اپنی کھڑکی تھی۔ مرحلہ 3 میں، CI اسکین کے نتائج GitHub ایکشنز کو فراہم کیے گئے تھے۔ فیز 4 نے Kyverno کو ٹرمینلز کی غلط تعیناتی کو روکتے ہوئے دکھایا۔ مرحلہ 6 میں، Falco وارننگز UI میں فراہم کی گئی تھیں اور انہیں کسی بھی وقت متحرک کیا جا سکتا ہے۔ kubectl logs فورڈ کو۔ یہ خیالات مفید ہیں لیکن بکھرے ہوئے ہیں۔

مرحلہ 7 یہ سب ایک جگہ پر اکٹھا کرتا ہے۔ گرافانا. پانچ ٹولز کے درمیان چھلانگ لگانے کے بجائے، آپ ایک ڈیش بورڈ کھول سکتے ہیں اور سیکیورٹی کے واقعات، پالیسی کی خلاف ورزیوں، اور ایپ کی صحت کو دیکھ سکتے ہیں جیسا کہ وہ وقت کے ساتھ ہوتے ہیں۔

تین ٹولز لگائے جا رہے ہیں۔

پرومیتھیس اپنے کلسٹر سے نمبرز جمع کریں، جیسے کہ "گزشتہ گھنٹے میں Kyverno کے مسترد ہونے کی تعداد" یا "HTTP درخواستیں فی سیکنڈ۔" ان نمبروں کو ہر 15 سے 30 سیکنڈ میں چیک کریں اور ایک ریکارڈ رکھیں جسے آپ گراف کر سکتے ہیں۔

پتھریلی لاگ لائنیں جمع کریں۔ یہ اسی قسم کا متن ہے جسے آپ نیچے دیکھ رہے ہیں۔ kubectl logsلیکن یہ ایک ہی وقت میں متعدد پھلیوں میں ہوتا ہے۔ Falco وارننگز، لاگ ان کی ناکام کوششیں، اور ایپلیکیشن کی غلطیاں سبھی یہاں دکھائے جاتے ہیں تاکہ آپ انہیں بعد میں بازیافت کر سکیں۔

گرافانا ایک ویب UI جس کے چارٹس اور ٹیبلز پرومیتھیس اور لوکی سے ڈیٹا کھینچتے ہیں۔ یہ آڈیٹر کو دکھایا جائے گا۔ یہ ایک بار کا ٹرمینل اسکرین شاٹ نہیں ہے، یہ اس بات کا ثبوت ہے کہ آپ واقعات کے رونما ہونے کے بعد انہیں تلاش اور پیمائش کر سکتے ہیں۔

پرومیتھیس جادوئی طور پر نہیں جانتا کہ کیا جمع کرنا ہے۔ سروس مانیٹرز اور پوڈ مانیٹر چھوٹے کنفیگریشن آبجیکٹ ہیں جو درست ہدف کی طرف اشارہ کرتے ہیں۔
اگر Kyverno کے پاس مانیٹر نہیں ہے تو Kyverno کا ڈیش بورڈ خالی رہے گا چاہے Kyverno ٹھیک سے کام کر رہا ہو۔ درخواست کی درخواست کی شرحوں پر بھی یہی لاگو ہوتا ہے۔ وہ پینل §7.5 تک خالی رہے گا، جب میٹرکس سے چلنے والی تصاویر GitOps کے ذریعے تعینات کی جائیں گی۔

لاگز اسی طرح کے راستے پر چلتے ہیں۔ Fromtale کنٹینر لاگز پڑھیں اور انہیں لوکی کو بھیجیں۔ اگر لوکی نہیں چل رہا ہے، تو گرافانا لاگ پینل "کوئی ڈیٹا نہیں" دکھائے گا۔ kubectl logs یہ اب بھی انفرادی پھلیوں کے لیے کام کرتا ہے۔

یہ اس چیز سے کیسے جوڑتا ہے جو آپ پہلے ہی بنا چکے ہیں؟

جب آپ بری چیزوں کو روکتے ہیں۔ kubectl apply مرحلہ 4 میں، Kyverno نے اس مسترد کو ریکارڈ کیا۔ مرحلہ 7 آپ کو دکھائے گا۔ Kyverno پالیسی کی خلاف ورزی ڈیش بورڈ (Prometheus کے ذریعے)۔

فالکو نے ایک الرٹ لکھا جب ہم نے پوڈ کے اندر شیل کو مرحلہ 6 میں متحرک کیا۔ مرحلہ 7 میں سیکیورٹی ایونٹ کی ٹائم لائن (لوکی کے ذریعے)۔

جب ClearLedger HTTP ٹریفک یا لاگ ان کی ناکامیوں پر کارروائی کرتا ہے، تو متعلقہ واقعات ہوتے ہیں۔ سروس کی حیثیت ڈیش بورڈ (لوکی اور پرومیتھیس کے ساتھ)۔

والٹ (مرحلہ 5) اور نیٹ ورک پالیسیاں (مرحلہ 6) کے ہمیشہ اپنے پینل نہیں ہوتے ہیں، لیکن وہ اب بھی اہم ہیں۔ گٹ کی کم خفیہ اور مسدود پوڈ ٹریفک بالواسطہ طور پر صحت مند، پرسکون کلسٹرز کو دکھائی دیتی ہے۔

اس مرحلے میں کیا کرنا ہے

ٹرمینل میں ایک کمانڈ چلائیں (مثلاً Kyverno breach or Falco trigger)، پھر ایک لمحہ انتظار کریں جب تک Prometheus یا Loki واقعات کو اکٹھا کریں۔ مماثل Grafana پینل تقریباً 15 سے 90 سیکنڈ میں اپ ڈیٹ ہو جائے گا۔

یہ حفاظتی مشاہدے کا جوہر ہے۔ ٹرمینل ثابت کرتا ہے کہ واقعہ ایک بار پیش آیا، اور ڈیش بورڈ ثابت کرتا ہے کہ کوئی واقعہ رونما ہو سکتا ہے۔ احساس اور پیمائش آپ اسے بعد میں اس عین وقت پر کلسٹر میں لاگ ان کیے بغیر کر سکتے ہیں۔

7.0: مفت نوڈ وسائل (لٹمس کمی)

مرحلہ 6.5 مکمل ہو گیا ہے۔ لٹمس UI، ​​MongoDB، یا افراتفری آپریٹرز کو چلانے کی ضرورت نہیں ہے جب کہ Prometheus، Loki، اور Grafana شروع ہوتے ہیں۔ سنگل نوڈ لیب VMs (6 بذریعہ ڈیفالٹ، دیکھیں) اسی CPU کے لیے مقابلہ کرتے ہیں۔ scripts/setup-cluster.sh)۔

لٹمس کو 0 میں ایڈجسٹ کرنے سے ~500-800MB RAM خالی ہو جاتی ہے اور مشاہداتی تنصیب سے پہلے CPU چرن کم ہو جاتی ہے۔

kubectl scale deployment,statefulset -n litmus --replicas=0 --all
kubectl get pods -n litmus
# Expected: no Running pods (Succeeded job pods from chaos experiments are OK)
multipass exec clearledger -- uptime
# Expected: load average (1m) ideally below ~8 before continuing

اگر آپ افراتفری کا تجربہ دوبارہ چلانا چاہتے ہیں تو آپ لٹمس بیک اپ کو بعد میں بڑھا سکتے ہیں (bash stages/stage-6.5-chaos-engineering/scripts/install-litmus.sh)۔ 7 سے 7.5 مراحل کے لیے، پیمانہ نیچے رکھیں۔

7.1: مشاہداتی اسٹیک کو انسٹال کرنا

کئی بار چلانا محفوظ ہے۔ اسکرپٹ چیک کرتا ہے کہ پہلے سے کیا انسٹال ہے۔ اگر Grafana، Prometheus، اور Loki ٹھیک ہیں، بھاری تنصیب کو چھوڑ دیں اور صرف ڈیش بورڈ اور سکریپ کنفیگریشن کو اپ ڈیٹ کریں۔ جزوی ناکامی کے بعد دوبارہ چلنا ٹاسک اسٹیک کو ڈپلیکیٹ یا ٹوٹتا نہیں ہے۔

صرف شامل کریں۔ FORCE=1 اگر آپ ہیلم ویلیوز فائل میں ترمیم کرتے ہیں اور یہ درحقیقت مسائل کا باعث بنتا ہے، مثال کے طور پر اگر آپ کو مکمل دوبارہ انسٹال کرنے کی ضرورت ہے یا لوکی ری اسٹارٹ لوپ میں کریش ہوتا رہتا ہے:

FORCE=1 bash stages/stage-7-observability/scripts/install-observability.sh

اگر یہ آپ کی پہلی تنصیب ہے، تو ذیل میں مرحلہ 1 میں عام کمانڈ استعمال کریں۔ استعمال نہ کریں FORCE=1 جب تک کہ ٹربل شوٹنگ سیکشن میں ایسا کرنے کی ہدایت نہ کی جائے۔

macOS، Linux، اور WSL2: FORCE=1 bash ... یہ تحریری طور پر کام کرتا ہے۔

مقامی ونڈوز پاور شیل میں وہ نحو استعمال نہیں کرتا۔

اندر سے اپنی لیب چلائیں۔ WSL2 اوبنٹو (تجویز کردہ) یا پہلے متغیر کو سیٹ کریں: $env:FORCE=1; bash stages/stage-7-observability/scripts/install-observability.sh.

مرحلہ 1: تنصیب (اسکرپٹ کے پرنٹ ہونے کا انتظار کریں۔ ✓ Stage 7 installed.):

bash stages/stage-7-observability/scripts/install-observability.sh

اگر آپ اسٹیج 7 کی تنصیب کے دوران "Witing for Falco" دیکھتے ہیں، تو یہ متوقع ہے۔

آپ نے پہلے ہی مرحلہ 6 میں Falco انسٹال کیا ہے۔ مرحلہ 7 دوسرا Falco شامل نہیں کرتا ہے۔ خیال اس بات کو یقینی بنانا ہے کہ آپ کا موجودہ Falco سیٹ اپ آپ کے مشاہداتی اسٹیک کو لاگ اور میٹرکس فراہم کر سکتا ہے۔

بہاؤ مندرجہ ذیل ہے:

• Falco اب بھی ہے falco نام کی جگہ۔

• پرومٹیل فالکو لاگز لوکی کو بھیجتا ہے۔

• گرافانا لوکی سے اپنے نوشتہ جات پڑھتا ہے۔

• سیکیورٹی ایونٹ ٹائم لائن ڈیش بورڈ Falco الرٹس دکھاتا ہے۔

تنصیب کے فوراً بعد، گرافانا پینل خالی ہو سکتا ہے۔ یہ عام بات ہے۔ ڈیش بورڈ میں کوئی بھی نیا مواد ظاہر ہونے سے پہلے §7.4 کو ایک نیا الرٹ متحرک کرنا چاہیے۔

مرحلہ 2. چیک فورڈ (مرحلہ 1 مکمل ہونے کے بعد چلائیں):

kubectl get pods -n monitoring

میں کچھ ایسا چاہتا ہوں (پوڈ نام کے لاحقے مختلف ہوتے ہیں):

NAME                                              READY   STATUS    RESTARTS   AGE
kube-prometheus-stack-grafana-....                3/3     Running   0          5m
kube-prometheus-stack-prometheus-....             2/2     Running   0          5m
loki-0                                            1/1     Running   0          5m
loki-promtail-....                                1/1     Running   0          5m

گرافانا دکھانا ہے۔ 3/3 تیار (2/3 نہیں)۔ لوکی کو مجھے دکھانے کی ضرورت ہے۔ 1/1. اگر پھلیاں اب بھی باقی ہیں۔ Pending یا ContainerCreatingچند منٹ انتظار کریں اور اسے چلائیں۔ kubectl get pods -n monitoring دوبارہ

متوقع - لوکی صحت مند:

kubectl exec -n monitoring loki-0 -- wget -qO- http://127.0.0.1:3100/ready

ready

متوقع - گرافانا لوکی تک پہنچ سکتا ہے (اسی راستے لاگ پینل کا استعمال کرتے ہوئے)۔

kubectl exec -n monitoring deploy/kube-prometheus-stack-grafana -c grafana -- 
  wget -qO- --timeout=5 http://loki:3100/ready

ready

متوقع - Grafana UI قابل رسائی:

curl -sI http://grafana.local | head -n 1

HTTP/1.1 302 Found

لاگ ان http://grafana.local: admin / admin123

تنصیب کے فوراً بعد خالی پینل عام. آپ نے ابھی تک کوئی ایونٹ نہیں بنایا ہے۔ §7.2–§7.4 کے ساتھ جاری رکھیں۔

اگر ہیلم ناکام ہوجاتا ہے: 30 سیکنڈ انتظار کریں، پھر FORCE=1 bash stages/stage-7-observability/scripts/install-observability.sh. دیکھیں troubleshooting.md. Stage 7.

ہینڈ آن چیک پوائنٹ: یقینی بنائیں کہ آپ کے پاس لوکی اور آپ کا ڈیش بورڈ تیار ہے۔

گرافانا کو کھولنے سے پہلے، چیک کریں کہ کون سا لاگنگ اسٹیک اور ڈیش بورڈ اصل میں انسٹال ہے۔

سنگل نوڈ VM پر، گرافانا ٹھیک لگ سکتا ہے جب کہ لوکی ایک لوپ میں کریش ہو جاتا ہے یا ClearLedger ڈیش بورڈ لوڈ نہیں ہوتا ہے۔ اگر آپ اس چیک کو چھوڑ دیتے ہیں، تو ہو سکتا ہے کہ آپ مرحلہ 7 کا بقیہ حصہ خالی پینل کو ڈیبگ کرنے میں صرف کریں۔

چلائیں:

kubectl get pods -n monitoring
kubectl get pods -n monitoring -l app.kubernetes.io/name=loki 
  -o jsonpath="{.items[*].status.containerStatuses[*].restartCount}{"n"}"
kubectl get configmap -n monitoring -l clearledger_dashboard=1 --no-headers | wc -l

متوقع:

• تمام مانیٹرنگ پوڈز Running

• گرافانا شو 3/3 تیار

• راکی شو 1/1 تیار

• لوکی دوبارہ شروع ہونے کی تعداد یہ ہے: 0یا کم ہے اور نہیں بڑھ رہا ہے۔

• ڈیش بورڈز کی تعداد درج ذیل ہے: 6

لوکی دوبارہ شروع ہوتا رہتا ہے یا ڈیش بورڈ کی گنتی کم ہوجاتی ہے۔ 0یہاں رکیں اور جاری رکھنے سے پہلے اپنی انسٹالیشن میں ترمیم کریں۔ خالی گرافانا پینل کا عام طور پر یہ مطلب نہیں ہوتا ہے کہ سیکیورٹی ایونٹ ناکام ہو گیا ہے، بلکہ یہ کہ لوکی یا ڈیش بورڈ غائب ہے۔

7.2: Prometheus، Loki، اور Grafana کو چیک کرنا (ڈیش بورڈ کھولنے سے پہلے)

اس بات کا تعین کرنے کے لیے کہ پینل کے خالی ہونے پر کن پرتوں کو نقصان پہنچا ہے، درج ذیل تین چیکس چلائیں:

چیک 1: پرومیتھیس کے پاس کیورنو میٹرکس ہیں۔

kubectl exec -n monitoring deploy/kube-prometheus-stack-grafana -c grafana -- 
  wget -qO- 'http://kube-prometheus-stack-prometheus.monitoring:9090/api/v1/query?query=kyverno_admission_requests_total' 2>/dev/null 
  | head -c 400

(Prometheus ایک StatefulSet pod کے طور پر چلتا ہے، تعیناتی نہیں۔ یہ سوالات Grafana کے ذریعے Prometheus کی خدمت میں جاتے ہیں۔)

متوقع: JSON "status":"success" اور "metric" بلاک (قدر ہے 0 §7.4 جب تک خلاف ورزی نہیں ہوتی)۔

اگر آپ دیکھتے ہیں "status":"success" لیکن "result":[]Prometheus شروع ہو چکا ہے، لیکن Kyverno نے ابھی تک اس کا داخلہ ریکارڈ نہیں کیا ہے۔ یہ لیب کے سامنے ٹھیک ہے۔

چیک 2: لوکی کے پاس فالکو لاگ ہیں۔

kubectl exec -n monitoring loki-0 -- wget -qO- 
  'http://127.0.0.1:3100/loki/api/v1/labels' 2>/dev/null | head -c 300

متوقع: JSON فہرست لیبل اس طرح: "namespace" (اور فالکو ایونٹ کے بعد "falco" لیبل کی قیمت میں)۔

ایک فوری لاگ تلاش (§7.4 مشق B تک خالی لائنیں واپس کر سکتے ہیں):

kubectl exec -n monitoring loki-0 -- wget -qO- 
  'http://127.0.0.1:3100/loki/api/v1/query?query=%7Bnamespace%3D%22falco%22%7D&limit=3' 2>/dev/null 
  | head -c 500

متوقع: "status":"success". "result":[] اس کا مطلب ہے کہ لوکی کے پاس ابھی تک Falco لائن نہیں ہے، جس کا مطلب ہے کہ یہ ٹوٹی ہوئی لوکی نہیں ہے۔

چیک 3: گرافانا نے ClearLedger ڈیش بورڈ درآمد کیا ہے۔

curl -s -u admin:admin123 'http://grafana.local/api/search?tag=clearledger' | jq -r '.[].title'

متوقع: 6 عنوانات:

ClearLedger - Compliance Posture
ClearLedger - DORA Metrics
ClearLedger - Kubernetes Audit Log Analysis
ClearLedger - Kyverno Policy Violations
ClearLedger - Security Event Timeline
ClearLedger - Service Health + Auth Security

یا UI میں: جاؤ۔ کوڈیش بورڈ پھر ٹیگز کو فلٹر کریں۔ clearledger. آپ کو بالکل مندرجہ ذیل 6 دیکھنا چاہئے (کوئی نام غائب نہیں):

7.3: گرافانا میں پہلے 10 منٹ

یہ سیکشن صرف ایک ٹور ہے۔ ہم نے ابھی تک کچھ ثابت نہیں کیا۔

تمام اسٹیج 7 کے اصول: خالی پینل کا عام طور پر مطلب یہ ہوتا ہے کہ منتخب وقت کی حد میں کوئی واقعہ پیش نہیں آیا اور اس کا مطلب یہ نہیں ہے کہ گرافانا کرپٹ ہے۔ ہم اصل واقعہ §7.4 میں تیار کرتے ہیں۔

مرحلہ 1: گرافانا کھولیں۔

تحریک http://grafana.local اور لاگ ان کریں:

• صارف کا نام: admin

• پاس ورڈ: admin123

مرحلہ 2: وقت کی حد مقرر کریں۔

اوپر دائیں طرف آخری 15 منٹ.

اس ترتیب کو تمام 7 مراحل کے لیے رکھیں۔ گزشتہ 24 گھنٹے آپ سنگل نوڈ لیب VMs پر لوکی کو اوورلوڈ کر سکتے ہیں۔

مرحلہ 3: ایک وقت میں ایک ڈیش بورڈ کھولیں۔

ایک ڈیش بورڈ کھولیں، اسے دریافت کریں، اور پھر اگلے ڈیش بورڈ پر جائیں۔ ایک ہی وقت میں تمام چھ نہ کھولیں۔

1. Kyverno پالیسی کی خلاف ورزی: ​​لیول 4 پالیسی بلاک۔

2. سیکیورٹی ایونٹ کی ٹائم لائن: اسٹیج 6 میں فالکو الرٹس۔ آپ پرانا مواد دیکھ سکتے ہیں۔ postgres لاگ ٹیبل شور مچا ہوا ہے۔

3. سروس ہیلتھ + توثیق: ایپ ٹریفک اور لاگ ان کی کوششیں۔

4. تعمیل کی حیثیت: آڈیٹرز کے لیے ایک خلاصہ نظریہ۔ سکیم کریں اور §7.4 کے بعد واپس آئیں۔

5. آڈٹ لاگ تجزیہ: ڈیزائن کے لحاظ سے MicroK8s پر خالی (آڈٹ پائپ لائن بطور ڈیفالٹ فعال نہیں ہے)۔

6. DORA میٹرکس: تعیناتی فریکوئنسی چارٹ۔ ڈیٹا اکٹھا کرنے کے لیے ایک سے زیادہ CI رنز درکار ہیں۔ جب آپ اسے پہلی بار دیکھیں گے تو یہ خالی نظر آ سکتا ہے۔ اختیاری

اس گائیڈ میں مختصر ڈیش بورڈ کا لنک استعمال کریں۔ لمبے بے ترتیب سلگس والے پرانے بک مارک URLs سے پرہیز کریں۔

آپ اسے Grafana میں بھی تلاش کر سکتے ہیں۔ ڈیش بورڈ پھر ٹیگز تلاش کریں۔ clearledger.

مرحلہ 4: آپ جو دیکھتے ہیں اسے کیسے پڑھیں

گرافانا پینل دو جگہوں سے ڈیٹا کھینچتا ہے۔

• پرومیتھیس وقت کے ساتھ نمبر دکھاتا ہے، جیسے Kyverno کی خلاف ورزیوں کی تعداد اور درخواست کی شرح۔

• پتھریلی لاگ لائنز دکھاتا ہے جیسے Falco وارننگز اور تصدیقی سروس کے پیغامات۔

نمبروں کا ایک بڑا پینل پوچھتا ہے۔ کیا یہ نمبر 0 سے زیادہ ہے؟

ایک لائن چارٹ مندرجہ ذیل سوالات پوچھتا ہے: کیا آپ کو کبھی کچھ چلانے کے بعد اسپائک ہوا ہے؟

لاگ پینل اصل متن دکھاتا ہے، جیسے کہ اصول کا نام۔ CRITICALیا Failed login attempt.

اگر صرف لاگ پینل ظاہر ہوتا ہے۔ connection refusedلوکی کو §7.1 میں دوبارہ چیک کریں۔

اگر نمبر پینل کام کرتا ہے لیکن لاگ پینل ناکام ہوجاتا ہے، تو مسئلہ غالباً لوکی کا ہے نہ کہ خود گرافانا۔

مرحلہ 5: جاری رکھیں

ڈیش بورڈز 1-3 کھولیں، پھر §7.4 کے ساتھ جاری رکھیں۔

یہاں سے آپ ٹرمینل میں کمانڈز چلا سکتے ہیں اور اصل سیکیورٹی ایونٹس کے ساتھ پینل اپ ڈیٹ دیکھ سکتے ہیں۔

7.4: ہینڈ آن لیب: ٹرمینل → ڈیش بورڈ پروف

یہ بنیادی سیکھنے کا سیکشن ہے۔ ہر مشق کے لیے، کمانڈ چلائیں، انتظار کریں، اور گرافانا میں چیک کریں۔

ٹائمنگ: انتظار کرو 30~90 سیکنڈ Prometheus scraping اور Loki جمع کرنے کے لئے ہر حکم کے بعد.

اس مشق کو کرنے کے دو طریقے

آپشن 1: نیچے دی گئی واک تھرو پر عمل کریں (سیکھنے کے لیے تجویز کردہ)

ہر کمانڈ کو براہ راست چلائیں اور پھر گرافانا کو چیک کریں۔ یہ مشقیں A، B اور C ہیں۔

آپشن 2: گائیڈڈ اسکرپٹ استعمال کریں۔

اسکرپٹ انہی مراحل کو چلا سکتا ہے اور توقف کر سکتا ہے، گرافانا کو ان کے درمیان چیک کرنے دیتا ہے۔

bash stages/stage-7-observability/scripts/generate-dashboard-data.sh

یا:

make demo-7

دونوں حکم ایک ہی کام کرتے ہیں۔ اسکرپٹ کچھ اس طرح کہتا ہے کہ "Kyverno ڈیش بورڈ کو چیک کریں اور پھر Enter دبائیں"۔ گرافانا پر سوئچ کریں، پینل دیکھیں، پھر واپس آئیں اور انٹر دبائیں۔

کیا آپ چاہتے ہیں کہ یہ بغیر کسی رکاوٹ کے چلے؟ (آپ کے ہاتھوں پر تیز اور کم)

SKIP_PROMPT=1 make demo-7

ہر قدم کو سمجھنے کے لیے آپشن 1 کا استعمال کریں۔ اگر آپ مشق کرنا چاہتے ہیں تو آپشن 2 استعمال کریں۔ SKIP_PROMPT=1 اگر آپ تیزی سے ڈیٹا بنانا چاہتے ہیں۔

مشق A: Kyverno Block → Prometheus → Kyverno Dashboard

ٹرمینل: مرحلہ 4 پالیسی کی خلاف ورزی کرنے والے پوڈز کو نافذ کریں (روٹ کے طور پر چلائیں)۔

cat <<'YAML' | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: stage7-kyverno-lab
  namespace: clearledger
spec:
  containers:
    - name: test
      image: nginx:alpine
YAML

یہ کیسے چیک کریں کہ آیا اس نے کام کیا:

ہم جانچ کر رہے ہیں کہ آیا یہ Kyverno ہے۔ بلاک جان بوجھ کر برا پھلی. کامیابی کا مطلب ہے فورڈ کبھی نہیں بنایا.

پاس آپ کو درج ذیل کو چیک کرنا چاہئے:

• ٹرمینل پرنٹ کرے گا۔ Error from server اور denied the request

• غلطی میں صحیح پالیسی کا نام اہم نہیں ہے۔ آؤٹ پٹ ایک قاعدہ یا متعدد قواعد کی فہرست دے سکتا ہے (disallow-root-containers, require-resource-limits, drop-all-capabilities…)۔ مزید لائنوں کا مطلب ہے کہ مزید قواعد ناکام ہوئے اور پھر بھی گزر گئے۔

• پوڈ کا نام کلسٹر میں ظاہر نہیں ہوتا ہے۔

kubectl get pods -n clearledger | grep stage7-kyverno-lab

متوقع: کوئی آؤٹ پٹ نہیں ہے۔

اگر یہ ناکام ہوجاتا ہے: پہلے مرحلہ 4 کو روکیں اور درست کریں۔

اس کا مطلب ہے Kyverno کو جڑ کی پھلی سے گزرنے کی اجازت دینا۔ چلائیں make check-4 مرحلہ 7 کے ساتھ جاری رکھنے سے پہلے۔

ٹرانزٹ ٹرمینل کی مثال (آپ کی پالیسی میں مزید پالیسیاں درج ہو سکتی ہیں):

Error from server: error when creating "STDIN": admission webhook "validate.kyverno.svc" denied the request:
policy disallow-root-containers/validate-run-as-non-root fail: Running as root is not allowed

یقینی بنائیں کہ پرومیتھیس نے اسے دیکھا ہے۔ (اختیاری، لیکن اگر گرافانا خالی ہو تو مفید):

kubectl exec -n monitoring deploy/kube-prometheus-stack-grafana -c grafana -- 
  wget -qO- 'http://kube-prometheus-stack-prometheus.monitoring:9090/api/v1/query?query=kyverno_admission_requests_total{request_allowed="false"}' 2>/dev/null 
  | grep -o '"value":[[^]]*]' | head -3

متوقع: کوئی راستہ نہیں "value" حالیہ یونکس ٹائم اسٹیمپ اور نمبرز پر مشتمل آئٹمز 0 سے زیادہ (مثال کے طور پر "value":[..., "1"])۔ اس کو دیکھتے ہوئے، Kyverno اور Prometheus کام کر رہے ہیں یہاں تک کہ جب Grafana پینل کہتا ہے: کوئی ڈیٹا نہیں.

گرافانا: Kyverno پالیسی کی کھلی خلاف ورزی۔

آپ کیا ثابت کرتے ہیں: آخری ردِ عمل گرافانا میں ظاہر ہوا۔ تمام پینلز کو آن کرنے کی ضرورت نہیں ہے۔ آپ کی ضرورت ہے ایک واضح نشانی Kyverno بلاکس کا حساب لگایا جا رہا ہے۔

مرحلہ 1: فوری حیثیت کی جانچ (اوپر کی قطار، بائیں سے دائیں)

1. پالیسی کی خلاف ورزی (وقت کی حد): بڑی تعداد پاس شدہ: 1 یا زیادہ دکھاتا ہے۔ یہ ناکام کہتا ہے: کوئی ڈیٹا نہیں۔

2. خلاف ورزی (وقت کی حد): ایک ہی خیال، دوسرا کاؤنٹر۔ پاس: 1 یا اس سے زیادہ۔

3. فعال Kyverno قواعد — عام طور پر 18۔ جب یہ نمبر ظاہر ہوتا ہے، گرافانا پرومیتھیئس سے بات کر سکتا ہے۔ یہ بھی اچھا ہے اگر پہلے دو پینل ابھی بھی خالی ہوں۔

مرحلہ 2: اگر اوپر کے دو نمبر آپ کے لیے کام کرتے ہیں، تو چارٹ کو اسکین کریں۔

• وسائل کی قسم کے لحاظ سے خلاف ورزی کی شرح (درمیانی چارٹ): دوڑتے وقت، Pod کے لیبل والے bumps کو دیکھیں۔ kubectl apply.

• سب سے اوپر مسدود وسائل کی اقسام (نیچے ٹیبل بائیں): پوڈ قطار تلاش کریں۔

• نام کی جگہ کی خلاف ورزیاں (رجحانات) (نیچے دائیں چارٹ): Clearledger کے لیے bumps تلاش کریں۔

چارٹس میں تاخیر ہو سکتی ہے۔ مرحلہ 1 میں، آگے بڑھنے کے لیے 0 سے بڑا نمبر کافی ہے۔ چارٹ §7.6 اسکرین شاٹ کے لیے بونس کا ثبوت ہے۔

اگر اوپر والے دو پینل کہتے ہیں کہ 'کوئی ڈیٹا نہیں' لیکن ٹرمینل مسترد کام کر رہا ہے:

یہ عام بات ہے۔ وہ پینل اہم ہے۔ نیا یہ اس مدت کے دوران مسترد ہونے کی تعداد ہے، ریکارڈ کی گئی کل تعداد نہیں۔ گرافانا کے جوابی اقدام سے پہلے کبھی کبھی پرومیتھیس کو ایک رد عمل مل جاتا ہے۔

اسے آزمائیں:

1. اسی طرح چلائیں kubectl apply دوبارہ حکم (دوبارہ مسترد، جس کی توقع ہے)۔

2. 60 سیکنڈ انتظار کریں۔

3. ریفریش پر کلک کریں (سرکلر تیر، اوپر دائیں)۔

دوسرے مسترد ہونے کے بعد، آپ کو اعداد و شمار کے اوپری پینل میں 2 نظر آئے گا۔ §7.6 کے لیے اسکرین شاٹ۔

کیا یہ اب بھی خالی ہے؟ ایکسپلور کو اپنے بیک اپ ثبوت کے طور پر استعمال کریں۔

1. گرافانا بائیں مینو → نیویگیشن

2. ڈیٹا ماخذ: پرومیتھیس

3. گوندھنا: sum(kyverno_admission_requests_total{request_allowed="false"})

4. Query چلائیں پر کلک کریں۔

پاس: نتیجہ 1 یا 2 ہے۔

نیویگیشن کے اسکرین شاٹس اور ٹرمینل مسترد ہونے والے نمبروں کو 0 سے زیادہ دکھانا پورٹ فولیو ثبوت سمجھا جاتا ہے، چاہے ڈیش بورڈ کے اعدادوشمار سست رہیں۔

مشق B: Falco Shell → Loki → سیکیورٹی ایونٹ ٹائم لائن

آپ کیا کر رہے ہیں (وہی خیال جیسا کہ ورزش A):

• ورزش A: تم نے کچھ برا کیا، کیورنو نے اسے روکا، گرافانا نے اسے روکا۔ کیبرنو ڈیش بورڈ کو اپ ڈیٹ کر دیا گیا ہے۔

• ورزش B: اگر چلتے ہوئے پوڈ کے اندر کوئی مشتبہ سرگرمی ہوتی ہے، تو Falco اس کا پتہ لگائے گا اور Grafana کرے گا۔ سیکیورٹی ایونٹ کی ٹائم لائن اپ ڈیٹ کریں۔

آپ نے پہلے ہی یہ مرحلہ 6 میں کیا ہے (make demo-6)۔ ہم یہاں یہ ثابت کرنے کے لیے دوبارہ کرتے ہیں کہ انتباہ Grafana کے ساتھ ساتھ Grafana میں بھی ظاہر ہوتا ہے۔ http://falco.local.

ایک سطری کہانی: فرض کریں کہ آپ اندر سے شیل تک رسائی کے ساتھ حملہ آور ہیں۔ auth-service: Falco کو چیخنا چاہئے اور چیخ کو ٹائم لائن ڈیش بورڈ پر ظاہر ہونا چاہئے۔

مرحلہ 1: الرٹ کو متحرک کریں (ٹرمینل طریقہ)

ایک حملہ آور اندر داخل ہونے کا ڈرامہ کر رہا ہے۔ auth-service میں نے ایک فوری کمانڈ چلایا (id) چیک کریں کہ آپ کس کے بطور لاگ ان ہیں۔ مجھے اس پر شک ہے۔ فالکو نے اسے پکڑنا ہے۔

نیچے دیا گیا بلاک تین کمانڈز کو ترتیب سے دکھاتا ہے۔ پورے بلاک کو کاپی اور پیسٹ کریں۔

AUTH_POD=$(kubectl get pod -n clearledger -l app=auth-service 
  --field-selector=status.phase=Running -o jsonpath="{.items[0].metadata.name}")
echo "Using pod: $AUTH_POD"
kubectl exec -n clearledger "$AUTH_POD" -c auth-service -- /bin/sh -c 'id && exit'

ہر سطر کا کردار درج ذیل ہے:

1. لائن 1: چل رہا نام تلاش کریں۔ auth-service اسے پوڈ میں محفوظ کریں AUTH_POD.

2. لائن 2: آپ چیک کر سکتے ہیں کہ اس نے اپنا نام پرنٹ کر کے ٹھیک سے کام کیا ہے (یہ خالی نہیں ہے)۔

3. لائن 3: پھانسی /bin/sh -c 'id && exit' اندر وہ پھلی. یہ ایک جعلی 'حملہ' ہے۔ فالکو اس طرح کے خول کا مشاہدہ کرتا ہے۔

پاس: آؤٹ پٹ کو صرف ان دو لائنوں کی ضرورت ہے:

Using pod: auth-service-77b7d9cd99-xxxxx
uid=1000 gid=1000 groups=1000

مرحلہ 1 اب مکمل ہو گیا ہے۔ پھلی ابھی تک چل رہی ہے۔ تم نے کچھ نہیں توڑا۔

ناکامی: مرحلہ 2 سے پہلے رکیں اور درست کریں۔

چلائیں kubectl get pods -n clearledger -l app=auth-service اگر آپ کو ایک پوڈ نظر آئے تو دوبارہ کوشش کریں۔ چل رہا ہے.

مرحلہ 2: چیک کریں کہ آیا Falco نے اسے دیکھا (ٹرمینل، فوری طور پر)

Falco لاگز ایک لمبی JSON لائن ہیں۔ پوری چیز پڑھنے کی کوشش نہ کریں۔ چلائیں:

kubectl logs -n falco -l app.kubernetes.io/name=falco --tail=50 | grep -i 'Shell spawned'

لائن کے ساتھ کہیں گزریں آپ کو ایک مختصر جملہ نظر آئے گا۔

Shell spawned in ClearLedger container ... pod=auth-service-... cmd=sh -c id && exit

یا اصول کا نام:

"rule":"Shell Spawned in ClearLedger Container"

ایک گریپ ہٹ کا مطلب ہے کہ ورزش B نے ٹرمینل میں کام کیا۔ اپنے پورٹ فولیو کے لیے اس لائن کو اسکرین شاٹ کریں۔

نظر انداز کرنا:

• Defaulted container "falco" out of: ...: جنرل کیوبیکٹل شور

• لائن کی معلومات postgres-0 اور /etc/passwd: سطح 6 پس منظر کا شور، ٹیسٹ نہیں۔

• باقی JSON (output_fields, k8smetaوغیرہ)۔ تجزیہ کرنے کی ضرورت نہیں ہے۔

اگر grep کچھ بھی پرنٹ نہیں کرتا ہے: مرحلہ 1 دوبارہ چلائیں، 5 سیکنڈ انتظار کریں، اور دوبارہ grep چلائیں۔

مرحلہ 3: یقینی بنائیں کہ لوکی نے اسے محفوظ کیا ہے۔ (پہلے تقریباً 60 سیکنڈ انتظار کریں۔)

اب تک کی کہانی:

مرحلہ 3 پوچھتا ہے: کیا وہ لاگ لائن کامیاب تھی؟ پتھریلی گرافانا کا لاگ ڈیٹا بیس کیا ہے؟

فالکو گرافانا کے ساتھ براہ راست بات چیت نہیں کرتا ہے۔ پرومٹیل فالکو کے لاگز کو لوکی میں کاپی کرتا ہے۔ اس کاپی میں 60 سے 90 سیکنڈ لگیں گے۔ مرحلہ 1 کے بعد، انتظار کریں اور اس چیک کو چلائیں۔

اس کمانڈ میں درج ذیل افعال ہیں:

"لوکی کو تلاش کریں Falco لاگ کے لیے جس میں شامل ہیں: Shell spawnedمنتخب کریں اور پھر صرف مذکورہ لائنوں کو ڈسپلے کریں۔ auth-service"

kubectl exec -n monitoring loki-0 -- wget -qO- 
  'http://127.0.0.1:3100/loki/api/v1/query?query=%7Bnamespace%3D%22falco%22%2Ccontainer%3D%22falco%22%7D%20%7C%3D%20%22Shell%20spawned%22&limit=3' 2>/dev/null 
  | grep -i 'auth-service'

پاس: مجھے دونوں میں ایک لائن نظر آتی ہے۔ auth-service اور Shell spawned. اس کا مطلب ہے کہ لوکی کو آپ کی وارننگ مل جائے گی اور گرافانا آپ کو دکھا سکتا ہے۔

ناکامی (گمراہ کن پاس): آپ grep ClearLedger اکیلے جاؤ اور مارو postgres-0 پڑھنا /etc/passwd. یہ اسٹیج 6 کا پس منظر کا شور ہے، شیل ٹیسٹنگ نہیں۔ ہمیشہ اسے تلاش کریں۔ auth-service.

کیا آؤٹ پٹ خالی ہے؟ یہ ٹھیک ہے اگر آپ نے مرحلہ 2 پاس کیا، مرحلہ 4 پر جاری رکھیں. یا تو Promtail اب بھی پکڑ سکتا ہے یا JSON اس تیز گریپ کے لیے بہت لمبا ہے۔ گرافانا اکثر ایک انتباہ دکھاتا ہے یہاں تک کہ جب یہ کمانڈ کچھ بھی پرنٹ نہ کرے۔

مرحلہ 4: گرافانا کھولیں۔

سیکیورٹی ایونٹس کی ٹائم لائن کھولیں۔

یہ آپ کا ڈیش بورڈ ہے۔ سب سے اوپر عنوان ہونا چاہئے: ClearLedger - سیکیورٹی ایونٹ کی ٹائم لائن۔

پینل کو دیکھنے سے پہلے:

1. وقت کی حد: آخری گھنٹے (اوپر دائیں)

2. آٹو ریفریش: آف

3. اگر شیل کمانڈ چند منٹ سے زیادہ پرانی ہے تو، مرحلہ 1 کو دوبارہ چلائیں۔

4. 90 سیکنڈ انتظار کریں اور ریفریش پر کلک کریں۔

آپ کو کچھ اس طرح نظر آئے گا (یہ عام بات ہے):

• اہم اطلاع (1 گھنٹہ): بڑی تعداد جیسے 1.08K. یہ زیادہ تر ہے۔ postgres-0 پڑھنا /etc/passwd لوپ میں (پس منظر کے شور کی 6 سطحیں)۔ ہاں ~ نہیں اس کا مطلب ہے کہ آپ ناکام ہو گئے۔

• قاعدے کے نام سے الرٹس (پائی چارٹ): غلبہ ClearLedger میں حساس فائلوں کو پڑھنا. یہ بھی نارمل ہے۔

• حالیہ خطرہ/انتباہی واقعات: پوسٹگریس کی بہت سی قطاریں ہیں۔ آپ کا شیل انتباہ وہاں ہے، لیکن یہ دفن ہے.

ٹاپ ٹائم لائن (Falco Alerts by Priority - ٹائم لائن) آپ بھی کہہ سکتے ہیں۔ کوئی ڈیٹا نہیں. یہ ایک معروف خصوصیت ہے۔ گھبرائیں نہیں، اس کے بجائے لاگ پینل اور براؤزر سرچ کا استعمال کریں۔

اسے کیسے تلاش کریں۔ آپ کا انتباہات (اس ڈیش بورڈ سے):

1. جاری رکھیں ClearLedger - سیکیورٹی ایونٹ کی ٹائم لائن - نیویگیشن نہیں، ٹیمپو نہیں۔

2. اندر کلک کریں۔ حالیہ خطرہ/انتباہی واقعات (دائیں لاگ لسٹ)

3. دبائیں کمانڈ + ایف (میک) یا Ctrl+F (ونڈوز/لینکس)۔

4. تلاش کریں auth-service یا Shell spawned.

اگر تلاش میں آپ کے پوڈ کا ذکر کرنے والی قطار ملتی ہے، شیل کی تخلیقاسکرین شاٹ لیں۔

غلط جگہیں (عام غلطیاں): گرافانا دریافت کریں ڈیٹا کے ذرائع شامل کریں۔ رفتار ڈسپلے ledger-service ثبوت کہ مرحلہ 7.5 (OpenTelemetry)، ورزش B نہیں۔ ٹیمپو Falco سیکیورٹی وارننگز کے بجائے درخواست کے نشانات دکھاتا ہے۔

مشق B پاس کریں (ایک کو منتخب کریں):

1. بہترین: مرحلہ 2 A ٹرمینل grep ظاہر ہوتا ہے۔ Shell spawned اور کہ سیکیورٹی ایونٹ کی ٹائم لائن تلاش کے نتائج کو لاگ کریں۔ auth-service / Shell spawned - دونوں اسکرین شاٹس۔

2. یہ بھی ٹھیک ہے: مرحلہ 2 grep اسکرین شاٹ پلس کہ سیکیورٹی ایونٹ کی ٹائم لائن ڈیش بورڈ اہم اطلاع (1 گھنٹہ) نمبر دکھائیں (یہ ثابت کرتا ہے کہ Falco → Loki → Grafana اس وقت بھی کام کرتا ہے جب پوسٹگریس شور میں شیل لائنیں دفن ہوں)

3. فال بیک (صرف اس صورت میں جب ڈیش بورڈ کی تلاش ناکام ہو جائے): مرحلہ 2 grep پلس گرافانا دریافت کریں ڈیٹا سورس شامل کریں۔ پتھریلی (ٹیمپو نہیں):

   • بائیں مینو پر جائیں۔ دریافت کریں

   • اوپر بائیں ڈیٹا سورس ڈراپ ڈاؤن: منتخب کریں۔ پتھریلی

   • سوال: {namespace="falco", container="falco"} |= "Shell spawned"

   • کلک کریں استفسار پر عمل درآمد

   • اس طرح ایک لائن تلاش کریں: auth-service

§7.6 سے اسکرین شاٹ۔

ایکسرسائز C: لاگ ان، لوکی، اور سروس ہیلتھ میں ناکام

کہانی: کوئی آپ کے لاگ ان API پاس ورڈ کا اندازہ لگا رہا ہے۔
ٹرمینل نے 10 غلط لاگ ان کوششیں بھیجیں۔ auth-service لکھنا Failed login attempt لاگ میں. گرافانا سروس ہیلتھ + توثیق سیکیورٹی اسے دکھانا چاہئے کہ گنتی بڑھ رہی ہے۔

A اور B جیسا ہی پیٹرن: ٹرمینل ایکشنز، پھر لاگز، پھر ڈیش بورڈ۔

مرحلہ 1: لاگ ان کی غلط کوشش بھیجیں (ٹرمینل)

پورے بلاک کو کاپی اور پیسٹ کریں۔

for i in $(seq 1 10); do
  curl -s http://clearledger.local/auth/health >/dev/null
  curl -s -X POST http://clearledger.local/auth/login 
    -H 'Content-Type: application/json' 
    -d '{"email":"lab-attacker@evil.com","password":"wrong"}' >/dev/null
done
echo "done"

پاس: آپ کو صرف آؤٹ پٹ کی ضرورت ہے:

done

کوئی آؤٹ پٹ نہیں ہے۔ curl لائن نارمل ہے۔ لوپ مارا /auth/health (ایپ کو گرم رکھیں) اور /auth/login میں نے 10 بار غلط پاس ورڈ درج کیا۔

ناکام: curl: (6) Could not resolve host. چلائیں bash scripts/setup-hosts.sh میک پر۔ curl: (7) Failed to connect. چیک کریں kubectl get pods -n clearledger -l app=auth-service.

مرحلہ 2: تصدیق کریں کہ تصدیق کی خدمت نے اسے ریکارڈ کیا ہے۔

kubectl logs -n clearledger -l app=auth-service --tail=30 | grep -i 'Failed login' | tail -3

پاس آپ کو اس طرح کی لائن دیکھنا چاہئے:

Failed login attempt for email: lab-attacker@evil.com

آپ کو متعدد لائنیں نظر آ سکتی ہیں (ایک سطر فی ناکام کوشش)۔ ایک لائن کافی ہے۔ یہاں آپ کے پورٹ فولیو کا اسکرین شاٹ ہے۔

اگر grep کچھ بھی پرنٹ نہیں کرتا ہے: تقریباً 10 سیکنڈ انتظار کریں اور اسے دوبارہ چلائیں۔ اگر یہ اب بھی خالی ہے تو چیک کریں کہ تصدیقی پوڈ چل رہا ہے۔ kubectl get pods -n clearledger -l app=auth-service.

مرحلہ 3: گرافانا کھولیں (مرحلہ 1 کے بعد ~ 60 سیکنڈ انتظار کریں)

سروس اسٹیٹس + توثیق سیکیورٹی کھولیں۔

یہ آپ کا ڈیش بورڈ ہے۔ عنوان میں کیا کہنا چاہئے ClearLedger - سروس ہیلتھ + توثیق سیکیورٹی.

1. وقت کی حد: آخری گھنٹے

2. خودکار ریفریش: بند کر دیں

3. کلک کریں ریفریش ایک بار

چیک کرنے کے لیے چیزیں (صرف ایکسرسائز C):

1. لاگ ان کی ناکام کوششیں (1 گھنٹہ): بڑی تعداد پاس: > 0. یہ آپ کا اہم ثبوت ہے۔

2. لاگ ان ناکامی لاگ اسٹریم: پینل پر لکیریں ریکارڈ کریں۔ پاس: لائن Failed login attempt یا lab-attacker@evil.com. استعمال کریں کمانڈ + ایف اگر ضروری ہو تو پینل کے اندر۔

وہ پینل جو خالی ہونے کی صورت میں نظر انداز کیے جا سکتے ہیں:

آپ ایکسرسائز C پاس کر لیں گے اگر آپ: دو اسکرین شاٹس:

اسکرین شاٹ 1 (ضروری): مرحلہ 2 ٹرمینل آؤٹ پٹ ظاہر ہوتا ہے۔ Failed login attempt for lab-attacker@evil.com. اس سے ثابت ہوتا ہے کہ ایپ نے غلط لاگ ان کیا ہے۔

اسکرین شاٹ 2 (ایک کو منتخب کریں):

• اختیار A: کہ لاگ ان کی ناکام کوششیں (1 گھنٹہ) ایک پینل جو 0 سے زیادہ نمبر دکھاتا ہے، جیسے 10)۔ اس سے ثابت ہوتا ہے کہ گرافانا نے ناکامی کا حساب لگایا۔

• اختیار B: کہ لاگ ان ناکامی لاگ اسٹریم پینل لائنیں دکھا رہا ہے۔ lab-attacker@evil.com. یہ طریقہ استعمال کریں اگر بڑی تعداد کا پینل ابھی بھی خالی ہے، لیکن لاگ اسٹریم میں ای میلز موجود ہیں۔

آپ کو اسکرین شاٹ 1 اور آپشن A یا آپشن B کی ضرورت ہوگی۔ §7.6 کافی ہے۔

مشق D: تعمیل ڈیش بورڈ (آڈیٹر کا خلاصہ)

آپ کیا کر رہے ہیں: ایک ڈیش بورڈ کھولیں جو A, B اور C کی مشقیں کرتا ہے۔ یہ "آڈیٹر کا نشان" کا منظر ہے۔ داخلہ کنٹرول، رن ٹائم کا پتہ لگانا، اور ایپلیکیشن سیکیورٹی سب ایک اسکرین پر۔

جب: A، B اور C مکمل کرنے کے بعد ہی۔

مرحلہ 1: اپنا ڈیش بورڈ کھولیں۔

تعمیل کرنسی

سیٹ آخری گھنٹےآٹو ریفریش بند کر دیںکلک کریں ریفریش.

مرحلہ 2: اوپری قطار کے اعدادوشمار چیک کریں۔

آپ کے ڈیش بورڈ میں اعدادوشمار	مقامی	پاس
پالیسی کی خلاف ورزی	ورزش A (Kyberno)	> 0
رن ٹائم دھمکیاں	ورزش بی (فالکو)	> 0 (پوسٹگریس شور کی گنتی - ٹھیک ہے)
تصدیق کی ناکام کوشش	مشق C (غلط لاگ ان)	> 0

تینوں کو بڑی تعداد میں ہونے کی ضرورت نہیں ہے۔ انہیں صرف کرنا ہے 0 سے زیادہ جانچ کے بعد۔

اگر ایک اعداد و شمار اب بھی 0 ہے: وہ مشق (A، B، یا C) دوبارہ کریں، 90 سیکنڈ انتظار کریں، اور پھر تازہ دم کریں۔ پالیسی کی خلاف ورزیوں کے لیے دوسری Kyverno کو مسترد کرنے کی ضرورت پڑ سکتی ہے، جیسے کہ Exercise A۔

یہ §7.6 کا اسکرین شاٹ #3 ہے۔ ایک واحد فریم جو گہرائی میں دفاع کو ثابت کرتا ہے۔

پریکٹس چیک پوائنٹ: کیا آپ نے واقعی مرحلہ 7 مکمل کیا ہے؟

گرافانا انسٹال کرنا مقصد نہیں ہے۔ پتہ لگانے کا مطلب ہے کہ آپ ایک حقیقی واقعہ کو متحرک کرسکتے ہیں اور اسے اپنے ڈیش بورڈ میں دیکھ سکتے ہیں۔

اختیاری ٹرمینل تصدیق (ثابت کرتا ہے کہ گرافانا منسلک ہے):

curl -s -u admin:admin123 'http://grafana.local/api/search?tag=clearledger' | jq -r '.[].title'

curl -s -u admin:admin123 'http://grafana.local/api/datasources' | jq -r '.[].name'

جب آپ پہلی کمانڈ چلاتے ہیں، تو آپ کو ڈیش بورڈ کے چھ نام نظر آئیں گے۔

• ClearLedger - Kyverno پالیسی کی خلاف ورزی

• ClearLedger - سیکیورٹی ایونٹ کی ٹائم لائن

• ClearLedger - سروس ہیلتھ + توثیق سیکیورٹی

• ClearLedger - تعمیل کرنسی

• ClearLedger - Kubernetes آڈٹ لاگ تجزیہ

• ClearLedger - DORA اشارے

دوسری کمانڈ کو کم از کم درج ذیل دکھانا چاہئے:

کیا مطلب یہ نہیں ہے کہ یہ ہو گیا ہے؟

make check-7 یہ صرف اس بات کی تصدیق کرتا ہے کہ مانیٹرنگ پوڈ چل رہا ہے۔ گرین آؤٹ پٹ ہوتا ہے۔ ~ نہیں §7.4 کو بدل دیتا ہے۔

کیا جائے اس کا کیا مطلب ہے؟

میں نے §7.4 میں A, B اور C کی مشقیں کیں اور §7.6 کا اسکرین شاٹ محفوظ کیا۔

1. Kyverno سے انکار کریں (ٹرمینل + ڈیش بورڈ)

2. فالکو شیل الرٹس (ٹرمینل + سیکیورٹی ایونٹ ٹائم لائن)

3. لاگ ان ناکام (ٹرمینل + سروس اسٹیٹ)

4. تعمیل کی صورتحال کا خلاصہ (تمام تینوں اعدادوشمار 0 سے زیادہ)

ایک بار جب آپ کے پاس یہ چار اسکرین شاٹس ہوں تو، مرحلہ 7 مکمل ہو جاتا ہے۔

7.5: درخواست کی شرح کا چارٹ بنانا (اختیاری)

مرحلہ 7 میں ضروری نہیں ہے۔ یہ سیکشن ایکسرسائزز A-C اور §7.6 اسکرین شاٹس کے لیے درکار نہیں ہے۔ اگر آپ جاری رکھنا چاہتے ہیں تو چھوڑ دیں۔

نیز، یہ اسٹیج 7.5 (OpenTelemetry/Tempo) جیسا نہیں ہے۔ یہ ذیلی سیکشن سروس کی طرف سے درخواست کی شرح یہ سروس ہیلتھ ڈیش بورڈ کا چارٹ ہے۔

اس سیکشن کا مقصد:

سروس ہیلتھ + توثیق سیکیورٹی میں لاگ ان ناکامی پینل لوکی میں کام کرتا ہے۔ سروس چارٹ کے ذریعہ درخواست کی شرح کچھ مختلف کی ضرورت ہے۔ ایپ پوڈز /metrics ایک اختتامی نقطہ فراہم کرتا ہے تاکہ Prometheus درخواستوں کی تعداد کو ختم کر سکے۔

کوڈ پہلے سے ہی ذخیرہ میں ہے (app/*/prom_metrics.py)۔ Prometheus پہلے سے ہی اس کو کھرچنے کے لیے ترتیب دیا گیا ہے (clearledger-podmonitor.yaml)۔ عام مسئلہ: کلسٹر اب بھی ایک پرانی تصویر چلا رہا ہے اس سے پہلے کہ اس کے کوڈ کو تعمیر میں شامل کیا گیا تھا۔

مرحلہ 1: چیک کریں کہ آیا انڈیکیٹر پہلے سے موجود ہے (30 سیکنڈ)

پہلے اسے چلائیں۔ اگر یہ گزر جاتا ہے تو باقی §7.5 کو چھوڑ دیں۔

kubectl exec -n monitoring deploy/kube-prometheus-stack-grafana -c grafana -- 
  wget -qO- 'http://kube-prometheus-stack-prometheus.monitoring:9090/api/v1/query?query=http_requests_total' 2>/dev/null 
  | grep -o '"__name__":"http_requests_total"' | head -1

پاس: پرنٹس "__name__":"http_requests_total". سروس اسٹیٹس کو کھولنا، ریفریش کرنا، اور سروس چارٹ کے ذریعہ درخواستوں کی شرح میں پہلے سے ہی لائنیں ہونی چاہئیں۔

کوئی آؤٹ پٹ نہیں: مرحلہ 2 کے ساتھ جاری رکھیں۔

مرحلہ 2: بے نقاب تصاویر تعینات کریں۔ /metrics

براہ کرم ایک راستہ منتخب کریں۔

راستہ A: GitOps (اگر آپ نے 1 اور 2 مراحل سے CI/CD استعمال کیا ہے)

1. عزم کو آگے بڑھائیں۔ main یہ ایپ اسٹور میں ہے۔

2. نئی تصویر بنانے اور اپ ڈیٹ کرنے کے لیے CI کا انتظار کریں۔ clearledger-infra.

3. ArgoCD ظاہر ہونے تک انتظار کریں۔ مطابقت پذیر اور صحت مند Clearledger ایپ میں

4. مرحلہ 3 پر جائیں۔

راستہ B: لیبز پر جائیں (تیز، صرف مقامی)

export DOCKER_USERNAME=your-dockerhub-user
bash stages/stage-7-observability/scripts/build-metrics-images.sh

یہ تینوں خدمات کے لیے میٹرکس سے چلنے والی تصاویر بناتا، آگے بڑھاتا اور رول آؤٹ کرتا ہے۔

الارم: ArgoCD Self-Repair ان تصویری ٹیگز کو منٹوں میں واپس کر سکتا ہے اگر: clearledger-infra یہ اب بھی پرانے ٹیگ کی طرف اشارہ کرتا ہے۔ یہ ایک سادہ ہینڈ آن ڈیمو کے لیے ٹھیک ہے۔ جاری ترمیم کے لیے، پاتھ A کا استعمال کریں یا انفراسٹرکچر ریپوزٹری کو اپ ڈیٹ کریں (§2 رول بیک نوٹس دیکھیں)۔

مرحلہ 3: پہنچنے والے میٹرکس کو چیک کریں (رول آؤٹ کے بعد ~60 سیکنڈ)

kubectl exec -n clearledger deploy/auth-service -c auth-service -- 
  wget -qO- http://127.0.0.1:8000/metrics 2>/dev/null | head -5

پاس: سے شروع ہونے والی لکیریں۔ # HELP یا http_requests_total.

پھر چیک کریں کہ کیا پرومیتھیس اسے دیکھ سکتا ہے۔

kubectl exec -n monitoring deploy/kube-prometheus-stack-grafana -c grafana -- 
  wget -qO- 'http://kube-prometheus-stack-prometheus.monitoring:9090/api/v1/query?query=http_requests_total' 2>/dev/null 
  | grep -o '"__name__":"http_requests_total"' | head -1

پاس: "__name__":"http_requests_total"

کچھ ٹریفک پیدا کریں (دوبارہ ورزش C curl loops یا http://clearledger.local/auth/health چند بار)، 60 سیکنڈ تک انتظار کریں، اور پھر اسے کھولیں۔ سروس ہیلتھ + توثیق سیکیورٹی اور تازہ دم کریں۔ سروس کی طرف سے درخواست کی شرح آپ کو اس کے لئے لائنیں دیکھنا چاہئے: auth-service, ledger-serviceیا notification-service.

کب روکنا ہے:

• درخواست کی شرح اب بھی خالی ہے لیکن لاگ ان ناکامی پینل کام کر رہا ہے؟ مرحلہ 7 اب مکمل ہو گیا ہے۔ درخواست کی شرح اچھی ہے۔

• Prometheus استفسار گزر جاتا ہے لیکن چارٹ خالی ہے؟ مدت میں توسیع کریں۔ آخری گھنٹےٹریفک بنائیں، 60 سیکنڈ انتظار کریں، اور پھر ریفریش کریں۔

7.6: مرحلہ 7 کی تکمیل (اسکرین شاٹ + تصدیق مکمل)

تقریباً ہو چکا ہے۔ یہ سیکشن بتاتا ہے کہ اپنے شواہد کو کیسے محفوظ کیا جائے اور پھر آگے بڑھیں۔

کیا یہ واقعی ختم ہو گیا ہے؟

گرافانا کھولنا اور چھ ڈیش بورڈز کو دیکھنا کافی نہیں ہے۔ make check-7 صرف گزر جانا کافی نہیں ہے۔ اس سے صرف یہ ثابت ہوتا ہے کہ پھلی چل رہی ہے۔

§7.4 چلانے کے بعد، میں نے پینل کے اپ ڈیٹ ہونے کا انتظار کیا اور کلسٹر سے تین اسکرین شاٹس محفوظ کر لیے۔

اگر پینل خالی ہے یا صرف پرانا پوسٹگریس شور دکھاتا ہے تو پہلے §7.4 پر واپس جائیں۔

ہر اسکرین شاٹ سے پہلے: وقت کی حد کو اس پر سیٹ کریں۔ آخری 15 منٹ (یا آخری گھنٹے مشق B)۔ فریم میں ٹائم چننے والا اور پینل ٹائٹل شامل ہے۔

اسکرین شاٹ 1: فالکو الرٹ (ورزش بی)

سیکیورٹی ایونٹس کی ٹائم لائن کھولیں۔

قبضہ حالیہ خطرہ/انتباہی واقعات اگر آپ کے پاس کوئی سطر ہے جس کا تذکرہ ہے: Shell spawned یا auth-service. اگر پوسٹگریس لائن اسے دفن کرتی ہے تو لاگ پینل کے اندر Cmd+F استعمال کریں۔ یہ اب بھی اہم ہے۔

اسکرین شاٹ 2: Kyverno Rejection (ورزش A)

Kyverno کی پالیسیوں کی خلاف ورزیوں کا انکشاف کریں۔

قبضہ پالیسی کی خلاف ورزی (وقت کی حد) یا خلاف ورزی (وقت کی حد) 1 سے بڑا یا اس کے برابر نمبر دکھاتا ہے۔

اسکرین شاٹ 3: تعمیل کا خلاصہ (ورزش D)

کھلی تعمیل کرنسی۔

اوپری قطار کو کیپچر کریں جہاں تینوں اعدادوشمار 0 سے اوپر ہیں۔ پالیسی کی خلاف ورزی, رن ٹائم دھمکیاںاور تصدیق کی ناکام کوشش.

اسکرین شاٹ 4 (اختیاری): لاگ ان میں ناکامی (ورزش C)

سروس اسٹیٹس + توثیق سیکیورٹی کھولیں۔

قبضہ لاگ ان کی ناکام کوششیں (1 گھنٹہ) 0 سے زیادہ یا لاگ ان ناکامی لاگ اسٹریم ڈسپلے lab-attacker@evil.com.

فائل کو مناسب جگہ پر محفوظ کریں، جیسے: docs/evidence/stage-7-screenshot-1-falco.png. ان کا نام لیں اور آپ کو معلوم ہو جائے گا کہ ہر ایک کیا ثابت کرتا ہے۔

حتمی تصدیق: چلائیں make check-7 (§7.7)، VM کو محفوظ کرنا آپ کو مرحلہ 7 کے لیے درخواست دینے کی اجازت دیتا ہے۔

7.7: تصدیق

make check-7

متوقع:

▶ Stage 7 — Observability (Grafana + Prometheus + Loki)
  ✓ Prometheus is running
  ✓ Grafana reachable (http://grafana.local or in-cluster health OK)
  ✓ Loki pod is running (0 restarts)
  ✓ Loki reachable from Grafana (http://loki:3100/ready)
  ✓ ClearLedger alerting rules exist
  ✓ ClearLedger dashboards imported (6 found)

لوکی کے دوبارہ شروع ہونے یا گمشدہ ڈیش بورڈز کے بارے میں انتباہ: براہ کرم مرحلہ 7 مکمل کرنے پر اصرار کرنے سے پہلے §7.1 کو درست کریں۔

VM اسٹوریج §7.6 کے بعد اور make check-7. نیچے مرحلہ 7 کے آخر میں بلاک دیکھیں۔

7.8: کیا مسئلہ تھا (لیب نوٹس + انٹرویو کی جھلکیاں)

ایک جملے میں اسٹیک: Prometheus نمبرز (میٹرکس) اسٹور کرتا ہے، لوکی لاگ لائنز اسٹور کرتا ہے، اور گرافانا دونوں کو بصری طور پر دکھاتا ہے۔ کچھ بھی ظاہر نہیں ہوتا جب تک کہ کلسٹر میں حقیقت میں کچھ نہ ہو۔

آپ کو لیبارٹری میں کس چیز نے پریشان کیا؟

1. تنصیب کے فوراً بعد خالی ڈیش بورڈ: عام گرافانا واقعات پیدا نہیں کرتا ہے۔ §7.4 (Kyverno مسترد، Falco شیل، لاگ ان ناکامی) اس کو متحرک کرتا ہے۔

2. لوکی سست ہوجاتا ہے یا "منسوخ" پر پھنس جاتا ہے: فالکو لاگز بہت بڑے ہیں۔ گزشتہ 24 گھنٹے چھوٹے کلسٹرز اوورلوڈ ہیں۔ استعمال کریں آخری گھنٹےایک وقت میں ایک ڈیش بورڈ منتخب کریں اور 10 سیکنڈ انتظار کریں۔

3. make check-7 پاس ہو گیا لیکن پینل ابھی بھی خالی ہے۔ (صرف لیب چیک لسٹ، انٹرویو کا موضوع نہیں): اس بات کی تصدیق کریں کہ Prometheus/Loki/Grafana Pod اس کی حیثیت کو چیک کر کے کام کر رہا ہے۔ ہاں ~ نہیں اس کا مطلب ہے کہ واقعہ موجود ہے۔ سنیپ شاٹ لینے اور آگے بڑھنے کے لیے آپ کو اب بھی §7.4 + §7.6 کی ضرورت ہے۔

اگر کوئی آپ سے انٹرویو میں اس بارے میں پوچھے۔

کیا آپ کا ڈیش بورڈ خالی ہے؟ گرافانا صرف وہی دکھاتا ہے جو پہلے سے ہوچکا ہے۔ ٹائم رینج میں کوئی ایونٹ نہ ہونے کا مطلب ہے کہ پینل خالی ہے۔ یہ معمول ہے جب تک کہ آپ کچھ نہیں چلاتے۔

کیا لوکی چھوٹے کلسٹرز پر سست ہے؟ فالکو لاگز بہت بڑے ہیں۔ ہم نے وقت کی حدود کو مختصر رکھا (24 گھنٹے کے بجائے 15 منٹ) اور ایک وقت میں ایک ڈیش بورڈ کھولا۔ وہی ٹریڈ آف لاگو ہوتے ہیں جیسے محدود ہارڈ ویئر تیار کرتے وقت۔

آپ نے کیسے ثابت کیا کہ یہ کام کرتا ہے؟ حملہ میں نے خود کیا۔ اس نے غلط پوڈز کو مسترد کر دیا، چلتے ہوئے کنٹینر میں ایک شیل پیدا کیا، اور ایک ناکام لاگ ان بھیجا۔ پھر میں نے گرافانا کو چیک کیا اور میچنگ پینلز کا اسکرین شاٹ لیا۔ ٹرمینل کام پہلے، ڈیش بورڈ ثبوت دوسرا.

مختصر ورژن یہ ہے کہ آپ اسے اونچی آواز میں کہہ سکتے ہیں۔

"ہم نے Kyverno اور Falco کو Grafana سے منسلک کیا۔ اس کو ثابت کرنے کے لیے، ہم نے پالیسی بلاکس اور رن ٹائم الرٹس کو متحرک کیا اور پھر دونوں کو اپنے سیکیورٹی ڈیش بورڈ میں ڈسپلے کیا۔ سنگل نوڈ لیب میں، لوکی ایک وسیع ٹائم رینج میں سست ہوجاتا ہے، اس لیے ہم نے اپنے سوالات کو سخت رکھا۔"

پچھلے مراحل میں پائپ لائن کے مسائل (Trivy, Kyverno, image tags، وغیرہ) docs/troubleshooting.md - آپ کو مرحلہ 7 کے لیے مشق کرنے کی ضرورت نہیں ہے۔

7.9: ریپوزٹری اپ ڈیٹ کے بعد پینل غلط دکھائی دیتا ہے۔

ڈیش بورڈ کو دوبارہ لاگو کرنے کے بعد، حقیقی واقعات (§7.4، جعلی ڈیٹا نہیں) بنائیں۔

bash stages/stage-7-observability/scripts/install-observability.sh
# Then run Exercises A–C from §7.4 (Kyverno denial, Falco shell, failed logins)

اوپن پرنٹ: آخری گھنٹےہر ورزش کے بعد 30-60 سیکنڈ انتظار کریں اور ایک بار تازہ دم کریں۔ ورزش §7.4 ہر ڈیش بورڈ کی متوقع ظاہری شکل کا احاطہ کرتی ہے۔

ہم نے مرحلہ 7 میں کیا سیکھا۔

• پرومیتھیس قابل شمار حفاظتی واقعات کو ثابت کرتا ہے (Kyverno rejections, HTTP کی رفتار)۔

• پتھریلی تفصیلات کا فرانزک ثبوت (فالکو JSON، توثیق لاگ لائن)

• گرافانا یہ ایک بیانیہ پرت ہے، مشق کے بعد تنصیب کا دوسرا مرحلہ نہیں۔

• ٹریک ایبل: ٹرمینل آپریشنز، بیک اینڈ سگنلز، پینل اپڈیٹس

• ServiceMonitors/PodMonitor مراحل 4-6 کو چارٹ سے جوڑتا ہے۔

• خالی ڈیش بورڈ کا مطلب "سیکیورٹی سمجھوتہ" نہیں ہے، اس کا مطلب ہے "ابھی تک کوئی ایونٹ نہیں" یا "وقت کی غلط حد"۔

• تعمیل کرنسی ایک اسکرین سے آڈیٹرز کو جواب دینے کا ایک طریقہ ہے۔

• آپ کے نیٹ ورک کی پالیسی کو واضح طور پر اجازت دینی چاہیے: monitoring پورٹ 8000 پر ایپ پوڈز تک پہنچنے کے لیے نام کی جگہ۔ بصورت دیگر، PodMonitor سکریپنگ خود بخود ناکام ہو جائے گی۔ context deadline exceeded

• Kubernetes آڈٹ لاگ ڈیش بورڈ MicroK8s پر ڈیزائن کے لحاظ سے خالی ہے۔ API سرور آڈٹ پائپ لائن (آڈٹ پالیسی → فائل → پرومٹیل → لوکی) بطور ڈیفالٹ فعال نہیں ہے۔

• درخواست کی شرح کو پوری چین کی ضرورت ہے۔ /metricsپوڈ مانیٹر اور نیٹ ورک کی پالیسیاں: ایک غائب ہونے کا مطلب ہے کہ پینل خالی ہے۔

اب آپ اپنے تجربے کی فہرست میں کیا ڈال سکتے ہیں/ایک انٹرویو میں کہہ سکتے ہیں:

ہم نے Prometheus, Loki, اور Grafana (Kyverno کی خلاف ورزیوں، Falco الرٹس، اور DORA میٹرکس سے متعلق ڈیش بورڈز) کا استعمال کرتے ہوئے حفاظتی مشاہدے کو بنایا ہے اور ٹرمینل سے لے کر ڈیش بورڈ تک سیکیورٹی کے واقعات کی تصدیق کر سکتے ہیں۔

7 مرحلہ مکمل کرنے کی فہرست:

• make check-7 → 6/6 ✓ (6.5 لیول لٹمس ناکامی متوقع: میموری کے استعمال کے لیے کم)

• http://grafana.local/d/clearledger-kyverno-violations. خلاف ورزی کے اعدادوشمار > 0

• http://grafana.local/d/clearledger-security-events. خطرے کا فالکو انتباہی نشان

• http://grafana.local/d/clearledger-compliance. پالیسی کی خلاف ورزیاں + رن ٹائم دھمکیاں + توثیق کی کوشش تمام > 0 ناکام

• http://grafana.local/d/clearledger-service-health. لاگ ان کی ناکام کوششیں > 0۔ درخواست کی شرح > 0 صرف اس صورت میں جب §7.5 کی کارکردگی کا مظاہرہ کیا جائے۔

• پورٹ فولیو اسکرین شاٹس 1-3 محفوظ کر لیے گئے ہیں۔

make snapshot STAGE=7 && make snapshots. چیک کریں clearledger.stage7. اس کو مت چھوڑیں. مرحلہ 7 بھاری ہے، اور ڈسک کمپریشن عام ہے۔ دیکھیں کہ اپنی ترقی کو کیسے بچایا جائے۔

توثیق/لیجر پوڈز میک کے دوبارہ شروع ہونے یا سونے کے بعد ظاہر ہو سکتے ہیں۔ نامعلوم یا ری سیٹ کریں: 0/1 یہاں تک کہ اگر کلسٹر اوپر ہے (دیکھیں Troubleshooting.md)، اپنے میک کو ریبوٹ کریں۔

مرحلہ 7.5 — OpenTelemetry (اختیاری)

آپ اس پورے مرحلے کو چھوڑ سکتے ہیں۔ ہوم لیب کو مکمل کرنے اور مرحلہ 8 پر جانے کے لیے مرحلہ 7 (میٹرکس + لاگز) کافی ہے۔

اسٹیج 7.5 کو صرف اس صورت میں انجام دیں جب آپ پورٹ فولیوز یا انٹرویوز کے لیے تقسیم شدہ ٹریکنگ چاہتے ہیں اور آپ کے VM میں مفت RAM ہے (تقریباً 1.5Gi خالی جگہ)۔

آپ کیا شامل کرتے ہیں

مرحلہ 7 جواب: کیا ہوا؟ (کیورنو نے پوڈ کو بلاک کر دیا، فالکو نے شیل دیکھا، یا لاگ ان ناکام ہو گیا۔)

ٹریکنگ جواب: اس درخواست کے لیے کیا اقدامات کیے گئے، اور ہر قدم کتنے عرصے میں اٹھایا گیا؟

• میٹرکس: درخواستوں کی تعداد، غلطیوں کی تعداد

• لاگ: ایپ لاگ فائل میں کیا پرنٹ کرتی ہے، جیسے غلطیاں، انتباہات، لاگ ان میں ناکامیاں وغیرہ۔)

• ثبوت: لیجر سروس جسے auth-service (12ms) کہتے ہیں، پھر Postgres (8ms)

اس مرحلے میں، آپ ایک حقیقی لین دین بھیجتے ہیں اور پھر اس درخواست کو Grafana Explore (Tempo) میں کھولتے ہیں۔ ہر قدم کو اوقات کے ساتھ درج کیا جاتا ہے: لیجر سروس، تصدیق کی خدمت، پوسٹگریس، وغیرہ۔

اس سے پہلے کہ آپ شروع کریں۔

1. مرحلہ 7 مکمل کریں: §7.4 واک تھرو مکمل کریں، §7.6 اسکرین شاٹ محفوظ کریں، SKIP_CHAOS_CHECK=1 make check-7 یہ گزر جاتا ہے۔

2. اپنی VM میموری چیک کریں۔ multipass exec clearledger -- free -h میں تقریباً 1.5Gi مفت میں چاہتا ہوں۔

3. اگر آپ اسٹیج 6.5 لٹمس چلاتے ہیں، تو پہلے اسکیل نیچے کریں (§7.0)۔

جب آپ Grafana Explore (Tempo ڈیٹا سورس) میں درخواست کا مکمل نشان دیکھیں گے تو آپ کو معلوم ہو جائے گا کہ آپ نے کام کر لیا ہے۔ make check-75 یہ گزر جاتا ہے۔ پھر make snapshot STAGE=75.

اپنے ایپ لاگ میں اس انتباہ کو نظر انداز کریں۔

مرحلہ 7 سے شروع کرتے ہوئے، آپ دیکھیں گے:

WARNING: Transient error StatusCode.UNAVAILABLE encountered while exporting traces

یہ بے ضرر ہے۔ ایپ ٹریکنگ ڈیٹا بھیجنے کے لیے پہلے سے ہی سیٹ اپ ہے، لیکن وصول کنندہ §7.5.3 تک انسٹال نہیں ہوتا ہے۔

آپ کی ایپ اب بھی ٹھیک کام کرے گی، لیکن آپ کا ٹریکنگ ڈیٹا بس ضائع کر دیا جائے گا۔ اگر آپ کلیکٹر کو §7.5.3 میں انسٹال کرتے ہیں، تو وارننگ غائب ہو جاتی ہے۔

ٹریکنگ کو کیسے جوڑیں۔

1. جب کسی درخواست پر عمل درآمد ہوتا ہے تو ایپ ٹریکنگ ڈیٹا بھیجتی ہے۔

2. OTel کلکٹر اس (پورٹ 4317) کو سنتا ہے اور اسے آگے بھیج دیتا ہے۔

3. گرافانا ٹیمپو میں محفوظ شدہ

4. گرافانا ایکسپلور (منتخب ٹیمپو) وہ جگہ ہے جہاں آپ ایک درخواست کے ذریعے قدم بہ قدم چلتے ہیں۔

ایپ ٹیمپو سے براہ راست بات نہیں کرتی ہے، یہ صرف کلکٹر سے بات کرتی ہے۔ یہ آپ کو یہ تبدیل کرنے کی اجازت دیتا ہے کہ بعد میں ایپ کو دوبارہ بنائے بغیر نشانات کہاں محفوظ کیے جاتے ہیں۔

7.5.1: میموری اور لوڈ چیک کریں۔

ٹیمپو کو ~300MB درکار ہے۔ براہ کرم تنصیب سے پہلے خالی جگہ کی جانچ کریں۔

multipass exec clearledger -- free -h    # want ~1.5Gi available
multipass exec clearledger -- uptime      # load should be reasonable for your CPU count
SKIP_CHAOS_CHECK=1 bash scripts/health-check.sh 7

اگر لٹمس اب بھی اسٹیج 6.5 پر چل رہا ہے، تو اسے پہلے نیچے پیمانہ کریں (§7.0)۔

kubectl get pods -n litmus --field-selector=status.phase=Running
# Expected: no resources found

7.5.2: گرافانا ٹیمپو انسٹال کریں۔

ٹیمپو ایک ٹریکنگ اسٹوریج بیک اینڈ ہے۔ اسے انسٹال کریں۔ monitoring Prometheus اور Loki کے آگے نام کی جگہیں:

helm repo add grafana https://grafana.github.io/helm-charts
helm repo update

helm install tempo grafana/tempo 
  --namespace monitoring 
  --set tempo.storage.trace.backend=local 
  --set tempo.storage.trace.local.path=/var/tempo 
  --set persistence.enabled=true 
  --set persistence.size=5Gi 
  --wait

یقینی بنائیں کہ ٹیمپو چل رہا ہے۔

kubectl get pods -n monitoring -l app.kubernetes.io/name=tempo
# Expected: tempo-0   1/1   Running

kubectl exec -n monitoring tempo-0 -- wget -qO- http://localhost:3200/ready
# Expected: ready

7.5.3: Otel کلکٹر اور وائر گرافانا کو تعینات کرنا

یہ OTel کلکٹر پر لاگو ہوتا ہے (جو ایپ پوڈ سے اسکوپ حاصل کرتا ہے) اور سائڈ کار کے ذریعے Tempo کو Grafana ڈیٹا سورس کے طور پر خود بخود رجسٹر کرتا ہے۔

kubectl apply -f stages/stage-7.5-opentelemetry/infra/otel/otel-collector.yaml
kubectl apply -f stages/stage-7.5-opentelemetry/infra/otel/grafana-datasource-tempo.yaml

تصدیق کریں کہ کلکٹر چل رہا ہے۔

kubectl get pods -n monitoring -l app=otel-collector
# Expected: otel-collector-xxxxx   1/1   Running

تصدیق کریں کہ کلکٹر نے شروع کر دیا ہے (ابھی تک نشانات موصول نہیں ہو رہے ہیں)۔

ایپ OTLP کے ذریعے اسکوپس کو کلکٹر تک پہنچاتی ہے۔ کلکٹر پھلی کو نہیں نوچتا ہے۔ اس مرحلے پر، آپ کو بس یہ یقینی بنانا ہے کہ آپ سن رہے ہیں۔

kubectl logs -n monitoring deploy/otel-collector --tail=15
# Expected:
#   Starting GRPC server ... endpoint: 0.0.0.0:4317
#   Starting HTTP server ... endpoint: 0.0.0.0:4318
#   Everything is ready. Begin running and processing data.
# No crash loops or repeated errors.

اس بات کا ثبوت کہ ٹریس دراصل بہہ رہا ہے بعد میں آتا ہے۔ §7.5.6 میں ٹریفک پیدا کرنے کے بعد، پھیلی ہوئی برآمدی لائنوں کے لیے کلکٹر لاگ کو یہاں پر چیک کریں: debug ایکسپورٹ کریں اور پھر گرافانا ٹیمپو (§7.5.7) میں ٹریس چیک کریں۔

7.5.4: Prometheus ریموٹ رائٹ ریسیور کو فعال کریں۔

OTel کلکٹر بھی OTel میٹرکس کو ریموٹ رائٹ کے ذریعے Prometheus کو منتقل کرتا ہے۔ پرومیتھیس کو یہ قبول کرنا چاہیے۔

helm upgrade kube-prometheus-stack prometheus-community/kube-prometheus-stack 
  --namespace monitoring 
  -f stages/stage-7-observability/infra/helm/kube-prometheus-stack-values.yaml 
  --wait

اس پر لاگو ہوتا ہے: enableRemoteWriteReceiver: true اسٹیج 7.5 میں ہیلم ویلیوز میں سیٹنگز شامل کی گئیں۔ Prometheus کے دوبارہ شروع ہونے کا انتظار کریں (تقریباً 60 سیکنڈ)۔

7.5.5: تصدیق کریں کہ ایپ پوڈ کلکٹر سے منسلک ہے۔

تقسیم clearledger-infra میرے پاس پہلے ہی موجود ہے۔ OTEL_EXPORTER_OTLP_ENDPOINT سیٹ جب کلیکٹر چلتا ہے، پھلی خود بخود جڑ جاتی ہے۔

تصدیق کریں کہ OTEL وارننگ غائب ہو گئی ہے۔

kubectl logs -n clearledger deploy/ledger-service -c ledger-service --tail=20 2>/dev/null 
  | grep -v "opentelemetry|otlp|Transient" | tail -10
# Expected: only INFO request logs, no WARNING: Transient error

اگر وارننگ برقرار رہتی ہے، تو ہو سکتا ہے آپ کے پاس آپ کی نیٹ ورک پالیسی میں پورٹ 4317 آؤٹ گوئنگ نہ ہو۔ تازہ ترین پالیسیوں کا اطلاق کریں۔

kubectl apply -f infra/deferred-by-stage/stage-6-runtime-security/netpol/network-policies.yaml

7.5.6: ٹریس بنانا

اب ایک ٹرانزیکشن بنائیں اور دیکھیں کہ یہ پورے سسٹم میں کیسے بہتا ہے۔

# Step 1: register (skip if already registered)
curl -s -X POST http://clearledger.local/auth/register 
  -H "Content-Type: application/json" 
  -d '{"email":"trace-demo@clearledger.io","password":"TracePass123"}' | python3 -m json.tool

# Step 2: login and grab the token
TOKEN=$(curl -s -X POST http://clearledger.local/auth/login 
  -H "Content-Type: application/json" 
  -d '{"email":"trace-demo@clearledger.io","password":"TracePass123"}' 
  | python3 -c "import sys,json; print(json.load(sys.stdin)['access_token'])")
echo "Token acquired: ${TOKEN:0:20}..."

# Step 3: create a transaction (this is the request you will trace)
curl -s -X POST http://clearledger.local/ledger/transactions 
  -H "Authorization: Bearer $TOKEN" 
  -H "Content-Type: application/json" 
  -d '{"amount": 5000, "direction": "credit"}' | python3 -m json.tool

کلکٹر کے ذریعہ موصول ہونے والی مدت کی جانچ کریں۔

kubectl logs -n monitoring deploy/otel-collector --tail=30 
  | grep -iE "Traces|spans|ResourceSpans" || echo "No span lines yet — see §7.5.5 (OTEL env / netpol)"
# Expected after a successful transaction: debug exporter lines mentioning exported traces/spans

7.5.7: گرافانا میں ٹریس دیکھیں

کھلا http://grafana.local پھر بائیں سائڈبار پر جائیں۔ دریافت کریں (کمپاس آئیکن)۔

مرحلہ 1: ایک ٹیمپو منتخب کریں اور تلاش کھولیں۔

استفسار ونڈو کے اوپری حصے میں:

1. ڈیٹا سورس ڈراپ ڈاؤن (اورنج چائے لوگو) → رفتار

2. A (ٹیمپو) → 3 ٹیبز کا لیبل لگا سوال کی قطار: تلاش | TraceQL | سروس گراف

3. کلک کریں تلاش کریں. ایک ڈراپ ڈاؤن فلٹر ظاہر ہوگا۔ ٹریس کیو ایل صرف ایک ٹیکسٹ باکس ہے۔ اگر میں کچھ داخل کیے بغیر اترتا ہوں تو مجھے درج ذیل نتیجہ ملتا ہے: 0 series returned.

مرحلہ 2: سروس کے لحاظ سے فلٹر کریں۔

پر تلاش کریں ٹیگ:

• سروس کا نام ← درج کریں یا منتخب کریں۔ ledger-service

• دائرہ کار کا نام، حیثیت، مدت، اور ٹیگز کو ابھی کے لیے خالی چھوڑ دیں۔

• گرافانا آپ کو چلانے کے لیے استفسار دکھاتا ہے۔ {resource.service.name="ledger-service"}

وقت کی حد (اوپر دائیں گھڑی کا آئیکن) اس پر سیٹ کریں: آخری 15 منٹ لہذا، §7.5.6 ٹرانزیکشنز شامل ہیں۔

مرحلہ 3: استفسار کو چلائیں۔

گرافانا کو دریافت کریں۔ کوئی 'رن استفسار' بٹن نہیں ہے۔: ایک سروس منتخب کریں اور نتائج خود بخود ظاہر ہوں گے۔ اگر میز خالی ہے۔ نیلے ریفریش بٹن ونڈو کے اوپری دائیں کونے میں۔

مرحلہ 4: ٹریس فالس کھولیں۔

استفسار ایڈیٹر کے تحت، تلاش کریں: ٹیبل - ٹریکنگ. آپ کو درج ذیل کی طرح کم از کم ایک قطار نظر آنی چاہئے:

گرمی	ہاں
ٹریکنگ آئی ڈی	5730edf3… (نیلا لنک)
وقت شروع	جب آپ بھاگتے ہیں curl
سروس	ledger-service
نام	POST /transactions
جاری رکھیں	~200ms (صارف کے لحاظ سے مختلف ہو سکتے ہیں)

ٹریکنگ آئی ڈی کے لنک پر کلک کریں۔ دائیں پینل ٹریک کی تفصیلات کا منظر کھولتا ہے۔

آپ کو ٹریکنگ تفصیلات کے منظر میں کیا نظر آتا ہے۔

ہیڈر: ledger-service: POST /transactions

• ٹریکنگ آئی ڈی: اس درخواست کے لیے منفرد ID

• جاری رکھیں: کل آخر سے آخر تک کا وقت

• سروس: 2 (ledger-service اور auth-service عام لین دین کے لیے)

ٹائم لائن میں دائرہ کار کو وسعت دیں۔

ledger-service   POST /transactions          (~total duration)
  ├── auth-service   GET /verify             ← JWT check over HTTP
  ├── ledger-service INSERT / sqlalchemy    ← Postgres write
  └── (optional) redis PUBLISH              ← only if amount ≥ notification threshold

ٹریکنگ تفصیلات کی سکرین پڑھیں:

ہر قطار درخواست میں ایک قدم ہے (گرافانا اسے بطور استعمال کرتا ہے۔ مدت)۔ دائیں طرف ایک رنگین بار ظاہر ہوتا ہے۔ اس قدم کو کتنا عرصہ لگا؟. بس اسپین بار. بار جتنا لمبا ہوگا، اس قدم میں اتنا ہی وقت لگے گا۔

قطار یا اس کے بار پر کلک کرنے سے دائیں طرف ایک تفصیلات کا پینل کھل جاتا ہے۔ میٹا ڈیٹا کی دو قسمیں ظاہر ہوتی ہیں:

• span کی خصوصیت: کیا ہوا؟ یہ قدم.
  مثال: HTTP طریقہ (POST, GET) اسٹیٹس کوڈ (200) یا ڈیٹا بیس مرحلہ سے SQL متن۔ آپ کی ٹریکنگ میں آپ دیکھ سکتے ہیں۔ asgi.event.type: http.request FastAPI وصولی کے مرحلے میں۔

• وسائل کی خصوصیات: کہاں رفتار تیز تھی۔
  ہاں: service.name: ledger-service, k8s.cluster.name: clearledger, deployment.environment: production.

فوری ذہنی ماڈل: اسکوپ انتساب = قدم نے کیا کیا۔ ریسورس پراپرٹی = سروس جس نے اسے بنایا۔

لاگ کرنے کے لیے لنک ٹریس: ایک قدم کا انتخاب آپ کو لاگ ٹیب میں بیک وقت اس پوڈ کے لیے مماثل لوکی لاگ لائن پر لے جائے گا۔

اس ٹریکنگ تفصیلات کا اسکرین شاٹ دیکھیں: اسٹیج 7.5 پورٹ فولیو ثبوت۔

ٹریس کیو ایل متبادل

اگر آپ ٹیکسٹ بکس کو ترجیح دیتے ہیں۔ ٹریس کیو ایل ٹیب دبائیں اور درج ذیل کو پیسٹ کریں:

{ resource.service.name = "ledger-service" }

اگر میز خالی ہے۔

اگر TraceQL کہتا ہے۔ 0 series returned: استعمال کریں۔ تلاش کریں اس کے بجائے، ٹیب پر کلک کریں یا TraceQL سوال کو اوپر سے TraceQL ٹیب میں چسپاں کریں۔

اگر تلاش کے ٹیب میں کوئی قطاریں نہیں ہیں: مدت کو اس تک پھیلائیں: آخری 15 منٹ§7.5.6 سے ٹرانزیکشن کرل کو دوبارہ چلائیں، چند سیکنڈ انتظار کریں اور ریفریش کریں۔

اگر گرافانا ٹیمپو سے منسلک نہیں ہوسکتا ہے: ڈیٹا سورس یو آر ایل کو پورٹ کی ضرورت ہے۔ 3200. ڈیٹا سورس کو دوبارہ لگائیں اور گرافانا کو دوبارہ شروع کریں۔

kubectl apply -f stages/stage-7.5-opentelemetry/infra/otel/grafana-datasource-tempo.yaml
kubectl rollout restart deployment/kube-prometheus-stack-grafana -n monitoring

اگر آپ کو کلکٹر لاگ میں ٹریکنگ ڈیٹا نظر نہیں آتا ہے: §7.5.5 کے ذریعے کام کریں۔ عام طور پر یہ OTEL ماحولیاتی متغیر یا نیٹ ورک پالیسی بلاکنگ پورٹ 4317 ہے۔

7.5.7b: ٹریکنگ کے وقت کو سمجھنا

میں نے §7.5.6 میں ایک curl کمانڈ چلائی۔ گرافانا آپ کو وہ تمام جگہیں دکھاتا ہے جہاں ایک درخواست کی گئی ہے۔

اس کے بارے میں سوچیں جیسے کسی پیکیج کو ٹریک کرنا۔

1. آپ منتقل POST /transactions کو لیجر سروس

2. لیجر سروس پوچھا تصدیق کی خدمت: "کیا یہ صارف لاگ ان ہے؟"

3. لیجر سروس قطار ڈیٹا بیس

4. ریڈیس یہ صرف اس صورت میں چلے گا جب رقم ہے: بڑا (10,000 یا اس سے زیادہ)

ہر ایک قطار ہے جو ٹیمپو تفصیلات کی اسکرین پر ظاہر ہوتی ہے۔ آپ چار الگ الگ درخواستوں کو نہیں دیکھ رہے ہیں۔ کہ ایک متعدد اسٹاپس کی درخواست کریں۔

میں لیجر-سروس اور auth-service دونوں کو کیوں دیکھتا ہوں؟

اس کی وجہ یہ ہے کہ لیجر کو لین دین کو ذخیرہ کرنے سے پہلے تصدیق کو کال کرنا پڑتا تھا۔ گرافانا ان اسٹاپوں کو ایک ٹرپ میں گروپ کرتا ہے، تاکہ آپ پورا راستہ دیکھ سکیں، نہ صرف پہلی ہاپ۔

میرے ڈیمو میں کوئی ریڈیس قطاریں کیوں نہیں ہیں؟

آپ استعمال کرتے ہیں "amount": 5000. ایپ صرف Redis کے ساتھ بات چیت کرے گی اگر رقم 10,000 سے زیادہ یا اس کے برابر ہو۔ لہذا، آپ درست ہیں کہ آپ کو لیجر + توثیق + ڈیٹا بیس نظر آئے گا لیکن ریڈیس نہیں۔

Redis دیکھنا چاہتے ہیں؟ استعمال کرتے ہوئے §7.5.6 کو دوبارہ چلائیں: "amount": 15000 Tempo کو دوبارہ تلاش کرنے کی کوشش کریں۔

اختیاری: کوڈ سے لنک

کھلا app/ledger-service/main.pyتلاش کریں create_transactionاوپر سے نیچے تک پڑھیں۔ ٹیمپو لائنیں ترتیب سے اپنے افعال کی پیروی کرتی ہیں۔ آپ صارفین کی تصدیق بھی کر سکتے ہیں، انہیں ڈیٹا بیس میں محفوظ کر سکتے ہیں، اور Redis کو مطلع کر سکتے ہیں۔

اختیاری: ایک ہی درخواست، تین ٹولز

جب میں curl چلاتا ہوں:

• رفتار (یہ مرحلہ): خدمات انجام دی گئی ہیں اور ہر سروس پر خرچ کیا گیا وقت

• پتھریلی (مرحلہ 7): ایپ لاگ فائل میں کیا لکھتی ہے۔

• پرومیتھیس (مرحلہ 7): اس وقت کتنی درخواستیں کی گئیں۔

ایک ہی لمحے، تین مختلف صورتیں۔ آپ نے پہلے ہی اسٹیج 7 میں لوکی اور پرومیتھیس کا استعمال کیا ہے۔

7.5.8: تصدیق

make check-75

متوقع پیداوار:

▶ Stage 7.5 — OpenTelemetry (Distributed Tracing)
  ✓ OTel Collector is running (1 replica(s))
  ✓ Grafana Tempo datasource ConfigMap exists
  ✓ Tempo is running
  ✓ auth-service has OTEL_EXPORTER_OTLP_ENDPOINT set

اگر آپ اس کے بجائے ایک انتباہ دیکھتے ہیں:

⚠ OTel env vars not found on auth-service, redeploy with updated manifests

check-75 تلاش کریں OTEL_EXPORTER_OTLP_ENDPOINT تعیناتی مینی فیسٹ میں۔ یہاں تک کہ اگر ٹریکنگ کام کر رہی ہے، پچھلا مرحلہ 5 مینی فیسٹ اس کی فہرست نہیں دے سکتا ہے۔ Python ایپس بنیادی طور پر ہیں۔ http://otel-collector.monitoring.svc.cluster.local:4317 اگر env var غائب ہے۔

ایک بار جب آپ کلکٹر لاگ میں رینج اور ٹیمپو میں ٹریس دیکھ لیں تو آپ آگے بڑھ سکتے ہیں۔ وارننگ کو صاف کرنے کے لیے، صرف ایپ کی تعیناتی کا اطلاق کریں (پورے کسٹمائز ٹری کو نہیں: Kyverno redis/postgres پیچ کو روک سکتا ہے)۔

kubectl apply -f infra/manifests/auth-service/deployment.yaml
kubectl apply -f infra/manifests/ledger-service/deployment.yaml
kubectl rollout restart deployment/auth-service deployment/ledger-service -n clearledger
make check-75

VM اسٹوریج ~ بعد make check-75. ذیل میں مرحلہ 7.5 کے آخر میں بلاک دیکھیں۔

میں نے کیا سیکھا۔

مرحلہ 7 نے میٹرکس (یہ کتنا مصروف ہے؟) اور لاگز (کیا پرنٹ کیا گیا تھا؟) فراہم کیا گیا۔ مرحلہ 7.5 ٹریسنگ کا اضافہ کرتا ہے (ایک سست درخواست کے لیے کن اقدامات میں وقت لگا؟)

لیب میں آپ نے اسے ایک کے طور پر ثابت کیا۔ POST /transactions curl پیداوار میں، خیال ایک ہی ہے. ایک صارف آپ کے API تک پہنچتا ہے، درخواست متعدد خدمات سے گزرتی ہے، اور آپ کو ایک جگہ پر پورا راستہ دیکھنے کی ضرورت ہوتی ہے۔

اگر کوئی آپ سے انٹرویو میں پوچھے:

نشانات کیوں ہیں؟ میٹرکس سے پتہ چلتا ہے کہ p99 میں تاخیر دوگنی ہو گئی ہے۔ نوشتہ جات ایک پوڈ کے لیے غلطیاں دکھا سکتے ہیں۔ نشانات مجھے بتاتے ہیں۔ کوئی بھی ڈاؤن اسٹریم کالز سلسلہ پر کوئی اندازہ نہیں، کوئی تاخیر، توثیق، ڈیٹا بیس، کیشز یا تھرڈ پارٹی APIs۔

آپ نے اسے کیسے نافذ کیا؟ ہم نے سروس کو انسٹرومنٹ کرنے، کلیکٹر کو ٹیلی میٹری بھیجنے اور گرافانا ٹیمپو میں نشانات ذخیرہ کرنے کے لیے OpenTelemetry کا استعمال کیا۔ ایپ بیک اینڈ سے براہ راست کنکشن کے بجائے کلکٹر کے ساتھ بات چیت کرتی ہے، لہذا آپ بعد میں اپنی تمام سروسز کو دوبارہ تعینات کیے بغیر اسٹوریج کو تبدیل کر سکتے ہیں۔

اگر کوئی واقعہ پیش آئے تو آپ کیا کریں گے؟ ایک سست یا ناکام ٹریس آئی ڈی تلاش کریں (لاگز، میٹرکس، یا الرٹس سے)، اسے ٹیمپو میں کھولیں، سروس کے لحاظ سے کال چین سروسز کو دریافت کریں، دیکھیں کہ وقت کہاں جمع ہے، اور پھر اسی ٹائم اسٹیمپ پر اس سروس کے لاگ پر جائیں۔ یہ 5 پوڈز میں لاگز کو ٹریک کرنے اور اس امید سے کہ وہ قطار میں لگنے سے تیز تر ہے۔

مختصر ورژن یہ ہے کہ آپ اسے اونچی آواز میں کہہ سکتے ہیں۔

"ہم تین چیزوں کو ایک ساتھ استعمال کرتے ہیں: رفتار اور غلطیوں کے لیے پرومیٹیس، لاگ کی تفصیلات کے لیے لوکی، اور مائیکرو سروسز میں درخواست کے درجے کی ڈیبگنگ کے لیے ٹیمپو۔ جب لیٹنسی میں اضافہ ہوتا ہے، تو ہم سست ہاپس کی شناخت کے لیے ایک ٹریس کے ساتھ شروع کرتے ہیں، چاہے وہ ڈیٹا بیس ہو یا ڈاؤن اسٹریم API، اور ان سروسز کے لیے لاگز اور میٹرکس کے ساتھ ان کو دوبارہ جوڑتے ہیں۔"

make check-75 && make snapshot STAGE=75 && make snapshots. چیک کریں clearledger.stage75. دیکھیں کہ اپنی ترقی کو کیسے بچایا جائے۔

مرحلہ 8 - AWS مائیگریشن

یہاں کا مقصد ایک ہی ClearLedger ایپ کو AWS پر لیپ ٹاپ VM کے بجائے چلانا ہے۔

ہم آپ کی درخواست کو دوبارہ نہیں بھریں گے۔ مراحل 0-7 میں، ہم نے GitOps، Kyverno، راز اور مشاہدے کے ساتھ Kubernetes پر مبنی کنٹینرز بنائے۔ مرحلہ 8 میں، پھانسی کی جگہ بدل جاتی ہے۔ یہ وہی امیجز، وہی ArgoCD ورک فلو، اور وہی سیکیورٹی پالیسیاں برقرار رکھتا ہے۔ صرف کلاؤڈ سروسز جو تبدیل ہوتی ہیں وہ تبدیل ہوں گی (MicroK8s → EKS، Vault → Secrets Manager، وغیرہ)۔

• ہوم لیب: مائیکرو کے 8، پوڈز میں پوسٹگریس، دیو والٹ، ڈوکر ہب، clearledger.local

• AWS: EKS, RDS, Secrets Manager, ECR, ALB میزبان کے نام

کیا میں مرحلہ 8 کے لیے تیار ہوں؟

• ہوم لیب کو مرحلہ 7 تک مکمل کریں (مرحلہ 7.5 اختیاری ہے)

• ایک چیک-7 پاس بنائیں (یا چیک-75 اگر آپ نے ٹریکنگ کی ہے)۔

• بلنگ اطلاعات کے ساتھ AWS اکاؤنٹ فعال ہے۔ make aws-up قابل بل وسائل پیدا کرتا ہے۔

• میک اپ کیا کرتا ہے اس کا اندازہ حاصل کرنے کے لیے §8.2 کو سکیم کریں (چاہے آپ فوری راستہ اختیار کریں)۔

کب مکمل کرنا ہے۔ آپ AWS ALB، ArgoCD مطابقت پذیری سے اپنی ایپ سے جڑ سکتے ہیں اور چلا سکتے ہیں: make aws-down مکمل ہونے کے بعد، چارجز رک جائیں گے۔

کیا make aws-up آپ کو دیتا ہے

یہ ہے ڈیمو اسٹیک: پیداوارشکللیکن پیداوار نہیں۔تیار. صرف HTTP ہے (کوئی TLS سرٹیفکیٹ نہیں)۔

مرحلہ 7 مشاہدہ خود بخود انسٹال ہوجاتا ہے۔ CI اب بھی Gitleaks، Semgrep، Checkov، Trivy، اور Cosign چلاتا ہے۔

حقیقی پیداوار میں، HTTPS شامل کریں (دیکھیں: ingress-aws-https.example.yaml)، پروموشن سے پہلے کی تیاری، اور الرٹ روٹنگ۔ اگرچہ یہ دستاویزی ہے، اس کا اطلاق اسپن اپ اسکرپٹس پر نہیں ہوتا ہے۔

GitOps کے قوانین: بوٹسٹریپنگ کے بعد ایسا نہ کریں۔ kubectl apply ایپ کو خود تقسیم کریں۔ ArgoCD کلسٹر کا مالک ہے (مرحلہ 2)۔ اپنی ظاہری تبدیلیوں کو Git میں دبائیں اور ArgoCD کو سنک کریں۔

AWS راز

ہوم لیب میں، والٹ نے پوڈ کو خفیہ فائلیں لکھیں۔ AWS کا ایک راز ہے۔ AWS سیکرٹ مینیجر (ٹیرافارم کے ذریعہ تخلیق کیا گیا)۔ آپ کی ایپ کو اب بھی درج ذیل ماحولیاتی متغیرات کی ضرورت ہے: DATABASE_URL.

ESO (اس لیب کے لیے ڈیفالٹ): سادہ ذہنی ماڈل

1. Terraform اصل راز کو AWS Secrets Manager میں محفوظ کرتا ہے، جیسے clearledger/auth-service)

2. ایکسٹرنل سیکرٹس آپریٹر (ESO) AWS رازوں کی نگرانی کرتا ہے۔

3. ESO اسے کلسٹر کے اندر ایک باقاعدہ Kubernetes راز میں کاپی کرتا ہے، جیسے auth-service-secret)

4. تقسیم کی تفصیلات درج ذیل ہیں: DATABASE_URL اسٹیج 0 کی طرح ہے، لیکن اقدار متعلقہ کبرنیٹس سیکریٹ سے کھینچی گئی ہیں، لیکن گٹ میں YAML فائل کی بجائے AWS سے۔

گٹ میں کبھی بھی اپنا پاس ورڈ درج نہ کریں۔ ESO سیکرٹس مینیجر کے ساتھ کبرنیٹس سیکرٹس کو ہم آہنگ رکھتا ہے۔

CSI (اختیاری، §8.5 مشق): ایک ہی AWS خفیہ لیکن مختلف ترسیل: بطور نصب فائل کو /mnt/secrets/* ماحولیاتی متغیرات کے بجائے۔ یہ گھر کی لیب میں والٹ کے کام کرنے کے طریقے سے قریب تر ہے۔

IRSA: ESO کو اپنے کلسٹر میں AWS رسائی کیز کو ذخیرہ کیے بغیر سیکرٹس مینیجر کو پڑھنے کی اجازت کیسے دی جائے۔ AWS اس کے بجائے Kubernetes سروس اکاؤنٹ پر بھروسہ کرتا ہے۔

IRSA AWS کو آپ کے Kubernetes ServiceAccount پر بھروسہ کرنے کی اجازت دیتا ہے۔ AWS_ACCESS_KEY_ID گٹ یا کلسٹر میں۔

مزید تفصیلات یہاں: stages/stage-8-aws-migration/docs/secrets-patterns.md.

8.1: مرحلہ 8 سے گزرنے کے دو طریقے

تیز راستہ (~45-60 منٹ): ترمیم کریں terraform/secrets.tf (تبدیلی CHANGE_ME_BEFORE_APPLY)، پھر:

make aws-up    # runs stages/stage-8-aws-migration/scripts/aws-spinup.sh
make aws-down  # destroys billable resources when you are done

اگر آپ بعد میں §8.2 پڑھتے ہیں تو آپ دیکھیں گے کہ کیا کیا گیا تھا۔

دستی راستہ (§8.3): Terraform، ECR Push، ArgoCD، Kyverno، اور ESO چلائیں اور براہ راست تعینات کریں۔ سیکھنے، انٹرویو لینے، یا ناکام اسپن اپس کو ڈیبگ کرتے وقت اس کا استعمال کریں۔

اگر آپ نے ابھی اسے چلایا ہے، تو §8.2 - §8.5 کو نہ چھوڑیں۔ make aws-up. بصورت دیگر آپ کو معلوم نہیں ہوگا کہ Terraform، ESO یا ArgoCD ہر ایک نے کیا کیا۔

§8: CI روٹنگ اور CLEARLEDGER_CI_TARGET اور سیٹ CLEARLEDGER_CI_TARGET=aws یہ ٹیرافارم کے کامیاب ہونے کے بعد ہی کیا جا سکتا ہے، اس وقت نہیں جب یہ ابھی تک 1-7 مراحل میں ہے۔

8.2: کیا؟ make aws-up پھانسی

اسپن اپ اسکرپٹ ترتیب میں 15 مراحل پر عمل کرتا ہے۔

ترتیبات (1~6): اپنے ٹولز اور AWS لاگ ان کو چیک کریں۔ terraform apply (VPC, EKS, RDS, ECR, Secrets Manager, GuardDuty, CloudTrail, IAM)، حفاظتی خدمات کی تصدیق کریں، تصاویر بنائیں اور ECR پر پش کریں، پیچ manifests/kustomization.yaml رجسٹری اور گٹ SHA کا استعمال کرتے ہوئے ترتیب kubectl EX کے لیے۔

پلیٹ فارم (7-12): ArgoCD انسٹال کریں۔ Kyverno + کلسٹر پالیسی، Falco، ایکسٹرنل سیکرٹ آپریٹر + IRSA سروس اکاؤنٹ، CSI سیکرٹ ڈرائیور اور 7 لیول آبزرویبلٹی اسٹیک۔

تقسیم (13–15): ArgoCD ایپ clearledger-aws ہم وقت سازی stages/stage-8-aws-migration/manifests/ALB میزبان نام کا انتظار کرتا ہے، پھر یو آر ایل پرنٹ کرتا ہے اور نوٹیفکیشن پھاڑ دیتا ہے۔

اسکرپٹ مکمل ہونے کے بعد پرنٹ کیا جاتا ہے۔ http:/// اپنے براؤزر میں (ClearLedger لاگ ان UI) یا §8.3 کی پیروی کریں۔ آپ Argo CD اور Grafana پورٹ فارورڈنگ کے لیے اندراجات کب کھولیں گے؟

مقامی ایپ کی تعیناتی راز کے لیے ESO کا استعمال کرتی ہے۔ CSI بھی انسٹال ہے لہذا آپ بغیر کسی اضافی سیٹ اپ کے §8.5 میں فائلوں کو ماؤنٹ کرنے کی کوشش کر سکتے ہیں۔

ٹیرافارم لے آؤٹ: نہیں terraform.tf فائل کہ terraform {} بلاکس (ورژن، فراہم کنندہ، اختیاری S3 پسدید) سب سے اوپر ہیں۔ main.tf. وسائل کو موضوع کے لحاظ سے تقسیم کیا گیا ہے۔ vpc.tf, eks.tf, rds.tf, ecr.tf, alb.tf, iam.tf, secrets.tf, security.tf.

سے تمام کمانڈز چلائیں: stages/stage-8-aws-migration/terraform/.

8.3: دستی واک تھرو

تحریک اس سے پہلے کہ آپ شروع کریں۔ اس سیکشن میں دستی اقدامات چلائیں۔ اسٹیج اے اس کے بجائے، کم از کم ایک بار خود make aws-up. راستہ ریپو روٹ سے لیا گیا ہے۔

کمانڈ چیز کو انسٹال کرتی ہے اور UI ثابت کرتا ہے کہ یہ کام کرتا ہے۔ ہوم لیب کے مراحل 2 اور 7 نے پہلے ہی آپ کو اپنے براؤزر میں Argo CD اور Grafana کو کھولنے کا طریقہ سکھایا ہے۔ مرحلہ 8 ایک ہی خیال ہے.

لیکن AWS میں نہیں۔ clearledger.local یا grafana.local کو /etc/hosts. اپنی ایپ کے لیے کنٹرول پلین UI اور عوامی ALB میزبان نام کے لیے پورٹ فارورڈنگ کا استعمال کریں۔

جب کیا کھولنا ہے (چیک پوائنٹ کا نقشہ)

make aws-up 15 قدم چلائیں۔ آپ کو ایک ساتھ تمام UI کھولنے کی ضرورت نہیں ہے۔ آپ کو صرف یہ جاننے کی ضرورت ہے کہ اسکرپٹ کی ترقی کے ساتھ کب چیک کرنا ہے اور آیا یہ کامیاب ہے یا نہیں۔

سب سے پہلے، Terraform AWS پر بناتا ہے۔ مرحلہ 2 مکمل ہونے کے بعد، کھولیں: AWS کنسول پوڈ کے چلنے سے پہلے، یہ تصدیق کرتا ہے کہ کلسٹر، رجسٹری، اور ڈیٹا بیس موجود ہے۔ E.K.S clearledger ہے فعالای سی آر کے چار ذخیرے ہیں جن میں شامل ہیں: frontend (اسے ابھی کے لیے خالی چھوڑ دینا ٹھیک ہے) اور RDS clearledger-postgres ہے دستیاب.

واک تھرو کے لیے، AWS کنسول دیکھیں (مرحلہ 2 کے بعد سے)۔

کنٹینر کی تصویر یہ ہے: ECR کو مرحلہ 4 کے بعد یا CI — AWS (ECR + OIDC) GitHub ایکشنز میں سبز ہونے کے بعد چیک کریں۔ ہر ذخیرہ میں ایک git SHA ٹیگ درج ہونا ضروری ہے۔ جب آپ کی ایپ کو تعینات کیا جاتا ہے تو ArgoCD کو یہی ملتا ہے۔

مرحلہ 7 کے آس پاس، اسکرپٹ آرگو سی ڈی کو انسٹال کرتا ہے۔ UI کی طرف پورٹ کریں اور دیکھیں کہ آیا لاگ ان صفحہ لوڈ ہوتا ہے۔ مجھے ابھی تک ایپ نظر نہیں آ رہی ہے۔ چیک کیا جا رہا ہے کہ آیا آپ GitOps سے منسلک ہو سکتے ہیں۔ تفصیلات: Argo CD UI۔

مرحلہ 12 مشاہدے کا اضافہ کرتا ہے۔ پورٹ فارورڈنگ اور گرافانا میں لاگ ان کرنے کے بعد، یقینی بنائیں کہ آپ کے پاس چھ ClearLedger ڈیش بورڈز درج ہیں۔ پینل اس وقت تک خالی ہو سکتا ہے جب تک کہ آپ ایونٹ نہیں بناتے۔ یہ ہوم لیب کا مرحلہ 7 جیسا ہی ہے۔

مرحلہ 13 مندرجہ ذیل پر لاگو ہوتا ہے: clearledger-aws ایپ Argo CD → پر واپس جائیں۔ درخواست → clearledger-aws. آپ کو تصدیق، لیجر، اور اطلاعات کے لیے مطابقت پذیر، صحت مند، اور چلنے والے پوڈز کی ضرورت ہے۔

مرحلہ 14 آپ کی ایپ کو عوامی یو آر ایل پر ظاہر کرتا ہے۔ کھلا http:/// آپ کے براؤزر میں: آپ کو وہی ClearLedger لاگ ان UI دیکھنا چاہیے جیسا کہ ہوم لیب۔ clearledger.localALB میں دستیاب نہیں ہے۔ /etc/hosts اندراج
استعمال کریں /auth/health جب آپ اپنے ٹرمینل میں فوری API چیک کرنا چاہتے ہیں تو اس کے لیے ایک اور اسٹیٹس URL۔

ALB دیکھیں۔ ایسا تب ہوتا ہے جب پہلی بار ایپ کو عوام کے لیے جاری کیا جاتا ہے۔

اگر آپ مزید تصدیق چاہتے ہیں، تو یہاں کچھ اختیاری تصدیقات ہیں: EC2 → لوڈ بیلنسر → clearledger: صورتحال فعالہمارے فرنٹ اینڈ اور API سروسز کے لیے صحت مند اہداف ہیں۔

AWS میں، ایک ایپ کے پاس ایک ALB کے پیچھے چار خدمات ہیں۔ / (لاگ ان، ڈیش بورڈ، ٹرانزیکشن) اور تین APIs /auth, /ledgerاور /notifications.

مرحلہ 8 میں پورٹ فولیو اسکرین شاٹ ALB URL ہے جو UI کو مندرجہ ذیل دکھا رہا ہے: http://clearledger-xxxxxxxxxx.eu-west-1.elb.amazonaws.com ClearLedger لاگ ان یا ڈیش بورڈ دکھایا جائے گا۔

Argo CD اور Grafana کے لیے، وقف شدہ ٹرمینلز چلانا جاری رکھیں۔ kubectl port-forward جبکہ براؤزر کا ٹیب کھلا ہے۔ Ctrl+C سرنگ بند کرو۔

اس سے پہلے کہ آپ شروع کریں۔

مرحلہ A: ایک حقیقی پاس ورڈ سیٹ کریں۔ secrets.tf

کھلا stages/stage-8-aws-migration/terraform/secrets.tf لفظی متن تلاش کریں۔ CHANGE_ME_BEFORE_APPLY. یہ فائل میں چار بار ظاہر ہوتا ہے (پوسٹگریس پاس ورڈ، جے ڈبلیو ٹی سیکریٹ، اور دو ڈیٹا بیس یو آر ایل)۔ تمام اشیاء کو تبدیل کریں۔

make aws-up کرے گا چلانے سے انکار اگر موجود ہے۔ CHANGE_ME_BEFORE_APPLY متن ابھی تک اس فائل میں ہے۔

مرحلہ B: ٹرمینل چیک کریں۔

aws sts get-caller-identity
terraform --version

# REQUIRED before first terraform apply; GitHub Actions OIDC (ci-aws.yaml) reads this at apply time:
cp stages/stage-8-aws-migration/terraform/terraform.tfvars.example 
   stages/stage-8-aws-migration/terraform/terraform.tfvars
# Edit terraform.tfvars: github_owner = "YOUR_GITHUB_USERNAME"   # your GitHub user or org, not a placeholder

terraform -chdir=stages/stage-8-aws-migration/terraform validate
# Fails with "Set github_owner in terraform.tfvars" until you replace YOUR_GITHUB_USERNAME

مت بھاگو terraform apply کو github_owner یہ مقرر ہے. جب آپ پلیس ہولڈر کا استعمال کرتے ہوئے درخواست دیتے ہیں، تو AWS آپ کے لیے ایک IAM رول تخلیق کرتا ہے۔ clearledger-github-actions-ecr اعتماد کے ساتھ repo:YOUR_GITHUB_USERNAME/.... CI اس میں ناکام: تصویر پوسٹ کریں → ECR کے ساتھ Not authorized to perform sts:AssumeRoleWithWebIdentity.

ترمیم کریں: ترمیم کریں۔ terraform.tfvars → terraform apply دوبارہ → چیک کریں۔ aws iam get-role پھر نیچے ہے۔ ناکام کاموں کو دوبارہ چلائیں۔ ناکام کام چلاتے وقت (پوری پائپ لائن نہیں)

مرحلہ 1 اور 2: ٹیرافارم

cd stages/stage-8-aws-migration/terraform
terraform init -upgrade
terraform apply

# Save outputs:
terraform output -raw ecr_registry_url
terraform output -raw github_actions_ecr_role_arn
terraform output -raw eso_role_arn
terraform output -raw auth_service_irsa_role_arn
terraform output -raw kubeconfig_command
cd ../../..

مرحلہ 2 کے بعد AWS کنسول۔

اپنے کلسٹر کو چھونے سے پہلے Terraform کے تخلیق کردہ وسائل کو چیک کریں۔

1. جیون → کلسٹر → clearledger → حیثیت: فعال, 3 نوڈس

2. ای سی آر → ذخیرہ → clearledger/auth-service, ledger-service, notification-service, frontend (0 تصاویر لیول 4 یا CI تک)

3. آر ڈی ایس → ڈیٹا بیس → clearledger-postgres → دستیاب

تصدیق کریں کہ GitHub ECR پر جا سکتا ہے (صرف اس صورت میں جب آپ مستقبل میں AWS CI استعمال کرنے کا ارادہ رکھتے ہیں)

GitHub ایکشنز کو آپ کے AWS اکاؤنٹ میں تصاویر کو آگے بڑھانے کے لیے اجازت درکار ہوتی ہے۔ Terraform اس کے لیے ایک IAM کردار تخلیق کرتا ہے، لیکن صرف اس صورت میں جب آپ ایک حقیقی GitHub صارف نام ترتیب دیتے ہیں۔ terraform.tfvars پہلے terraform apply.

چیک کریں کہ آیا اس نے کام کیا۔

aws iam get-role --role-name clearledger-github-actions-ecr 
  --query 'Role.AssumeRolePolicyDocument.Statement[0].Condition.StringEquals."token.actions.githubusercontent.com:sub"' 
  --output text

اچھا: repo:your-real-username/clearledger:environment:production

برا: repo:YOUR_GITHUB_USERNAME/clearledger:... میں اس میں ترمیم کرنا بھول گیا۔ terraform.tfvars.

فائل میں ترمیم کریں اور اسے چلائیں۔ terraform apply GitHub میں جابز پر واپس جائیں اور پھر Run Failed CI, AWS (ECR + OIDC) → ناکام جاب کو دوبارہ چلائیں پر کلک کریں۔ صرف پش سٹیپ پر دوبارہ کوشش کریں۔ ہر چیز کو دوبارہ بنانے اور تلاش کرنے کی ضرورت نہیں ہے۔

اس پورے بلاک کو صرف اس صورت میں چھوڑیں جب آپ استعمال کریں: make aws-up اس وقت، میں نے ابھی تک AWS CI کو فعال نہیں کیا ہے۔

ای سی آر کے ذخیرے کب ظاہر ہوں گے؟

دوران terraform apply (مرحلہ 2)جب آپ آس پاس ہوں تو نہیں۔ docker push. ٹیرافارم اسے تیار کرتا ہے۔ مفت تصویری ذخیرہ: clearledger/auth-service, ledger-service, notification-serviceاور frontendلہذا، درخواست کے فوراً بعد 0 تصاویر دیکھنا معمول کی بات ہے۔

تصویر کو بعد میں مرحلہ 4 میں کاپی کیا جائے گا (دستی طور پر docker push) یا اگر GitHub ایکشنز CI کامیاب ہے۔

AWS CLI ریجن کو اس پر سیٹ کریں: eu-west-1

اس لیب میں تمام اشیاء eu-west-1 (آئرلینڈ) میں واقع ہیں۔ جب CLI ڈیفالٹ ہوتا ہے۔ us-east-1کمانڈ سے پتہ چلتا ہے کہ وسائل موجود ہونے کے باوجود غائب ہے۔

aws configure set region eu-west-1
aws configure get region   # expect: eu-west-1

مرحلہ 3-4: سیکیورٹی سروس + ECR امیج

AWS_REGION=eu-west-1   # or rely on aws configure set region above

# Step 3: verify security services (must pass --region eu-west-1)
aws guardduty list-detectors --region "${AWS_REGION}"
# Expect: DetectorIds: [""]  — empty [] means wrong region, not "not created"

aws cloudtrail get-trail-status --name clearledger-trail --region "${AWS_REGION}"
# Expect: IsLogging: true
# Error "Unknown trail ... us-east-1" → you forgot --region eu-west-1

# Step 4: build and push images to the ECR repos Terraform already created
ECR_REGISTRY=$(terraform -chdir=stages/stage-8-aws-migration/terraform output -raw ecr_registry_url)
AUTH_ECR=$(terraform -chdir=stages/stage-8-aws-migration/terraform output -raw auth_service_ecr_url)
LEDGER_ECR=$(terraform -chdir=stages/stage-8-aws-migration/terraform output -raw ledger_service_ecr_url)
NOTIFY_ECR=$(terraform -chdir=stages/stage-8-aws-migration/terraform output -raw notification_service_ecr_url)
TAG=$(git rev-parse --short HEAD)

aws ecr get-login-password --region "${AWS_REGION}" 
  | docker login --username AWS --password-stdin "${ECR_REGISTRY}"

docker build -t "${AUTH_ECR}:${TAG}" app/auth-service && docker push "${AUTH_ECR}:${TAG}"
docker build -t "${LEDGER_ECR}:${TAG}" app/ledger-service && docker push "${LEDGER_ECR}:${TAG}"
docker build -t "${NOTIFY_ECR}:${TAG}" app/notification-service && docker push "${NOTIFY_ECR}:${TAG}"

# Confirm images landed (optional)
aws ecr describe-images --repository-name clearledger/auth-service --region "${AWS_REGION}" 
  --query 'imageDetails[*].imageTags' --output table

ECR کنسول (مرحلہ 4 یا گرین CI کے بعد): کھولیں اور ہر ایک ذخیرہ پر تشریف لے جائیں۔ امیجز ٹیب پر جائیں۔ آپ کو گٹ کمٹ SHA سے ​​مماثل ٹیگز دیکھنا چاہئے۔ اگر ذخیرہ خالی ہے تو، ArgoCD دکھایا جائے گا۔ ImagePullBackOff بعد میں

GitHub ایکشنز (اگر دستی دھکا کے بجائے CI استعمال کر رہے ہوں): ذخیرہ → ٹاسکس → ورک فلو CI۔ AWS (ECR + OIDC)۔

اگر سب کچھ سبز ہے تو میں تصویر پوسٹ کروں گا۔ ECR کامیاب ہو گیا۔ یہ پری ڈسٹری بیوشن سپلائی چین کا ثبوت ہے۔

مرحلہ 5: GitOps معلومات کے ذرائع

پیچ پلیس ہولڈر kustomization.yaml (ایک ہی sed پسند aws-spinup.sh مرحلہ 5):

AWS_REGION=eu-west-1
ECR_REGISTRY=$(terraform -chdir=stages/stage-8-aws-migration/terraform output -raw ecr_registry_url)
TAG=$(git rev-parse --short HEAD)
KUST=stages/stage-8-aws-migration/manifests/kustomization.yaml

sed -i.bak 
  -e "s|REPLACE_ECR_REGISTRY|${ECR_REGISTRY}|g" 
  -e "s|REPLACE_IMAGE_TAG|${TAG}|g" 
  "${KUST}"
rm -f "${KUST}.bak"

# Region in ESO + CSI manifests (only if not eu-west-1)
if [[ "${AWS_REGION}" != "eu-west-1" ]]; then
  sed -i.bak "s|region: eu-west-1|region: ${AWS_REGION}|g" 
    stages/stage-8-aws-migration/manifests/external-secrets.yaml 
    stages/stage-8-aws-migration/manifests/csi/auth-service-spc.yaml 
    stages/stage-8-aws-migration/manifests/csi/ledger-service-spc.yaml
  rm -f stages/stage-8-aws-migration/manifests/external-secrets.yaml.bak 
        stages/stage-8-aws-migration/manifests/csi/*.bak 2>/dev/null || true
fi

# Verify before commit
grep -E 'newName:|newTag:' "${KUST}"
# Expect: YOUR_AWS_ACCOUNT.dkr.ecr.eu-west-1.amazonaws.com/clearledger/... and your git SHA

git add stages/stage-8-aws-migration/manifests/kustomization.yaml
git commit -m "stage8: ECR images ${TAG}"
git push

ایک بار ArgoCD ایپلیکیشن ریپوزٹری یو آر ایل میں بھی ترمیم کریں (اپنے GitHub صارف نام سے تبدیل کریں)۔

# Example: YOUR_GITHUB_USERNAME/clearledger — check: git remote get-url origin
sed -i.bak 's|YOUR_GITHUB_USERNAME|YOUR_ACTUAL_GITHUB_USER|g' 
  stages/stage-8-aws-migration/argocd/clearledger-aws-app.yaml
rm -f stages/stage-8-aws-migration/argocd/clearledger-aws-app.yaml.bak

مرحلہ 6: کلسٹر رسائی + ٹیرافارم آؤٹ پٹ

ریپوزٹری روٹ سے چلائیں: پہلے CLI ریجن سیٹ کریں (EKS اور IAM آؤٹ پٹ ریجنز ہیں)، ایک kubeconfig کریں، اور پھر IRSA رول ARN کو ایکسپورٹ کریں۔ اقدامات 9 اور 10 کے لیے درکار ہے۔

aws configure set region eu-west-1

eval "$(terraform -chdir=stages/stage-8-aws-migration/terraform output -raw kubeconfig_command)"
kubectl get nodes

export AWS_REGION=eu-west-1
export ESO_ROLE_ARN=$(terraform -chdir=stages/stage-8-aws-migration/terraform output -raw eso_role_arn)
export FALCO_ROLE_ARN=$(terraform -chdir=stages/stage-8-aws-migration/terraform output -raw falco_role_arn)
export REPLACE_AUTH_IRSA_ROLE_ARN=$(terraform -chdir=stages/stage-8-aws-migration/terraform output -raw auth_service_irsa_role_arn)
export REPLACE_LEDGER_IRSA_ROLE_ARN=$(terraform -chdir=stages/stage-8-aws-migration/terraform output -raw ledger_service_irsa_role_arn)
export REPLACE_NOTIFICATION_IRSA_ROLE_ARN=$(terraform -chdir=stages/stage-8-aws-migration/terraform output -raw notification_service_irsa_role_arn)

# Sanity check (all should print ARNs, not empty)
echo "ESO:      ${ESO_ROLE_ARN}"
echo "Falco:    ${FALCO_ROLE_ARN}"
echo "Auth IRSA: ${REPLACE_AUTH_IRSA_ROLE_ARN}"

مرحلہ 7 سے 12: کلسٹر کا پلیٹ فارم اسٹیک

مکمل شدہ مراحل 1-6 (AWS موجود ہے، تصاویر ECR میں ہیں، kubectl فیکٹری)۔ مرحلہ 7 سے 12 اب پلیٹ فارم اسٹیک کو انسٹال کریں، جو ایک ہی جزو ہے جیسا کہ: aws-spinup.shتاہم، یہ نیچے دیے گئے سیکشن میں کمانڈ چلاتا ہے، نہ کہ اسکرپٹ۔

ہر قدم کے لیے، انسٹالیشن کوڈ بلاک چلائیں، اس کے بعد فوراً نیچے تصدیقی بلاک۔ اگلے مرحلے پر نہ جائیں جب تک کہ آپ Running Pods (یا ClusterPolicy فہرست) نہ دیکھیں۔ "کمانڈ آؤٹ پٹ کے بغیر باہر نکل گئی" کافی نہیں ہے۔

قدم	نام کی جگہ	جو آپ انسٹال کر رہے ہیں۔	پھلیوں کی تخمینی تعداد
7	argocd	GitOps کنٹرولر	~7 پھلیاں
8	kyverno	داخلہ کی پالیسی	~4 پوڈز + کلسٹر پالیسی
9	falco	رن ٹائم کا پتہ لگانا	1 ڈیمون سیٹ پوڈ فی نوڈ (3 اس کلسٹر میں)
10	external-secrets + clearledger	ESO + IRSA سروس اکاؤنٹ	~3 ESO Pods + 3 سروس اکاؤنٹس
11	kube-system + clearledger	CSI ڈرائیور + AWS فراہم کنندہ	3 ڈرائیور + 3 فراہم کنندگان (1 فی نوڈ)
12	monitoring	پرومیتھیس، گرافانا، لوکی	~ 10 یا اس سے زیادہ پھلیاں

مرحلہ 13-15 (ایپ کی تعیناتی، ALB انتظار، UI کی توثیق) نیچے 12 کے بعد انجام دیے گئے ہیں۔

مرحلہ 7: ArgoCD

kubectl create namespace argocd --dry-run=client -o yaml | kubectl apply -f -
kubectl apply -n argocd --server-side --force-conflicts 
  -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
kubectl rollout status deployment/argocd-server -n argocd --timeout=180s

چیک کریں کہ کیا بنایا گیا ہے۔

kubectl get pods -n argocd
kubectl get svc -n argocd
kubectl get deploy -n argocd

متوقع: argocd-server, argocd-repo-server, argocd-application-controllerوغیرہ: سب سے زیادہ فورڈ چل رہا ہے 1/1 یا 2/2. argocd-server سروس پورٹ 443 کو بے نقاب کرتی ہے۔

UI (فی الحال اختیاری، مرحلہ 13 کے بعد درکار ہے): نیا ٹرمینل، چلتے رہیں۔ مفت مقامی بندرگاہ (8081 اگر 8080 استعمال میں):

kubectl port-forward svc/argocd-server -n argocd 8080:443
# Or if 8080 is taken:
# kubectl port-forward svc/argocd-server -n argocd 8081:443
# https://localhost:8080 (or 8081)  user: admin
kubectl get secret argocd-initial-admin-secret -n argocd -o jsonpath="{.data.password}" | base64 -d; echo

مرحلہ 13 تک، درخواست کی فہرست خالی ہے۔ یہ عام بات ہے۔

مرحلہ 8: Kyverno + پالیسیاں

cosign.pub / infra/cosign.pub اسے نظر انداز کیا جاتا ہے (نجی کلید کا ارتکاب نہیں کیا جانا چاہئے؛ عوامی کلید ہر سیکھنے والے کے لئے مخصوص ہے)۔
ریپوزٹری مثال کے طور پر کلیدیں فراہم کرتی ہے: require-signed-images.yaml / require-signed-images-ecr.yaml.
اگر آپ نے مرحلہ 3 میں کلید کو دوبارہ تخلیق کیا ہے، تو اسے لاگو کرنے سے پہلے اپنی مقامی عوامی کلید کو پالیسی سے ہم آہنگ کریں۔

# infra/cosign.pub exists locally but is gitignored — safe to copy into committed policy YAMLs
bash scripts/embed-cosign-pub-in-policies.sh
diff infra/cosign.pub <(grep -A3 'BEGIN PUBLIC KEY' infra/policies/require-signed-images-ecr.yaml | grep -v publicKeys)

helm repo add kyverno https://kyverno.github.io/kyverno/ --force-update
helm upgrade --install kyverno kyverno/kyverno 
  --namespace kyverno --create-namespace 
  -f stages/stage-4-admission-control/infra/kyverno/values.yaml 
  --set admissionController.replicas=1 
  --wait --timeout=180s
kubectl apply -f infra/policies/

چیک کریں:

kubectl get pods -n kyverno
kubectl get clusterpolicy
kubectl get clusterpolicy require-signed-images-ecr -o jsonpath="{.spec.rules[0].verifyImages[0].attestors[0].entries[0].keys.publicKeys}" | head -3

متوقع: داخلہ کنٹرولر، بیک گراؤنڈ کنٹرولر، کلینز کنٹرولر، اور رپورٹ کنٹرولر پوڈز چل رہے ہیں۔

kubectl get clusterpolicy 6 سے زیادہ پالیسیاں درج ہیں، بشمول: require-signed-images-ecr, disallow-root-containersوغیرہ وہ publicKeys آپ کو آؤٹ پٹ دیکھنا چاہئے۔ -----BEGIN PUBLIC KEY-----نہیں PASTE_YOUR_COSIGN_PUBLIC_KEY_HERE (Kyverno پلیس ہولڈر کو فائل پاتھ سمجھے گا اور کسی بھی تعیناتی کو روک دے گا)۔

require-signed-images-ecr ڈیفالٹ آڈٹ ہے جب تک کہ CI Cosign ECR امیج پر دستخط نہیں کرتا (COSIGN_PRIVATE_KEY + COSIGN_PASSWORD GitHub پر)۔ غیر دستخط شدہ تصاویر کی تقسیم جاری رہے گی۔ دستخط شدہ تصویر کو بعد میں لگانا اختیاری ہے۔

اگر verify-slsa-provenance درخواست دینے میں ناکام (شکریہ + mutateDigest)، سیٹ mutateDigest: false اسے اس فائل میں رکھیں یا اسے چھوڑ دیں۔ مرحلہ 8 اختیاری ہے۔

مرحلہ 9: فالکو

helm repo add falcosecurity https://falcosecurity.github.io/charts --force-update
helm upgrade --install falco falcosecurity/falco 
  --namespace falco --create-namespace 
  -f stages/stage-6-runtime-security/infra/falco/helm-values.yaml 
  --set driver.kind=modern_ebpf 
  --set "serviceAccount.annotations.eks.amazonaws.com/role-arn=${FALCO_ROLE_ARN}" 
  --wait --timeout=300s

چیک کریں:

kubectl get pods -n falco -o wide
kubectl get daemonset -n falco
kubectl get sa falco -n falco -o jsonpath="{.metadata.annotations.eks.amazonaws.com/role-arn}"; echo

متوقع: DESIRED = Falco DaemonSet نوڈس کی تعداد کے ساتھ (3)۔ ہر پھلی چل رہا ہے. سروس اکاؤنٹ کی تشریح یہ ہے۔ FALCO_ROLE_ARN.

مرحلہ 10: ایکسٹرنل سیکرٹ آپریٹر + IRSA سروس اکاؤنٹس

helm repo add external-secrets https://charts.external-secrets.io --force-update
helm upgrade --install external-secrets external-secrets/external-secrets 
  --namespace external-secrets --create-namespace 
  --set "serviceAccount.annotations.eks.amazonaws.com/role-arn=${ESO_ROLE_ARN}" 
  --wait --timeout=180s
kubectl apply -f stages/stage-8-aws-migration/manifests/resources/namespace.yaml
envsubst < stages/stage-8-aws-migration/manifests/clearledger-serviceaccounts.yaml | kubectl apply -f -

چیک کریں:

kubectl get pods -n external-secrets
kubectl get sa -n external-secrets external-secrets -o jsonpath="{.metadata.annotations.eks.amazonaws.com/role-arn}"; echo
kubectl get sa -n clearledger

متوقع: external-secrets تعیناتی چل رہا ہے (اکثر 3 کنٹینرز/1 پوڈ) 3 سروس اکاؤنٹس clearledger: auth-service, ledger-service, notification-service: ہر ایک eks.amazonaws.com/role-arn تشریح ابھی تک کوئی ایپ پوڈ نہیں ہے (ArgoCD انہیں مرحلہ 13 میں تعینات کرتا ہے)۔

مرحلہ 11: CSI ڈرائیور + SecretProviderClasses

bash stages/stage-8-aws-migration/scripts/install-csi-secrets.sh

چیک کریں:

kubectl get pods -n kube-system | grep -E 'secrets-store|provider-aws'
kubectl get secretproviderclass -n clearledger
helm list -n kube-system | grep -E 'csi-secrets|secrets-provider'

متوقع: CSI ڈرائیور پوڈ 3/3 رن (ایک فی نوڈ) AWS فراہم کنندہ پوڈ 1/1 رن فی نوڈ دو SecretProviderClass کا اعتراض clearledger. پچنگ شو csi-secrets-store اور/یا secrets-provider-aws رکھا.

جب ہیلم رپورٹ کرتا ہے۔ meta.helm.sh/release-name اگر کوئی تصادم ہوتا ہے تو اسکرپٹ کو دوبارہ چلائیں۔ ڈرائیور چارٹس کو نقل کیے بغیر AWS فراہم کنندگان کو انسٹال کریں۔

مرحلہ 12: مشاہدہ

bash stages/stage-7-observability/scripts/install-observability.sh

چیک کریں:

kubectl get pods -n monitoring
kubectl get svc -n monitoring | grep -E 'grafana|prometheus|loki'
kubectl get configmap -n monitoring -l grafana_dashboard=1 --no-headers | wc -l

متوقع: گرافانا 3/3 رنپرومیتھیس اور لوکی فورڈ چل رہا ہے. ڈیش بورڈ میں ConfigMaps کی تعداد درج ذیل ہے: 6 (ClearLedger ڈیش بورڈ)۔ پرنٹ سکرپٹ http://grafana.local: EKS اس کے بجائے پورٹ فارورڈنگ کا استعمال کرتا ہے۔

# New terminal — keep running
kubectl port-forward -n monitoring svc/kube-prometheus-stack-grafana 3000:80
# http://localhost:3000  admin / admin123
# http://localhost:3000/dashboards?tag=clearledger

پینل میں دکھایا جا سکتا ہے۔ کوئی ڈیٹا نہیں جب تک آپ کسی ایونٹ کو متحرک نہیں کرتے ہیں (§7.4 مشق بھی اس کلسٹر کے لیے کام کرتی ہے)۔

پلیٹ فارم اسٹیک کا خلاصہ: مرحلہ 13 سے پہلے فوری حیثیت کی جانچ:

for ns in argocd kyverno falco external-secrets monitoring clearledger; do
  echo "=== ${ns} ==="
  kubectl get pods -n "${ns}" --no-headers 2>/dev/null | awk '{print $3}' | sort | uniq -c || echo "(no pods yet)"
done
kubectl get clusterpolicy --no-headers | wc -l | xargs echo "ClusterPolicies:"
kubectl get secretproviderclass -n clearledger --no-headers | wc -l | xargs echo "SecretProviderClasses:"

متوقع: تمام نام کی جگہیں اس طرح ظاہر ہوتی ہیں: Running (یا Completed پیشہ ورانہ استعمال کے لیے)۔ clearledger ArgoCD مطابقت پذیر ہونے تک یہ خالی ہو سکتا ہے۔ کلسٹر پالیسیاں ≥ 6. SecretProviderClasses = 2۔

نام کی جگہ بناتے وقت EKS API ٹائم آؤٹ؟ آپ دیکھ سکتے ہیں Unexpected error when reading response body / context deadline exceeded اور اب بھی حاصل کریں namespace/argocd created. کہ عارضی کلائنٹ ٹائم آؤٹ ناکام تخلیق کے بجائے EKS API (پہلی درخواست، سست نیٹ ورک، یا کنٹرول پلین کیچ اپ) کے ساتھ بات چیت کریں۔ چیک کریں kubectl get namespace argocd اور چلتے رہیں۔ اگر کمانڈ کا وقت ختم ہوتا رہتا ہے تو دوبارہ کوشش کریں یا اسے ایک بار چلائیں۔ kubectl cluster-info اپنا کنکشن چیک کریں۔

مرحلہ 13-14: ArgoCD + ALB حوالہ کے ذریعے تعینات کریں۔

اگلی ایپ YAML stages/stage-8-aws-migration/manifests/ ہاتھ سے نہیں لگایا جاتا۔ مرحلہ 13 آپ کو گٹ کو آرگو سی ڈی سے ہم آہنگ کرنے کی ہدایت کرتا ہے۔ Argo CD پھر تقسیم، خدمات، وصول اور باقی تخلیق کرتا ہے۔

ریپو تک ترجیحی رسائی

اگر آپ کا GitHub ذخیرہ نجی ہے تو Argo CD → ترتیبات → Repository میں PAT شامل کریں۔ اگر آپ ریپوزٹری کو پبلک پر سیٹ کرتے ہیں تو ایپ کو ریفریش کریں اور ComparisonError: authentication required صاف ہونا ضروری ہے۔

اگر مطابقت پذیری اب بھی ناکام ہوجاتی ہے۔عام وجوہات کو چیک کریں:

• external-secrets.io/v1beta1 نہیں ملاآپ کے کلسٹر میں تازہ ترین ESO API ہے۔ دھکا external-secrets.yaml کے ساتھ apiVersion: external-secrets.io/v1.

• Kyverno شکایت کرتا ہے: PASTE_YOUR_COSIGN_PUBLIC_KEY_HERE چلائیں bash scripts/embed-cosign-pub-in-policies.shپھر kubectl apply -f infra/policies/.

• SecretSyncedError تصدیق کے بعد، database_url یا jwt_secret نہیں ملا - AWS راز clearledger/auth-service آپ کو دونوں کلیدوں کو شامل کرنا ہوگا (ٹیرافارم مندرجہ ذیل کلیدوں کو لکھتا ہے): secrets.tf)۔ دوبارہ کریں terraform apply ٹھیک کرنے کے بعد CHANGE_ME_BEFORE_APPLY قیمت چیک کریں یا AWS کنسول میں راز کو چیک کریں۔

• فورڈ رک گیا۔ Pending یا 'بہت زیادہ پھلی' لیب نوڈس چھوٹے ہیں۔ ٹیرافارم میں نوڈ گروپ کو پھیلائیں یا مینی فیسٹ میں نقل کی تعداد کو کم کریں۔

اپنی ایپ کو رجسٹر کریں:

kubectl apply -f stages/stage-8-aws-migration/argocd/clearledger-aws-app.yaml

جب تک آپ آرگو سی ڈی نہیں دیکھتے clearledger-aws ہے مطابقت پذیر اور صحت مند. اس مقام پر، ایپ پوڈ ظاہر ہوگا۔ clearledger.

مرحلہ 13: ArgoCD Sync (UI + CLI) دیکھیں

آرگو سی ڈی براؤزر ٹیب کو کھولیں جو آپ نے کھولا تھا (مرحلہ 7 میں پورٹ فارورڈنگ)۔

https://localhost:8080        ← or 8081 if 8080 was busy

کلک کریں clearledger-aws. انتظار کرو نارمل + مطابقت پذیر (پہلی تعیناتی کے لیے 2-5 منٹ) آپ وہی معلومات اپنے براؤزر کو چھوئے بغیر اپنے ٹرمینل میں دیکھ سکتے ہیں۔

kubectl get application clearledger-aws -n argocd -w
# Ctrl-C when HEALTH STATUS shows Healthy

جب اسے حل کیا جا رہا ہے، واچ پوڈ دوسرے ٹرمینل میں شروع ہو جائے گا۔

kubectl get pods -n clearledger -w
# All pods should reach 1/1 Running within 2 minutes
# Ctrl-C when everything is Running

مرحلہ 14: عوامی ایپ URL (ALB) حاصل کریں

AWS کو ArgoCD کی مطابقت پذیری کے بعد لوڈ بیلنس کی فراہمی میں 2 سے 5 منٹ لگتے ہیں۔
اسے چلائیں اور ADDRESS کالم کے آباد ہونے کا انتظار کریں۔

kubectl get ingress clearledger-ingress -n clearledger -w
# ADDRESS is empty at first, then shows something like:
# clearledger-xxxxxxxxxx.eu-west-1.elb.amazonaws.com
# Ctrl-C once the hostname appears

ذیل کے مراحل کے لیے URL برآمد کریں۔

export ALB_DNS=$(kubectl get ingress clearledger-ingress -n clearledger 
  -o jsonpath="{.status.loadBalancer.ingress[0].hostname}")
echo "Your app is live at: http://${ALB_DNS}"

10 منٹ کے بعد بھی خالی ہے؟ ALB/Receive وصولی کے مراحل کے لیے، Troubleshooting.md دیکھیں۔

مرحلہ 15: اپنے براؤزر میں ایپ کھولیں۔

ALB روٹ URL کو اپنے براؤزر میں چسپاں کریں۔ کوئی DNS اندراجات، پورٹ فارورڈنگ، یا VPN نہیں:

http://clearledger-xxxxxxxxxx.eu-west-1.elb.amazonaws.com/

ClearLedger لاگ ان اسکرین ظاہر ہوتی ہے (وہی SPA ہوم لیب کی طرح)۔ clearledger.local)۔ رجسٹر کریں یا لاگ ان کریں، لین دین جمع کروائیں، اور اپنا ڈیش بورڈ لوڈ دیکھیں۔ یہ آپ کے مرحلہ 8 کے پورٹ فولیو کا اسکرین شاٹ ہے۔

فوری API اسٹیٹس چیک (ٹرمینل یا براؤزر):

curl -fsS "http://${ALB_DNS}/auth/health" && echo
curl -fsS "http://${ALB_DNS}/ledger/health" && echo
curl -fsS "http://${ALB_DNS}/notifications/health" && echo

ہر ایک کو اس طرح JSON واپس کرنا چاہئے: {"status":"ok","service":"auth-service"}.

مرحلہ 16: AWS کنسول میں تصدیق کریں (اختیاری، لیکن تجویز کردہ)

AWS سائیڈ پر تعینات اسٹیک کیسا دکھتا ہے وہ یہ ہے:

کنسول کا مقام	آپ کو کیا تلاش کرنا چاہئے؟
EC2 → لوڈ بیلنسر	نام لوڈ بیلنسر clearledger-… حیثیت کے ساتھ فعال
EC2 → ہدف گروپ	2-3 ٹارگٹ گروپس، تمام اہداف دکھائیں۔ صحت مند
ECR → اسٹوریج	clearledger/auth-service, clearledger/ledger-service, clearledger/notification-service, clearledger/frontend - ہر ایک کے پاس حال ہی میں دھکا دیا گیا امیج ٹیگ ہے۔
EKS → کلسٹر → Clearledger → کام کا بوجھ	پوڈ رننگ کے طور پر ظاہر ہوتا ہے۔ clearledger نام کی جگہ
خفیہ مینیجر	clearledger/auth-service, clearledger/ledger-service, clearledger/postgres - ہر کوئی موجود ہے۔

ALB میں 502/503؟ لوڈ بیلنس ختم ہو گیا ہے، لیکن پوڈز ابھی تک صحت مند نہیں ہیں یا راز ہم آہنگی سے باہر ہیں۔ چیک کریں: kubectl get pods -n clearledger (ہر 1/1 Running؟) اور kubectl get externalsecret -n clearledger (دونوں SecretSynced True؟)۔

پریکٹس چیک پوائنٹ: ایپ عوامی طور پر قابل رسائی ہے۔

# All three must print {"status":"ok",...}
curl -fsS "http://${ALB_DNS}/auth/health"         && echo
curl -fsS "http://${ALB_DNS}/ledger/health"        && echo
curl -fsS "http://${ALB_DNS}/notifications/health" && echo

# All pods Running
kubectl get pods -n clearledger

# Nothing printed here = all pods Running (non-Running pods would show)
kubectl get pods -n clearledger --field-selector=status.phase!=Running

ImagePullBackOff اس کا مطلب ہے کہ پوڈ لسٹ میں ابھی تک کوئی ECR امیجز نہیں ہیں۔ GitHub ایکشنز کو چیک کریں اور ورک فلو کو دوبارہ چلائیں۔ کوئی راستہ نہیں 502 اسٹیٹس یو آر ایل میں موجود معلومات کا مطلب ہے کہ پوڈ ابھی تیار نہیں ہے۔ براہ کرم 30 سیکنڈ انتظار کریں اور دوبارہ کوشش کریں۔

8.4: پہلے سے طے شدہ خفیہ راستے (ESO) کی جانچ کرنا

آرگو سی ڈی کے سنکرونائز ہونے کے بعد، تصدیق کریں کہ بیرونی سیکرٹ آپریٹر نے AWS سیکرٹس مینیجر سے ریگولر Kubernetes سیکرٹس میں اقدار کو کاپی کیا ہے۔

kubectl get externalsecret,secret -n clearledger
kubectl describe externalsecret auth-service-secret -n clearledger | grep -A6 "Conditions:"
kubectl get pods -n clearledger -l app=auth-service
kubectl exec -n clearledger deploy/auth-service -c auth-service -- env | grep DATABASE_URL

کمانڈ 1: بیرونی راز + خفیہ

آپ کو دو بیرونی رازوں سے مماثل دو راز دیکھنا چاہئے (تصدیق میں دو کلیدیں ہیں اور ایک لیجر میں)۔

NAME                                                     STORE                 REFRESH INTERVAL   STATUS         READY
externalsecret.external-secrets.io/auth-service-secret   aws-secrets-manager   1h                 SecretSynced   True
externalsecret.external-secrets.io/ledger-service-secret aws-secrets-manager   1h                 SecretSynced   True

NAME                         TYPE     DATA   AGE
secret/auth-service-secret   Opaque   2      3m
secret/ledger-service-secret Opaque   1      3m

STATUS ہونا ضروری ہے خفیہ مطابقت پذیر اور تیار ہونا ضروری ہے سچائی. اگر آپ دیکھتے ہیں SecretSyncedErrorیہاں رکیں اور §8.5 سے پہلے IRSA کو ٹھیک کریں۔

کمانڈ 2: توثیق بیرونی خفیہ تفصیل

اسے تلاش کریں۔ Reason: SecretSynced اور Status: True:

  Conditions:
    Last Transition Time:   2026-07-10T22:15:00Z
    Message:                Secret was synced
    Reason:                 SecretSynced
    Status:                 True
    Type:                   Ready

کمانڈ 3: توثیق پوڈ چلانا

NAME                            READY   STATUS    RESTARTS   AGE
auth-service-xxxxxxxxxx-xxxxx   1/1     Running   0          2m
auth-service-xxxxxxxxxx-xxxxx   1/1     Running   0          2m

دونوں نقلیں 1/1 رن. اگر آپ کا پوڈ اس طرح ہے: CrashLoopBackOff یا CreateContainerConfigErrorآپ کا K8s پاس ورڈ غائب یا خالی ہو سکتا ہے۔

کمانڈ 4: DATABASE_URL ایک ماحولیاتی متغیر (ESO پاتھ) ہے، فائل پاتھ نہیں۔

DATABASE_URL=postgresql://clearledger:*****@clearledger-postgres.xxxxx.eu-west-1.rds.amazonaws.com:5432/clearledger

اچھا: بی postgresql://... کنکشن سٹرنگ (پاس ورڈ درج ذیل ظاہر ہوتا ہے) ***** یا اصل پاس ورڈ)۔

اس سیکشن میں فٹ نہیں ہے: /mnt/secrets/database_url اس کا مطلب ہے پہلے سے طے شدہ ESO env-var پاتھ کے بجائے CSI فائلوں (§8.5) کو بڑھانا۔

آپ یہ بھی چیک کر سکتے ہیں کہ آیا قیمت پرنٹ کیے بغیر کوئی راز موجود ہے۔

kubectl get secret auth-service-secret -n clearledger -o jsonpath="{.data}" | grep -o 'database_url|jwt_secret'
# Expect: database_url and jwt_secret (two keys)

اگر SecretSynced=FalseESO لاگز اور IRSA چیک کریں۔

kubectl logs -n external-secrets deploy/external-secrets -c external-secrets | tail -30
kubectl get sa auth-service -n clearledger -o yaml | grep role-arn

چیک پوائنٹس کی مشق کریں۔ بیرونی راز دراصل AWS سے مطابقت پذیر ہیں۔

kubectl get externalsecret -n clearledger
kubectl get secret -n clearledger

متوقع: auth-service-secret اور ledger-service-secret ہر شو SecretSynced / تیار True. ایک مماثل Kubernetes راز موجود ہے۔ clearledger. کوئی راستہ نہیں SecretSyncedError اس کا مطلب ہے کہ IRSA/IAM سیکرٹس مینیجر سے رابطہ نہیں کر سکتا۔ §8.5 سے پہلے رول بائنڈنگ میں ترمیم کریں۔

اگر آپ اسے چھوڑ دیتے ہیں تو، §8.5 (CSI ڈرائیور) کام کرنے والی خفیہ رسائی کے اوپر بنایا گیا ہے، جہاں خاموش IAM ناکامیاں دو حصوں کے بعد بظاہر غیر متعلقہ پوڈ کی غلطیوں کے طور پر ظاہر ہوتی ہیں۔

8.5: لیب، CSI ڈرائیور (فائل ماؤنٹ)

ڈیفالٹ پوڈ پہلے سے ہی ESO استعمال کر رہا ہے۔ راز کبرنیٹس سیکریٹ آبجیکٹ میں ماحولیاتی متغیر کے طور پر آتا ہے۔ یہ مشق ایک سوئچ ہے۔ auth-service اس کے بجائے CSI کے راستے پر: راز کو باقاعدہ فائل کے طور پر نصب کیا جاتا ہے۔ /mnt/secrets/ایپ اپنے مواد کو ڈسک سے پڑھتی ہے۔ یہ وہی کوڈ پاتھ ہے جسے ہوم لیب والٹ (DATABASE_URL_FILE / JWT_SECRET_FILE)۔

اسپن اپ مرحلہ 11 میں CSI پہلے سے ہی انسٹال تھا، لہذا انسٹال کرنے کے لیے کوئی اضافی چیز نہیں ہے۔

مرحلہ 1: تصدیق کریں کہ CSI چل رہا ہے۔

kubectl get pods -n kube-system -l app=secrets-store-csi-driver
kubectl get secretproviderclass -n clearledger

آپ کو ہر نوڈ میں ایک CSI ڈرائیور پوڈ نظر آئے گا، آپ کو دو نظر آئیں گے۔ SecretProviderClass آبجیکٹ: ایک توثیق کی خدمت کے لیے اور ایک لیجر سروس کے لیے۔

مرحلہ 2: گٹ میں تعیناتی کو تبدیل کریں۔

کھلا stages/stage-8-aws-migration/manifests/kustomization.yaml ایک لائن تبدیل کریں:

# Before
  - deployments/auth-service.yaml

# After
  - deployments/auth-service-csi.yaml

کمٹ کریں، دبائیں، اور مطابقت پذیری کریں۔

argocd app sync clearledger-aws
kubectl rollout status deployment/auth-service -n clearledger

ArgoCD ایک نئی تصدیقی سروس پوڈ شروع کرے گا جس میں CSI والیوم منسلک ہیں۔

مرحلہ 3: چیک کریں کہ آیا فائل موجود ہے۔

# Find the new pod
kubectl get pod -n clearledger -l secrets=csi

# List the mounted secret files
kubectl exec -n clearledger deploy/auth-service -- ls /mnt/secrets

# Check the database URL was written correctly
kubectl exec -n clearledger deploy/auth-service -- cat /mnt/secrets/database_url

# Confirm the service is still healthy
curl -s "http://$(kubectl get ingress clearledger-ingress -n clearledger 
  -o jsonpath="{.status.loadBalancer.ingress[0].hostname}")/auth/health"

آپ کو دیکھنا چاہئے database_url اور jwt_secret اسے ایک فائل کے طور پر درج کیا جائے گا اور اسٹیٹس چیک کو واپس کیا جانا چاہیے۔ {"status":"ok"}.

ESO بمقابلہ CSI: واقعی کیا بدلا ہے؟

دونوں راستے AWS سیکرٹس مینیجر سے ایک ہی راز پڑھتے ہیں۔ صرف شپنگ کا طریقہ بدل جائے گا۔

ESO (پہلے سے طے شدہ، جیسا کہ §8.4 میں دیکھا گیا ہے)

ESO کو ایک کلسٹر پر چلنے والے کاپی آفس کے طور پر سوچیں۔

1. ESO کی اپنی AWS اجازتیں (IAM رولز) ہیں۔

2. یہ پڑھتا ہے clearledger/auth-service سیکرٹس مینیجر میں۔

3. اقدار کو ایک عام Kubernetes راز میں کاپی کریں جس کا نام ہے: auth-service-secret.

4. توثیق پوڈ پڑھتا ہے: DATABASE_URL اور JWT_SECRET پسند ماحولیاتی متغیرات۔

راز کلسٹر کے اندر ایک Kubernetes خفیہ آبجیکٹ کے طور پر مختصر طور پر موجود ہے۔

CSI (یہ مشق، ماؤنٹ فائل)

آپ CSI کو ایک پوڈ کے طور پر سوچ سکتے ہیں جو شروع ہونے پر اپنے طور پر راز اکٹھا کرتا ہے۔

1. auth-service pod کے پاس اپنی AWS اجازتیں ہیں (IRSA for ServiceAccount)۔

2. جب کوئی پوڈ شروع ہوتا ہے، تو CSI ڈرائیور سیکرٹس مینیجر سے اقدار کی درخواست کرتا ہے۔

3. یہ ذیل میں فائل کے طور پر ظاہر ہوتا ہے. /mnt/secrets/ (database_url, jwt_secret)۔

4. فورڈ کیا کہتا ہے۔ DATABASE_URL_FILE=/mnt/secrets/database_url ڈسک سے پڑھیں K8s کے راز کاپی نہیں کیے گئے۔

اس راستے میں اس قدر کے لیے Kubernetes راز کی کوئی کاپی نہیں بنائی گئی ہے۔

ایک ہی ایپ کوڈ دونوں کے لیے کیوں کام کرتا ہے؟

app/auth-service/main.py تھوڑا سا مددگار استعمال کریں۔ _read_secret():

ایک ہی تصویر، وہی کوڈ: YAML صرف اس تقسیم کو تبدیل کرتا ہے جس کے ساتھ آرگو سی ڈی مطابقت پذیر ہوتی ہے۔

ESO پر واپس جانے کے لیے: کو kustomization.yamlتبدیلی auth-service-csi.yaml دوبارہ auth-service.yamlکمٹ، دھکا اور argocd app sync clearledger-aws.

ٹیرافارم تمام AWS وسائل (VPC، EKS، RDS، ECR، سیکرٹس مینیجر، اور IAM کردار) فراہم کریں۔ .tf فائل stages/stage-8-aws-migration/terraform/.

8 مراحل میں دو OIDC آئیڈیاز

مرحلہ 8 دو مختلف جگہوں پر OIDC کا استعمال کرتا ہے۔ اگرچہ وہ ایک جیسے نظر آتے ہیں، وہ مختلف مسائل کو حل کرتے ہیں.

گٹ ہب ایکشن OIDC آپ کی CI پائپ لائن GitHub میں طویل عرصے تک AWS کیز کو ذخیرہ کیے بغیر تصاویر کو ECR پر دھکیل سکتی ہے۔ جب کوئی کام چلتا ہے، GitHub ایک مختصر مدت کا ٹوکن جاری کرتا ہے جو کام کی شناخت کو ثابت کرتا ہے۔ AWS اس ٹوکن پر بھروسہ کرتا ہے اور امیج کو آگے بڑھانے کے لیے کافی عارضی اسناد واپس کرتا ہے۔

IRSA یہ ان پھلیوں کا معاملہ ہے جو ایک ہی کام کرتے ہیں لیکن EKS کے اندر چلتے ہیں۔ GitHub ٹوکن کے بجائے، Pods ایک Kubernetes ServiceAccount ٹوکن فراہم کرتے ہیں۔ AWS EKS کلسٹر کے OIDC فراہم کنندہ پر بھروسہ کرتا ہے، ٹوکن کی تصدیق کرتا ہے، اور پوڈ کے لیے درکار دائروں میں عارضی اسناد واپس کرتا ہے۔

ہر آئٹم کو چیک کرنا مفید ہوگا۔

GitHub Actions OIDC:
  Pipeline says → "I am a job in the production environment of YOUR_USERNAME/clearledger"
  AWS replies   → "Here are credentials to push to ECR, valid for one hour"

IRSA:
  Pod says   → "I am the auth-service ServiceAccount in the clearledger namespace"
  AWS replies → "Here are credentials to read only the auth-service secret, valid for one hour"

کلید کیا ہے؟ ~ نہیں کہیں بھی ذخیرہ:

No AWS_ACCESS_KEY_ID in GitHub Secrets
No AWS_SECRET_ACCESS_KEY in GitHub Secrets
No AWS keys inside Kubernetes Secrets

Terraform کردار تخلیق کرتا ہے۔ clearledger-github-actions-ecr دونوں کے لیے اعتماد کی پالیسی کو منسلک کریں۔ پائپ لائن .github/workflows/ci-aws.yaml کردار سنبھالیں، تصویر کو ECR پر پش کریں، اور اسے اپ ڈیٹ کریں۔ kustomization.yaml. ArgoCD تبدیلیاں اٹھاتا ہے اور نئی تصویر کو تعینات کرتا ہے۔

CI روٹنگ: مراحل 1-7 اور 8

ذخیرہ دو ورک فلو فائلیں فراہم کرتا ہے: آپ کو ایک ہی وقت میں دونوں کو چلانے کی ضرورت نہیں ہے۔

ci.yaml یہ مرحلہ 1 سے 7 تک ہوم لیب کی پائپ لائن ہے۔ خود میزبان ملٹی پاس VM پر چلتی ہے، تصاویر کو Docker Hub میں دھکیلتی ہے، clearledger-infra GitOps ذخیرہ۔ یہ پہلے سے طے شدہ ہے۔ ترتیب دینے کے لیے کچھ نہیں ہے۔

ci-aws.yaml اسٹیج 8 کے لیے AWS پائپ لائن۔ GitHub پر میزبانی کی گئی۔ ubuntu-latest رنر، پش اور تصاویر کو ای سی آر میں اپ ڈیٹ کریں۔ kustomization.yaml براہ راست اس مخزن سے۔ یہ صرف اس وقت چالو ہوتا ہے جب آپ ریپو متغیر کو سیٹ کرتے ہیں۔ CLEARLEDGER_CI_TARGET=aws.

اگر آپ 1-7 مراحل میں ہیں، تو کچھ نہ کریں۔ کہ CLEARLEDGER_CI_TARGET متغیر بطور ڈیفالٹ سیٹ نہیں ہوتا ہے، لہذا ہر دھکا پر عمل درآمد ہوتا ہے۔ ci.yaml عام طور پر خود میزبان رنر پر۔ AWS ورک فلو فائل ریپوزٹری میں ہے، لیکن کام چھوڑ دیا گیا ہے۔

سیٹ نہیں ہے۔ CLEARLEDGER_CI_TARGET=aws جب تک EKS کلسٹر نہیں چل رہا ہے۔

اگر آپ اسے جلد ترتیب دیتے ہیں۔ ci.yaml پش چلنا بند ہوجاتا ہے (مزید ڈوکر ہب نہیں بنتا ہے)۔ ci-aws.yaml یہ فوری طور پر ناکام ہو جائے گا کیونکہ آپ کے پاس ابھی تک ECR، OIDC رول، یا AWS انفراسٹرکچر نہیں ہے۔ متغیر کو حذف کریں اگر غلطی سے سیٹ ہو جائے: GitHub → repo ترتیب → راز اور متغیرات → عمل → متغیر → حذف کریں۔ CLEARLEDGER_CI_TARGET.

AWS CI کو فعال کریں (آپ یہ بعد میں کریں گے) terraform apply مکمل)

ایک فائل کے لیے 3 سٹوریج متغیرات اور 1 خفیہ کی ضرورت ہوتی ہے۔ production ماحول

سب سے پہلے، متغیرات کو سیٹ کریں. YOUR_USERNAME اپنے GitHub صارف نام کے ساتھ:

gh variable set CLEARLEDGER_CI_TARGET --body aws --repo YOUR_USERNAME/clearledger

gh variable set AWS_ACCOUNT_ID --body "$(aws sts get-caller-identity --query Account --output text)" --repo YOUR_USERNAME/clearledger

gh variable set AWS_REGION --body eu-west-1 --repo YOUR_USERNAME/clearledger

پھر production اپنا ماحول منتخب کریں اور OIDC رول ARN کو بطور راز شامل کریں۔

# Create the environment first, gh secret set returns 404 if it does not exist
gh api --method PUT "repos/YOUR_USERNAME/clearledger/environments/production"

gh secret set AWS_ACTIONS_ROLE_ARN 
  --env production 
  --body "$(terraform -chdir=stages/stage-8-aws-migration/terraform output -raw github_actions_ecr_role_arn)" 
  --repo YOUR_USERNAME/clearledger

میمو: GitHub اس سے شروع ہونے والے خفیہ ناموں کو روکتا ہے: GITHUB_. استعمال کریں AWS_ACTIONS_ROLE_ARNنہیں GITHUB_ACTIONS_ROLE_ARN.

بھی چیک کریں۔ github_owner صحیح طریقے سے ترتیب دیا گیا ہے۔ terraform.tfvars (دیکھیں۔ terraform.tfvars.example) چلانے سے پہلے terraform apply. یہ OIDC ٹرسٹ پالیسی کو منسلک کرتا ہے تاکہ AWS مخصوص GitHub اکاؤنٹ سے ٹوکن قبول کرے۔

ایک بار CLEARLEDGER_CI_TARGET=aws اگر سیٹ ہو تو، جب بھی آپ دبائیں گے۔ main AWS پائپ لائن چلائیں: Gitleaks → Semgrep → Checkov → Build → Trivy scan → ECR push → کسٹمائزیشن اپ ڈیٹ۔ ہوم لیب ci.yaml چھوڑیں۔

اگر CI ECR پش مرحلے کے دوران ناکام ہو جاتا ہے:

سب سے عام ناکامی ہے Not authorized to perform sts:AssumeRoleWithWebIdentity. اس کا مطلب ہے کہ IAM رول ٹرسٹ پالیسی میں اب بھی پلیس ہولڈر موجود ہے۔ YOUR_GITHUB_USERNAME پر :sub صورت حال اسے ترتیبات کے ساتھ حل کریں۔ github_owner کو terraform.tfvars اور چل رہا ہے۔ terraform apply اس کے بعد یہ صرف ناکام کاموں کو دوبارہ چلاتا ہے (پوری پائپ لائن نہیں: پچھلا اسکین مرحلہ گزر چکا ہے)۔

GitHub → Actions → failed run → Re-run failed jobs

اگر آپ دیکھتے ہیں 404 جب چل رہا ہے۔ gh secret set, production ماحول ابھی موجود نہیں ہے۔ پھانسی gh api --method PUT سب سے پہلے مندرجہ بالا کمانڈ.

OIDC میں ترمیم کریں اور اسے دوبارہ چلائیں۔ یہ صرف ناکام کاموں پر لاگو ہوتا ہے، پوری پائپ لائن پر نہیں۔ پچھلے گیٹس (Gitleaks, Build, Scan) پہلے ہی پاس ہو چکے ہیں اور ان کے نمونے ابھی بھی ورک فلو پر عملدرآمد میں ہیں۔ ہر چیز کو دوبارہ کریں صرف اس صورت میں استعمال کریں جب آپ نے اپنا ایپ کوڈ تبدیل کر دیا ہو یا شروع سے کلین چیک کرنا چاہتے ہو۔

پیداوار بڑھانے کی چیک لسٹ

لیب کا فن تعمیر پروڈکشن سٹائل ہے، لیکن ایک حقیقی پروڈکشن سیٹ اپ کے لیے اضافی گارڈریلز کی ضرورت ہوتی ہے۔ یہ بتانے سے پہلے کہ یہ پیداوار کے لیے تیار ہے۔

1. اپنے اہم نکات کی حفاظت کریں۔

GitHub کے دونوں ذخیروں کو محفوظ کریں۔

github.com/YOUR_GITHUB_USERNAME/clearledger
github.com/YOUR_GITHUB_USERNAME/clearledger-infra

ہر ذخیرے پر جائیں۔

Settings
→ Rules
→ Rulesets
→ New ruleset
→ Branch targeting: main

فعال کریں:

Require a pull request before merging
Require approvals
Require status checks to pass
Require branches to be up to date before merging
Block force pushes
Block branch deletion

یہ کیوں ضروری ہے: کسی کو بھی براہ راست پروڈکشن میں کوڈ ریپوزٹری یا GitOps ریپوزٹری کی طرف دھکیلنا نہیں چاہئے۔ برا براہ راست دھکا clearledger-infra یہ براہ راست تقسیم کی درخواست ہے۔

2. اجازت کے ساتھ GitHub ماحول استعمال کریں۔

ایک محفوظ ماحول بنائیں۔

clearledger repo
→ Settings
→ Environments
→ New environment
→ Name: production
→ Required reviewers: add yourself or the team
→ Deployment branches: main only

AWS ورک فلو استعمال کرتا ہے:

environment: production

اس کا مطلب ہے کہ GitHub آپ کی AWS تعیناتی کو اس وقت تک روک دے گا جب تک کہ کوئی منظور شدہ جائزہ لینے والا اس کی اجازت نہیں دیتا۔ یہ "ہر دھکا پروڈکشن میں تعینات ہو جاتا ہے" کے بجائے ایک حقیقی پروموشن گیٹ بناتا ہے۔

3. دانے دار ٹوکنز یا GitHub ایپس کو ترجیح دیں۔

بنیادی لیبارٹریوں کے معاملے میں، INFRA_REPO_TOKEN ایک کلاسک PAT ہو سکتا ہے۔ پیداوار کے لیے سخت کریں۔

بہتر اختیارات:

Fine-grained personal access token
→ Repository access: only YOUR_GITHUB_USERNAME/clearledger-infra
→ Permissions:
   Contents: Read and write
   Metadata: Read

اپنی ٹیم کے لیے بہترین آپشن: GitHub ایپس کو صرف ان پر انسٹال کریں: clearledger-infraآپ کو مواد لکھنے کی اجازت ہے۔ یہ نجی ٹوکن کے مقابلے بہتر آڈٹ لاگ اور آسان گردش فراہم کرتا ہے۔

اسٹور INFRA_REPO_TOKEN باقاعدہ ذخیرہ راز کے بجائے پیداواری ماحول کے راز کے ساتھ:

clearledger
→ Settings
→ Environments
→ production
→ Environment secrets
→ INFRA_REPO_TOKEN

4. پیداوار میں AWS OIDC پن کریں۔

یہ شیل کمانڈ نہیں ہے۔ ٹرسٹ کا اصول ہے کہ جب ٹیرافارم چلتا ہے تو AWS کو لکھتا ہے۔ terraform apply.

میں iam.tfIAM کا کردار clearledger-github-actions-ecr صرف مماثل عنوان کے دعووں کے ساتھ GitHub ٹوکن قبول کیے جاتے ہیں۔

repo:YOUR_GITHUB_USERNAME/clearledger:environment:production

صرف GitHub ایکشن ٹاسک چل رہے ہیں۔ production آپ کا ماحول clearledger ایک ریپو ECR پش رول کو لے سکتا ہے۔ متعلقہ ماحول کے بغیر کوئی بھی برانچ، فورک، یا ورک فلو AWS اسناد حاصل نہیں کر سکتا۔

آپ کیا کرتے ہیں:

1. سیٹ github_owner کو terraform.tfvarsپھر terraform apply (مرحلہ 2 از 8)۔

2. GitHub پر: ترتیبات → ماحولیات → پیداوار۔ اگر وہ غائب ہو تو انہیں بنائیں اور اگر چاہیں تو تحفظ کے اصول شامل کریں۔

3. ماحولیاتی پاس ورڈ شامل کریں۔ AWS_ACTIONS_ROLE_ARN = terraform output -raw github_actions_ecr_role_arn.

4. ci-aws.yaml پہلے سے سیٹ environment: production ECR آپریشنز میں، یہ وہی چیز ہے جو GitHub منٹ کو مماثل ٹوکن بناتی ہے۔

چیک کریں کہ آیا کوئی اصول موجود ہے (اختیاری)۔

aws iam get-role --role-name clearledger-github-actions-ecr 
  --query 'Role.AssumeRolePolicyDocument.Statement[0].Condition.StringEquals."token.actions.githubusercontent.com:sub"' 
  --output text

توقع: repo:your-username/clearledger:environment:production

دستی 8 قدمی راستہ آپ کو GitHub CI کو مکمل طور پر چھوڑنے کی اجازت دیتا ہے۔ یہ تالا صرف اس صورت میں اہم ہے جب آپ CI, AWS (ECR + OIDC) کو فعال کرتے ہیں۔

5. پری پروڈکشن کی تیاری (کوئی پروموشن نہیں، دوبارہ تعمیر نہیں)

لیب کا بہاؤ: اندر دھکیلنا main → ci-aws.yaml بنائیں اور اسکین کریں → CI اپ ڈیٹ stages/stage-8-aws-migration/manifests/kustomization.yaml → آرگو سی ڈی کو نئے امیج ٹیگز کے ساتھ سنک کریں۔ clearledger-aws.

ہوم لیب کے مراحل 1-7 اب بھی استعمال کیے جاتے ہیں۔ clearledger-infra اور ڈوکر حب۔ مرحلہ 8 AWS ریپوزٹری کے اندر کسٹمائز پاتھ کا استعمال کرتا ہے۔

حقیقی پیداوار میں، ہم درمیان میں ایک مرحلہ وار شامل کرتے ہیں۔ اس کا مطلب ہے کہ آپ تصویر کو ایک بار بناتے ہیں، اسی ٹیگ یا ڈائجسٹ کو اسٹیجنگ پر لگاتے ہیں، اسموک ٹیسٹ چلاتے ہیں یا دستی منظوری حاصل کرتے ہیں، اور پھر اسے دوبارہ تعمیر کیے بغیر پروڈکشن میں فروغ دیتے ہیں۔

کیوں اس کی وجہ یہ ہے کہ پروڈکشن کے لیے دوبارہ تعمیر کرنے کے نتیجے میں اسٹیجنگ گزرنے والے کوڈ سے مختلف ہو سکتا ہے۔ ایک محفوظ نمونہ ایک نمونہ ہے جو ایک بار آزمایا جاتا ہے اور دو بار فروغ دیا جاتا ہے۔

Build once (one image SHA)
  → deploy to staging
  → test / approve
  → deploy the same SHA to production

6. جب بھی ممکن ہو ذاتی نیٹ ورکنگ کا استعمال کریں۔

پیداوار AWS کے لیے:

- EKS nodes in private subnets
- RDS in private subnets
- Private EKS API endpoint, or restricted public endpoint
- Security groups scoped to required ports only
- ALB public only if the app is public
- No SSH-based deployment path

پائپ لائن کو AWS APIs کے ساتھ IAM/OIDC کے ذریعے رابطہ کرنا چاہیے اور GitOps کے ذریعے تعینات کرنا چاہیے۔ آپ کو اپنے EC2 مثال میں SSH نہیں کرنا چاہئے۔

7. Terraform ریاست کو دور سے محفوظ کریں۔

مقامی ٹیرافارم ریاست لیبز کے لیے موزوں ہے۔ پیداوار میں، آپ کو انکرپٹڈ ریموٹ اسٹیٹ استعمال کرنا چاہیے۔

- S3 bucket for terraform.tfstate
- DynamoDB table for state locking
- SSE encryption enabled
- Bucket versioning enabled
- Public access blocked

ٹیرافارم بیک اینڈ بلاکس پہلے ہی شامل ہیں۔ stages/stage-8-aws-migration/terraform/main.tf ایک تشریح شدہ ٹیمپلیٹ کے طور پر۔
S3 بالٹی اور DynamoDB لاک ٹیبل بنانے کے بعد، ان پر تبصرہ کریں۔

پیداوار کی تیاری کا خلاصہ:

- CI builds and proves the artifact.
- GitHub Environments approve production.
- OIDC gives short-lived AWS credentials.
- ECR stores immutable images.
- kustomization.yaml (Stage 8 path) records desired state.
- ArgoCD clearledger-aws deploys from Git.
- No SSH. No static AWS keys. No direct kubectl from CI.

یو آر ایل کھولیں۔ ClearLedger AWS پر چلتا ہے۔ وہی فن تعمیر، وہی حفاظتی تہہ، نیا انفراسٹرکچر۔

مکمل ہونے پر اسے ضائع کر دیں۔ اس سے تمام چارجز رک جائیں گے۔

make aws-down

دیکھیں stages/stage-8-aws-migration/README.md مکمل ٹور اور لاگت کے حوالے دیکھیں۔

آپ نے مرحلہ 8 میں کیا سیکھا۔

• کنٹینرائزڈ ایپلی کیشنز پورٹیبل ہیں۔ ایک ہی کوڈ لیپ ٹاپ اور AWS دونوں پر چلتا ہے۔

• Terraform کیا کرتا ہے: اپنے بنیادی ڈھانچے کو کوڈ کے طور پر قرار دیں تاکہ آپ اپنے ماحول کو دوبارہ تیار کر سکیں۔

• کلاؤڈ مائیگریشن میں کیا تبدیلیاں آتی ہیں (منظم خدمات، آئی اے ایم، نیٹ ورکنگ) اور کیا نہیں بدلتا (ایپلی کیشن کوڈ، سی آئی لاجک، سیکیورٹی پالیسیاں)

• تین AWS خفیہ ترسیل کے راستوں کا موازنہ: ESO (پہلے سے طے شدہ)، CSI فائل ماؤنٹ (§8.5)، اور HomeLab's Vault

• AWS مخصوص سیکیورٹی سروسز: گارڈ ڈیوٹی (خطرے کا پتہ لگانے)، کلاؤڈ ٹریل (API آڈیٹنگ)، GitHub ایکشنز OIDC (طویل مدتی کیلیس پائپ لائن AWS تصدیق)، اور IRSA (پوڈ لیول IAM بغیر طویل مدتی اسناد کے)

اب آپ اپنے تجربے کی فہرست میں کیا ڈال سکتے ہیں/ایک انٹرویو میں کہہ سکتے ہیں:

ہم نے درخواست کو دوبارہ لکھے بغیر اسی فن تعمیر کو AWS میں منتقل کیا جو Terraform (بشمول EKS، ECR، RDS، ALB، ایکسٹرنل سیکرٹ آپریٹر، اور IRSA کے ذریعے راز) میں فراہم کیا گیا ہے۔

جب آپ AWS استعمال کر لیں تو اسے ختم کر دیں اور بلنگ بند کر دیں۔

make aws-down

Homelab VM الگ ہے۔ اگر آپ واپس آنے کا ارادہ رکھتے ہیں، تو آپ کے پاس پہلے سے ہی مرحلہ 7 کا سنیپ شاٹ ہونا چاہیے (make snapshots تصدیق کرنے کے لیے)۔ سیونگ پروگریس دیکھیں۔

پوڈ زیر التواء حالت میں پھنس گیا:

kubectl describe pod POD_NAME -n clearledger
# Insufficient memory/cpu → reduce resource requests
# Image pull error → check Docker Hub repo name and credentials

Kyverno بلاک کرنے کی تعیناتی:

kubectl get events -n clearledger --sort-by='.lastTimestamp' | tail -10
kubectl get policyreport -n clearledger -o yaml

والٹ ایجنٹ راز نہیں لگاتا:

kubectl logs POD_NAME -n clearledger -c vault-agent-init
kubectl exec -n vault vault-0 -- vault read auth/kubernetes/role/auth-service

Falco انتباہ جاری نہیں کرتا:

kubectl logs -n falco daemonset/falco | grep -i error | tail -20

ArgoCD OutOfSync دکھاتا ہے:

argocd app sync clearledger --force
argocd app get clearledger
kubectl get events -n clearledger --sort-by='.lastTimestamp'

Clearledger.local حل نہیں ہوا:

multipass info clearledger | grep IPv4
grep clearledger /etc/hosts
# If the IP changed, update /etc/hosts

VM ڈسک مکمل یا پوڈ ہٹا دیا گیا (ڈسک پریشر):

make doctor     # PASS / WARN / FAIL + PVC and Prometheus TSDB sizes
make reclaim    # safe reclaim — unused images + journald only (not PVCs)

اگر یہ دوبارہ حاصل کرنے کے بعد بھی ناکام ہو جاتا ہے، تو اسے ختم کر کے دوبارہ پیدا کریں۔ make teardown && make setup. مکمل ہدایات: Troubleshooting.md: ڈسک کی حیثیت اور VM ڈسک بھری ہوئی ہے۔

تعمیل کا حوالہ

ہر کنٹرول ایک یا زیادہ فریم ورک کے نقشے بناتا ہے۔ مکمل نقشہ سازی: docs/compliance-mapping.md.

کنٹرول	سامان	قدم	PCI-DSS	SOC2	CIS K8
خفیہ پتہ لگانا	گٹلیکس	3	6.2	CC8.1	-
SAST	شیمگریب	3	6.3.2	CC7.1	-
انحصار کی تلاش	ٹریوی ایس سی اے	3	6.3.3	CC7.1	-
IaC اسکین	چیکر	3	6.3.1	CC6.1	-
تصویر کے دستخط	مشترکہ نشان	3	6.3	CC6.1	-
SBOM بنائیں	سوفٹ	3	6.3.3	CC6.1	-
غیر جڑ کنٹینر	کیبرنو	4	6.5	CC6.3	5.2.6
وسائل کی حدود	کیبرنو	4	-	A1.1	5.2.4
مراعات کی کوئی بلندی نہیں۔	کیبرنو	4	6.5	CC6.3	5.2.5
خفیہ انتظام	والٹ	5	3.5	CC6.1	-
رن ٹائم کا پتہ لگانا	فالکو	6	10.7	CC7.2	-
نیٹ ورک سیگمنٹیشن	نیٹ ورک کی پالیسی	6	1.3	CC6.6	5.3.2
حفاظتی مشاہدہ	گرافانا	7	10.6	CC7.2	-
DORA اشارے	ArgoCD + گرافانا	7	-	-	-
اکاؤنٹ کے خطرے کا پتہ لگانا	گارڈ ڈیوٹی	8	10.6	CC7.2	-
API آڈٹ ٹریل	کلاؤڈ ٹریل	8	10.2	CC7.3	-

EU ڈیجیٹل آپریشنز ریسیلینسی ایکٹ (DORA): جنوری 2025 سے یورپی یونین کے مالیاتی اداروں پر لاگو ہوتا ہے۔ ClearLedger تمام پانچوں DORA اصولوں کا نقشہ بناتا ہے۔ مکمل نقشہ سازی docs/compliance-mapping.md.

انٹرویو کی تیاری

مکمل کمزور/مضبوط جوابات: docs/interview-prep.md

جیسا کہ آپ ہر قدم کو مکمل کرتے ہیں، درج ذیل پر عمل کریں:

مرحلہ 0: Kubernetes میں ٹریفک کیسے خدمات تک پہنچتی ہے؟ جب تعیناتی دستی ہوتی ہے تو سب سے پہلے کون سی چیز رک جاتی ہے؟

مرحلہ 1: میں یہ کیسے ثابت کروں کہ کون سی تصویر کسی مخصوص کمٹ کے لیے لگائی گئی تھی؟ ڈویلپرز کو CI کو نظرانداز کرنے سے کیا روک رہا ہے؟

مرحلہ 2: میکانکی طور پر GitOps کا کیا مطلب ہے؟ آپ کیسے ثابت کرتے ہیں کہ بہاؤ خود بخود درست ہوجاتا ہے؟

مرحلہ 3: SAST، IaC اسکیننگ اور امیج اسکیننگ میں کیا فرق ہے؟ معذوری کی شدت کی حد کیا ہے؟

مرحلہ 4: داخلہ کنٹرول کیا ہے اور یہ CI سے مختلف کیوں ہے؟ پالیسی مستثنیات کو محفوظ طریقے سے کیسے متعارف کرایا جا سکتا ہے؟

مرحلہ 5: کبرنیٹس کے راز "خفیہ انتظام" کیوں نہیں ہیں؟ ڈاؤن ٹائم کے خطرے کو کم کرتے ہوئے آپ رازوں کو کیسے بدلتے ہیں؟

مرحلہ 6: رن ٹائم کا پتہ لگانے سے کیا گرفت ہوتی ہے جو CI اور منظوری نہیں کر سکتی؟ شیل سپون وارننگ پر آپ کا پہلا ردعمل کیا ہے؟

مرحلہ 7: ڈیش بورڈز اور الرٹس میں کیا فرق ہے؟ آپ صرف دعووں کے بجائے آڈٹ ثبوت کیسے تیار کرتے ہیں؟

مرحلہ 8: جب آپ EKS پر سوئچ کرتے ہیں تو اصل میں کیا تبدیلیاں آتی ہیں؟ کیا تبدیل نہیں ہونا چاہئے؟ IRSA خطرے کو کیسے کم کرتا ہے؟

AWS لاگت کا حوالہ

پہلے سے طے شدہ مرحلہ 8 سائز (eu-west-1، تخمینی):

مرضی	ماہانہ (8 گھنٹے فی دن)	ماہانہ (سال بھر کھلا)
ای کے ایس کنٹرول ہوائی جہاز	~$24	~$73
3× t3.میڈیم نوڈس	~$30	~$92
NAT گیٹ وے	~$11	~$33
RDS db.t3.micro	~$4	~$13
alb	~$2	~$6
گارڈ ڈیوٹی + کلاؤڈ ٹریل	~$2	~$5
کل تخمینہ	~$73	~$222

استعمال میں نہ ہونے پر ہمیشہ تباہ کریں۔

make aws-down

نتیجہ

آپ نے اب ایک فنٹیک ایپلی کیشن بنائی ہے اور اس کے اوپر سیکیورٹی اور قابل اعتماد کنٹرول کی آٹھ پرتیں بنائی ہیں۔ آپ کے لیپ ٹاپ پر سب ممکن ہے۔

فیز 0 میں، ہم نے خام کبرنیٹس اور دستی تعیناتی کے ساتھ شروعات کی۔ مرحلہ 1 میں، ہم نے ایک CI پائپ لائن شامل کی ہے جو خود بخود تصاویر بناتی، اسکین کرتی اور سائن کرتی ہے۔ مرحلہ 2 میں، آپ نے گٹ کو اپنے کلسٹر سے جوڑنے کے لیے ArgoCD کا استعمال کیا۔ فیز 3 میں، SAST، IaC، اور امیج اسکیننگ کا استعمال کرتے ہوئے تمام پشز کو کنٹرول کیا گیا۔ مرحلہ 4 میں، ہم نے کلسٹر بارڈر پر ناگوار کام کے بوجھ کو روکنے کے لیے Kyverno کا استعمال کیا۔ مرحلہ 5 میں، آپ نے اسناد کو Git اور Kubernetes secrets سے Vault میں منتقل کر دیا۔ Falco اور نیٹ ورک کا استعمال کرتے ہوئے رن ٹائم خطرے کا پتہ لگانا شامل کیا گیا۔ 6 مراحل میں تقسیم۔ مرحلہ 7 میں، ہم نے ایک مشاہداتی ڈیش بورڈ بنایا جو آڈٹ کے ثبوت تیار کرتا ہے۔ اور مرحلہ 8 میں، ہم نے ہر چیز کو AWS میں منتقل کر دیا۔

ان اقدامات میں سے کوئی بھی کھلونا مشق نہیں ہے۔ ہر ایک ایک حقیقی مسئلہ کی نمائندگی کرتا ہے جس کا سامنا حقیقی ٹیموں کو پیداوار میں ہوتا ہے۔ درد محسوس کرنے کے بعد، ہم نے ایک حل بنایا. DevSecOps کے بارے میں پڑھنے اور اسے کرنے کے قابل ہونے میں یہی فرق ہے۔

انٹرویو کی تیاری کے سیکشن کا استعمال کریں جب آپ کو اسکرین شاٹس لینے، مخصوص ٹولز اور نتائج کے ساتھ اپنے ریزیومے کو اپ ڈیٹ کرنے، اور اپنے کیے گئے فیصلوں پر بحث کرنے کی ضرورت ہو۔ آپ نے ان سب کو بنایا۔

اگر آپ کو یہ گائیڈ کارآمد معلوم ہوا، تو اسے DevOps یا DevSecOps میں توڑنے والے کسی کے ساتھ بھی شیئر کریں۔ LinkedIn سے جڑیں۔.

ہم ڈی او اوپس کی مشقیں اور ملازمت کے لیے انٹرویو کی تجاویز بھی پوسٹ کرتے ہیں۔ پیروی کریں یا وہاں شامل ہوں اگر آپ مزید چاہتے ہیں۔