Docker Compose کمانڈز: حقیقی سرور کے لیے cheat sheet

وہ Compose کمانڈز جو آپ عملی طور پر استعمال کرتے ہیں

Docker Compose چالیس سے زیادہ ذیلی کمانڈز فراہم کرتا ہے۔ سرور پر روزمرہ کام کے لیے تقریباً ایک درجن کمانڈز کافی ہوتی ہیں۔ یہ صفحہ ان کمانڈز کو آپ کے کام کے لحاظ سے گروپ کرتا ہے، ہر کمانڈ کی ایک واضح وجہ بتاتا ہے، اور جہاں کمانڈ میں کوئی پیچیدگی ہو وہاں تفصیلی وضاحت کی طرف رہنمائی کرتا ہے۔

یہاں ہر جگہ Compose V2 استعمال ہوتا ہے: docker compose، جس میں space ہوتا ہے، نہ کہ پرانی docker-compose script۔ V2 ایک Go plugin ہے جو Docker Engine کے ساتھ انسٹال ہوتا ہے۔ موجودہ packages سے V1 ختم ہو چکا ہے، اس لیے July 2026 تک تازہ Ubuntu system پر docker-compose: command not found کا موجود ہونا خرابی نہیں بلکہ متوقع صورت ہے۔ docker compose version سے جانچ کریں۔ اگر اس کا کوئی output نہ آئے تو docker-compose-plugin package انسٹال کریں۔

ذیل کی ہر کمانڈ اس directory سے چلائیں جس میں آپ کی compose.yaml موجود ہو، کیونکہ Compose project name اسی directory سے لیتا ہے اور file بھی اسی کے نسبت سے تلاش کرتا ہے۔ یہی کمانڈ اس سے ایک سطح اوپر چلانے پر Compose no configuration file provided: not found کے ساتھ رک جاتا ہے۔ اگر file format آپ کے لیے نیا ہے تو VPS پر پہلی Compose file سے شروع کریں، پھر کمانڈز کے لیے یہاں واپس آئیں۔

لائف سائیکل: وہ چار کمانڈز جو آپ ٹائپ کرتے ہیں، اور وہ ایک جو containers ہٹا دیتی ہے

docker compose up -d
docker compose up -d --wait
docker compose stop
docker compose start
docker compose restart web
docker compose down

up -d network بناتی ہے، containers بناتی ہے، انہیں شروع کرتی ہے، اور واپس آ جاتی ہے۔ یہ اسی وقت واپس آ جاتی ہے جب containers صرف بنائے جاتے ہیں۔ اسی لیے اس کے فوراً بعد curl probe چلانے والی deploy script اکثر پہلی کوشش میں ناکام ہو جاتی ہے۔ up -d --wait اس وقت تک منتظر رہتی ہے جب تک healthcheck متعین کرنے والی ہر service صحت مند ہونے کی اطلاع نہ دے۔ اگر کوئی service کبھی صحت مند نہ ہو تو یہ non-zero status کے ساتھ ختم ہوتی ہے۔ یہ flag اپنے پسِ منظر میں موجود check جتنی ہی قابلِ اعتماد ہے۔ اس لیے automation میں اس پر انحصار کرنے سے پہلے ایسا healthcheck لکھیں جس پر Compose اعتماد کر سکے۔

stop containers کو روک دیتی ہے لیکن انہیں برقرار رکھتی ہے۔ اس لیے start انہی containers کو اسی writable layer کے ساتھ دوبارہ شروع کرتی ہے۔ down containers کو روکتی ہے، پھر containers اور project network کو ہٹا دیتی ہے۔ volume کے باہر container کے اندر لکھی گئی ہر چیز بھی ان کے ساتھ ختم ہو جاتی ہے۔ Compose میں یہ سب سے مہنگی غلط فہمی ہے، اور down اور stop کے درمیان مکمل فرق واضح کرتا ہے کہ یہ مسئلہ کہاں پیدا ہوتا ہے۔

