Docker Compose commands: தினசரி பயன்பாட்டிற்கான வழிகாட்டி

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

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

இங்கு உள்ள அனைத்தும் Compose V2 அல்லது V5-ஐப் பயன்படுத்துகின்றன: docker compose-ல் space உள்ளது; பழைய docker-compose script பயன்படுத்தப்படாது. இரண்டும் Go plugins ஆகும். Linux-ல், Compose plugin-ஐ Docker Engine-இலிருந்து தனியாக install செய்ய வேண்டும். Ubuntu 24.04 LTS-ன் universe repository-ல் legacy Python V1 tool இன்னும் docker-compose version 1.29.2-6ubuntu1 ஆக வழங்கப்படுகிறது. docker compose version மூலம் சரிபார்க்கவும். அந்த command கிடைக்கவில்லை என்றால், Docker-ன் repository-ஐ அமைத்து docker-compose-plugin package-ஐ install செய்யவும்.

கீழே உள்ள ஒவ்வொரு command-ஐயும் உங்கள் compose.yaml இருக்கும் directory-லிருந்து இயக்க வேண்டும். நீங்கள் வேறு project name-ஐ குறிப்பிடாவிட்டால், Compose அந்த directory-யின் பெயரை default project name-ஆகப் பயன்படுத்தும். -f அல்லது COMPOSE_FILE இல்லையெனில், Compose working directory மற்றும் அதன் parent directories-ல் configuration file-ஐத் தேடும். எனவே, ஒரு level மேலிருந்து இயக்கும்போது, அந்த file இன்னும் search path-ல் இருந்தால் மட்டுமே உங்கள் stack கண்டறியப்படும். 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-ஐ உருவாக்கி, அவற்றைத் தொடங்கி, பின்னர் முடிவடைகிறது. Application readiness-க்காக காத்திருக்காமல் containers தொடங்கியவுடன் இது முடிவடைகிறது. அதனால் இதற்குப் பிறகு curl probe-ஐ இயக்கும் deploy script முதல் முயற்சியிலேயே பெரும்பாலும் தோல்வியடைகிறது. Healthcheck உள்ள services healthy ஆகும் வரையும், healthcheck இல்லாத services running நிலைக்கு வரும் வரையும் up -d --wait காத்திருக்கும்; unhealthy service அல்லது காலாவதியான --wait-timeout non-zero exit-ஐ ஏற்படுத்தும். இந்த flag-ன் செயல்திறன், அதற்குப் பின்னால் உள்ள check-ஐப் பொறுத்தது. எனவே automation-ல் இதை நம்புவதற்கு முன், Compose நம்பக்கூடிய healthcheck ஒன்றை எழுதவும்.

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

restart reload அல்ல. ஏற்கனவே உள்ள configuration-ஐப் பயன்படுத்தி அதே container-ஐ நிறுத்தி மீண்டும் தொடங்குகிறது. எனவே மாற்றிய environment variable, புதிய image tag அல்லது திருத்திய port mapping எதுவும் செயல்படாது. File மாற்றத்தைப் பயன்படுத்த up -d-ஐ மீண்டும் இயக்க வேண்டும். ஒவ்வொரு service-ஐயும் அதன் running container-உடன் Compose ஒப்பிடும். Configuration அல்லது image மாற்றப்பட்ட 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, configuration மற்றும் image மாறாமல் இருந்தால் ஏற்கனவே இயங்கும் containers-ஐ மீண்டும் பயன்படுத்தும்; image pulls மற்றும் builds, service-ன் pull policy-ஐ பின்பற்றும். --force-recreate அந்த ஒப்பீட்டை புறக்கணித்து, configuration ஒரே மாதிரியாக இருந்தாலும் ஒவ்வொரு container-ஐயும் மாற்றும். எனவே container-க்குள் ஏற்பட்ட விசித்திரமான state-ஐ விரைவாக நீக்க இதுவே சிறந்த வழி.

வெளிப்படையான image update routine இரண்டு commands-ஐ பயன்படுத்துகிறது. அவை இரண்டு வேறு செயல்களைச் செய்கின்றன. pull file-ல் குறிப்பிடப்பட்டுள்ள ஒவ்வொரு tag-க்குமான தற்போதைய image-ஐ download செய்யும். அதன் பிறகு up -d, service-ன் image ID இயங்கும் container-ன் image ID-யுடன் பொருந்தவில்லை என்பதை கண்டறிந்து, அந்த container-ஐ recreate செய்யும். இயல்புநிலை missing pull policy-யில், cached tags மீண்டும் பயன்படுத்தப்படும்; ஆனால் latest எப்போதும் pull செய்யப்படும். இதற்கு மாறான அபாயம் multi-service stack-ல் உள்ளது. அங்கு ஒவ்வொரு service-க்கும் ஒரே நேரத்தில் latest pull செய்தால், பத்து விநாடிகளுக்கு முன்பு சரியாக இயங்கிய application செயலிழக்கலாம். அதனால் self-hosted AFFiNE workspace application மற்றும் migration image இரண்டையும் ஒரே digest-க்கு pin செய்ய பரிந்துரைக்கிறது. Pinning செய்தால் upgrade என்பது tag-ஐ திட்டமிட்டு edit செய்து, அதே pull மற்றும் recreate செயல்முறையைத் தொடர்வதாக மாறும். Boot ஆகும்போது database-ஐ migrate செய்யும் stack-ல், இந்த இரண்டு commands-ல் ஏதேனும் ஒன்றை இயக்குவதற்கு முன் dump தயாராக இருக்க வேண்டும். ஒவ்வொரு version bump-க்கும் self-hosted Chatwoot support desk இதே routine-ஐப் பின்பற்றுகிறது.

