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

مختصر جواب

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

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

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

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

docker compose stop
docker compose ps -a

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

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

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 کے لیے کچھ بھی output نہیں کرتا، اور <project>_default network موجود نہیں رہتا۔ project name عموماً directory name سے حاصل ہوتا ہے، جب تک کہ آپ Compose file میں name: set نہ کریں یا -p pass نہ کریں۔ 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 حذف کر دیتا ہے؟

نہیں۔ top level volumes key کے تحت اعلان کردہ named volume، down کے بعد بھی برقرار رہتا ہے اور اس container کے بعد بھی موجود رہتا ہے جس کے ساتھ وہ attach تھا۔ اس 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:

اسے start کریں اور ایک 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 کو destroy کریں اور volume کو check کریں۔

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 ایک مختلف container ہے اور اس کی ID بھی مختلف ہے، لیکن وہ اسی volume کے ساتھ attach ہے۔ اگر آپ مکمل تصویر دیکھنا چاہتے ہیں تو Compose basics guide میں named volumes، bind mounts، اور host پر ہر ایک کے اصل مقام کی وضاحت موجود ہے۔

down -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 ہوتا ہے جو اس project سے باہر ہے، اس لیے Compose اسے کبھی حذف نہیں کرتا۔ اگر down -v چلانے سے پہلے آپ نے named volume کو Compose فائل سے حذف کر دیا ہو تو وہ اب declared نہیں رہتا۔ Compose اسے حذف کرنے سے واقف نہیں ہوتا، اس لیے وہ docker volume prune کے لیے orphan کے طور پر باقی رہتا ہے۔

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

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

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

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

docker compose up -d --force-recreate

یہ ہر container کو stop اور remove کرتا ہے، پھر اسی definition سے نیا container بناتا ہے۔ Mounted config file میں edit کے بعد، یا جب container ایسی state میں چلا جائے جس کی وجہ واضح نہ ہو، اسے استعمال کریں۔ 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 کیا، لیکن version اب بھی پرانا ہے" ایک عام شکایت ہے۔

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

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

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

ہر Compose verb اسی تقسیم کے مطابق کام کرتا ہے۔ stop اور start container برقرار رکھتے ہیں۔ down اور up container کو تبدیل کرتے ہیں اور volume برقرار رکھتے ہیں۔ down -v واحد معمول کی command ہے جو state حذف کرتی ہے، اسی لیے اسے explicit flag درکار ہوتا ہے۔ اسے کسی حقیقی system پر چلانے سے پہلے تصدیق کریں کہ آپ کے پاس 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 ایسی directory میں چل رہا ہے جہاں نہ 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 کا حوالہ دے رہا ہے، جس میں stopped container بھی شامل ہے۔ پہلے docker compose down چلائیں، پھر volume ہٹائیں، یا براہِ راست down -v استعمال کریں۔ بڑے project میں متعدد services والا Compose stack دکھاتا ہے کہ ایک project میں کتنے volumes جمع ہو سکتے ہیں۔

FAQ

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

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

جس 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 میں declare کیے گئے 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 کو چلتا رہنے دیتا ہے اور وہی values استعمال ہوتی ہیں جو startup کے وقت پڑھی گئی تھیں۔ file دوبارہ پڑھنے والا نیا container بنانے کے لیے docker compose up -d --force-recreate چلائیں۔

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

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