Estado del sistema de Docker: caída total del servicio

 (dockerstatus.com)
2 puntos por GN⁺ 2025-10-22 | 1 comentarios | Compartir por WhatsApp
  • Se produjo una interrupción extensa en los principales servicios de Docker.
  • Se confirmó que la causa se relaciona con un problema del proveedor de servicios en la nube.
  • Se observó una tasa de errores en el conjunto de servicios SaaS.
  • La recuperación de errores avanzó hasta la etapa de resolución de la cola pendiente y monitoreo.
  • Finalmente se declaró la resolución del problema y la normalización.

Resumen de la interrupción del sistema de Docker

Docker reportó problemas generalizados de acceso y uso en diversos servicios de Docker, incluyendo 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 y Docker Hardened Images.

20 de octubre de 2025, 00:16 PDT / 07:16 UTC

[Investigación en curso]
Se inició una investigación debido a incidencias generalizadas de acceso y uso en un gran número de servicios de producto.

20 de octubre de 2025, 01:22 PDT / 08:22 UTC

[Causa identificada]
Se identificó el origen del incidente en un problema con el proveedor de servicios en la nube.
Mientras se aguardaba la recuperación del proveedor, se preparó la plataforma propia y se realizó monitoreo.

20 de octubre de 2025, 02:43 PDT / 09:43 UTC

[Monitoreo]
Se observó una tendencia de recuperación gradual de la tasa de errores en todos los servicios SaaS.
Se continúa monitoreando continuamente el estado junto con el procesamiento de la cola pendiente.

20 de octubre de 2025, 03:05 PDT / 10:05 UTC

