VPS پر Docker چلانے کے اہم مسائل اور ان کا حل

VPS پر Docker چلانے سے کیا تبدیل ہوتا ہے

VPS پر Docker وہی انجن اور وہی images استعمال کرتا ہے جو آپ کے لیپ ٹاپ پر چلتی ہیں، اس لیے آپ کے معلوم تمام commands ویسے ہی کام کرتی ہیں۔ تبدیلی اس کے گرد موجود ماحول میں آتی ہے۔ لیپ ٹاپ میں فالتو memory ہوتی ہے، ایک ایسا firewall جسے کوئی scan نہیں کر رہا ہوتا، اور اتنی بڑی disk کہ آپ کو کبھی اس کی فکر نہیں کرنی پڑتی۔ کرائے کے سرور میں memory کی ایک مقررہ حد ہوتی ہے، ایک public IP address جسے boot ہونے کے چند منٹ بعد ہی scan کیا جانے لگتا ہے، اور ایک root filesystem جسے Docker بغیر پوچھے بھر دیتا ہے۔

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

• Memory محدود ہوتی ہے، اور kernel کمی ہونے پر کسی process کو kill کر کے اسے حل کرتا ہے۔
• ایک published port براہ راست UFW (uncomplicated firewall) سے گزر جاتی ہے، کیونکہ Docker اپنے firewall rules خود لکھتا ہے۔
• Containers reboot کے بعد خود بخود واپس نہیں آتے جب تک کہ آپ نے پہلے سے اس کی ہدایت نہ دی ہو۔
• Images، containers، volumes اور build cache تب تک بڑھتے رہتے ہیں جب تک disk مکمل بھر نہ جائے۔

نیچے دیا گیا ہر سیکشن خرابی، وہ string جو آپ کو درحقیقت نظر آئے گی، اور اس گائیڈ کی نشاندہی کرتا ہے جو اسے تفصیل سے ٹھیک کرتی ہے۔ اگر آپ نے ابھی تک compose file نہیں لکھی ہے، تو پہلے VPS پر Docker Compose کی بنیادی باتیں پڑھیں اور پھر واپس آئیں۔ یہ صفحہ فرض کرتا ہے کہ آپ پہلے ہی ایک stack کو چلانے کی صلاحیت رکھتے ہیں۔

Docker container کتنی RAM استعمال کرتا ہے؟

زیادہ تر لوگوں کی توقع سے بہت کم۔ Container دراصل ایک cgroup (control group) میں چلنے والا process ہے، نہ کہ virtual machine، اس لیے اس میں کوئی guest kernel یا مخصوص allocation نہیں ہوتی۔ اس کی قیمت وہی ہے جو اس کے اندر چلنے والا process استعمال کرتا ہے۔ یہی وجہ ہے کہ ایک مکمل stack 2 GB میں سما جاتا ہے، جبکہ virtual machines سے بنا وہی stack اتنی جگہ میں نہیں سما سکتا۔

نیچے دی گئی تعداد Ubuntu 24.04 پر stock images کے لیے idle حالت میں عام اعداد و شمار ہیں، جنہیں شروع ہونے کے چند منٹ بعد docker stats سے پڑھا گیا ہے۔ یہ منصوبہ بندی کے لیے ایک ابتدائی نقطہ ہیں، نہ کہ آپ کے workload کا benchmark۔ کسی بھی عدد پر بھروسہ کرنے سے پہلے، بشمول ان کے، اپنے سسٹم پر docker stats --no-stream چلائیں۔

[
  {
    "label": "nginx",
    "idle_mb": 8,
    "budget_mb": 64
  },
  {
    "label": "Redis 7",
    "idle_mb": 12,
    "budget_mb": 128
  },
  {
    "label": "Traefik v3",
    "idle_mb": 40,
    "budget_mb": 128
  },
  {
    "label": "PostgreSQL 16",
    "idle_mb": 45,
    "budget_mb": 512
  },
  {
    "label": "Uptime Kuma",
    "idle_mb": 95,
    "budget_mb": 256
  },
  {
    "label": "MariaDB 11",
    "idle_mb": 190,
    "budget_mb": 512
  },
  {
    "label": "Nextcloud (Apache)",
    "idle_mb": 210,
    "budget_mb": 768
  }
]

