acr
acr copied to clipboard
Azure
Pull through caching
What is the problem you're trying to solve With Docker licensing and rate limiting changes, we are interested in using our ACR instance to mirror our base images. The current solution seems to be manually importing base images into ACR and creating an ACR task to pull in base image updates.
Describe the solution you'd like Ability to use ACR as a pull through cache similar to what was added to AWS. For us, this would help with the Docker changes and save us work from manually importing and updating the base images.
https://aws.amazon.com/blogs/aws/announcing-pull-through-cache-repositories-for-amazon-elastic-container-registry/
It would be much better to support multiple public registries, including major ones ghcr.io, quay.io, docker.io and gcr.io as Images from these major registries needs to be imported to private registry for image scanning and firewall restriction reasons
Hi @jsheetzati and @logamanig, your wish is ours also -- we need this as well as you. There will be early this fall the ability to configure an ACR registry to become an automatic cache, initially with Docker Hub content but shortly thereafter with MCR and other registries. Look for "artifact and image management" features.
There IS a good thing you can do now to prepare for the future, and that is to get yourself a docker subscription -- a free one will do for now. This will likely mitigate against any rate limiting you might see, and going forward will enable us to synchronize Docker Hub library content with your ACR artifact & image management smoothly and without interruption.
In addition, we are doing some other work if you end up using your ACR instances to build from using upstream content like that from Docker Hub. We have built a modification into buildkit so that it will automatically generate a complete list of required images from any build using "dry run", and then you can modify that generated file to point any of the listed images at another registry (such as your new ACR artiface and image management registry). This will enable most but not all builds to continue working without modification against specific git commits if you don't have the immediate ability to modify them.
The modification should be an upstream PR very shortly, possibly within a month or two, and will be available to everyone.
In short, we're working hard to create solid solutions here, because just like you we also are building and deploying in a rapidly changing world. :-)
Is there any update on this, it'd sure come in handy and solve some very large problems for me.
Yes, @tssgery apologies on the slow delivery here. We had to work through some authentication issues as well as other challenges, but we are getting ready for preview by the end of January. We regret the delay, of course.
Do you have a scenario you can describe here? I'd love to ensure it'll be picked up by what we're doing here.
Something that we want(ed) to do is a repository for container images that we can then pass on to other environments.
The idea was to create a single central acr used as repository for internal golden images, as well as cache for external container registries like dockerhub or mcr. In addition to the central registry, each project/dev environment/etc. has an additional local registry that's configured to pull everything from the central one.
That way dev teams can upload their in-development images to their own isolated container registry while still having access to approved company images and images from external sources.
In addition, that makes it easier to control what external images are being used, e.g. by configuring the central repository to only allow pulling from verified uploaders.
Nothing that couldn't technically be done with separate registries, but having just a single source of truth to moderate makes things much easier.
This is, essentially, precisely one thing you'll get in late January, @mmuffins. You'll get other nice features as well. Keep an eye out for the announcement.
@squillace But you do not talk about connected registries, where all images are sync into the own ACR?
Apologies. For
For @jkroepke, the answer is that connected registries will not be able to make use of this immediately, but we've queued that ability for a future release. It's a tad trickier scenario that it at first appears.
Adding on that I'm extremely interested in this feature as well for my company. Looking forward to the announcement! Should we watch an additional place for the release notes?
You can watch here, but there will be a big blog post and a customer email announcement as well.
Hi all, look for our new feature announcement tomorrow. I will update this thread with links at that time. I'd really like to hear from everyone who tries it and collect as much feedback as possible, as we'll be iterating this feature rapidly to ensure we're hitting the high notes.
As yesterday came and went without any announcement, I guess the new documentation is https://learn.microsoft.com/en-us/azure/container-registry/tutorial-registry-cache … which unfortunately doesn't help me, because it currently excludes private registries. :disappointed:
https://techcommunity.microsoft.com/t5/apps-on-azure-blog/announcing-public-preview-of-caching-for-acr/ba-p/3744655
@hho, we just had to touch one little thing, which pushed it to this morning PST.
@hho what do you mean, https://github.com/Azure/acr/issues/599#issuecomment-1433495512 excludes private networks? It explicitly supports private networks.
But "support" in this case means it's transparent. You do not need to enable anything directly; just create a private network ACR, set up your cache rules, and inside that private network from the ACR instance cached repo. It should work fine.
@@@@@NOTE: You must pull once to "hydrate" the image. It doesn't arrive automatically. You are in control of pulling the images into the cache. But once there, your next pull comes directly from that ACR cached image.@@@@@@@
@squillace Thanks for the update!
I wasn't talking about networks at all, I'm only referring to the preview's limitation of not supporting our own registry.
Ah, @hho, I'd call them "custom" or "self-hosted registries" as there are a LOT of possibilities there. We have customers who are waiting on this support, which I expect to come rapidly now that we have the platform. Do you have a specific one in mind we should test against?
@squillace That's great news! I'd be most interested in JFrog Artifactory (currently on-prem, but they also have a cloud offering you could test against).
JFrog is already one of the leading candidates suggested by other customers, so we'll definitely have that in the first list of support! I'll update this when I have clearer ideas of the next wave.
From the docs I guess you cannot do caching of another ACR registry (ie. in another region)?
not yet; ACR support will be in the next iteration. We have people who would like to chain cache instances of ACR for various departments and so on.
Happy to see quay.io and ghcr.io Support, since a lot of upstream images are not longer using Docker Hub anymore, e.g Prometheus Community.
Just to throw in my opinion as well... Privately hosted JFrog Artifactory instances are our most important need now that docker.io support is in place.
Really nice to see this feature!
I'm also really happy seeing that you mention support for ghcr and quay, but is there a slightly more specific ETA for other registries? I would love to see quay and ghcr before May. Is that realistic?
Nice to see this feature. Right now, you need to configure each image you want to cache with a rule (up to 50) them the system do this automatically for you.
Could be possible to configure as a proxy-caché system? Trying to download the image from CR if found, otherwise search the image on external repositories and cache it in the CR for future downloads. This is available on other tools like sonatype nexus since long time ago.
I'm also really happy seeing that you mention support for ghcr and quay, but is there a slightly more specific ETA for other registries? I would love to see quay and ghcr before May. Is that realistic?
Dear @diegopasten, no, not quite realistic. June, however..... as in early June.... is our objective for quay. We will update here if we have anything get in the way of that schedule.