รวมคำสั่ง Docker Compose ที่ต้องใช้จริงบนเซิร์ฟเวอร์

คำสั่ง Compose ที่คุณต้องใช้งานจริง

Docker Compose มีคำสั่งย่อยมากกว่า 40 คำสั่ง แต่การทำงานบนเซิร์ฟเวอร์ในแต่ละวันใช้เพียงประมาณ 12 คำสั่งเท่านั้น หน้านี้จะจัดกลุ่มคำสั่งเหล่านั้นตามงานที่คุณทำ พร้อมระบุเหตุผลสั้นๆ สำหรับแต่ละคำสั่ง และชี้ไปยังเนื้อหาเชิงลึกในกรณีที่คำสั่งนั้นอาจมีข้อควรระวังแฝงอยู่

เนื้อหาทั้งหมดที่นี่ใช้ Compose V2 คือ docker compose โดยเว้นวรรค ไม่ใช่สคริปต์ docker-compose แบบเก่า V2 เป็น Go plugin ที่ติดตั้งมาพร้อมกับ Docker Engine และ V1 ได้ถูกถอดออกจากแพ็กเกจปัจจุบันแล้ว ดังนั้นการใช้ docker-compose: command not found บน Ubuntu เวอร์ชันใหม่ ณ เดือนกรกฎาคม 2026 จึงเป็นเรื่องปกติ ไม่ใช่ข้อผิดพลาด ตรวจสอบด้วย docker compose version หากคำสั่งดังกล่าวไม่แสดงผลลัพธ์ใดๆ ให้ติดตั้งแพ็กเกจ docker-compose-plugin

ทุกคำสั่งด้านล่างนี้ต้องรันจากไดเรกทอรีที่มีไฟล์ compose.yaml ของคุณ เนื่องจาก Compose จะดึงชื่อโปรเจกต์จากไดเรกทอรีนั้นและค้นหาไฟล์โดยอ้างอิงจากตำแหน่งดังกล่าว หากคุณรันคำสั่งเดิมในระดับโฟลเดอร์ที่สูงขึ้นไปหนึ่งชั้น Compose จะหยุดทำงานพร้อมกับแจ้ง no configuration file provided: not found หากรูปแบบไฟล์ยังเป็นเรื่องใหม่สำหรับคุณ ให้เริ่มต้นที่ การสร้างไฟล์ Compose ไฟล์แรกบน VPS แล้วค่อยกลับมาดูคำสั่งเหล่านี้ที่นี่

วงจรชีวิต: สี่คำสั่งที่คุณต้องใช้ และหนึ่งคำสั่งสำหรับลบ container

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, สร้าง container, เริ่มการทำงานของ container แล้วจบการทำงานทันที คำสั่งนี้จะคืนค่ากลับมาทันทีที่ container ถูก สร้าง เสร็จสิ้น ซึ่งเป็นสาเหตุที่สคริปต์ deploy ที่ใช้คำสั่ง curl ตรวจสอบต่อท้ายมักจะล้มเหลวในการรันครั้งแรก up -d --wait จะรอจนกว่าทุกบริการที่ประกาศ healthcheck ไว้จะรายงานสถานะว่าปกติ และจะจบการทำงานด้วยสถานะ non-zero หากมีบริการใดไม่สามารถเข้าสู่สถานะปกติได้ คำสั่งนี้จะมีประสิทธิภาพเท่ากับตัวตรวจสอบที่อยู่เบื้องหลังเท่านั้น ดังนั้นควรเขียน healthcheck ที่ Compose เชื่อถือได้ ก่อนที่จะนำไปใช้ในระบบอัตโนมัติ

stop จะหยุดการทำงานของ container แต่ยังคงเก็บ container เหล่านั้นไว้ ดังนั้น start จึงสามารถนำ container เดิมกลับมาทำงานต่อได้โดยที่ข้อมูลใน writable layer ยังคงอยู่ down จะหยุดการทำงานของ container จากนั้นจึงลบ container และ project network ทิ้ง ข้อมูลใดก็ตามที่เขียนไว้ภายใน container และไม่ได้อยู่ใน volume จะถูกลบหายไปพร้อมกัน นี่คือความเข้าใจผิดที่สร้างความเสียหายมากที่สุดในการใช้งาน Compose และบทความ ความแตกต่างทั้งหมดระหว่าง down และ stop ได้อธิบายถึงผลกระทบที่อาจเกิดขึ้นไว้แล้ว

