Docker Compose execతో ఇంటరాక్టివ్ shell ఎలా తెరవాలి

docker compose exec తో ఇంటరాక్టివ్ shell పొందడం

docker compose exec web bash ఇప్పటికే నడుస్తున్న containerలో, web serviceగా నడుస్తున్నదానిలో, ఇంటరాక్టివ్ shellను తెరుస్తుంది. exec తర్వాత ఇచ్చే పేరు మీ compose.yaml లోని service పేరు; అది container పేరు కాదు. imageలో bash లేకపోతే దాని బదులుగా sh ను అడగండి.

docker compose ps
docker compose exec web bash

ముందుగా docker compose ps ను అమలు చేయండి. అందులో web, running స్థితితో కనిపించాలి. తరువాతి command containerలోని promptకు తీసుకెళ్తుంది. అక్కడి నుంచి exit లేదా Ctrl-D నొక్కితే hostకు తిరిగి వస్తారు. మీరు బయటకు వచ్చిన తర్వాత కూడా service నడుస్తూనే ఉంటుంది, ఎందుకంటే exec ప్రధాన process పక్కన రెండవ processను ప్రారంభించింది. మీ shellను మూసివేయడం PID 1 (process id 1) పై ప్రభావం చూపదు. Container నడపడానికి నిర్మించబడిన process అదే.

Containerలోకి ప్రవేశించడానికి ఇవి రెండు మార్గాల్లో ఒకటి. ఇప్పటికే ఉన్న containerలో exec చేరుతుంది. docker compose run అదే service definition ఆధారంగా కొత్త containerను సృష్టిస్తుంది. ఈ ఒక్క తేడా నుంచే ఈ guideలోని దాదాపు అన్ని ఇతర విషయాలు అర్థమవుతాయి.

Composeలో -it ఐచ్ఛికం, కానీ plain dockerలో ఎందుకు అవసరం

సెషన్‌లోని interactive భాగాన్ని రెండు flags నియంత్రిస్తాయి. -i stdin ను openగా ఉంచుతుంది. అందువల్ల మీరు టైప్ చేసేది processకు చేరుతుంది. -t TTY అని పిలిచే pseudo terminalను allocate చేస్తుంది. అందువల్ల shell promptను చూపించి arrow keysను process చేయగలదు. Plain docker exec డిఫాల్ట్‌గా ఈ రెండింటినీ ఆఫ్‌లో ఉంచుతుంది. అందుకే మీరు చూసిన ప్రతి ఉదాహరణలో docker exec -it ఉంటుంది. docker compose exec ఈ రెండింటినీ మీకు స్వయంచాలకంగా ఆన్ చేస్తుంది. అందువల్ల docker compose exec -it web bash మరియు docker compose exec web bash ఒకే విధంగా పనిచేస్తాయి. పాత అలవాటు అలాగే పనిచేయడానికి Compose ఇప్పటికీ -it ను అంగీకరిస్తుంది.

TTY లేకపోవడం కొన్ని సెకన్లలోనే తెలుస్తుంది. Shell నడుస్తుంది, కానీ promptను చూపించదు. Ctrl-C కూడా processకు చేరదు. దీనికి విరుద్ధమైన సందర్భంలో, Compose TTYను allocate చేయకూడదని మీరు చెప్పాలి. దానికి ప్రత్యేక flag మరియు కింద ప్రత్యేక section ఉన్నాయి.

bash లేని image ఉన్నప్పుడు ఏమి చేయాలి

Alpine ఆధారిత image లో bash ను అడిగితే exec ఇలా విఫలమవుతుంది:

OCI runtime exec failed: exec failed: unable to start container process: exec: "bash": executable file not found in $PATH: unknown

ఇది exec సమస్య కాదు. మీరు అడిగిన binary image లో లేదని ఆ సందేశం చెబుతోంది. Alpine లో BusyBox మాత్రమే ఉంటుంది. అందులో ash, /bin/sh గా అందుబాటులో ఉంటుంది; bash అసలు ఉండదు. కాబట్టి sh ను అడగాలి:

docker compose exec web sh

