Status Sistem Docker: Pemadaman Seluruh Layanan

 (dockerstatus.com)
2 poin oleh GN⁺ 2025-10-22 | 1 komentar | Bagikan ke WhatsApp
  • Terjadi gangguan luas pada layanan utama Docker
  • Akar masalah teridentifikasi terkait penyedia layanan cloud
  • Seluruh layanan SaaS memperlihatkan tingkat error
  • Pemulihan berlanjut ke tahap penanganan backlog dan pemantauan
  • Akhirnya dinyatakan terselesaikan dan pemulihan layanan diumumkan

Gambaran Umum Gangguan Sistem 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, dan layanan Docker lainnya mengalami masalah akses dan penggunaan yang luas.

20 Oktober 2025 00:16 PDT / 07:16 UTC

[Sedang Diselidiki]
Penyelidikan dimulai setelah terjadinya masalah akses dan penggunaan yang luas di seluruh produk layanan.

20 Oktober 2025 01:22 PDT / 08:22 UTC

[Masalah Teridentifikasi]
Penyebab gangguan teridentifikasi sebagai isu terkait penyedia layanan cloud.
Persiapan sistem internal dan pemantauan dilakukan untuk menghadapi pemulihan dari penyedia layanan cloud.

20 Oktober 2025 02:43 PDT / 09:43 UTC

[Pemantauan]
Di seluruh layanan SaaS, tingkat error menunjukkan tren pemulihan secara bertahap.
Penanganan backlog dilakukan bersama pemantauan status yang berkelanjutan.

20 Oktober 2025 03:05 PDT / 10:05 UTC

[Selesai]
Gangguan ini secara resmi diselesaikan.
Status normalisasi seluruh layanan sudah diverifikasi.

Bacaan terkait

