Skip to content

Document AZD's strategies for Azure Container Apps #5216

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
121 changes: 121 additions & 0 deletions cli/azd/docs/container-app-strategies.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,121 @@
# Azure Container Apps Strategies in AZD

Azure Developer CLI (AZD) provides multiple strategies to provision and deploy applications to [Azure Container Apps](https://learn.microsoft.com/en-us/azure/container-apps/overview). This document outlines these strategies, including when to use them and how they work.

## Strategy 1: container-app-upsert

The `container-app-upsert` strategy is a Bicep-based approach for creating or updating Azure Container Apps. It's a flexible approach that works well for many different types of container applications.

### How it works

The `container-app-upsert` strategy:

1. Uses a Bicep module (`container-app-upsert.bicep`) that detects whether a Container App already exists
2. If the Container App exists, it updates the existing app while preserving its current container image if no new image is specified
3. If the Container App doesn't exist, it creates a new one with the specified parameters

This approach is commonly used in AZD templates, such as the Todo application templates (nodejs-mongo-aca, python-mongo-aca, etc.).

### When to use it

Use the `container-app-upsert` strategy when:

- You want the ability to incrementally update your Container App without replacing it entirely
- You need to preserve certain settings during updates
- You're working with standard container applications that aren't based on the .NET Aspire framework
- You want a pattern that supports composability across multiple services

### Example

Here's how to use the `container-app-upsert` strategy in your Bicep files:

```bicep
module api 'br/public:avm/ptn/azd/container-app-upsert:0.1.1' = {
name: 'api'
params: {
name: 'my-api'
location: location
containerAppsEnvironmentName: containerAppsEnvironment.name
containerRegistryName: containerRegistry.name
imageName: !empty(apiImageName) ? apiImageName : ''
exists: apiExists
env: [
{
name: 'MONGODB_CONNECTION_STRING'
value: mongodb.outputs.connectionString
}
]
targetPort: 3100
}
}
```

In this example:
- `exists` parameter determines whether to update an existing app or create a new one
- `imageName` uses the `!empty()` function to conditionally specify a new image or keep the existing one
- Application settings are provided via the `env` parameter

## Strategy 2: delay-deployment (.NET Aspire)

The `delay-deployment` strategy is specifically designed for .NET Aspire applications. It postpones full container app creation until deployment time, which allows for more flexibility with .NET Aspire's orchestration model.

### How it works

The `delay-deployment` strategy:

1. Delays full provisioning of container resources until deployment time
2. Uses the .NET Aspire manifest to define container apps and their configurations
3. Supports two deployment approaches based on the manifest:
- Bicep-based deployment (when the manifest includes a deployment configuration)
- YAML-based deployment (direct Container Apps YAML deployment)
4. Handles special features like service binding and configuration sharing across Aspire components

When using .NET Aspire with AZD, the Aspire project generates a manifest that AZD uses during deployment. This approach allows for better integration with .NET Aspire's application model.

### When to use it

Use the `delay-deployment` strategy when:

- Working with .NET Aspire applications
- Your application has complex service relationships defined in the Aspire manifest
- You need integration with .NET Aspire's resource binding model
- You want to leverage .NET Aspire's application hosting capabilities

### Example

For .NET Aspire applications, AZD automatically uses the delay-deployment strategy when you specify `"containerapp-dotnet"` as the host type. Typically this is handled automatically when importing a .NET Aspire project.

When working with a .NET Aspire application:

1. Initialize your AZD project with a .NET Aspire application:

```bash
# This is typically done automatically by azd init for .NET Aspire projects
azd init
```

2. During provisioning, AZD will set up the necessary Azure resources but will delay full Container App configuration.

3. During deployment, AZD will:
- Build and publish the container images
- Apply the .NET Aspire manifest with proper configuration
- Configure service bindings between components

The delay-deployment strategy is primarily managed internally by AZD based on the .NET Aspire application structure.

## Choosing the Right Strategy

| Feature | container-app-upsert | delay-deployment (.NET Aspire) |
|---------|---------------------|------------------------------|
| Application type | Any containerized application | .NET Aspire applications |
| Configuration source | Bicep parameters | .NET Aspire manifest |
| Deployment timing | All configuration during provisioning | Container App specifics during deployment |
| Service binding | Manual configuration | Integrated with Aspire binding model |
| Best for | General container applications | .NET microservices orchestrated with Aspire |

## Additional Resources

- [Azure Container Apps Overview](https://learn.microsoft.com/en-us/azure/container-apps/overview)
- [Azure Container Apps Bicep Reference](https://learn.microsoft.com/en-us/azure/templates/microsoft.app/containerapps)
- [.NET Aspire Overview](https://learn.microsoft.com/en-us/dotnet/aspire/get-started/aspire-overview)
- [Todo Application Templates](https://github.com/Azure-Samples/todo-nodejs-mongo) (using container-app-upsert)