ความแตกต่างระหว่าง docker compose stop กับ down

คำตอบโดยย่อ

docker compose stop จะหยุดการทำงานของคอนเทนเนอร์แต่ยังคงเก็บไฟล์ไว้บนดิสก์ ส่วน docker compose down จะหยุดการทำงานแล้วลบทั้งคอนเทนเนอร์และเน็ตเวิร์กที่ Compose สร้างขึ้นสำหรับโปรเจกต์นั้นทิ้งไป ทั้งสองคำสั่งจะไม่ส่งผลกระทบต่อ named volume หากเพิ่มแฟล็ก -v เข้าไป เช่นในคำสั่ง docker compose down -v ระบบจะลบ named volume ที่ไม่ได้ระบุว่าเป็น external ซึ่งประกาศไว้ในส่วน volumes ของไฟล์ Compose ที่เป็นของโปรเจกต์นี้ สิ่งที่ down จะลบทิ้งอย่างถาวรคือข้อมูลทุกอย่างที่คอนเทนเนอร์เขียนลงใน writable layer ของตัวเอง ซึ่งอยู่นอกเหนือจาก volume ใดๆ

นี่คือความแตกต่างทั้งหมดในย่อหน้าเดียว ส่วนที่เหลือของคู่มือนี้จะพิสูจน์ให้เห็นด้วย Postgres volume ที่คุณสามารถตรวจสอบได้ว่ามันยังคงอยู่หลังการใช้ down และจะหายไปเมื่อใช้ down -v พร้อมทั้งอธิบายกรณีการใช้งาน 2 กรณีที่คุณจำเป็นต้องใช้ --force-recreate

docker compose stop: คอนเทนเนอร์ยังคงอยู่

stop จะส่งสัญญาณหยุดที่กำหนดไว้ให้กับคอนเทนเนอร์ ซึ่งโดยปกติคือ SIGTERM ไปยังกระบวนการหลักในแต่ละคอนเทนเนอร์ จากนั้นจะรอและส่ง SIGKILL หากกระบวนการดังกล่าวยังทำงานอยู่ ระยะเวลาการรอเริ่มต้นคือ 10 วินาที และ -t สามารถใช้เพื่อปรับเปลี่ยนค่านี้ได้ โดยไม่มีการลบข้อมูลใดๆ คอนเทนเนอร์จะยังคงรักษา ID, เลเยอร์ที่เขียนได้ (writable layer) และ log ของตนเองไว้

docker compose stop
docker compose ps -a

docker compose ps โดยปกติจะแสดงเฉพาะคอนเทนเนอร์ที่กำลังทำงานอยู่ ดังนั้นหลังจากใช้ stop คำสั่งนี้จะแสดงตารางว่างเปล่า ซึ่งทำให้ผู้ใช้เข้าใจผิดว่าคอนเทนเนอร์ถูกลบไปแล้ว ps -a จะรวมคอนเทนเนอร์ที่หยุดทำงานแล้วด้วย และนั่นคือจุดที่คุณจะเห็นสถานะ Exited ปรากฏอยู่ถัดจากแต่ละเซอร์วิส พร้อมกับ exit code ที่กระบวนการนั้นส่งกลับมา การปิดระบบอย่างสมบูรณ์มักจะแสดงสถานะ Exited (0) แต่ก็ไม่เสมอไป เซิร์ฟเวอร์บางตัวอาจปิดการทำงานอย่างเรียบร้อยแล้วส่งสัญญาณหยุดซ้ำอีกครั้งเพื่อให้กระบวนการสิ้นสุดลงด้วยสัญญาณนั้น ซึ่ง Uvicorn ทำงานในลักษณะนี้ ดังนั้นการหยุดทำงานที่เป็นระเบียบก็อาจส่งผลให้เกิดรหัสที่ไม่ใช่ศูนย์ได้เช่นกัน รหัสที่ไม่ใช่ศูนย์ยังอาจหมายถึงกระบวนการล้มเหลวหรือถูกสั่งยุติหลังจากหมดเวลาที่กำหนด คุณสามารถเรียกใช้งานคอนเทนเนอร์เหล่านั้นกลับมาได้ด้วย docker compose start ซึ่งจะเป็นการนำคอนเทนเนอร์เดิมกลับมาใช้งานต่อ