1 komentar

 
GN⁺ 2025-10-22
Komentar Hacker News
  • Halo, saya Tushar dari Docker. Mohon maaf atas gangguan layanan Docker yang terjadi karena isu AWS saat ini. Tim kami bekerja sama dengan AWS untuk memulihkan layanan secepat mungkin. Kami terus memperbarui statusnya di dockerstatus.com. Kami sadar Docker Hub dan layanan kami sangat penting bagi jutaan pengembang di seluruh dunia. Kami akan berusaha yang terbaik untuk pemulihan cepat. Setelah insiden ini terselesaikan sepenuhnya, kami akan merilis postmortem lengkap beserta rencana tindak lanjut.
    • Saya merasa menarik jika penyebab runtuhan beruntun ini ternyata DynamoDB, bila ternyata memang di-host sebagai image Docker di Docker Hub.
  • Ini adalah dampak dari insiden AWS tautan referensi
    • Mereka bilang “satu penyedia layanan cloud menemukan masalah fundamental,” padahal kan kebanyakan orang sekarang pakai beberapa penyedia cloud sekaligus? Kenapa dampaknya bisa sebesar ini oleh satu penyedia?
  • Kami juga bergantung pada beberapa image Docker publik. Pada dasarnya build rusak karena Docker memakai docker.io. Untungnya AWS menyediakan mirror untuk docker.io, jadi setelah mengubah ke
    FROM public.ecr.aws/docker/library/{image_name}
    semua build jadi normal lagi. Di log error, sebagian besar dari endpoint autentikasi (https://auth.docker.io) adalah
    “Tidak ada server yang dapat menangani permintaan.” Setelah beralih ke mirror AWS, build berhasil tanpa kendala.
    • Docker down karena insiden AWS, tetapi penyimpanan mirror AWS tetap jalan normal. Agak ironi.
    • docker.io juga menetapkan rate limit, jadi ketika organisasi tumbuh ke titik tertentu, build failure mulai sering terjadi. Selain itu, layanan hosting image lain, quay.io (milik Red Hat), juga read-only seharian ini. Kalau bergantung pada image kontainer, sebaiknya punya solusi hosting sendiri daripada terus naik bus orang lain.
    • public.ecr.aws juga menampilkan error 5XX hari ini karena insiden AWS, jadi untuk saya juga gagal tautan referensi
    • Cara ini tidak berhasil untuk saya, tetapi mirror Google (mirror.gcr.io) bekerja dengan baik. Cukup ubah dari
      FROM {image_name}
      menjadi
      FROM mirror.gcr.io/{image_name}. Mudah-mudahan membantu. panduan terkait
    • Kami mengelola sistem build skala besar, dan pull image dari ECR tidak stabil sepanjang hari ini.
  • Menjalankan registry sendiri seperti Nexus dan membangun container image langsung untuk base image bersama, hari ini mereka jelas merasa keputusannya terasa masuk akal. Saya penasaran berapa banyak build atau redeploy yang terganggu oleh insiden seperti ini. Saya tidak punya kebencian terhadap Docker maupun Docker Hub, dan saya memanfaatkannya dengan baik.
    • Menempatkan cache image Docker di perantara itu kebiasaan penting. Jika docker tiba-tiba menurunkan upstream image, ketika node K8s diganti Anda bisa tidak menemukan base image sehingga layanan sulit dijalankan. Bagiku ini soal hygiene engineering.
    • Kami juga memakai base image, tetapi GitHub Actions mengambil image docker di tahap persiapan, jadi meski build aplikasi berhasil, deployment tidak dapat berjalan. CI/CD kami tergantung pada dockerhub, dan beberapa image tidak bisa dialihkan jalurnya via pull-through cache, sehingga begini keadaannya.
    • Kami menjalankan Harbor dan memirror semua base image melalui Proxy Cache, dan kami sudah menjalankan konfigurasi ini selama bertahun-tahun. Harbor memang punya beberapa kekurangan, tetapi secara keseluruhan cukup memuaskan.
    • Lebih lega karena sama sekali tidak memakai container itu sendiri.
    • Tanpa workaround manual, kami tidak bisa melakukan pekerjaan baru di lingkungan dev maupun prod. Saya rasa dampaknya cukup besar. Sepertinya Signal juga terkena isu hari ini.
  • Lebih menarik dari kabar insiden AWS, insiden ini lebih menonjol di halaman utama HN.
  • Meskipun ini seperti iklan yang memalukan, saya merekomendasikan menginstal Spegel di Kubernetes cluster bila ketergantungan ke Docker Hub tinggi.
    • Kalau memang open source penuh, akan lebih baik jika ditampilkan lebih jelas di landing page-nya. Kalau bisa langsung dipasang dan dicoba, bedanya besar sekali untuk engineer karena tidak perlu melewati proses pembelian.
    • Saya penasaran perbedaannya dengan kuik. Spegel agak berlebihan untuk homelab saya, tetapi bisa menjadi upgrade bagus untuk lingkungan kantor. Kuik: referensi
    • Ada alternatif lain yang memirror lebih banyak repositori selain Docker Hub. Kebanyakan terasa “enterprise-yet,” tapi tetap jalan sesuai fitur yang dijelaskan. Artifactory, Nexus Repository, Cloudsmith, dan ProGet termasuk di antaranya. Berkat mereka, kami sudah beberapa kali lolos dari krisis.
    • Spegel terlihat bagus, tetapi kami menggunakan GKE sehingga saat ini baru berfungsi sebagai workaround. Ingin tahu apakah nanti akan benar-benar didukung di GKE.
  • Ini semacam desain yang disengaja.
    docker menolak permintaan fitur konfigurasi private registry, demi kepentingan dirinya sendiri.
    stackoverflow terkait
    Red Hat membuat podman yang kompatibel dengan Docker sehingga bagian ini bisa ditutup.
    /etc/config/docker:
    BLOCK_REGISTRY='--block-registry=all'
    ADD_REGISTRY='--add-registry=registry.access.redhat.com'
    • Saya rasa ini terlalu berlebihan. Walau bisa mengganti registry default dari docker.io ke tempat lain, saya kira kebanyakan orang akan malas melakukannya. Sebenarnya cukup memberi tag image dengan benar. Di perusahaan kami, tidak ada sekali image yang dipull dari docker.io. Cukup tambahkan <company-repo>/ di awal nama image, butuh 2 detik.
    • Saya pikir 'footgun' seperti ini masih bisa ditoleransi. Manfaat adanya tag image yang menyertakan domain menurut saya lebih besar daripada salah paham yang ditimbulkan. Misalnya, kalau di dokumentasi tim ada perintah dan konfigurasi docker sudah usang, orang bisa saja salah pull dari registry publik global. Secara pribadi saya rasa lebih baik menghapus registry global itu agar jelas dari mana aslinya image diambil (walau saya tidak yakin Docker akan memikirkan ini secara serius).
    • Kalau ECR pernah dipakai sebagai private registry di region us-east-1, cara ini tidak berguna.
  • Docker tidak bisa dibuka sehingga saya bahkan tidak bisa login ke O'Reilly; jadi sempat terpikir, “kalau Docker down ya belajar yang lain,” dan saya penasaran apakah ini penyebabnya.
    • Instal pull-through proxy yang menyimpan semua paket yang baru-baru ini dipakai.
  • Bagi yang menghadapi masalah serupa, cara yang membantu adalah pakai ghcr. Tidak sepenuhnya menggantikan semuanya, tetapi
    contoh: docker pull ghcr.io/linuxcontainers/debian-slim:latest
    • Image ini sudah tidak diupdate lebih dari setahun tautan terkait. Google Container Registry menyediakan pull-through mirror, jadi cukup tambahkan prefix mirror.gcr.io, dan untuk Docker Official Images, gunakan library sebagai namespace, misalnya mirror.gcr.io/library/redis halaman resmi redis
  • Pada 20 Oktober 2025 pukul 09:43 UTC, pemulihan sedang berlangsung secara bertahap. Error rate pada layanan SaaS secara umum terlihat menurun. Kami sedang memproses backlog sambil terus memantau situasi.