Docker Compose stop vs down: తేడా ఏమిటి?

సంక్షిప్త సమాధానం

docker compose stop కంటైనర్‌లను ఆపి, వాటిని డిస్క్‌లో ఉంచుతుంది. docker compose down కంటైనర్‌లను ఆపిన తర్వాత, వాటితో పాటు ప్రాజెక్ట్ కోసం Compose సృష్టించిన కంటైనర్‌లు మరియు నెట్‌వర్క్‌ను తొలగిస్తుంది. ఈ రెండు కమాండ్‌లలో ఏదీ named volume‌ను ప్రభావితం చేయదు. -v జోడించినప్పుడే మీ database తొలగిపోతుంది. ఉదాహరణకు docker compose down -vలో, Compose file‌లోని volumes విభాగంలో ప్రకటించిన named volume‌లను ఇది తొలగిస్తుంది.

మొత్తం తేడా ఇదే. ఈ guideలో Postgres volume‌ను down తర్వాత కూడా మిగిలి ఉండటాన్ని, down -v అమలు చేసినప్పుడు తొలగించబడటాన్ని మీరు పరిశీలించవచ్చు. అలాగే --force-recreate అవసరమయ్యే రెండు సందర్భాలను ఇది వివరిస్తుంది.

docker compose stop: containers కొనసాగుతూనే ఉంటాయి

stop ప్రతి containerలోని ప్రధాన processకు SIGTERM పంపుతుంది, కొంతసేపు వేచి ఉంటుంది. ఆ process ఇంకా నడుస్తుంటే SIGKILL పంపుతుంది. డిఫాల్ట్ వేచి ఉండే సమయం 10 seconds. -t ఆ సమయాన్ని మారుస్తుంది. ఏదీ తొలగించబడదు. container తన ID, writable layer, IP reservation మరియు logsను అలాగే ఉంచుకుంటుంది.

docker compose stop
docker compose ps -a

docker compose ps స్వయంగా నడుస్తున్న containersను మాత్రమే చూపిస్తుంది. అందువల్ల stop తర్వాత అది ఖాళీ పట్టికను చూపిస్తుంది. దీంతో containers తొలగిపోయాయని అనుకుంటారు. ps -a ఆపివేసిన containersను కూడా చూపిస్తుంది. అక్కడ ప్రతి service పక్కన Exited (0) కనిపిస్తుంది. docker compose startతో వాటిని మళ్లీ ప్రారంభించండి. ఇది ఖచ్చితమైన అదే containersను తిరిగి ఉపయోగిస్తుంది.

containers ఇంకా ఉన్నందున, volume వెలుపల వాటిలో వ్రాయబడిన ఏదైనా అలాగే ఉంటుంది. ఇందులో docker compose execతో చేతితో install చేసిన package, అలాగే containerలో సవరించిన config file కూడా ఉన్నాయి. Debugging సమయంలో stopను ఎంచుకోవడానికి ఇదే ప్రధాన కారణం: అదే స్థితిలో మళ్లీ ప్రారంభించవచ్చు.

docker compose down: కంటైనర్లు మరియు నెట్‌వర్క్‌లు తొలగించబడతాయి

down కంటైనర్‌లను ఆపి, వాటిని తొలగిస్తుంది. ప్రాజెక్ట్ కోసం Compose సృష్టించిన default network కూడా తొలగించబడుతుంది. Docker documentation ప్రకారం, ఇది up సృష్టించిన కంటైనర్‌లు, నెట్‌వర్క్‌లు, వాల్యూమ్‌లు మరియు ఇమేజ్‌లను ఆపి తొలగిస్తుంది. అయితే వాల్యూమ్‌లు మరియు ఇమేజ్‌ల తొలగింపు కోసం -v మరియు --rmi ఎంపికలను స్పష్టంగా ఇవ్వాలి.

docker compose down
docker compose ps -a
docker network ls