เนื่องจากคอนเทนเนอร์ยังคงมีอยู่ ข้อมูลใดๆ ที่ถูกเขียนไว้ภายในคอนเทนเนอร์นอกเหนือจาก volume จะยังคงอยู่ ซึ่งรวมถึงแพ็กเกจที่คุณติดตั้งด้วยตนเองผ่าน docker compose exec และไฟล์คอนฟิกที่คุณแก้ไขไว้ภายในคอนเทนเนอร์ นี่คือเหตุผลในทางปฏิบัติที่ควรเลือกใช้ 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 จะถูกลบออกไป ชื่อโปรเจกต์จะมาจากชื่อไดเรกทอรีของโปรเจกต์ เว้นแต่คุณจะตั้งค่า name: ไว้ในไฟล์ Compose, ตั้งค่า COMPOSE_PROJECT_NAME หรือส่งค่าผ่าน -p การเปลี่ยนแปลงทุกอย่างที่คุณทำภายใน writable layer ของคอนเทนเนอร์จะไม่สามารถกู้คืนได้ ดังนั้นให้ถือว่า down เป็นคำสั่งที่ทิ้งคอนเทนเนอร์ไป แต่ยังคงรักษาข้อมูลที่คุณเก็บไว้ในวอลุ่มเอาไว้

หาก Compose ไม่พบไฟล์คอนฟิกูเรชันในไดเรกทอรีปัจจุบันหรือไดเรกทอรีแม่ และคุณไม่ได้ระบุไฟล์ผ่าน -f หรือ COMPOSE_FILE คุณจะได้รับข้อผิดพลาด no configuration file provided: not found เนื่องจาก Compose ไม่ทราบว่าคุณหมายถึงโปรเจกต์ใด จึงปฏิเสธการทำงาน ให้ใช้ docker compose -f /srv/myapp/compose.yaml down เมื่อคุณไม่ได้อยู่ในโฟลเดอร์ของโปรเจกต์นั้น

การใช้ docker compose down จะลบ volume ของฉันหรือไม่?

ไม่ลบ Volume แบบระบุชื่อ (named volume) ที่ประกาศไว้ภายใต้คีย์ระดับบนสุด volumes จะยังคงอยู่หลังจากใช้คำสั่ง down และจะยังคงอยู่แม้คอนเทนเนอร์ที่เชื่อมต่อกับ volume นั้นจะถูกลบไปแล้ว นี่เป็นความกังวลที่พบบ่อยที่สุดเกี่ยวกับคำสั่งนี้ Compose เวอร์ชัน 5.7.0 ได้เปลี่ยนการทำงานของ down -v โดยปัจจุบันคำสั่งนี้จะข้าม volume แบบระบุชื่อที่เป็นของโปรเจกต์อื่นหรือถูกสร้างขึ้นภายนอก Compose พร้อมกับแสดงคำเตือน

ตั้งค่า stack เพื่อใช้ทดสอบ โดยใส่เนื้อหาต่อไปนี้ลงใน compose.yaml ภายในไดเรกทอรีว่างที่ชื่อว่า voltest

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

volumes:
  pgdata:

เริ่มการทำงานของ stack และเขียนข้อมูลหนึ่งแถวที่คุณจะจำได้ในภายหลัง

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');"

ตอนนี้ให้ทำลายคอนเทนเนอร์และตรวจสอบ volume

docker compose down
docker volume ls

ผลลัพธ์ที่ได้จะยังคงแสดง voltest_pgdata อยู่ คอนเทนเนอร์ถูกลบไปแล้วแต่ข้อมูลยังคงอยู่ ให้เริ่ม stack ใหม่อีกครั้งและอ่านข้อมูลแถวนั้น

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

คุณจะได้รับข้อมูลหนึ่งแถวที่มี survived คอนเทนเนอร์ใหม่จะเป็นคอนเทนเนอร์คนละตัวที่มี ID ต่างกัน แต่เชื่อมต่อกับ volume เดิม หากคุณต้องการข้อมูลในภาพรวมที่กว้างขึ้น คู่มือพื้นฐานของ Compose ได้อธิบายเกี่ยวกับ volume แบบระบุชื่อเปรียบเทียบกับ bind mounts และตำแหน่งที่แท้จริงของข้อมูลแต่ละประเภทบนโฮสต์ไว้แล้ว

