Tình trạng hệ thống Docker: gián đoạn toàn bộ dịch vụ

• Các dịch vụ chủ chốt của Docker xảy ra sự cố rộng rãi
• Nguyên nhân được xác định là do vấn đề liên quan tới nhà cung cấp dịch vụ đám mây
• Tỷ lệ lỗi được quan sát trên toàn bộ dịch vụ SaaS
• Đang tiến hành khôi phục lỗi, bước xử lý backlog và giám sát đã bắt đầu
• Cuối cùng vấn đề đã được giải quyết và xác nhận đã phục hồi bình thường

---

Tổng quan sự cố hệ thống 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, cùng nhiều dịch vụ khác của Docker đã gặp sự cố truy cập và sử dụng rộng rãi

20 tháng 10 năm 2025 00:16 PDT / 07:16 UTC

[Đang điều tra]
Đã bắt đầu điều tra nguyên nhân do sự cố kết nối và sử dụng trên diện rộng tại nhiều sản phẩm dịch vụ

20 tháng 10 năm 2025 01:22 PDT / 08:22 UTC

[Nhận diện sự cố]
Nguyên nhân sự cố đã được xác định là do vấn đề từ nhà cung cấp dịch vụ đám mây
Chuẩn bị hệ thống nội bộ và giám sát trong lúc chờ nhà cung cấp dịch vụ khắc phục

20 tháng 10 năm 2025 02:43 PDT / 09:43 UTC

[Giám sát]
Đã xác nhận tỷ lệ lỗi trên toàn bộ dịch vụ SaaS đang có xu hướng phục hồi dần
Xử lý backlog và giám sát trạng thái tiếp tục được tiến hành liên tục

20 tháng 10 năm 2025 03:05 PDT / 10:05 UTC

[Đã giải quyết]
Sự cố này đã được giải quyết chính thức
Đã xác nhận toàn bộ dịch vụ trở lại trạng thái hoạt động bình thường

[GN⁺]

Bình luận Hacker News

• Chào mọi người, đây là Tushar của Docker. Chúng tôi xin lỗi về sự gián đoạn dịch vụ Docker do vấn đề với AWS hiện tại. Đội của chúng tôi đang phối hợp với AWS để khôi phục dịch vụ nhanh nhất có thể. Chúng tôi đang cập nhật liên tục trên dockerstatus.com. Chúng tôi hiểu Docker Hub và dịch vụ này quan trọng đến đâu với hàng triệu nhà phát triển trên toàn cầu, và chúng tôi sẽ làm mọi thứ để khôi phục sớm nhất có thể. Sau khi sự cố này được giải quyết hoàn toàn, chúng tôi sẽ đăng một bài postmortem chi tiết cùng với kế hoạch phản hồi trong tương lai.
  • Mình tự hỏi việc gây nên sự cố dây chuyền lần này là DynamoDB có đang được Docker Hub host như image Docker thì thật thú vị.
• Đây là hậu quả của sự cố AWS. Liên kết tham khảo
  • Họ nói 'phát hiện ra một vấn đề cốt lõi ở một trong các nhà cung cấp dịch vụ đám mây', nhưng ngày nay chẳng ai vẫn chỉ dùng một nhà cung cấp cloud đâu? Mình thắc mắc vì sao một nhà cung cấp lỗi lại tác động lớn như vậy.