down తర్వాత, ఆ ప్రాజెక్ట్‌కు ps -a ఏమీ చూపించదు. <project>_default network కూడా ఉండదు. మీరు name: ను Compose file లో సెట్ చేయకపోతే లేదా -p ను పంపకపోతే, project name directory name నుంచి వస్తుంది. కంటైనర్‌లోని writable layer లో మీరు చేసిన ప్రతి మార్పు ఇక తిరిగి పొందలేరు. అందువల్ల down ను కంటైనర్‌ను తొలగించి, volumes లో ఉంచిన డేటాను మాత్రమే నిలుపుకునే commandగా పరిగణించండి.

తప్పు directoryలో దీన్ని అమలు చేస్తే no configuration file provided: not found వస్తుంది. మీరు ఉద్దేశించిన project ఏదో Composeకు తెలియదు. అందువల్ల అది అమలును నిరాకరిస్తుంది. మీరు project folderలో లేకపోతే docker compose -f /srv/myapp/compose.yaml down ఉపయోగించండి.

docker compose down నా volumes‌ను తొలగిస్తుందా?

లేదు. టాప్-లెవల్ volumes కీ కింద ప్రకటించిన named volume, down కంటే ఎక్కువ కాలం ఉంటుంది. అది జతచేయబడిన container కంటే కూడా ఎక్కువ కాలం ఉంటుంది. ఈ command గురించి సాధారణంగా కలిగే భయం ఇదే. Compose v2లో కూడా సమాధానం మారదు.

మీరు పరీక్షించగల stack‌ను సిద్ధం చేయండి. ఖాళీగా ఉన్న voltest అనే directoryలో 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

అవుట్‌పుట్‌లో 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 ప్రాథమికాల గైడ్ named volumesను bind mountsతో పోల్చి, ప్రతి దాని data 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‌ను ప్రారంభిస్తుంది. 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 ఈ project‌కు బయట ఉన్నదిగా ప్రకటించబడుతుంది. అందువల్ల Compose దాన్ని ఎప్పుడూ తొలగించదు. down -v అమలు చేయడానికి ముందు Compose file నుంచి తొలగించిన named volume ఇక ప్రకటించబడదు. కాబట్టి Compose దాన్ని తొలగించాల్సిందిగా గుర్తించదు. అది docker volume prune కోసం orphan‌గా మిగిలిపోతుంది.

refactor సమయంలో చివరి సందర్భం వల్ల చాలామంది ఇబ్బందిపడతారు. file నుంచి service మరియు దాని volume‌ను తొలగించి down -v అమలు చేస్తే, file‌లో దాని ప్రస్తావన లేకపోవడం వల్ల volume మిగిలిపోతుంది. file‌ను సవరించే ముందు down -v అమలు చేయండి, తర్వాత కాదు.

మీరు నిజంగా --force-recreate అవసరమైనప్పుడు

docker compose up -d ప్రతి సారి మొత్తం వ్యవస్థను మళ్లీ నిర్మించదు. Compose ప్రతి service యొక్క పరిష్కరించిన configuration యొక్క hash‌ను container‌పై label‌గా నిల్వ చేస్తుంది. ఆ hash సరిపోతే, image ID కూడా సరిపోతే, container‌ను అలాగే ఉంచుతుంది. అప్పుడు మీకు Container voltest-db-1 Running బదులుగా Recreated లభిస్తుంది. సాధారణంగా మీకు కావలసిన ప్రవర్తన ఇదే, ఎందుకంటే up -d ను పదేపదే సురక్షితంగా అమలు చేయవచ్చు.

కొన్ని సవరణలు ఎలాంటి ప్రభావం చూపనట్లుగా కనిపించడానికి ఇదే కారణం. Compose, service definition సూచించే ఫైళ్లలోని విషయాలను కాకుండా, పరిష్కరించిన service definition‌ను hash చేస్తుంది. container‌లో mount చేసిన config file‌ను ప్రారంభ సమయంలో ఒక్కసారి మాత్రమే చదివితే, దాన్ని సవరించినప్పుడు recreate జరగదు, ఎందుకంటే mount path మారలేదు. Service ప్రారంభ సమయంలో చదివిన విలువలతోనే నడుస్తుంది.

docker compose up -d --force-recreate

