Docker Compose கட்டளைகள்: முழுமையான வழிகாட்டி

நீங்கள் அடிக்கடி பயன்படுத்தும் Compose கட்டளைகள்

Docker Compose நாற்பதிற்கும் மேற்பட்ட துணைக்கட்டளைகளைக் கொண்டுள்ளது. ஒரு server-ல் தினசரி வேலைகளுக்கு ஒரு டஜன் கட்டளைகளே போதுமானவை. இந்தப் பக்கம் அவற்றைச் செய்யும் வேலைகளின் அடிப்படையில் வகைப்படுத்துகிறது, ஒவ்வொன்றிற்கும் ஒரு தெளிவான காரணத்தைக் கூறுகிறது, மேலும் ஒரு கட்டளை சிக்கலை மறைத்து வைத்திருக்கும்போது விரிவான விளக்கத்திற்கு வழிகாட்டுகிறது.

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

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

Lifecycle: நீங்கள் பயன்படுத்தும் நான்கு கட்டளைகள் மற்றும் 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 பெரும்பாலும் முதல் முயற்சியிலேயே தோல்வியடைகிறது. up -d --wait என்பது healthcheck-ஐக் கொண்ட ஒவ்வொரு service-ம் healthy என்று அறிவிக்கும் வரை காத்திருக்கும்; ஏதேனும் ஒன்று அந்த நிலையை அடையவில்லை எனில், இது non-zero exit code-ஐ வழங்கும். இந்த flag-ன் திறன் அதன் பின்னால் உள்ள check-ஐப் பொறுத்தது, எனவே நீங்கள் automation-ல் இதைப் பயன்படுத்துவதற்கு முன்பு Compose நம்பக்கூடிய ஒரு healthcheck-ஐ எழுதுங்கள்.

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

restart என்பது reload கிடையாது. இது ஏற்கனவே உள்ள configuration-உடன் அதே container-ஐ நிறுத்தி மீண்டும் தொடங்கும், எனவே மாற்றப்பட்ட environment variable, புதிய image tag அல்லது திருத்தப்பட்ட port mapping ஆகியவை எந்த மாற்றத்தையும் ஏற்படுத்தாது. ஒரு file மாற்றத்தைப் பயன்படுத்த நீங்கள் மீண்டும் up -d-ஐ இயக்க வேண்டும். Compose ஒவ்வொரு service-ஐயும் அதன் இயங்கும் container-உடன் ஒப்பிட்டு, configuration மாறியவற்றை மட்டும் மீண்டும் உருவாக்கும்.

மாற்றங்களைச் செயல்படுத்துதல்: 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-ஐப் புதுப்பிக்க இரண்டு கட்டளைகள் தேவைப்படுகின்றன, ஏனெனில் அவை இரண்டு வெவ்வேறு பணிகளைச் செய்கின்றன. pull கோப்பில் குறிப்பிடப்பட்டுள்ள ஒவ்வொரு tag-க்கும் தற்போதைய image-ஐத் தரவிறக்கம் செய்கிறது. அதன் பிறகு up -d, service-ன் image ID தற்போது இயங்கும் container-உடன் பொருந்தவில்லை என்பதைக் கண்டறிந்து, அதை மீண்டும் உருவாக்குகிறது (recreate). pull கட்டளையைத் தவிர்த்தால், up -d கடந்த மாதத்தின் latest-ஐ எந்தப் பிழையும் இன்றி தொடர்ந்து இயக்கும். பல service-களைக் கொண்ட stack-ல் இதற்கு நேர்மாறான ஆபத்து உள்ளது; அனைத்து service-களுக்கும் ஒரே நேரத்தில் latest-ஐப் பயன்படுத்தினால், பத்து வினாடிகளுக்கு முன்பு சரியாக இயங்கிக்கொண்டிருந்த app செயலிழக்கக்கூடும். இதனால்தான் ஒரு self-hosted AFFiNE workspace அதன் நான்கு image tag-களையும் தனித்தனியாகப் பிணைத்து (pin) வைத்துள்ளது.

build என்பது image:-க்கு பதிலாக build: பகுதியை அறிவிக்கும் service-களுக்குப் பொருந்தும். up -d --build ஒரே கட்டத்தில் build செய்து தொடங்கும், இது நீங்கள் code-ஐ மாற்றும்போது பயன்படுத்தும் வழக்கமான முறையாகும். cached layer பழையதாகிவிட்டது என்று உறுதியாகத் தெரிந்தால் மட்டுமே --no-cache-ஐப் பயன்படுத்தவும், ஏனெனில் இது ஒவ்வொரு layer-ஐயும் புதிதாக மீண்டும் உருவாக்கும்.