restart reload نہیں ہے۔ یہ اسی container کو اس کی موجودہ configuration کے ساتھ روکتی اور دوبارہ شروع کرتی ہے۔ اس لیے تبدیل کیا گیا environment variable، نیا image tag یا ترمیم شدہ port mapping بالکل اثر انداز نہیں ہوتا۔ file میں تبدیلی لاگو کرنے کے لیے آپ دوبارہ up -d چلاتے ہیں۔ Compose ہر service کا اس کے running container سے موازنہ کرتی ہے اور صرف ان containers کو دوبارہ بناتی ہے جن کی configuration تبدیل ہوئی ہو۔

تبدیلی کا اطلاق: دوبارہ بنائیں، حاصل کریں، یا ازسرنو تعمیر کریں

docker compose up -d --force-recreate
docker compose pull && docker compose up -d
docker compose build --no-cache web
docker compose up -d --build web

جب کوئی تبدیلی نہ ہوئی ہو تو up -d خود سے کچھ نہیں کرتا، اسی وجہ سے اسے بار بار چلانا محفوظ ہے۔ --force-recreate اس موازنے کو نظرانداز کرتا ہے اور ترتیب یکساں ہونے کے باوجود ہر container کو تبدیل کر دیتا ہے، اس لیے in-container کی غیر معمولی حالت صاف کرنے کا یہ تیز ترین طریقہ ہے۔

image کو اپ ڈیٹ کرنے کے لیے دو commands درکار ہوتی ہیں، کیونکہ یہ دونوں مختلف کام کرتی ہیں۔ pull فائل میں نام زد ہر tag کے لیے موجودہ image download کرتا ہے۔ اس کے بعد up -d دیکھتا ہے کہ service کا image ID اس کے چلتے ہوئے container سے مطابقت نہیں رکھتا، اور اسے دوبارہ بناتا ہے۔ pull کو چھوڑ دیں تو up -d پچھلے ماہ کا latest بغیر کسی error کے چلاتا رہتا ہے۔

build ان services پر لاگو ہوتا ہے جن میں image: کے بجائے build: section بیان کیا گیا ہو۔ up -d --build ایک ہی مرحلے میں build اور start کرتا ہے، اور code میں تبدیلی کرتے وقت یہی معمول کا طریقہ ہے۔ --no-cache صرف اس وقت استعمال کریں جب cached layer واضح طور پر پرانی ہو، کیونکہ یہ ہر layer کو شروع سے دوبارہ بناتا ہے۔

جو کچھ چل رہا ہے اسے دیکھنا

docker compose ps
docker compose ps -a
docker compose logs -f --tail=100
docker compose logs --since 15m --timestamps db
docker compose top
docker compose ls

ps صرف چلنے والے containers کی فہرست دکھاتا ہے۔ جو service شروع ہوتے وقت crash ہو جائے، وہ اس فہرست میں اس وقت تک نظر نہیں آتی جب تک آپ -a شامل نہ کریں۔ اس لیے ps میں موجود نہ ہونے والا container، جبکہ ps -a اسے Exited (1) دکھا رہا ہو، startup failure کی معمول کی صورت ہے۔ پہلے exit code دیکھیں، پھر logs دیکھیں۔

logs -f تمام services کو ایک ساتھ follow کرتا ہے اور ہر لائن کے شروع میں service کا نام لکھتا ہے۔ جب services ایک دوسرے سے بات کرتی ہوں اور واقعات کی ترتیب اہم ہو، تو یہی view درکار ہوتا ہے۔ دائرہ محدود کرنے کے لیے service کا نام دیں۔ ایسے container کے لیے --tail=100 اہم ہے جو ایک ماہ سے چل رہا ہو، کیونکہ default پوری history دکھاتا ہے اور terminal بھر دیتا ہے۔ --since 15m عموماً مطلوبہ سوال کا جواب دیتا ہے: ابھی کیے گئے restart کے دوران کیا ہوا؟

top ہر container کے اندر موجود processes کی فہرست دکھاتا ہے۔ اس سے یہ فرق واضح ہوتا ہے کہ container چل رہا ہے یا اس کے اندر موجود process چل رہا ہے۔ ls موجودہ directory سے باہر جا کر host پر موجود تمام Compose projects کو ان کی status کے ساتھ دکھاتا ہے۔ اس طرح آپ وہ stack تلاش کر سکتے ہیں جسے آپ نے تین ماہ پہلے شروع کیا تھا۔

