Docker Compose stop vs down: என்ன வித்தியாசம்?

சுருக்கமான பதில்

docker compose stop கன்டெய்னர்களை நிறுத்திவிட்டு, அவற்றை டிஸ்க்கிலேயே வைத்திருக்கும். docker compose down கன்டெய்னர்களை நிறுத்திவிட்டு, அந்த புராஜெக்ட்டிற்காக Compose உருவாக்கிய கன்டெய்னர்கள் மற்றும் நெட்வொர்க்கை நீக்கிவிடும். இந்த இரண்டு கட்டளைகளுமே named volume-களைப் பாதிக்காது. docker compose down -v கட்டளையைப் பயன்படுத்தி -v என்று குறிப்பிடும்போது மட்டுமே உங்கள் டேட்டாபேஸ் நீக்கப்படும்; இது Compose கோப்பின் volumes பகுதியில் அறிவிக்கப்பட்ட named volume-களை நீக்கிவிடும்.

இதுவே ஒரே பத்தியில் சொல்லக்கூடிய முழுமையான வித்தியாசம். இந்த வழிகாட்டியின் மீதமுள்ள பகுதி, ஒரு Postgres volume-ஐ வைத்து இதை நிரூபிக்கிறது. ஒரு down-க்கு பிறகும் அந்த வால்யூம் எப்படி அழியாமல் இருக்கிறது என்பதையும், down -v-க்கு பிறகு அது எப்படி மறைகிறது என்பதையும் இது விளக்குகிறது. மேலும், --force-recreate உங்களுக்குத் தேவைப்படும் இரண்டு சூழல்களையும் இது விவரிக்கிறது.

docker compose stop: containers நீக்கப்படாது

stop ஒவ்வொரு container-லும் உள்ள முதன்மை process-க்கு SIGTERM சிக்னலை அனுப்பி, சிறிது நேரம் காத்திருந்து, process இன்னும் இயங்கிக்கொண்டிருந்தால் SIGKILL சிக்னலை அனுப்பும். இயல்பான காத்திருப்பு நேரம் 10 வினாடிகள் ஆகும், இதை -t மூலம் மாற்றலாம். இதில் எதுவும் நீக்கப்படாது. Container அதன் ID, writable layer, IP ஒதுக்கீடு மற்றும் logs ஆகியவற்றைத் தக்கவைத்துக் கொள்ளும்.

docker compose stop
docker compose ps -a

docker compose ps கட்டளையை மட்டும் பயன்படுத்தினால் இயங்கும் containers மட்டுமே தெரியும், எனவே stop கட்டளைக்குப் பிறகு இதைப் பார்த்தால், பட்டியல் காலியாக இருப்பதால் containers நீக்கப்பட்டுவிட்டதாகத் தோன்றும். ps -a கட்டளையைப் பயன்படுத்தினால் நிறுத்தப்பட்ட containers-ம் தெரியும், அங்கு ஒவ்வொரு service-க்கும் அருகில் Exited (0) என்று குறிப்பிடப்பட்டிருப்பதைக் காணலாம். அவற்றை மீண்டும் இயக்க docker compose start கட்டளையைப் பயன்படுத்தவும்; இது அதே containers-ஐ மீண்டும் பயன்படுத்தும்.

Containers தொடர்ந்து இருப்பதால், volume-க்கு வெளியே அவற்றுக்குள் எழுதப்பட்ட தரவுகள் அப்படியே இருக்கும். நீங்கள் docker compose exec மூலம் கைமுறையாக நிறுவிய package மற்றும் container-க்குள் நீங்கள் திருத்திய config file ஆகியவையும் இதில் அடங்கும். பிழைத்திருத்தம் (debugging) செய்யும் போது stop கட்டளையை விரும்புவதற்கு இதுவே நடைமுறைச் காரணமாகும்: நீங்கள் அதே நிலையில் இருந்து மீண்டும் தொடங்க முடியும்.

docker compose down: containers மற்றும் networks நீக்கப்படுகின்றன

