రియల్ సర్వర్ల కోసం Docker Compose కమాండ్ చీట్ షీట్

మీరు వాస్తవంగా ఉపయోగించే Compose commands

Docker Compose లో నలభైకి పైగా subcommands ఉన్నాయి. సర్వర్‌పై రోజువారీ పనిలో సుమారు డజను commands మాత్రమే ఉపయోగిస్తారు. మీరు చేస్తున్న పనిని బట్టి ఈ పేజీ వాటిని సమూహాలుగా విభజిస్తుంది. ప్రతి command కు ఒక స్పష్టమైన కారణాన్ని ఇస్తుంది. ఏదైనా command లో దాగి ఉన్న సమస్య ఉంటే, దాని వివరాలకు కూడా మార్గం చూపిస్తుంది.

ఇక్కడ ఉన్న ప్రతిదీ Compose V2 ను ఉపయోగిస్తుంది: docker compose తరువాత space ఉంటుంది; పాత docker-compose script కాదు. V2 అనేది Docker Engine తో install అయ్యే Go plugin. ప్రస్తుత packages లో V1 అందుబాటులో లేదు. అందువల్ల July 2026 నాటికి కొత్త Ubuntu system లో docker-compose: command not found కనిపించడం సాధారణమే; అది సమస్యను సూచించదు. docker compose version తో తనిఖీ చేయండి. అది ఏ output ఇవ్వకపోతే, docker-compose-plugin package ను install చేయండి.

కింద ఉన్న ప్రతి command ను మీ compose.yaml ఉన్న directory నుంచి run చేయాలి. ఎందుకంటే Compose project name ను ఆ directory నుంచి తీసుకుంటుంది. File ను కూడా అదే directory కి సంబంధించి కనుగొంటుంది. అదే command ను ఒక level పై directory నుంచి run చేస్తే, Compose no configuration file provided: not found తో ఆగిపోతుంది. File format మీకు కొత్తగా ఉంటే, VPS పై మొదటి Compose file తో ప్రారంభించి, commands కోసం తిరిగి ఇక్కడికి రండి.

లైఫ్‌సైకిల్: మీరు ఉపయోగించే నాలుగు commands, 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 మొదటి ప్రయత్నంలో తరచుగా విఫలమవుతుంది. ప్రతి healthcheck ప్రకటించిన service healthy అని నివేదించే వరకు up -d --wait వేచి ఉంటుంది. ఏదైనా service ఎప్పటికీ healthy కాకపోతే ఇది non-zero తో ముగుస్తుంది. ఈ flag వెనుక ఉన్న check ఎంత నమ్మదగినదో, ఈ flag కూడా అంతే నమ్మదగినది. అందువల్ల automation లో దీనిపై ఆధారపడే ముందు Compose నమ్మగల healthcheck ను రాయండి.

stop containers ను ఆపుతుంది, కానీ వాటిని ఉంచుతుంది. అందువల్ల start అదే containers ను, అదే writable layer తో మళ్లీ ప్రారంభిస్తుంది. down containers ను ఆపి, తరువాత containers మరియు project network ను తొలగిస్తుంది. container లో, volume వెలుపల రాసిన ఏదైనా data containers తోపాటు తొలగిపోతుంది. 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 ను భర్తీ చేస్తుంది. కాబట్టి container లోని అసాధారణ state ను త్వరగా తొలగించడానికి ఇది సరైన మార్గం.

Image ను update చేయడానికి రెండు commands అవసరం, ఎందుకంటే అవి రెండు వేర్వేరు పనులు చేస్తాయి. pull file లో పేర్కొన్న ప్రతి tag కు ప్రస్తుత image ను download చేస్తుంది. తరువాత up -d service యొక్క image ID, ప్రస్తుతం నడుస్తున్న container image IDతో సరిపోలడం లేదని గుర్తించి container ను మళ్లీ సృష్టిస్తుంది. pull ను దాటవేస్తే up -d గత నెలలోని latest ను ఎలాంటి error లేకుండా కొనసాగిస్తుంది. దీనికి విరుద్ధమైన ప్రమాదం multi-service stack లో కనిపిస్తుంది. అక్కడ ప్రతి service కోసం ఒకేసారి latest pull చేయడం వల్ల పది seconds ముందు సరిగ్గా పనిచేస్తున్న app కూడా విఫలమవుతుంది. అందుకే self-hosted AFFiNE workspace తన నాలుగు image tags లో ప్రతిదానినీ pin చేస్తుంది. Pinning వల్ల upgrade అనేది tag ను ఉద్దేశపూర్వకంగా మార్చి, అదే pull మరియు recreate ప్రక్రియను అమలు చేయడంగా మారుతుంది. Stack ప్రారంభమయ్యేటప్పుడు database ను migrate చేస్తే, ఈ రెండు commands లో ఏదైనా అమలు చేయడానికి ముందు dump సిద్ధంగా ఉంచాలి. ప్రతి version bump కోసం self-hosted Chatwoot support desk అనుసరించే పద్ధతి ఇదే.

build అనేది image: కు బదులుగా build: section ప్రకటించే services కు వర్తిస్తుంది. up -d --build ఒకే దశలో build చేసి start చేస్తుంది. Code మార్చుతున్నప్పుడు సాధారణంగా ఇదే loop ఉపయోగిస్తారు. Cached layer స్పష్టంగా పాతదిగా ఉన్నప్పుడు మాత్రమే --no-cache ఉపయోగించాలి, ఎందుకంటే అది ప్రతి layer ను మొదటి నుంచి rebuild చేస్తుంది. Stack registry image కు బదులుగా checked out git tag నుంచి deploy అయితే, ఇదే build loop update path గా కూడా పనిచేస్తుంది. self-hosted openGym workout tracker ఒక pinned version నుంచి తదుపరి version కు మారడానికి ఇదే విధానాన్ని ఉపయోగిస్తుంది.

నడుస్తున్న వాటిని చూడటం

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 ను మాత్రమే జాబితా చేస్తుంది. ప్రారంభ సమయంలో crash అయిన service కు -a జోడించే వరకు అక్కడ కనిపించదు. అందువల్ల ps లో container కనిపించకపోయినా, ps -a దాన్ని Exited (1) గా చూపించడం startup failure యొక్క సాధారణ రూపం. ముందుగా exit code ను చదవండి. తరువాత logs ను చదవండి.

logs -f అన్ని services ను ఒకేసారి follow చేస్తుంది. ప్రతి line ముందు service name ను జోడిస్తుంది. Services పరస్పరం communicate చేసుకునేటప్పుడు, events జరిగిన క్రమం ముఖ్యమైనప్పుడు ఇదే అవసరమైన view. పరిధిని తగ్గించడానికి service name ఇవ్వండి. ఒక నెలగా up లో ఉన్న container పై --tail=100 ముఖ్యమైనది. ఎందుకంటే default మొత్తం history ను print చేసి terminal ను messages తో నింపుతుంది. సాధారణంగా మీకు కావలసిన ప్రశ్నకు --since 15m సమాధానం ఇస్తుంది: మీరు ఇప్పుడే చేసిన restart సమయంలో ఏమి జరిగింది?

top ప్రతి container లోని processes ను జాబితా చేస్తుంది. దీని ద్వారా "container running లో ఉంది" మరియు "దాని లోపలి process running లో ఉంది" అనే రెండు పరిస్థితులను వేరు చేయవచ్చు. ls ప్రస్తుత directory వెలుపలికి వెళ్లి, host పై ఉన్న ప్రతి Compose project ను దాని 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 ను ప్రారంభిస్తుంది. సేవ exec చేయడానికి సరిపడా సమయం నడవకపోతే ఇదే అవసరం. run ను ఎల్లప్పుడూ --rm తో కలిపి ఉపయోగించండి. లేకపోతే ప్రతి invocation ఆగిపోయిన container ను మిగులుస్తుంది. అవి పేరుకుపోయి చివరకు docker compose ps -a చదవలేని స్థితికి చేరుతుంది.

bash కంటే ముందు sh ను ప్రయత్నించండి. Alpine ఆధారిత images లో bash ఉండదు. అందువల్ల వచ్చే వైఫల్య సందేశం exec: "bash": executable file not found in $PATH గా కనిపిస్తుంది. --no-deps ను run కు జోడిస్తే service dependencies దాటవేయబడతాయి. దీంతో త్వరిత config తనిఖీ కోసం మొత్తం database ప్రారంభం కాదు.

ప్రతి .env file, environment: block మరియు shell variable విలీనం అయిన తర్వాత, service వాస్తవంగా పొందిన environment ను చూడటానికి run --rm web env వేగవంతమైన మార్గం. విలువ తప్పుగా ఉన్నప్పుడు సాధారణంగా merge order కారణం అవుతుంది. ఏ source కు ప్రాధాన్యం లభిస్తుందో Compose env files మరియు secrets ను ఎలా పరిష్కరిస్తుందో వివరిస్తుంది.

నెట్‌వర్క్‌లు, ports మరియు name resolution

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

Compose ప్రతి service ను ఒకే project network పై ఉంచుతుంది. ప్రతి service name ఆ network లో DNS name గా పనిచేస్తుంది. Resolution పనిచేసినప్పుడు getent hosts db ను web లో run చేస్తే container IP కనిపిస్తుంది. Resolution పనిచేయకపోతే ఏ output ఉండదు. అందువల్ల “ఈ containers ఒకదానికొకటి చేరగలవా?” అనే ప్రశ్నకు రెండు seconds లో సమాధానం లభిస్తుంది. Name resolve అయినా connection refused అయితే, db లోని process 0.0.0.0 బదులుగా 127.0.0.1 కు bind అయి ఉంటుంది. అందువల్ల అది మరో container నుంచి వచ్చే packet ను ఎప్పుడూ accept చేయదు. Project బయట start చేసిన container కు కూడా ఇదే network boundary వర్తిస్తుంది. దాన్ని docker run ద్వారా start చేసినా లేదా దాని స్వంత stack గా నడిపినా, jellyfin వంటి name ను అసలు resolve చేయలదు. మీ Jellyfin library కోసం ఉన్న Halcyon front end అది సూచించే server ను చేరుకోలేకపోతే, ముందుగా పరిశీలించాల్సింది ఇదే. ఈ model లోని మిగతా వివరాలు Compose networks మరియు service DNS ఎలా పనిచేస్తాయి లో ఉన్నాయి.

port web 80 ఒక container port ఏ host address మరియు port పై publish అయిందో చూపిస్తుంది. Mapping variable నుంచి వచ్చినప్పుడు ఊహించాల్సిన అవసరం ఉండదు. Port ను publish చేయడం ద్వారా Docker స్వయంగా నిర్వహించే firewall rule కూడా రాయబడుతుంది. ఆ rule మీ rules కంటే ముందు అమలవుతుంది. అందువల్ల private గా ఉందని మీరు భావించిన service internet కు open అయి ఉండవచ్చు. ఈ పరిస్థితిని published Docker ports ufw ను ఎందుకు దాటవేస్తాయి లో వివరించారు. ఆ ports ను unpublished గా ఉంచి, services ముందు project network పై authentication చేసే ఒకే proxy ను ఉంచడం మరింత సురక్షితమైన నిర్మాణం. Authentik ను single sign-on layer గా నడపడం ఇదే విధానాన్ని అందిస్తుంది.

వాల్యూమ్‌లు మరియు డేటా

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

config --volumes ప్రాజెక్ట్ ప్రకటించిన named volumes ను ఒక్కో లైన్‌లో చూపిస్తుంది. మీరు backup చేయాల్సిన జాబితా ఇదే. Volumes లో తిరిగి పొందలేని డేటా ఉంటే, backup command కూడా ఈ జాబితా అంతే ముఖ్యమైనది. అందుకే PhotoPrism మరియు Immich పోలిక ప్రతి photo server కు అవసరమైన dump మరియు copy commands ను స్పష్టంగా చూపిస్తుంది. cp shell తెరవకుండానే container లోకి లేదా container నుంచి file ను copy చేస్తుంది. Container ఉన్న వైపు service:path రూపాన్ని ఉపయోగించాలి.

down -v containers తో పాటు ఆ named volumes ను కూడా తొలగిస్తుంది. Test stack ను పూర్తిగా తొలగించడానికి ఇది సరైన command. మీరు అవసరమైన డేటాను కలిగి ఉన్న stack కు ఇది తప్పు command. ఎందుకంటే confirmation అడగదు, undo కూడా లేదు. Bind mounts మాత్రం దీనివల్ల తొలగిపోవు. అవి host filesystem లో ఉంటాయి. ఈ ప్రభావ పరిధిలోని తేడా కారణంగా bind mounts మరియు named volumes మధ్య ఉద్దేశపూర్వకంగా ఎంపిక చేయాలి.

డేటాను కోల్పోకుండా డిస్క్ స్థలాన్ని ఖాళీ చేసే Cleanup

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

--remove-orphans ప్రాజెక్ట్‌కు చెందినప్పటికీ ఫైల్‌లో ఇక కనిపించని containers ను తొలగిస్తుంది. సేవ పేరు మార్చిన తర్వాత ఇదే పరిస్థితి ఏర్పడుతుంది. దీన్ని అమలు చేయకపోతే ఆ containers నడుస్తూనే ఉంటాయి. అవి docker compose ps లో కనిపించవు.

