Private registries with no port are not properly handled about docker-image-resource

[concourse-bot]

Hi there!

We use Pivotal Tracker to provide visibility into what our team is working on. A story for this issue has been automatically created.

The current status is as follows:

• #115464593 Private registries with no port are not properly handled

This comment, as well as the labels on the issue, will be automatically updated as the status in Tracker changes.

[ldejager]

fix_repository_flood.txt

The attached patch works somewhat - I still see a lot of requests to docker.io but nothing near the volumes I saw before which resulted into my account being temporarily blocked. I assume the requests I'm still seeing is perhaps from the in and out scripts.

There is probably a much more elegant and complete way to solve the issue so if this doesn't align with the project goals feel free to push back.

[cjcjameson]

@ldejager we had been trying to run against a private registry and ran into issues which seemed to manifest as an issue with specifying the port # in our docker url, but was actually an issue along this same codepath about understanding when a non-dockerhub registry is being used.

my.private.docker.registry/image-name: if we refer to the image this way, then pushing works, but all our "check" containers fail
my.private.docker.registry:443/image-name: if we refer to the image this way, the check containers work because they know not to refer to dockerhub. But any pushes we want to make fail.

We have a pipeline where we're chaining image creation from one job to the next, so we had no good way out. Fortunately, we just started using Dockerhub, so we're unblocked.

[dajulia3]

Would really love this change for our Pivotal Labs clients thinking of using concourse. For many of our enterprise customers we require private docker registries. For example, we have a docker image of a legacy db2 database seeded with realistic data, which they wouldn't want to be public. Right now we have a work-around, but it'd be nice to have this feature!

[DenisIzmaylov]

I got the same issue, some of the logs:

Step 2 : COPY html /var/www/html
 ---> 627a205fcec0
Removing intermediate container f35cf1d025c5
Step 3 : EXPOSE 80
 ---> Running in d7d52ea162d9
 ---> 00c13e3f24d9
Removing intermediate container d7d52ea162d9
Step 4 : CMD /start.sh
 ---> Running in 8815e83217d0
 ---> 2ad0ca203f93
Removing intermediate container 8815e83217d0
Successfully built 2ad0ca203f93
The push refers to a repository [my-private-registry:5000/frontend-release]
Get https://my-private-registry:5000/v1/_ping: dial tcp 62.4.21.33:5000: i/o timeout

@dajulia3 Could you please share how did you make this work-around to get it working with private Docker Registry?

[DenisIzmaylov]

I've launched Docker Registry without any complex config:

docker run -d -p 5000:5000 --restart=always --name registry \
  -v /var/docker-registry:/var/lib/registry \
  registry:2

[DenisIzmaylov]

It was ufw issue.

[vito]

Went with a pretty broad fix to just treat anything with a . in the first repository segment as a URL. Looking at Docker's code this is pretty much what they do, too. Fix should be in the next release.

[concourse-bot]

Hello again!

All stories related to this issue have been accepted, so I'm going to automatically close this issue.

At the time of writing, the following stories have been accepted:

• #115464593 Private registries with no port are not properly handled

If you feel there is still more to be done, or if you have any questions, leave a comment and we'll reopen if necessary!