down என்பது containers-ஐ நிறுத்திவிட்டு, அந்த project-க்காக Compose உருவாக்கிய default network-உடன் அவற்றை நீக்குகிறது. Docker ஆவணங்களின்படி, இது containers-ஐ நிறுத்திவிட்டு, up மூலம் உருவாக்கப்பட்ட containers, networks, volumes மற்றும் images-ஐ நீக்குவதாகக் கூறுகிறது. ஆனால், volumes மற்றும் images நீக்கப்படுவது நீங்கள் -v மற்றும் --rmi ஆகிய flags-ஐப் பயன்படுத்தினால் மட்டுமே நடக்கும்.

docker compose down
docker compose ps -a
docker network ls

down கட்டளைக்கு பிறகு, ps -a அந்த project-க்கு எதையும் காட்டாது மற்றும் <project>_default network நீக்கப்பட்டிருக்கும். நீங்கள் Compose file-ல் name:-ஐ அமைக்காதவரை அல்லது -p-ஐப் பயன்படுத்தாதவரை, directory-ன் பெயரே project-ன் பெயராக இருக்கும். container-ன் writable layer-ல் நீங்கள் செய்த மாற்றங்கள் அனைத்தும் இப்போது மீட்க முடியாதவை. எனவே, down கட்டளையை container-ஐ நீக்கிவிட்டு, volumes-ல் உள்ள தரவை மட்டும் பாதுகாக்கும் ஒரு செயலாகக் கருதவும்.

தவறான directory-ல் இதை இயக்கினால் no configuration file provided: not found பிழை வரும். எந்த project-ஐக் குறிப்பிடுகிறீர்கள் என்பது Compose-க்குத் தெரியாது என்பதால், அது அந்தச் செயலைச் செய்ய மறுத்துவிடும். project folder-ல் இல்லாதபோது docker compose -f /srv/myapp/compose.yaml down-ஐப் பயன்படுத்தவும்.

docker compose down கட்டளை எனது volumes-ஐ நீக்கிவிடுமா?

இல்லை. உயர்மட்ட volumes key-ன் கீழ் அறிவிக்கப்பட்ட ஒரு named volume, down கட்டளையை விட அதிக காலம் நிலைத்திருக்கும், மேலும் அது இணைக்கப்பட்டிருந்த container-ஐ விடவும் அது நீடிக்கும். இந்த கட்டளையைப் பற்றிய பொதுவான அச்சம் இதுவே, Compose v2 பதிப்பு முழுவதிலும் இதற்கான பதில் மாறாதது.

நீங்கள் சோதிக்கக்கூடிய ஒரு stack-ஐ அமைக்கவும். voltest என்று பெயரிடப்பட்ட ஒரு காலி கோப்பகத்தில் (directory) இதை compose.yaml கோப்பில் உள்ளிடவும்.

services:
  db:
    image: postgres:16.4
    restart: unless-stopped
    environment:
      POSTGRES_PASSWORD: example
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:

இதை தொடங்கி, நீங்கள் பின்னர் அடையாளம் காணக்கூடிய ஒரு வரி தரவை எழுதவும்.

docker compose up -d
sleep 10
docker compose exec -T db psql -U postgres -c "create table marker (note text);"
docker compose exec -T db psql -U postgres -c "insert into marker values ('survived');"

இப்போது container-ஐ அழித்துவிட்டு, volume-ஐ சரிபார்க்கவும்.

docker compose down
docker volume ls

வெளியீடு இன்னும் voltest_pgdata-ஐ பட்டியலிடும். container நீக்கப்பட்டுவிட்டது, ஆனால் தரவு நீக்கப்படவில்லை. stack-ஐ மீண்டும் கொண்டு வந்து அந்த வரியை வாசிக்கவும்.

docker compose up -d
sleep 10
docker compose exec -T db psql -U postgres -c "select * from marker;"