-slim tags సహా Debian మరియు Ubuntu ఆధారిత images లో bash ఉంటుంది. bash command history మరియు మెరుగైన completion అందిస్తుంది. కాబట్టి ముందుగా bash ను ప్రయత్నించి, విఫలమైతే sh కు fallback చేయండి. దాదాపు ప్రతి general-purpose image లో sh ఉంటుంది.

కొన్ని images లో shell అసలు ఉండదు. Distroless images మరియు FROM scratch నిర్మించిన images లో application binary, దానికి అవసరమైన libraries మాత్రమే ఉంటాయి. ఇది ఉద్దేశపూర్వకంగా చేసే అమరిక. లేని shell ను మీపై దాడికి ఉపయోగించలేరు. అలాంటి images లో sh అదే సందేశంతో విఫలమవుతుంది. ప్రయత్నించడానికి మరేమీ ఉండదు. దీనికి రెండు పద్ధతులు పనిచేస్తాయి. Google యొక్క distroless images లో BusyBox shell ను జోడించే :debug tags అందుబాటులో ఉంటాయి. ఆ tag కు తాత్కాలికంగా మారితే మీరు లోపలికి ప్రవేశించగలరు. లేదా target యొక్క namespaces లోకి ప్రత్యేక container ను ప్రారంభించండి:

CID=$(docker compose ps -q web)
docker run --rm -it --network "container:$CID" --pid "container:$CID" nicolaka/netshoot

ఇప్పుడు application's network ను లక్ష్యంగా చేసుకుని netshoot యొక్క tools మీకు అందుబాటులో ఉంటాయి. అందువల్ల curl localhost:8080 మరియు ss -lntp ను target లోపల ఉన్నట్లుగానే ఉపయోగించవచ్చు. మీరు చూస్తున్న filesystem netshoot కు చెందుతుంది, app కు కాదు. Process namespace shared గా ఉన్నందున, మీరు root గా ఉన్నప్పుడు ls /proc/1/root/ target కు చెందిన స్వంత files ను చేరుకుంటుంది.

సేవా నడుస్తూ లేకపోతే docker compose run --rm ఉపయోగించండి

నడుస్తున్న container అవసరం కాబట్టి exec ఆగిపోయిన సేవకు పనిచేయదు. ఆపివేసిన సేవను లక్ష్యంగా ఎంచుకుంటే అది నిరాకరిస్తుంది:

service "web" is not running

ఇది మీ తరఫున ఏదీ ప్రారంభించదు. docker compose run మాత్రం చేస్తుంది:

docker compose run --rm web bash

run అనేది web service definition ఆధారంగా కొత్త container ను సృష్టిస్తుంది. ఇందులో అదే image, environment, volumes మరియు networks ఉంటాయి. మీరు టైప్ చేసిన command తో service యొక్క command భర్తీ అవుతుంది. బయటకు వచ్చినప్పుడు --rm ఆ container ను తొలగిస్తుంది. --rm ను వదిలేస్తే, మిగిలిన containers myproject-web-run-4f1c2b వంటి పేర్లతో పేరుకుపోతాయి. వాటిని docker compose ps -a చూపిస్తుంది. వాటిని మరే ఇతర ప్రక్రియ శుభ్రం చేయదు.

run యొక్క రెండు ప్రవర్తనలు చాలామందికి ఆశ్చర్యం కలిగిస్తాయి. మీరు --service-ports జోడించకపోతే, ఇది service ports ను publish చేయదు. ఇది ఉద్దేశపూర్వకమే. మొదటి container port 8080 ను ఇప్పటికే ఆక్రమించి ఉండగా, రెండవ container అదే host port ను bind చేయడం bind: address already in use వల్ల విఫలమవుతుంది. అలాగే, మీ shell కనిపించే ముందు service depends_on కింద పేర్కొన్న ప్రతిదాన్ని ఇది ప్రారంభిస్తుంది. అందువల్ల లోపల త్వరగా పరిశీలించడానికి database మరియు cache కూడా ప్రారంభమవుతాయి. --no-deps దీన్ని దాటవేస్తుంది.