سروس کے اندر shell حاصل کرنا

docker compose exec web sh
docker compose exec -u root web sh
docker compose run --rm web env
docker compose run --rm --no-deps web sh

exec پہلے سے چل رہے container کے اندر command چلاتا ہے۔ run اسی service definition سے نیا container شروع کرتا ہے۔ جب service اتنی دیر تک نہیں چلتی کہ اس میں exec کیا جا سکے، تو یہی طریقہ درکار ہوتا ہے۔ run کو ہمیشہ --rm کے ساتھ استعمال کریں۔ اس کے بغیر ہر invocation ایک stopped container چھوڑ دیتی ہے۔ یہ containers جمع ہوتے رہتے ہیں، یہاں تک کہ docker compose ps -a کو پڑھنا مشکل ہو جاتا ہے۔

sh کو bash سے پہلے آزمائیں۔ Alpine پر مبنی images میں bash موجود نہیں ہوتا، اس لیے failure میں exec: "bash": executable file not found in $PATH ظاہر ہوتا ہے۔ --no-deps کو run میں شامل کرنے سے service کی dependencies نظرانداز ہو جاتی ہیں۔ اس سے فوری config check کے دوران پورا database شروع نہیں ہوتا۔

run --rm web env یہ دیکھنے کا تیز ترین طریقہ ہے کہ تمام .env file، environment: block اور shell variable کو merge کرنے کے بعد service کو حقیقت میں کون سا environment ملا۔ جب کوئی value غلط ہو، تو عموماً وجہ merge order ہوتی ہے۔ Compose env files اور secrets کو کیسے resolve کرتا ہے میں بتایا گیا ہے کہ کون سا source ترجیح حاصل کرتا ہے۔

نیٹ ورکس، پورٹس، اور ناموں کی resolution

docker compose port web 80
docker compose exec web getent hosts db
docker compose config --networks

Compose ہر service کو ایک ہی project network پر رکھتا ہے، اور ہر service کا نام اس network پر DNS نام ہوتا ہے۔ web کے اندر getent hosts db چلانے سے، resolution درست ہونے پر container کا IP ظاہر ہوتا ہے، اور resolution ناکام ہونے پر کچھ بھی ظاہر نہیں ہوتا۔ اس طرح یہ دو سیکنڈ میں بتا دیتا ہے کہ آیا یہ containers ایک دوسرے کو دیکھ سکتے ہیں۔ اگر نام resolve ہو جائے لیکن connection مسترد ہو، تو db کے اندر process 0.0.0.0 کے بجائے 127.0.0.1 پر bound ہے۔ اسی لیے وہ کسی دوسرے container سے آنے والا packet قبول نہیں کرتا۔ اس ماڈل کی باقی وضاحت Compose networks اور service DNS کیسے کام کرتے ہیں میں ہے۔

port web 80 اس host address اور port کو ظاہر کرتا ہے جس پر container کا port publish کیا گیا ہے۔ اس سے اس وقت اندازہ لگانے کی ضرورت نہیں رہتی جب mapping کسی variable سے آئی ہو۔ Port publish کرنے سے Docker خود ایک firewall rule بھی بناتا ہے، اور یہ rule آپ کے rule سے پہلے لاگو ہوتا ہے۔ اس لیے جو service آپ نے private سمجھی تھی، وہ internet کے لیے کھلی ہو سکتی ہے۔ اس صورتِ حال کی وضاحت published Docker ports، ufw کو bypass کیوں کرتے ہیں میں ہے۔

والیومز اور ڈیٹا

docker compose config --volumes
docker compose cp db:/etc/postgresql/pg_hba.conf ./pg_hba.conf
docker compose down -v

config --volumes پروجیکٹ میں بیان کردہ نام زدہ والیومز کو فی سطر دکھاتا ہے۔ آپ کو اسی فہرست کا بیک اپ لینا ہوگا۔ cp شیل کھولے بغیر کسی فائل کو container میں کاپی کرتا ہے یا وہاں سے باہر لاتا ہے۔ اس کے لیے container والی جانب service:path فارم استعمال کریں۔