คำสั่ง down -v ทำลายข้อมูลอะไรบ้าง

-v (รูปแบบเต็มคือ --volumes) จะลบ named volumes ที่ไม่ได้เป็นแบบ external ซึ่งถูกประกาศไว้ในส่วน volumes ของไฟล์ Compose ที่เป็นของโปรเจกต์นี้ รวมถึง anonymous volumes ที่ผูกอยู่กับคอนเทนเนอร์ด้วย ใน Compose v5.7.0 หากพบ named volume ที่มีป้ายกำกับความเป็นเจ้าของของโปรเจกต์อื่นหรือไม่มีป้ายกำกับโปรเจกต์ ระบบจะข้ามการลบและแสดงคำเตือน หากไม่สามารถตรวจสอบความเป็นเจ้าของได้ คำสั่งจะล้มเหลวและเก็บ volume นั้นไว้ ให้รันคำสั่งนี้กับ stack เดียวกัน

docker compose down -v
docker volume ls

voltest_pgdata จะไม่ปรากฏในรายการอีกต่อไป เมื่อเริ่ม stack ใหม่อีกครั้ง Postgres entrypoint จะพบว่าไดเรกทอรีข้อมูลว่างเปล่า จึงทำการเริ่มต้น cluster ใหม่ ซึ่ง log ของคอนเทนเนอร์จะระบุเรื่องนี้ไว้อย่างชัดเจน

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

การเห็นข้อความดังกล่าวบน stack ที่รันมานานหลายเดือนหมายความว่า Postgres กำลังเริ่มต้นไดเรกทอรีข้อมูลที่ว่างเปล่า ตาราง marker ของคุณหายไปแล้ว และวิธีเดียวที่จะกู้คืนได้คือการใช้ข้อมูลสำรอง

พื้นที่จัดเก็บข้อมูลบางส่วนจะไม่ถูกลบโดย -v ตัวอย่างเช่น bind mount ซึ่งเป็น path บนโฮสต์ Docker จะทำเพียงแค่ unmount ออกเท่านั้น และไฟล์ของคุณจะยังคงอยู่ที่เดิม ส่วน volume ที่ระบุว่า external: true จะถูกประกาศว่ามีเจ้าของเป็นสิ่งที่อยู่นอกเหนือจากโปรเจกต์นี้ Compose จึงไม่ลบออก นอกจากนี้ named volume ที่คุณลบออกจากไฟล์ Compose ก่อนรัน down -v จะถือว่าไม่ได้ถูกประกาศไว้ Compose จึงไม่ทราบว่าต้องลบออก และมันจะถูกทิ้งไว้เป็น orphan เพื่อรอ docker volume prune -a เมื่อไม่มีคอนเทนเนอร์ใดอ้างอิงถึงมันอีกต่อไป

กรณีสุดท้ายนี้มักทำให้ผู้ใช้งานพลาดระหว่างการปรับโครงสร้าง (refactor) หากคุณลบ service และ volume ออกจากไฟล์ แล้วรัน down -v ตัว volume จะยังคงอยู่เพราะไฟล์ไม่ได้ระบุถึงมันอีกต่อไป ดังนั้นควรเลือกใช้ down -v ก่อนที่คุณจะแก้ไขไฟล์ ไม่ใช่หลังจากนั้น

เมื่อคุณจำเป็นต้องใช้ --force-recreate จริงๆ

docker compose up -d ไม่ได้สร้างคอนเทนเนอร์ใหม่ทั้งหมดทุกครั้ง Compose จะเก็บค่า hash ของการตั้งค่าที่ resolve แล้วของแต่ละบริการไว้เป็น label บนคอนเทนเนอร์ ใน Compose v5.7.0 คอนเทนเนอร์ที่กำลังทำงานอยู่จะไม่ถูกแตะต้องหากค่า hash ของการตั้งค่า, image ID และ image-volume digest ตรงกัน รวมถึงการเชื่อมต่อเครือข่ายและ named volume ที่ระบุไว้ยังอยู่ครบ และไม่มี parent ที่แชร์ namespace หรือ volume ถูกสร้างใหม่ คุณจะได้รับผลลัพธ์เป็น Container voltest-db-1 Running แทนที่จะเป็น Recreated ซึ่งเป็นพฤติกรรมที่คุณต้องการเกือบทุกครั้ง เพราะทำให้การรัน up -d ซ้ำๆ มีความปลอดภัย