run image యొక్క ENTRYPOINT ద్వారా నడుస్తుంది. exec అలా చేయదు. exec ఇప్పటికే ఉన్న container లో మీ command ను నేరుగా ప్రారంభిస్తుంది. అందువల్ల entrypoint script దాన్ని చూడదు. run లో మీ bash ఆ script కు arguments గా చేరుతుంది. అనేక official images తమ entrypoint ను exec "$@" తో ముగిస్తాయి. అందువల్ల అది నేరుగా ముందుకు పంపబడుతుంది, మీకు shell లభిస్తుంది. తన arguments ను స్వయంగా అర్థం చేసుకునే script వాటితో వేరే పని చేస్తుంది. అప్పుడు ఆ ఒక్క run కోసం entrypoint ను ఇలా భర్తీ చేయండి:

docker compose run --rm --entrypoint sh web

exec కింద పనిచేసే command run కింద భిన్నంగా పనిచేయడానికి ఇదే అత్యంత సాధారణ కారణం. command మరియు entrypoint మధ్య విభజన ప్రతి సారి image configuration లోని ఏ భాగాన్ని మీరు భర్తీ చేస్తున్నారో వివరిస్తుంది.

exec లేదా run: ఎలా ఎంచుకోవాలి

• exec కు నడుస్తున్న container అవసరం. run కు అది అవసరం లేదు; అలాగే run dependencies ను ప్రారంభించవచ్చు.
• exec ప్రస్తుతం నడుస్తున్న process జాబితాను, ఈ క్షణంలో ఉన్న files ను చూస్తుంది. అప్లికేషన్ ప్రారంభమైన తర్వాత రాసినవి కూడా అందులో ఉంటాయి. run image యొక్క శుభ్రమైన కాపీని పొందుతుంది. అందువల్ల ఆ మార్పులు ఏవీ అందులో ఉండవు.
• exec entrypoint ను దాటవేస్తుంది. run దాన్ని అమలు చేస్తుంది.
• --rm ను pass చేయకపోతే run ఒక container ను మిగులుస్తుంది.

నిజంగా ఏమి జరుగుతుందో చూడటానికి exec ను ఉపయోగించండి. అదే environment యొక్క తాత్కాలిక కాపీ కోసం, ఒక్కసారి మాత్రమే అమలు చేయాల్సిన migration command కోసం, లేదా అసలు service exec చేయడానికి సరిపడా సమయం నడవనప్పుడు run --rm ను ఉపయోగించండి.

ఉపయోగకరమైన exec flags: user, working directory మరియు replicas

చాలా images non-root user కు మారతాయి. అందువల్ల మీ exec shell లో diagnostic tool install చేయడం ఇక్కడే ఆగిపోతుంది:

E: Could not open lock file /var/lib/dpkg/lock-frontend - open (13: Permission denied)

-u root అదే container లో మీకు root shell ఇస్తుంది:

docker compose exec -u root web sh

-w /srv/app ఆ command కు మాత్రమే working directory ను సెట్ చేస్తుంది. -e KEY=value మీ session కు environment variable ను జోడిస్తుంది; service కు కాదు. ఒక service ఒకటి కంటే ఎక్కువ replicas నడిపినప్పుడు, మీరు ఏ container లోకి ప్రవేశించాలో --index 2 నిర్ణయిస్తుంది. Mounted directory లోని file ownership కారణమని మీరు పరిశీలిస్తున్నట్లయితే, container images లో PUID మరియు PGID numeric ids ఎందుకు ముఖ్యమో వివరిస్తుంది; అక్కడ ఎవరు write చేయగలరో user names కాదు, numeric ids నిర్ణయిస్తాయి.

డేటాబేస్ container లోపల psql లేదా mysql shell పొందడం

Client ఇప్పటికే database image లో ఉంది. అందువల్ల host పై client అవసరం లేదు. Port ను publish చేయాల్సిన అవసరం కూడా లేదు:

docker compose exec db psql -U postgres -d app
docker compose exec db mariadb -u root -p

