உண்மையான Server-களுக்கான Docker Compose Cheat Sheet

நீங்கள் உண்மையில் பயன்படுத்தும் Compose commands

Docker Compose நாற்பதுக்கும் மேற்பட்ட subcommands-ஐ வழங்குகிறது. Server-ல் தினசரி பணிகளுக்கு அவற்றில் சுமார் ஒரு டஜன் commands மட்டுமே தேவைப்படும். நீங்கள் செய்யும் பணியின் அடிப்படையில் இந்தப் பக்கம் அவற்றைக் குழுவாகப் பிரிக்கிறது. ஒவ்வொரு command-க்கும் ஒரு தெளிவான காரணத்தை வழங்குகிறது. Command-ல் மறைந்துள்ள சிக்கல் இருந்தால், அதற்கான விரிவான விளக்கத்திற்கும் வழிகாட்டுகிறது.

இங்கு அனைத்தும் Compose V2-ஐப் பயன்படுத்துகின்றன: docker compose இடைவெளியுடன் பயன்படுத்த வேண்டும்; பழைய docker-compose script-ஐ அல்ல. V2 என்பது Docker Engine உடன் install ஆகும் Go plugin ஆகும். தற்போதைய packages-ல் V1 நீக்கப்பட்டுவிட்டதால், July 2026 நிலவரப்படி புதிதாக நிறுவப்பட்ட Ubuntu box-ல் docker-compose: command not found காணப்படுவது எதிர்பார்க்கப்படும் நிலை; அது கோளாறு அல்ல. docker compose version மூலம் சரிபார்க்கவும். அது எதையும் காட்டவில்லை என்றால், docker-compose-plugin package-ஐ install செய்யவும்.

கீழே உள்ள ஒவ்வொரு command-ஐயும் உங்கள் compose.yaml இருக்கும் directory-ல் இருந்து இயக்க வேண்டும். Compose project name-ஐ அந்த directory-யிலிருந்து பெறுகிறது; file-ஐயும் அதனுடன் தொடர்புடைய பாதையில் தேடுகிறது. அதே command-ஐ அதற்கு ஒரு level மேலுள்ள directory-ல் இயக்கினால், Compose no configuration file provided: not found என்ற பிழையுடன் நிறுத்தப்படும். File format உங்களுக்கு புதிதாக இருந்தால், முதலில் VPS-ல் முதல் Compose file என்பதைப் படிக்கவும். பின்னர் commands-க்காக இங்கு திரும்பி வரவும்.

Lifecycle: நீங்கள் பயன்படுத்தும் நான்கு commands மற்றும் containers-ஐ அகற்றும் command

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 created நிலையில் வந்தவுடன் இது முடிவடைகிறது. அதனால் இதற்குப் பிறகு curl probe-ஐ இயக்கும் deploy script, முதல் முயற்சியில் பெரும்பாலும் தோல்வியடைகிறது. up -d --wait healthcheck அறிவிக்கப்பட்டுள்ள ஒவ்வொரு service-மும் healthy என report செய்யும் வரை காத்திருக்கும். ஏதேனும் service healthy நிலையை அடையாவிட்டால், இது non-zero status-உடன் முடிவடைகிறது. இந்த flag-ன் செயல்திறன், அதன் பின்னால் உள்ள check-ன் தரத்தைப் பொறுத்தது. எனவே automation-ல் இதை நம்புவதற்கு முன், Compose நம்பக்கூடிய healthcheck ஒன்றை எழுதவும்.

stop containers-ஐ நிறுத்தி, அவற்றை வைத்திருக்கும். எனவே start அதே writable layer-உடன் அதே containers-ஐ மீண்டும் தொடங்கும். down containers-ஐ நிறுத்திய பிறகு, containers மற்றும் project network-ஐ அகற்றும். container-ன் உள்ளே எழுதப்பட்டு, volume-க்கு வெளியே இருக்கும் அனைத்தும் அவற்றுடன் அகற்றப்படும். Compose-ல் இது அதிக செலவான தவறான புரிதலாகும். down மற்றும் stop ஆகியவற்றுக்கிடையிலான முழு வேறுபாடு எந்தச் சூழலில் பாதிப்பு ஏற்படும் என்பதை விளக்குகிறது.

