Status do Docker: interrupção de todos os serviços

• Serviços principais do Docker tiveram uma falha ampla
• A causa foi identificada como uma questão relacionada ao provedor de serviços em nuvem
• Foi observada taxa de erro em todos os serviços SaaS
• A recuperação de erros entrou na etapa de processamento de backlog e monitoramento
• Foi declarada a resolução do problema e retorno à normalidade

---

Visão geral da interrupção do sistema Docker

Foram observados problemas generalizados de acesso e uso em vários serviços do Docker, incluindo 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 e Docker Hardened Images.

20 de outubro de 2025 00:16 PDT / 07:16 UTC

[Investigação em andamento]
Iniciada a investigação da causa devido a problemas de acesso e uso em diversos serviços do produto.

20 de outubro de 2025 01:22 PDT / 08:22 UTC

[Causa identificada]
A causa da falha foi identificada como um problema do provedor de serviços em nuvem. Sistemas internos foram preparados e monitoramento começou, caso o provedor de serviços apresentasse recuperação.

20 de outubro de 2025 02:43 PDT / 09:43 UTC

[Monitorando]
Foi observada uma tendência de recuperação gradual da taxa de erros em todos os serviços SaaS. O monitoramento de estado segue em andamento junto com o processamento de backlog.

20 de outubro de 2025 03:05 PDT / 10:05 UTC

[Resolvido]
Esta falha foi oficialmente resolvida. A normalização completa dos serviços foi confirmada

[GN⁺]

Comentários do Hacker News

• Olá, sou o Tushar, da Docker. Pedimos desculpas pela indisponibilidade dos serviços da Docker causada pelo incidente atual na AWS. Nossa equipe está trabalhando com a AWS para recuperar os serviços o mais rápido possível e mantendo atualizações contínuas em dockerstatus.com. A Docker sabe o quanto Docker Hub e o serviço são importantes para milhões de desenvolvedores ao redor do mundo. Vamos fazer o máximo para uma recuperação rápida. Depois que esse incidente estiver totalmente resolvido, vamos publicar um postmortem detalhado com os próximos passos de resposta
  • Fiquei pensando que seria curioso se o DynamoDB, que foi a causa dessa falha em cadeia, estivesse sendo hospedado no Docker Hub no formato de uma imagem Docker
• Isso é consequência da falha da AWS link de referência
  • Eles disseram que “descobriram uma questão de base em um dos provedores de nuvem”, mas hoje em dia todo mundo usa mais de um provedor de cloud, certo? Fico curioso sobre por que uma falha em um único fornecedor causa tanto impacto