Postgres images లో psql, MySQL images లో mysql, MariaDB images లో mariadb ఉంటాయి. Connection container లోపల నుంచే ఏర్పడుతుంది. అందువల్ల compose file ఎలాంటి database port ను publish చేయకపోయినా ఇది పనిచేస్తుంది. అదే మరింత సురక్షితమైన అమరిక. మీరు publish చేయని port ను internet ద్వారా ఎవరూ చేరుకోలేరు.

ఒక పొరపాటు వల్ల పనిలో ఒక మధ్యాహ్నం వృథా కావచ్చు. Docker command ను చూసే ముందే మీ shell host పై variables ను expand చేస్తుంది. అందువల్ల ఆ variable container లోపల మాత్రమే ఉంటే -U "$POSTGRES_USER" ఖాళీ string ను పంపుతుంది. Single quotes మరియు container లోపల నడిచే shell దాన్ని సరైన చోట expand చేస్తాయి:

docker compose exec db sh -c 'psql -U "$POSTGRES_USER" -d "$POSTGRES_DB"'

ఇక్కడ command లేకుండా docker compose run --rm db ను ఉపయోగించవద్దు. అది అదే data volume పై రెండో Postgres server ను ప్రారంభిస్తుంది. ఆ server ప్రారంభం కావడానికి నిరాకరిస్తుంది:

FATAL:  lock file "postmaster.pid" already exists

Lock file తన పని చేస్తోంది. ఒకే data directory పై రెండు servers రాస్తే data corrupt అవుతుంది. Database నడుస్తున్నప్పుడు running container లోకి exec చేయండి. Database ను Compose లోనే ఉంచాలా అనేది వేరే నిర్ణయం. Docker లో లేదా host పై database నడపడం వల్ల కలిగే ప్రయోజనాలు, పరిమితులను వివరిస్తుంది.

ప్రారంభ సమయంలో console అవసరమైన సేవలు: stdin_open మరియు tty

మీరు చేతితో తెరిచే shells కు exec మరియు run సరిపోతాయి. ప్రధాన process సహజంగానే interactive గా ఉండే సేవకు compose file లో రెండు keys అవసరం:

services:
  console:
    image: python:3.12-slim
    command: python
    stdin_open: true
    tty: true

stdin_open: true అంటే docker run -i, అలాగే tty: true అంటే docker run -t. ఇవి లేకపోతే container ప్రారంభమై వెంటనే code 0తో నిష్క్రమిస్తుంది. అప్పుడు docker compose ps -a లో Exited (0) కనిపిస్తుంది. ఎలాంటి crash జరగలేదు. stdin పై terminal లేకపోవడంతో python వెంటనే end of file ను చదివి సాధారణంగా నిష్క్రమిస్తుంది. ఎవరూ టైప్ చేయని program కు ఇదే సరైన ప్రవర్తన.

రెండు keys సెట్ చేసిన తర్వాత నడుస్తున్న process కు attach అవ్వండి:

docker attach $(docker compose ps -q console)

Ctrl-P తర్వాత Ctrl-Q నొక్కితే detach అవుతుంది. దాంతో process నడుస్తూనే ఉంటుంది. Container లో TTY మరియు stdin రెండూ open గా ఉన్నప్పుడు మాత్రమే ఈ క్రమం పనిచేస్తుంది. Ctrl-C బదులుగా PID 1 కు interrupt పంపి service ను ఆపుతుంది.

సాధారణ services కోసం రెండు keys ను off లో ఉంచండి. Web server stdin ను ఎప్పుడూ చదవదు. అలాగే tty: true వల్ల తాను ఒక వ్యక్తి గమనిస్తున్నాడని భావించే అనేక programs colour output మరియు line buffering కు మారతాయి. దాంతో docker compose logs escape codes తో నిండిపోతుంది.

cron మరియు CIలో scripted exec ఎందుకు విఫలమవుతుంది: -T flag

మీ terminalలో పనిచేసే exec command, cron job లేదా continuous integration (CI) runnerలో విఫలమవుతుంది:

the input device is not a TTY

Compose డిఫాల్ట్‌గా pseudo terminal ను అభ్యర్థిస్తుంది. cron jobకు terminal అందించదు. అందువల్ల మీ command అమలుకాకముందే request విఫలమవుతుంది. -T ఈ అభ్యర్థనను నిలిపివేస్తుంది:

