Thereâs been some chatter about the partnership between JFrog and Docker, most of it around this bit here:
JFrog Artifactory as a pull-through cache for Docker Hub
By taking advantage of JFrog Artifactory as a local container cache, coupled with limitless Docker Hub access, enterprise developers will reap a variety of benefits, including:
A boost to developer productivity. Enterprise developers will get faster and more responsive access to containers by standing up JFrog Artifactory as their local container cache with no Docker Hub limitations.
Optimized usage of IT resources. By caching Docker images locally on JFrog Artifactory, external traffic on the developersâ networks is reduced, lowering their companiesâ bandwidth consumption. In addition, it lessens the load on Docker Hubâs infrastructure, which benefits the overall DevOps community.
It sounds cool. Useful. Punchy. Everyone loves words like âproductivity,â âfaster,â and âoptimized.â If you like the sound of all of this but arenât super sure what it actually means or how to implement it, Iâm here to help!
Whatâs a Docker registry pull-through cache?
In the context of Docker, a pull-through cache is a registry that acts as an intermediary between you and Docker Hub. A pull-through cache is self-populating; that is, if you attempt to pull an image from the cache that it doesnât already have, it will go get it from Docker Hub for you, cache a copy, and then hand it over to you. From then on, all requests for that image come from your cache first, rather than straight from Docker Hub.
Neat. Why would I want to do that though?
Speed and resource management. If you have a bunch of different things pulling that image, going out to Docker Hub every time is a lot of internet traffic. With a local pull-through cache, the request doesnât have to go out to Docker Hub unless you try to pull an image tag that your cache doesnât have. Thereâs also a security aspect to this, since youâre now in control of your dependencies.
Since you are now only pulling an image from Docker Hub when you request something that doesnât exist in your pull-through cache, it will take much longer for you to hit Docker Hubâs rate limits, whether youâre pulling anonymously or have your pull-through cache configured to authenticate with Docker Hub.
What does JFrog Artifactory have to do with this?
Simply using a pull-through cache, regardless of the registry you use to do it, means you get more mileage out of Docker Hubâs rate limit on image pulls. However, because of our fancy new partnership with Docker, using Artifactory as your pull-through cache means youâre completely exempt from Docker Hubâs rate limiting. Pull to your heartâs content. Or your CIâs content, whatever.
Rad. How do I set that up?
In Artifactory, youâll need Docker repositories. The Quick Setup wizard will automatically create three of them for you: docker-local (for your images), docker-remote (the pull-through cache), and docker (a virtual repository that kind of acts as an envelope around your local and remote repositories).
To treat Artifactory as a pull-through cache, from here, make your requests against the virtual repository. For example, if I wanted to pull a specific version of Ubuntu, I would do this:
docker pull katc.jfrog.io/docker/ubuntu:16:04
To break that down a bit, katc.jfrog.io is the address of my JFrog platform, docker is the name of my virtual repository, ubuntu is the image I want, and 16.04 is the specific tag.
When that command runs, it will first check my Docker repositories in Artifactory for a matching image and tag. If it isnât there, Artifactory will go out and pull it from Docker Hub for me, cache it in the docker-remote repository, then serve it to me. No additional configuration is required for this behavior, and because weâve partnered with Docker, the request wonât count against your rate limit whether your remote repository is authenticated with Docker Hub or not. Cool, right? This partnership does also apply to the cloud free tier of the JFrog Platform -- sign up here to see for yourself!
Top comments (0)