یہ دو کالم مختلف کام کرتے ہیں۔ idle_mb وہ ہے جو container کچھ نہ کرتے ہوئے استعمال کرتا ہے۔ budget_mb وہ ہے جسے آپ منصوبہ بندی کے وقت reserve کریں، کیونکہ حقیقی استعمال idle نہیں ہوتا۔ PostgreSQL تقریباً 45 MB پر idle رہتا ہے اور جب connections، sorts اور cache فعال ہو جائیں تو اسے 512 MB درکار ہوتے ہیں۔ منصوبہ بندی budget کالم کے ساتھ کریں۔ Debugging idle کالم کے ساتھ کریں۔

ان 7 قطاروں کی ساخت پر غور کریں۔ nginx 8 MB پر اور Nextcloud 210 MB پر idle رہتا ہے۔ آپ کی ایپلی کیشنز کے سامنے موجود proxy تقریباً مفت ہے۔ آپ سرور کا سائز database اور PHP ایپلی کیشن کی بنیاد پر طے کرتے ہیں۔

docker stats کے بارے میں ایک انتباہ: میموری کے اعداد و شمار میں وہ page cache شامل ہے جو container کی اپنی فائل ریڈز نے حاصل کیا ہے، اس لیے یہ شروع ہونے کے بعد کچھ دیر تک بڑھتا ہے اور پھر مستحکم ہو جاتا ہے۔ کسی بھی چیز کو leaking قرار دینے سے پہلے اسے ایک گھنٹے تک مانیٹر کریں۔

VPS کا سائز طے کرنا: 2 GB، 4 GB اور 8 GB میں کیا سما سکتا ہے

سب سے پہلے host کا حصہ نکال دیں۔ Kernel، systemd، journald، sshd اور Docker daemon اسی RAM میں رہتے ہیں جس میں آپ کے containers، اور dockerd بمعہ containerd اس کا تقریباً 100 MB استعمال کرتے ہیں۔ آپ کو page cache کے لیے، اور image build یا database dump کے دوران آنے والے لوڈ کے لیے بھی خالی میموری درکار ہوتی ہے۔

[
  {
    "plan": "2 GB VPS",
    "total_mb": 2048,
    "host_reserve_mb": 768,
    "container_mb": 1280
  },
  {
    "plan": "4 GB VPS",
    "total_mb": 4096,
    "host_reserve_mb": 1024,
    "container_mb": 3072
  },
  {
    "plan": "8 GB VPS",
    "total_mb": 8192,
    "host_reserve_mb": 1536,
    "container_mb": 6656
  }
]

host_reserve_mb آپریٹنگ سسٹم، Docker daemon اور اس اضافی گنجائش (headroom) کا احاطہ کرتا ہے جو لوڈ کے دوران سرور کو فعال رکھتی ہے۔ جو باقی بچتا ہے وہ container_mb ہے، اور یہی وہ واحد تعداد ہے جسے آپ خرچ کر سکتے ہیں۔ یہ ریزرو پلان کے ساتھ بڑھتا ہے، سب سے چھوٹے باکس پر 768 MB سے لے کر سب سے بڑے پر 1536 MB تک، کیونکہ بڑا باکس زیادہ containers چلاتا ہے، زیادہ logs لکھتا ہے اور اسے زیادہ page cache درکار ہوتا ہے۔

2 GB کا پلان containers کے لیے 1280 MB چھوڑتا ہے۔ اس میں سے 512 MB PostgreSQL پر اور 128 MB Traefik پر خرچ کریں، تو آدھی میموری ختم ہو جاتی ہے۔ باقی میں تقریباً 256 MB کی دو چھوٹی ایپلی کیشنز آ سکتی ہیں۔ یہ ایک حقیقی اور کارآمد سرور ہے۔ اس میں Nextcloud اور سرچ کلسٹر کے لیے جگہ نہیں ہے۔

4 GB کا پلان 3072 MB چھوڑتا ہے، جس میں ایک ڈیٹا بیس، ایک ریورس پراکسی، تین ایپلی کیشنز اور ایک مانیٹرنگ کنٹینر ایک ساتھ سما سکتے ہیں۔ یہ کم از کم وہ سائز ہے جو کسی بھی اہم کام کے لیے استعمال کرنے کے قابل ہے، کیونکہ اضافی میموری ہی وہ چیز ہے جو کسی غلط deploy کے اثرات کو جذب کرتی ہے۔

