Deploy .NET 8 Minimal APIs on Azure Container Apps with Dapr Sidecar

Mahmut Sarıkaya 4 dk okuma 6 Görüntülenme 0
Deploy .NET 8 Minimal APIs on Azure Container Apps with Dapr Sidecar

Why containerize Minimal APIs for cloud‑native workloads?

Enterprises are moving 70% of new services to containers, according to the 2024 Cloud Native Survey. Minimal APIs introduced in .NET 6, now refined in .NET 8, give you a lean HTTP surface with less boilerplate. When you wrap that surface in a container, you gain instant scalability, isolated dependencies, and the ability to run the same image on Azure Container Apps, Kubernetes, or local dev clusters.

Preparing the .NET 8 Minimal API

Start with a fresh .NET 8 console project and enable the minimal hosting model. The following Program.cs defines a simple WeatherForecast endpoint and registers Dapr client services for later use.

using Microsoft.AspNetCore.Builder; using Microsoft.Extensions.DependencyInjection; using Dapr.Client; var builder = WebApplication.CreateBuilder(args); builder.Services.AddDaprClient(); var app = builder.Build(); app.MapGet("/weather", async (DaprClient dapr) => { var forecasts = new[] { new { Date = DateTime.UtcNow.AddDays(1), TemperatureC = 22, Summary = "Sunny" }, new { Date = DateTime.UtcNow.AddDays(2), TemperatureC = 18, Summary = "Cloudy" } }; // Example of invoking another Dapr‑enabled service return await dapr.InvokeMethodAsync<object>(HttpMethod.Get, "weather-service", "forecast"); }).WithName("GetWeather"); app.Run();

Notice the use of builder.Services.AddDaprClient(). This injects a typed Dapr client that can call other services without hard‑coding URLs, making service invocation truly location‑agnostic.

Adding Dapr sidecar and service invocation

Dapr runs as a sidecar container alongside your app. The sidecar handles service discovery, state management, and pub/sub. Define a components folder with a simple statestore.yaml that uses Azure Cosmos DB (or any supported store). The sidecar reads this file at startup.

apiVersion: dapr.io/v1alpha1 kind: Component metadata: name: statestore namespace: default spec: type: state.azure.cosmosdb version: v1.0 metadata: - name: url value: "https://mycosmos.documents.azure.com:443/" - name: masterKey value: "" - name: database value: "mydb" - name: collection value: "mycol" 

When you call dapr.InvokeMethodAsync from the API, Dapr resolves the target service name (weather-service) using its internal DNS, so you never hard‑code http://localhost:5000 or a public endpoint.

Deploying to Azure Container Apps

Azure Container Apps (ACA) abstracts the underlying Kubernetes cluster, letting you focus on the container image and scaling rules. First, push the Docker image to Azure Container Registry (ACR).

az login az account set --subscription "MySubscription" az acr login --name myregistry docker build -t myregistry.azurecr.io/minimalapi:latest . docker push myregistry.azurecr.io/minimalapi:latest

Next, create the ACA environment and the app with Dapr enabled.

az containerapp env create --name myenv --resource-group rg-demo --location eastus az containerapp create --name minimalapi --resource-group rg-demo --environment myenv --image myregistry.azurecr.io/minimalapi:latest --cpu 0.5 --memory 1.0Gi --min-replicas 1 --max-replicas 5 --enable-dapr --dapr-app-id minimalapi --dapr-app-port 80

The --enable-dapr flag automatically injects the sidecar. You can also attach the components folder by mounting a volume or using a Git repo reference in the ACA configuration.

Testing the end‑to‑end flow

After deployment, retrieve the fully qualified domain name (FQDN) of the app and issue a request with curl. The Dapr sidecar will forward the call to any other Dapr‑enabled service registered in the same ACA environment.

curl https://minimalapi.eastus.azurecontainerapps.io/weather

If you have a second service called weather-service deployed in the same environment, the first API will invoke it through Dapr, and you will see a combined JSON payload. This demonstrates seamless service invocation without network‑level configuration.

Best practices and troubleshooting

1. **Version pinning** – Always target a specific .NET 8 SDK version (e.g., 8.0.100) in your global.json to avoid breaking changes.
2. **Health probes** – ACA supports Liveness and Readiness probes; configure them to point at /healthz in your minimal API to enable auto‑scaling.
3. **Observability** – Enable Dapr metrics (`--dapr-config` with Prometheus) and forward them to Azure Monitor for end‑to‑end tracing.
4. **Secret management** – Store connection strings (e.g., Cosmos DB key) in Azure Key Vault and reference them via secretStore component, never in plain text.

If a call fails with a 502 error, check the Dapr sidecar logs (`az containerapp logs show … --container dapr`) for DNS resolution issues. Often the problem is a mismatched dapr-app-id between caller and callee.

Conclusion

Deploying a .NET 8 Minimal API to Azure Container Apps with a Dapr sidecar gives you a production‑ready stack that abstracts networking, provides built‑in observability, and scales on demand. By following the steps above—building the image, enabling Dapr, configuring components, and leveraging ACA’s managed scaling—you can deliver microservices that communicate via service invocation without writing any custom discovery code.

Sources

Microsoft Docs – Azure Container Apps documentation; Dapr.io – Official Dapr documentation; .NET Blog – .NET 8 release notes.

Author: Mahmut Sarıkaya — sarikayadev.com

Etiketler: #dotnet 8 #minimal APIs #azure container apps #dapr #service invocation
Paylaş:
M

Yazar

Mahmut Sarıkaya

yazılım Geliştirici

Yorumlar

Henüz yorum yok. İlk yorumu siz yapın!

Yorum Bırakın

1 + 3 =