0 3 * * * docker compose -f /srv/app/compose.yaml exec -T db pg_dump -U postgres -Fc app > /srv/backups/app.dump

-T కు మరో కారణం కూడా ఉంది. బయటకు వెళ్లే సమయంలో TTY byte stream ను మార్చుతుంది. అందువల్ల దాని ద్వారా వెళ్లే compressed dump దెబ్బతిన్న స్థితిలో చేరుతుంది. Redirect చేసిన లేదా pipe చేసిన output కు -T అవసరం.

cronకు సంబంధించిన మరో రెండు విషయాలు ఉన్నాయి. -f ను absolute path తో ఇవ్వాలి. cron job ను home directory నుంచి అమలు చేస్తుంది; అక్కడ compose file ఉండదు. అప్పుడు Compose no configuration file provided: not found తో ఆగిపోతుంది. అలాగే exec తాను అమలు చేసిన command యొక్క exit code ను తిరిగి ఇస్తుంది. అందువల్ల విఫలమైన pg_dump, ఖాళీ backup రాసి success గా నివేదించకుండా, set -e కింద మీ script ను విఫలపరుస్తుంది. రోజువారీగా ఉపయోగించే మిగిలిన commands ను Compose command cheat sheet లో సమీకరించాం. ఈ scripts పక్కన ఉంచుకోవడం ఉపయోగకరం.

కంటైనర్‌లో మీరు చేసిన మార్పులు ఎందుకు అదృశ్యమవుతాయి

మీరు exec తో ఒక టూల్‌ను ఇన్‌స్టాల్ చేసి, configuration file ను సవరించి, సమస్యను పరిష్కరిస్తారు. వారం తర్వాత ఆ పరిష్కారం కనిపించదు. ఇది కంటైనర్‌లోని writable layer ఉద్దేశించిన విధంగానే పనిచేస్తోందని సూచిస్తుంది. docker compose up -d image tag లేదా service definition లో ఏదైనా మార్పు వచ్చినప్పుడు పాత కంటైనర్‌ను తొలగించి, image నుంచి కొత్తదాన్ని సృష్టిస్తుంది. అందువల్ల మీరు పాత కంటైనర్‌లో చేసిన ప్రతి manual edit కూడా తొలగిపోతుంది.

docker compose restart దీనికి భిన్నంగా పనిచేస్తుంది. ఇది అదే కంటైనర్‌ను stop చేసి మళ్లీ start చేస్తుంది. కాబట్టి manual edits అలాగే ఉంటాయి. అందుకే ఒక manual fix వారాలపాటు నిలిచినట్లు కనిపించి, సంబంధం లేని update సమయంలో అకస్మాత్తుగా అదృశ్యమవుతుంది. Named volumes మరియు bind mounts రెండింటి operations తర్వాత కూడా నిలిచి ఉంటాయి, ఎందుకంటే వాటి data కంటైనర్ వెలుపల ఉంటుంది. డేటాను నిల్వ చేయడానికి ఏది ఎంచుకోవాలో bind mounts మరియు named volumes లో వివరించబడింది.

అందువల్ల exec shell ను చదవడానికి మరియు పరీక్షించడానికి మాత్రమే ఉపయోగించండి. పరిష్కారం తెలిసిన తర్వాత, అది నిలిచిపోయే ప్రదేశంలో రాయండి: package ను Dockerfile లో, setting ను compose file లో నమోదు చేయండి. తర్వాత docker compose up -d ను వర్తింపజేయండి. కొత్త కంటైనర్‌లో అది నిజంగా ఉందో మరో exec ద్వారా నిర్ధారించండి.

FAQ

docker compose exec మరియు docker compose run మధ్య తేడా ఏమిటి?

