Docker Community Forums

Share and learn in the Docker community.

Error 500 when pulling from public registry with docker 1.3

(Nharraud) #1

I have tried to pull different images from the public registry but most of them return a 500 error.

From what I see, I can pull library images without problem:
It succeeded for “mongo” and “redis”

However it fail for every other images:

docker pull dockerfile/elasticsearch
docker pull barnybug/elasticsearch
docker pull tutum/elasticsearch
docker pull dockerfile/mongodb

all fail with the same error

Pulling repository tutum/elasticsearch
2014/10/20 14:37:00 HTTP code: 500

I successfully pulled the last version of dockerfile/mongodb yesterday, just after upgrading docker to 1.3

Is there a server issue or am I doing something wrong?

I am on MacOS 10.9.5. Docker was installed with the last docker for OSX installer (1.3)


(Benjamin Waller) #2

I have the same problem, so there is probably something wrong with the servers.
Since I still am on 1.2, I thought, this could be the reason. Thanks for testing with 1.3 :smile:

seems to be working again…

(Sam Saffron) #3

This happens occasionally when the registry is overloaded, what we really need @sven and @solomon is something like this.

(Andy Rothfusz) #4

We have

Errors which get caught by automation also get posted automatically, but some errors aren’t caught automatically. Unfortunately the ops team is usually busy fixing the problem and we often forget to update the status until after the issue is fixed for these manual issues.

Sorry about the login problems recently. There have been two causes:

  1. A metrics routine that overwhelms the database. We’re in the process of creating a follower database which can get slammed without impacting production.
  2. An error in how we were handling our web proxies for user login: as soon as N users in a row failed to log in via the website, everyone got blocked because the locking logic only saw the proxy IP, so it blocked that. Blocking the proxy blocks everyone who tries to log in via the website. We’ve now fixed this so that we block the originating IP instead of the proxy. That could still be bad for conferences, etc, but it is the best way to keep out brute force attacks on passwords.

(Sam Saffron) #5

@rufus I think a big metric which would help tons is performance of the registry CDN.

Often we find that images in australia are super slow to download and super fast in north america. It would be very interesting to keep track of this somehow.

(Sven Dowideit) #6

I hear (was it you?) that the DO data center in singapore had awful registry throughput?

I agree - it’d be awesome to have ways to help the network infrastructure providors see where the good and bad bits are.