survived என்ற தரவு கொண்ட ஒரு வரி உங்களுக்குக் கிடைக்கும். புதிய container என்பது வேறுபட்ட ID கொண்ட ஒரு புதிய container ஆகும், அது அதே volume-உடன் இணைக்கப்பட்டுள்ளது. இது குறித்த கூடுதல் விவரங்களுக்கு, Compose அடிப்படைகள் வழிகாட்டி-ஐப் பார்க்கவும்; இது named volumes மற்றும் bind mounts ஆகியவற்றுக்கு இடையேயான வேறுபாடுகளையும், அவை host-ல் எங்கு சேமிக்கப்படுகின்றன என்பதையும் விளக்குகிறது.

down -v கட்டளை எதை நீக்குகிறது

-v (இதன் முழு வடிவம் --volumes) என்பது Compose கோப்பின் volumes பகுதியில் குறிப்பிடப்பட்டுள்ள named volumes மற்றும் containers-உடன் இணைக்கப்பட்டுள்ள anonymous volumes ஆகியவற்றை நீக்குகிறது. இதை அதே stack-ல் இயக்கிப் பார்க்கவும்.

docker compose down -v
docker volume ls

voltest_pgdata இப்போது பட்டியலில் இல்லை. Stack-ஐ மீண்டும் தொடங்கினால், Postgres entrypoint ஒரு காலி data directory-ஐக் கண்டறியும். எனவே, அது புதிய cluster-ஐ உருவாக்கும். Container log-ல் இது தெளிவாகக் குறிப்பிடப்பட்டிருக்கும்.

The files belonging to this database system will be owned by user "postgres".
PostgreSQL init process complete; ready for start up.

மாதக்கணக்கில் இயங்கிக்கொண்டிருக்கும் ஒரு stack-ல் இந்தத் தகவலைக் காண்பது, அந்த volume நீக்கப்பட்டுவிட்டது என்பதைக் குறிக்கிறது. உங்கள் marker அட்டவணை அழிந்துவிட்டது; அதை மீட்டெடுக்க backup மட்டுமே ஒரே வழி.

சில சேமிப்பகங்களை -v கட்டளையால் நீக்க முடியாது. Bind mount என்பது host-ல் உள்ள ஒரு path ஆகும்; எனவே Docker அதை unmount மட்டுமே செய்யும், உங்கள் கோப்புகள் அங்கேயே இருக்கும். external: true எனக் குறிக்கப்பட்ட ஒரு volume, இந்தத் திட்டத்திற்கு வெளியே உள்ளதாகக் கருதப்படுகிறது, எனவே Compose அதை ஒருபோதும் நீக்காது. down -v கட்டளையை இயக்குவதற்கு முன்பே, Compose கோப்பிலிருந்து ஒரு named volume-ஐ நீக்கிவிட்டால், அது இனி அந்த கோப்பில் இருக்காது. எனவே, அதை நீக்க வேண்டியது தனது பொறுப்பு என்று Compose கருதாது, அது ஒரு orphan-ஆக அப்படியே தங்கிவிடும், இதை docker volume prune மூலம் மட்டுமே நீக்க முடியும்.

இந்தக் கடைசிச் சூழல், refactor செய்யும்போது பலருக்குச் சிக்கலை ஏற்படுத்துகிறது. ஒரு service மற்றும் அதன் volume-ஐ கோப்பிலிருந்து நீக்கிவிட்டு, down -v கட்டளையை இயக்கினால், அந்த volume நீங்காமல் அப்படியே இருக்கும், ஏனெனில் கோப்பில் அதைப் பற்றிய குறிப்பு இல்லை. எனவே, கோப்பைத் திருத்துவதற்கு முன்பே down -v கட்டளையை இயக்கவும், திருத்திய பிறகு அல்ல.

எப்போது உங்களுக்கு --force-recreate தேவைப்படுகிறது

docker compose up -d ஒவ்வொரு முறையும் அனைத்தையும் மீண்டும் கட்டமைப்பதில்லை. Compose, ஒவ்வொரு சேவையின் தீர்க்கப்பட்ட (resolved) உள்ளமைவின் hash மதிப்பை container-ல் ஒரு label-ஆகச் சேமிக்கிறது. hash மற்றும் image ID ஆகியவை ஒத்துப்போனால், container மாற்றப்படாமல் அப்படியே இருக்கும், மேலும் உங்களுக்கு Recreated-க்கு பதிலாக Container voltest-db-1 Running கிடைக்கும். இதுவே நீங்கள் எப்போதும் எதிர்பார்க்கும் செயல்பாடாகும், ஏனெனில் இது up -d-ஐ மீண்டும் மீண்டும் இயக்குவதை பாதுகாப்பானதாக்குகிறது.

