I followed the JFrog Blog post detailing the process but have not been successful in pulling any images from that mirror specifically. Other mirrors (such as docker-hub) do work correctly.
Here are screenshots I've taken to show the manifest syntax I followed when pulling the ironbank image through artifactory:
Manifest syntax example from the JFrog guide
Docker manifest not found
This is within the same major version of Artifactory, so I expected there not to be any API changes. I verified this by pulling other docker images through a docker-hub mirror repository.
The redacted-user matches the Username in Ironbank's registry1 User Profile and the CLI token was generated to use as the access token:
Artifactory mirror config
Has anyone gotten their ironbank mirror proxy to work through Artifactory?
Related
I wonder if there is a way to keep untagged images in JFrog Artifactory.
When I push the first image with a tag 1.1 for example I get a digest of that image.
If I pull the image with docker pull my-docker.jfrog.io/myimage#$digest_from_first_image it works just fine.
But if I push another image with the same tag 1.1 which will likely have another digest, the old digest is deleted and no longer available. I get the error not found: manifest unknown: The named manifest is not known to the registry.
I just started using OpenShift and currently using the 60 day free trial. I was hoping to test some of my developmental Dockerfiles in it, but when I try to use any Dockerfile I get this error:
admission webhook "validate.build.create" denied the request: Builds with docker strategy are prohibited on this cluster
To recreate:
Developer view -> Topology -> From Dockerfile ->
GitHub Repo URL = https://github.com/alpinelinux/docker-alpine -> Defaults for everything else -> Create
This example just uses the official Alpine Dockerfile and it does not work.
Based on this answer made by Graham Dumpleton
If you are using OpenShift Online, it is not possible to enable the docker build type. For OpenShift Online your options are to build your image locally and then push it up to an external image registry such as Docker Hub, or login to the internal OpenShift registry and push your image directly in to it. The image can then be used in a deployment.
If you have set up your own OpenShift cluster, my understanding is that docker build type should be enabled by default. You can find more details at:
https://docs.openshift.com/container-platform/3.11/admin_guide/securing_builds.html
If you are after a way to deploy a site using a httpd web server, there is a S2I builder image available that can do that. See:
https://github.com/sclorg/httpd-container
OpenShift Online provides the source build strategy (S2I). Neither docker or custom build strategies are enabled. So you can build images in OpenShift Online, but only using the source build strategy.
I have a remote docker repository configured in Artifactory (to docker hub). To test it I've created docker image A and pushed it to docker hub.
The image is user-name/image:latest.
Now I can pull it from artifactory using artifactory-url/docker/user-name/image:latest.
Now I've updated image A to image B and pushed it to docker hub. When I remove my local images and pull this image again from Artifactory I still get the image A (so it seems the cache is used). When I set the following setting to zero (Metadata Retrieval Cache Period) I'll pull the updated image B.
All fine. Now I increase the Metadata Retrieval Cache Period setting again. I've now deleted the image from docker hub and try to pull it again using artifactory. This fails while I was hoping it would just pull the image from the Artifactory cache?
I can also not pull it using the cache directly: docker pull artifactory-url/docker-cache/user-name/image:latest.
Is there a way to use a docker image from artifactory which is deleted in the remote repository?
The first part you wrote is ok and its the expected behavior. Now, for the second part, it's also the expected behavior and I will explain why - when you use a virtual repository as your Artifactory Docker registry, it will always search for artifacts in the local repositories first, then in the remote-cache, and only then in the remote itself. However, if Artifactory finds the package in the local or remote-cache repositories, it will always also check the remote for newer versions. This causes cached images that are deleted from the remote itself to not be downloadable from the remote-cache in Artifactory, since Artifactory receives a 404 error from the remote repository. You can fix this by moving the image to the local repository, and you will be able to pull it.
I have a linux bare-metal server with docker installed.
I work on an asp.net core project on my computer.
My source code is pushed on github.
Each time i commit and push something, github triggers a webhook on my docker hub account.
Docker hub builds me a new image which contains my asp.net core application binaries. (docker hub also run the tests)
This image works fine when i pull it manually on my server.
My question is how can i do this automatically ? Is there a way for my server to "detect" that docker hub contains a new version of the image and run something to pull this image and fire database migrations automatically ?
Thanks
If you have a public ip which external internet such as dockerhub could visit you, then you can use Docker Hub Webhooks:
You can create webhooks like next diagram, set the url which external could visit your service, when image was pushed, it will post some json data to the url you afforded, one example data here, then your own url could receive data and do related things as you like.
And, if you use jenkins, there are lots of plugin help you to do similar things: refer Triggering Docker pipelines with Jenkins, also Polling Docker Registries for Image Changes
If you not have a public ip which dockerhub could visit, then I guess you had to poll dockerhub to see if new image there...
I'm trying to get the Docker Build and Publish plugin working on our Jenkins instance. The Docker image is getting built correctly, but I'm having issues with getting this image pushed to our Artifactory Docker Repository.
The Artifactory repository is hosted at https://instance.company.com/artifactory/test-docker-build
When I look in the logs for the build, it fails to upload the Docker image, but the url looks like https://instance.company.com/test-docker-build. Here is the output from the log:
[workspace] $ docker push instance.company.com/test-docker-build:test
The push refers to a repository [instance.company.com/test-docker-build] (len: 1)
Sending image list
Error: Status 405 trying to push repository test-docker-build: "<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>405 Method Not Allowed</title>\n</head><body>\n<h1>Method Not Allowed</h1>\n<p>The requested method PUT is not allowed for the URL /v1/repositories/test-docker-build/.</p>\n</body></html>\n"
Build step 'Docker Build and Publish' marked build as failure
Finished: FAILURE
I am assuming that it is failing because the repository URL is incorrect. I have also tried logging into the backend and pushing via the command line with the correct repository URL and that doesn't seem to work either.
My main question is: does docker not like the URL structure since it uses the '/' to denote user/image name? I.E. would this work if the url didn't include the /artifactory?
Any ideas would be greatly appreciated!
The response you're getting back looks like something a reverse proxy would return (nginx\apache), not Artifactory - did you follow the instructions on how to set up a Reverse Proxy with Artifactory?
Usually you would need to:
set up the reverse proxy for docker usage correctly
either get a certificate for company.com and use it in the proxy or set up Artifactory as an insecure registry (beware of this - should not be used in production)
Once you did these you will reference the Artifactory instance as instance.company.com no need for /artifactory or anything else.
The url you posted is what the reverse proxy should use when directing to Artifactory (i.e. instance.company.com/artifactory/api/docker/test-docker-build/v2)
Then usage would look like docker push instance.company.com/myImage:myTag