restart reload அல்ல. ஏற்கனவே உள்ள configuration-உடன் அதே container-ஐ நிறுத்தி மீண்டும் தொடங்குகிறது. எனவே மாற்றிய environment variable, புதிய image tag, அல்லது திருத்திய port mapping எதுவும் செயல்படாது. file மாற்றத்தை அமல்படுத்த up -d-ஐ மீண்டும் இயக்க வேண்டும். 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-உம் இல்லாமல் தொடர்ந்து இயக்கும். இதற்கு மாறாக, பல services கொண்ட stack-ல் ஒவ்வொரு service-க்குமான latest-ஐ ஒரே நேரத்தில் pull செய்வது, பத்து விநாடிகளுக்கு முன்பு சரியாக இயங்கிய application-ஐ பாதிக்கக்கூடும். அதனால் self-hosted AFFiNE workspace-ல் உள்ள நான்கு image tags-களும் தனித்தனியாக pin செய்யப்படுகின்றன. Pinning செய்வதால் upgrade என்பது tag-ஐ திட்டமிட்டு edit செய்து, அதே pull மற்றும் recreate செயல்முறையைத் தொடர்ந்து செய்வதாக மாறுகிறது. Boot ஆகும்போது database-ஐ migrate செய்யும் stack-ல், இவற்றில் ஏதேனும் command-ஐ இயக்குவதற்கு முன் dump தயாராக வைத்திருக்க வேண்டும். ஒவ்வொரு version bump-க்கும் self-hosted Chatwoot support desk பின்பற்றும் நடைமுறை இதுவாகும்.

build, image:-க்கு பதிலாக build: section-ஐ declare செய்யும் services-க்கு பொருந்தும். up -d --build ஒரே படியில் build செய்து start செய்கிறது. Code-ஐ மாற்றிக்கொண்டிருக்கும் போது இது வழக்கமான loop ஆகும். Cached layer தெளிவாக stale ஆக இருக்கும் போது மட்டும் --no-cache-ஐ பயன்படுத்தவும். அது ஒவ்வொரு layer-ஐயும் ஆரம்பத்திலிருந்து மீண்டும் build செய்யும். Registry image-க்கு பதிலாக checked out git tag-இலிருந்து stack deploy செய்யப்படும்போது, இதே build loop update path-ஆகவும் செயல்படும். self-hosted openGym workout tracker pinned version-இலிருந்து அடுத்த pinned 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 -a அதை Exited (1) நிலையில் இருப்பதாகக் காட்டும் போது ps-ல் அந்த container இல்லாதிருப்பது startup failure-ன் வழக்கமான அறிகுறியாகும். முதலில் exit code-ஐப் பார்க்கவும். பின்னர் logs-ஐப் பார்க்கவும்.

logs -f அனைத்து services-ன் output-ஐ ஒரே நேரத்தில் பின்தொடரும். ஒவ்வொரு வரியின் முன்பும் service name சேர்க்கப்படும். Services ஒன்றுடன் ஒன்று தொடர்புகொள்ளும் போது, events நடந்த வரிசை முக்கியமாக இருக்கும் போது, இதுவே தேவையான பார்வையாகும். குறிப்பிட்ட service-ன் பெயரை வழங்கி வெளியீட்டைச் சுருக்கலாம். ஒரு container ஒரு மாதமாக இயங்கிக்கொண்டிருந்தால் --tail=100 முக்கியமானது. ஏனெனில் default முறையில் முழு history-யும் அச்சிடப்பட்டு terminal நிரம்பிவிடும். நீங்கள் இப்போது செய்த restart-ன் போது என்ன நடந்தது என்பதே பொதுவாகத் தேவைப்படும் பதில். அதற்கு --since 15m பயன்படும்.

top ஒவ்வொரு container-க்குள்ளும் இயங்கும் processes-ஐப் பட்டியலிடும். இதன் மூலம் “container இயங்குகிறது” என்பதையும் “அதற்குள் உள்ள process இயங்குகிறது” என்பதையும் வேறுபடுத்தலாம். ls தற்போதைய directory-யைத் தாண்டி, host-ல் உள்ள அனைத்து Compose projects-ஐ அவற்றின் status உடன் பட்டியலிடும். இதனால் மூன்று மாதங்களுக்கு முன்பு தொடங்கிய stack-ஐக் கண்டறியலாம்.