• Chúng tôi cũng phụ thuộc vào nhiều public Docker image, và mặc định Docker dùng docker.io nên build bị hỏng. May mắn là AWS có dịch vụ mirror cho docker.io, và khi chuyển thành
  FROM public.ecr.aws/docker/library/{image_name}
  thì mọi thứ đều build bình thường. Trong log lỗi, phần lớn là lỗi từ endpoint xác thực (https://auth.docker.io) với nội dung
  "No server is available to handle this request". Sau khi chuyển sang mirror của AWS, build thành công mọi thứ.
  • Docker bị sập vì sự cố AWS nhưng kho mirror của AWS vẫn chạy, khá mỉa mai.
  • docker.io cũng bị áp rate limit, nên khi tổ chức lớn dần thì build thất bại bắt đầu xảy ra thường xuyên. Ngoài ra, dịch vụ hosting image quay.io (thuộc sở hữu của Red Hat) cũng ở trạng thái read-only trong cả ngày hôm nay. Nếu bạn phụ thuộc vào image container, tốt hơn là xây một giải pháp hosting đúng đắn thay vì đơn giản là leo lên người khác.
  • public.ecr.aws hôm nay cũng báo lỗi 5XX do sự cố AWS nên với mình thì vẫn thất bại. Liên kết tham khảo
  • Cách này với mình không ổn nhưng dùng mirror của Google (mirror.gcr.io) lại chạy tốt.
    FROM {image_name}
    từ
    FROM mirror.gcr.io/{image_name}
    chỉ cần vậy là xong. Hy vọng hữu ích. Hướng dẫn liên quan
  • Mình quản lý một hệ thống build quy mô lớn và việc pull image từ ECR đã bất ổn suốt cả ngày.
• Khi vận hành registry nội bộ như Nexus, những người build container image trực tiếp cho common base image chắc chắn hôm nay sẽ thấy yên tâm về lựa chọn của họ. Mình tò mò xem sự cố này làm hỏng bao nhiêu lần build hay redeploy. Mình không hề có ấn tượng xấu với Docker hay Docker Hub, mình vẫn dùng chúng rất hiệu quả.
  • Đặt cache image Docker ở giữa là một thói quen cực kỳ quan trọng. Khi docker đột ngột ngừng upstream image, khi thay thế node K8s sẽ không tìm được base image nên khó chạy dịch vụ. Mình coi đó là một chuyện của sự gọn gàng trong kỹ thuật.
  • Chúng tôi cũng dùng base image, nhưng GitHub Actions có bước kéo docker image trong giai đoạn chuẩn bị, vì vậy ứng dụng build được nhưng deploy thì không chạy được. CI/CD phụ thuộc vào dockerhub, và có một số image không thể đổi đường dẫn qua pull-through cache nên mới rơi vào thế này.
  • Chúng tôi vận hành Harbor và mirror tất cả base image bằng Proxy Cache, và cấu hình này đã chạy ổn mấy năm nay. Harbor có vài nhược điểm, nhưng nhìn chung vẫn khá hài lòng.
  • Có cảm giác yên tâm hơn khi hoàn toàn không dùng container.
  • Không thể làm việc mới ở môi trường dev hay prod mà không có workaround thủ công. Mình nghĩ tác động khá lớn. Theo dõi thì Signal cũng có vẻ gặp vấn đề hôm nay.
• So với tin sự cố AWS, việc sự cố này lên trang chính HN khiến mình thấy khá thú vị.
  • Không phải là trang main secret đâu nhé! trang active
• Dù hơi ngại vì giống quảng cáo, nhưng nếu phụ thuộc nhiều vào Docker Hub thì khuyên cài Spegel vào Kubernetes cluster.
  • Nếu thực sự là open source hoàn toàn thì nên ghi rõ hơn trên landing page. Nếu có thể cài đặt và thử ngay, đó sẽ là khác biệt rất lớn cho kỹ sư vì không cần đi qua quy trình mua.
  • Mình muốn biết khác biệt giữa nó và kuik. Spegel có vẻ hơi quá đáng cho home lab của mình, nhưng trong môi trường công ty có thể là một bản nâng cấp tốt. Kuik: xem thêm
  • Ngoài Docker Hub, còn có nhiều phương án mirror thêm nhiều repo hơn. Phần lớn mang tính enterprise và có phần gây bực bội, nhưng phần lớn hoạt động đúng theo tính năng đã nói. Artifactory, Nexus Repository, Cloudsmith, ProGet... Có những công cụ này, chúng tôi đã thoát khỏi nhiều cuộc khủng hoảng.
  • Spegel trông ổn, nhưng vì chúng tôi dùng GKE nên hiện tại nó chỉ hoạt động như một giải pháp tạm thời. Mình tò mò GKE có dự định hỗ trợ đúng chuẩn không.
• Đây là một kiểu thiết kế cố ý.
  docker từng bị yêu cầu bật cấu hình private registry cho chính nó nhưng đã từ chối vì lợi ích của chính nó.
  Stack Overflow liên quan
  Red Hat tạo ra podman tương thích docker để khóa phần này
  /etc/config/docker:
  BLOCK_REGISTRY='--block-registry=all'
  ADD_REGISTRY='--add-registry=registry.access.redhat.com'
  • Mình thấy đây là một chút suy diễn quá xa. Dù có thể đổi registry mặc định từ docker.io sang nơi khác, mình nghĩ phần lớn mọi người sẽ không làm vì phiền. Thực chất chỉ cần tag image chuẩn thôi. Ở công ty mình không có image nào pull từ docker.io; chỉ mất 2 giây để thêm <company-repo>/ vào trước tên image.
  • Mình nghĩ có thể chấp nhận một mức độ 'footgun' này. Cảm giác lợi ích của khả năng biểu đạt của tag image có domain lớn hơn những hiểu lầm do nó tạo ra. Ví dụ, trong tài liệu đội có ghi lệnh mà cấu hình docker đã cũ thì có thể vô tình pull từ registry public toàn cầu. Cá nhân mình nghĩ tốt hơn là bỏ hẳn global registry và để rõ ràng nguồn lấy là gì (dù chắc Docker sẽ không nghĩ sâu về việc này).
  • Với trường hợp dùng ECR ở us-east-1 làm private registry thì cách này không áp dụng được.
• Vì Docker đang down nên không đăng nhập được O'Reilly, nên tự hỏi liệu ý định "nếu Docker down thì học thứ khác" có phải do sự cố này không.
  • Cách tốt là cài pull-through proxy lưu trữ tất cả package đã dùng gần đây.
• Cách giúp ích cho những người khác gặp vấn đề tương tự là dùng ghcr. Không phải thay thế hoàn toàn, nhưng...
  Ví dụ: docker pull ghcr.io/linuxcontainers/debian-slim:latest
  • Image này chưa được cập nhật hơn một năm rồi. Liên kết liên quan. Vì Google Container Registry có cung cấp pull-through mirror, bạn chỉ cần thêm mirror.gcr.io làm prefix, và với Docker Official Images thì dùng library như tên user, ví dụ mirror.gcr.io/library/redis. trang chính thức redis
• Tính đến 09:43 UTC ngày 20-10-2025, đang dần khôi phục. Tỷ lệ lỗi của các dịch vụ SaaS nói chung đang giảm xuống. Chúng tôi đang xử lý backlog và tiếp tục theo dõi tình hình.