build, build: section-ஐ declare செய்யும் services-க்கு பொருந்தும். image:-ஐயும் declare செய்யும் services-களும் இதில் அடங்கும். up -d --build build செய்து start செய்வதை ஒரே step-ல் நிறைவேற்றும். Code-ஐ மாற்றிக்கொண்டிருக்கும் போது வழக்கமாகப் பயன்படுத்தப்படும் loop இதுவாகும். Cached layer தெளிவாக stale ஆக இருக்கும்போது மட்டுமே --no-cache-ஐப் பயன்படுத்தவும். அது ஒவ்வொரு layer-ஐயும் scratch-இலிருந்து மீண்டும் build செய்யும். சில projects ஒரே cloned repo-விலிருந்து இரண்டு வழிகளையும் வழங்குகின்றன. அப்போது இந்த இரண்டு loops மாற்று update paths ஆகும்: self-hosted openGym workout tracker, தனது pinned checkout-ஐ build செய்ய docker compose up -d --build-ஐப் பயன்படுத்துகிறது. காரணம், அதன் latest images-ஐ pull செய்தால் அந்த checkout-ஐ விட புதிய release இயங்கக்கூடும்.

இயக்கத்தில் உள்ளவற்றைப் பார்ப்பது

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

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

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

ஒரு 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 இருக்கும். Official PostgreSQL Alpine image-லும் இது உள்ளது. அது இல்லாதபோது, பிழை exec: "bash": executable file not found in $PATH எனக் காட்டப்படும். --no-deps-ஐ run-ல் சேர்த்தால் service-ன் dependencies தவிர்க்கப்படும். இதனால் விரைவான configuration check செய்யும்போது முழு database-ஐ தொடங்க வேண்டியதில்லை.

ஒவ்வொரு .env file, environment: block மற்றும் shell variable இணைக்கப்பட்ட பிறகு, service உண்மையில் பெற்ற environment-ஐ பார்க்க run --rm web env மிக விரைவான வழியாகும். ஒரு value தவறாக இருந்தால், பொதுவாக merge order-தான் காரணமாக இருக்கும். Compose env files மற்றும் 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-ல் இணைக்கிறது. அந்த network-ல் ஒவ்வொரு service name-மும் DNS name-ஆக இருக்கும். image-ல் getent இருந்தால், web-க்குள் getent hosts db-ஐ இயக்குவது name resolution-ஐச் சோதிக்கும்; db connections-ஐ ஏற்கிறதா என்பதை அது சோதிக்காது. Name resolve ஆனாலும் connection refused என வந்தால், server இயங்குகிறதா என்றும் கோரப்பட்ட address மற்றும் port-ல் listening செய்கிறதா என்றும் பார்க்கவும்; 127.0.0.1-க்கு மட்டும் bind செய்திருப்பது ஒரு சாத்தியமான காரணம். இதே network எல்லைதான், project-க்கு வெளியே தொடங்கப்பட்ட container — docker run மூலம் தொடங்கப்பட்டதாயினும் அல்லது தனி stack-ஆக இயங்கினாலும் — jellyfin போன்ற service name-ஐ resolve செய்ய shared network தேவைப்படுவதையும் விளக்குகிறது. உங்கள் Jellyfin library-க்கான Halcyon front end அது குறிப்பிடும் server-ஐ அணுக முடியாதபோது, முதலில் இதைத்தான் சோதிக்க வேண்டும். இந்த model-ன் மீதமுள்ள பகுதி Compose networks மற்றும் service DNS எவ்வாறு செயல்படுகின்றன என்பதில் விளக்கப்பட்டுள்ளது.