service-க்குள் 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-ஐ தொடங்கும். Service, அதற்குள் exec செய்யும் அளவுக்கு நீண்ட நேரம் இயங்காமல் இருக்கும் போது இதுவே தேவைப்படும். run-ஐ எப்போதும் --rm உடன் இணைத்துப் பயன்படுத்தவும். இல்லையெனில் ஒவ்வொரு invocation-மும் நிறுத்தப்பட்ட container-ஐ விட்டுச் செல்லும். அவை குவிந்து, இறுதியில் docker compose ps -a படிக்க முடியாத நிலையை உருவாக்கும்.

bash-க்கு முன் sh-ஐ முயற்சிக்கவும். Alpine அடிப்படையிலான images-ல் bash இருக்காது. அப்போது பிழை exec: "bash": executable file not found in $PATH எனக் காட்டப்படும். run-க்கு --no-deps சேர்த்தால், அந்த service-ன் dependencies தவிர்க்கப்படும். இதனால் விரைவான configuration check செய்யும்போது முழு database-ஐத் தொடங்க வேண்டியதில்லை.

ஒவ்வொரு .env file, environment: block மற்றும் shell variable-உம் merge செய்யப்பட்ட பிறகு, service உண்மையில் பெற்ற environment-ஐப் பார்க்க run --rm web env மிக விரைவான வழியாகும். ஒரு value தவறாக இருந்தால், அதற்கான காரணம் பொதுவாக merge order ஆகும். Compose env files மற்றும் secrets-ஐ எவ்வாறு resolve செய்கிறது என்ற பகுதியில் எந்த source-க்கு முன்னுரிமை கிடைக்கும் என்பது விளக்கப்பட்டுள்ளது.

Networks, ports, and 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-க்குள் இயக்கினால் container IP அச்சிடப்படும். Resolution செயல்படவில்லை என்றால் எதுவும் அச்சிடப்படாது. ஆகவே, “இந்த containers ஒன்றையொன்று பார்க்க முடியுமா?” என்ற கேள்விக்கு இது இரண்டு வினாடிகளில் பதிலளிக்கிறது. Name resolve ஆகிறது, ஆனால் connection refused என வந்தால், db-க்குள் உள்ள process 0.0.0.0-க்கு பதிலாக 127.0.0.1-ல் bind செய்யப்பட்டிருக்கிறது. அதனால் மற்றொரு container-இலிருந்து வரும் packet-ஐ அது ஏற்காது. Project-க்கு வெளியே தொடங்கப்பட்ட container-களுக்கும் இதே network boundary பொருந்தும். docker run மூலம் தொடங்கப்பட்ட container ஆக இருந்தாலும், தனித்த stack ஆக இருந்தாலும், அது jellyfin போன்ற name-ஐ resolve செய்ய முடியாது. உங்கள் Jellyfin library-க்கான Halcyon front end அது குறிப்பிடும் server-ஐ அணுக முடியாதபோது, முதலில் இதைத்தான் சோதிக்க வேண்டும். இந்த model-ன் மீதமுள்ள விளக்கம் Compose networks மற்றும் service DNS எவ்வாறு செயல்படுகின்றன என்பதில் உள்ளது.

port web 80 container port publish செய்யப்பட்டுள்ள host address மற்றும் port-ஐ அச்சிடுகிறது. Mapping ஒரு variable-ல் இருந்து வந்திருந்தால், ஊகிக்க வேண்டிய அவசியத்தை இது நீக்குகிறது. Port-ஐ publish செய்வது Docker தானாக நிர்வகிக்கும் firewall rule-ஐயும் உருவாக்குகிறது. அந்த rule, நீங்கள் உருவாக்கிய rule-க்கு முன்பாகச் செயல்படும். எனவே private-ஆக இருக்க வேண்டும் என்று நீங்கள் கருதிய service internet-க்கு திறந்திருக்கலாம். இந்த நிலை published Docker ports ufw-ஐ ஏன் கடந்து செல்கின்றன என்பதில் விளக்கப்பட்டுள்ளது. அந்த ports-ஐ publish செய்யாமல் விட்டு, project network-ல் services-க்கு முன்பாக authentication செய்யும் ஒரே proxy-ஐ அமைப்பது பாதுகாப்பான அமைப்பாகும். இதையே Authentik-ஐ single sign-on layer ஆக இயக்குதல் வழங்குகிறது.

