Docker Compose stop மற்றும் down இடையே உள்ள வேறுபாடு என்ன?

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

docker compose stop கன்டெய்னர்களை நிறுத்திவிட்டு, அவற்றை வட்டில் (disk) அப்படியே வைத்திருக்கும். docker compose down கன்டெய்னர்களை நிறுத்திவிட்டு, அந்தத் திட்டத்திற்காக Compose உருவாக்கிய கன்டெய்னர்கள் மற்றும் நெட்வொர்க்கை நீக்கிவிடும். இந்த இரண்டு கட்டளைகளுமே named volume-களைப் பாதிக்காது. docker compose down -v-ல் உள்ளது போல -v-ஐச் சேர்த்தால், அந்தத் திட்டத்தின் volumes பகுதியில் குறிப்பிடப்பட்டுள்ள, external அல்லாத named volume-கள் நீக்கப்படும். down எதை அழிக்கும் என்றால், ஒரு கன்டெய்னர் எந்தவொரு volume-க்கும் வெளியே அதன் சொந்த writable layer-ல் எழுதிய தரவுகளை மட்டுமே.

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

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

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

docker compose stop
docker compose ps -a

docker compose ps கட்டளை இயங்கும் container-களை மட்டுமே காட்டும். எனவே stop கட்டளைக்குப் பிறகு, அது காலியான அட்டவணையை மட்டுமே காட்டும்; இதனால் containers நீக்கப்பட்டுவிட்டதாகப் பலர் தவறாக நினைக்கிறார்கள். ps -a கட்டளை நிறுத்தப்பட்ட container-களையும் காட்டும். அங்கு ஒவ்வொரு service-க்கும் அருகில் Exited என்ற நிலையையும், அதன் process வழங்கிய exit code-ஐயும் நீங்கள் காணலாம். ஒரு முறையான shutdown பெரும்பாலும் Exited (0) என்று காட்டும், ஆனால் எப்போதும் அப்படி இருக்காது. சில servers graceful shutdown-ஐ முடித்த பிறகு, மீண்டும் stop signal-ஐ எழுப்பும்; இதனால் process அந்த signal மூலமே முடிவடையும். Uvicorn இதைத்தான் செய்கிறது, எனவே முறையான stop-க்கு பிறகும் non-zero code வரலாம். Non-zero code என்பது process தோல்வியடைந்ததையோ அல்லது timeout-க்கு பிறகு கொல்லப்பட்டதையோ குறிக்கலாம். docker compose start கட்டளையைப் பயன்படுத்தி அவற்றை மீண்டும் தொடங்கலாம்; இது அதே containers-ஐ மீண்டும் பயன்படுத்தும்.

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

docker compose down: கொள்கலன்கள் மற்றும் நெட்வொர்க்குகள் நீக்கப்படுகின்றன

down என்பது கொள்கலன்களை நிறுத்திவிட்டு, அந்தத் திட்டத்திற்காக Compose உருவாக்கிய இயல்புநிலை நெட்வொர்க்கையும் நீக்குகிறது. Docker ஆவணங்களின்படி, இது கொள்கலன்களை நிறுத்திவிட்டு, up மூலம் உருவாக்கப்பட்ட கொள்கலன்கள், நெட்வொர்க்குகள், வால்யூம்கள் மற்றும் இமேஜ்களை நீக்குவதாகக் கூறுகிறது. ஆனால், வால்யூம்கள் மற்றும் இமேஜ்கள் நீக்கப்படுவது நீங்கள் -v மற்றும் --rmi ஆகியவற்றை பயன்படுத்தினால் மட்டுமே நடக்கும்.

docker compose down
docker compose ps -a
docker network ls

down கட்டளைக்கு பிறகு, ps -a அந்தத் திட்டத்திற்கு எதையும் காட்டாது மற்றும் <project>_default நெட்வொர்க் நீக்கப்பட்டிருக்கும். நீங்கள் Compose கோப்பில் name:-ஐ அமைக்காதவரை, COMPOSE_PROJECT_NAME-ஐ பயன்படுத்தாதவரை அல்லது -p-ஐ வழங்காதவரை, திட்டத்தின் பெயர் அது இருக்கும் கோப்பகத்தின் (directory) பெயரிலிருந்தே எடுக்கப்படும். கொள்கலனின் writable layer-ல் நீங்கள் செய்த ஒவ்வொரு மாற்றமும் இப்போது மீட்க முடியாதவை. எனவே, down கட்டளையை கொள்கலனைத் தூக்கி எறியும் ஒரு செயலாகக் கருதுங்கள்; இது வால்யூம்களில் நீங்கள் சேமித்த தரவை மட்டும் வைத்திருக்கும்.

தற்போதைய கோப்பகத்திலோ அல்லது அதன் தாய் கோப்பகங்களிலோ Compose-ஆல் ஒரு கட்டமைப்பு கோப்பைக் (configuration file) கண்டறிய முடியவில்லை என்றால், மற்றும் நீங்கள் -f அல்லது COMPOSE_FILE மூலம் அதை வழங்கவில்லை என்றால், உங்களுக்கு no configuration file provided: not found பிழை கிடைக்கும். எந்தத் திட்டத்தைக் குறிப்பிடுகிறீர்கள் என்று Compose-க்குத் தெரியாது என்பதால், அது செயல்பட மறுத்துவிடும். நீங்கள் திட்டக் கோப்பகத்தில் இல்லாதபோது docker compose -f /srv/myapp/compose.yaml down-ஐப் பயன்படுத்தவும்.

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

