สถานะระบบ Docker: การหยุดทำงานของบริการทั้งหมด

• เกิดเหตุขัดข้องอย่างกว้างขวางในบริการหลักของ Docker
• สาเหตุของปัญหา เกี่ยวข้องกับผู้ให้บริการคลาวด์
• สังเกตพบอัตราข้อผิดพลาดใน บริการ SaaS โดยรวม
• มีการเริ่มขั้นตอน จัดการงานค้างและการตรวจสอบระบบ หลังจากเริ่มการแก้ไขข้อผิดพลาด
• ในที่สุด มีการแก้ไขปัญหาแล้ว และประกาศการกลับสู่สภาพปกติ

---

ภาพรวมเหตุขัดข้องของระบบ Docker

เกิดปัญหาการเข้าถึงและการใช้งานอย่างกว้างขวางในบริการต่าง ๆ ของ Docker ได้แก่ Docker Hub Registry, Docker Authentication, Docker Hub Web Services, Docker Billing, Docker Hub Automated Builds, Docker Hub Security Scanning, Docker Scout, Docker Build Cloud, Testcontainers Cloud, Docker Cloud, Docker Hardened Images

20 ตุลาคม 2025 เวลา 00:16 PDT / 07:16 UTC

[กำลังตรวจสอบ]
เริ่มการสืบสวนสาเหตุเนื่องจากเกิดปัญหาการเข้าถึงและการใช้งานข้ามบริการจำนวนมาก

20 ตุลาคม 2025 เวลา 01:22 PDT / 08:22 UTC

[ระบุปัญหา]
สาเหตุของเหตุขัดข้องถูกระบุว่าเป็นปัญหาจากผู้ให้บริการคลาวด์
เริ่มเตรียมระบบภายในและติดตามสถานะเพื่อรับมือกับการแก้ไขปัญหาของผู้ให้บริการ

20 ตุลาคม 2025 เวลา 02:43 PDT / 09:43 UTC

[การติดตาม]
สังเกตแนวโน้มการลดลงอย่างต่อเนื่องของอัตราข้อผิดพลาดทั่วทั้งบริการ SaaS
ดำเนินการจัดการงานค้างควบคู่กับการตรวจสอบสถานะอย่างต่อเนื่อง

20 ตุลาคม 2025 เวลา 03:05 PDT / 10:05 UTC

[แก้ไขแล้ว]
เหตุขัดข้องนี้ได้รับการแก้ไขอย่างเป็นทางการ
ยืนยันว่าบริการทั้งหมดกลับสู่สภาวะปกติ

[GN⁺]

ความคิดเห็นจาก Hacker News

• สวัสดีครับ ผมคือ Tushar จาก Docker ผมขออภัยในเหตุการณ์หยุดให้บริการของ Docker ที่เกิดจากปัญหา AWS ในขณะนี้ ทีมงานของเรากำลังร่วมมือกับ AWS เพื่อกู้คืนบริการให้เร็วที่สุด โดยมีการอัปเดตสถานะอย่างต่อเนื่องที่ dockerstatus.com เราตระหนักดีว่า Docker Hub และบริการนี้สำคัญต่อผู้พัฒนาทั่วโลกนับล้านคน เราจะพยายามอย่างสุดความสามารถเพื่อให้กลับมาใช้งานได้โดยเร็ว หลังจากเหตุการณ์นี้คลี่คลายสมบูรณ์แล้ว เราจะแชร์โพสต์มอร์เท็มพร้อมแนวทางรับมือครั้งหน้าอย่างละเอียด
  • ผมคิดไม่ออกไปแล้วว่าถ้า DynamoDB ที่เป็นต้นเหตุการล่มต่อเนื่องนี้ถูกโฮสต์ไว้ในรูปแบบ Docker image บน Docker Hub มันน่าจะเป็นกิ๊กที่น่าสนใจมาก
• สาเหตุเกิดจากเหตุการณ์ AWS ลิงก์อ้างอิง
  • เขาบอกว่า "พบปัญหาหลักที่ผู้ให้บริการคลาวด์รายหนึ่ง" แต่ในยุคนี้หลายองค์กรก็ใช้หลายผู้ให้บริการพร้อมกันแล้ว ทำไมการล่มของรายเดียวถึงกระทบได้ขนาดนี้?