இயங்கிக்கொண்டிருப்பவற்றைப் பார்த்தல்

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-ல் ஒரு container இல்லை, ஆனால் ps -a-ல் அது Exited (1) எனக் காட்டுகிறது என்றால், அது ஒரு startup failure-ன் பொதுவான அறிகுறியாகும். Exit code-ஐப் படித்துவிட்டு, அதன் பிறகு logs-ஐப் பார்க்கவும்.

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

top ஒவ்வொரு container-க்குள் இயங்கும் process-களைப் பட்டியலிடும். இது "container இயங்குகிறது" என்பதற்கும் "அதற்குள் இருக்கும் process இயங்குகிறது" என்பதற்கும் உள்ள வேறுபாட்டைத் தெளிவுபடுத்தும். ls தற்போதைய directory-க்கு வெளியே சென்று, host-ல் உள்ள ஒவ்வொரு Compose project-ஐயும் அதன் நிலையுடன் பட்டியலிடும். இதன் மூலம் மூன்று மாதங்களுக்கு முன்பு நீங்கள் தொடங்கிய 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

ஏற்கனவே இயங்கிக்கொண்டிருக்கும் container-க்குள் ஒரு command-ஐ இயக்க exec பயன்படுகிறது. ஒரு service நீண்ட நேரம் இயங்காமல், உடனே நின்றுவிடும் சூழலில், அதன் service definition-ஐப் பயன்படுத்தி புதிய container-ஐத் தொடங்க run தேவைப்படுகிறது. run-ஐ எப்போதும் --rm உடன் பயன்படுத்தவும்; இல்லையெனில், ஒவ்வொரு முறையும் ஒரு stopped container எஞ்சியிருக்கும். இவை குவியத் தொடங்கினால், docker compose ps -a-ஐ வாசிப்பது கடினமாகிவிடும்.

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

ஒவ்வொரு .env கோப்பு, environment: தொகுதி மற்றும் shell variable ஆகியன ஒன்றிணைக்கப்பட்ட பிறகு, ஒரு service உண்மையில் பெற்ற environment-ஐக் காண run --rm web env மிக வேகமான வழியாகும். ஒரு மதிப்பு தவறாக இருந்தால், அதற்கு வழக்கமாக merge வரிசையே காரணமாக இருக்கும். Compose எவ்வாறு env கோப்புகள் மற்றும் secrets-ஐத் தீர்க்கிறது என்பதில் எந்த 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 பெயரும் அதில் ஒரு DNS பெயராகச் செயல்படுகிறது. getent hosts db-ஐ web-க்குள் இயக்குவது, name resolution சரியாக வேலை செய்யும்போது container IP-ஐக் காட்டும்; வேலை செய்யவில்லை எனில் எதையும் காட்டாது. எனவே, "இந்த container-கள் ஒன்றையொன்று பார்க்க முடியுமா" என்ற கேள்விக்கு இது இரண்டு நொடிகளில் பதிலளித்துவிடும். பெயர் சரியாகத் தெரிந்தும் connection நிராகரிக்கப்பட்டால், db-க்குள் இருக்கும் process 0.0.0.0-க்கு பதிலாக 127.0.0.1-ல் bound ஆகியிருக்கலாம்; இதனால் அது மற்றொரு container-லிருந்து வரும் packet-களை ஏற்காது. இந்த மாதிரியின் மீதமுள்ள விவரங்கள் Compose networks மற்றும் service DNS எவ்வாறு செயல்படுகின்றன என்பதில் உள்ளன.

