Docker Compose stop vs down: containers, volumes வேறுபாடு

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

docker compose stop containers-ஐ நிறுத்தி, அவற்றை disk-ல் வைத்திருக்கும். docker compose down containers-ஐ நிறுத்திய பிறகு, project-க்காக Compose உருவாக்கிய containers மற்றும் network-ஐ நீக்குகிறது. எந்தக் command-மும் named volume-ஐ பாதிக்காது. -v-ஐச் சேர்த்தால் மட்டுமே உங்கள் database நீக்கப்படும். இதற்கான உதாரணம் docker compose down -v. இது Compose file-ன் volumes பகுதியில் அறிவிக்கப்பட்ட named volumes-ஐ நீக்குகிறது.

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

docker compose stop: containers இயங்கிக்கொண்டே இருக்கின்றன

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

docker compose stop
docker compose ps -a

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

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

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

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

docker compose down
docker compose ps -a
docker network ls

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

தவறான 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-ஐ விடவும் நீண்ட காலம் நிலைத்திருக்கும். இந்த command குறித்து பொதுவாக எழும் அச்சம் இதுவாகும். 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:

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

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 நீக்கப்பட்டுள்ளது; data நீக்கப்படவில்லை. stack-ஐ மீண்டும் கொண்டு வந்து, அந்த row-ஐப் படிக்கவும்.

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

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

down -v என்னைத் துல்லியமாக அழிக்கிறது

-v (நீண்ட வடிவம் --volumes) Compose file-இன் volumes section-இல் குறிப்பிடப்பட்ட named volumes-ஐயும், containers-க்கு இணைக்கப்பட்ட anonymous volumes-ஐயும் அகற்றுகிறது. இதை அதே stack-க்கு எதிராக இயக்கவும்.

docker compose down -v
docker volume ls

voltest_pgdata இனி பட்டியலிடப்படாது. Stack-ஐ மீண்டும் தொடங்கினால், Postgres entrypoint காலியான data directory-ஐக் கண்டறிந்து புதிய cluster-ஐ initialises செய்கிறது. Container log இதைத் தெளிவாகக் குறிப்பிடுகிறது.

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

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

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

Refactor செய்யும்போது இந்த இறுதி நிலை பலரையும் சிக்கலில் ஆழ்த்துகிறது. File-இலிருந்து service மற்றும் அதன் volume-ஐ நீக்கி, down -v இயக்கினால், file இனி அதைக் குறிப்பிடாததால் volume தொடர்ந்து இருக்கும். File-ஐத் திருத்துவதற்கு முன் down -v இயக்கவும்; பின்னர் இயக்க வேண்டாம்.

--force-recreate எப்போது உண்மையில் தேவைப்படுகிறது

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

சில திருத்தங்கள் எந்த விளைவையும் ஏற்படுத்தாதது இதனால் தான். Compose, service definition சுட்டிக்காட்டும் கோப்புகளின் contents-ஐ அல்ல, resolved service definition-ஐ hash செய்கிறது. Container-ல் mount செய்யப்பட்டு, startup நேரத்தில் ஒருமுறை வாசிக்கப்படும் config file-ஐ நீங்கள் திருத்தினாலும் recreate தொடங்காது. காரணம் mount path மாறவில்லை. Service, boot நேரத்தில் வாசித்த values-ஐக் கொண்டு தொடர்ந்து இயங்கும்.

docker compose up -d --force-recreate

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

docker compose pull
docker compose up -d

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

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

மனதில் வைத்திருக்க வேண்டிய கருத்து

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

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

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

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

no configuration file provided: not found என்பது compose.yaml அல்லது docker-compose.yml இல்லாத directory-யில் Compose இயங்குகிறது என்பதைக் குறிக்கிறது. முழு path-ஐக் கொண்டு -f-ஐ வழங்கவும்.

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

Service-ஐ rename அல்லது delete செய்த பின்னர் Found orphan containers ([voltest-old-1]) for this project தோன்றும். பழைய container-ல் project label இன்னும் உள்ளது. docker compose down --remove-orphans அவற்றை நீக்குகிறது. ஆரோக்கியமாக இயங்கும் stack-ல் இதை இயக்குவது பாதுகாப்பானது.

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

FAQ

docker compose down இயக்கினால் எனது database நீக்கப்படுமா?

database, named volume அல்லது bind mount-ல் இருந்தால் நீக்கப்படாது. down containers மற்றும் project network-ஐ நீக்குகிறது. volume அதன் data-வுடன் disk-ல் அப்படியே இருக்கும். அடுத்த docker compose up -d அதே volume-ஐ புதிய container-க்கு இணைக்கும். Data அங்கே இருக்கும். docker compose down -v மட்டுமே named volumes-ஐ நீக்குகிறது. அதுவும் Compose file-இன் volumes section-ல் அறிவிக்கப்பட்ட volumes-ஐ மட்டுமே நீக்குகிறது.

மீண்டும் பயன்படுத்த வேண்டிய container-க்கு stop மற்றும் down இடையிலான வேறுபாடு என்ன?

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

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

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

Mounted config file-ல் செய்த மாற்றத்தை எனது container ஏன் புறக்கணிக்கிறது?

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

POSTGRES_PASSWORD-ஐ மாற்றிய பிறகு புதிய password ஏன் செயல்படவில்லை?

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