Skip to content

Commit 0a483e0

Browse files
denreadenrea
authored
Merge pull request #269838 from anthonychu/20240321-aca-dotnet-guide
[Container Apps] Add .NET overview
2 parents d818278 + 3503810 commit 0a483e0

File tree

2 files changed

+140
-2
lines changed

2 files changed

+140
-2
lines changed

‎articles/container-apps/TOC.yml

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -333,10 +333,12 @@
333333
items:
334334
- name: .NET
335335
items:
336-
- name: Deploy and scale an ASP.NET Core app
337-
href: /aspnet/core/host-and-deploy/scaling-aspnet-apps/scaling-aspnet-apps
336+
- name: Overview
337+
href: dotnet-overview.md
338338
- name: Deploy a .NET Aspire app
339339
href: /dotnet/aspire/deployment/azure/aca-deployment
340+
- name: Deploy and scale an ASP.NET Core app
341+
href: /aspnet/core/host-and-deploy/scaling-aspnet-apps/scaling-aspnet-apps
340342
- name: Java
341343
items:
342344
- name: Overview

‎articles/container-apps/dotnet-overview.md

Lines changed: 136 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,136 @@
1+
---
2+
title: .NET on Azure Container Apps overview
3+
description: Learn about the tools and resources needed to run .NET and ASP.NET Core applications on Azure Container Apps.
4+
services: container-apps
5+
author: craigshoemaker
6+
ms.service: container-apps
7+
ms.topic: conceptual
8+
ms.date: 06/13/2024
9+
ms.author: cshoe
10+
---
11+
12+
# .NET on Azure Container Apps overview
13+
14+
To deploy a .NET application to a cloud native environment like Azure Container Apps, there are decisions you need to make to ensure your application runs smoothly and securely. This guide covers key concepts involved in deploying a .NET application to Azure Container Apps.
15+
16+
Azure Container Apps is a fully managed serverless container service that allows you to run containerized applications without having to manage the underlying infrastructure. Container Apps includes built-in support for features including autoscaling, health checks, and transport layer security (TLS) certificates.
17+
18+
This article details the concepts and concerns important to you as you deploy a .NET application on Azure Container Apps.
19+
20+
## Select a resource type
21+
22+
Container Apps supports two types of resources: apps and jobs. Apps are continuously running services, while jobs are short-lived tasks designed to run to completion.
23+
24+
As you prepare to deploy your app, consider differences between these two application types as their behavior affects how you manage your .NET application. The following table describes the difference in use cases between and jobs.
25+
26+
| Use case | Resource type |
27+
|-------------|---------------|
28+
| An ASP.NET Core web API that serves HTTP requests | App |
29+
| A .NET Core console application that processes some data, then exits | Job |
30+
| A continuously running background service that processes messages from a queue | App |
31+
| An image optimization service that runs only when large images are saved to a storage account. | Job |
32+
| An application using a framework like Hangfire, Quartz.NET, or the Azure WebJobs SDK | App |
33+
34+
## Containerize and deploy your .NET application
35+
36+
For both apps or jobs, you need to build a container image to package your .NET application. For more information on building container image, see [Docker images for ASP.NET Core](/aspnet/core/host-and-deploy/docker/building-net-docker-images).
37+
38+
Once set up, you can deploy your application to Azure Container Apps by following these guides:
39+
40+
* [Tutorial: Deploy to Azure Container Apps using Visual Studio](deploy-visual-studio.md)
41+
* [Quickstart: Build and deploy from a repository to Azure Container Apps](quickstart-repo-to-cloud.md)
42+
* [Create a job with Azure Container Apps](jobs-get-started-cli.md)
43+
44+
## Use the HTTP ingress
45+
46+
Azure Container Apps includes a built-in HTTP ingress that allows you to expose your apps to traffic coming from outside the container. The Container Apps ingress sits between your app and the end user. Since the ingress acts as an intermediary, whatever the end user sees ends at the ingress, and whatever your app sees begins at the ingress.
47+
48+
The ingress manages TLS termination and custom domains, eliminating the need for you to manually configure them in your app. Through the ingress, port `443` is exposed for HTTPS traffic, and optionally port `80` for HTTP traffic. The ingress forwards requests to your app at its target port.
49+
50+
If your app needs metadata about the original request, it can use [X-forwarded headers](#define-x-forwarded-headers).
51+
52+
To learn more, see [HTTP ingress in Azure Container Apps](ingress.md).
53+
54+
### Define a target port
55+
56+
To receive traffic, the ingress is configured on a target port where your app listens for traffic.
57+
58+
When ASP.NET Core is running in a container, the application listens to ports as configured in the container image. When you use the [official ASP.NET Core images](/aspnet/core/host-and-deploy/docker/building-net-docker-images), your app is configured to listen to HTTP on a default port. The default port depends on the ASP.NET Core version.
59+
60+
| Runtime | Target port |
61+
|---|---|
62+
| ASP.NET Core 7 and earlier | `80` |
63+
| ASP.NET Core 8 and later | `8080` |
64+
65+
When you configure the ingress, set the target port to the number corresponding to the container image you're using.
66+
67+
### Define X-forwarded headers
68+
69+
As the ingress handles the original HTTP request, your app sees the ingress as the client. There are some situations where your app needs to know the original client's IP address or the original protocol (HTTP or HTTPS). You can access the protocol and IP information via the request's [`X-Forwarded-*` header](ingress-overview.md#http-headers).
70+
71+
You can read original values from these headers by accessing the `ForwardedHeaders` object.
72+
73+
```csharp
74+
builder.Services.Configure<ForwardedHeadersOptions>(options =>
75+
{
76+
options.ForwardedHeaders =
77+
ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
78+
options.KnownNetworks.Clear();
79+
options.KnownProxies.Clear();
80+
});
81+
```
82+
83+
For more information on working with request headers, see [Configure ASP.NET Core to work with proxy servers and load balancers](/aspnet/core/host-and-deploy/proxy-load-balancer).
84+
85+
## Build cloud-native .NET applications
86+
87+
Applications deployed to Container Apps often work best when you build on the foundations of [cloud-native principles](/dotnet/architecture/cloud-native/definition). The following sections help detail common concerns surrounding cloud-native applications.
88+
89+
### Application configuration
90+
91+
When deploying your .NET application to Azure Container Apps, use environment variables for storing configuration information instead of using *appsettings.json*. This practice allows you to configure your application in different ways in differing environments. Additionally, using environment variables makes it easier to manage configuration values without having to rebuild and redeploy your container image.
92+
93+
In Azure Container Apps, you [set environment variables](./environment-variables.md) when you define your app or job's container. Store sensitive values in secrets and reference them as environment variables. To learn more about managing secrets, see [Manage secrets in Azure Container Apps](manage-secrets.md).
94+
95+
### Managed identity
96+
97+
Azure Container Apps supports managed identity, which allows your app to access other Azure services without needing to exchange credentials. To learn more about securely communicating between Azure services, see [Managed identities in Azure Container Apps](managed-identity.md).
98+
99+
### Logging
100+
101+
In a cloud-native environment, logging is crucial for monitoring and troubleshooting your applications. By default, Azure Container Apps uses Azure Log Analytics to collect logs from your containers. You can configure other logging providers. To learn more about application logging, see [Log storage and monitoring options in Azure Container Apps](log-options.md).
102+
103+
When you configure a [logging provider](/aspnet/core/fundamentals/logging/) that writes logs to the console, Azure Container Apps collects and stores log messages for you.
104+
105+
### Health probes
106+
107+
Azure Container Apps includes built-in support for health probes, which allow you to monitor the health of your applications. If a probe determines your application is in an unhealthy state, then your container is automatically restarted. To learn more about health probes, see [Health probes in Azure Container Apps](health-probes.md).
108+
109+
For a chance to implement custom logic to determine the health of your application, you can configure a health check endpoint. To learn more about health check endpoints, see [Health checks in ASP.NET Core](/aspnet/core/host-and-deploy/health-checks).
110+
111+
### Autoscaling considerations
112+
113+
By default, Azure Container Apps automatically scales your ASP.NET Core apps based on the number of incoming HTTP requests. You can also configure custom autoscaling rules based on other metrics, such as CPU or memory usage. To learn more about scaling, see [Set scaling rules in Azure Container Apps](scale-app.md).
114+
115+
Autoscaling changes the number of replicas of your app based on the rules you define. By default, Container Apps randomly routes incoming traffic to the replicas of your ASP.NET Core app. Since traffic can split among different replicas, your app should be stateless so your application doesn't experience state-related issues.
116+
117+
Features such as anti-forgery, authentication, SignalR, Blazor Server, and Razor Pages depend on data protection require extra configuration to work correctly when scaling to multiple replicas.
118+
119+
#### Configure data protection
120+
121+
ASP.NET Core has special features protect and unprotect data, such as session data and anti-forgery tokens. By default, data protection keys are stored on the file system, which isn't suitable for a cloud-native environment.
122+
123+
If you're deploying a .NET Aspire application, data protection is automatically configured for you. In all other situations, you need to [configure data protection manually](/aspnet/core/host-and-deploy/scaling-aspnet-apps/scaling-aspnet-apps?view=aspnetcore-8.0&tabs=login-azure-cli&preserve-view=true#connect-the-azure-services).
124+
125+
#### Configure ASP.NET Core SignalR
126+
127+
ASP.NET Core SignalR requires a backplane to distribute messages to multiple server replicas. When deploying your ASP.NET Core app with SignalR to Azure Container Apps, you must configure one of the supported backplanes, such as Azure SignalR Service or Redis. To learn more about backplanes, see [ASP.NET Core SignalR hosting and scaling](/aspnet/core/signalr/scale).
128+
129+
#### Configure Blazor Server
130+
131+
ASP.NET Core Blazor Server apps store state on the server, which means that each client must be connected to the same server replica during their session. When deploying your Blazor Server app to Azure Container Apps, you must enable sticky sessions to ensure that clients are routed to the same replica. To learn more, see [Session Affinity in Azure Container Apps](sticky-sessions.md).
132+
133+
## Related information
134+
135+
* [Deploy a .NET Aspire app](/dotnet/aspire/deployment/azure/aca-deployment)
136+
* [Deploy and scale an ASP.NET Core app](/aspnet/core/host-and-deploy/scaling-aspnet-apps/scaling-aspnet-apps)

0 commit comments

Comments
 (0)