ఇది ప్రతి container‌ను ఆపి తొలగించి, అదే definition ఆధారంగా కొత్తదాన్ని సృష్టిస్తుంది. mount చేసిన config file‌ను సవరించిన తర్వాత, అలాగే container‌ యొక్క స్థితిలో వివరించలేని మార్పు వచ్చినప్పుడు దీన్ని ఉపయోగించండి. Volumes‌కు ఎలాంటి మార్పు ఉండదు. అందువల్ల force recreate చేసినా database నిలిచి ఉంటుంది. అదే tag‌తో ఉన్న కొత్త image‌ను పొందాలంటే pull కూడా అవసరం.

docker compose pull
docker compose up -d

pull కొత్త image IDను పొందుతుంది. తర్వాత up -d నడుస్తున్న container‌లోని image ID భిన్నంగా ఉందని గుర్తించి, స్వయంగా దాన్ని recreate చేస్తుంది. pull లేకుండా --force-recreate జోడిస్తే, అదే పాత image‌ నుంచి కొత్త container మాత్రమే సృష్టించబడుతుంది. అందుకే "నేను force recreate చేశాను, అయినా ఇది పాత version‌గానే ఉంది" అనే ఫిర్యాదు చాలా సాధారణం.

docker compose restart వీటిలో ఏదీ చేయదు. ఇది ఇప్పటికే ఉన్న container‌లను restart చేస్తుంది. Compose file‌ను మళ్లీ చదవదు. అందువల్ల మార్చిన environment variable లేదా మార్చిన port mapping అమలులోకి రాదు. మీరు file‌ను సవరించినట్లయితే, up -d ఉపయోగించండి.

గుర్తుంచుకోవాల్సిన మానసిక నమూనా

Containers ను భర్తీ చేయవచ్చు. Container అనేది ఒక process మరియు రాయగలిగే పలుచని layer కలయిక. Compose file నుంచి సుమారు ఒక సెకనులో అదే విధమైన container ను మళ్లీ నిర్మించగలదు. Volumes ను భర్తీ చేయలేము. ఎందుకంటే repository లోని ఏ file కూడా తిరిగి రూపొందించలేని state యొక్క ఏకైక ప్రతిని అవి కలిగి ఉంటాయి.

ప్రతి Compose verb ఈ విభజనకు అనుగుణంగా పనిచేస్తుంది. stop మరియు start container ను అలాగే ఉంచుతాయి. down మరియు up container ను భర్తీ చేసి volume ను అలాగే ఉంచుతాయి. state ను తొలగించే సాధారణ command down -v మాత్రమే. అందుకే దీనికి explicit flag అవసరం. వాస్తవ వ్యవస్థపై దీన్ని type చేయడానికి ముందు, మీరు backup తీసుకున్నారని మరియు దాన్ని కనీసం ఒక్కసారి restore చేసి నిర్ధారించుకున్నారని ధృవీకరించండి.

ఇదే తర్కం secrets కు కూడా వర్తిస్తుంది. POSTGRES_PASSWORD ద్వారా సెట్ చేసిన password ను database మొదట initialise అయ్యే సమయంలో మాత్రమే చదువుతుంది. అందువల్ల environment file లో password మార్చి up -d అమలు చేస్తే password authentication failed for user "postgres" వస్తుంది. కొత్తది container, పాతది volume. ఆ పాత volume లో ఇప్పటికీ పాత password ఉంటుంది. ఒకే variable రెండుసార్లు సెట్ చేసినప్పుడు ఏ layer ప్రాధాన్యత పొందుతుందో Compose env files మరియు secrets ను ఎలా పరిష్కరిస్తుంది వివరిస్తుంది.

వైఫల్య పరిస్థితులు మరియు మీరు చూసే సందేశాలు

no configuration file provided: not found అంటే compose.yaml మరియు docker-compose.yml లేని డైరెక్టరీలో Compose నడుస్తోందని అర్థం. పూర్తి pathతో -f ను అందించండి.

down పై network voltest_default has active endpoints అంటే ఈ projectకు చెందినది కాని ఒక container project networkకు అనుసంధానమై ఉందని అర్థం. సాధారణంగా ఇది docker run --network తో చేతితో ప్రారంభించిన container. ఆ containerను తొలగించి, మళ్లీ down ను అమలు చేయండి.

