Docker Compose میں down اور stop کا فرق کیا ہے؟

مختصر جواب

docker compose stop کنٹینرز کو روکتا ہے اور انہیں ڈسک پر برقرار رکھتا ہے۔ docker compose down کنٹینرز کو روکتا ہے، پھر ان کنٹینرز اور اس نیٹ ورک کو حذف کر دیتا ہے جسے Compose نے پروجیکٹ کے لیے بنایا تھا۔ دونوں میں سے کوئی بھی کمانڈ named volume کو متاثر نہیں کرتی۔ آپ کا database صرف اس وقت حذف ہوتا ہے جب آپ -v شامل کرتے ہیں، جیسا کہ docker compose down -v میں ہے۔ یہ Compose فائل کے volumes سیکشن میں اعلان کردہ named volumes کو حذف کرتا ہے۔

یہی پورا فرق ایک پیراگراف میں ہے۔ اس گائیڈ کے باقی حصے میں Postgres volume کے ذریعے ثابت کیا گیا ہے کہ وہ down کے بعد برقرار رہتا ہے اور down -v کے تحت حذف ہو جاتا ہے۔ اس میں وہ دو صورتیں بھی بیان کی گئی ہیں جن میں آپ کو --force-recreate درکار ہوتا ہے۔

docker compose stop: کنٹینرز برقرار رہتے ہیں

stop ہر کنٹینر کے مرکزی عمل کو SIGTERM بھیجتا ہے، انتظار کرتا ہے، پھر اگر عمل اب بھی چل رہا ہو تو SIGKILL بھیجتا ہے۔ پہلے سے مقررہ انتظار 10 سیکنڈ ہے، اور -t اسے تبدیل کرتا ہے۔ کچھ بھی حذف نہیں ہوتا۔ کنٹینر کی ID، اس کی writable layer، اس کی IP reservation، اور اس کے logs برقرار رہتے ہیں۔

docker compose stop
docker compose ps -a

docker compose ps اکیلے صرف چلنے والے کنٹینرز دکھاتا ہے، اس لیے stop کے بعد یہ ایک خالی جدول دکھاتا ہے اور لوگ سمجھتے ہیں کہ کنٹینرز ختم ہو گئے ہیں۔ ps -a رکے ہوئے کنٹینرز بھی شامل کرتا ہے، اور وہیں ہر سروس کے ساتھ Exited (0) نظر آتا ہے۔ انہیں docker compose start کے ذریعے دوبارہ شروع کریں؛ یہ بالکل وہی کنٹینرز دوبارہ استعمال کرتا ہے۔

چونکہ کنٹینرز اب بھی موجود ہیں، اس لیے volume کے باہر ان کے اندر لکھی گئی ہر چیز برقرار رہتی ہے۔ اس میں وہ package بھی شامل ہے جسے آپ نے docker compose exec کے ذریعے دستی طور پر install کیا تھا، اور وہ config file بھی جس میں آپ نے کنٹینر کے اندر ترمیم کی تھی۔ debugging کے دوران stop کو ترجیح دینے کی عملی وجہ یہی ہے: آپ اسی حالت میں دوبارہ شروع کر سکتے ہیں۔

docker compose down: کنٹینرز اور نیٹ ورکس حذف کر دیے جاتے ہیں

down کنٹینرز کو روکتا ہے اور پھر انہیں حذف کر دیتا ہے۔ اس کے ساتھ وہ default network بھی حذف ہو جاتا ہے جسے Compose نے project کے لیے بنایا تھا۔ Docker کی documentation کے مطابق یہ up کے ذریعے بنائے گئے containers، networks، volumes اور images کو روکنے اور حذف کرنے کا کام کرتا ہے، لیکن volumes اور images سے متعلق کارروائی صرف اس وقت ہوتی ہے جب آپ -v اور --rmi استعمال کر کے اس کی درخواست کریں۔

docker compose down
docker compose ps -a
docker network ls

down کے بعد ps -a project کے لیے کچھ بھی print نہیں کرتا، اور <project>_default network بھی موجود نہیں رہتا۔ Project name، directory name سے حاصل ہوتا ہے، جب تک کہ آپ Compose file میں name: مقرر نہ کریں یا -p فراہم نہ کریں۔ Container کی writable layer میں کی گئی ہر تبدیلی اب recover نہیں کی جا سکتی۔ اس لیے down کو ایسی command سمجھیں جو container کو ضائع کر دیتی ہے، جبکہ volumes میں محفوظ کیا گیا data برقرار رہتا ہے۔