down -v ان نام زدہ والیومز کو containers کے ساتھ حذف کر دیتا ہے۔ ٹیسٹ stack ختم کرنے کے لیے یہ درست command ہے، لیکن ایسے کسی بھی stack کے لیے غلط ہے جس میں آپ کا اہم ڈیٹا موجود ہو، کیونکہ اس میں تصدیق کا مرحلہ نہیں ہوتا اور کارروائی واپس نہیں لی جا سکتی۔ Bind mounts اس کارروائی سے محفوظ رہتے ہیں، کیونکہ وہ host filesystem پر موجود ہوتے ہیں۔ اسی اثر انگیزی کے فرق کی وجہ سے bind mounts اور نام زدہ والیومز میں سے انتخاب سوچ سمجھ کر کرنا چاہیے۔

ڈیٹا ضائع کیے بغیر ڈسک خالی کرنے والی صفائی

docker compose down --remove-orphans
docker system df
docker image prune -a
docker builder prune

--remove-orphans ان containers کو حذف کرتا ہے جو project سے متعلق ہیں لیکن اب file میں موجود نہیں ہیں۔ service کا نام تبدیل کرنے کے بعد یہی صورت حال بنتی ہے۔ اس کے بغیر وہ containers چلتے رہتے ہیں اور docker compose ps میں نظر نہیں آتے۔

docker system df کسی بھی چیز کو حذف کرنے سے پہلے دکھاتا ہے کہ ڈسک کی جگہ کہاں استعمال ہوئی ہے۔ یہ images، containers، local volumes اور build cache کو الگ الگ دکھاتا ہے، اور ہر ایک کے لیے reclaimable مقدار بھی بتاتا ہے۔ image prune -a ایسی تمام images ہٹا دیتا ہے جن کی طرف کوئی tag اشارہ نہیں کرتا۔ جس box نے کسی بڑی image کے کئی versions pull کیے ہوں، وہاں عموماً اسی سے سب سے زیادہ جگہ خالی ہوتی ہے۔ builder prune build cache صاف کرتا ہے، جو اپنے images بنانے والے ہر server پر خاموشی سے بڑھتا رہتا ہے۔

ان میں سے کوئی بھی named volume کو متاثر نہیں کرتا۔ صرف docker volume prune اور docker compose down -v ایسا کرتے ہیں۔

فائل کسی مسئلے کا باعث بننے سے پہلے اس کی جانچ

docker compose config --quiet
docker compose config --services
docker compose --dry-run up -d

config --quiet کامیابی کی صورت میں فائل کی توثیق کرتا ہے اور کچھ پرنٹ نہیں کرتا، اس لیے اسے تعیناتی سے پہلے کے مرحلے یا git hook میں شامل کرنا مناسب ہے۔ سادہ config مکمل طور پر ضم شدہ اور interpolated فائل پرنٹ کرتا ہے۔ اس سے آپ تصدیق کر سکتے ہیں کہ متغیر کی قدر حل ہوئی ہے اور override فائل آپ کی توقع کے مطابق شامل ہوئی ہے۔ غیر متعین متغیر وہاں خالی قدر کے طور پر ظاہر ہوتا ہے، اور اس کے ساتھ انتباہ The "X" variable is not set. Defaulting to a blank string. ہوتا ہے۔

--dry-run subcommand flag کے بجائے global flag ہے، اس لیے اسے up سے پہلے لکھا جاتا ہے۔ یہ وہ تمام کارروائیاں پرنٹ کرتا ہے جو Compose کرے گا، لیکن کوئی تبدیلی نہیں کرتا۔ اہم stack پر down چلانے سے پہلے صرف تیس سیکنڈ صرف کرنا فائدہ مند ہے۔

فائلوں، پروفائلز، اور پروجیکٹس کے ساتھ کام کرنا

docker compose -f compose.yaml -f compose.prod.yaml up -d
docker compose --profile debug up -d
docker compose -p staging up -d

متعدد -f flags ترتیب کے مطابق merge ہوتے ہیں، اور بعد والی فائلیں key کی سطح پر پہلے والی فائلوں کو override کرتی ہیں۔ ایک چھوٹی production override کے ساتھ ایک base فائل برقرار رکھنے کا یہ معیاری طریقہ ہے، تاہم lists اور maps کے لیے قواعد مختلف ہیں۔ اس لیے غیر متوقع نتیجے کی troubleshooting سے پہلے Compose متعدد فائلوں کو کیسے merge کرتا ہے پڑھیں۔