นี่คือเหตุผลว่าทำไมการแก้ไขบางอย่างถึงดูเหมือนไม่มีผล Compose ทำการ hash ที่ตัวนิยามบริการ (service definition) ที่ resolve แล้ว ไม่ใช่เนื้อหาของไฟล์ที่นิยามนั้นอ้างถึง ไฟล์ config ที่ถูก mount เข้าไปในคอนเทนเนอร์และถูกอ่านเพียงครั้งเดียวตอนเริ่มต้นทำงาน จะไม่กระตุ้นให้เกิดการสร้างคอนเทนเนอร์ใหม่เมื่อคุณแก้ไขไฟล์นั้น เพราะ path ของการ mount ไม่ได้เปลี่ยนแปลง บริการจะยังคงทำงานต่อไปด้วยค่าที่อ่านได้ตอนบูต

docker compose up -d --force-recreate

คำสั่งนี้จะหยุดและลบแต่ละคอนเทนเนอร์ทิ้ง แล้วสร้างคอนเทนเนอร์ใหม่จากนิยามเดิม ให้ใช้คำสั่งนี้หลังจากแก้ไขไฟล์ config ที่ถูก mount ไว้ หรือเมื่อคอนเทนเนอร์อยู่ในสถานะที่คุณไม่สามารถอธิบายได้ ข้อมูลใน volume จะไม่ถูกแตะต้อง ดังนั้นฐานข้อมูลจะยังคงอยู่หลังจากการ force recreate หากต้องการดึง image ใหม่ที่ใช้ tag เดิม คุณจำเป็นต้องสั่ง pull ด้วย

docker compose pull
docker compose up -d

pull จะดึง image ID ใหม่มา และ up -d จะตรวจพบว่า image ID แตกต่างจากคอนเทนเนอร์ที่กำลังทำงานอยู่ จึงทำการสร้างคอนเทนเนอร์ใหม่ให้โดยอัตโนมัติ การเพิ่ม --force-recreate โดยไม่มี pull จะทำให้คุณได้คอนเทนเนอร์ใหม่จาก image เดิมที่ใช้อยู่ นี่คือเหตุผลว่าทำไม "ฉัน force recreate แล้วแต่ยังเป็นเวอร์ชันเก่าอยู่" จึงเป็นปัญหาที่พบได้บ่อย

docker compose restart ไม่ได้ทำสิ่งเหล่านี้เลย มันเพียงแค่รีสตาร์ทคอนเทนเนอร์ที่มีอยู่โดยไม่นำการเปลี่ยนแปลงการตั้งค่าไปใช้ ดังนั้นหากมีการเปลี่ยน environment variable หรือเปลี่ยน port mapping การเปลี่ยนแปลงเหล่านั้นจะไม่มีผล หากคุณแก้ไขไฟล์ ให้ใช้ up -d แทน

แนวคิดที่ควรยึดถือ

คอนเทนเนอร์เป็นสิ่งที่ทดแทนได้ คอนเทนเนอร์คือกระบวนการทำงาน (process) รวมกับเลเยอร์ที่เขียนทับได้ (writable layer) ซึ่ง Compose สามารถสร้างคอนเทนเนอร์ใหม่ขึ้นมาแทนที่ได้จากไฟล์และอิมเมจ แต่ Volumes ไม่สามารถทดแทนได้ เนื่องจากเป็นที่เก็บสำเนาข้อมูลสถานะเพียงชุดเดียวที่ไม่มีไฟล์ใดใน repository ของคุณสามารถสร้างขึ้นมาใหม่ได้