اگر اسے غلط directory میں چلایا جائے تو no configuration file provided: not found موصول ہوتا ہے۔ Compose کو معلوم نہیں ہوتا کہ آپ کا مطلوبہ project کون سا ہے، اس لیے یہ command پر عمل کرنے سے انکار کر دیتا ہے۔ اگر آپ project folder میں موجود نہیں ہیں تو docker compose -f /srv/myapp/compose.yaml down استعمال کریں۔

کیا docker compose down میرے volumes حذف کرتا ہے؟

نہیں۔ اوپری سطح کی volumes key کے تحت بیان کیا گیا named volume، down کے ختم ہونے کے بعد بھی موجود رہتا ہے، اور اس container کے ختم ہونے کے بعد بھی موجود رہتا ہے جس کے ساتھ یہ منسلک تھا۔ اس command کے بارے میں یہ سب سے عام خدشہ ہے، اور Compose v2 میں اس کا جواب مستقل ہے۔

ایک ایسا stack تیار کریں جسے آپ جانچ کے لیے استعمال کر سکیں۔ خالی directory voltest میں compose.yaml کے نام سے یہ مواد رکھیں۔

services:
  db:
    image: postgres:16.4
    restart: unless-stopped
    environment:
      POSTGRES_PASSWORD: example
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:

اسے شروع کریں اور ایسی row لکھیں جسے آپ بعد میں پہچان سکیں۔

docker compose up -d
sleep 10
docker compose exec -T db psql -U postgres -c "create table marker (note text);"
docker compose exec -T db psql -U postgres -c "insert into marker values ('survived');"

اب container کو ختم کریں اور volume کو چیک کریں۔

docker compose down
docker volume ls

Output میں اب بھی voltest_pgdata درج ہے۔ container ختم ہو گیا ہے، لیکن data موجود ہے۔ stack کو دوبارہ شروع کریں اور row پڑھیں۔

docker compose up -d
sleep 10
docker compose exec -T db psql -U postgres -c "select * from marker;"

آپ کو survived پر مشتمل ایک row ملے گی۔ نیا container ایک مختلف ID والا مختلف container ہے، جو اسی volume کے ساتھ منسلک ہے۔ اگر آپ مکمل تصویر دیکھنا چاہتے ہیں تو Compose basics guide میں named volumes کا bind mounts کے ساتھ تقابل اور یہ وضاحت شامل ہے کہ ہر volume host پر حقیقت میں کہاں موجود ہوتا ہے۔

-v بالکل کیا تباہ کرتا ہے

-v (طویل صورت --volumes) Compose فائل کے volumes حصے میں اعلان کردہ نام زد volumes کے علاوہ containers سے منسلک anonymous volumes بھی حذف کرتا ہے۔ اسے اسی stack پر چلائیں۔

docker compose down -v
docker volume ls

voltest_pgdata اب فہرست میں موجود نہیں ہے۔ stack دوبارہ شروع کریں۔ Postgres entrypoint کو خالی data directory ملتی ہے، اس لیے وہ نیا cluster initialize کرتا ہے۔ container log میں یہ بات واضح الفاظ میں درج ہوتی ہے۔

The files belonging to this database system will be owned by user "postgres".
PostgreSQL init process complete; ready for start up.

کئی ماہ سے چلنے والے stack پر یہ block نظر آنے کا مطلب ہے کہ volume حذف ہو چکا ہے۔ آپ کی marker table ختم ہو گئی ہے، اور واپسی کا واحد طریقہ backup ہے۔

کچھ storage -v کے ذریعے کبھی حذف نہیں ہوتی۔ bind mount، host path ہوتا ہے، اس لیے Docker صرف اسے unmount کرتا ہے اور آپ کی files اپنی جگہ موجود رہتی ہیں۔ external: true سے نشان زد volume کو کسی بیرونی چیز سے متعلق declared کیا گیا ہے، اس لیے Compose اسے کبھی حذف نہیں کرتا۔ اگر آپ down -v چلانے سے پہلے named volume کو Compose فائل سے حذف کر دیں، تو وہ اب declared نہیں رہتا۔ Compose اسے حذف کرنا نہیں جانتا، اس لیے وہ docker volume prune کے طور پر پیچھے رہ جاتا ہے۔

یہ آخری صورت refactor کے دوران لوگوں کو مشکل میں ڈالتی ہے۔ فائل سے service اور اس کا volume حذف کریں، پھر down -v چلائیں، تو volume محفوظ رہتا ہے کیونکہ فائل میں اب اس کا ذکر نہیں ہوتا۔ فائل میں ترمیم کرنے کے بعد نہیں، بلکہ اس سے پہلے down -v چلائیں۔

جب آپ کو واقعی --force-recreate درکار ہو