8 GB کا پلان اپنے 8192 MB میں سے 6656 MB چھوڑتا ہے، اور یہاں حد عام طور پر میموری سے ہٹ کر CPU یا ڈسک کی رفتار (throughput) پر منتقل ہو جاتی ہے۔ ایک قسم کے containers اپنی کنفیگریشن کے لحاظ سے میموری لیتے ہیں نہ کہ لوڈ کے لحاظ سے: ایک لوکل ماڈل سرور اپنے context window کے تناسب سے KV cache ریزرو کرتا ہے، لہذا Ollama کے num_ctx کو بڑھانا کسی بھی درخواست کے آنے سے پہلے ہی بجٹ میں گیگا بائٹس کا اضافہ کر سکتا ہے۔ اگر حساب بتاتا ہے کہ آپ کا اسٹیک فٹ نہیں ہو رہا، تو اسے محدود کرنے کے بجائے بڑا پلان خریدیں: ایک VPS کی اصل قیمت بتاتی ہے کہ اضافی گیگا بائٹس ماہانہ کتنی اہمیت رکھتے ہیں۔

دو اصول اس حساب کو درست رکھتے ہیں۔ ہر سروس پر میموری کی حد (memory limit) لگائیں، تاکہ ایک بے قابو پروسیس پورے باکس کو کریش نہ کر سکے۔ اور بجٹ کا کچھ حصہ غیر خرچ شدہ چھوڑ دیں، کیونکہ docker compose build اور pg_dump دونوں کو بدترین لمحات میں میموری کی ضرورت ہوتی ہے۔ Docker Compose میں میموری کی حدود میں اس کا طریقہ کار اور احتیاطی تدابیر موجود ہیں۔

میرا کنٹینر exit code 137 کے ساتھ کیوں بند ہو جاتا ہے؟

اس کی وجہ یہ ہے کہ کرنل نے اسے ختم کر دیا ہے۔ 137 دراصل 128 جمع 9 ہے، اور signal 9 کا مطلب SIGKILL ہے۔ کنٹینر نے اپنی اجازت سے زیادہ میموری مانگی، جس پر out of memory (OOM) killer نے اسے بند کر دیا۔

CONTAINER ID   IMAGE         STATUS
9f2c1a4d7b3e   postgres:16   Exited (137) 4 minutes ago

اندازہ لگانے کے بجائے وجہ کی تصدیق کریں:

docker inspect my-db | grep -i oomkilled
sudo journalctl -k | grep -i "out of memory"

"OOMKilled": true کا مطلب ہے کہ کنٹینر اپنی cgroup حد تک پہنچ گیا تھا، اور کرنل لاگ اس عمل (process) کا نام بتاتا ہے جسے اس نے منتخب کیا:

Memory cgroup out of memory: Killed process 2417 (postgres) total-vm:1284416kB

یہ بہتر صورتحال ہے، کیونکہ نقصان صرف ایک کنٹینر تک محدود رہا۔ بری صورتحال وہ ہے جب کنٹینر پر کوئی حد (limit) نہ ہو۔ حد نہ ہونے کی صورت میں اس کی آخری حد پوری مشین ہوتی ہے، لہذا ایک سروس میں میموری لیک ہونے سے پورا ہوسٹ متاثر ہوتا ہے، اور کرنل پھر پورے سسٹم میں سے کسی بھی عمل کو شکار بنا لیتا ہے۔ ایسی صورت میں لاگ لائن سے Memory cgroup کا prefix ہٹ جاتا ہے اور وہ Out of memory: Killed process 2417 (postgres) پڑھا جاتا ہے۔ کرنل اکثر آپ کے ڈیٹا بیس کو منتخب کر لیتا ہے، جبکہ وہ کنٹینر جس میں لیک تھی، چلتا رہتا ہے۔ یہی وجہ ہے کہ ہر سروس پر حد لگانا، کسی ایک حد کی درست قیمت متعین کرنے سے زیادہ اہم ہے۔

Swap وقت کو تبدیل کرتا ہے، حساب کتاب کو نہیں۔ زیادہ تر VPS امیجز بغیر swap کے آتی ہیں۔ swapon --show کے ساتھ چیک کریں، جو کچھ نہ ہونے کی صورت میں کوئی آؤٹ پٹ نہیں دیتا۔ ایک swap file کرنل کو غیر استعمال شدہ صفحات (cold pages) رکھنے کی جگہ دیتی ہے، جس سے آپ کو مسئلہ نوٹس کرنے کے لیے چند منٹ مل جاتے ہیں۔

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
free -h

