2 puan yazan GN⁺ 2025-10-22 | 1 yorum | WhatsApp'ta paylaş
  • Docker'ın ana hizmetlerinde geniş çaplı bir kesinti yaşandı
  • Sorun nedeni, bulut servis sağlayıcısı ile ilgili bir mesele olarak doğrulandı
  • Tüm SaaS hizmetlerinde hata oranı gözlemlendi
  • Hata giderimi ilerledi ve kuyrukta bekleyen işlerin işlenmesi ve izleme aşamasına geçildi
  • Sonuçta sorunun çözümü ve normalleşme ilan edildi

Docker sistem kesinti özeti

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 gibi Docker'ın çeşitli hizmetlerinde geniş kapsamlı erişim ve kullanım sorunları meydana geldi

2025 Ekim 20, 00:16 PDT / 07:16 UTC

[İnceleme sürüyor]
Birçok ürün hizmeti genelinde yaşanan erişim ve kullanım sorunu nedeniyle kök neden incelemesi başlatıldı

2025 Ekim 20, 01:22 PDT / 08:22 UTC

[Sorun belirlendi]
Bulut servis sağlayıcısının kaynaklı bir sorun nedeniyle arıza nedeni tespit edildi
Hizmet sağlayıcısı kesintisi çözülürken, kendi sistemimiz için hazırlık ve izleme çalışmaları yapıldı

2025 Ekim 20, 02:43 PDT / 09:43 UTC

[İzleme]
SaaS hizmetleri genelinde hata oranının kademeli olarak toparlandığı bir eğilim gözlendi
Backlog işleme ile birlikte sürekli durum izleme sürdürüldü

2025 Ekim 20, 03:05 PDT / 10:05 UTC

[Çözüldü]
Bu kesinti resmen çözüldü
Tüm hizmetlerin normale döndüğü doğrulandı