docker compose up -d ہر بار تمام چیزیں دوبارہ نہیں بناتا۔ Compose ہر سروس کی حل شدہ configuration کا hash، container پر label کے طور پر محفوظ کرتا ہے۔ اگر hash اور image ID دونوں مماثل ہوں تو container میں کوئی تبدیلی نہیں کی جاتی، اور آپ کو Container voltest-db-1 Running کے بجائے Recreated ملتا ہے۔ عموماً یہی مطلوبہ رویہ ہے، کیونکہ اس سے up -d کو بار بار محفوظ طریقے سے چلایا جا سکتا ہے۔

اسی وجہ سے بعض ترامیم کا کوئی اثر دکھائی نہیں دیتا۔ Compose ان فائلوں کے مواد کے بجائے resolved service definition کا hash بناتا ہے جن کی طرف یہ definition اشارہ کرتی ہے۔ اگر container میں mount کی گئی config file کو startup پر صرف ایک بار پڑھا جاتا ہے، تو اسے edit کرنے سے recreate شروع نہیں ہوتا، کیونکہ mount path تبدیل نہیں ہوا۔ سروس چلتی رہتی ہے اور boot کے وقت پڑھی گئی values استعمال کرتی ہے۔

docker compose up -d --force-recreate

یہ ہر container کو stop کرکے remove کرتا ہے اور اسی definition سے نیا container بناتا ہے۔ اسے mounted config file میں ترمیم کے بعد استعمال کریں، اور اس وقت بھی جب کوئی container ایسی حالت میں پہنچ جائے جس کی آپ وضاحت نہ کر سکیں۔ Volumes میں کوئی تبدیلی نہیں کی جاتی، اس لیے force recreate کے بعد database برقرار رہتا ہے۔ اسی tag پر نئی image حاصل کرنے کے لیے pull بھی درکار ہے۔

docker compose pull
docker compose up -d

pull نئی image ID حاصل کرتا ہے، اور up -d پھر running container سے مختلف image ID دیکھ کر خود اسے recreate کر دیتا ہے۔ pull کے بغیر --force-recreate شامل کرنے سے وہی پرانی image استعمال کرتے ہوئے نیا container بنتا ہے۔ اسی لیے یہ شکایت عام ہے کہ "میں نے force recreate کیا، لیکن ورژن اب بھی پرانا ہے۔"

docker compose restart ان میں سے کچھ بھی نہیں کرتا۔ یہ موجودہ containers کو restart کرتا ہے اور Compose file کو دوبارہ پڑھتا ہی نہیں، اس لیے تبدیل شدہ environment variable یا port mapping لاگو نہیں ہوگی۔ اگر آپ نے file edit کی ہے تو up -d استعمال کریں۔

ذہنی ماڈل جسے برقرار رکھنا ہے

Containers قابلِ تبدیلی ہوتے ہیں۔ ایک container میں ایک process اور ایک پتلی writable layer شامل ہوتی ہے، اور Compose تقریباً ایک second میں file سے اسی جیسا container دوبارہ بنا سکتا ہے۔ Volumes قابلِ تبدیلی نہیں ہوتے، کیونکہ state کی واحد copy ان میں ہوتی ہے، جسے آپ کی repository میں موجود کوئی file دوبارہ تیار نہیں کر سکتی۔

ہر Compose verb اسی تقسیم کے مطابق کام کرتا ہے۔ stop اور start container برقرار رکھتے ہیں۔ down اور up container کو تبدیل کرتے ہیں اور volume برقرار رکھتے ہیں۔ down -v واحد معمول کی command ہے جو state کو حذف کرتی ہے، اسی لیے اس کے لیے explicit flag درکار ہوتا ہے۔ اسے کسی حقیقی environment پر چلانے سے پہلے تصدیق کریں کہ آپ کے پاس backup موجود ہے اور آپ اسے کم از کم ایک بار restore کر چکے ہیں۔

یہی منطق secrets پر بھی لاگو ہوتی ہے۔ POSTGRES_PASSWORD کے ذریعے set کیا گیا password صرف اس وقت پڑھا جاتا ہے جب database پہلی بار initialise ہوتا ہے، اس لیے environment file میں اسے تبدیل کرنے اور up -d چلانے سے آپ کو password authentication failed for user "postgres" ملتا ہے۔ container نیا ہوتا ہے اور volume پرانا، اور پرانے volume میں اب بھی پرانا password موجود ہوتا ہے۔ Compose env files اور secrets کو کیسے resolve کرتا ہے وضاحت کرتا ہے کہ ایک ہی variable دو بار set ہونے پر کون سی layer ترجیح حاصل کرتی ہے۔

ناکامی کی صورتیں اور ظاہر ہونے والے پیغامات

no configuration file provided: not found کا مطلب ہے کہ Compose ایسی ڈائریکٹری میں چل رہا ہے جس میں نہ compose.yaml موجود ہے اور نہ docker-compose.yml۔ مکمل path کے ساتھ -f فراہم کریں۔