คำสั่งทุกคำสั่งของ Compose สอดคล้องกับการแบ่งแยกนี้ stop และ start จะคงคอนเทนเนอร์ไว้ ส่วน down และ up จะแทนที่คอนเทนเนอร์แต่ยังคง Volume ไว้ down -v เป็นคำสั่งปกติเพียงคำสั่งเดียวที่ลบข้อมูลสถานะทิ้ง ซึ่งเป็นเหตุผลว่าทำไมจึงต้องใช้ flag ระบุเจาะจง ก่อนที่คุณจะพิมพ์คำสั่งนี้กับระบบงานจริง ให้ยืนยันก่อนว่าคุณมีข้อมูลสำรองที่เคยทดสอบกู้คืนสำเร็จมาแล้วอย่างน้อยหนึ่งครั้ง

ตรรกะเดียวกันนี้ใช้กับ secrets รหัสผ่านที่ตั้งค่าผ่าน POSTGRES_PASSWORD จะถูกใช้เพื่อกำหนดรหัสผ่านฐานข้อมูลเฉพาะตอนที่ฐานข้อมูลเริ่มทำงานครั้งแรกเท่านั้น ดังนั้นการเปลี่ยนรหัสผ่านในไฟล์ environment แล้วรัน up -d จะไม่ทำให้รหัสผ่านที่จัดเก็บไว้ในฐานข้อมูลเปลี่ยนแปลงตาม คอนเทนเนอร์จะเป็นชุดใหม่แต่ Volume ยังคงเป็นชุดเดิม และ Volume เดิมนั้นยังคงเก็บรหัสผ่านเก่าเอาไว้ วิธีที่ Compose จัดการกับไฟล์ env และ secrets อธิบายว่าเลเยอร์ใดจะมีผลเหนือกว่าเมื่อมีการตั้งค่าตัวแปรเดียวกันซ้ำสองครั้ง

รูปแบบความล้มเหลวและข้อความที่คุณจะพบ

no configuration file provided: not found หมายความว่า Compose ไม่พบไฟล์คอนฟิกูเรชันผ่านการค้นหาในไดเรกทอรีปัจจุบันและไดเรกทอรีแม่ -f หรือ COMPOSE_FILE ให้ระบุ -f พร้อมระบุพาธแบบเต็ม

Network voltest_default Resource is still in use บน down ใน Compose v5.7.0 หมายความว่ายังมีคอนเทนเนอร์เชื่อมต่ออยู่กับเน็ตเวิร์กของโปรเจกต์ ซึ่งมักเป็นคอนเทนเนอร์ภายนอกโปรเจกต์ที่ถูกสั่งเริ่มทำงานด้วยมือผ่าน docker run --network ให้ลบคอนเทนเนอร์เหล่านั้นออก แล้วรัน down อีกครั้ง

Found orphan containers (voltest-old-1) for this project จะปรากฏขึ้นหลังจากที่คุณเปลี่ยนชื่อหรือลบเซอร์วิส Compose เวอร์ชันปัจจุบันจะแสดงรายการชื่อเปล่าๆ และคั่นด้วยเครื่องหมายจุลภาค Compose v2 รุ่นเก่าจะแสดงคำเตือนเดียวกันโดยมีชื่ออยู่ในวงเล็บเหลี่ยม ดังเช่น ([voltest-old-1]) คอนเทนเนอร์เก่ายังคงมีป้ายกำกับ (label) ของโปรเจกต์ติดอยู่ docker compose down --remove-orphans จะล้างค่าเหล่านี้ออก

Error response from daemon: remove voltest_pgdata: volume is in use ในการสั่ง docker volume rm ด้วยมือ หมายความว่ายังมีคอนเทนเนอร์บางตัวอ้างอิงถึงโวลุ่มนั้นอยู่ รวมถึงคอนเทนเนอร์ที่หยุดทำงานไปแล้ว ให้รัน docker compose down ก่อน จากนั้นจึงลบโวลุ่ม หรือใช้เพียง down -v ในโปรเจกต์ขนาดใหญ่ สแต็ก Compose แบบหลายเซอร์วิส จะแสดงให้เห็นว่าโปรเจกต์หนึ่งสามารถสะสมโวลุ่มได้มากเพียงใด

FAQ

docker compose down จะลบฐานข้อมูลของฉันหรือไม่?

