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)