சில மாற்றங்கள் எந்த விளைவையும் ஏற்படுத்தாததற்கும் இதுவே காரணம். Compose, அந்த வரையறை சுட்டிக்காட்டும் கோப்புகளின் உள்ளடக்கத்தை அல்ல, மாறாக தீர்க்கப்பட்ட சேவை வரையறையை (resolved service definition) மட்டுமே hash செய்கிறது. ஒரு config கோப்பு container-க்குள் mount செய்யப்பட்டு, தொடக்கத்தின்போது ஒருமுறை வாசிக்கப்பட்டால், நீங்கள் அதைத் திருத்தும்போது அது மீண்டும் உருவாக்கப்படாது (recreate), ஏனெனில் mount பாதை மாறவில்லை. அந்தச் சேவை தொடக்கத்தின்போது வாசித்த மதிப்புகளுடனேயே தொடர்ந்து இயங்கும்.

docker compose up -d --force-recreate

இது ஒவ்வொரு container-ஐயும் நிறுத்தி நீக்கிவிட்டு, அதே வரையறையிலிருந்து புதிய ஒன்றை உருவாக்குகிறது. mount செய்யப்பட்ட config கோப்பில் மாற்றம் செய்த பிறகும், அல்லது ஒரு container உங்களால் விளக்க முடியாத நிலைக்குச் சென்றபோதும் இதைப் பயன்படுத்தவும். Volumes மாற்றப்படாமல் இருக்கும், எனவே database ஒரு force recreate-க்குப் பிறகும் அப்படியே இருக்கும். அதே tag-ல் உள்ள புதிய image-ஐப் பெற, நீங்கள் pull கட்டளையையும் பயன்படுத்த வேண்டும்.

docker compose pull
docker compose up -d

pull புதிய image ID-ஐப் பெறுகிறது, பின்னர் up -d இயங்கும் container-ஐ விட மாறுபட்ட image ID-ஐக் கண்டு, தானாகவே அதை மீண்டும் உருவாக்குகிறது. pull இல்லாமல் --force-recreate-ஐ மட்டும் சேர்த்தால், அதே பழைய image-லிருந்து புதிய container கிடைக்கும். இதனால்தான் "நான் force recreate செய்தேன், ஆனால் இன்னும் பழைய பதிப்புதான் உள்ளது" என்பது பொதுவான புகாராக உள்ளது.

docker compose restart இதையெதையும் செய்வதில்லை. இது ஏற்கனவே உள்ள container-களை மீண்டும் தொடங்குகிறது (restart), ஆனால் Compose கோப்பை மீண்டும் வாசிப்பதில்லை. எனவே, மாற்றப்பட்ட environment variable அல்லது port mapping போன்றவை நடைமுறைக்கு வராது. நீங்கள் கோப்பைத் திருத்தியிருந்தால், up -d-ஐப் பயன்படுத்தவும்.

மனதில் கொள்ள வேண்டிய அடிப்படை மாதிரி

Containers மாற்றக்கூடியவை. ஒரு container என்பது ஒரு process மற்றும் அதன் மேல் உள்ள மெல்லிய writable layer ஆகும். Compose மூலம் கோப்பிலிருந்து ஒரு நொடியில் அதே போன்ற புதிய container-ஐ உருவாக்க முடியும். Volumes மாற்றக்கூடியவை அல்ல; ஏனெனில், உங்கள் repository-ல் உள்ள எந்தக் கோப்பாலும் மீண்டும் உருவாக்க முடியாத தரவுகளின் ஒரே நகல் அவற்றில் மட்டுமே இருக்கும்.

