इसे छोड़कर कंटेंट पर जाएं
Docs Try Aspire
Docs Try

Set up Azure Container Registry in the AppHost

यह कंटेंट अभी तक आपकी भाषा में उपलब्ध नहीं है।

Azure Container Registry logo

This article is the reference for the Aspire Azure Container Registry Hosting integration. It enumerates the AppHost APIs — with examples for both AppHost.cs and apphost.ts — that you use to model an Azure Container Registry resource in your AppHost project.

If you’re new to the Azure Container Registry integration, start with the Get started with Azure Container Registry integrations guide. For how the registry is consumed at deployment time — including the loginServer output — see Connect to Azure Container Registry.

To start building an Aspire app that uses Azure Container Registry, install the 📦 Aspire.Hosting.Azure.ContainerRegistry NuGet package:

Terminal
aspire add Aspire.Hosting.Azure.ContainerRegistry

Learn more about aspire add in the command reference.

Or, choose a manual installation approach:

C# — AppHost.cs
#:package Aspire.Hosting.Azure.ContainerRegistry@*
XML — AppHost.csproj
<PackageReference Include="Aspire.Hosting.Azure.ContainerRegistry" Version="*" />

Once you’ve installed the hosting integration in your AppHost project, add an Azure Container Registry resource and wire it to a compute environment:

C# — AppHost.cs
var builder = DistributedApplication.CreateBuilder(args);
var acr = builder.AddAzureContainerRegistry("my-acr");
builder.AddAzureContainerAppEnvironment("env")
.WithAzureContainerRegistry(acr);
builder.Build().Run();
  1. The registry resource is modeled as an AzureContainerRegistryResource in the Aspire resource graph.

  2. Calling WithAzureContainerRegistry (or withAzureContainerRegistry) on the compute environment attaches the registry and provisions the necessary role assignments and managed-identity bindings so the environment can pull images securely.

  3. At deployment time, the generated Bicep provisions the registry and outputs its name and loginServer for use by the deployment pipeline.

Get the registry from a compute environment

Section titled “Get the registry from a compute environment”

To retrieve the registry that is associated with a compute environment — for example, to add purge tasks to the auto-provisioned default registry — use GetAzureContainerRegistry (or getAzureContainerRegistry):

C# — AppHost.cs
var builder = DistributedApplication.CreateBuilder(args);
var env = builder.AddAzureContainerAppEnvironment("env");
// Retrieve the default auto-provisioned registry
var registry = env.GetAzureContainerRegistry();

This returns an AzureContainerRegistryResource builder that you can use for further configuration, such as scheduling image cleanup with purge tasks.

To reference a registry your team already manages rather than provisioning a new one, use publishAsExisting, runAsExisting, or asExisting:

Use PublishAsExisting to reference an existing registry only in publish (deployment) mode:

C# — AppHost.cs
var builder = DistributedApplication.CreateBuilder(args);
var registryName = builder.AddParameter("registryName");
var rgName = builder.AddParameter("rgName");
var acr = builder.AddAzureContainerRegistry("my-acr")
.PublishAsExisting(registryName, rgName);
builder.AddAzureContainerAppEnvironment("env")
.WithAzureContainerRegistry(acr);
builder.Build().Run();

Use AsExisting to reference an existing registry in both run and publish modes:

C# — AppHost.cs
var acr = builder.AddAzureContainerRegistry("my-acr")
.AsExisting(name: builder.AddParameter("registryName"),
options: new() { ResourceGroup = builder.AddParameter("rgName") });

Use WithRoleAssignments (or withRoleAssignments) to grant an Azure resource fine-grained access to the registry. The ContainerRegistryBuiltInRole enum (TypeScript: AzureContainerRegistryRole) covers the standard ACR roles:

C# — AppHost.cs
var builder = DistributedApplication.CreateBuilder(args);
var acr = builder.AddAzureContainerRegistry("my-acr");
// Grant the 'api' project permission to push images
builder.AddProject<Projects.Api>("api")
.WithRoleAssignments(acr, ContainerRegistryBuiltInRole.AcrPush);
builder.Build().Run();