port web 80 ஒரு container port எந்த host முகவரி மற்றும் port-ல் வெளியிடப்பட்டுள்ளது என்பதைக் காட்டுகிறது; mapping ஒரு variable-லிருந்து வரும்போது இது ஊகிப்பதைத் தவிர்க்க உதவுகிறது. ஒரு port-ஐ வெளியிடுவது Docker தானாகவே நிர்வகிக்கும் ஒரு firewall rule-ஐ உருவாக்குகிறது. அந்த rule உங்கள் firewall rule-களுக்கு முன்னால் அமர்வதால், நீங்கள் private என்று நினைத்த service இணையத்திற்குத் திறந்திருக்கலாம். இந்தச் சூழல் ஏன் வெளியிடப்பட்ட Docker ports ufw-ஐத் தவிர்க்கின்றன என்பதில் விளக்கப்பட்டுள்ளது. அந்த port-களை வெளியிடாமல், project network-ல் உள்ள service-களுக்கு முன்னால் ஒரு authenticating proxy-ஐ வைப்பதே பாதுகாப்பான முறையாகும். இதுவே Authentik-ஐ single sign-on அடுக்காக இயக்குதல் உங்களுக்கு வழங்குகிறது.

Volumes மற்றும் தரவு

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-ல் மாற்ற முடியாத முக்கியமான தரவுகள் இருக்கும்போது, அந்தப் பட்டியலை விட, அதை backup எடுக்கும் சரியான command மிக முக்கியமானது. இதனால்தான் PhotoPrism மற்றும் Immich ஒப்பீடு பகுதியில் ஒவ்வொரு photo server-க்கும் தேவையான dump மற்றும் copy கட்டளைகள் விளக்கப்பட்டுள்ளன. cp என்பது shell-ஐத் திறக்காமலேயே ஒரு container-க்குள் அல்லது வெளியே கோப்புகளை நகலெடுக்கப் பயன்படுகிறது. இதில் container-ஐக் குறிக்கும் பக்கத்தில் service:path என்ற வடிவம் பயன்படுத்தப்படுகிறது.

down -v என்பது named volumes மற்றும் containers ஆகியவற்றை முழுமையாக நீக்கிவிடும். ஒரு test stack-ஐ முழுமையாக அகற்றுவதற்கு இது சரியான கட்டளை. ஆனால், முக்கியமான தரவுகள் உள்ள எதற்கும் இதைப் பயன்படுத்தக்கூடாது, ஏனெனில் இதில் உறுதிப்படுத்தல் (confirmation) கேட்கப்படாது மற்றும் நீக்கியதை மீண்டும் பெற முடியாது. Bind mounts-ஐப் பொறுத்தவரை, அவை host filesystem-ல் இருப்பதால், இந்த கட்டளையினால் பாதிக்கப்படாது. இந்த பாதுகாப்பு இடைவெளிதான் 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 ஆகியவற்றைத் தனித்தனியாகப் பிரித்து, ஒவ்வொன்றிலும் எவ்வளவு இடத்தை மீட்க முடியும் என்பதைக் குறிப்பிடுகிறது. image prune -a, எந்த tag-உம் இல்லாத அனைத்து images-ஐயும் நீக்குகிறது. பல பதிப்புகளைக் கொண்ட பெரிய image-களைப் பதிவிறக்கியுள்ள server-களில், இதுவே அதிக இடத்தை மீட்டுத்தரும். builder prune, build cache-ஐ நீக்குகிறது. சொந்தமாக images-ஐ உருவாக்கும் எந்தவொரு server-லும் இது மெதுவாக வளர்ந்து கொண்டே இருக்கும்.

இவை எதுவும் named volume-களைப் பாதிக்காது. docker volume prune மற்றும் docker compose down -v மட்டுமே அவற்றை நீக்கும்.

கோப்பு சிதைவதற்கு முன்பே அதைச் சரிபார்த்தல்

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

config --quiet கட்டளையானது வெற்றிகரமாக இருந்தால் எதையும் அச்சிடாது, எனவே இதை ஒரு pre-deploy நிலையிலோ அல்லது git hook-லோ பயன்படுத்த வேண்டும். config கட்டளையானது முழுமையாக இணைக்கப்பட்ட மற்றும் interpolated செய்யப்பட்ட கோப்பை அச்சிடும்; இதன் மூலம் ஒரு variable சரியாக resolved ஆகி உள்ளதா என்பதையும், override கோப்பு நீங்கள் எதிர்பார்த்தபடி இணைந்துள்ளதா என்பதையும் உறுதிப்படுத்தலாம். ஒரு variable unset செய்யப்பட்டிருந்தால், அது 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 வரிசைப்படி ஒன்றிணைக்கப்படுகின்றன, மேலும் பிந்தைய கோப்புகள் முந்தைய கோப்புகளை key வாரியாக மாற்றியமைக்கின்றன. ஒரு அடிப்படை கோப்பை வைத்துக்கொண்டு, சிறிய production மாற்றங்களைச் செய்வதற்கு இதுவே நிலையான வழியாகும். இருப்பினும், lists மற்றும் maps-க்கு விதிகள் மாறுபடும் என்பதால், எதிர்பாராத முடிவுகளைத் தவிர்க்க Compose பல கோப்புகளை எவ்வாறு ஒன்றிணைக்கிறது என்பதைப் படிக்கவும்.

