I'm having problems pushing images to my docker repo in Artifactory. Pulling the images works as expected, but pushing them gives me an error. I can see the progress bar pushing the image, but somehow it times out w/ a "I/O Timeout"
My setup consists of an Artifactory instance running in my k8 cluster and I have a F5 in front of it for SSL offloading. I followed these instruction for using the repository path method.
On the http settings I've tried using the nginx/http reverse proxy or just using the embedded tomcat. I either the the "I/O timeout" or a "503 Service Unavailable" (when using the embedded).
I know network wise everything is ok, since I can push other items. i.e, files, npm etc... It's a bit frustrating that I'm able to pull but not push. Has anyone seen this before??
Do the docker push command again with artifactory UI open ( Admin -> System logs -> Request log )
You should see a few requests coming in with '/api/docker' in the path. What's the return code and full path shows in request log?
The docker registry push would require docker login. You may need to get credentials for the docker registry so that you push. Say if you have saved password in a file
docker login --username=yourhubusername --email=youremail#company.com
And then try push.
Related
our Nexus (Nexus3 3.38.0) is currently down and just keeps on restarting, we use docker to run nexus as a container and when we check the container logs, we get this error:
javax.validation.constraintViolationExceiption: attributes[httpclient].authentication.password: must not be blank
We got this error logs after shutting down nexus and restarting docker service.
we suspect it might be due to one of the proxy repository password field that became blank (which we usually update using curl by a jenkins job)
Can you please suggest if:
There is any workaround for this issue
Since we can’t open into nexus portal, can we fix this using backend / config files?
Is there any way to disable / delete docker proxy repository using nexus data / config files?
Any other suggestion which might help us here
Looking for a little help here. Trying to bootstrap a small side business, and I have never been the DevOps guy. I use the web hosted version Gitlab to store my codebase, but I am unable to use it to act as a repository for docker images that I am creating from that code. The images that I am generating are quite large and exceed the token expiration when I am attempting to push back to the registry from the group gitlab-runner that I have installed on my personal machine. I have an extra machine sitting around, so I installed gitlab-ee and exposed it through a dynamic dns service (NoIP). I then mirrored the repositories that I want to generate images for on my locally hosted gitlab instance. At first, I tried to use a runner that was on the same machine as my gitlab instance, but always failed due to all available memory being consumed and locked up the machine. All in all, gitlab docs pretty much don’t run the runner and instance on the same machine. So, I went back to using the runner I originally used for the web hosted instance, but I am having issues pushing to my local instance. When trying to push to my repository (through the ddns URL), I end up getting a lot of this:
e4fdbd3bf512: Retrying in X seconds
And it eventually times out due to job time limit or token time limit. I am guessing this is due to my connectivity not being great. What I would like to do is have the (installed on a local machine) runner push to the local IP on my network, but I am unsure how to do this with the SSL setup. When trying to login and push in my pipeline, I get the following error:
Error response from daemon: Get "https://xxx.xxx.xxx.xxx:xxxx/v2/": x509: cannot validate certificate for xxx.xxx.xxx.xxx because it doesn't contain any IP SANs
How do I correct this without affecting the https:// SSL that is already setup for when accessing the instance from the DDNS? Appreciate any help you can give me.
I abandoned attempts at getting this to work. Ran through a bunch of scenarios of creating my on CA and trying to create certificates for the IP address and share that with the other machine. Ultimately, gitlab obscures some things with LetsEncrypt. Funny enough it was just a connectivity issue where I was getting timeouts. Ended up hard-lining both machines and getting better throughput. Able to push ~6GB docker images up through the URL.
While following Heroku's docs for how to push a docker image to their registry, I keep running into this error:
> docker push registry.heroku.com/<MY-APP>/web cd
Using default tag: latest
The push refers to repository [registry.heroku.com/<MY-APP>/web]
e0d052f1dc62: Preparing
41ec0e96eb83: Preparing
d081ada49467: Waiting
73c3e7ef7bc6: Waiting
unauthorized: authentication required
I continue to get a Login Succeeded whenever I try to use docker login, so I'm not sure what the issue is.
I tried to debug using the Docker Daemon logs but those weren't helpful.
Turns out I was bitten by what I'd consider to be a bug with the Heroku registry that stems from a debate about how to deny the user properly when they're logged in but try to access a resource that either doesn't exist or isn't theirs so that sensitive info, like the existence of a resource, isn't exposed (check this summary if you're interested).
TL;DR - Heroku shuold be sending a 404 but send a 401 instead - Go make the app via the UI and then try again.
I've an on-prem instance of Gitlab-CE 13.0.5 running, I'm using the official docker image of Gitlab.
I've enabled the integrated container registry.
Testing the login and push at the registry using a personal access token works, both on the commandline and within a CI script.
Using the CI job token in a CI script, the docker login passes, the docker push fails.
Using a group access token (with the read and write registry privilege), both login and then of course also push fails. Testing the group access token manually on the commandline the login step also fails.
I've checked the logfile of the registry, I only see the access denied message, no further hint whats might be wrong.
I've considered to tag the image with the correct hiearchy of group and project name.
Has anyone an idea where I should continue to search?
Thanks and cheers
Wolfgang
Finally, I found it!
If there is a port number in the registry name in the login command, exactly the same name including the port number has to be used when tagging and pushing an image.
So, if in the gitlab configuration in the variable gitlab_rails['registry_port'] = "443" the default port number 443 is mentioned, it appears in the variable $CI_REGISTRY and you have to use it in the tag and the push command.
Setting the variable gitlab_rails['registry_port'] = "" to an empty string let the system still use the port 443 - since it is the default port. However, it will be removed from the name.
To be honest, I was a bit surprised.
I have a CI-server which is building en pushing images to a secure registry. Every image gets a tag which is equal to the ID of the build.
I can see the images in my secure registry (self-signed). I can also use them so they're working fine.
But I'm unable to see them by URL in my browser:
In the browser of the server I'm performing:
https://localhost:5000/var/lib/registry/docker/registry/v2/repositories/conti/myapp/_manifests/tags/19
But I'm getting a 404-error instead of the image ID (after I've accepted the certificate).
What am I doing wrong? I get a 404 for every https://localhost:5000/...
I see nothing when just going to https://localhost:5000
[x#localhost ~]$ curl -k https://localhost:5000/var/lib/registry/docker/registry/v2/repositories/conti/myapp/_manifests/tags/19
404 page not found
Docker registry V2 doesn't support that particular endpoint, so it's not possible at the moment.