as of 22:45 UTC (~30 minutes ago) they marked the status green with "Issue is mitigated, monitoring the situation"
...but I'm still getting 503 responses on my dev box as well as when I run `curl https://registry.docker.io/` on 2 CI boxes in 2 different datacenters.
Can also confirm that our entire pipeline is down. We use CircleCI and henceforth all deployments are instantly failing. Luckily no mission critical deployments today...
Does anyone know how to skip/bypass the "load metadata for docker.io/" step on a build? I already have the image cached but it fails on that step regardless.
The metadata check is part of the builds image pull process. The step can resolve a `FROM repo/image:tag` reference to the content sha the tag points to, and then if required fetch the content.
In any case, recent-ish (maybe 24+) versions of docker default to a "prefer local" mode in buildkit so a local cached entry will be returned first if possible before any remotes are resolved.
Out of interest, what docker/buildx/buildkit versions were attempting the connection? We ran into this on some container builds that run offline last year some time and I'm wondering if it was due to some ancient docker, as that flag appears useless on current docker.
docker build --pull=false . still does a metadata check for me every single time. If i add the @sha256: like the sibling comment suggested, it does not.
This is the 2nd one this year I'm pretty sure. I wonder what the losses come out to all things considered in terms of development time and applications going offline (claude was offline for 10 or so minutes when this happened).
30 comments
[ 2.0 ms ] story [ 52.2 ms ] threadUpdate: I configured the gcp docker mirror and can pull images again https://cloud.google.com/artifact-registry/docs/pull-cached-...
...but I'm still getting 503 responses on my dev box as well as when I run `curl https://registry.docker.io/` on 2 CI boxes in 2 different datacenters.
`Error response from daemon: Get "https://registry-1.docker.io/v2/": received unexpected HTTP status: 503 Service Unavailable`
For example:
In any case, recent-ish (maybe 24+) versions of docker default to a "prefer local" mode in buildkit so a local cached entry will be returned first if possible before any remotes are resolved.
Out of interest, what docker/buildx/buildkit versions were attempting the connection? We ran into this on some container builds that run offline last year some time and I'm wondering if it was due to some ancient docker, as that flag appears useless on current docker.
- https://github.com/docker/buildx/blob/7b1ec7211d871dfba53b10...
Docker 26.1.4
The reason the outage is impactful on many is because they're using containers which are hosted on dockerhub.