இல்லை. உயர்மட்ட volumes key-ன் கீழ் அறிவிக்கப்பட்ட ஒரு named volume, down-ஐ விட நீண்ட காலம் நிலைத்திருக்கும்; அது இணைக்கப்பட்டிருந்த container நீக்கப்பட்டாலும் இந்த volume அழியாது. இந்தக் கட்டளையைப் பற்றிய பொதுவான அச்சம் இதுவே. Compose v5.7.0 பதிப்பில் down -v மாற்றப்பட்டது: இப்போது இது மற்றொரு project-க்குச் சொந்தமான அல்லது Compose-க்கு வெளியே உருவாக்கப்பட்ட named volumes-ஐத் தவிர்த்துவிட்டு, ஒரு எச்சரிக்கையை மட்டும் காட்டும்.

நீங்கள் சோதிக்கக்கூடிய ஒரு 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-ல் எங்கு சேமிக்கப்படுகின்றன என்பதையும் விளக்குகிறது.

docker compose down -v எதை நீக்குகிறது

-v (நீண்ட வடிவம் --volumes) என்பது Compose கோப்பின் volumes பகுதியில் அறிவிக்கப்பட்ட, இந்த project-க்கு சொந்தமான external அல்லாத named volumes-ஐயும், containers-உடன் இணைக்கப்பட்ட anonymous volumes-ஐயும் நீக்குகிறது. Compose v5.7.0-ல், மற்றொரு project-ன் ownership label கொண்ட அல்லது project label இல்லாத named volume தவிர்க்கப்பட்டு எச்சரிக்கை விடுக்கப்படும்; அதன் ownership-ஐ ஆய்வு செய்ய முடியாவிட்டால், கட்டளை தோல்வியடைந்து அந்த volume அப்படியே இருக்கும். அதே 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-ல் இந்தத் தகவலைக் காண்பது, Postgres ஒரு காலி data directory-ஐத் தயார் செய்கிறது என்று அர்த்தம். உங்கள் marker அட்டவணை அழிந்துவிட்டது; அதை மீட்டெடுக்க backup மட்டுமே ஒரே வழி.

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

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

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

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

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

docker compose up -d --force-recreate

இது ஒவ்வொரு container-ஐயும் நிறுத்தி நீக்கிவிட்டு, அதே definition-லிருந்து புதிய ஒன்றை உருவாக்குகிறது. mount செய்யப்பட்ட config கோப்பில் மாற்றம் செய்த பிறகும், அல்லது ஒரு container உங்களால் விளக்க முடியாத நிலைக்குச் சென்றபோதும் இதைப் பயன்படுத்தவும். Volumes மாற்றப்படாமல் இருப்பதால், force recreate செய்தாலும் database அழியாது. அதே 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-களை அவற்றின் configuration-ல் மாற்றங்களைச் செய்யாமலேயே restart செய்கிறது, எனவே மாற்றப்பட்ட environment variable அல்லது மாற்றப்பட்ட port mapping போன்றவை நடைமுறைக்கு வராது. நீங்கள் கோப்பைத் திருத்தியிருந்தால், up -d-ஐப் பயன்படுத்தவும்.

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

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

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

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

தோல்வி நிலைகளும் நீங்கள் காணும் சரங்களும் (strings)

no configuration file provided: not found என்பது, தற்போதைய கோப்பகம் மற்றும் அதன் பெற்றோர் கோப்பகத் தேடலின் மூலம் Compose-ஆல் ஒரு கட்டமைப்பு கோப்பைக் (configuration file) கண்டறிய முடியவில்லை என்பதைக் குறிக்கிறது, -f, அல்லது COMPOSE_FILE. -f-ஐ முழு பாதையுடன் (full path) வழங்கவும்.

Compose v5.7.0-ல் down மீது வரும் Network voltest_default Resource is still in use, containers இன்னும் project network-உடன் இணைக்கப்பட்டுள்ளன என்பதைக் குறிக்கிறது; இவை பொதுவாக docker run --network மூலம் கைமுறையாகத் தொடங்கப்பட்ட, இந்த project-க்கு வெளியே உள்ள containers ஆகும். அந்த containers-ஐ நீக்கிவிட்டு, மீண்டும் down-ஐ இயக்கவும்.

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

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

FAQ

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

database ஒரு named volume அல்லது bind mount-ல் இருந்தால் நீக்காது. down containers மற்றும் project network-ஐ மட்டுமே நீக்கும்; volume அதன் தரவுகளுடன் வட்டில் அப்படியே இருக்கும். அடுத்த docker compose up -d கட்டளை அதே volume-உடன் புதிய container-ஐ இணைக்கும், தரவுகள் அப்படியே இருக்கும். docker compose down -v கட்டளை, Compose file-ன் volumes பகுதியில் குறிப்பிடப்பட்டுள்ள, இந்த project-க்கு சொந்தமான external அல்லாத named 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 கட்டளை containers, project network, file-ல் குறிப்பிடப்பட்ட external அல்லாத named volumes, services பயன்படுத்திய images மற்றும் அந்த project-ன் orphan containers ஆகியவற்றை நீக்கும். இது bind mounts அல்லது external: true எனக் குறிக்கப்பட்ட volumes-ஐ பாதிக்காது. நீங்கள் எதை இழக்கப்போகிறீர்கள் என்பதை docker volume ls மூலம் சரிபார்த்த பிறகு இதை இயக்கவும்.

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

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

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

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