Docker نیٹ ورکس گہرائی میں کیسے کام کرتے ہیں؟

Question

Accepted Answer

Docker کئی **نیٹ ورک ڈرائیورز** فراہم کرتا ہے (bridge، host، overlay، macvlan، none) مختلف کنیکٹیویٹی کی ضروریات کے لیے، اور **صارف کی طرف سے متعرفہ نیٹ ورکس** جیسی خصوصیات DNS-پر مبنی سروس ڈسکوری کے ساتھ۔ نیٹ ورکنگ کو گہرائی سے سمجھنا ملٹی-کنٹینر اور ملٹی-ہوسٹ ایپلیکیشنز کو صحیح طریقے سے جوڑنے کے لیے اہم ہے۔

## نیٹ ورک ڈرائیورز

```text
BRIDGE (default) → a private internal network on a single host; containers communicate;
  isolated from the host except via published ports. USER-DEFINED bridges add DNS
  (containers reach each other by name) — preferred over the default bridge.
HOST → the container uses the host's network stack directly (no isolation, no port
  mapping needed) — max performance, less isolation.
OVERLAY → spans MULTIPLE hosts → containers on different machines communicate
  (for Docker Swarm / multi-host clusters).
MACVLAN → gives a container its own MAC/IP on the physical network (appears as a
  physical device).
NONE → no networking (fully isolated).
```

## صارف کی طرف سے متعرفہ نیٹ ورکس اور سروس ڈسکوری

```bash
docker network create app-net
docker run -d --name db --network app-net postgres
docker run -d --name api --network app-net myapi
# → on a user-defined network, Docker's embedded DNS resolves container NAMES
#   the "api" reaches the database at hostname "db" → automatic service discovery
```

صارف کی طرف سے متعرفہ نیٹ ورکس **خودکار DNS-پر مبنی سروس ڈسکوری** فراہم کرتے ہیں (کنٹینرز ایک دوسرے تک نام سے رسائی حاصل کرتے ہیں) اور ڈیفالٹ bridge کے مقابلے بہتر علیحدگی — ملٹی-کنٹینر ایپلیکیشنز کے لیے تجویز کردہ نقطہ نظر۔

## نیٹ ورک علیحدگی اور تقسیم

```text
→ Containers can be placed on DIFFERENT networks to isolate them (segmentation):
  e.g. a frontend network and a backend network; only certain containers bridge both
→ Improves security (a container only reaches what it's networked with)
→ Published ports (-p) are the controlled boundary to the outside world
```

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

Docker نیٹ ورکنگ کو گہرائی سے سمجھنا **ملٹی-کنٹینر اور ملٹی-ہوسٹ ایپلیکیشنز کو صحیح طریقے سے اور محفوظ طریقے سے جوڑنے** کے لیے اہم ہے، اس لیے یہ بنیادی اصول سے پرے قیمتی عملی علم ہے۔

**نیٹ ورک ڈرائیورز** اور ان کے مقاصد جاننا — **bridge** (ایک-ہوسٹ کنٹینر کمیونیکیشن، صارف کی طرف سے متعرفہ bridges کو ترجیح دیتے ہوئے)، **host** (کارکردگی کے لیے براہ راست ہوسٹ نیٹ ورک استعمال کرتے ہوئے، علیحدگی کو قربان کرتے ہوئے)، **overlay** (متعدد ہوسٹس میں پھیلاتے ہوئے، کلسٹر/Swarm ڈپلائمنٹس کے لیے ضروری جہاں مختلف مشینوں پر کنٹینرز کو بات چیت کرنی چاہیے)، **macvlan** (کنٹینرز کو فزیکل-نیٹ ورک شناخت دیتے ہوئے)، اور **none** (مکمل علیحدگی) — آپ کو ہر منظر نامے کے لیے صحیح نیٹ ورکنگ منتخب کرنے دیتا ہے، سنگل-ہوسٹ ایپلیکیشنز سے ملٹی-ہوسٹ کلسٹرز تک۔

**صارف کی طرف سے متعرفہ نیٹ ورکس کو DNS-پر مبنی سروس ڈسکوری کے ساتھ** سمجھنا (کنٹینرز خودکار طور پر Docker کے embedded DNS کے ذریعے نام سے ایک دوسرے تک رسائی حاصل کرتے ہیں) خاص طور پر اہم ہے، کیونکہ یہ ملٹی-کنٹینر ایپلیکیشنز کے لیے تجویز کردہ نقطہ نظر ہے — نام سے صاف سروس-سے-سروس کمیونیکیشن فعال کرتے ہوئے IP کو منظم کیے بغیر، اور ڈیفالٹ bridge سے بہتر علیحدگی فراہم کرتے ہوئے۔

**نیٹ ورک علیحدگی اور تقسیم** کے بارے میں جاننا (کنٹینرز کو مختلف نیٹ ورکس پر رکھ کر کنٹرول کریں کہ کیا بات کر سکتا ہے، مثال کے طور پر frontend اور backend نیٹ ورکس کو الگ کرتے ہوئے، شائع کیے ہوئے ports کے ساتھ کنٹرول شدہ بیرونی حد) **سیکیورٹی** کے لیے قیمتی ہے — ایک کنٹینر کی رسائی کو محدود کرنا حملہ کی سطح کو کم کرتا ہے۔

چونکہ حقیقی ایپلیکیشنز میں متعدد بات چیت کنے والے کنٹینرز شامل ہوتے ہیں (اور کبھی کبھی متعدد ہوسٹس میں پھیلے ہوتے ہیں)، اور چونکہ درست، محفوظ نیٹ ورکنگ (ڈرائیورز کا انتخاب، سروس ڈسکوری کا استعمال، سیکیورٹی کے لیے نیٹ ورکس کو الگ کرنا) انہیں صحیح طریقے سے جوڑنے کے لیے ضروری ہے، Docker نیٹ ورکنگ کو گہرائی سے سمجھنا — ڈرائیورز، DNS سروس ڈسکوری کے ساتھ صارف کی طرف سے متعرفہ نیٹ ورکس، اور سیکیورٹی کے لیے نیٹ ورک تقسیم — حقیقی containerized ایپلیکیشنز بنانے کے لیے قیمتی، عملی طور پر متعلقہ علم ہے، ملٹی-کنٹینر اور distributed ڈپلائمنٹس میں فعالیت (کنیکٹیویٹی) اور سیکیورٹی (علیحدگی) دونوں کے لیے اہم۔