[Resuelto]
Este incidente fue oficialmente resuelto.
Se verificó la normalización completa de todo el servicio

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-10-22
Comentario de Hacker News
  • Hola, soy Tushar de Docker. Les pedimos disculpas por la caída del servicio de Docker provocada por el incidente de AWS actual. Nuestro equipo está trabajando con AWS para restaurar el servicio tan rápido como nos sea posible. Seguimos actualizando de forma continua en dockerstatus.com. Sabemos lo importantes que son Docker y el servicio para cientos de millones de desarrolladores alrededor del mundo. Pondremos todo nuestro esfuerzo para recuperar el servicio rápido. Una vez que esta situación esté completamente resuelta, anunciaremos un postmortem detallado junto con las medidas de prevención para el futuro.
    • Me dio curiosidad imaginar lo interesante que sería si DynamoDB, que causó esta caída en cadena, estuviera alojada en Docker Hub como una imagen de Docker.
  • Es una consecuencia del incidente de AWS. enlace de referencia
    • Dices que “se encontró un problema fundamental en uno de los proveedores de nube”, pero hoy en día casi todos usamos varios proveedores de nube, ¿por qué este incidente impacta tanto a uno solo?
  • También dependemos de varias imágenes públicas de Docker, y por defecto Docker usaba docker.io, así que los builds se rompieron. Por suerte, AWS ofrece un mirror de docker.io, y al cambiar a FROM public.ecr.aws/docker/library/{image_name} a todo funcionó correctamente. En los logs de error, la mayor parte del tiempo el fallo venía del endpoint de autenticación (https://auth.docker.io): “No hay un servidor disponible para procesar esta solicitud”. Tras cambiar al mirror de AWS, todos los builds terminaron sin problema.
    • Es un poco irónico que Docker se haya caído por el incidente de AWS y, sin embargo, el mirror de AWS esté funcionando.
    • docker.io también aplica rate limit y, cuando una organización crece lo suficiente, empiezan a aparecer fallas frecuentes de build. Por cierto, otro servicio de alojamiento de imágenes, quay.io (de propiedad de Red Hat), estuvo en modo solo lectura casi todo el día. Si dependes de imágenes de contenedor, conviene menos subirse sin más al barco de alguien más y más armar una solución de hosting robusta.
    • public.ecr.aws también devolvía errores 5XX hoy por el incidente de AWS y a mí me falló enlace de referencia
    • A mí este método no me funcionó, pero usando el mirror de Google (mirror.gcr.io) sí me funcionó. Solo hay que cambiar FROM {image_name} por FROM mirror.gcr.io/{image_name}. Ojalá te ayude. guía relacionada
    • Yo administro un sistema de build a gran escala y el pull de imágenes en ECR estuvo inestable todo el día.
  • Cuando operamos un registry propio como Nexus, y construimos imágenes de contenedor usando imágenes base comunes, hoy sin dudas se siente más tranquilizador esa elección. Me pregunto cuántos builds y redeploys puede romper un incidente así. No tengo aversión a Docker o Docker Hub; de hecho, los sigo usando con gusto.
    • Tener una caché de imágenes de Docker en el medio es un hábito importante de higiene de ingeniería. Si Docker retira de golpe una imagen upstream, cuando se reemplazan nodos de K8s no se puede encontrar la imagen base y arranque de servicio puede fallar. Es simplemente ingeniería limpia.
    • También usamos imágenes base, pero en GitHub Actions hay una etapa de preparación donde se trae una imagen Docker, de modo que la app puede compilarse pero el despliegue no. Nuestro CI/CD depende de dockerhub, y hay imágenes cuyo path no se puede cambiar vía pull-through cache y entonces pasa esto.
    • Nosotros operamos Harbor y hacemos mirror de todas las imágenes base con Proxy Cache, y hemos usado esta configuración por años. Harbor tiene algunos pros y contras, pero en general estamos bastante satisfechos.
    • Lo que pasa es que cuando directamente no usas contenedores, te da aún más tranquilidad.
    • No se puede trabajar en dev ni prod sin un workaround manual. El impacto me parece bastante grande. Por cierto, también parece que hoy tuvo inconvenientes Signal.
  • Me pareció bastante curioso que esta caída esté más en portada en HN que la noticia del incidente de AWS.
  • Una publicidad algo incómoda, pero si dependes mucho de Docker Hub recomiendo instalar Spegel en tu clúster de Kubernetes.
    • Si fuera realmente open source, estaría genial que la landing lo indique claramente, de forma más obvia. Podrías instalarlo y probarlo ya; eso hace una gran diferencia para un ingeniero porque no tenés que pasar por ningún proceso de compra.
    • Me intriga la diferencia con kuik. Spegel me parece demasiado para mi home lab, pero para un entorno de empresa podría ser una buena mejora. Kuik: referencia
    • También hay alternativas para hacer mirror de más repositorios que Docker Hub. La mayoría se siente un poco enterprise-ish, pero cumplen bien lo que prometen. Están Artifactory, Nexus Repository, Cloudsmith, ProGet, entre otros. Gracias a estos sistemas, ya salimos de varias crisis.
    • Spegel se ve bien, pero nosotros usamos GKE y por ahora está funcionando algo así como una trampa. Me gustaría saber si habrá soporte más directo para GKE.
  • Esto es, en cierta forma, un diseño intencional. Docker rechazó solicitudes para configuración de registro privado, pero lo rechazó por interés propio. stackoverflow relacionado Red Hat cerró ese hueco con podman, compatible con docker /etc/config/docker: BLOCK_REGISTRY='--block-registry=all' ADD_REGISTRY='--add-registry=registry.access.redhat.com'
    • Para mí esta explicación se siente demasiado forzada. Aunque se pudiera cambiar el registry por defecto de docker.io por otro, la mayoría de la gente no lo haría, por comodidad. En realidad, con etiquetar bien las imágenes alcanza. En mi empresa no hacemos pull de ninguna imagen desde docker.io: solo agregamos <company-repo>/ al nombre de la imagen y nos toma 2 segundos.
    • Creo que podemos tolerar este tipo de ‘footgun’ en cierta medida. Siento que los beneficios de la expresividad de las etiquetas con dominio superan las confusiones que puede generar. Por ejemplo, si en documentación de equipo hay comandos y la configuración de Docker está vieja, podrías hacer pull desde un registro público global por error. Personalmente creo que es mejor quitar el registro global y dejar explícito de dónde trae cada imagen (aunque dudo que Docker lo tome en serio).
    • En mi caso, esto no sirvió cuando usamos ECR como registro privado en la región us-east-1.
  • No pude loguearme en O'Reilly porque Docker no estaba disponible, y por eso me pregunté si el “si Docker cae, hay que aprender otra cosa” iba a pasar por esta caída.
    • Un cambio de los paquetes que venías usando recientemente a un pull-through proxy te lo resuelve.
  • Para otros que tuvieron el mismo problema, una alternativa útil fue usar ghcr; no reemplaza todo, pero Ejemplo: docker pull ghcr.io/linuxcontainers/debian-slim:latest
    • Esta imagen no se actualiza desde hace más de un año. enlace relacionado. Como Google Container Registry ofrece un mirror pull-through, basta con poner mirror.gcr.io como prefijo y para las Docker Official Images poner library como usuario, por ejemplo mirror.gcr.io/library/redis. redis page
    • Al 20 de octubre de 2025, 09:43 UTC, la recuperación era progresiva. Se observa una caída en la tasa de error en servicios SaaS en general. Estamos procesando el backlog y monitoreando la situación continuamente.