Volumes மற்றும் data

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

config --volumes project அறிவிக்கும் named volumes-ஐ ஒவ்வொன்றாக ஒரு வரியில் காட்டும். நீங்கள் backup எடுக்க வேண்டியது அந்தப் பட்டியலே. Volumes-ல் மீண்டும் உருவாக்க முடியாத data இருந்தால், அந்தப் பட்டியலுக்கு இணையாகச் சரியான backup command-மும் முக்கியம். அதனால் PhotoPrism மற்றும் Immich ஒப்பீடு ஒவ்வொரு photo server-க்கும் தேவையான dump மற்றும் copy commands-ஐத் தெளிவாகக் குறிப்பிடுகிறது. cp shell திறக்காமல், container-க்கு அல்லது container-இலிருந்து file-ஐ copy செய்கிறது. இதற்காக container இருக்கும் பக்கத்தில் service:path form பயன்படுத்தப்படுகிறது.

down -v containers-உடன் அந்த named volumes-ஐயும் நீக்குகிறது. Test stack-ஐ முழுமையாக அகற்ற இது சரியான command. நீங்கள் பாதுகாக்க வேண்டிய data உள்ள எதற்கும் இது தவறான command. ஏனெனில் confirmation எதுவும் கேட்காது; undo வசதியும் இல்லை. Bind mounts இதனால் பாதிக்கப்படாது. அவை host filesystem-ல் இருப்பதால் தொடர்ந்து இருக்கும். இந்த blast radius வேறுபாடு காரணமாகவே bind mounts மற்றும் named volumes ஆகியவற்றில் எதைப் பயன்படுத்துவது என்பதைத் திட்டமிட்டு தேர்ந்தெடுக்க வேண்டும்.

தரவை இழக்காமல் disk இடத்தை விடுவிக்கும் cleanup

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

--remove-orphans project-க்கு சேர்ந்துள்ள, ஆனால் file-ல் இனி இடம்பெறாத containers-ஐ delete செய்கிறது. Service-ஐ rename செய்த பிறகு இதுவே ஏற்படும். இதை இயக்காமல் விட்டால், அந்த containers தொடர்ந்து இயங்கும். அவை docker compose ps-ல் தெரியாது.

எதையும் delete செய்வதற்கு முன் disk இடம் எங்கு பயன்படுத்தப்பட்டுள்ளது என்பதை docker system df காட்டுகிறது. இது images, containers, local volumes மற்றும் build cache ஆகியவற்றைத் தனித்தனியாகப் பிரித்து, ஒவ்வொன்றிற்கும் reclaim செய்யக்கூடிய அளவைக் காட்டுகிறது. எந்த tag-மும் குறிப்பிடாத images அனைத்தையும் image prune -a நீக்குகிறது. பெரிய image-ன் பல versions-ஐ pull செய்த server-ல் இது பொதுவாக அதிக disk இடத்தை விடுவிக்கும். தானாக images-ஐ build செய்யும் எந்த server-லும் அமைதியாக வளரக்கூடிய build cache-ஐ builder prune அழிக்கிறது.

இவற்றில் எதுவும் named volume-ஐத் தொடாது. docker volume prune மற்றும் docker compose down -v மட்டுமே அவற்றை மாற்றும்.

ஏதேனும் பாதிப்பை ஏற்படுத்தும் முன் file-ஐச் சரிபார்த்தல்

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

config --quiet வெற்றியடைந்தால் validation செய்து எதையும் print செய்யாது. ஆகவே, இது pre-deploy step அல்லது git hook-ல் இடம்பெற வேண்டும். சாதாரண config முழுமையாக merge செய்யப்பட்டு interpolate செய்யப்பட்ட file-ஐ print செய்யும். இதன் மூலம் variable சரியாக resolve ஆனதையும், override file எதிர்பார்த்தபடி layer செய்யப்பட்டதையும் உறுதிப்படுத்தலாம். Unset variable அங்கு empty value-ஆகத் தோன்றும்; அதனுடன் warning The "X" variable is not set. Defaulting to a blank string. இருக்கும்.

