I am trying to run "pack build" (using Paketo as buildpacks provider) in an environment where I do not have direct access to "registry-1.docker.io". Access to the external docker registry is provided via an internal proxy endpoint.
When running the command
pack build paketo-demo-app --builder my-dockerhub-proxy.company.com/paketobuildpacks/builder:base
I see that it fails to load the run-image because registry location reverts back to the default. See logs below
base: Pulling from paketobuildpacks/builder
10a039f4d1c5: Pull complete
281985c8fc9f: Pull complete
72ad9888618d: Pull complete
4f4fb700ef54: Pull complete
....
Digest: sha256:07fe9a8fca80c2259062f1400ccc856caa896428d93d5d8c60b6b6fd2480c07e
Status: Downloaded newer image for my-dockerhub-proxy.company.com/paketobuildpacks/builder:base
ERROR: failed to build: invalid run-image 'index.docker.io/paketobuildpacks/run:base-cnb': Error response from daemon: Get https://registry-1.docker.io/v2/: EOF
Is there a Paketo configuration parameter that can override the docker registry location ?
I have a Dockerfile which is going to be implemented FROM a private registry's image. I build this file without any problem with Docker version 1.12.6, build 78d1802 and docker-compose version 1.8.0, build unknown, but in another machine which has Docker version 17.06.1-ce, build 874a737 and docker-compose version 1.16.1, build 6d1ac21, the docker-compose build returns:
FROM my.private.gitlab.registry:port/image:tag
http://my.private.gitlab.registry:port/v2/docker/image/manifests/tag: denied: access forbidden
docker pull my.private.gitlab.registry:port/image:tag returns the same.
Notice that I tried to get my.private.registry:port/image:tag and http://my.private.registry:port/v2/docker/image/manifests/tag has been catched.
If this is an authenticated registry, then you need to run docker login <registryurl> on the machine where you are building this.
This only needs to be done once per host. The command then caches the auth in a file
$ cat ~/.docker/config.json
{
"auths": {
"https://index.docker.io/v1/": {
"auth": "......="
}
}
}
A login did not fix the problem for me. This may be specific to Mac, but just in case here is the Git issue
My comment on it:
Also experiencing this issue.
Dockerfile:
FROM <insert_private_registry>/test-image:latest
CLI
Both commands fail without a login to the private registry (expected)
$ docker-compose up
Building app
Step 1/2 : FROM <insert_private_registry>/test-image:latest
ERROR: Service 'app' failed to build: Get https://<insert_private_registry>/v2/test-image/manifests/latest: denied: access forbidden
$ docker pull <insert_private_registry>/test-image:latest
Error response from daemon: Get https://<insert_private_registry>/test-image/manifests/latest: denied: access forbidden
After logging in, a docker pull ... works while the docker-compose up fails to pull the image:
$ docker login <insert_private_registry>
Username: <insert>
Password: <insert>
Login Succeeded
$ docker-compose up
Building app
Step 1/2 : FROM <insert_private_registry>/test-image:latest
ERROR: Service 'app' failed to build: Get https://<insert_private_registry>/v2/test-image/manifests/latest: denied: access forbidden
$ docker pull <insert_private_registry>/test-image:latest
latest: Pulling from <insert_private_image_path>/test-image
...
Status: Downloaded newer image for <insert_private_registry>/test-image:latest
Current Solution
Our current workaround is to explicitly pull the image prior to running the docker-compose containers:
docker pull <insert_private_registry>/test-image:latest
latest: Pulling from <insert_private_image_path>/test-image
...
Status: Downloaded newer image for <insert_private_registry>/test-image:latest
$ docker-compose up
Building app
Step 1/2 : FROM <insert_private_registry>/test-image:latest
...
I notice your URL scheme uses the http protocol - Docker needs to be configured to allow insecure registries.
Create or modify your daemon.json (required in one of the following locations):
Linux: /etc/docker/
Windows: C:\ProgramData\Docker\config\
With the contents:
{
"insecure-registries" : [ "my.private.gitlab.registry:port" ]
}
Then restart Docker (not just the terminal session) and try again.
Once you've logged in with:
docker login my.private.gitlab.registry:port
As per tarun-lalwani's answer, this should then add the auth into the config, for future use (docker pull's etc.).
In my case on Linux I can fix this error by adding sudo to my docker-compose up command.
The nexus is configured at 8444 for internal hosting and the 7001 for the external proxy. I am able to pull images from 8444. But can't pull anything from the internet. The nexus is pointing to https://registry-1.docker.io in the proxy settings. Any suggestions?
$ docker pull x.com:8444/hello-world
Using default tag: latest
latest: Pulling from hello-world
c04b14da8d14: Pull complete
Digest: sha256:a18ed77532f6d6781500db650194e0f9396ba5f05f8b50d4046b294ae5f83aa4
Status: Downloaded newer image for x.com:8444/hello-world:latest
$ docker pull x.com:7001/node
Using default tag: latest
Error response from daemon: unknown: unknown
(there is no error log showing in nexus for this pull)
I found the answer myself. In the configuration, need to use
"Use Docker Hub"
option in the Proxy->Docker index.
I used "Use proxy registry (specified above)" which doesn't work.
I had initially thought this was the same as: Kubernetes imagePullSecrets not working; getting "image not found"
However, even disabling authentication (to avoid the need for secrets) still produces the same error.
So, Kubernetes trying to pull images from Nexus Docker registry keeps producing the kubernetes error:
"Failed to pull image "nexus.mydomain.co.uk/nginx": Error: image nginx:latest not found"
This is also reflected in the Nexus logs:
2016-06-22 14:51:26,929+0000 WARN [qtp556619582-227] docker org.sonatype.nexus.repository.docker.internal.V1Handlers - Error: GET /v1/repositories/nginx/images: 404 - org.sonatype.nexus.repository.docker.internal.V1Exception$ImagesNotFound: images not found
I can't get onto the kube boxes to try a pull, however, when I run "docker pull" from my mac command line all is well and good.
I am asking docker to build an ASP.NET 5 beta6 application image for me at Ubuntu 14.04.1 virtual machine:
docker build -t instanceName .
using dockerfile that starts with:
FROM microsoft/aspnet:1.0.0-beta6
It responds with this message:
Sending build context to Docker daemon 124.4 kB
Sending build context to Docker daemon
Step 0 : FROM microsoft/aspnet:1.0.0-beta6
Pulling repository microsoft/aspnet
9424b500cebc: Error pulling image (1.0.0-beta6) from microsoft/aspnet, HTTP code 400
ba249489d0b6: Download complete
19de96c112fc: Download complete
b92a854a78d0: Download complete
63e9265ef57c: Error pulling dependent layers
INFO[0019] Error pulling image (1.0.0-beta6) from microsoft/aspnet, HTTP code 400
It does similar thing when I replace dockerfile definition to just FROM microsoft/aspnet.
What does it mean? If it were 404, I would understand that there is no such image. But "Bad Request"? Can I make the request... better?