--profile, அந்த profile-ல் குறிக்கப்பட்ட services-ஐ, குறிக்கப்படாதவற்றுடன் சேர்த்துத் தொடங்குகிறது. இது debug கருவிகளை சாதாரண up-ல் இருந்து விலக்கி வைக்க உதவுகிறது. -p project பெயரை அமைக்கிறது, எனவே ஒரே stack-ன் இரண்டு பிரதிகளை தனித்தனி networks மற்றும் தனித்தனி volume பெயர்களுடன் அருகருகே இயக்க முடியும். ஒரு reboot-க்கு பிறகு stack-ஐ மீண்டும் பெறுவது என்பது நீங்கள் தட்டச்சு செய்யும் கட்டளை அல்ல; அது உங்களுக்காக அதை இயக்கும் ஒரு unit ஆகும். இது Compose stacks-ஐ boot-ல் தொடங்குதல் என்பதில் விவரிக்கப்பட்டுள்ளது.

FAQ

docker-compose-க்கு பதிலாக ஹைஃபன் (-) எதனால் மாற்றப்பட்டது?

Compose V2, docker compose என்று ஒரு இடைவெளியுடன் (space) அழைக்கப்படுகிறது. இது Docker Engine-உடன் இணைக்கப்பட்ட ஒரு plugin ஆகும்; தற்போதைய தொகுப்புகளில் (packages) பழைய V1 Python கருவி வழங்கப்படுவதில்லை. இடைவெளியுடன் கூடிய கட்டளை எதையும் காட்டவில்லை என்றால், உங்கள் distribution-க்கு ஏற்ற docker-compose-plugin தொகுப்பை நிறுவவும். பழைய script-களை alias மூலம் மாற்றாமல், இடைவெளி கொண்ட வடிவத்திற்கு மாற்றவும்; ஏனெனில் V1-ல் இல்லாத பல புதிய flags V2-ல் உள்ளன.

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

restart ஏற்கனவே உள்ள container-ஐ அது உருவாக்கப்பட்ட அதே configuration-உடன் நிறுத்தி மீண்டும் தொடங்கும், அது ஒருபோதும் compose.yaml-ஐ மீண்டும் படிக்காது. Environment variables, ports, volumes அல்லது image tag ஆகியவற்றில் செய்யப்படும் எந்த மாற்றத்திற்கும் docker compose up -d தேவைப்படுகிறது; இது ஒவ்வொரு service-ஐயும் இயங்கும் container-உடன் ஒப்பிட்டு, மாற்றங்கள் இருந்தால் அவற்றை மீண்டும் உருவாக்கும். கோப்பில் எந்த மாற்றமும் இல்லாதபோதும் container-ஐ மாற்ற விரும்பினால் --force-recreate-ஐச் சேர்க்கவும்.

ஒரு service-ஐ புதிய image-க்கு எவ்வாறு மேம்படுத்துவது?

முதலில் docker compose pull, பிறகு docker compose up -d ஆகியவற்றை இயக்கவும். Pull கட்டளை கோப்பில் உள்ள ஒவ்வொரு tag-க்கும் தற்போதைய image-ஐப் பதிவிறக்கும், மேலும் up -d கட்டளை எந்த service-ன் image ID அதன் container-உடன் பொருந்தவில்லையோ அதை மீண்டும் உருவாக்கும். up -d-ஐ மட்டும் இயக்கினால், வட்டில் ஏற்கனவே உள்ள image-ஐயே அது பயன்படுத்தும். இதனால்தான் latest-ல் உள்ள stack, பல மாதங்கள் பழைய build-ல் இருந்தாலும் எந்தப் பிழையும் காட்டாமல் இயங்குகிறது.

நேரடி server-ல் எந்தெந்த cleanup கட்டளைகள் பாதுகாப்பானவை?

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

முழு stack-ஐயும் தொடங்காமல் ஒரு கட்டளையை மட்டும் இயக்க முடியுமா?

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