Available roles include: AcrPull, AcrPush, AcrDelete, AcrImageSigner, AcrQuarantineReader, and AcrQuarantineWriter.

Over time, container registries accumulate old images that consume storage. Use WithPurgeTask (or withPurgeTask) to add a scheduled ACR purge task that automatically removes old or unused images:

C# — AppHost.cs
var builder = DistributedApplication.CreateBuilder(args);
var acr = builder.AddAzureContainerRegistry("my-acr")
.WithPurgeTask("0 1 * * *", ago: TimeSpan.FromDays(7), keep: 5);
builder.Build().Run();

The preceding code creates a purge task that runs daily at 1:00 AM, removing images older than 7 days while keeping the 5 most recent images per repository. The C# ago parameter accepts a TimeSpan; the TypeScript ago option accepts milliseconds.

Add multiple purge tasks to target different repositories with different schedules:

C# — Multiple purge tasks
var acr = builder.AddAzureContainerRegistry("my-acr")
.WithPurgeTask("0 1 * * *", filter: "app1:.*", keep: 3)
.WithPurgeTask("0 2 * * 0", filter: "app2:.*", ago: TimeSpan.FromDays(30), keep: 10);

Each purge task is given a unique name automatically. Use the taskName option to specify a custom task name.

To make changes that go beyond what the built-in APIs expose, configure the underlying Bicep infrastructure directly via ConfigureInfrastructure (or configureInfrastructure):

C# — AppHost.cs
var acr = builder.AddAzureContainerRegistry("my-acr")
.ConfigureInfrastructure(infra =>
{
var registry = infra.GetProvisionableResources()
.OfType<ContainerRegistry>()
.Single();
registry.Sku = new ContainerRegistrySku { Name = ContainerRegistrySkuName.Premium };
});

If you’re new to Bicep, it’s a domain-specific language for defining Azure resources. With Aspire, you don’t need to write Bicep by hand — the provisioning APIs generate Bicep for you. When you publish your app, the generated Bicep is output alongside the manifest file. When you add an Azure Container Registry resource, the following Bicep is generated:

my-acr.module.bicep
@description('The location for the resource(s) to be deployed.')
param location string = resourceGroup().location
resource my_acr 'Microsoft.ContainerRegistry/registries@2023-07-01' = {
name: take('myacr${uniqueString(resourceGroup().id)}', 50)
location: location
sku: {
name: 'Basic'
}
tags: {
'aspire-resource-name': 'my-acr'
}
}
output name string = my_acr.name
output loginServer string = my_acr.properties.loginServer

The generated Bicep outputs the registry name and loginServer (the registry endpoint used for image push/pull). These outputs are referenced by the compute environment’s Bicep and by your deployment pipeline.

When you attach a registry to an Azure Container Apps environment, the environment’s generated Bicep references the registry outputs and creates the required AcrPull role assignment on the managed identity:

env.module.bicep (excerpt)
param my_acr_outputs_name string
resource my_acr 'Microsoft.ContainerRegistry/registries@2023-07-01' existing = {
name: my_acr_outputs_name
}
resource my_acr_env_mi_AcrPull 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
name: guid(my_acr.id, env_mi.id, subscriptionResourceId('Microsoft.Authorization/roleDefinitions', '7f951dda-4ed3-4680-a7ca-43fe172d538d'))
properties: {
principalId: env_mi.properties.principalId
roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', '7f951dda-4ed3-4680-a7ca-43fe172d538d')
principalType: 'ServicePrincipal'
}
scope: my_acr
}

The generated Bicep is a starting point and is influenced by changes to the provisioning infrastructure in C#. Customizations to the Bicep file directly are overwritten, so make changes through the C# provisioning APIs (or configureInfrastructure) to ensure they’re reflected in the generated files.