--dry-run என்பது subcommand flag அல்ல; global flag. ஆகவே, இது up-க்கு முன் வர வேண்டும். Compose மேற்கொள்ளும் ஒவ்வொரு action-ஐயும் இது print செய்யும்; எந்த மாற்றத்தையும் செய்யாது. முக்கியமான 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 ஆகும். பின்னர் வரும் files, ஒவ்வொரு key அடிப்படையிலும் முன்னதாக வந்த files-ஐ override செய்யும். ஒரு சிறிய production override உடன் ஒரு base file-ஐ வைத்திருப்பதற்கான நிலையான முறை இதுவாகும். ஆனால் lists மற்றும் maps-க்கு விதிகள் வேறுபடும். ஆகவே எதிர்பாராத merge முடிவை debug செய்வதற்கு முன் பல files-ஐ Compose எவ்வாறு merge செய்கிறது என்பதைப் படிக்கவும்.

--profile அந்த 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 என்பதற்குப் பதிலாக hyphen உடன் வந்தது எது?

Compose V2. இது இடைவெளியுடன் docker compose ஆக இயக்கப்படுகிறது. இது Docker Engine-உடன் சேர்க்கப்பட்ட plugin ஆகும். தற்போதைய packages மூலம் V1 Python tool இனி install செய்யப்படாது. இடைவெளி வடிவம் எந்த output-ஐயும் காட்டவில்லை என்றால், உங்கள் distribution-க்கான docker-compose-plugin package-ஐ install செய்யவும். Alias சேர்ப்பதற்குப் பதிலாக, பழைய scripts-ஐ இடைவெளி வடிவத்திற்கு மாற்றவும். ஏனெனில் V2-ல் V1-ல் இல்லாத flags உள்ளன.

docker compose restart என் configuration மாற்றத்தை ஏன் எடுத்துக்கொள்ளவில்லை?

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-ஐ இயக்கவும். File-ல் உள்ள ஒவ்வொரு tag-க்குமான தற்போதைய image-ஐ pull பெறும். அதன் image ID, container-ன் image ID-யுடன் பொருந்தாத service-களை up -d மீண்டும் உருவாக்கும். up -d-ஐ மட்டும் இயக்கினால், disk-ல் ஏற்கனவே உள்ள image மீண்டும் பயன்படுத்தப்படும். இதனால் latest-க்கு pinned செய்யப்பட்ட stack, எந்த error-ஐயும் காட்டாமல் பல மாதங்கள் பழைய build-ல் தொடர்ந்து இயங்கலாம்.

இயங்கிக்கொண்டிருக்கும் server-ல் எந்த cleanup commands பாதுகாப்பானவை?

docker system df, docker image prune -a மற்றும் docker builder prune images மற்றும் cache-ஐ மட்டும் remove செய்கின்றன. எனவே running services தொடர்ந்து இயங்கும்; named volumes பாதிக்கப்படாது. ஆபத்தான pair docker compose down -v மற்றும் docker volume prune ஆகும். இவை எந்த prompt-உம் இல்லாமல் named volumes-ஐ delete செய்யும். எது பாதிக்கப்படலாம் என்பதை அறிய முதலில் docker compose config --volumes-ஐ இயக்கவும்.

முழு stack-ஐ start செய்யாமல் ஒரு command-ஐ இயக்க முடியுமா?

ஆம். docker compose run --rm --no-deps web sh, web service definition-ஐப் பயன்படுத்தி ஒரு container-ஐ மட்டும் start செய்கிறது. இது அதன் dependencies-ஐ skip செய்து, நீங்கள் exit செய்யும்போது container-ஐ remove செய்கிறது. Container ஏற்கனவே running நிலையில் இருந்தால் exec-ஐப் பயன்படுத்தவும். ஏனெனில் exec live process-ல் இணைந்து, service உண்மையில் இயங்கிக்கொண்டிருக்கும் நிலையை காட்டும்.