ஒவ்வொரு Compose verb-ம் இந்த பிரிவின் அடிப்படையிலேயே செயல்படுகிறது. stop மற்றும் start ஆகியவை container-ஐ அப்படியே வைத்திருக்கும். down மற்றும் up ஆகியவை container-ஐ மாற்றி அமைக்கும், ஆனால் volume-ஐ அப்படியே வைத்திருக்கும். down -v மட்டுமே தரவுகளை நீக்கும் வழக்கமான கட்டளையாகும், அதனால்தான் இதற்கு ஒரு குறிப்பிட்ட flag தேவைப்படுகிறது. உண்மையான சூழலில் இதை இயக்கும் முன், நீங்கள் ஏற்கனவே ஒருமுறை restore செய்து பார்த்த backup உங்களிடம் இருப்பதை உறுதிப்படுத்திக் கொள்ளுங்கள்.

இதே தர்க்கம் secrets-க்கும் பொருந்தும். POSTGRES_PASSWORD மூலம் அமைக்கப்படும் கடவுச்சொல், database முதல்முறை தொடங்கும் போது மட்டுமே வாசிக்கப்படும். எனவே, environment கோப்பில் அதை மாற்றிவிட்டு up -d-ஐ இயக்கினால், உங்களுக்கு password authentication failed for user "postgres" கிடைக்கும். இதில் container புதியது, ஆனால் volume பழையது; அந்த பழைய volume-ல் இன்னும் பழைய கடவுச்சொல்லே இருக்கும். Compose எவ்வாறு env கோப்புகள் மற்றும் secrets-ஐ கையாள்கிறது என்ற பகுதியில், ஒரே variable இருமுறை அமைக்கப்படும்போது எந்த layer-ன் மதிப்பு முன்னுரிமை பெறும் என்பது விளக்கப்பட்டுள்ளது.

தோல்வி நிலைகள் மற்றும் நீங்கள் காணும் செய்திகள்

no configuration file provided: not found என்பது, compose.yaml அல்லது docker-compose.yml இல்லாத ஒரு கோப்பகத்தில் (directory) Compose இயங்குகிறது என்று பொருள். -f கொடியுடன் முழுமையான பாதையை (full path) குறிப்பிடவும்.

down-ல் வரும் network voltest_default has active endpoints என்பது, இந்தத் திட்டத்திற்கு வெளியே உள்ள ஒரு container, திட்டத்தின் network-உடன் இணைக்கப்பட்டுள்ளது என்று பொருள். இது பொதுவாக docker run --network மூலம் கைமுறையாகத் தொடங்கப்பட்ட ஒன்றாக இருக்கும். அந்த container-ஐ நீக்கிவிட்டு, மீண்டும் down-ஐ இயக்கவும்.

ஒரு service-ஐ மறுபெயரிட்ட பிறகு அல்லது நீக்கிய பிறகு Found orphan containers ([voltest-old-1]) for this project தோன்றும். பழைய container இன்னும் அந்தத் திட்டத்தின் label-ஐக் கொண்டிருக்கும். docker compose down --remove-orphans அவற்றை நீக்கிவிடும்; ஆரோக்கியமான stack-ல் இதை இயக்குவது பாதுகாப்பானது.

கைமுறையாக docker volume rm செய்யும்போது வரும் Error response from daemon: remove voltest_pgdata: volume is in use என்பது, நிறுத்தப்பட்டவை உட்பட ஏதேனும் ஒரு container அந்த volume-ஐ இன்னும் பயன்படுத்துகிறது என்று பொருள். முதலில் docker compose down-ஐ இயக்கவும், பிறகு volume-ஐ நீக்கவும். அல்லது நேரடியாக down -v-ஐப் பயன்படுத்தவும். பெரிய திட்டங்களில், பல சேவைகளைக் கொண்ட Compose stack ஒரு திட்டத்தில் எத்தனை volumes சேரக்கூடும் என்பதைக் காட்டுகிறது.

FAQ

docker compose down எனது database-ஐ அழித்துவிடுமா?