free -h کو اب Swap کی قطار میں صفر کے علاوہ کوئی قدر دکھانی چاہیے۔ Swap ریم (RAM) میں اضافہ نہیں کرتا۔ مسلسل میموری کے دباؤ میں رہنے والی مشین اتنی سست ہو جاتی ہے کہ آپ اسے ٹھیک کرنے کے لیے SSH بھی نہیں کر سکتے، لہذا swap کو ایک الارم بفر سمجھیں اور سائزنگ کو درست کریں۔

UFW میرے شائع کردہ Docker port کو بلاک کیوں نہیں کرتا؟

کیونکہ ٹریفک کبھی بھی اس chain تک نہیں پہنچتی جس کی UFW نگرانی کرتا ہے۔ جب آپ -p 5432:5432 یا compose ports: انٹری کے ساتھ کوئی port شائع کرتے ہیں، تو daemon nat ٹیبل میں ایک DNAT (destination network address translation) رول اور اپنی DOCKER chain میں ایک accept رول لکھ دیتا ہے۔ کنٹینر کے لیے آنے والا پیکٹ ہوسٹ کو ڈیلیور ہونے کے بجائے براہ راست اس کنٹینر کو فارورڈ کر دیا جاتا ہے، لہذا یہ FORWARD پاتھ میں ہینڈل ہوتا ہے اور کبھی بھی ان INPUT رولز سے نہیں گزرتا جو UFW لکھتا ہے۔

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

sudo ufw status | grep 5432
sudo iptables -t nat -L DOCKER -n | grep 5432

UFW 5432 DENY IN Anywhere پرنٹ کر سکتا ہے جبکہ nat ٹیبل میں اسی port کے لیے DNAT tcp ... to:172.18.0.2:5432 رول موجود ہوتا ہے۔ کسی دوسری مشین سے، nc -vz your.server.ip 5432 اب بھی کنیکٹ ہو جاتا ہے۔ ڈیٹا بیس عوامی انٹرنیٹ پر ہوتا ہے اور فائر وال کہتی ہے کہ یہ نہیں ہے۔

اس کا حل یہ ہے کہ کم پورٹس شائع کریں۔ ایک compose پروجیکٹ میں موجود کنٹینرز ایک نیٹ ورک شیئر کرتے ہیں اور سروس کے نام سے ایک دوسرے تک پہنچ جاتے ہیں، لہذا جو ڈیٹا بیس صرف اپنے ساتھ والی ایپلیکیشن کو سروس دیتا ہے اسے کسی ports: انٹری کی ضرورت نہیں ہوتی۔ جب آپ مقامی رسائی چاہتے ہیں، تو پبلشنگ کو loopback پر bind کریں:

services:
  db:
    image: postgres:16
    ports:
      - "127.0.0.1:5432:5432"

docker compose up -d کے بعد، باہر سے nc -vz your.server.ip 5432 ناکام ہو جاتا ہے، اور باکس پر psql -h 127.0.0.1 -p 5432 اب بھی کام کرتا ہے۔ ایک صحت مند چھوٹے اسٹیک میں صرف ریورس پراکسی 80 اور 443 پر کچھ بھی شائع کرتی ہے۔ Docker کے شائع کردہ پورٹس UFW کو بائی پاس کیوں کرتے ہیں ان کیسز کے لیے DOCKER-USER chain کا احاطہ کرتا ہے جہاں آپ کو پورٹ شائع بھی کرنا ہو اور اسے فلٹر بھی کرنا ہو، اور UFW فائر وال کی بنیادی باتیں ہوسٹ رولز کی وضاحت کرتی ہے۔

ریبوٹ کے بعد میرے کنٹینرز کیوں غائب ہو جاتے ہیں؟

اس کی وجہ یہ ہے کہ انہیں واپس آنے کی ہدایت نہیں دی گئی تھی۔ جب تک آپ کوئی پالیسی سیٹ نہ کریں، کنٹینر no ری اسٹارٹ پالیسی کے ساتھ بنتا ہے، لہذا ریبوٹ کے بعد وہ بند رہتا ہے اور ڈیمن (daemon) اس کی پرواہ نہیں کرتا۔ VPS پر ریبوٹ غیر معمولی نہیں ہیں: unattended upgrades سے کرنل اپڈیٹس، پرووائیڈر کی دیکھ بھال، اور اوپر بیان کردہ OOM sequence، سب کا نتیجہ ریبوٹ پر نکلتا ہے۔

دو چیزوں کا درست ہونا ضروری ہے۔ ڈیمن کو بوٹ کے وقت شروع ہونا چاہیے:

systemctl is-enabled docker

یہ ایک معیاری Ubuntu انسٹال پر enabled پرنٹ کرتا ہے۔ پھر ہر سروس کو ایک پالیسی کی ضرورت ہوتی ہے:

services:
  app:
    image: ghcr.io/example/app:1.4
    restart: unless-stopped

unless-stopped ریبوٹ کے بعد کنٹینر کو واپس لاتا ہے اور آپ کے جان بوجھ کر بند کیے گئے کنٹینر کا احترام کرتا ہے۔ always ان کنٹینرز کو بھی ری اسٹارٹ کر دیتا ہے جنہیں آپ نے جان بوجھ کر بند کیا تھا، جب بھی ڈیمن ری اسٹارٹ ہوتا ہے، جو کہ ڈیبگنگ کے دوران ایک حیران کن صورتحال ہو سکتی ہے۔ صرف فائل کو ایڈٹ کرنا کافی نہیں ہے، کیونکہ ری اسٹارٹ پالیسی تب سیٹ ہوتی ہے جب کنٹینر بنایا جاتا ہے۔ docker compose up -d چلائیں تاکہ اسے دوبارہ بنایا جا سکے، پھر لائیو ویلیو چیک کریں:

docker inspect my-app | grep -A3 RestartPolicy

پھر باکس کو جان بوجھ کر ریبوٹ کریں اور پروجیکٹ ڈائریکٹری میں docker compose ps چلائیں۔ جو اسٹیک منصوبہ بند ریبوٹ کے بعد بحال ہو جاتا ہے، وہ غیر منصوبہ بند ریبوٹ کے بعد بھی بحال ہو جائے گا۔ اگر آپ کے اسٹیک کو بوٹ کے وقت ترتیب (ordering) کی ضمانت یا ایک بار چلنے والے کام (one-shot job) کی ضرورت ہو، تو systemd یونٹ ایک بہتر ٹول ہے: Docker Compose کو بوٹ پر شروع کرنا میں یونٹ فائل موجود ہے۔ یہ جاننے کے لیے کہ آیا واپس آنے والا کنٹینر واقعی سروس فراہم کر رہا ہے، Compose ہیلتھ چیکس شامل کریں۔

میرا VPS ڈسک فل کیوں ہے؟

اس کی وجہ یہ ہے کہ Docker ہر چیز کو تب تک محفوظ رکھتا ہے جب تک آپ اسے حذف کرنے کا حکم نہ دیں۔ آپ کی ڈاؤن لوڈ کردہ ہر image tag، ہر بند شدہ container، دوبارہ تخلیق (recreate) کے بعد پیچھے رہ جانے والا ہر anonymous volume، اور build cache کی ہر تہہ ڈسک پر موجود رہتی ہے۔ 40 GB یا 80 GB کے root filesystem پر، جو کہ ان پلان سائزز کے لیے معمول ہے، یہ چند سالوں کے بجائے چند مہینوں میں سروس کی بندش کا باعث بنتا ہے۔

ڈسک کا بھر جانا کسی کریش جیسا نہیں لگتا۔ آپ کو ایک ہی گھنٹے کے اندر کنٹینر سے no space left on device، apt سے، journald سے اور docker pull سے غلطیاں موصول ہوتی ہیں۔ PostgreSQL لکھنا (writes) بند کر دیتا ہے۔ سرور اب بھی چل رہا ہوتا ہے، جس کی وجہ سے اسے reboot loop کے مقابلے میں پہچاننا زیادہ مشکل ہوتا ہے۔

حذف کرنے سے پہلے جائزہ لیں:

docker system df
df -h /

docker system df کل جگہ کو images، containers، local volumes اور build cache میں تقسیم کرتا ہے، اور ہر ایک کے ساتھ RECLAIMABLE کا کالم دکھاتا ہے۔ ایسے سرور پر جو اپنی images خود بناتا ہے، build cache عام طور پر سب سے بڑی لائن ہوتی ہے۔

docker image prune -a
docker builder prune
docker system df

docker image prune -a ہر وہ image ہٹا دیتا ہے جسے کوئی کنٹینر استعمال نہیں کر رہا۔ docker builder prune بلڈ کیشے کو صاف کرتا ہے۔ سروسز چلتے ہوئے دونوں کمانڈز محفوظ ہیں، کیونکہ جو کچھ استعمال میں ہوتا ہے اسے چھوڑ دیا جاتا ہے۔ جو چیز محفوظ نہیں ہے وہ docker system prune --volumes ہے، جو ہر وہ volume حذف کر دیتا ہے جس کا حوالہ اس وقت کوئی کنٹینر نہیں دے رہا۔ ویک اینڈ کے لیے روکی گئی stack کی حالت بالکل ایسی ہی ہوتی ہے، اور اس کا database volume بھی اس کے ساتھ ہی حذف ہو جاتا ہے۔ اس فلیگ کو ٹائپ کرنے سے پہلے bind mounts بمقابلہ named volumes پڑھیں، اور پہلے بیک اپ لیں۔

کنٹینر کے logs خاموشی سے جگہ گھیرتے ہیں۔ ڈیفالٹ json-file ڈرائیور کی کوئی سائز کی حد نہیں ہوتی، اس لیے ایک زیادہ ڈیٹا لکھنے والا کنٹینر /var/lib/docker/containers میں گیگا بائٹس ڈیٹا لکھ دیتا ہے۔ /etc/docker/daemon.json میں ہر کنٹینر کے لیے اس کی حد مقرر کریں:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

اسے sudo systemctl restart docker کے ساتھ لاگو کریں، جو آپ کے کنٹینرز کو ری اسٹارٹ کرتا ہے، لہذا مناسب وقت کا انتخاب کریں۔ یہ حد تبدیلی کے بعد بنائے گئے کنٹینرز پر لاگو ہوتی ہے، اس لیے چلتے ہوئے کنٹینرز کو docker compose up -d --force-recreate کے ساتھ دوبارہ بنائیں اور تصدیق کریں:

docker inspect my-app | grep -A5 LogConfig
sudo du -sh /var/lib/docker/containers

inspect آؤٹ پٹ میں max-size سیٹ نظر آنا چاہیے۔ اگر یہ خالی ہے، تو اس کا مطلب ہے کہ وہ کنٹینر اس تبدیلی سے پہلے کا ہے اور اب بھی بغیر کسی حد کے ڈیٹا لکھ رہا ہے۔

چھوٹے Docker باکس کو صحت مند رکھنے کی عادات

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

• ہر مہینے کی پہلی تاریخ کو docker system df اور df -h / چلائیں۔ دو کمانڈز، تیس سیکنڈ کا وقت، اور آپ خرابی پیدا ہونے سے کافی پہلے رجحان دیکھ لیں گے۔
• ہر سروس کو میموری کی حد (memory limit) دیں، بشمول ان کے جن کے بارے میں آپ کو یقین ہے کہ وہ چھوٹی ہیں۔ یہ حد پورے ہوسٹ کی بندش کو صرف ایک ری اسٹارٹ ہونے والے کنٹینر تک محدود کر دیتی ہے۔
• باکس کو کہیں اور سے مانیٹر کریں، تاکہ کرنل کے عمل کرنے سے پہلے آپ کو میموری یا ڈسک کے دباؤ کا علم ہو جائے۔ Uptime Kuma ایک کنٹینر میں چلتا ہے اور تقریباً 95 MB پر آئیڈل رہتا ہے۔
• کنٹینرز کا نہیں، والیمز (volumes) کا بیک اپ لیں۔ کنٹینر ضائع کیا جا سکتا ہے لیکن والیم نہیں۔ restic backups on a VPS شیڈول اور بحالی کے ٹیسٹ کا احاطہ کرتا ہے۔
• compose فائل میں امیج ٹیگز کو پن (pin) کریں اور اپنی مرضی کے دن انہیں اپ ڈیٹ کریں۔ latest کے ساتھ، اگلی docker compose pull سے آپ کو وہی ورژن ملے گا جو اس صبح ریلیز ہوا ہو۔

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

FAQ

VPS پر Docker چلانے کے لیے کتنی RAM درکار ہے؟

