آپ کنٹینر کے وسائل (CPU اور میموری) کو کیسے منظم کرتے ہیں؟

Question

Accepted Answer

ڈिفالٹ طور پر، کنٹینرز **لامحدود host وسائل** استعمال کر سکتے ہیں — جو ایک کنٹینر کو دوسری کنٹینرز کو محروم کرنے یا host کو کریش کرنے کا خطرہ ڈالتا ہے۔ Docker آپ کو **وسائل کی حدود** (CPU، میموری) سیٹ کرنے دیتا ہے تاکہ استعمال کو کنٹرول کیا جا سکے، جو پروڈکشن میں استحکام اور منصفانہ وسائل کے اشتراک کے لیے اہم ہے۔

## مسئلہ: غیر محدود وسائل کا استعمال

```text
BY DEFAULT a container can consume ALL available host CPU and memory:
  → a buggy/busy container (memory leak, runaway loop) can starve other containers
    or crash the entire host (out of memory)
→ In production (multiple containers per host), LIMIT resources to isolate them.
```

## میموری اور CPU حدود سیٹ کریں

```bash
# memory limits
docker run -m 512m myapp              # hard limit: 512 MB (container killed if exceeded — OOM)
docker run -m 512m --memory-reservation 256m myapp   # soft limit + hard limit

# CPU limits
docker run --cpus="1.5" myapp         # limit to 1.5 CPU cores
docker run --cpu-shares=512 myapp     # relative weight (priority under contention)
```

```yaml
# in docker-compose.yml (or for orchestrators)
services:
  app:
    deploy:
      resources:
        limits:    { cpus: '1.5', memory: 512M }   # maximum
        reservations: { cpus: '0.5', memory: 256M } # guaranteed minimum
```

میموری کی حدود (`-m`) استعمال کو محدود کرتی ہے (اگر کنٹینر سخت حد سے تجاوز کرے تو **OOM-killed** ہوتا ہے)؛ CPU حدود (`--cpus`) CPU کے استعمال کو محدود کرتی ہے۔ **Reservations** کم سے کم کو یقینی بناتے ہیں۔

## نگرانی اور ٹیونیং

```text
✓ docker stats → live CPU/memory usage per container (to right-size limits)
✓ Set limits based on the app's actual needs (measure, then add headroom)
✓ OOMKilled (in docker inspect) → the container hit its memory limit → raise it or fix a leak
✓ Orchestrators (Kubernetes) use requests/limits similarly — essential for scheduling
```

## یہ اہم کیوں ہے

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

بنیادی مسئلہ — ڈیفالٹ طور پر، **کنٹینرز تمام دستیاب host وسائل کو استعمال کر سکتے ہیں** — ایک حقیقی خطرہ ہے: ایک خرابی والا یا مصروف کنٹینر (میموری leak یا runaway process کے ساتھ) دوسری کنٹینرز کو **محروم کر سکتا ہے یا پوری host کو کریش کر سکتا ہے** (میموری سے باہر)، host کو غیر مستحکم بناتا ہے۔

**وسائل کی حدود** (میموری اور CPU) سیٹ کرنا اس سے بچاتا ہے **کنٹینرز کی وسائل کی کھپت کو الگ تھلگ کر کے**، یقینی بناتے ہوئے کہ ایک کنٹینر دوسری کنٹینرز یا host کو نیچے نہیں لا سکتا — جب ایک host پر متعدد کنٹینرز چلائے جا رہے ہوں (پروڈکشن میں معمول)۔

**میموری حدود** سیٹ کرنا سمجھنا (کنٹینر کے ہارڈ لمٹ سے تجاوز کرنے پر OOM-killed ہونے کے ساتھ) اور **CPU حدود**، ساتھ ہی **reservations** (کم سے کم کی ضمانت)، وسائل کو کنٹرول کرنے اور منصفانہ طریقے سے بانٹنے کے لیے عملی طریقہ کار ہے۔

**نگرانی اور ٹیونیں** کرنا جاننا — `docker stats` استعمال کرتے ہوئے اصل استعمال کا مشاہدہ کریں اور حدود کو صحیح سائز میں رکھیں، `OOMKilled` (کنٹینر اپنی میموری لمٹ تک پہنچنا) کو کنٹینر کریش کی تشخیص کے لیے شناخت کریں — حقیقی ضروریات کی بنیاد پر مناسب حدود مقرر کرنے کے لیے اہم ہے۔

یہ آرکسٹریشن سے بھی منسلک ہے: **Kubernetes بھی اسی طرح کے وسائل کی درخواست/حدود استعمال کرتا ہے** جو شیڈیولنگ اور استحکام کے لیے لازمی ہیں، اس لیے تصور کو سمجھنا آرکسٹریٹ شدہ ماحول میں منتقل ہوتا ہے۔

چونکہ متعدد کنٹینرز کو قابل اعتماد طریقے سے چلانے کے لیے وسائل کے تنازع اور runaway کھپت کو روکنے کی ضرورت ہے، اور چونکہ وسائل کی حدود (میموری اور CPU سیپس، reservations، نگرانی) کنٹینرز کو الگ تھلگ کرنے اور host کے استحکام کو محفوظ رکھنے کا طریقہ ہیں، کنٹینر وسائل کا انتظام سمجھنا پروڈکشن کنٹینر ڈیپلائے کے لیے قیمتی، عملی اہم علم ہے — مستحکم multi-کنٹینر hosts کے لیے ضروری اور ایک تصور جو براہ راست Kubernetes جیسے آرکسٹریٹ شدہ ماحول تک پھیلا ہوا ہے، جہاں وسائل کی تفصیل بنیادی ہے۔