• Nós também dependemos de várias imagens públicas do Docker e, por padrão, o Docker usava docker.io, então as builds quebraram. Felizmente, como a AWS fornece um mirror do docker.io, ao trocar para
  FROM public.ecr.aws/docker/library/{image_name}
  as builds ficaram todas funcionando. Nos logs de erro, a maior parte era um erro no endpoint de autenticação (https://auth.docker.io):
  "Nenhum servidor disponível para processar esta solicitação". Depois de trocar para o mirror da AWS, as builds passaram a ser concluídas sem problemas
  • O Docker caiu por causa da falha da AWS, enquanto o repositório mirror da AWS segue funcionando, o que é um pouco irônico
  • O docker.io também tem rate limit e, quando uma organização cresce, as falhas de build começam a aparecer com frequência. Só para registrar, o quay.io (propriedade da Red Hat) também ficou em modo apenas leitura o dia todo. Se sua solução depende de imagens de contêiner, é melhor ter uma solução de hospedagem realmente robusta em vez de apenas “andar no ônibus” do outro
  • O public.ecr.aws também apresentou erro 5XX por causa da falha da AWS hoje e falhou para mim link de referência
  • Esse método não funcionou bem para mim, mas funcionou bem usando o mirror do Google (mirror.gcr.io). Basta trocar
    FROM {image_name}
    por
    FROM mirror.gcr.io/{image_name}
    . Espero que ajude. guia relacionado
  • Eu gerencio um sistema de build grande e o pull de imagem no ECR ficou instável o dia inteiro
• Quem opera registry próprio, como o Nexus, e cria contêineres a partir de imagens base comuns hoje certamente está aliviado com a decisão de fazer isso internamente. Fico curioso para saber quantas builds e redistribuições isso pode quebrar. Não tenho aversão a Docker ou Docker Hub e uso muito bem eles
  • Manter cache de imagem do Docker no meio é um hábito importante. Se o Docker tirar de repente uma imagem upstream, quando um nó do K8s é substituído ele não encontra a imagem base e fica difícil subir o serviço. Isso é, para mim, higiene de engenharia
  • Também usamos imagens base, mas o passo de preparo no GitHub Actions puxa as imagens Docker, então a build da aplicação roda, mas o deploy não. O CI/CD depende do Docker Hub e algumas imagens não conseguem alterar o caminho via pull-through cache, então acontece isso
  • Operamos o Harbor e fazemos espelho de todas as imagens base via Proxy Cache; já usamos essa configuração há anos. O Harbor tem algumas limitações, mas no geral estamos satisfeitos
  • Fica ainda mais tranquilo nas vezes em que não usamos contêiner
  • Sem workaround manual, não dá para fazer novos trabalhos em ambientes de dev e prod. A repercussão é bem grande, eu acho. Pelo que parece, o Signal também teve problema hoje
• Mais curioso do que a notícia da falha da AWS é essa falha ficar no topo do HN
  • Não na tal front page secreta, olha só! página active
• É uma propaganda meio estranha, mas se sua dependência no Docker Hub for grande, recomendo instalar o Spegel no cluster Kubernetes
  • Se o Spegel fosse realmente 100% open source, seria legal deixar isso bem claro na landing page. Se desse para instalar e testar na hora, faria uma baita diferença para engenheiros, já que não precisaria passar por processo de compra
  • Fiquei curioso sobre a diferença com o kuik. O Spegel é meio exagerado para o meu homelab, mas pode ser um bom upgrade no ambiente corporativo. Kuik: referência
  • Também há alternativas para espelhar mais repositórios além do Docker Hub. A maioria tem aquele ar de solução enterprise, mas funcionam como esperado nas funcionalidades anunciadas. Existem Artifactory, Nexus Repository, Cloudsmith e ProGet. Graças a elas, já saímos de várias crises
  • O Spegel parece promissor, mas nós usamos GKE então hoje ele funciona apenas como uma gambiarra. Fico curioso se vai ter suporte adequado no GKE
• Isso é uma espécie de design intencional.
  docker recebeu solicitação para configurar registry privado, mas recusou por decisão própria
  stackoverflow relacionado
  A Red Hat permitiu isso criando o podman compatível com docker
  /etc/config/docker:
  BLOCK_REGISTRY='--block-registry=all'
  ADD_REGISTRY='--add-registry=registry.access.redhat.com'
  • Acho essa linha de raciocínio um pouco exagerada. Mesmo se for possível trocar o registry padrão do docker.io por outro, a maioria das pessoas não vai fazer isso por preguiça. Na prática, basta colocar corretamente as tags de imagem. Na empresa em que trabalho, não fazemos pull de imagem nenhuma do docker.io. Prefixar <company-repo>/ no nome da imagem leva 2 segundos
  • Eu acho que dá para tolerar esse tipo de “armadilha” (footgun). Penso que os benefícios da expressividade de tags de imagem com domínio incluído são maiores que os mal-entendidos que ele pode gerar. Por exemplo, se uma ordem de comando estiver em documentos de time e a configuração do Docker estiver desatualizada, alguém pode puxar da registry pública global sem perceber. Acredito que é melhor remover o registry global por completo e deixar explícito de onde vem cada imagem (mas acho que a Docker não vai considerar isso seriamente)
  • Para quem usava ECR como registry privado na região us-east-1, esse método não ajudou
• O Docker não está no ar e também não consigo logar no O'Reilly, então fiquei pensando se a ideia de “se o Docker cair, aprender outra coisa” foi por causa desse incidente
  • Instalar um pull-through proxy que guarde todos os pacotes usados recentemente deve resolver
• Um método que ajudou outros com problema parecido foi usar o ghcr. Não substitui completamente, mas
  ex.: docker pull ghcr.io/linuxcontainers/debian-slim:latest
  • Essa imagem não recebe atualização há mais de um ano link relacionado. Como o Google Container Registry oferece um mirror pull-through, basta adicionar mirror.gcr.io como prefixo e, para Docker Official Images, usar library como namespace, por exemplo mirror.gcr.io/library/redis, conforme a página oficial do redis
• Em 20 de outubro de 2025 09:43 UTC, está em recuperação progressiva. Está sendo observada uma queda na taxa de erro dos serviços SaaS em geral. A equipe segue monitorando a situação enquanto trata o backlog