DevOps ایک آلہ نہیں ہے، یہ ایک زنجیر ردعمل ہے

ٹھیک ہے. چلو شروع کریں. اس مضمون کو شروع کرنے کے لئے کچھ اہم اجزاء میں DevOps اور ان کو جدید ترقی کے عمل میں کس طرح شامل کرنے کے لئے ڈھونڈنا چاہتا ہے. ایک ہی موضوع کی وضاحت کرنے کے لئے بہت سے ویب مضامین ہیں، اور میں یہاں کچھ جدید فراہم کرنے کا ارادہ نہیں رکھتا. اس کے بجائے، میں بنیادی سگنل پر توجہ مرکوز کرنا چاہتا ہوں - جو اہم ہے - تاکہ ضروریات تمام شور کے درمیان واضح طور پر آتے ہیں. +------------------------------------------------+ | THE DEVOPS PROCESS FLOW | +==================+=============================+ | STAGE | KEY ACTION | +==================+=============================+ | 1. Code | Write and commit changes | +------------------+-----------------------------+ | 2. Build | Compile and package code | +------------------+-----------------------------+ | 3. Test | Run automated tests | +------------------+-----------------------------+ | 4. Deploy | Release to production | +------------------+-----------------------------+ | 5. Feedback | Monitor and inform new code | +------------------+-----------------------------+ | (Repeat) | The loop continues... | +------------------+-----------------------------+ Diagram 1: DevOps کی پروسیسنگ فلائٹ Diagram 1: DevOps کی پروسیسنگ فلائٹ +======================================================+ | Process Transformation: DevOps | +======================+===============================+ | STAGE | MANUAL (BEFORE) | +======================+===============================+ | Code Integration | Manual merges, "merge hell" | | Build | Run on local machine | | Test | Manual testing, slow | | Deploy | Manual scripts, risky | |----------------------+-------------------------------| | **Result** | Slow, Error-Prone, Stressful | +======================+===============================+ | STAGE | AUTOMATED (AFTER) | +======================+===============================+ | Code Integration | Auto-merge via CI server | | Build | Automated build on push | | Test | Automated tests run in pipe | | Deploy | Automated CD to production | |----------------------+-------------------------------| | **Result** | Fast, Reliable, Repeatable | +======================+===============================+ فہرست 2: DevOps کے فوائد فہرست 2: DevOps کے فوائد سادہ ترقی سے پیچیدہ حقیقت تک جب ہم ترقی کے بارے میں سوچتے ہیں تو، ہم عام طور پر یہ بہت سادہ الفاظ میں تصور کرتے ہیں. ایک پروگرامر کوڈ لکھتا ہے، اور یہ ویب سائٹ پر لاگو ہوتا ہے. لیکن عملی طور پر، عمل ایک مختصر وقت میں بہت پیچیدہ ہوسکتا ہے. کئی پروگرامر ایک ہی کوڈ بیس پر کام کر رہے ہیں. ایک شخص کی طرف سے کیا گیا کوڈ تبدیلیوں کو متاثر کرسکتا ہے جو دوسرے نے پہلے سے ہی تعمیر کیا ہے. یہ اہم ہے کہ کس نے کیا اور کب تبدیل کیا ہے، لہذا اگر کچھ غلط ہو تو واپس پلٹنے کے لئے آسان ہے. یہ وہاں ہے جہاں ایک ذریعہ کوڈ مینجمنٹ سسٹم جیسے Git میں آتا ہے - یہ ہر تبدیلی، ہر ورژن کی پیروی کرتا ہے، اور کئی ڈویلپرز کو مؤثر اور آسانی سے تعاون کرنے کی اجازت دیتا ہے. ╔═══════════════════════════════════════════════════╗ ║ THE ILLUSION VS REALITY OF DEVELOPMENT ║ ╚═══════════════════════════════════════════════════╝ WHAT WE IMAGINE WHAT ACTUALLY HAPPENS ┌──────────────┐ ┌──────────────┐ │ Programmer │ │ Programmer A │ └──────┬───────┘ └──────┬───────┘ │ │ ▼ ▼ ┌──────────────┐ ┌──────────────┐ │ Code │ │ Code v1 │◄─┐ └──────┬───────┘ └──────────────┘ │ │ │ │ ▼ │ CONFLICT! ┌──────────────┐ │ │ │ Website │ ▼ │ └──────────────┘ ┌──────────────┐ │ │ Code v2 │──┘ SIMPLE └──────────────┘ ▲ │ ┌──────┴───────┐ │ Programmer B │ └──────────────┘ COMPLEX Diagram 3: سافٹ ویئر کی ترقی کی حقیقت کی وضاحت کرتا ہے Diagram 3: سافٹ ویئر کی ترقی کی حقیقت کی وضاحت کرتا ہے ╔═════════════════════════════════════════════╗ ║ THE CHANGE TRACKING CHALLENGE ║ ╚═════════════════════════════════════════════╝ BEFORE GIT (CHAOS) Week 1 Week 2 Week 3 │ │ │ ▼ ▼ ▼ Change Change Something Made Made Broke! │ │ │ └───────────┴───────────┘ │ ▼ ┌───────────────┐ │ Who did it? │ │ When? │ │ Why? │ │ How to undo? │ └───────────────┘ │ ▼ [ MYSTERY ] NEED: TRACKING SYSTEM Diagram 4: Git کے بغیر سافٹ ویئر کی ترقی (ویژن کنٹرول سسٹم) Diagram 4: Git کے بغیر سافٹ ویئر کی ترقی (ویژن کنٹرول سسٹم) ╔════════════════════════════════════════════════╗ ║ GIT: THE SOLUTION TO CHAOS ║ ╚════════════════════════════════════════════════╝ ┌─────────────┐ │ GIT │ │ REPOSITORY │ └──────┬──────┘ │ ┌──────────────┼──────────────┐ │ │ │ ▼ ▼ ▼ ┌───────────┐ ┌───────────┐ ┌───────────┐ │ Dev A │ │ Dev B │ │ Dev C │ │ Branch │ │ Branch │ │ Branch │ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘ │ │ │ │ ┌─────────┼─────────┐ │ │ │ │ │ │ └────┼─────────┴─────────┼────┘ │ │ ▼ ▼ [ MERGE ] [ TRACKED ] │ │ └─────────┬─────────┘ ▼ ┌───────────┐ │ NO CHAOS! │ └───────────┘ Diagram 5: Git کے ساتھ سافٹ ویئر کی ترقی (ویژن کنٹرول سسٹم) Diagram 5: Git کے ساتھ سافٹ ویئر کی ترقی (ویژن کنٹرول سسٹم) ╔═══════════════════════════════════════════════╗ ║ THE ROLLBACK SAFETY NET CONCEPT ║ ╚═══════════════════════════════════════════════╝ WITHOUT GIT Past ──────────────► Present │ ▼ ┌────────┐ │ BROKEN │ └────────┘ │ ▼ [ NO WAY BACK ] WITH GIT ┌────┐ ┌────┐ ┌────┐ ┌────┐ │ v1 │───►│ v2 │───►│ v3 │───►│ v4 │ └────┘ └────┘ └────┘ └────┘ ▲ │ │ │ │ SOMETHING BROKE │ │ ▼ │ │ ┌────────┐ │ │ │ROLLBACK│ │ └─────────┤ TO v1 │◄──────────┘ └────────┘ SAFETY GUARANTEED Diagram 6: Git میں رول بیک مفهوم Diagram 6: Git میں رول بیک مفهوم Manual deployment کے مسائل ایک بار جب کوڈ محفوظ طور پر Git میں ہے، آپ کو اب بھی اسے ایک سرور پر حاصل کرنے کی ضرورت ہے. پہلے، ابتدائی دنوں میں، کسی نے اس کوڈ کو دستی طور پر نکال دیا، ان کے اپنے کمپیوٹر پر کچھ ٹیسٹ چلائیں، اسے پیکیج کریں، اور پیداوار میں انسٹال کریں.یہ کام کرتا ہے اگر آپ کم سے کم انسٹال کرتے ہیں. غلطیوں کو بھولنا - ایک ٹیسٹ مرحلے کو بھولنے سے غلط ماحول میں تنصیب کرنے کے لئے. +===================================================+ | The Manual Bottleneck Effect | +===================================================+ LOW SCALE (1x/Month) -------------------- [Commit] ---> ( 👤 ) ---> [Deploy OK] (No pressure) HIGH SCALE (10x/Week) --------------------- [Commit] --\ [Commit] -- \ [Commit] --- > ( 👤 ) --- > [ERROR] [Commit] -- / (Pressure) [CONFLICT] [Commit] --/ (Overwhelmed) [FAILURE] CONCLUSION: A human 👤 cannot process high volume. SOLUTION: Need an automated CI/CD pipeline. ڈائریکٹر 7: دستی تعینات ڈائریکٹر 7: دستی تعینات تعمیر اور ٹیسٹ کے عمل کو خود کار طریقے سے ایک CI / CD پائپ لائن کوڈ لکھنے اور پیداوار میں اس کی تنصیب کے درمیان اقدامات خود کار طریقے سے کرتا ہے. جب کوڈ ذخائر میں دباؤ کیا جاتا ہے تو پائپ لائن اس کو ایک بنائی میں پیک کرتا ہے، پھر خود کار طریقے سے ٹیسٹ چلتا ہے - انفرادی افعال کی جانچ پڑتال کرنے کے لئے یونٹ ٹیسٹ، مختلف حصوں کو ایک دوسرے کے ساتھ کام کرنے کی ضمانت کرنے کے لئے انٹرویو ٹیسٹ، صارفین کی صحت کی جانچ پڑتال کرنے کے لئے صارفین کی صحت کی جانچ پڑتال کرتا ہے. یہ سب کسی کو ہر کام کو یاد کرنے کی ضرورت نہیں ہے، اور نئے خصوصیات کی ترقی پر زیادہ توجہ دی جا سکتی ہے. ╔═══════════════════════════════════════════════╗ ║ THE CI/CD PIPELINE ANATOMY ║ ╚═══════════════════════════════════════════════╝ ┌─────────────┐ │ CODE PUSHED │ │ TO REPO │ └──────┬──────┘ │ ▼ ╔══════════════════════╗ ║ CI/CD PIPELINE ║ ║ ║ ║ ┌────────────────┐ ║ ║ │ 1. PACKAGE │ ║ ║ │ (Build) │ ║ ║ └────────┬───────┘ ║ ║ │ ║ ║ ┌────────▼───────┐ ║ ║ │ 2. TEST │ ║ ║ │ - Unit │ ║ ║ │ - Integration│ ║ ║ │ - Security │ ║ ║ │ - Performance│ ║ ║ └────────┬───────┘ ║ ║ │ ║ ║ ┌────────▼───────┐ ║ ║ │ 3. DEPLOY │ ║ ║ │ Test/Dev Env │ ║ ║ └────────┬───────┘ ║ ║ │ ║ ║ ┌────────▼───────┐ ║ ║ │ 4. DEPLOY │ ║ ║ │ Production │ ║ ║ └────────────────┘ ║ ╚══════════════════════╝ گرافٹ 8: CI / CD پائپ لائن گرافٹ 8: CI / CD پائپ لائن ╔═════════════════════════════════════════════╗ ║ THE CI/CD AUTOMATION ENGINE ║ ╚═════════════════════════════════════════════╝ DEVELOPER CI/CD DOES ALL: │ │ ┌──────────┐ │ │ Package │ ▼ └────┬─────┘ ┌────────────┐ │ │ PUSH CODE │ │ └────────────┘ ▼ │ ┌──────────┐ │ │Unit Test │ │ └────┬─────┘ │ │ │ ▼ Developer's ┌──────────┐ Job Done! │Integrate │ │ │ Test │ │ └────┬─────┘ │ │ ▼ ▼ ┌────────────┐ ┌──────────┐ │ FOCUS ON │ │ Security │ │ NEXT │ │ Scan │ │ FEATURE │ └────┬─────┘ └────────────┘ │ ▼ ┌──────────┐ │Performnce│ │ Test │ └────┬─────┘ │ ▼ ┌──────────┐ │ Deploy │ └──────────┘ ڈائریکٹر 9: ڈویلپر کی کارکردگی میں بہتر ڈائریکٹر 9: ڈویلپر کی کارکردگی میں بہتر اگر سب کچھ بھاگتا ہے تو، بلڈنگ ایک ٹیسٹ یا ترقی کے ماحول میں جاتا ہے، جہاں نئے کوڈ کو پہلے سے ہی پیداوار میں کیا جاتا ہے کے ساتھ ساتھ تجربہ کیا جاتا ہے. جب چیزیں اچھی لگتی ہیں تو، یہ براہ راست اپ ڈیٹ کیا جاتا ہے. Jenkins، GitHub Actions، Azure DevOps، اور Harness مقبول CI / CD آلات کے کچھ مثالیں ہیں. ╔═══════════════════════════════════════════════╗ ║ THE ENVIRONMENT PROMOTION LADDER ║ ╚═══════════════════════════════════════════════╝ ┌──────────────┐ │ CODE PUSHED │ └──────┬───────┘ │ ▼ ┌──────────────┐ │ CI/CD RUNS │ │ TESTS │ └──────┬───────┘ │ TESTS PASS │ ▼ ╔════════════════════════╗ ║ TEST/DEV ENVIRON ║ ◄── Try Here First ║ ║ ║ New Code + Old Code ║ ║ Working Together? ║ ╚════════════╤═══════════╝ │ LOOKS GOOD │ ▼ ╔════════════════════════╗ ║ PRODUCTION ENVIRON ║ ◄── Deploy Live ║ ║ ║ Users Get Update ║ ╚════════════════════════╝ SAFE PROGRESSION TEST → PRODUCTION Diagram 10 : ٹیسٹ / ڈویو ماحول کی پیداوار کے ماحول Diagram 10 : ٹیسٹ / ڈویو ماحول کی پیداوار کے ماحول ماحولیاتی مطابقت کا مسئلہ یہاں تک آگے بڑھنے کے بعد، ہم قدرتی طور پر ایک اور پریشانی کا سامنا کریں گے: کبھی کبھی کوڈ ایک ڈویلپر کے لیپ ٹاپ پر کام کرتا ہے، لیکن پیداوار میں خرابی ہوتی ہے کیونکہ بنیادی ماحول مختلف ہیں. سافٹ ویئر کا ایک ٹکڑا اس کے آپریٹنگ سسٹم، لائبریریوں، یا مخصوص ورژن کی ذمہ داریوں کے ساتھ بات چیت کرتا ہے جو آسانی سے ایک مشین سے دوسرے میں تبدیل ہوسکتا ہے. ╔═══════════════════════════════════════════════╗ ║ "IT WORKS ON MY MACHINE" SYNDROME ║ ╚═══════════════════════════════════════════════╝ DEVELOPER'S LAPTOP PRODUCTION SERVER ┌──────────┐ ┌──────────┐ │ CODE │ │ CODE │ └────┬─────┘ └────┬─────┘ │ │ ▼ ▼ ┌──────────┐ ┌──────────┐ │ Python │ │ Python │ │ 3.9 │ │ 3.7 │ └────┬─────┘ └────┬─────┘ │ │ ▼ ▼ ┌──────────┐ ┌──────────┐ │ Library │ │ Library │ │ v2.0 │ │ v1.5 │ └────┬─────┘ └────┬─────┘ │ │ ▼ ▼ ┌──────────┐ ┌──────────┐ │ OS │ │ OS │ │ Ubuntu22 │ │ Ubuntu20 │ └────┬─────┘ └────┬─────┘ │ │ ▼ ▼ [ ✓ WORKS ] [ ✗ CRASHES ] THE ENVIRONMENT MISMATCH PROBLEM ڈائریکٹر 11: ماحول کی خلاف ورزی کا مسئلہ ڈائریکٹر 11: ماحول کی خلاف ورزی کا مسئلہ ╔═══════════════════════════════════════════════╗ ║ THE ISOLATION LAYER VISUALIZATION ║ ╚═══════════════════════════════════════════════╝ WITHOUT CONTAINERS ┌───────────────────────────┐ │ Operating System │ │ │ │ App1 App2 App3 App4 │ │ │ │ │ │ │ │ └─────┴─────┴─────┘ │ │ │ │ │ Shared Resources │ │ (Conflicts!) │ └───────────────────────────┘ WITH CONTAINERS ┌───────────────────────────┐ │ Operating System │ ├───────────────────────────┤ │ ╔═══╗ ╔═══╗ ╔═══╗ ╔═══╗ │ │ ║App║ ║App║ ║App║ ║App║ │ │ ║ 1 ║ ║ 2 ║ ║ 3 ║ ║ 4 ║ │ │ ╚═══╝ ╚═══╝ ╚═══╝ ╚═══╝ │ │ │ │ Each Isolated & Protected │ └───────────────────────────┘ ڈائریکٹر 12 : انفرادیت کے فوائد ڈائریکٹر 12 : انفرادیت کے فوائد ایک کنٹینر ایک چھوٹی سی پیکیج کی طرح کام کرتا ہے: یہ ایک ایپلی کیشن کی ضروریات - اس کے کوڈ، چلانے کے وقت، سسٹم آلات، لائبریریز - کو پکڑتا ہے، لہذا یہ ایک ہی طریقے سے چل سکتا ہے جہاں بھی اس کو اپ ڈیٹ کیا جاتا ہے. کنٹینرز اس ایپلی کیشن کو بنیادی ماحول سے جدا کرتے ہیں، "یہ میرے مشین پر کام کرتا ہے" ایک ماضی کی چیز بناتا ہے. مختلف کنٹینر ٹیکنالوجیوں میں سے، Docker سب سے زیادہ مقبول ہے. Docker کنٹینرز کی تخلیق، تنصیب، ٹیسٹ اور انتظام کو آسان بناتا ہے. اس کے نتیجے میں، آپ کے ایپ ہر جگہ ایک ہی چلتا ہے - مقامی مشینوں سے پیداوار سرورز تک. ╔══════════════════════════════════════════════╗ ║ THE DEPENDENCY ISOLATION SHIELD ║ ╚══════════════════════════════════════════════╝ HOST MACHINE (ANY OS) ┌────────────────────────────────────┐ │ │ │ ╔═══════════════════════════════╗ │ │ ║ CONTAINER SHIELD ║ │ │ ║ ║ │ │ ║ ┌─────────────────────────┐ ║ │ │ ║ │ YOUR APPLICATION │ ║ │ │ ║ │ │ ║ │ │ ║ │ • Code │ ║ │ │ ║ │ • Runtime │ ║ │ │ ║ │ • System Tools │ ║ │ │ ║ │ • Libraries │ ║ │ │ ║ │ • Dependencies │ ║ │ │ ║ │ │ ║ │ │ ║ └─────────────────────────┘ ║ │ │ ║ ║ │ │ ║ ISOLATED FROM HOST ║ │ │ ╚═══════════════════════════════╝ │ │ │ │ Host Changes Don't Affect App! │ └────────────────────────────────────┘ مرحلہ 13: کنٹینر ڈیزائن مرحلہ 13: کنٹینر ڈیزائن ╔═══════════════════════════════════════════════╗ ║ FROM LOCAL DEVELOPMENT TO PRODUCTION ║ ╚═══════════════════════════════════════════════╝ SINGLE CONTAINER ╔═════════════╗ ║ Docker ║ ║ Container ║ ╚══════╤══════╝ │ │ DEPLOY JOURNEY │ │ ┌────────────┼────────────┐ │ │ │ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ LOCAL │ │ STAGING │ │ PROD │ │ DEV │ │ SERVER │ │ SERVER │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ ▼ ▼ ▼ [IDENTICAL] [IDENTICAL] [IDENTICAL] NO CONFIGURATION DRIFT! NO ENVIRONMENT SURPRISES! PREDICTABLE DEPLOYMENTS! Diagram 14 : Docker کنٹینر میں ایپز تمام ماحولوں میں اسی طرح کام کرتے ہیں Diagram 14 : Docker کنٹینر میں ایپز تمام ماحولوں میں اسی طرح کام کرتے ہیں آرکسٹریشن کا چیلنج Docker ایپ کو باقاعدگی سے پیک کرنے کے لئے بہترین ہے، لیکن جب آپ کو ویب سرورز، ڈیٹا بیس، کیچز، اور مائیکرو سروسز کے طور پر چیزوں کے لئے پیداوار میں بہت سے کنٹینر ہیں تو، دستی مینجمنٹ پیچھے نہیں جا سکتا. ╔═════════════════════════════════════════════╗ ║ THE ORCHESTRATION REQUIREMENT ║ ╚═════════════════════════════════════════════╝ PRODUCTION REALITY Web Server Database Cache APIs Containers Containers Containers Containers │ │ │ │ ▼ ▼ ▼ ▼ ┌────┐┌────┐ ┌────┐┌────┐ ┌────┐ ┌────┐ │ W1 ││ W2 │ │ D1 ││ D2 │ │ C1 │ │ A1 │ └────┘└────┘ └────┘└────┘ └────┘ └────┘ ┌────┐┌────┐ ┌────┐ │ W3 ││ W4 │ │ A2 │ └────┘└────┘ └────┘ MANUAL QUESTIONS: • Which container crashed? • How to reroute traffic? • When to scale up/down? • How to connect them? ▼ NEED ORCHESTRATOR ▼ KUBERNETES! Diagram 15: کنٹینر آرکسٹریشن کی ضرورت Diagram 15: کنٹینر آرکسٹریشن کی ضرورت Kubernetes Docker کے اوپر ایک آرکسٹریشن کی سطح ہے. یہ خود کار طریقے سے کنٹینرز کا انتظام کرتا ہے - ناکام کنٹینرز کو دوبارہ شروع کرنا، اضافہ یا کم کرنا، ٹریفک کی توازن، اور کنٹینرز کو ایک دوسرے سے منسلک کرنا. ╔═════════════════════════════════════════════╗ ║ THE AUTOMATIC MANAGEMENT LOOP ║ ╚═════════════════════════════════════════════╝ ╔═══════════════════════╗ ║ KUBERNETES ║ ║ CONTROL PLANE ║ ╚═════════╤═════════════╝ │ Constantly Monitors │ ┌─────────────┼─────────────┐ │ │ │ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │Container │ │Container │ │Container │ │ A │ │ B │ │ C │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ └─────────────┼─────────────┘ │ Reports Status │ ▼ ╔═══════════════════╗ ║ AUTO ACTIONS: ║ ║ • Restart ║ ║ • Scale ║ ║ • Balance ║ ║ • Link ║ ╚═══════════════════╝ CONTINUOUS AUTOMATION فہرست 16: خودکار انتظام فہرست 16: خودکار انتظام ╔══════════════════════════════════════════════╗ ║ THE FAILED CONTAINER AUTO-RECOVERY ║ ╚══════════════════════════════════════════════╝ TIME LINE t=0 t=1 t=2 t=3 │ │ │ │ ▼ ▼ ▼ ▼ ┌────────┐ ┌────────┐ ┌────────┐ ┌─────────┐ │Running │ │Crashed!│ │Detected│ │Restarted│ └────────┘ └───╳────┘ └────────┘ └─────────┘ │ │ │ │ ▼ │ │ ╔═══════════════╗ │ │ ║ KUBERNETES ║ │ └───►║ Monitors ║ │ ║ & Acts ║───┘ ╚═══════════════╝ AUTOMATIC HEALING NO MANUAL INTERVENTION خطوط 17: خود کار طریقے سے خطوط 17: خود کار طریقے سے ╔═══════════════════════════════════════════════╗ ║ THE SCALING AUTOMATION ENGINE ║ ╚═══════════════════════════════════════════════╝ ╔═══════════════════════╗ ║ KUBERNETES ║ ║ Watches Metrics ║ ╚═══════╤═══════════════╝ │ ┌───────────┴───────────┐ │ │ LOW DEMAND HIGH DEMAND │ │ ▼ ▼ ┌──────────┐ ┌──────────┐ │ Scale │ │ Scale │ │ DOWN │ │ UP │ └────┬─────┘ └────┬─────┘ │ │ ▼ ▼ ┌────┐ ┌────┐┌────┐ │ C1 │ │ C1 ││ C2 │ └────┘ └────┘└────┘ ┌────┐┌────┐ 1 Container │ C3 ││ C4 │ Enough └────┘└────┘ 4 Containers Needed ELASTIC SCALING مرحلہ 18: لچکدار سکرین مرحلہ 18: لچکدار سکرین ╔═════════════════════════════════════════════╗ ║ THE TRAFFIC BALANCING MECHANISM ║ ╚═════════════════════════════════════════════╝ USER TRAFFIC │ │ ▼ ╔═══════════════╗ ║ KUBERNETES ║ ║ LOAD ║ ║ BALANCER ║ ╚═══════╤═══════╝ │ ┌───────────┼───────────┐ │ │ │ 33%│ 33%│ 33%│ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │Container │ │Container │ │Container │ │ 1 │ │ 2 │ │ 3 │ └──────────┘ └──────────┘ └──────────┘ EVEN DISTRIBUTION OPTIMIZED ROUTING NO OVERLOAD مرحلہ 19: وزن کی توازن مرحلہ 19: وزن کی توازن ╔══════════════════════════════════════════════╗ ║ THE CONTAINER LINKING SYSTEM ║ ╚══════════════════════════════════════════════╝ ╔═══════════════════════╗ ║ KUBERNETES ║ ║ Service Mesh ║ ╚═══════╤═══════════════╝ │ Auto-Links │ ┌───────────┼───────────┐ │ │ │ ▼ ▼ ▼ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ WEB │◄─┤ API │◄─┤DATABASE │ │ SERVER │ │ SERVICE │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ │ └───────────┼───────────┘ │ ┌─────▼─────┐ │ CACHE │ └───────────┘ AUTOMATIC SERVICE DISCOVERY DYNAMIC CONNECTIONS فہرست 20: کنٹینر کا لنک فہرست 20: کنٹینر کا لنک ╔═════════════════════════════════════════════╗ ║ THE DIVISION OF RESPONSIBILITIES ║ ╚═════════════════════════════════════════════╝ DOCKER'S JOB KUBERNETES' JOB ┌─────────────┐ ┌─────────────┐ │ CREATE │ │ DEPLOY │ │ Containers │ │ Where? │ └──────┬──────┘ └──────┬──────┘ │ │ ▼ ▼ ┌─────────────┐ ┌─────────────┐ │ PACKAGE │ │ MONITOR │ │ Application │ │ Health │ └──────┬──────┘ └──────┬──────┘ │ │ ▼ ▼ ┌─────────────┐ ┌─────────────┐ │ RUN │ │ SCALE │ │ Containers │ │ Count │ └─────────────┘ └──────┬──────┘ │ ▼ ┌─────────────┐ │ MANAGE │ │ Lifecycle │ └─────────────┘ CONTAINERIZATION ORCHESTRATION ڈائریکٹر 21: مشترکہ ذمہ داری کے ماڈل ڈائریکٹر 21: مشترکہ ذمہ داری کے ماڈل پیداوار میں کیا ہوتا ہے دیکھیں اپلی کیشن کے بعد کام مکمل نہیں کیا جاتا ہے. یہ دیکھنے کے لئے ضروری ہے کہ اپلی کیشن اصل میں پیداوار میں کس طرح چلتا ہے. کیا غلطیوں میں اضافہ ہو رہا ہے؟ کیا اپلی کیشن طویل ہے؟ نگرانی کے آلات CPU استعمال، میموری استعمال، ردعمل کے اوقات، اور غلطی کی شرح جیسے میٹرک کو ٹریک کرتے ہیں. لاگ ان جو اپلی کیشن کر رہا ہے اور غلطیوں کو پکڑتا ہے. جب کچھ غلط ہو جاتا ہے، یہ انٹرفیس آپ کو فوری طور پر تلاش اور آخر صارفین کو اطلاع دینے سے پہلے مسائل کو حل کرنے میں مدد ملتی ہے. ╔═══════════════════════════════════════════════╗ ║ THE COMPLETE OBSERVABILITY STACK ║ ╚═══════════════════════════════════════════════╝ ┌─────────────────┐ │ APPLICATION │ │ IN PRODUCTION │ └────────┬────────┘ │ ┌────────────┼────────────┐ │ │ │ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │MONITORING│ │ LOGGING │ │ INCIDENT │ │ │ │ │ │ RESPONSE │ │Tracks │ │Captures │ │ │ │Metrics │ │Events │ │Fixes │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ └────────────┼────────────┘ │ ▼ ╔═══════════════╗ ║ COMPLETE ║ ║ VISIBILITY ║ ║ ║ ║ Know What's ║ ║ Happening ║ ║ Always ║ ╚═══════════════╝ ڈرائنگ 22: نگرانی، لوڈنگ، اور واقعات کے جواب ڈرائنگ 22: نگرانی، لوڈنگ، اور واقعات کے جواب ╔══════════════════════════════════════════════╗ ║ DETECTING ISSUES BEFORE USERS ║ ╚══════════════════════════════════════════════╝ WITHOUT MONITORING Error Occurs ──► User Complains ──► Fix │ │ └───────────────────┘ Hours/Days Later! WITH MONITORING Error Occurs │ ▼ ╔═════════════╗ ║ MONITORING ║ ║ Detects ║ ──► Alerts Team ║ Instantly ║ ╚═════╤═══════╝ │ ▼ Team Fixes Issue │ ▼ Users Never Know! PROACTIVE > REACTIVE فہرست 23: فعال ردعمل فہرست 23: فعال ردعمل کیا ایک کو یاد رکھنے کی ضرورت ہے جو بھی DevOps میں مزید مہارت حاصل کرنا چاہتا ہے وہ مختلف قسم کے خودکار ٹیسٹ کو سمجھنے پر بھی توجہ مرکوز کرنا چاہئے جو لکھا جاتا ہے. ╔══════════════════════════════════════════════╗ ║ THINKING THROUGH USE & MISUSE ║ ╚══════════════════════════════════════════════╝ ┌─────────────────┐ │ FEATURE TO │ │ BE TESTED │ └────────┬────────┘ │ Think About: │ ┌────────────┴────────────┐ │ │ ▼ ▼ ┌───────────┐ ┌───────────┐ │ NORMAL │ │ ABNORMAL │ │ USE │ │ USE │ │ │ │ │ │• Expected │ │• Wrong │ │ Inputs │ │ Inputs │ │• Happy │ │• Edge │ │ Path │ │ Cases │ │• Valid │ │• Malicious│ │ Flow │ │ Intent │ └─────┬─────┘ └─────┬─────┘ │ │ └────────────┬────────────┘ │ ▼ [ COMPREHENSIVE TEST COVERAGE ] مرحلہ 24: ٹیسٹ کے بارے میں سوچیں مرحلہ 24: ٹیسٹ کے بارے میں سوچیں پروگرامنگ زبان کی مہارت، API واقفیت، ڈومین کے علم، اور ٹیسٹنگ فریم ورک کے واقفیت سب میں مدد ملتی ہے. یہاں کے اختیارات آپ کے ڈیو اوپس ایکو سسٹم کے باقی کے ساتھ کام کرنا چاہئے - کلاؤڈ سپلائر، سی آئی / سی ڈی ٹول، آٹومیشن پلیٹ فارم. مثال کے طور پر، Jenkins (ایک سی آئی / سی ڈی ٹول) مختلف زبانوں، پائٹون سمیت اور فریم ورک جیسے pytest کے ساتھ انٹرویو کرتا ہے، لہذا یہ جاننا ضروری ہے کہ کونسی آلات اچھی طرح کام کرتے ہیں. ╔═════════════════════════════════════════════╗ ║ THE DEVOPS ECOSYSTEM COMPATIBILITY ║ ╚═════════════════════════════════════════════╝ ┌─────────────────┐ │ TEST CHOICE │ └────────┬────────┘ │ Must Work With: │ ┌────────────┼────────────┐ │ │ │ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ Cloud │ │ CI/CD │ │Automation│ │ Provider │ │ Tool │ │ Platform │ │ │ │ │ │ │ │AWS/Azure │ │ Jenkins │ │ Etc. │ │ /GCP │ │ GitHub │ │ │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ └────────────┼────────────┘ │ ▼ ╔═══════════════╗ ║ INTEGRATION ║ ║ IS CRITICAL ║ ╚═══════════════╝ ڈائریکٹر 25: ماحولیاتی نظام کی مطابقت ڈائریکٹر 25: ماحولیاتی نظام کی مطابقت اٹھا کر یہ DevOps کے معنی بنانے کے لئے ایک آغاز نقطہ ہے، کوڈ اور تعاون سے آٹومیشن اور انشورنس سے نگرانی اور تبصرہ کرنے کے لئے اقدامات کو منسلک کرنے کے لئے. ہر سطح ایک مسئلہ کو حل کرنے کے لئے ظاہر ہوتا ہے جو پہلے سے ہی حل نہیں کیا جا سکتا تھا. جیسا کہ یہ منظر جاری ہے، ان اہم انتقالوں کو دیکھنے میں مدد ملتی ہے جو پیچیدہ ڈپازٹ کو کچھ ایسی چیز میں تبدیل کرنے میں مدد ملتی ہے جو واقعی کام کرتا ہے. +------------------+ | Source Control | +------------------+ | +------------------+ | CI/CD | +------------------+ | +------------------+ | Containers | +------------------+ | +------------------+ | Orchestration | +------------------+ | +------------------+ | Monitoring | +------------------+ صفحہ 26: خلاصہ صفحہ 26: خلاصہ سب سے زیادہ، DevOps یہ سمجھنے کے بارے میں ہے کہ کس طرح ٹکڑے ایک دوسرے کے ساتھ ملتے ہیں اور کیوں ہر ایک کی ضرورت ہوتی ہے، بلکہ صرف منفرد طور پر آلات سیکھنے کے لئے. اگر آپ کو کوئی سوال ہے تو، براہ مہربانی مجھے ایک ای میل بھیجنے کے لئے آزاد محسوس کریں. آپ بھی LinkedIn کے ذریعے مجھ سے رابطہ کر سکتے ہیں. ای میل ای میل لنکنگ لنکنگ . X X آپ میری پوسٹ پڑھ سکتے ہیں system design . یہاں یہاں اگر آپ مجھے کسی دوسرے موضوع پر لکھنا چاہتے ہیں تو، براہ مہربانی مجھے تبصرے میں بتائیں. میرے لیے لنک . ہیکر پروفائل