database ஒரு named volume அல்லது bind mount-ல் இருந்தால், அது அழியாது. down கட்டளையானது container-களையும் project network-ஐயும் மட்டுமே நீக்கும்; volume-ல் உள்ள தரவுகள் வட்டில் அப்படியே இருக்கும். அடுத்தமுறை docker compose up -d கட்டளையை இயக்கும்போது, புதிய container அதே volume-உடன் இணைந்து பழைய தரவுகளைப் பயன்படுத்தும். docker compose down -v கட்டளை மட்டுமே named volume-களை நீக்கும், அதுவும் Compose கோப்பில் volumes பிரிவில் குறிப்பிடப்பட்டவற்றை மட்டுமே நீக்கும்.

மீண்டும் தேவைப்படும் ஒரு container-க்கு stop மற்றும் down ஆகியவற்றுக்கு என்ன வித்தியாசம்?

stop கட்டளை container-ஐ அப்படியே வைத்திருக்கும், எனவே docker compose start கட்டளை மூலம் அதே writable layer-உடன் கூடிய பழைய container-ஐ மீண்டும் பெறலாம். நீங்கள் கைமுறையாக நிறுவிய அல்லது மாற்றியமைத்த கோப்புகள் அப்படியே இருக்கும். down கட்டளை container-ஐ நீக்கிவிடும், எனவே அடுத்தமுறை up -d கட்டளையை இயக்கும்போது image-லிருந்து புதிய container உருவாக்கப்படும்; உங்கள் கைமுறை மாற்றங்கள் அனைத்தும் அழிந்துவிடும். நீங்கள் debugging செய்யும்போது stop கட்டளையைப் பயன்படுத்தவும்.

ஒரு Compose project உருவாக்கிய அனைத்தையும் எவ்வாறு நீக்குவது?

docker compose down -v --rmi all --remove-orphans கட்டளையானது container-கள், project network, கோப்பில் குறிப்பிடப்பட்ட named volumes, services பயன்படுத்திய images மற்றும் project பெயரைக் கொண்ட அனைத்து container-களையும் நீக்கும். இது bind mounts அல்லது external: true எனக் குறிக்கப்பட்ட volumes-ஐ பாதிக்காது. எதை நீக்கப்போகிறீர்கள் என்பதை உறுதிப்படுத்த, இயக்குவதற்கு முன் docker volume ls கட்டளையைப் பயன்படுத்திச் சரிபார்க்கவும்.

mounted config கோப்பில் நான் செய்த மாற்றத்தை எனது container ஏன் கண்டுகொள்வதில்லை?

resolved service definition-ன் hash மதிப்பை ஒப்பிட்டுத்தான் ஒரு container-ஐ மீண்டும் உருவாக்க வேண்டுமா என்பதை Compose தீர்மானிக்கிறது. அந்த hash மதிப்பில் mounted கோப்பின் உள்ளடக்கம் சேர்க்கப்படுவதில்லை. கோப்பின் பாதை மாறாததால், தொடக்கத்தில் வாசித்த அதே மதிப்புகளுடன் container தொடர்ந்து இயங்குகிறது. கோப்பை மீண்டும் வாசிக்கச் செய்து புதிய container-ஐ உருவாக்க docker compose up -d --force-recreate கட்டளையை இயக்கவும்.

நான் மாற்றிய புதிய POSTGRES_PASSWORD ஏன் வேலை செய்யவில்லை?

Postgres image ஆனது ஒரு காலி data directory-ஐ முதன்முதலில் உருவாக்கும்போது மட்டுமே POSTGRES_PASSWORD-ஐ வாசிக்கும். உங்கள் volume-ல் ஏற்கனவே initialized செய்யப்பட்ட cluster இருப்பதால், இந்த variable புறக்கணிக்கப்பட்டு பழைய கடவுச்சொல்லே தொடரும். அப்போது நீங்கள் password authentication failed for user "postgres" என்ற செய்தியைக் காண்பீர்கள். இயங்கிக்கொண்டிருக்கும் database-க்குள் ALTER USER கட்டளையைப் பயன்படுத்தி கடவுச்சொல்லை மாற்றவும், அல்லது தரவுகள் அழிந்தாலும் பரவாயில்லை எனில் docker compose down -v கட்டளையைப் பயன்படுத்தி மீண்டும் தொடங்கவும்.