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

మీరు నిజంగా ఉపయోగించే Compose ఆదేశాలు

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

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

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

Lifecycle: మీరు టైప్ చేసే నాలుగు కమాండ్లు మరియు కంటైనర్‌లను తొలగించేది ఒకటి

docker compose up -d
docker compose up -d --wait
docker compose stop
docker compose start
docker compose restart web
docker compose down

up -d నెట్‌వర్క్‌ను సృష్టించి, కంటైనర్‌లను సృష్టించి, వాటిని ప్రారంభించి తిరిగి వస్తుంది. కంటైనర్‌లు సృష్టించబడిన వెంటనే ఇది తిరిగి వస్తుంది. అందుకే దాని తర్వాత curl probe ను అమలు చేసే deploy script మొదటి ప్రయత్నంలో తరచుగా విఫలమవుతుంది. up -d --wait healthcheck ప్రకటించిన ప్రతి service healthy అని నివేదించే వరకు వేచి ఉంటుంది. ఏదైనా service ఎప్పటికీ healthy కాకపోతే ఇది non-zero తో ముగుస్తుంది. ఈ flag వెనుక ఉన్న check ఎంత నమ్మదగినదో దాని ఫలితం అంతే నమ్మదగినది. అందువల్ల automation లో దీనిపై ఆధారపడే ముందు Compose నమ్మగల healthcheck ను రాయండి.

stop కంటైనర్‌లను ఆపి, వాటిని అలాగే ఉంచుతుంది. అందువల్ల start అదే writable layer తో అదే కంటైనర్‌లను మళ్లీ ప్రారంభిస్తుంది. down కంటైనర్‌లను ఆపిన తర్వాత వాటిని మరియు project network ను తొలగిస్తుంది. కంటైనర్‌లో volume వెలుపల రాసిన ఏదైనా డేటా వాటితో పాటు తొలగిపోతుంది. Compose లో ఇది అత్యంత ఖరీదైన అపార్థం. down మరియు stop మధ్య పూర్తి తేడా ఈ సమస్య ఎక్కడ ఎదురవుతుందో వివరిస్తుంది.

restart reload కాదు. ఇది ఇప్పటికే ఉన్న configuration తో అదే కంటైనర్‌ను ఆపి మళ్లీ ప్రారంభిస్తుంది. అందువల్ల మార్చిన environment variable, కొత్త image tag లేదా సవరించిన port mapping అసలు ప్రభావం చూపవు. File మార్పును వర్తింపజేయడానికి మళ్లీ up -d అమలు చేయాలి. Compose ప్రతి service ను దాని running container తో పోల్చుతుంది. Configuration మారిన service‌లను మాత్రమే ఇది మళ్లీ సృష్టిస్తుంది.

మార్పును వర్తింపజేయడం: మళ్లీ సృష్టించడం, pull చేయడం లేదా మళ్లీ build చేయడం

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 లోని అసాధారణ స్థితిని తొలగించడానికి ఇది వేగవంతమైన మార్గం.

Image ను update చేయడానికి రెండు commands అవసరం, ఎందుకంటే అవి రెండు వేర్వేరు పనులు చేస్తాయి. ఫైల్‌లో పేర్కొన్న ప్రతి tag కోసం ప్రస్తుత image ను pull download చేస్తుంది. ఆ తర్వాత service యొక్క image ID, ప్రస్తుతం నడుస్తున్న container కు సరిపోలడం లేదని up -d గుర్తించి, దాన్ని మళ్లీ సృష్టిస్తుంది. pull ను దాటవేస్తే, up -d గత నెలలోని latest ను ఎటువంటి error లేకుండా కొనసాగిస్తుంది.

build, image: బదులుగా build: section ను ప్రకటించే services కు వర్తిస్తుంది. up -d --build ఒకే దశలో build చేసి start చేస్తుంది. మీరు code ను మార్చుతున్నప్పుడు సాధారణంగా ఉపయోగించే విధానం ఇదే. Cached layer స్పష్టంగా పాతదిగా ఉన్నప్పుడు మాత్రమే --no-cache ను ఉపయోగించండి, ఎందుకంటే అది ప్రతి layer ను మొదటి నుంచి మళ్లీ build చేస్తుంది.

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

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

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

top ప్రతి container లోని processes ను జాబితా చేస్తుంది. దీని ద్వారా "container నడుస్తోంది" మరియు "దానిలోని process నడుస్తోంది" అనే రెండు పరిస్థితులను వేరు చేయవచ్చు. ls ప్రస్తుత directory పరిధిని దాటి, host లోని ప్రతి Compose project ను దాని status తో జాబితా చేస్తుంది. మూడు నెలల క్రితం ప్రారంభించిన stack ను ఇలా కనుగొనవచ్చు.

సేవలో షెల్‌ను ప్రారంభించడం

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 ఉపయోగించండి. అదే service definition నుండి కొత్త కంటైనర్‌ను ప్రారంభించడానికి run ఉపయోగించండి. service తగినంతసేపు నడవకపోతే, అందులో exec చేయడానికి ఇది అవసరం. run ను ఎల్లప్పుడూ --rm తో కలిపి ఉపయోగించండి. లేకపోతే ప్రతి invocation ఆగిపోయిన కంటైనర్‌ను మిగిల్చుతుంది. అవి పేరుకుపోయి చివరకు docker compose ps -a ను చదవలేనిదిగా చేస్తాయి.

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

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

నెట్‌వర్క్‌లు, పోర్ట్‌లు మరియు పేర్ల పరిష్కారం

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