จะไม่ลบหากฐานข้อมูลอยู่ใน named volume หรือ bind mount คำสั่ง down จะลบเฉพาะคอนเทนเนอร์และเครือข่ายของโปรเจกต์ ส่วน volume จะยังคงอยู่บนดิสก์พร้อมข้อมูลครบถ้วน การรัน docker compose up -d ในครั้งถัดไปจะเชื่อมต่อคอนเทนเนอร์ใหม่เข้ากับ volume เดิมและข้อมูลจะยังคงอยู่ ส่วน docker compose down -v จะลบ named volume ที่ไม่ได้ระบุว่าเป็น external ซึ่งประกาศไว้ในส่วน volumes ของไฟล์ Compose ที่เป็นของโปรเจกต์นี้เท่านั้น

stop กับ down ต่างกันอย่างไรสำหรับคอนเทนเนอร์ที่ฉันต้องการใช้งานต่อ?

stop จะเก็บคอนเทนเนอร์ไว้ ดังนั้น docker compose start จะทำให้คุณกลับไปใช้งานคอนเทนเนอร์เดิมที่มี writable layer เดิมได้ สิ่งใดก็ตามที่คุณติดตั้งหรือแก้ไขภายในคอนเทนเนอร์ด้วยตนเองจะยังคงอยู่ ส่วน down จะลบคอนเทนเนอร์ทิ้ง ดังนั้น up -d ในครั้งถัดไปจะเป็นการสร้างคอนเทนเนอร์ใหม่จาก image และการแก้ไขด้วยตนเองเหล่านั้นจะสูญหายไป ในระหว่างการดีบั๊ก ให้ใช้ stop

ฉันจะลบทุกอย่างที่โปรเจกต์ Compose สร้างขึ้นมาได้อย่างไร?

docker compose down -v --rmi all --remove-orphans จะลบคอนเทนเนอร์, เครือข่ายของโปรเจกต์, named volume ที่ไม่ได้เป็น external ซึ่งประกาศไว้ในไฟล์และเป็นของโปรเจกต์นี้, image ที่บริการต่างๆ ใช้งาน รวมถึงคอนเทนเนอร์ที่ตกค้าง (orphan) ของโปรเจกต์นั้นๆ คำสั่งนี้จะไม่แตะต้อง bind mount หรือ volume ที่ระบุว่าเป็น external: true ให้ตรวจสอบสิ่งที่จะสูญหายด้วย docker volume ls ก่อนที่จะรันคำสั่งจริง

ทำไมคอนเทนเนอร์ของฉันถึงไม่สนใจการเปลี่ยนแปลงที่ฉันทำกับไฟล์ config ที่ mount ไว้?

Compose จะตัดสินใจว่าจะสร้างคอนเทนเนอร์ใหม่หรือไม่โดยการเปรียบเทียบ hash ของนิยามบริการที่ประมวลผลแล้ว ซึ่ง hash ดังกล่าวไม่ได้รวมเนื้อหาของไฟล์ที่ mount ไว้ด้วย เนื่องจาก path ไม่ได้เปลี่ยน Compose จึงปล่อยให้คอนเทนเนอร์ทำงานต่อไปด้วยค่าที่อ่านได้ตั้งแต่ตอนเริ่มต้น ให้รัน docker compose up -d --force-recreate เพื่อสร้างคอนเทนเนอร์ใหม่ที่จะอ่านไฟล์นั้นอีกครั้ง

ทำไม POSTGRES_PASSWORD ใหม่ของฉันถึงใช้งานไม่ได้หลังจากเปลี่ยนค่าแล้ว?

image ของ Postgres จะใช้ POSTGRES_PASSWORD เพื่อตั้งค่ารหัสผ่านฐานข้อมูลเฉพาะตอนที่เริ่มสร้างไดเรกทอรีข้อมูลที่ว่างเปล่าเท่านั้น เนื่องจาก volume ของคุณมี cluster ที่ถูกสร้างไว้แล้ว ตัวแปรนี้จึงถูกละเลยและรหัสผ่านเดิมยังคงมีผลอยู่ การเชื่อมต่อด้วยรหัสผ่านใหม่จะทำให้เกิดข้อผิดพลาด password authentication failed for user "postgres" ให้เปลี่ยนรหัสผ่านด้วย ALTER USER ภายในฐานข้อมูลที่กำลังทำงานอยู่ หรือยอมรับการสูญเสียข้อมูลและเริ่มใหม่ด้วย docker compose down -v