• เรายังพึ่งพา public Docker image หลายตัวอยู่ โดยปกติแล้ว Docker ใช้ docker.io เป็นค่าเริ่มต้น จึงทำให้ build ผิดพลาด โชคดีที่ AWS มีบริการ mirror ของ docker.io ให้ จึงเปลี่ยนเป็น FROM public.ecr.aws/docker/library/{image_name} และทุกอย่าง build ผ่านหมด ในบันทึกข้อผิดพลาดพบปัญหาส่วนใหญ่ที่ endpoint การยืนยันตัวตน (https://auth.docker.io) "ไม่มีเซิร์ฟเวอร์ที่สามารถประมวลผลคำขอได้" หลังจากสลับไปใช้ AWS mirror แล้ว build สำเร็จโดยไม่มีปัญหา
  • Docker ล่มเพราะปัญหา AWS แต่ที่เก็บ mirror ของ AWS กลับยังทำงานได้ ดูค่อนข้างย้อนแย้ง
  • docker.io ยังมี rate limit ด้วย เมื่อองค์กรขยายตัวขึ้นก็เริ่มเจอ build fail บ่อยขึ้น ซึ่ง quay.io (เป็นของ Red Hat) ก็อยู่ในโหมด read-only ตลอดทั้งวันเช่นกัน ถ้ามี dependency คอนเทนเนอร์ image ควรจัดการโซลูชันโฮสต์ที่เหมาะสมเองแทนการไปพึ่งพาเวอร์ชันของใครตลอดเวลา
  • public.ecr.aws ก็มีกดขึ้น error 5XX จากเหตุการณ์ AWS วันนี้ ทำให้เกิดความล้มเหลวในระบบผมเช่นกัน ลิงก์อ้างอิง
  • วิธีนี้ใช้งานกับผมไม่ค่อยได้ผล แต่การใช้ mirror ของ Google (mirror.gcr.io) ใช้ได้ดี เปลี่ยนจาก FROM {image_name} เป็น FROM mirror.gcr.io/{image_name} ก็พอ หวังว่าจะช่วยได้ คู่มือที่เกี่ยวข้อง
  • ผมดูแลระบบ build ขนาดใหญ่ และพบว่าการ pull image จาก ECR วันนั้นไม่เสถียรตลอดทั้งวัน
• คนที่รัน Nexus หรือ registry ส่วนตัวเอง และ build container image โดยตรงจาก base image ร่วมกัน คงรู้สึกสบายใจขึ้นในเหตุการณ์แบบนี้นะ คิดว่าความล่มครั้งนี้จะทำลาย build หรือการ re-deploy จำนวนมากแค่ไหน แต่ผมไม่ค่อยมีความรู้สึกลบต่อ Docker หรือ Docker Hub และยังใช้งานได้คุ้มค่าอยู่
  • การมี docker image cache เป็นชั้นกลางเป็นพฤติกรรมที่สำคัญมาก ถ้า docker ดึง upstream image ออกไปกะทันหัน เมื่อโหนด K8s ถูกแทนที่อาจหา base image ไม่เจอจนรันบริการไม่ออก ผมมองว่าเป็นเรื่องความสะอาดเชิงวิศวกรรม
  • เรายังใช้ base image เช่นกัน แต่ใน GitHub Actions มีขั้นตอนเอา docker image เข้ามาก่อนในช่วงเตรียมงาน ทำให้ build แอปเสร็จแต่ deploy ไม่ได้ เพราะ CI/CD พึ่งพา dockerhub และบาง image ไม่สามารถเปลี่ยนเส้นทางผ่าน pull-through cache ได้ จึงเกิดเรื่องนี้
  • เราดำเนินการ Harbor และ mirror base image ทั้งหมดผ่าน Proxy Cache มาหลายปีมาแล้ว แม้ Harbor จะมีจุดด้อยเล็กน้อย แต่โดยรวมแล้วพอใจมาก
  • รู้สึกอุ่นใจมากขึ้นเพราะไม่ได้ใช้ container โดยตรงเลย
  • สถานการณ์ที่ทำงานใหม่ใน dev หรือ prod ไม่ได้เลยหากไม่ทำ workaround มือ ถือว่าเป็นผลกระทบค่อนข้างสูง เชื่อว่า Signal ก็เจอปัญหาอยู่วันนี้เหมือนกัน
• น่าสนใจว่าปัญหานี้ขึ้นหน้า HN main มากกว่าเรื่อง outage ของ AWS
  • ไม่ได้ขึ้นที่หน้า secret main เลยนะ! หน้า active
• ถือว่าโฆษณาเชิงเขินๆ แต่ถ้าพึ่งพา Docker Hub มาก แนะนำติดตั้ง Spegel ใน Kubernetes cluster
  • ถ้ามันเป็นโอเพ่นซอร์สจริงๆ ก็ควรแสดงให้ชัดเจนบนหน้า landing page มากขึ้น เพราะการติดตั้งและลองใช้ได้ทันทีต่างกันมากสำหรับวิศวกรเลย เพราะไม่ต้องผ่านขั้นตอนซื้อของซับซ้อน
  • อยากรู้ว่ามันต่างจาก kuik อย่างไร Spegel อาจค่อนข้างเกินความจำเป็นใน home lab ของผม แต่ในสภาพแวดล้อมองค์กรอาจเป็น upgrade ที่ดีมาก Kuik: อ้างอิง
  • ยังมีทางเลือกอื่นเพื่อ mirror repository จำนวนมากนอกเหนือ Docker Hub แม้หลายตัวอาจให้ความรู้สึกแบบ enterprise-heavy แต่ทำงานตามฟีเจอร์ที่ประกาศไว้ได้ดี Artifactory, Nexus Repository, Cloudsmith และ ProGet เป็นตัวอย่าง พวกนั้นช่วยให้หลายทีมรอดจากวิกฤตซ้ำๆ มาหลายรอบ
  • Spegel ดูน่าสนับสนุน แต่ตอนนี้เราใช้ GKE จึงใช้งานได้แบบ workaround เท่านั้น อยากดูว่ามันจะได้รับการ support อย่างเป็นทางการบน GKE หรือไม่
• นี่เป็นการออกแบบแบบเจตนาสำหรับบางเรื่อง docker เคยรับคำขอการตั้ง private registry แต่มองว่าไม่เหมาะสมกับตัวเอง Stack Overflow ที่เกี่ยวข้อง Red Hat จึงสร้าง podman ที่เข้ากันได้กับ docker เพื่อเติมเต็มจุดนี้ /etc/config/docker: BLOCK_REGISTRY='--block-registry=all' ADD_REGISTRY='--add-registry=registry.access.redhat.com'
  • ผมคิดว่ามุมมองนี้ค่อนข้างกระโดดมาก การที่เปลี่ยน default registry จาก docker.io ไปยังที่อื่นได้ ก็เท่ากับคนส่วนใหญ่ไม่น่าจะทำเพราะมันยุ่งยาก ผมเชื่อว่าใส่ tag ให้ image ให้ดีเท่านั้นก็พอ ที่บริษัทเรามีการ pull image จาก docker.io ไม่เคยทำเลย แค่เพิ่ม <company-repo>/ หน้าชื่อ image แค่นั้น 2 วินาที
  • ผมคิดว่าแนวคิด 'footgun' นี้ยอมรับได้ระดับหนึ่ง ข้อดีจากการมี domain ใน image tag มักมากกว่าความเข้าใจผิดที่เกิดขึ้น เช่น ถ้าเอกสารทีมมีคำสั่งอยู่และการตั้งค่า Docker ล้าสมัยก็อาจ pull จาก global public registry ผิดพลาดได้ ส่วนตัวผมคิดว่าการเอา global registry ออกจากสแต็กและทำให้เห็นแหล่งที่มาชัดเจนจะดีกว่า (แต่คงไม่ใช่เรื่องที่ Docker ให้ความสำคัญมาก)
  • สำหรับกรณีที่เคยใช้ ECR เป็น private registry ใน us-east-1 แนวทางนี้ไม่ช่วย
• Docker ไม่ทำงาน จึงไม่สามารถล็อกอินเข้า O'Reilly ได้ เลยทำให้ผมคิดว่า "ถ้า Docker ล่มแล้วก็ไปเรียนอย่างอื่น" อาจมาจากเหตุการณ์นี้หรือไม่
  • ติดตั้ง pull-through proxy สำหรับแพ็กเกจที่ใช้ทั้งหมดล่าสุดก็ช่วยได้
• วิธีที่ช่วยคนอื่นที่เจอปัญหาคล้ายกันคือใช้ ghcr แม้ไม่ใช่ทางเลือกแทนแบบครบถ้วน เช่น ตัวอย่าง: docker pull ghcr.io/linuxcontainers/debian-slim:latest
  • Image นี้ไม่ได้อัปเดตมากว่า 1 ปีแล้ว ลิงก์อ้างอิง Google Container Registry มี pull-through mirror ให้ ดังนั้นแค่เติม mirror.gcr.io เป็น prefix และในกรณี Docker Official Images ก็ให้ใช้ library เป็น user เช่น mirror.gcr.io/library/redis ก็ได้ หน้า redis อย่างเป็นทางการ
• ตามข้อมูลเวลา 09:43 UTC วันที่ 20 ตุลาคม 2025 ระดับการกู้คืนกำลังค่อยเป็นค่อยไป ระดับ error rate ของบริการ SaaS โดยรวมกำลังลดลง มีการ monitor สถานการณ์ต่อเนื่องพร้อมเคลียร์ backlog