Compose ప్రతి service ను ఒకే project networkలో ఉంచుతుంది. ప్రతి service పేరు ఆ networkలో DNS nameగా పనిచేస్తుంది. resolution పనిచేసినప్పుడు web లోపల getent hosts db ను అమలు చేస్తే container IP ముద్రించబడుతుంది. resolution పనిచేయకపోతే ఏమీ ముద్రించబడదు. అందువల్ల “ఈ containers ఒకదానినొకటి చూడగలవా” అనే ప్రశ్నకు ఇది రెండు సెకన్లలో సమాధానం ఇస్తుంది. పేరు resolve అయినా connection refused వస్తే, db లోని process 0.0.0.0 కు బదులుగా 127.0.0.1 కు bind అయి ఉంటుంది. అందువల్ల అది మరొక container నుంచి వచ్చే packet ను ఎప్పుడూ అంగీకరించదు. ఈ model గురించి మిగతా వివరాలు Compose networks మరియు service DNS ఎలా పనిచేస్తాయి లో ఉన్నాయి.

port web 80 container port publish చేయబడిన host address మరియు port ను ముద్రిస్తుంది. Mapping ఒక variable నుంచి వచ్చినప్పుడు అంచనా వేయాల్సిన అవసరం ఉండదు. Port ను publish చేయడం ద్వారా Docker స్వయంగా నిర్వహించే firewall rule కూడా వ్రాయబడుతుంది. ఆ rule మీ rules కంటే ముందు అమలవుతుంది. అందువల్ల private గా ఉందని మీరు భావించిన service internetకు అందుబాటులో ఉండవచ్చు. ఈ పరిస్థితి గురించి published Docker ports ufw నియమాలను ఎందుకు దాటవేస్తాయి లో వివరించబడింది.

Volumes మరియు data

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 చేయాల్సింది ఇదే జాబితా. cp shell తెరవకుండా, container లోకి లేదా container నుంచి file ను copy చేస్తుంది. Container ఉన్న వైపున service:path రూపాన్ని ఉపయోగించండి.

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

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

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

--remove-orphans ప్రాజెక్ట్‌కు చెందిన, కానీ ఫైల్‌లో ఇక కనిపించని కంటైనర్‌లను తొలగిస్తుంది. సేవ పేరు మార్చిన తర్వాత సాధారణంగా ఇదే పరిస్థితి ఏర్పడుతుంది. దీన్ని ఉపయోగించకపోతే, ఆ కంటైనర్‌లు నడుస్తూనే ఉంటాయి. అవి 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 volumeను ప్రభావితం చేస్తాయి.

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

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

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

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

ఫైళ్లు, ప్రొఫైళ్లు మరియు ప్రాజెక్ట్‌లలో పని చేయడం

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

--profile ఆ profileకు tag చేసిన servicesను, tag లేని servicesతో పాటు ప్రారంభిస్తుంది. దీనివల్ల సాధారణ upలో debug tooling చేర్చబడదు. -p project nameను సెట్ చేస్తుంది. అందువల్ల ఒకే stack యొక్క రెండు కాపీలు వేర్వేరు networks మరియు వేర్వేరు volume namesతో పక్కపక్కనే అమలు కావచ్చు. reboot తర్వాత stackను తిరిగి ప్రారంభించడం మీరు టైప్ చేసే command కాదు. మీకు బదులుగా దాన్ని ప్రారంభించే unitను ఉపయోగించాలి. దీని వివరాలు boot సమయంలో Compose stacksను ప్రారంభించడంలో ఉన్నాయి.

FAQ

హైఫన్‌తో ఉన్న docker-compose స్థానంలో ఏమి వచ్చింది?

ఖాళీతో ఉపయోగించే docker compose అయిన Compose V2 వచ్చింది. ఇది Docker Engineతో కూడిన plugin. ప్రస్తుత packagesలో V1 Python tool ఇకపై install చేయబడదు. ఖాళీతో ఉన్న రూపం ఏమీ ప్రింట్ చేయకపోతే, మీ distributionకు సంబంధించిన docker-compose-plugin packageను install చేయండి. Aliasను జోడించకుండా పాత scriptsను ఖాళీతో ఉన్న రూపానికి update చేయండి. ఎందుకంటే V2లో V1లో లేని flags ఉన్నాయి.

నా config మార్పును docker compose restart ఎందుకు గుర్తించదు?

restart ఇప్పటికే ఉన్న containerను, అది సృష్టించబడిన configurationతో, stop చేసి మళ్లీ start చేస్తుంది. ఇది 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ను run చేయండి. Fileలోని ప్రతి tagకు ప్రస్తుత imageను pull fetch చేస్తుంది. ఆ తర్వాత up -d, containerలోని image IDతో సరిపోని image ఉన్న serviceలను మళ్లీ సృష్టిస్తుంది. up -dను మాత్రమే run చేస్తే 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ను run చేయండి.

మొత్తం stackను start చేయకుండా ఒక commandను run చేయవచ్చా?

అవును. docker compose run --rm --no-deps web sh, web service definition ఆధారంగా ఒకే containerను start చేస్తుంది. ఇది dependenciesను skip చేస్తుంది. మీరు exit అయినప్పుడు containerను తొలగిస్తుంది. Container ఇప్పటికే runningలో ఉంటే execను ఉపయోగించండి. ఎందుకంటే exec live processలోకి చేరి, service వాస్తవంగా ఉన్న స్థితిని చూపిస్తుంది.