Ce contenu n’est pas encore disponible dans votre langue.
The Aspire AppHost simplifies infrastructure provisioning by generating code to create Azure resources for your applications. This approach lets you model and configure deployment-related aspects directly in your AppHost, reducing the need to rely on tools like Bicep. These aspects include configuring ACA environments, which provide a serverless platform for running containerized applications.
Using the Aspire.Hosting.Azure.AppContainers integration, you can deploy compute resources to Azure Container Apps by adding an ACA environment with AddAzureContainerAppEnvironment. Use PublishAsAzureContainerApp only when you want to customize the generated Container App resource for a project, container, or executable — it does not create the ACA environment. Add an ACA environment first, then use the callback to customize the generated Container App resource.
By using the Azure.Provisioning APIs (explained in Customize Azure resources), you can configure and customize ACA environments along with related resources, such as container registries and file share volumes. Any available deployment setting can be configured. For more information on the available settings, see Microsoft.App managedEnvironments.
The AzureContainerAppEnvironmentResource type models an ACA environment resource. When you call the AddAzureContainerAppEnvironment method, it creates an instance of this type (wrapped in the IResourceBuilder<AzureContainerAppEnvironmentResource>).
A role assignment for the user principal ID to the ACA environment.
Various outputs for the ACA environment.
Using the acaEnv variable, you can chain a call to the ConfigureInfrastructure API to customize the ACA environment to your liking. For more information, see Configure infrastructure.
The callback receives an AzureResourceInfrastructure instance and the strongly-typed ContainerApp resource. This lets you set any property that Azure Container Apps supports — such as scaling rules, ingress settings, or environment variables — before the Bicep is generated.
By default, AddAzureContainerAppEnvironment uses a different Azure resource naming scheme than the Azure Developer CLI (azd). If you’re upgrading an existing deployment that previously used azd, you might see duplicate Azure resources. To avoid this issue, call the WithAzdResourceNaming method to revert to the naming convention used by azd:
All Azure resources are subclasses of the AzureProvisioningResource type. This enables customization of the generated Bicep by providing a fluent API to configure the Azure resources — using the ConfigureInfrastructure API: