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

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

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

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

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

ذیل کے ہر section میں failure، وہ string جو آپ حقیقت میں دیکھیں گے، اور وہ guide درج ہے جو اس مسئلے کو تفصیل سے حل کرتی ہے۔ اگر آپ نے ابھی compose file نہیں لکھی تو پہلے VPS پر Docker Compose کی بنیادی باتیں پڑھیں اور پھر واپس آئیں۔ اس صفحے میں یہ فرض کیا گیا ہے کہ آپ stack کو پہلے ہی start کر سکتے ہیں۔

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

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

ذیل کے اعداد Ubuntu 24.04 پر default configuration کے ساتھ stock images کے عام idle اعداد ہیں۔ انہیں start کے چند منٹ بعد docker stats سے پڑھا گیا ہے۔ یہ planning کے لیے ابتدائی اندازہ ہیں، آپ کے workload کا benchmark نہیں۔ کسی بھی figure، بشمول ان اعداد کے، پر اعتماد کرنے سے پہلے اپنے box پر 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
  }
]

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

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

docker stats کے بارے میں ایک انتباہ: memory figure میں وہ page cache بھی شامل ہوتا ہے جو container کے اپنے file reads سے load ہوا ہے۔ اس لیے start کے بعد یہ کچھ دیر بڑھتا ہے اور پھر مستحکم ہو جاتا ہے۔ کسی memory leak کا فیصلہ کرنے سے پہلے اسے ایک گھنٹے تک monitor کریں۔

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

سب سے پہلے host کا حصہ الگ نکالیں۔ kernel، systemd، journald، sshd اور Docker daemon اسی RAM میں چلتے ہیں جس میں آپ کے containers چلتے ہیں، اور dockerd کے ساتھ containerd اس میں تقریباً 100 MB استعمال کرتے ہیں۔ page cache کے لیے بھی مفت memory درکار ہوتی ہے، اور اس وقت اضافی memory چاہیے ہوتی ہے جب 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 operating system، Docker daemon اور وہ اضافی گنجائش شامل کرتا ہے جو load کے دوران server کو responsive رکھتی ہے۔ باقی memory container_mb ہے، اور خرچ کرنے کے لیے آپ کے پاس یہی واحد مقدار ہے۔ چھوٹے ترین plan میں reserve 768 MB سے شروع ہوتا ہے اور بڑے ترین plan میں 1536 MB تک بڑھ جاتا ہے، کیونکہ بڑا server زیادہ containers چلاتا ہے، زیادہ logs لکھتا ہے اور زیادہ page cache چاہتا ہے۔

2 GB plan containers کے لیے 1280 MB چھوڑتا ہے۔ اس میں سے 512 MB PostgreSQL اور 128 MB Traefik کو دیں تو آدھی memory پہلے ہی استعمال ہو جاتی ہے۔ باقی memory تقریباً 256 MB کی دو چھوٹی applications کے لیے کافی ہے۔ یہ ایک حقیقی اور مفید server ہے۔ لیکن اس میں Nextcloud اور search cluster دونوں چلانے کی گنجائش نہیں ہے۔

4 GB plan 3072 MB چھوڑتا ہے۔ اس میں database، reverse proxy، تین applications اور monitoring container بیک وقت سما جاتے ہیں۔ کسی اہم استعمال کے لیے یہ کم از کم قابلِ غور سائز ہے، کیونکہ اضافی memory ہی خراب deploy کے اثرات کو برداشت کرتی ہے۔

8 GB plan اپنی 8192 MB میں سے 6656 MB چھوڑتا ہے، اور اس صورت میں حد عموماً memory کے بجائے CPU یا disk throughput بن جاتی ہے۔ اگر حساب سے معلوم ہو کہ آپ کا stack نہیں سما رہا تو اس کے مطابق configuration کو زبردستی محدود کرنے کے بجائے بڑا plan خریدیں: VPS کی اصل لاگت میں بتایا گیا ہے کہ اضافی gigabytes کی ماہانہ قدر کیا ہے۔

دو اصول حساب کو درست رکھتے ہیں۔ ہر service پر memory limit مقرر کریں، تاکہ کوئی بے قابو process پورے server کو متاثر نہ کر سکے۔ اور budget کا کچھ حصہ خرچ کیے بغیر چھوڑیں، کیونکہ docker compose build اور pg_dump دونوں کو بدترین وقت میں memory درکار ہوتی ہے۔ Docker Compose میں memory limits میں syntax اور عام مسائل بیان کیے گئے ہیں۔

میرا container code 137 کے ساتھ کیوں exit ہوتا ہے؟

کیونکہ kernel نے اسے ختم کر دیا۔ 137، 128 جمع 9 کے برابر ہے، اور signal 9، SIGKILL ہے۔ container نے اپنی اجازت شدہ حد سے زیادہ memory طلب کی، اس لیے 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 کا مطلب ہے کہ container اپنی cgroup limit تک پہنچ گیا، اور kernel log میں اس process کا نام درج ہوتا ہے جسے اس نے منتخب کیا:

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

یہ بہتر صورت ہے، کیونکہ نقصان صرف ایک container تک محدود رہتا ہے۔ خراب صورت وہ ہے جب container پر کوئی limit نہ ہو۔ ایسی صورت میں اس کی maximum حد پوری machine کی memory ہوتی ہے۔ ایک service میں memory leak host کی دستیاب memory ختم کر دیتا ہے، اور پھر kernel پورے system میں memory کے استعمال کے لحاظ سے کسی process کو ختم کرنے کے لیے منتخب کرتا ہے۔ log line میں Memory cgroup prefix نہیں ہوتا اور وہ Out of memory: Killed process 2417 (postgres) دکھاتی ہے۔ منتخب ہونے والا process اکثر آپ کا database ہوتا ہے، جبکہ memory leak کرنے والا container چلتا رہتا ہے۔ اسی لیے ہر service پر limit مقرر کرنا کسی ایک limit کی درست قدر سے زیادہ اہم ہے۔

Swap وقت بدلتا ہے، حساب نہیں۔ زیادہ تر VPS images میں swap موجود نہیں ہوتا۔ swapon --show سے تصدیق کریں؛ اگر swap موجود نہ ہو تو یہ کچھ بھی print نہیں کرتا۔ swap file kernel کو غیر فعال 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 row میں non-zero total دکھانا چاہیے۔ Swap RAM میں اضافہ نہیں کرتا۔ مسلسل memory pressure والی machine اتنی سست ہو سکتی ہے کہ مسئلہ حل کرنے کے لیے آپ SSH سے login نہ کر سکیں۔ اس لیے swap کو عارضی alarm buffer سمجھیں اور sizing درست کریں۔

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

کیونکہ network traffic اس chain تک پہنچتا ہی نہیں جس کی نگرانی UFW کرتا ہے۔ جب آپ -p 5432:5432 کے ذریعے port publish کرتے ہیں یا Compose کی ports: entry استعمال کرتے ہیں، تو daemon nat table میں DNAT (destination network address translation) rule اور اپنی DOCKER chain میں accept rule لکھتا ہے۔ Container کے لیے بھیجا گیا packet host کو deliver ہونے کے بجائے اس container کو forward کر دیا جاتا ہے، اس لیے اسے FORWARD path میں handle کیا جاتا ہے اور یہ UFW کی لکھی ہوئی INPUT rules سے نہیں گزرتا۔

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

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

UFW 5432 DENY IN Anywhere دکھا سکتا ہے، جبکہ nat table میں اسی port کے لیے DNAT tcp ... to:172.18.0.2:5432 rule موجود ہوتا ہے۔ کسی دوسری machine سے nc -vz your.server.ip 5432 اب بھی connect ہو جاتا ہے۔ Database public internet پر موجود ہے، لیکن firewall کے مطابق یہ موجود نہیں۔

اس کا حل کم ports publish کرنا ہے۔ ایک Compose project کے containers ایک ہی network share کرتے ہیں اور service name کے ذریعے ایک دوسرے تک پہنچ سکتے ہیں، اس لیے جو database صرف اپنے ساتھ موجود application کو service دیتا ہے اسے ports: entry کی ضرورت نہیں۔ جب local access درکار ہو تو publish کو loopback سے bind کریں:

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

docker compose up -d کے بعد باہر سے nc -vz your.server.ip 5432 ناکام ہو جاتا ہے، جبکہ اسی box پر psql -h 127.0.0.1 -p 5432 اب بھی کام کرتا ہے۔ ایک درست طور پر ترتیب دیے گئے چھوٹے stack میں صرف reverse proxy ہی کوئی port publish کرتا ہے، یعنی 80 اور 443۔ Docker کے شائع کردہ ports UFW کو bypass کیوں کرتے ہیں ان صورتوں میں DOCKER-USER chain کا احاطہ کرتا ہے جہاں port publish کرنا ضروری ہو اور پھر بھی اسے filter کرنا ہو، جبکہ UFW firewall کی بنیادی باتیں اس کے نیچے موجود host rules کی وضاحت کرتا ہے۔

ریبوٹ کے بعد میرے containers کہاں چلے گئے؟

کیونکہ انہیں دوبارہ شروع کرنے کی کوئی ہدایت نہیں دی گئی تھی۔ اگر آپ restart policy مقرر نہ کریں تو container کو no کے ساتھ بنایا جاتا ہے۔ اس لیے reboot کے بعد وہ stopped حالت میں رہتا ہے اور daemon اسے دوبارہ شروع نہیں کرتا۔ VPS پر reboot غیر معمولی واقعہ نہیں ہے۔ unattended upgrades کے kernel updates، provider کی maintenance، اور اوپر بیان کردہ OOM sequence، سب reboot کا سبب بن سکتے ہیں۔

دو باتیں درست ہونی چاہییں۔ daemon کو boot کے وقت شروع ہونا چاہیے:

systemctl is-enabled docker

یہ stock Ubuntu install پر enabled دکھاتا ہے۔ اس کے بعد ہر service کے لیے ایک policy مقرر کریں:

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

unless-stopped reboot کے بعد container کو دوبارہ شروع کرتا ہے اور اس container کا احترام کرتا ہے جسے آپ نے جان بوجھ کر stop کیا ہو۔ always ان containers کو بھی daemon کے restart ہونے پر دوبارہ شروع کرتا ہے جنہیں آپ نے دانستہ طور پر stop کیا تھا۔ debugging کے دوران یہ غیر متوقع رویہ ہو سکتا ہے۔ صرف file میں ترمیم کرنا کافی نہیں، کیونکہ restart policy container بناتے وقت مقرر ہوتی ہے۔ docker compose up -d چلائیں تاکہ container دوبارہ بنایا جائے، پھر موجودہ value دیکھیں:

docker inspect my-app | grep -A3 RestartPolicy

اس کے بعد جان بوجھ کر box کو reboot کریں اور project directory میں docker compose ps چلائیں۔ جو stack planned reboot کے بعد برقرار رہتا ہے، وہ unplanned reboot کے بعد بھی برقرار رہتا ہے۔ اگر آپ کے stack کو ordering guarantee یا boot کے وقت one-shot job درکار ہو تو systemd unit بہتر tool ہے: boot پر Docker Compose شروع کرنا میں unit file موجود ہے۔ یہ جاننے کے لیے کہ واپس آنے والا container واقعی service فراہم کر رہا ہے یا نہیں، Compose healthchecks شامل کریں۔

میرا VPS ڈسک سے بھر کیوں گیا ہے؟

کیونکہ Docker ہر چیز اس وقت تک محفوظ رکھتا ہے جب تک آپ اسے ایسا نہ کرنے کو کہیں۔ آپ نے جتنے بھی image tags pull کیے ہیں، ہر stopped container، recreate کے بعد بچ رہنے والا ہر anonymous volume، اور build cache کی ہر layer ڈسک پر موجود رہتی ہے۔ ان plan sizes میں 40 GB یا 80 GB کا root filesystem معمول کی بات ہے۔ اس لیے یہ مسئلہ برسوں کے بجائے چند ماہ میں outage کا سبب بن سکتا ہے۔

بھری ہوئی ڈسک crash جیسی نظر نہیں آتی۔ ایک ہی گھنٹے میں آپ کو کسی container، no space left on device، journald اور apt سے docker pull مل سکتا ہے۔ PostgreSQL writes قبول کرنا بند کر دیتا ہے۔ سرور پھر بھی up رہتا ہے، اس لیے اسے reboot loop کے مقابلے میں محسوس کرنا زیادہ مشکل ہوتا ہے۔

حذف کرنے سے پہلے صورتِ حال دیکھیں:

docker system df
df -h /

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

docker image prune -a
docker builder prune
docker system df

docker image prune -a ایسی تمام images حذف کرتا ہے جنہیں کوئی container استعمال نہیں کر رہا۔ docker builder prune build cache صاف کرتا ہے۔ Services چلتے وقت دونوں commands محفوظ ہیں، کیونکہ استعمال میں موجود چیزیں skip کر دی جاتی ہیں۔ محفوظ نہ ہونے والی command docker system prune --volumes ہے، جو ایسے تمام volumes حذف کر دیتی ہے جن کا اس وقت کوئی container حوالہ نہیں دے رہا۔ Weekend کے لیے روکا گیا stack عین اسی حالت میں ہوتا ہے، اور اس کا database volume بھی حذف ہو جاتا ہے۔ یہ flag استعمال کرنے سے پہلے bind mounts اور named volumes کا فرق پڑھیں، اور پہلے backup لیں۔

Container logs نسبتاً خاموشی سے بڑھتے ہیں۔ Default json-file driver کی کوئی size limit نہیں ہوتی، اس لیے ایک زیادہ logs لکھنے والا container /var/lib/docker/containers میں gigabytes محفوظ کر سکتا ہے۔ ہر container کے لیے /etc/docker/daemon.json میں اس کی حد مقرر کریں:

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

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

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

Inspect output میں max-size set نظر آنا چاہیے۔ اگر یہ خالی ہے تو وہ container change سے پہلے بنایا گیا تھا اور اب بھی بغیر کسی limit کے لکھ رہا ہے۔

وہ عادات جو ایک چھوٹے Docker box کو صحت مند رکھتی ہیں

اس میں dashboard یا ایسا tool درکار نہیں جسے آپ کو سیکھنا پڑے۔

• مہینے کی پہلی تاریخ کو docker system df اور df -h / چلائیں۔ دو commands، تیس seconds، اور آپ کو مسئلہ outage بننے سے بہت پہلے رجحان نظر آ جاتا ہے۔
• ہر service کے لیے memory limit مقرر کریں، ان services کے لیے بھی جنہیں آپ یقینی طور پر چھوٹا سمجھتے ہیں۔ یہ limit پورے host کے outage کو صرف ایک restarted container تک محدود کر دیتی ہے۔
• box کو کسی دوسرے مقام سے monitor کریں، تاکہ kernel کارروائی کرنے سے پہلے ہی آپ کو memory یا disk pressure کا پتا چل جائے۔ Uptime Kuma ایک container میں چلتا ہے اور idle حالت میں تقریباً 95 MB memory استعمال کرتا ہے۔
• containers کے بجائے volumes کا backup لیں۔ container عارضی ہوتا ہے، volume نہیں۔ VPS پر restic backups schedule اور restore test دونوں کا احاطہ کرتا ہے۔
• compose file میں image tags کو pin کریں اور انہیں اپنی مقررہ تاریخ کو update کریں۔ latest کے ساتھ، اگلے docker compose pull سے ملنے والا version وہی ہوتا ہے جو اس صبح release ہوا ہو۔

Docker چلانے والا ایک چھوٹا VPS برسوں تک صحت مند رہتا ہے، جب چار numbers مقررہ حد میں رہیں: memory budget، published ports کی فہرست، ہر service کی restart policy، اور free disk۔ باقی سب وہی Docker ہے جسے آپ پہلے ہی گھر پر چلا رہے ہیں۔

FAQ

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

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

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

ہاں، ایک یا دو ہلکے containers کے لیے چلا سکتے ہیں۔ شروع کرنے سے پہلے swap file بنائیں۔ operating system اور Docker daemon چلنے کے بعد 1 GB host کی تقریباً نصف memory استعمال ہو جاتی ہے۔ باقی گنجائش ایک چھوٹی application اور reverse proxy کے لیے کافی ہے، لیکن حقیقی load کے دوران database کے لیے نہیں۔ اتنے کم وسائل والے host پر images build کرنے سے build ناکام ہو سکتی ہے یا کوئی دوسری service بند ہو سکتی ہے۔ اس لیے images کسی دوسرے host پر build کریں اور تیار image pull کریں۔

کیا UFW Docker container کو تحفظ دیتا ہے؟

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

کیا VPS reboot ہونے کے بعد میرے containers دوبارہ شروع ہو جائیں گے؟

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

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

زیادہ تر چھوٹے servers کے لیے ماہانہ pruning کافی ہے۔ آپ اسے اس وقت بھی کر سکتے ہیں جب docker system df ایسی reclaimable space دکھائے جس کی آپ کو ضرورت ہو۔ services چلتے ہوئے docker image prune -a اور docker builder prune دونوں محفوظ ہیں، کیونکہ استعمال میں موجود images اور cache کو چھوڑ دیا جاتا ہے۔ docker system prune --volumes سے گریز کریں، جب تک آپ کو پوری طرح معلوم نہ ہو کہ کون سے volumes unreferenced ہیں، کیونکہ یہ کسی بھی ایسے stack کا data حذف کر دیتا ہے جو اس وقت stopped ہو۔