Docker بذات خود بہت کم وسائل استعمال کرتا ہے۔ daemon اور containerd مل کر تقریباً 100 MB لیتے ہیں، باقی ضرورت آپ کے containers پر منحصر ہے۔ پہلے host کا حصہ مختص کریں: 2048 MB کے باکس میں 768 MB آپریٹنگ سسٹم، daemon اور اضافی گنجائش کے لیے رکھیں، جس کے بعد 1280 MB آپ کے پاس استعمال کے لیے بچتے ہیں۔ 512 MB پر ایک ڈیٹا بیس، 128 MB پر ایک reverse proxy اور دو چھوٹی ایپلی کیشنز اس میں آسانی سے سما سکتی ہیں۔ کسی بھی شائع شدہ اعداد و شمار پر بھروسہ کرنے کے بجائے docker stats --no-stream کے ذریعے اپنے stack کی پیمائش خود کریں۔

کیا میں 1 GB والے VPS پر Docker چلا سکتا ہوں؟

جی ہاں، ایک یا دو ہلکے containers کے لیے یہ ممکن ہے، لیکن شروع کرنے سے پہلے swap file ضرور بنائیں۔ 1 GB کے باکس کا تقریباً نصف حصہ آپریٹنگ سسٹم اور Docker daemon کے چلتے ہی استعمال ہو جاتا ہے، جس کے بعد ایک چھوٹی ایپلی کیشن اور reverse proxy کے لیے جگہ تو بچتی ہے، لیکن حقیقی لوڈ کے تحت ڈیٹا بیس کے لیے نہیں۔ اس سائز کے باکس پر images build کرنے سے عمل ناکام ہو سکتا ہے یا کوئی دوسری سروس بند ہو سکتی ہے، اس لیے بہتر ہے کہ کہیں اور build کریں اور تیار شدہ image کو pull کریں۔

کیا UFW میرے Docker container کی حفاظت کرتا ہے؟

ان ports کے لیے نہیں جنہیں آپ publish کرتے ہیں۔ Docker اپنے DNAT اور forward rules خود لکھتا ہے، لہذا published container port پر آنے والی ٹریفک براہ راست container کو بھیج دی جاتی ہے، نہ کہ host کو، اور UFW کے زیر انتظام INPUT rules اسے دیکھ ہی نہیں پاتے۔ ufw deny 5432 فعال ہو سکتا ہے جبکہ وہ port انٹرنیٹ سے جواب دے رہی ہو۔ 127.0.0.1:5432:5432 کے ساتھ loopback پر publish کریں، اندرونی سروسز کو unpublished رہنے دیں، یا DOCKER-USER chain میں فلٹر کریں۔

کیا VPS ریبوٹ ہونے کے بعد میرے containers خود بخود دوبارہ شروع ہوں گے؟

صرف تب، اگر وہ restart policy کے ساتھ بنائے گئے ہوں۔ ہر سروس پر restart: unless-stopped سیٹ کریں، docker compose up -d چلائیں تاکہ containers اس پالیسی کے ساتھ دوبارہ بن جائیں، اور تصدیق کریں کہ systemctl is-enabled docker کا آؤٹ پٹ enabled ہے۔ اس کے بعد جان بوجھ کر ریبوٹ کریں اور docker compose ps چیک کریں۔ ایسی restart policy جس کا آپ نے تجربہ نہ کیا ہو، وہ قابلِ بھروسہ نہیں ہے۔

مجھے Docker images کو کتنی بار prune کرنا چاہیے؟

زیادہ تر چھوٹے سرورز کے لیے مہینے میں ایک بار کافی ہے، یا جب بھی docker system df ایسی جگہ کی نشاندہی کرے جسے آپ دوبارہ حاصل کرنا چاہتے ہیں۔ docker image prune -a اور docker builder prune سروسز کے چلتے ہوئے استعمال کرنا محفوظ ہے، کیونکہ زیر استعمال images اور cache کو نظر انداز کر دیا جاتا ہے۔ docker system prune --volumes سے گریز کریں جب تک کہ آپ کو بخوبی علم نہ ہو کہ کون سی volumes غیر متعلقہ (unreferenced) ہیں، کیونکہ یہ کسی بھی ایسے stack کا ڈیٹا حذف کر سکتا ہے جو اتفاق سے بند ہو۔