port web 80 ஒரு container port எந்த host address மற்றும் port-ல் publish செய்யப்பட்டுள்ளது என்பதை காட்டுகிறது. Mapping ஒரு variable-லிருந்து வந்திருந்தால், இதனால் ஊகிக்க வேண்டிய அவசியம் இல்லை. ஒரு port-ஐ publish செய்வது, Docker தானாக நிர்வகிக்கும் firewall rule-ஐயும் உருவாக்குகிறது. அந்த rule, நீங்கள் உருவாக்கிய firewall rule-க்கு முன்னதாகச் செயல்படும். எனவே private-ஆக இருக்க வேண்டும் என்று நினைத்த service இணையத்துக்கு திறந்திருக்கலாம். இந்த நிலை published Docker ports ஏன் ufw-ஐத் தாண்டிச் செல்கின்றன என்பதில் விளக்கப்பட்டுள்ளது. அந்த ports-ஐ publish செய்யாமல் விட்டு, அதற்குப் பதிலாக services-க்கு முன்பாக project network-ல் 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 inventory-யின் ஒரு பகுதி மட்டுமே. bind mounts மற்றும் configuration files-ஐயும் சரிபார்க்க வேண்டும். மீண்டும் உருவாக்க முடியாத data volumes-ல் இருந்தால், பட்டியலைப் போலவே சரியான backup command-உம் முக்கியம். அதனால் PhotoPrism மற்றும் Immich ஒப்பீடு ஒவ்வொரு photo server-க்கும் தேவையான dump மற்றும் copy commands-ஐத் தெளிவாகக் குறிப்பிடுகிறது. cp shell திறக்காமல், ஒரு file-ஐ container-க்குள் அல்லது container-இலிருந்து வெளியே copy செய்யும். இதற்கு container இருக்கும் பக்கத்தில் service:path form பயன்படுத்தப்படுகிறது.

down -v external volumes-ஐத் தவிர, அறிவிக்கப்பட்ட named volumes-ஐ நீக்கும். Containers-க்கு இணைக்கப்பட்ட anonymous volumes-ஐயும் containers-உடன் நீக்கும். Test stack-ஐ முழுமையாக அகற்றுவதற்கு இது சரியான command. ஆனால் முக்கியமான data உள்ள எந்த stack-க்கும் இது தவறான 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 இயல்பாக இயங்கிக்கொண்டிருக்கும் orphan containers-ஐயும் சேர்த்துக்கொள்ளும்.

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

இவற்றில் எதுவும் named volume-ஐத் தொடாது. docker volume prune --all, docker compose down -v மற்றும் docker volume rm named volumes-ஐ அகற்றும். Plain docker volume prune anonymous volumes-ஐ மட்டும் அகற்றும்.

ஏதேனும் பாதிப்பை ஏற்படுத்தும் முன் 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 செய்வதற்கு முன் செலவிடும் முப்பது விநாடிகள் பயனுள்ளவை.

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

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

FAQ

ஹைபனுடன் கூடிய docker-compose-க்கு பதிலாக என்ன பயன்படுத்தப்படுகிறது?

Compose V2 மற்றும் V5 ஆகியவை இடைவெளியுடன் கூடிய docker compose என்ற வடிவில் பயன்படுத்தப்படுகின்றன. Linux-ல் Compose தனியாக நிறுவப்படும் plugin ஆகும்; Ubuntu 24.04 LTS-ன் universe repository-ல் V1 Python tool இன்னும் கிடைக்கிறது. இடைவெளி கொண்ட வடிவம் கிடைக்கவில்லை என்றால், Docker-ன் repository-ஐ அமைத்து docker-compose-plugin package-ஐ நிறுவவும். Alias சேர்ப்பதற்குப் பதிலாக பழைய scripts-ஐ இடைவெளி கொண்ட வடிவத்திற்கு மாற்றவும்; ஏனெனில் V2-ல் V1-ல் இல்லாத flags உள்ளன.

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

restart ஏற்கனவே உள்ள container-ஐ, அது உருவாக்கப்பட்டபோதைய configuration-ஐப் பயன்படுத்தி நிறுத்தி மீண்டும் தொடங்கும்; அது compose.yaml-ஐ மறுபடியும் வாசிக்காது. Environment variables, ports, volumes அல்லது image tag ஆகியவற்றில் ஏதேனும் மாற்றம் செய்தால் docker compose up -d தேவைப்படும். இது ஒவ்வொரு service-ஐயும் அதற்குரிய running container-உடன் ஒப்பிட்டு, வேறுபடும் 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-ஐ மட்டும் இயக்கினால், அது pull policy-ஐப் பின்பற்றும். இயல்புநிலை missing policy, latest-ஐத் தவிர cached images-ஐ மீண்டும் பயன்படுத்தும்; latest எப்போதும் pull செய்யப்படும்.

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

docker system df எதையும் நீக்காமல் disk usage-ஐக் காட்டும். docker image prune -a மற்றும் docker builder prune பயன்படுத்தப்படாத images மற்றும் build cache-ஐ நீக்கும்; எனவே இயங்கும் services தொடர்ந்து செயல்படும், named volumes பாதிக்கப்படாது. ஆபத்தான commands docker compose down -v மற்றும் docker volume prune --all ஆகும். docker compose down -v project-ல் declare செய்யப்பட்ட external அல்லாத named volumes மற்றும் இணைக்கப்பட்ட anonymous volumes-ஐ எந்த prompt-உம் இல்லாமல் நீக்கும். docker volume prune --all பயன்படுத்தப்படாத local volumes, அதில் named volumes-உம் அடங்கும், ஒரே y/N prompt-க்கு பிறகு நீக்கும்; -f பயன்படுத்தினால் prompt எதுவும் இருக்காது. எது பாதிக்கப்படலாம் என்பதை அறிய முதலில் docker compose config --volumes-ஐ இயக்கவும்.

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

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