Should we use one Azure Container Registry (ACR) for all the products in development or one ACR per product?

Question

We have started to spin off products off the one big monolith into Azure. A product could also be called a micro service.

A question that we have - should we have one Azure Container Registry (ACR) serving all the different products or should every product has its own ACR? We are talking about the development subscription only. In production we plan to have a different ACR or sets of ACRs to which the images will be imported from the development.

But the question is - what is the recommended way? If we treat ACR as an artifactory, then one is enough. After all, we have only one instance of Azure Artifacts (with several different feeds) where we push our nuget packages. Both nuget packages and docker images are build artifacts, so there is an argument that if we have just one nuget artifactory, why have multiple ACRs?

On the other hand, with Azure Artifacts we do not really have a choice - there is just one. So maybe we are missing some valid scenarios that can be enabled and even desired by having multiple ACRs.

Chrono

Answer 1

This question is a bit old but still relevant.

There are two approach for this problem :

1. use 1 registry for each environment e.g. dev,staging,prod
2. use 1 registry for all environment.

I recommend solution 2. You should see your container registry like you see your source code repository. You don't have 1 repository of code for each environment right ? The same goes for your container registry. The reason why is because the container registry should (must) contain your compiled source code and the basic infrastructure to run this. That's it. It's only the same thing has your code repository but pre-compiled/packaged. If your dev has access to your code repo, they basically have the same access to your container registry.

Multiple registry can be dangerous if you think of rebuilding your image each time you deploy to production. You may think that your image work in staging, you rebuild it for your prod registry, a dependencing changes and your break production. The mitigation for this is to download the container from staging and upload it to production. In my opinion, just use the container you just tested in staging and don't bother with download reuploading to the prod registry.

Multiple registry waste resources. You have a copy of all your image in all of your registry. Just use 1 registry.

One big registry makes it easier for security. You only have to scan one registry and you can integrate security much earlier in your deployment process (scan the staging image in advance because this is the container that you will deploy in prod).

If you create a lot of environment, it is very cumbersome to create new registry and change all your CI to push to this new registry. 1 registry solve this problem easy.

The only reason to use multiple container registry is because you have sensitive information in your container or you have environment specific config in your containers. If this is what you are doing, use multiple registry.

TL;DR; use one registry, there is no real benefit for multiple, not even security.

Valene

benefit = latency? my company deploys the same stack but to different regions. if, say, one stack is in Europe, and the common ACR is in Australia, latency might be noticeable. Unless the premium offerings of ACR has an edge computing feature? In this dummy example, the resource in Europe pulls an image from the ACR in the AU resource group, but the image is physically pulled from Europe? – Triennium

just answered my own question. yes indeed, there is a geo-replication feature. At a price though, only with the premium SKU learn.microsoft.com/en-us/azure/container-registry/… – Triennium

Answer 2

You can do it in both ways, According to the best practices docs you can have single container registry and manage them through namespaces and dedicated resource groups,

By leveraging repository namespaces, you can allow sharing a single registry across multiple groups within your organization. Registries can be shared across deployments and teams. Azure Container Registry supports nested namespaces, enabling group isolation.

For example, consider the following container image tags. Images that are used corporate-wide, like aspnetcore, are placed in the root namespace, while container images owned by the Products and Marketing groups each use their own namespaces.

• contoso.azurecr.io/aspnetcore:2.0
• contoso.azurecr.io/products/widget/web:1
• contoso.azurecr.io/products/bettermousetrap/refundapi:12.3
• contoso.azurecr.io/marketing/2017-fall/concertpromotions/campaign:218.42

Epicure

Answer 3

Having multiple container registries can help keeping failure domains separated. If you have a problem with the registry you use for developing and testing, you don't want that error in production.

That's why I would suggest using at least two container registries, where one is dedicated to production use. Configuring your non-production registry will be less dangerous. If you are confident in your configuration, and have thoroughly tested it, you can propagate that to production.

Comparing a package registry to a container registry has problems, as you are not relying on packages to be available for your production to run. However, if your workload is fully containerized, you are relying on container images to be available at all times.

Ramirez

I agree with Joe here. On my current project. We use 3 (non-prod, Prod .and a sandbox). Onces the Non-Prod gets an image pushed to it, and it passes all testing phases (regression, UAT, etc.) Then the image gets "promoted" to the Prod Registry (we use Azure so its an AZ IMPORT step). This way we know that Prod never accidently has untested images. – Sianna

az acr import - learn.microsoft.com/en-us/cli/azure/… This is how you can promote your tested/verified/approved image from non-prod ACR to a PROD ACR. – Sianna