restart ไม่ใช่การ reload คำสั่งนี้จะหยุดและเริ่ม container เดิมด้วยการตั้งค่าที่มีอยู่แล้ว ดังนั้นการเปลี่ยนแปลง environment variable, การเปลี่ยน image tag หรือการแก้ไข port mapping จะไม่มีผลใดๆ ทั้งสิ้น หากต้องการนำการเปลี่ยนแปลงไฟล์ไปใช้ คุณต้องรัน up -d อีกครั้ง Compose จะเปรียบเทียบแต่ละบริการกับ container ที่กำลังทำงานอยู่ และจะสร้างใหม่เฉพาะบริการที่มีการตั้งค่าเปลี่ยนแปลงไปเท่านั้น

การปรับใช้การเปลี่ยนแปลง: การสร้างใหม่ (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 จะไม่ดำเนินการใดๆ หากไม่มีการเปลี่ยนแปลง ซึ่งเป็นเหตุผลว่าทำไมจึงสามารถรันคำสั่งนี้ซ้ำๆ ได้อย่างปลอดภัย --force-recreate จะข้ามการเปรียบเทียบดังกล่าวและแทนที่คอนเทนเนอร์ทุกตัวแม้ว่าการกำหนดค่าจะเหมือนเดิมทุกประการ จึงเป็นวิธีที่รวดเร็วที่สุดในการล้างสถานะที่ผิดปกติภายในคอนเทนเนอร์

การอัปเดต image ต้องใช้ 2 คำสั่ง เพราะแต่ละคำสั่งทำงานต่างกัน pull จะดาวน์โหลด image ปัจจุบันสำหรับแต่ละ tag ที่ระบุไว้ในไฟล์ จากนั้น up -d จะตรวจพบว่า image ID ของ service ไม่ตรงกับ container ที่กำลังทำงานอยู่ จึงสร้าง container ใหม่ หากข้ามขั้นตอน pull up -d จะคงให้ latest ของเดือนที่แล้วทำงานต่อไปโดยไม่แสดงข้อผิดพลาด ความเสี่ยงในทางกลับกันเกิดขึ้นกับ stack ที่มีหลาย service ซึ่งการ pull latest สำหรับทุก service พร้อมกันอาจทำให้แอปที่ทำงานปกติเมื่อ 10 วินาทีก่อนหยุดทำงานได้ ด้วยเหตุนี้ workspace AFFiNE แบบ self-hosted จึงกำหนด tag ของ image ทั้ง 4 รายการแยกกัน

การ pin ยังทำให้การอัปเกรดเป็นการแก้ไข tag โดยตั้งใจ ตามด้วยการ pull และสร้าง container ใหม่ด้วยขั้นตอนเดิม และสำหรับ stack ที่ migrate database ระหว่างการเริ่มต้นระบบ ควรมี dump พร้อมก่อนใช้คำสั่งใดคำสั่งหนึ่ง ซึ่งเป็นขั้นตอนปกติที่ ระบบ help desk Chatwoot แบบ self-hosted ใช้กับการเพิ่ม version ทุกครั้ง

build ใช้กับบริการที่ประกาศส่วน build: แทนการใช้ image: คำสั่ง up -d --build จะทำการ build และ start ในขั้นตอนเดียว ซึ่งเป็นวงจรการทำงานปกติในขณะที่คุณกำลังแก้ไขโค้ด ให้ใช้ --no-cache เฉพาะเมื่อเลเยอร์ที่ถูกแคชไว้ล้าสมัยอย่างชัดเจนเท่านั้น เนื่องจากคำสั่งนี้จะสร้างทุกเลเยอร์ขึ้นใหม่ตั้งแต่ต้น

การตรวจสอบสิ่งที่กำลังทำงานอยู่

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 จะแสดงเฉพาะคอนเทนเนอร์ที่กำลังทำงานอยู่เท่านั้น บริการที่ล้มเหลวระหว่างการเริ่มทำงานจะไม่ปรากฏในรายการจนกว่าคุณจะเพิ่ม -a ดังนั้นการที่คอนเทนเนอร์ไม่ปรากฏใน ps ในขณะที่ ps -a แสดงสถานะเป็น Exited (1) จึงเป็นลักษณะปกติของความล้มเหลวในการเริ่มทำงาน ให้ตรวจสอบ exit code แล้วจึงอ่าน log

logs -f จะติดตามทุกบริการพร้อมกันและใส่ชื่อบริการไว้หน้าแต่ละบรรทัด ซึ่งเป็นมุมมองที่คุณต้องการเมื่อบริการต่างๆ สื่อสารกันและลำดับของเหตุการณ์มีความสำคัญ คุณสามารถระบุชื่อบริการเพื่อจำกัดขอบเขตได้ --tail=100 มีความสำคัญสำหรับคอนเทนเนอร์ที่ทำงานมานานเป็นเดือน เพราะค่าเริ่มต้นจะแสดงประวัติทั้งหมดและทำให้ terminal เต็มไปด้วยข้อมูล --since 15m จะตอบคำถามที่คุณมักจะสงสัย ซึ่งก็คือเกิดอะไรขึ้นในช่วงการรีสตาร์ทที่คุณเพิ่งทำไป

top จะแสดงรายการกระบวนการ (process) ภายในแต่ละคอนเทนเนอร์ ซึ่งช่วยแยกแยะระหว่าง "คอนเทนเนอร์กำลังทำงาน" กับ "กระบวนการภายในคอนเทนเนอร์กำลังทำงาน" ออกจากกัน ls จะก้าวออกจากไดเรกทอรีปัจจุบันและแสดงรายการโปรเจกต์ Compose ทั้งหมดบนโฮสต์พร้อมสถานะ เพื่อให้คุณสามารถค้นหา stack ที่คุณเริ่มไว้เมื่อสามเดือนก่อนได้

การเข้าถึง Shell ภายใน Service

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 ใช้สำหรับรันคำสั่งภายในคอนเทนเนอร์ที่กำลังทำงานอยู่ ส่วน run จะเริ่มคอนเทนเนอร์ใหม่จากนิยามของ Service เดิม ซึ่งเป็นสิ่งที่คุณต้องใช้เมื่อ Service นั้นไม่สามารถทำงานค้างไว้นานพอที่จะใช้คำสั่ง exec เข้าไปได้ ควรใช้ run คู่กับ --rm เสมอ เพราะหากไม่มีแฟล็กนี้ ทุกครั้งที่เรียกใช้จะทิ้งคอนเทนเนอร์ที่หยุดทำงานไว้เบื้องหลัง และคอนเทนเนอร์เหล่านี้จะสะสมจนทำให้ docker compose ps -a อ่านข้อมูลได้ยาก

ให้ลองใช้ sh ก่อนที่จะใช้ bash เนื่องจากอิมเมจที่ใช้ Alpine เป็นพื้นฐานจะไม่มี bash ติดตั้งมาให้ และจะแสดงข้อผิดพลาดว่า exec: "bash": executable file not found in $PATH การเพิ่ม --no-deps เข้าไปใน run จะเป็นการข้าม Dependency ของ Service นั้นๆ ซึ่งช่วยป้องกันไม่ให้การตรวจสอบ Config เพียงชั่วคราวไปสั่งบูตฐานข้อมูลทั้งหมดของคุณขึ้นมา

run --rm web env เป็นวิธีที่เร็วที่สุดในการดูสภาพแวดล้อม (Environment) ที่ Service ได้รับจริง หลังจากที่ไฟล์ .env, บล็อก environment: และตัวแปร Shell ทั้งหมดถูกรวมเข้าด้วยกันแล้ว เมื่อพบว่าค่าใดค่าหนึ่งไม่ถูกต้อง สาเหตุมักเกิดจากลำดับการรวมข้อมูล และ วิธีที่ Compose จัดการกับไฟล์ env และ secrets ได้อธิบายไว้ว่าแหล่งข้อมูลใดจะมีลำดับความสำคัญสูงสุด

เครือข่าย พอร์ต และการแก้ไขชื่อโฮสต์

docker compose port web 80
docker compose exec web getent hosts db
docker compose config --networks

Compose จะวางทุก service ไว้ใน project network เดียวกัน และชื่อของแต่ละ service จะเป็น DNS name บน network นั้น การเรียกใช้ getent hosts db ภายใน web จะแสดง IP ของ container เมื่อการ resolve สำเร็จ และไม่แสดงผลลัพธ์ใดเมื่อ resolve ไม่สำเร็จ จึงใช้ตอบได้ภายใน 2 วินาทีว่า "container เหล่านี้เชื่อมต่อถึงกันได้หรือไม่" หาก resolve ชื่อได้แต่การเชื่อมต่อถูกปฏิเสธ แสดงว่า process ภายใน db bind อยู่กับ 127.0.0.1 แทนที่จะเป็น 0.0.0.0 จึงไม่รับ packet จาก container อื่น ขอบเขตเดียวกันนี้อธิบายว่าเหตุใด container ที่เริ่มทำงานอยู่นอก project ไม่ว่าจะเริ่มด้วย docker run หรือทำงานเป็น stack ของตนเอง จึง resolve ชื่ออย่าง jellyfin ไม่ได้เลย ซึ่งเป็นสิ่งแรกที่ควรตรวจสอบเมื่อ front end ของ Halcyon สำหรับ library ของ Jellyfin ไม่สามารถเข้าถึง server ที่กำหนดไว้ได้ รายละเอียดส่วนที่เหลือของแนวคิดนี้อยู่ใน วิธีที่ Compose networks และ service DNS ทำงาน

port web 80 จะแสดงที่อยู่โฮสต์และพอร์ตที่พอร์ตของคอนเทนเนอร์ถูกเผยแพร่ออกมา ซึ่งช่วยลดการคาดเดาเมื่อการแมปพอร์ตมาจากตัวแปร การเผยแพร่พอร์ตยังเป็นการเขียนกฎไฟร์วอลล์ที่ Docker จัดการเอง ซึ่งกฎนี้จะอยู่เหนือกว่ากฎที่คุณตั้งไว้ ทำให้บริการที่คุณเข้าใจว่าเป็นส่วนตัวอาจเปิดเผยต่ออินเทอร์เน็ตได้ กรณีนี้อธิบายไว้ใน เหตุใดพอร์ต Docker ที่เผยแพร่จึงข้าม ufw การไม่เผยแพร่พอร์ตเหล่านั้นและใช้พร็อกซีที่มีการยืนยันตัวตนบนเครือข่ายโปรเจกต์วางไว้หน้าบริการต่างๆ เป็นวิธีที่ปลอดภัยกว่า ซึ่งเป็นสิ่งที่ การรัน Authentik เป็นเลเยอร์การลงชื่อเข้าใช้ครั้งเดียว มอบให้คุณ

Volumes และข้อมูล

docker compose config --volumes
docker compose cp db:/etc/postgresql/pg_hba.conf ./pg_hba.conf
docker compose down -v

config --volumes จะแสดงรายการ named volumes ที่โปรเจกต์ประกาศไว้ โดยแสดงผลทีละบรรทัด รายการนี้คือสิ่งที่คุณต้องสำรองข้อมูล เมื่อ volumes บรรจุข้อมูลที่ไม่สามารถหาทดแทนได้ คำสั่งสำรองข้อมูลที่ถูกต้องมีความสำคัญพอๆ กับรายการดังกล่าว ซึ่งเป็นเหตุผลว่าทำไม การเปรียบเทียบ PhotoPrism และ Immich จึงระบุคำสั่ง dump และ copy ที่เซิร์ฟเวอร์รูปภาพแต่ละตัวจำเป็นต้องใช้ cp ใช้สำหรับคัดลอกไฟล์เข้าหรือออกจากคอนเทนเนอร์โดยไม่ต้องเปิด shell โดยใช้รูปแบบ service:path ในฝั่งที่เป็นคอนเทนเนอร์

down -v จะลบ named volumes เหล่านั้นออกพร้อมกับคอนเทนเนอร์ นี่เป็นคำสั่งที่ถูกต้องสำหรับการรื้อถอน stack ที่ใช้ทดสอบ แต่เป็นคำสั่งที่ผิดพลาดสำหรับข้อมูลใดๆ ที่คุณต้องการเก็บรักษาไว้ เนื่องจากไม่มีการยืนยันและไม่สามารถย้อนกลับได้ Bind mounts จะยังคงอยู่เนื่องจากไฟล์เหล่านี้ถูกจัดเก็บไว้ในระบบไฟล์ของโฮสต์ ความแตกต่างในขอบเขตความเสียหายนี้เป็นเหตุผลหนึ่งที่ควรเลือกอย่างรอบคอบระหว่าง bind mounts และ named volumes

การล้างข้อมูลเพื่อเพิ่มพื้นที่ดิสก์โดยไม่สูญเสียข้อมูล

docker compose down --remove-orphans
docker system df
docker image prune -a
docker builder prune

--remove-orphans จะลบ container ที่อยู่ในโปรเจกต์แต่ไม่มีระบุไว้ในไฟล์แล้ว ซึ่งเป็นสิ่งที่เกิดขึ้นหลังจากเปลี่ยนชื่อ service หากไม่มีคำสั่งนี้ container เหล่านั้นจะยังคงทำงานอยู่โดยที่ docker compose ps มองไม่เห็น

docker system df จะแสดงให้เห็นว่าพื้นที่ดิสก์ถูกใช้ไปกับส่วนใดบ้างก่อนที่คุณจะลบสิ่งใดออก โดยจะแยกหมวดหมู่เป็น image, container, local volume และ build cache พร้อมระบุจำนวนพื้นที่ที่สามารถเรียกคืนได้สำหรับแต่ละรายการ image prune -a จะลบ image ทุกตัวที่ไม่มี tag ใดอ้างถึง ซึ่งบนเซิร์ฟเวอร์ที่มีการดึง image ขนาดใหญ่หลายเวอร์ชัน มักจะเป็นวิธีที่ช่วยเพิ่มพื้นที่ได้มากที่สุด builder prune จะล้าง build cache ซึ่งมักจะเพิ่มขนาดขึ้นเรื่อยๆ บนเซิร์ฟเวอร์ที่มีการ build image เอง

คำสั่งเหล่านี้จะไม่ส่งผลกระทบต่อ named volume โดยจะมีเพียง docker volume prune และ docker compose down -v เท่านั้นที่จัดการกับส่วนนี้

การตรวจสอบไฟล์ก่อนที่จะเกิดความเสียหาย

docker compose config --quiet
docker compose config --services
docker compose --dry-run up -d

config --quiet จะทำการตรวจสอบและไม่แสดงผลลัพธ์ใดๆ หากสำเร็จ ดังนั้นจึงควรใช้ในขั้นตอนก่อนการ deploy หรือใช้เป็น git hook ส่วน config จะแสดงผลไฟล์ที่รวมและแทนที่ตัวแปรทั้งหมดแล้ว ซึ่งเป็นวิธีที่คุณใช้ยืนยันว่าตัวแปรถูกแทนที่ค่าและไฟล์ override ถูกซ้อนทับตามที่คาดหวังไว้ หากตัวแปรใดไม่ได้ถูกกำหนดค่าไว้ จะปรากฏเป็นค่าว่างในส่วนนี้ พร้อมกับคำเตือน The "X" variable is not set. Defaulting to a blank string.

--dry-run เป็น global flag ไม่ใช่ subcommand flag ดังนั้นจึงต้องวางไว้หน้า up โดยคำสั่งนี้จะแสดงทุกการกระทำที่ Compose จะดำเนินการโดยไม่มีการเปลี่ยนแปลงใดๆ เกิดขึ้นจริง ซึ่งเป็นการใช้เวลา 30 วินาทีที่คุ้มค่าก่อนที่จะรัน down บน stack ที่มีความสำคัญ

การทำงานข้ามไฟล์ โปรไฟล์ และโปรเจกต์

docker compose -f compose.yaml -f compose.prod.yaml up -d
docker compose --profile debug up -d
docker compose -p staging up -d

การใช้ flag -f หลายรายการจะถูกรวมเข้าด้วยกันตามลำดับ โดยไฟล์ที่ระบุภายหลังจะเขียนทับค่าในไฟล์ก่อนหน้าแบบคีย์ต่อคีย์ นี่เป็นวิธีมาตรฐานในการเก็บไฟล์ฐานไว้หนึ่งไฟล์และใช้ไฟล์ override ขนาดเล็กสำหรับ production อย่างไรก็ตาม กฎการรวมข้อมูลสำหรับรายการ (list) และแผนผัง (map) นั้นแตกต่างกัน โปรดอ่าน วิธีการที่ Compose รวมไฟล์หลายไฟล์ ก่อนที่คุณจะเริ่มแก้ไขปัญหาที่คาดไม่ถึง

--profile จะเริ่มบริการที่ถูกแท็กด้วยโปรไฟล์นั้นควบคู่ไปกับบริการที่ไม่ได้แท็ก ซึ่งช่วยแยกเครื่องมือสำหรับ debug ออกจาก up ปกติ -p ใช้สำหรับกำหนดชื่อโปรเจกต์ เพื่อให้สามารถรัน stack ชุดเดียวกันสองชุดควบคู่กันไปได้โดยใช้เครือข่ายและชื่อ volume ที่แยกจากกัน การทำให้ stack กลับมาทำงานหลังการรีบูตไม่ใช่คำสั่งที่คุณต้องพิมพ์เอง แต่เป็น unit ที่ทำงานให้คุณโดยอัตโนมัติ ซึ่งอธิบายไว้ใน การเริ่ม Compose stacks ตอนบูตเครื่อง

FAQ

อะไรมาแทนที่ docker-compose ที่มีเครื่องหมายยัติภังค์?

Compose V2 ซึ่งเรียกใช้งานด้วย docker compose โดยเว้นวรรค มันเป็นปลั๊กอินที่รวมมากับ Docker Engine และเครื่องมือ Python เวอร์ชัน V1 จะไม่ถูกติดตั้งมากับแพ็กเกจปัจจุบันอีกต่อไป หากการเรียกใช้งานแบบเว้นวรรคไม่แสดงผลลัพธ์ใดๆ ให้ติดตั้งแพ็กเกจ docker-compose-plugin สำหรับดิสทริบิวชันของคุณ ควรปรับปรุงสคริปต์เก่าให้ใช้รูปแบบการเว้นวรรคแทนการสร้าง alias เพราะ V2 มีแฟล็กที่ V1 ไม่มี

ทำไม docker compose restart ถึงไม่รับการเปลี่ยนแปลงค่าคอนฟิกของฉัน?

restart จะหยุดและเริ่มคอนเทนเนอร์เดิมที่มีอยู่ด้วยการตั้งค่าที่ใช้สร้างขึ้นมาตั้งแต่แรก และมันจะไม่โหลด compose.yaml ซ้ำ การเปลี่ยนแปลงใดๆ ต่อ environment variable, พอร์ต, volume หรือ image tag จำเป็นต้องใช้ docker compose up -d ซึ่งจะเปรียบเทียบแต่ละบริการกับคอนเทนเนอร์ที่กำลังทำงานอยู่และสร้างใหม่เฉพาะส่วนที่แตกต่างกัน ให้เพิ่ม --force-recreate เมื่อคุณต้องการให้เกิดการแทนที่แม้ว่าจะไม่มีสิ่งใดในไฟล์เปลี่ยนแปลงก็ตาม

ฉันจะอัปเดตบริการให้เป็น image เวอร์ชันใหม่ได้อย่างไร?

ให้รัน docker compose pull ตามด้วย docker compose up -d คำสั่ง pull จะดึง image ปัจจุบันสำหรับแต่ละ tag ในไฟล์ และ up -d จะสร้างบริการใหม่หาก image ID ไม่ตรงกับคอนเทนเนอร์ที่ทำงานอยู่ การรัน up -d เพียงอย่างเดียวจะเป็นการใช้ image ที่มีอยู่บนดิสก์ซ้ำ ซึ่งเป็นเหตุผลว่าทำไม stack ที่ล็อกไว้กับ latest ถึงยังคงใช้ build ที่เก่าหลายเดือนโดยไม่แสดงข้อผิดพลาดใดๆ

คำสั่งล้างข้อมูลใดบ้างที่ปลอดภัยบนเซิร์ฟเวอร์ที่ใช้งานจริง?

docker system df, docker image prune -a และ docker builder prune จะลบเฉพาะ image และแคชเท่านั้น ดังนั้นบริการที่กำลังทำงานอยู่จะยังคงทำงานต่อไปและ named volume จะไม่ได้รับผลกระทบ คู่คำสั่งที่อันตรายคือ docker compose down -v และ docker volume prune ซึ่งจะลบ named volume โดยไม่มีการแจ้งเตือน ให้รัน docker compose config --volumes ก่อนเพื่อให้คุณทราบว่ามีข้อมูลใดที่เสี่ยงต่อการสูญหาย

ฉันสามารถรันคำสั่งเดียวโดยไม่ต้องเริ่มทั้ง stack ได้หรือไม่?

ได้ docker compose run --rm --no-deps web sh จะเริ่มคอนเทนเนอร์เดี่ยวจากนิยามบริการ web โดยข้าม dependency ของมันและลบคอนเทนเนอร์ทิ้งเมื่อคุณออกจากโปรแกรม ให้ใช้ exec แทนเมื่อคอนเทนเนอร์กำลังทำงานอยู่แล้ว เพราะ exec จะเชื่อมต่อเข้ากับโพรเซสที่กำลังทำงานอยู่และแสดงสถานะที่แท้จริงของบริการนั้นให้คุณเห็น