--profile اس profile کے ساتھ tagged services کو untagged services کے ساتھ شروع کرتا ہے۔ اس سے debug tooling عام up سے الگ رہتی ہے۔ -p project name مقرر کرتا ہے، اس لیے ایک ہی stack کی دو copies الگ networks اور الگ volume names کے ساتھ بیک وقت چل سکتی ہیں۔ reboot کے بعد stack کو دوبارہ بحال کرنا ایسا command نہیں ہے جسے آپ خود type کریں۔ اس کے لیے ایک unit ہوتی ہے جو یہ کام خود کرتی ہے۔ اس کی تفصیل boot پر Compose stacks شروع کرنا میں ہے۔

FAQ

docker-compose کی جگہ ہائفن کیوں استعمال نہیں ہوتا؟

Compose V2 کو docker compose کے طور پر، یعنی درمیان میں space کے ساتھ، چلایا جاتا ہے۔ یہ Docker Engine کے ساتھ شامل plugin ہے، جبکہ V1 Python tool موجودہ packages کے ذریعے مزید install نہیں ہوتا۔ اگر space والی شکل کوئی output نہیں دیتی تو اپنی distribution کے لیے docker-compose-plugin package install کریں۔ پرانے scripts میں alias شامل کرنے کے بجائے space والی شکل استعمال کریں، کیونکہ V2 میں وہ flags موجود ہیں جو V1 میں نہیں تھے۔

docker compose restart میری config کی تبدیلی کیوں نہیں اپناتا؟

restart موجودہ container کو اسی configuration کے ساتھ stop اور start کرتا ہے جس کے ساتھ وہ بنایا گیا تھا، اور یہ compose.yaml کو دوبارہ نہیں پڑھتا۔ Environment variables، ports، volumes یا image tag میں کسی بھی تبدیلی کے لیے docker compose up -d درکار ہے۔ یہ ہر service کا اس کے running container سے موازنہ کرتا ہے اور مختلف ہونے والی services کو دوبارہ بناتا ہے۔ جب آپ چاہتے ہیں کہ file میں کوئی تبدیلی نہ ہونے کے باوجود replacement ہو، تو --force-recreate شامل کریں۔

میں service کو نئی image پر کیسے update کروں؟

پہلے docker compose pull چلائیں، پھر docker compose up -d۔ Pull اس file میں موجود ہر tag کے لیے موجودہ image حاصل کرتا ہے، اور up -d ایسی service کو دوبارہ بناتا ہے جس کی image ID اس کے container سے مطابقت نہ رکھتی ہو۔ صرف up -d چلانے سے disk پر پہلے سے موجود image دوبارہ استعمال ہوتی ہے۔ اسی وجہ سے latest پر pinned stack کئی ماہ پرانی build پر چلتی رہ سکتی ہے، اور کوئی error بھی ظاہر نہیں ہوتا۔

Live server پر کون سے cleanup commands محفوظ ہیں؟

docker system df، docker image prune -a اور docker builder prune صرف images اور cache ہٹاتے ہیں، اس لیے running services کام کرتی رہتی ہیں اور named volumes متاثر نہیں ہوتے۔ خطرناک جوڑا docker compose down -v اور docker volume prune ہے، جو بغیر prompt کے named volumes حذف کر دیتا ہے۔ پہلے docker compose config --volumes چلائیں تاکہ معلوم ہو کہ کیا خطرے میں ہے۔

کیا میں پورا stack شروع کیے بغیر ایک command چلا سکتا ہوں؟

ہاں۔ docker compose run --rm --no-deps web sh، web service definition سے ایک single container شروع کرتا ہے، اس کی dependencies کو نظرانداز کرتا ہے، اور آپ کے exit کرنے پر container حذف کر دیتا ہے۔ جب container پہلے سے running ہو تو اس کے بجائے exec استعمال کریں، کیونکہ exec live process میں شامل ہوتا ہے اور آپ کو service کی اصل موجودہ حالت دکھاتا ہے۔