Pular para o conteúdo
Docs Try Aspire

Customize Azure Container Apps

Este conteúdo não está disponível em sua língua ainda.

When you deploy to Azure Container Apps using aspire deploy, Aspire provisions infrastructure automatically based on the resources defined in your AppHost. While the defaults work for many scenarios, you often need to customize the generated infrastructure—scaling rules, custom domains, resource groups, role assignments, and more.

This page covers the most common customization options for Azure Container Apps deployments. For hosting-side configuration of the Container Apps environment, see Configure Azure Container Apps.

Customize a Container App with PublishAsAzureContainerApp

Section titled “Customize a Container App with PublishAsAzureContainerApp”

Use PublishAsAzureContainerApp to customize the generated Container App resource for any project, container, or executable in your AppHost. The callback gives you access to the AzureResourceInfrastructure and the ContainerApp construct, allowing you to modify any property of the generated resource.

AppHost.cs
var builder = DistributedApplication.CreateBuilder(args);
builder.AddAzureContainerAppEnvironment("env");
builder.AddProject<Projects.Api>("api")
.PublishAsAzureContainerApp((infrastructure, app) =>
{
// Customize the Container App
app.Template.Scale.MinReplicas = 1;
app.Template.Scale.MaxReplicas = 10;
});
builder.Build().Run();

The infrastructure parameter provides access to the overall Azure resource infrastructure, while the app parameter represents the ContainerApp construct. You can modify scaling, ingress, environment variables, and other settings directly.

For more information, see Publish as Azure Container App.

Use ConfigureCustomDomain to set up custom domains on Container Apps. This lets you bind a custom DNS name and a managed certificate to your Container App.

AppHost.cs
var customDomain = builder.AddParameter("customDomain");
var certificateName = builder.AddParameter("certificateName");
#pragma warning disable ASPIREACADOMAINS001
builder.AddProject<Projects.Api>("api")
.PublishAsAzureContainerApp((infrastructure, app) =>
{
ContainerAppExtensions.ConfigureCustomDomain(
app, customDomain, certificateName);
});
#pragma warning restore ASPIREACADOMAINS001

When you have Azure resources that already exist—such as a shared Service Bus namespace or a database server—you can reference them instead of having Aspire provision new ones. Aspire provides three APIs for this:

  • AsExisting — use the existing resource in both local development and deployment.
  • RunAsExisting — use the existing resource during local development only.
  • PublishAsExisting — use the existing resource during deployment only.
AppHost.cs
var existingBusName = builder.AddParameter("existingServiceBusName");
var existingBusRg = builder.AddParameter("existingServiceBusResourceGroup");
var serviceBus = builder.AddAzureServiceBus("messaging")
.PublishAsExisting(existingBusName, existingBusRg);

When you reference an existing resource, Aspire skips provisioning for that resource and instead configures your application to connect to the specified instance.

By default, all Azure resources deploy to the same resource group created by the environment. Use WithResourceGroup on the AzureEnvironmentResource to set the resource group for the deployment:

AppHost.cs
builder.AddAzureEnvironment()
.WithResourceGroup(builder.AddParameter("resourceGroup"));

Aspire automatically assigns Azure RBAC roles for resources based on how they’re referenced. For example, a project that references an Azure Service Bus resource is automatically granted the Azure Service Bus Data Sender role.

To remove the default role assignments for a resource, use ClearDefaultRoleAssignments:

AppHost.cs
builder.AddAzureServiceBus("messaging")
.ClearDefaultRoleAssignments();

Custom role assignments can be configured via ConfigureInfrastructure.

For more information, see Manage Azure role assignments.

Services deployed to Azure Container Apps use internal DNS for service discovery. HTTP and HTTPS endpoints are both available by default for internal communication between container apps.

To expose an endpoint externally (outside the Container Apps environment), use WithExternalHttpEndpoints():

AppHost.cs
builder.AddProject<Projects.Api>("api")
.WithExternalHttpEndpoints();