1 yorum

 
GN⁺ 2025-10-22
Hacker News Yorumları
  • Merhaba, ben Docker'dan Tushar. AWS kaynaklı Docker hizmet kesintisi nedeniyle özür dileriz. Ekibimiz, AWS ile işbirliği içinde hizmeti mümkün olan en kısa sürede geri getirmek için çalışıyor. Docker durumu dockerstatus.com'da sürekli güncelleniyor. Docker Hub'ın ve hizmetimizin dünya genelindeki milyonlarca geliştirici için ne kadar kritik olduğunu biliyoruz. En hızlı şekilde geri dönmek için elimizden geleni yapacağız. Bu olay tamamen çözüldükten sonra, sonraki adımlarla birlikte ayrıntılı bir postmortem paylaşmayı planlıyoruz
    • Benim için ilginç olanı, bu domino etkisinin kaynağı olarak Docker Hub'da bir Docker image formatında barındırılan DynamoDB'nin yer alması olurdu
  • AWS kesintisinin bir sonucu. referans bağlantısı
    • “Bir bulut hizmet sağlayıcısında kök bir problem bulundu” deniyor ama bugün çoğumuz birden fazla bulut sağlayıcı kullanmıyor mu? Tek bir sağlayıcının çökmesinden bu kadar etkilenmemiz nasıl oluyor?
  • Biz de birden fazla public Docker image'ına bağımlıyız. Docker'ın varsayılan olarak docker.io kullanması nedeniyle build'ler kırıldı. Neyse ki AWS bugün docker.io için bir mirror servisi sunduğu için, FROM public.ecr.aws/docker/library/{image_name} satırını FROM public.ecr.aws/docker/library/{image_name} olarak değiştirdiğimizde her şey yeniden doğru şekilde build oldu. Hata günlüklerinde çoğunlukla auth endpoint'inde (https://auth.docker.io) “İsteği işleyebilecek sunucu yok” hatası vardı. AWS mirror'una geçince sorunsuz build edildi
    • Docker AWS nedeniyle kapanmasına rağmen AWS mirror deposunun çalışıyor olması biraz ironik
    • docker.io ayrıca rate limit uyguluyor; organizasyon belli bir büyüklüğe gelince build failure'lar daha sık çıkmaya başlıyor. Ayrıca bugün gün boyu Red Hat'in sahibi olduğu başka bir image hosting servisi olan quay.io de read-only haldeydi. Eğer container image bağımlılığınız varsa, yalnızca başkasının trenine binmek yerine doğru bir hosting çözümü kurmak daha iyi olur
    • public.ecr.aws bugün AWS kesintisi nedeniyle bende 5XX hatası verdiği için yine fail oldu referans bağlantısı
    • Benim için bu yöntem iyi gitmedi ama Google'ın mirror.gcr.io'su iyi çalıştı. FROM {image_name} satırını FROM mirror.gcr.io/{image_name} olarak değiştirmeniz yeterliydi. Umarım faydalı olur. ilgili kılavuz
    • Ben büyük bir build sistemi yönettiğim için bugün ECR'den image pull'lar gün boyu kararsızdı
  • Nexus gibi kendi registrilerini işletenler, ortak base image'larla doğrudan container image build edenler bugün gerçekten seçimlerine sevindiklerini düşünebilirim. Bu arızanın ne kadar çok build ve yeniden dağıtımı nasıl etkilediğini merak ediyorum. Docker veya Docker Hub'a karşı negatif bir görüşüm yok, hâlâ faydalı şekilde kullanıyorum
    • Docker image cache'ini ara katmana koymak gerçekten önemli bir alışkanlık. Docker upstream image'ları birdenbire düşerse, K8s node'ları değişirken base image bulunamaz ve servis ayağa kalkamaz. Sadece mühendislik disiplini olarak düşünülmesi gereken bir durum
    • Biz de base image kullanıyoruz ama GitHub Actions'ın hazırlık aşamasında docker image çeken bölüm var; uygulama build'i oluyor ama deploy olmuyor. CI/CD, dockerhub'a bağımlı ve bazı image'lar için pull-through cache ile path değiştirmek mümkün değil
    • Biz Harbor işletiyoruz ve Proxy Cache ile tüm base image'ları mirrorlıyoruz, bu yapıyı yıllardır sorunsuz kullanıyoruz. Harbor'ın da bazı kusurları var ama genel olarak gayet memnunuz
    • Konteyneri hiç kullanmıyor olmamız bu yüzden daha rahatlatıcı
    • Manuel workaround olmadan dev veya prod ortamında yeni iş yapamıyoruz. Etkisi oldukça büyük. Ayrıca Signal'da da bugün bir sorun var gibi görünüyor
  • AWS kesintisi haberinden daha ilginç olanı, bu kesintinin HN main'de daha çok görünmesi
  • Biraz utanarak yaptığım bir reklam ama, Docker Hub'a yüksek bağımlılığınız varsa Kubernetes cluster'ınıza Spegel kurulumunu öneriyorum
    • Gerçekten tamamen açık kaynaksa bunu landing sayfasında daha net belirtmeliler. Doğrudan kurup test edebilmek bir mühendisin dünyasında gerçekten büyük fark yaratır, çünkü satın alma sürecinden geçmek zorunda kalmazsınız
    • kuik ile farkını merak ediyorum. Spegel benim home-lab ortamım için biraz fazla olabilir, ama kurumsal ortamda iyi bir upgrade olabilir. Kuik: referans
    • Docker Hub dışındaki daha fazla repoyu mirrorlayan alternatifler de var. Çoğu enterprise seviyesinde biraz hantallaştırıcı olsa da, belirtilen özellikleri aynı şekilde çalışıyor. Artifactory, Nexus Repository, Cloudsmith, ProGet vb. Bunlar sayesinde birden fazla krizden çıkmış durumdayız
    • Spegel iyi görünüyor ama biz GKE kullandığımız için şu an için biraz hile gibi çalışıyor gibi. GKE'de düzgün desteklenecek mi merak ediyorum
  • Bu, bir tür kasıtlı tasarım.
    docker, private registry ayarını istememize rağmen kendini korumak için bunu reddetti ilgili stackoverflow Red Hat, docker ile uyumlu podman yaparak bu boşluğu doldurdu /etc/config/docker: BLOCK_REGISTRY='--block-registry=all' ADD_REGISTRY='--add-registry=registry.access.redhat.com'
    • Bu yorumu fazla iddialı buluyorum. Temel registry'yi docker.io yerine başka bir yere çevirme imkanı olsa bile, çoğu insan bunu yapmaz, çok zahmetlidir. Aslında tek yapılması gereken image tag'lerini doğru atmak. Şirketimizde tek bir imaj bile docker.io'dan çekilmiyor. İsimlerin başına <company-repo>/ eklemek 2 saniye sürer
    • Böyle bir 'footgun'u belli ölçüde tolere edilebilir buluyorum. Alan adı içeren image tag'lerin getirdiği ifade gücüyle oluşan yanlış anlamalardan çok daha büyük faydası var. Örneğin ekibin dokümantasyonunda eski bir komut varsa ve docker config'i eskiyse, yanlışlıkla global public registry'den pull yapılabilir. Kişisel olarak global registry'yi tamamen kaldırıp kaynağın açıkça görünmesini sağlamayı tercih ederim (fakat docker'ın bunu ciddiyetle ele alacağını sanmıyorum)
    • us-east-1 bölgesinde ECR'yi private registry olarak kullananlar için bu yöntem işe yaramadı
  • Docker çalışmadığı için O'Reilly'de bile oturum açamıyorum; bu yüzden “Docker down olduğunda bir şeyler öğreniriz” kısmının tam da bu nedenle mi olduğunu merak ettim
    • Son zamanlarda kullandığımız tüm paketleri tutan bir pull-through proxy kurmak yeterli oldu
  • Benzer bir durumda olanlara yardımcı olan yöntem ghcr oldu. Tamamen yerini tutmaz ama
    Örnek: docker pull ghcr.io/linuxcontainers/debian-slim:latest
    • Bu image bir yıldır güncelleme görmemişti ilgili bağlantı. Google Container Registry pull-through mirror sunduğu için sadece mirror.gcr.io önekini ekleyip, Docker Official Images için namespace yerine library yazarak örneğin mirror.gcr.io/library/redis kullanabilirsiniz redis resmi sayfası
  • 20 Ekim 2025 09:43 UTC itibarıyla kademeli olarak toparlanıyor. SaaS hizmetlerinde genel olarak hata oranında düşüş görülüyor. Backlog'u işlerken durumu takip etmeye devam ediyoruz