நிஜ server-களுக்கான Docker Compose commands வழிகாட்டி

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

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

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

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

build என்பது image:-க்குப் பதிலாக build: section-ஐ அறிவிக்கும் services-க்கு பொருந்தும். up -d --build ஒரே படியில் build செய்து start செய்கிறது. Code-ஐ மாற்றிக் கொண்டிருக்கும் போது இதுவே வழக்கமான workflow ஆகும். Cached layer தெளிவாக stale ஆக இருக்கும் போது மட்டும் --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-ன் பெயரைக் குறிப்பிடவும். ஒரு 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 படிக்க முடியாத நிலையை ஏற்படுத்தும்.

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

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

Networkகள், portகள் மற்றும் 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 ஆகும். web-க்குள் getent hosts db-ஐ இயக்கினால், resolution வெற்றியடைந்தபோது container IP அச்சிடப்படும். resolution தோல்வியடைந்தால் எதுவும் அச்சிடப்படாது. எனவே, “இந்த containerகள் ஒன்றையொன்று காண முடியுமா” என்ற கேள்விக்கு இது 2 வினாடிகளில் பதிலளிக்கிறது. name resolve ஆகிறது, ஆனால் connection மறுக்கப்பட்டால், db-க்குள் உள்ள process 0.0.0.0-க்கு பதிலாக 127.0.0.1-ல் bind செய்யப்பட்டிருக்கிறது. அதனால் மற்றொரு container-லிருந்து வரும் packet-ஐ அது ஏற்காது. இந்த model-ன் மீதமுள்ள விளக்கம் Compose networkகளும் service DNS-உம் எவ்வாறு செயல்படுகின்றன என்பதில் உள்ளது.

ஒரு container port publish செய்யப்பட்டுள்ள host address மற்றும் port-ஐ port web 80 அச்சிடுகிறது. Mapping ஒரு variable-லிருந்து வந்தபோது ஊகிக்க வேண்டிய அவசியத்தை இது நீக்குகிறது. ஒரு port-ஐ publish செய்வது Docker தானாக நிர்வகிக்கும் firewall rule-ஐயும் எழுதுகிறது. அந்த rule, உங்கள் rule-களுக்கு முன்னதாகச் செயல்படும். எனவே private என்று நீங்கள் கருதிய service இணையத்திற்குத் திறந்திருக்கலாம். இந்த நிலை published Docker portகள் 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 project அறிவிக்கும் named volumes-ஐ ஒவ்வொரு வரியிலும் காட்டுகிறது. அந்தப் பட்டியலில் உள்ளவற்றையே backup செய்ய வேண்டும். cp shell திறக்காமல், ஒரு file-ஐ container-க்குள் அல்லது container-இலிருந்து வெளியே copy செய்கிறது. Container இருக்கும் பக்கத்தில் service:path form-ஐ பயன்படுத்தவும்.

down -v containers-உடன் அந்த named volumes-ஐயும் நீக்குகிறது. Test stack-ஐ அகற்றுவதற்கு இது சரியான command. நீங்கள் பாதுகாக்க வேண்டிய data உள்ள எதற்கும் இது தவறான command. ஏனெனில் confirmation இல்லை; undo செய்யும் வழியும் இல்லை. Bind mounts host filesystem-ல் இருப்பதால், இந்த command அவற்றை பாதிக்காது. இந்த 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 file-ல் இனி காணப்படாத, ஆனால் project-க்கு உரிய containers-ஐ delete செய்கிறது. Service-ஐ rename செய்த பிறகு கிடைக்கும் நிலை இதுவே. இதைப் பயன்படுத்தாவிட்டால், அந்த containers தொடர்ந்து இயங்கும்; அவை docker compose ps-க்கு தெரியாது.

எதையும் delete செய்வதற்கு முன் disk இடம் எங்கு பயன்படுத்தப்பட்டுள்ளது என்பதை 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 மட்டுமே அவற்றை நீக்கும்.

கோப்பு சிக்கலை ஏற்படுத்தும் முன் சரிபார்த்தல்

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

config --quiet வெற்றியடைந்தால் எந்த வெளியீட்டையும் வழங்காது. எனவே இதை deployment-க்கு முந்தைய படியில் அல்லது git hook-இல் பயன்படுத்தலாம். எளிய config முழுமையாக merge செய்யப்பட்டு interpolation செய்யப்பட்ட கோப்பை அச்சிடும். இதன் மூலம் ஒரு variable-ன் மதிப்பு தீர்மானிக்கப்பட்டதையும், override கோப்பு எதிர்பார்த்தபடி அடுக்கப்பட்டதையும் உறுதிப்படுத்தலாம். அமைக்கப்படாத variable அங்கு காலி மதிப்பாகத் தோன்றும். அதனுடன் The "X" variable is not set. Defaulting to a blank string. என்ற warning தோன்றும்.

--dry-run என்பது subcommand flag அல்ல; global flag ஆகும். எனவே இது up-க்கு முன் வர வேண்டும். Compose மேற்கொள்ளும் ஒவ்வொரு செயலையும் இது அச்சிடும்; எந்த மாற்றத்தையும் செய்யாது. முக்கியமான stack-இல் down செய்வதற்கு முன் செலவிடும் 30 seconds பயனுள்ளதாக இருக்கும்.

கோப்புகள், 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 கோப்பை வைத்திருப்பதற்கான நிலையான முறை இதுவாகும். ஆனால் lists மற்றும் maps க்கான விதிகள் வேறுபடும். ஆகவே எதிர்பாராத முடிவை debug செய்வதற்கு முன் Compose பல கோப்புகளை எவ்வாறு merge செய்கிறது என்பதைப் படிக்கவும்.

--profile அந்த profile-ஆல் tag செய்யப்பட்ட services-ஐ, tag செய்யப்படாத services-உடன் சேர்த்து start செய்கிறது. இதனால் வழக்கமான up-இல் debug tooling இடம்பெறாது. -p project name-ஐ அமைக்கிறது. எனவே ஒரே stack-இன் இரண்டு copies தனித்தனி networks மற்றும் தனித்தனி volume names உடன் ஒரே நேரத்தில் இயங்கலாம். Reboot செய்யப்பட்ட பிறகு stack-ஐ மீண்டும் இயக்குவது நீங்கள் type செய்யும் command அல்ல. அதற்குப் பதிலாக, உங்களுக்காக அதை இயக்கும் ஒரு unit தேவைப்படும். இது boot நேரத்தில் Compose stacks-ஐ start செய்தல் என்பதில் விளக்கப்பட்டுள்ளது.

FAQ

docker-compose என்பதற்குப் பதிலாக hyphen-உடன் எது வந்தது?

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

docker compose restart என் config மாற்றத்தை ஏன் ஏற்கவில்லை?

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

ஒரு service-ஐ புதிய image-க்கு எவ்வாறு update செய்வது?

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

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

docker system df, docker image prune -a மற்றும் docker builder prune images மற்றும் cache-ஐ மட்டும் நீக்குகின்றன. எனவே இயங்கும் services தொடர்ந்து செயல்படும்; named volumes பாதிக்கப்படாது. ஆபத்தான இணை commands 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-ஐத் தவிர்த்து, நீங்கள் வெளியேறும்போது container-ஐ நீக்குகிறது. Container ஏற்கனவே இயங்கிக் கொண்டிருந்தால் exec-ஐப் பயன்படுத்தவும். ஏனெனில் exec இயங்கும் process-உடன் இணைந்து, service உண்மையில் இருக்கும் நிலையை காட்டுகிறது.