exec ఇప్పటికే నడుస్తున్న container లోని ప్రధాన process పక్కన ఒక command ను నడుపుతుంది. ఇది image entrypoint ను దాటవేస్తుంది. run అదే service definition నుంచి, అదే image, environment, volumes మరియు networks తో కొత్త container ను సృష్టిస్తుంది. ఇది మీ command ను entrypoint ద్వారా పంపి నడుపుతుంది. ముందుగా ఏవైనా depends_on services ఉంటే వాటిని కూడా ప్రారంభిస్తుంది. మీరు --service-ports జోడించకపోతే run service ports ను publish చేయదు. నడుస్తున్న service ను పరిశీలించడానికి exec ఉపయోగించండి. Service ఆగిపోయి ఉన్నప్పుడు లేదా దానికి అంతరాయం కలిగించకూడదనుకున్నప్పుడు run --rm ఉపయోగించండి.

docker compose exec service నడవడం లేదని ఎందుకు చూపిస్తుంది?

exec ఇప్పటికే ఉన్న container కు జతకడుతుంది; కొత్త container ను సృష్టించదు. అందువల్ల service ఆగిపోయి ఉన్నా లేదా crash అయినా service "web" is not running కనిపిస్తుంది. docker compose ps -a ను పరిశీలించండి. ఇది Exited (1) వంటి status తో exit అయిన containers ను జాబితా చేస్తుంది. ఆగిపోవడానికి గల కారణాన్ని తెలుసుకోవడానికి docker compose logs web చదవండి. అయినప్పటికీ shell పొందాలంటే docker compose run --rm --entrypoint sh web నడపండి. ఇది అదే service definition నుంచి కొత్త container ను నిర్మిస్తుంది. విఫలమైన start command ను నడపదు.

image లో bash లేకపోతే shell ను ఎలా తెరవాలి?

docker compose exec web bash విఫలమై exec: "bash": executable file not found in $PATH చూపిస్తే, image లో bash లేదని అర్థం. Alpine ఆధారంగా నిర్మించిన images లో ఇది సాధారణమే. docker compose exec web sh ఉపయోగించండి, ఎందుకంటే BusyBox /bin/sh ను అందిస్తుంది. Distroless మరియు scratch images లో అసలు shell ఉండదు. అందువల్ల ఏ exec command కూడా పనిచేయదు. Publisher అందిస్తే image యొక్క :debug tag కు మారండి. లేదా docker run --rm -it --network "container:$CID" --pid "container:$CID" nicolaka/netshoot తో target namespaces లో debug container ను ప్రారంభించండి. అందులో $CID, docker compose ps -q web నుంచి వస్తుంది.

cron లో నా exec command "the input device is not a TTY" అనే లోపంతో ఎందుకు విఫలమవుతుంది?

docker compose exec డిఫాల్ట్‌గా pseudo terminal ను అభ్యర్థిస్తుంది. cron ఎటువంటి pseudo terminal ను అందించదు. అందువల్ల మీ command నడవకముందే అభ్యర్థన విఫలమవుతుంది. దీన్ని ఆపివేయడానికి -T జోడించండి: docker compose exec -T db pg_dump -U postgres app. Redirect చేసిన లేదా pipe చేసిన output కు కూడా -T ఉపయోగించండి. TTY byte stream ను మార్చి binary dump ను దెబ్బతీయవచ్చు. cron లో మీ compose file కు absolute path తో -f కూడా ఇవ్వండి. లేకపోతే Compose no configuration file provided: not found తో నిష్క్రమిస్తుంది.

exec తో container లో చేసిన మార్పులు restart తర్వాత కూడా ఉంటాయా?

అవి docker compose restart వరకు ఉంటాయి. ఇందులో అదే container తిరిగి ఉపయోగించబడుతుంది. ఏదైనా image లేదా configuration మారిన తర్వాత docker compose up -d సమయంలో అవి కోల్పోతాయి. ఎందుకంటే అది image నుంచి container ను మళ్లీ సృష్టించి, దాని writable layer ను తొలగిస్తుంది. Named volumes లేదా bind mounts లో రాసిన data మాత్రం రెండింటి తర్వాత కూడా ఉంటుంది. అది container వెలుపల నిల్వ ఉంటుంది. Diagnostic మార్పులను exec తో చేయండి. శాశ్వత మార్పులను Dockerfile లేదా compose file లో నమోదు చేయండి.