down پر network voltest_default has active endpoints کا مطلب ہے کہ اس project سے باہر کا کوئی container، project network سے منسلک ہے۔ عموماً یہ container ہاتھ سے docker run --network کے ذریعے شروع کیا گیا ہوتا ہے۔ اس container کو ہٹائیں، پھر دوبارہ down چلائیں۔

Found orphan containers ([voltest-old-1]) for this project اس وقت ظاہر ہوتا ہے جب آپ کسی service کا نام تبدیل یا اسے حذف کرتے ہیں۔ پرانا container اب بھی project label رکھتا ہے۔ docker compose down --remove-orphans انہیں صاف کر دیتا ہے، اور اسے صحت مند stack پر چلانا محفوظ ہے۔

دستی طور پر docker volume rm چلانے پر Error response from daemon: remove voltest_pgdata: volume is in use کا مطلب ہے کہ کوئی container اب بھی اس volume کا حوالہ دے رہا ہے، جس میں بند container بھی شامل ہے۔ پہلے docker compose down چلائیں، پھر volume ہٹائیں، یا صرف down -v استعمال کریں۔ بڑے project میں multi service Compose stack سے معلوم ہوتا ہے کہ ایک project میں کتنے volumes جمع ہو سکتے ہیں۔

FAQ

کیا docker compose down میرا database حذف کر دیتا ہے؟

اگر database کسی named volume یا bind mount میں موجود ہو تو نہیں۔ down containers اور project network کو ہٹا دیتا ہے، جبکہ volume اپنی data سمیت disk پر برقرار رہتا ہے۔ اگلا docker compose up -d اسی volume کے ساتھ نیا container منسلک کرتا ہے، اور data موجود رہتی ہے۔ صرف docker compose down -v named volumes کو ہٹاتا ہے، اور وہ بھی صرف جو Compose file کے volumes section میں بیان کیے گئے ہوں۔

جس container کو میں دوبارہ استعمال کرنا چاہتا ہوں، اس کے لیے stop اور down میں کیا فرق ہے؟

stop container کو برقرار رکھتا ہے، اس لیے docker compose start آپ کو اسی container میں واپس لے جاتا ہے، جس میں وہی writable layer ہوتی ہے۔ آپ نے container کے اندر دستی طور پر جو کچھ install یا edit کیا ہو، وہ موجود رہتا ہے۔ down container کو حذف کر دیتا ہے، اس لیے اگلا up -d image سے نیا container بناتا ہے اور وہ دستی تبدیلیاں ضائع ہو جاتی ہیں۔ Debugging کے دوران stop استعمال کریں۔

Compose project کی بنائی ہوئی ہر چیز کیسے ہٹاؤں؟

docker compose down -v --rmi all --remove-orphans containers، project network، file میں بیان کردہ named volumes، services کے استعمال کردہ images، اور project name کے label والا ہر container ہٹا دیتا ہے۔ یہ bind mounts یا external: true سے نشان زد volumes کو متاثر نہیں کرتا۔ چلانے سے پہلے docker volume ls کے ذریعے دیکھ لیں کہ کیا کچھ ضائع ہونے والا ہے۔

mounted config file میں کی گئی تبدیلی کو میرا container کیوں نظرانداز کرتا ہے؟

Compose اس بات کا فیصلہ resolved service definition کے hash کا موازنہ کرکے کرتا ہے کہ container کو دوبارہ بنانا ہے یا نہیں، اور اس hash میں mounted file کا content شامل نہیں ہوتا۔ Path تبدیل نہیں ہوا، اس لیے Compose container کو اسی طرح چلاتا رہتا ہے اور startup کے وقت پڑھی گئی values استعمال کرتا ہے۔ فائل دوبارہ پڑھنے والا نیا container بنانے کے لیے docker compose up -d --force-recreate چلائیں۔

POSTGRES_PASSWORD تبدیل کرنے کے بعد نیا POSTGRES_PASSWORD کیوں کام نہیں کر رہا؟

Postgres image POSTGRES_PASSWORD کو صرف اس وقت پڑھتا ہے جب وہ خالی data directory کو initialize کرتا ہے۔ آپ کے volume میں پہلے سے initialized cluster موجود ہے، اس لیے variable نظرانداز ہو جاتا ہے اور پرانا password لاگو رہتا ہے۔ آپ کو password authentication failed for user "postgres" نظر آئے گا۔ چلتے ہوئے database کے اندر ALTER USER کے ذریعے password تبدیل کریں، یا data ضائع ہونے کو قبول کرکے docker compose down -v کے ساتھ دوبارہ شروع کریں۔