రియల్ సర్వర్ల కోసం Docker Compose commands cheat sheet
Docker Compose V2లో lifecycle, మార్పులు, logs, shells, networks, volumes కోసం రోజూ ఉపయోగించే commands, అలాగే సురక్షితమైన cleanup విధానాలను పని ప్రకారం చూడండి.
మీరు వాస్తవంగా ఉపయోగించే Compose commands
Docker Composeలో నలభైకి పైగా subcommands ఉన్నాయి. సర్వర్పై రోజువారీ పనులకు వాటిలో సుమారు డజను మాత్రమే ఉపయోగిస్తారు. మీరు చేస్తున్న పనిని బట్టి ఈ పేజీ వాటిని సమూహాలుగా విభజిస్తుంది. ప్రతి command కు ఒక సరళమైన కారణాన్ని ఇస్తుంది. ఏదైనా command లో దాగి ఉన్న సమస్య ఉంటే, దాని లోతైన వివరణకు సూచిస్తుంది.
ఇక్కడ ఉన్న ప్రతిదీ Compose V2ను ఉపయోగిస్తుంది: docker compose మధ్యలో ఒక space ఉంటుంది; పాత docker-compose script కాదు. V2 అనేది Docker Engineతో install అయ్యే Go plugin. ప్రస్తుత packagesలో V1 లేదు. అందువల్ల July 2026 నాటికి కొత్త Ubuntu boxపై docker-compose: command not found కనిపించడం సాధారణమే; అది లోపం కాదు. docker compose version తో తనిఖీ చేయండి. అది ఏ output ఇవ్వకపోతే, docker-compose-plugin packageను install చేయండి.
కింద ఉన్న ప్రతి commandను మీ compose.yaml ఉన్న directory నుంచి అమలు చేయాలి. Compose project nameను ఆ directory నుంచి తీసుకుంటుంది. అలాగే fileను కూడా అదే directoryకి సంబంధించి కనుగొంటుంది. అదే commandను ఒక level పై directoryలో అమలు చేస్తే, Compose no configuration file provided: not foundతో ఆగిపోతుంది. File format మీకు కొత్త అయితే, VPSపై మొదటి Compose fileతో ప్రారంభించి, commands కోసం ఇక్కడికి తిరిగి రండి.
Lifecycle: మీరు టైప్ చేసే నాలుగు ఆదేశాలు మరియు containers ను తొలగించేది
docker compose up -d
docker compose up -d --wait
docker compose stop
docker compose start
docker compose restart web
docker compose downup -d network ను సృష్టించి, containers ను సృష్టించి, వాటిని ప్రారంభించి, తిరిగి వస్తుంది. Containers సృష్టించబడిన వెంటనే ఇది తిరిగి వస్తుంది. అందుకే దీని తరువాత curl probe ను అమలు చేసే deploy script మొదటి ప్రయత్నంలో తరచుగా విఫలమవుతుంది. Healthcheck ప్రకటించిన ప్రతి service healthy స్థితిని నివేదించే వరకు up -d --wait వేచి ఉంటుంది. ఏదైనా service ఆ స్థితికి చేరుకోకపోతే ఇది non-zero తో ముగుస్తుంది. ఈ flag వెనుక ఉన్న check ఎంత నమ్మదగినదో, ఈ flag కూడా అంతే నమ్మదగినది. అందువల్ల automation లో దీనిపై ఆధారపడే ముందు Compose నమ్మగల healthcheck ను రాయండి.
stop containers ను ఆపుతుంది, కానీ వాటిని అలాగే ఉంచుతుంది. అందువల్ల start అదే containers ను, అదే writable layer తో మళ్లీ ప్రారంభిస్తుంది. down containers ను ఆపిన తరువాత వాటిని మరియు project network ను తొలగిస్తుంది. Container లో volume వెలుపల రాయబడిన ఏదైనా వాటితోపాటు తొలగిపోతుంది. Compose విషయంలో ఇది అత్యంత ఖరీదైన అపార్థం. down మరియు stop మధ్య పూర్తి తేడా దీని ప్రభావం ఎక్కడ ఉంటుందో వివరిస్తుంది.
restart reload కాదు. ఇది ఇప్పటికే ఉన్న configuration తో అదే container ను ఆపి మళ్లీ ప్రారంభిస్తుంది. అందువల్ల మార్చిన environment variable, కొత్త image tag లేదా సవరించిన port mapping ఏ ప్రభావాన్నీ చూపవు. File లో చేసిన మార్పును అమలు చేయడానికి up -d ను మళ్లీ run చేయాలి. Compose ప్రతి service ను దాని running container తో పోల్చుతుంది. Configuration మారిన services ను మాత్రమే ఇది మళ్లీ సృష్టిస్తుంది.
మార్పును అమలు చేయడం: recreate, pull లేదా rebuild
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 ఆ పోలికను పక్కనపెట్టి, configuration ఒకేలా ఉన్నా ప్రతి container ను replace చేస్తుంది. కాబట్టి container లోని అసాధారణమైన state ను త్వరగా తొలగించడానికి ఇది ఉపయోగపడుతుంది.
Image ను update చేయడానికి రెండు commands అవసరం, ఎందుకంటే అవి రెండు వేర్వేరు పనులు చేస్తాయి. ఫైల్లో పేర్కొన్న ప్రతి tag కోసం ప్రస్తుత image ను pull download చేస్తుంది. తరువాత సేవ యొక్క image ID, ప్రస్తుతం నడుస్తున్న container యొక్క image IDతో సరిపోలడం లేదని up -d గుర్తించి, దాన్ని మళ్లీ create చేస్తుంది. pull ను దాటవేస్తే, up -d గత నెలకు చెందిన latest ను ఎటువంటి error లేకుండా అలాగే నడుపుతుంది.
build లో image: కు బదులుగా build: section ను ప్రకటించిన services కు వర్తిస్తుంది. up -d --build ఒకే దశలో build చేసి start చేస్తుంది. మీరు code మార్చుతున్నప్పుడు సాధారణంగా అనుసరించాల్సిన విధానం ఇదే. Cached layer స్పష్టంగా పాతదై ఉన్నప్పుడు మాత్రమే --no-cache ఉపయోగించండి, ఎందుకంటే ఇది ప్రతి layer ను మొదటి నుంచి rebuild చేస్తుంది.
నడుస్తున్న వాటిని చూడటం
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 lsps నడుస్తున్న containers ను మాత్రమే జాబితా చేస్తుంది. ప్రారంభ సమయంలో crash అయిన service కు -a జోడించే వరకు అక్కడ కనిపించదు. అందువల్ల ps లో container కనిపించకపోయినా, ps -a దాన్ని Exited (1) గా చూపించడం startup failure యొక్క సాధారణ రూపం. ముందుగా exit code ను చదవండి. తరువాత logs ను చదవండి.
logs -f అన్ని services ను ఒకేసారి follow చేస్తుంది. ప్రతి line ప్రారంభంలో service name ను జోడిస్తుంది. Services పరస్పరం మాట్లాడుకునే సమయంలో, events జరిగిన క్రమం ముఖ్యమైనప్పుడు ఇదే అవసరమైన view. పరిధిని తగ్గించడానికి service name ఇవ్వండి. ఒక నెలగా నడుస్తున్న container పై --tail=100 ముఖ్యమైనది. లేకపోతే default గా మొత్తం history ను చూపించి terminal నిండిపోతుంది. మీరు ఇప్పుడే చేసిన restart సమయంలో ఏమి జరిగిందో --since 15m చూపిస్తుంది.
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 shexec ఇప్పటికే నడుస్తున్న container లో command ను అమలు చేస్తుంది. run అదే service definition నుంచి కొత్త container ను ప్రారంభిస్తుంది. Service ఎక్కువసేపు నడవకపోవడం వల్ల దానిలోకి exec చేయలేనప్పుడు ఇది అవసరం. run ను ఎల్లప్పుడూ --rm తో కలిపి ఉపయోగించండి. లేకపోతే ప్రతి invocation ఆగిపోయిన container ను మిగిల్చుతుంది. అవి పేరుకుపోయి చివరకు docker compose ps -a చదవలేనంతగా మారుతుంది.
bash కంటే ముందు sh ను ప్రయత్నించండి. Alpine ఆధారిత images లో bash ఉండదు. అందువల్ల failure message exec: "bash": executable file not found in $PATH గా కనిపిస్తుంది. run కు --no-deps జోడిస్తే service dependencies దాటవేయబడతాయి. దీంతో త్వరిత config check కోసం మొత్తం database ప్రారంభం కాదు.
ప్రతి .env file, environment: block మరియు shell variable merge అయిన తర్వాత service నిజంగా పొందిన environment ను చూడటానికి run --rm web env వేగవంతమైన మార్గం. ఏదైనా value తప్పుగా ఉంటే, సాధారణంగా కారణం merge order అవుతుంది. env files మరియు secrets ను Compose ఎలా resolve చేస్తుందో, ఏ source కు ప్రాధాన్యం ఉంటుందో Compose env files మరియు secrets ను ఎలా resolve చేస్తుంది వివరిస్తుంది.
నెట్వర్క్లు, ports మరియు name resolution
docker compose port web 80
docker compose exec web getent hosts db
docker compose config --networksCompose ప్రతి service ను ఒకే project network పై ఉంచుతుంది. ప్రతి service name ఆ network లో DNS name గా పనిచేస్తుంది. Resolution పనిచేస్తే getent hosts db ను web లో నడిపినప్పుడు container IP కనిపిస్తుంది. Resolution పనిచేయకపోతే ఏ output కూడా కనిపించదు. అందువల్ల “ఈ containers ఒకదానితో ఒకటి communicate చేయగలవా?” అనే ప్రశ్నకు రెండు seconds లో సమాధానం లభిస్తుంది. Name resolve అయినా connection refused వస్తే, db లోని process 0.0.0.0 బదులుగా 127.0.0.1 కు bind అయి ఉంటుంది. అందువల్ల అది మరో container నుంచి వచ్చే packet ను ఎప్పుడూ accept చేయదు. ఈ model లోని మిగతా వివరాలు Compose networks మరియు service DNS ఎలా పనిచేస్తాయో లో ఉన్నాయి.
ఒక container port publish చేయబడినప్పుడు host address మరియు port ను port web 80 చూపిస్తుంది. Mapping variable నుంచి వచ్చినప్పుడు ఇది అంచనా వేయాల్సిన అవసరాన్ని తొలగిస్తుంది. Port publish చేయడం ద్వారా Docker స్వయంగా నిర్వహించే firewall rule కూడా ఏర్పడుతుంది. ఆ rule మీ rules కంటే ముందుగా అమలవుతుంది. అందువల్ల private గా ఉందని మీరు భావించిన service internet కు open కావచ్చు. ఈ పరిస్థితి published Docker ports ufw ను ఎందుకు దాటవేస్తాయో లో వివరించబడింది.
వాల్యూమ్లు మరియు డేటా
docker compose config --volumes
docker compose cp db:/etc/postgresql/pg_hba.conf ./pg_hba.conf
docker compose down -vconfig --volumes ప్రాజెక్ట్ ప్రకటించిన named volumes ను ఒక్కో పంక్తిలో చూపిస్తుంది. మీరు backup చేయాల్సింది ఆ జాబితాలో ఉన్నవే. cp shell తెరవకుండానే ఒక file ను container లోకి లేదా container నుంచి బయటకు copy చేస్తుంది. Container ఉన్న వైపు service:path రూపాన్ని ఉపయోగించాలి.
down -v containers తో పాటు ఆ named volumes ను కూడా తొలగిస్తుంది. Test stack ను పూర్తిగా తొలగించడానికి ఇది సరైన command. మీరు అవసరమైన డేటాను కలిగి ఉన్న ఏదైనా stack కోసం ఇది తప్పు command, ఎందుకంటే దీనిలో confirmation ఉండదు మరియు మార్పును undo చేయలేరు. Bind mounts దీనివల్ల తొలగిపోవు, ఎందుకంటే అవి host filesystem లో ఉంటాయి. Blast radius లోని ఈ తేడా కారణంగా bind mounts మరియు named volumes మధ్య ఉద్దేశపూర్వకంగా ఎంపిక చేయాలి.
డేటాను కోల్పోకుండా డిస్క్ స్థలాన్ని ఖాళీ చేసే శుభ్రపరిచే చర్యలు
docker compose down --remove-orphans
docker system df
docker image prune -a
docker builder prune--remove-orphans ఫైల్లో ఇక కనిపించని, కానీ ప్రాజెక్ట్కు చెందిన containers ను తొలగిస్తుంది. service పేరు మార్చిన తర్వాత సాధారణంగా ఇదే పరిస్థితి ఏర్పడుతుంది. దీన్ని అమలు చేయకపోతే ఆ containers నడుస్తూనే ఉంటాయి, కానీ docker compose ps కు అవి కనిపించవు.
ఏదైనా తొలగించే ముందు డిస్క్ స్థలం ఎక్కడ వినియోగమైందో docker system df చూపిస్తుంది. ఇది images, containers, local volumes మరియు build cache ను విడిగా చూపించి, ప్రతి విభాగంలో తిరిగి పొందగల స్థలాన్ని కూడా పేర్కొంటుంది. ఏ tag కూడా సూచించని ప్రతి image ను image prune -a తొలగిస్తుంది. పెద్ద image యొక్క అనేక versions ను pull చేసిన server లో ఇది సాధారణంగా అత్యధిక స్థలాన్ని ఖాళీ చేస్తుంది. స్వయంగా images build చేసే ఏ server లోనైనా నిశ్శబ్దంగా పెరిగే build cache ను builder prune తొలగిస్తుంది.
వీటిలో ఏదీ named volume ను ప్రభావితం చేయదు. docker volume prune మరియు docker compose down -v మాత్రమే named volumes ను తొలగిస్తాయి.
ఏదైనా సమస్య కలిగించే ముందు ఫైల్ను తనిఖీ చేయడం
docker compose config --quiet
docker compose config --services
docker compose --dry-run up -dconfig --quiet విజయవంతమైనప్పుడు ఏమీ print చేయకుండా validation చేస్తుంది. అందువల్ల దీన్ని pre-deploy దశలో లేదా git hook లో ఉపయోగించాలి. సాధారణ config పూర్తిగా merge చేసి interpolate చేసిన ఫైల్ను print చేస్తుంది. Variable సరైన విలువకు resolve అయిందో, override ఫైల్ మీరు ఆశించిన విధంగా layer అయిందో నిర్ధారించడానికి ఇదే సరైన పద్ధతి. Unset variable అక్కడ ఖాళీ విలువగా కనిపిస్తుంది; దాని పక్కనే The "X" variable is not set. Defaulting to a blank string. warning కనిపిస్తుంది.
--dry-run subcommand flag కాదు, global flag. అందువల్ల ఇది up ముందు రావాలి. Compose చేయబోయే ప్రతి చర్యను ఇది print చేస్తుంది, కానీ ఎలాంటి మార్పూ చేయదు. ముఖ్యమైన stack పై down అమలు చేయడానికి ముందు ఖర్చు చేసే ముప్పై seconds సమయం ఇది.
ఫైళ్లు, profiles మరియు projectsపై కలిసి పని చేయడం
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 అవుతాయి. తరువాతి files, ముందున్న files లోని విలువలను key వారీగా override చేస్తాయి. చిన్న production overrideతో ఒక base fileను నిర్వహించడానికి ఇది సాధారణ పద్ధతి. అయితే lists మరియు maps కోసం నియమాలు భిన్నంగా ఉంటాయి. కాబట్టి అనూహ్య ఫలితాన్ని debug చేయడానికి ముందు Compose అనేక filesను ఎలా merge చేస్తుందో చదవండి.
--profile తో గుర్తించిన services, profileలో గుర్తించని servicesతో పాటు ప్రారంభమవుతాయి. దీనివల్ల సాధారణ upలో debug tooling చేరదు. -p project nameను నిర్దేశిస్తుంది. అందువల్ల ఒకే stack యొక్క రెండు copiesను వేర్వేరు networks మరియు వేర్వేరు volume namesతో పక్కపక్కనే నడపవచ్చు. reboot తర్వాత stackను తిరిగి ప్రారంభించడం మీరు type చేసే command కాదు. దాని కోసం స్వయంగా నడిచే unit అవసరం. దీని వివరణ boot సమయంలో Compose stacksను ఎలా ప్రారంభించాలోలో ఉంది.
FAQ
హైఫన్తో ఉన్న docker-compose స్థానంలో ఏమి వచ్చింది?
ఖాళీతో రన్ చేసే docker compose రూపంలోని Compose V2 వచ్చింది. ఇది Docker Engine తో కలిసి వచ్చే plugin. ప్రస్తుత packages లో V1 Python tool ఇక install చేయబడదు. ఖాళీతో ఉన్న రూపం ఏ output ఇవ్వకపోతే, మీ distribution కోసం docker-compose-plugin package ను install చేయండి. Alias జోడించడానికి బదులుగా పాత scripts ను ఖాళీతో ఉన్న రూపానికి మార్చండి, ఎందుకంటే V2లో V1లో లేని flags ఉన్నాయి.
నా config మార్పును docker compose restart ఎందుకు గుర్తించదు?
restart ఇప్పటికే ఉన్న container ను ఆ container సృష్టించినప్పుడు ఉపయోగించిన configuration తో stop చేసి మళ్లీ start చేస్తుంది. ఇది compose.yaml ను మళ్లీ చదవదు. Environment variables, ports, volumes లేదా image tag లో చేసిన ఏ మార్పుకైనా docker compose up -d అవసరం. ఇది ప్రతి service ను నడుస్తున్న container తో పోల్చి, తేడా ఉన్న వాటిని మళ్లీ సృష్టిస్తుంది. File లో ఏదీ మారకపోయినా replacement జరగాలని అనుకుంటే --force-recreate ను జోడించండి.
Service ను కొత్త image కు ఎలా update చేయాలి?
docker compose pull ను అమలు చేసి, తరువాత docker compose up -d ను అమలు చేయండి. File లోని ప్రతి tag కోసం pull ప్రస్తుత image ను fetch చేస్తుంది. ఆ తరువాత up -d image ID తన container తో సరిపోని ఏ service నైనా మళ్లీ సృష్టిస్తుంది. up -d ను మాత్రమే అమలు చేస్తే disk లో ఇప్పటికే ఉన్న image ను మళ్లీ ఉపయోగిస్తుంది. అందువల్ల latest కు pinned గా ఉన్న stack ఎలాంటి error చూపకుండా నెలల క్రితం build పై కొనసాగవచ్చు.
Live server పై ఏ cleanup commands సురక్షితమైనవి?
docker system df, docker image prune -a మరియు docker builder prune images మరియు cache ను మాత్రమే తొలగిస్తాయి. అందువల్ల నడుస్తున్న services పనిచేస్తూనే ఉంటాయి. Named volumes మారవు. ప్రమాదకరమైన జత docker compose down -v మరియు docker volume prune. ఇవి ఎలాంటి prompt లేకుండా named volumes ను తొలగిస్తాయి. ఏది ప్రమాదంలో ఉందో తెలుసుకోవడానికి ముందుగా docker compose config --volumes ను అమలు చేయండి.
మొత్తం stack ను start చేయకుండా ఒక command ను అమలు చేయవచ్చా?
అవును. docker compose run --rm --no-deps web sh, web service definition ఆధారంగా ఒకే container ను start చేస్తుంది. ఇది dependencies ను skip చేస్తుంది. మీరు exit చేసినప్పుడు container ను తొలగిస్తుంది. Container ఇప్పటికే running లో ఉంటే exec ను ఉపయోగించండి. ఎందుకంటే exec live process లోకి join అయి, service వాస్తవంగా ఉన్న స్థితిని చూపిస్తుంది.