ఏదైనా తొలగించే ముందు డిస్క్ స్థలం ఎక్కడ వినియోగమైందో docker system df చూపిస్తుంది. ఇది images, containers, local volumes, build cache ను విడిగా చూపిస్తుంది. ప్రతి విభాగానికి reclaim చేయగల స్థలాన్ని కూడా చూపిస్తుంది. ఏ 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 volume ను ప్రభావితం చేస్తాయి.

ఏదైనా సమస్య కలిగించే ముందు ఫైల్‌ను తనిఖీ చేయడం

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

config --quiet విజయవంతమైనప్పుడు ఏమీ ముద్రించదు. అందువల్ల దీన్ని deployment కు ముందు దశలో లేదా git hook లో ఉపయోగించాలి. సాధారణ config పూర్తిగా merge చేసి interpolate చేసిన ఫైల్‌ను ముద్రిస్తుంది. Variable విలువ సరిగ్గా resolve అయిందా, override file మీరు ఆశించిన విధంగా layer అయిందా అని నిర్ధారించడానికి ఇదే మార్గం. Set చేయని variable అక్కడ ఖాళీ విలువగా కనిపిస్తుంది. దాని పక్కనే The "X" variable is not set. Defaulting to a blank string. హెచ్చరిక కనిపిస్తుంది.

--dry-run subcommand flag కాదు, global flag. అందువల్ల ఇది up ముందు రావాలి. Compose చేయబోయే ప్రతి చర్యను ఇది ముద్రిస్తుంది. ఎలాంటి మార్పూ చేయదు. ముఖ్యమైన stack పై down చేసే ముందు వెచ్చించే ముప్పై సెకన్లు ప్రయోజనకరంగా ఉంటాయి.

ఫైళ్లు, 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 చేస్తారు. తరువాతి ఫైళ్లు ముందున్న ఫైళ్లలోని keyలను ఒక్కొక్కటిగా override చేస్తాయి. చిన్న production override తో ఒక base file ను నిర్వహించడానికి ఇది ప్రామాణిక పద్ధతి. అయితే lists మరియు maps కు merge నియమాలు వేర్వేరుగా ఉంటాయి. అనుకోని ఫలితాన్ని debug చేయడానికి ముందు అనేక Compose ఫైళ్లను Compose ఎలా merge చేస్తుందో చదవండి.

--profile profile తో గుర్తించిన services ను profile లేని services తో పాటు ప్రారంభిస్తుంది. అందువల్ల సాధారణ up లో debug tooling ఉండదు. -p project name ను సెట్ చేస్తుంది. దీంతో ఒకే stack యొక్క రెండు copies ను వేర్వేరు networks మరియు volume names తో పక్కపక్కనే నడపవచ్చు. Reboot తర్వాత stack ను తిరిగి ప్రారంభించడానికి మీరు స్వయంగా ఏ command ను type చేయాల్సిన అవసరం లేదు. దాని కోసం స్వయంచాలకంగా నడిచే 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 ను ఆపి, అది సృష్టించబడినప్పుడు ఉన్న configuration తో మళ్లీ ప్రారంభిస్తుంది. ఇది compose.yaml ను మళ్లీ చదవదు. Environment variables, ports, volumes లేదా image tag లో ఏదైనా మార్చితే docker compose up -d అవసరం. ఇది ప్రతి service ను దాని running container తో పోల్చి, తేడా ఉన్న వాటిని మళ్లీ సృష్టిస్తుంది. File లో ఏ మార్పూ లేకపోయినా replacement జరగాలనుకుంటే --force-recreate జోడించండి.

Service ను కొత్త image కు ఎలా update చేయాలి?

ముందుగా docker compose pull, తరువాత docker compose up -d ను అమలు చేయండి. File లోని ప్రతి tag కోసం pull ప్రస్తుత image ను పొందుతుంది. 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 ను మాత్రమే తొలగిస్తాయి. అందువల్ల 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 ఆధారంగా ఒకే container ను ప్రారంభిస్తుంది. ఇది dependencies ను దాటవేస్తుంది. మీరు exit చేసినప్పుడు container ను తొలగిస్తుంది. Container ఇప్పటికే running లో ఉంటే exec ను ఉపయోగించండి. ఎందుకంటే exec live process లోకి చేరి, service వాస్తవంగా ఉన్న స్థితిని చూపిస్తుంది.