మీరు service పేరు మార్చిన తర్వాత లేదా దాన్ని తొలగించిన తర్వాత Found orphan containers ([voltest-old-1]) for this project కనిపిస్తుంది. పాత containerలో ఇప్పటికీ project label ఉంటుంది. docker compose down --remove-orphans ఆ labelలను తొలగిస్తుంది. ఆరోగ్యంగా నడుస్తున్న stackపై కూడా దీన్ని సురక్షితంగా అమలు చేయవచ్చు.

చేతితో అమలు చేసిన docker volume rm పై Error response from daemon: remove voltest_pgdata: volume is in use కనిపిస్తే, ఆ volumeను ఇప్పటికీ ఏదో ఒక container సూచిస్తోందని అర్థం. ఆ container ఆపివేయబడి ఉన్నా ఇది వర్తిస్తుంది. ముందుగా docker compose down ను అమలు చేసి, తర్వాత volumeను తొలగించండి. లేదా నేరుగా down -v ను ఉపయోగించండి. పెద్ద projectలో, బహుళ serviceల Compose stack ఒక projectలో ఎన్ని volumeలు పేరుకుపోవచ్చో చూపిస్తుంది.

FAQ

docker compose down నా database‌ను తొలగిస్తుందా?

Database named volume లేదా bind mount‌లో ఉంటే తొలగించదు. down containers మరియు project network‌ను తొలగిస్తుంది. Volume disk‌పై దాని dataతో అలాగే ఉంటుంది. తర్వాతి docker compose up -d అదే volume‌కు కొత్త container‌ను అనుసంధానిస్తుంది. Data అందులోనే ఉంటుంది. docker compose down -v మాత్రమే named volumes‌ను తొలగిస్తుంది. అదీ Compose file‌లోని volumes section‌లో ప్రకటించిన volumes‌ను మాత్రమే తొలగిస్తుంది.

తిరిగి ఉపయోగించాల్సిన container కోసం stop మరియు down మధ్య తేడా ఏమిటి?

stop container‌ను ఉంచుతుంది. అందువల్ల docker compose start మిమ్మల్ని అదే container‌కు, అదే writable layer‌తో తిరిగి తీసుకెళ్తుంది. Container‌లో మీరు చేతితో install చేసిన లేదా edit చేసినవి అలాగే ఉంటాయి. down container‌ను తొలగిస్తుంది. అందువల్ల తర్వాతి up -d image నుంచి కొత్త container‌ను సృష్టిస్తుంది. మీరు చేసిన manual మార్పులు కోల్పోతారు. 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 ఎందుకు పట్టించుకోవడం లేదు?

Container‌ను మళ్లీ సృష్టించాలా వద్దా అని Compose, resolved service definition యొక్క hash‌ను పోల్చి నిర్ణయిస్తుంది. Mounted fileలోని contents ఆ hash‌లో ఉండవు. Path మారలేదు. అందువల్ల startup సమయంలో చదివిన values‌తో Compose container‌ను నడుస్తున్న స్థితిలోనే ఉంచుతుంది. File‌ను మళ్లీ చదివే కొత్త container‌ను సృష్టించడానికి docker compose up -d --force-recreate అమలు చేయండి.

మార్చిన తర్వాత నా కొత్త POSTGRES_PASSWORD ఎందుకు పనిచేయడం లేదు?

Postgres image ఖాళీ data directoryను initialise చేస్తున్నప్పుడు మాత్రమే POSTGRES_PASSWORDను చదువుతుంది. మీ volume‌లో ఇప్పటికే initialised cluster ఉంది. అందువల్ల variable పరిగణించబడదు. పాత password ఇప్పటికీ పనిచేస్తుంది. మీరు password authentication failed for user "postgres"ను చూస్తారు. నడుస్తున్న database‌లో ALTER USERతో password మార్చండి. లేదా data కోల్పోవడాన్ని అంగీకరించి docker compose down -vతో మళ్లీ ప్రారంభించండి.