From 69c9f52385edbb6db2f632726e0311f958b0b7b0 Mon Sep 17 00:00:00 2001 From: David Pine Date: Fri, 11 Jul 2025 08:51:06 -0500 Subject: [PATCH 1/3] Add details about how container networks are managed --- docs/architecture/overview.md | 6 ++++-- docs/fundamentals/networking-overview.md | 25 +++++++++++++++++++++++- 2 files changed, 28 insertions(+), 3 deletions(-) diff --git a/docs/architecture/overview.md b/docs/architecture/overview.md index 096f4617a8..a8983d06a3 100644 --- a/docs/architecture/overview.md +++ b/docs/architecture/overview.md @@ -1,7 +1,7 @@ --- title: .NET Aspire architecture overview description: Learn about the overall architecture of .NET Aspire, including its integrations, orchestration, and networking capabilities. -ms.date: 05/09/2025 +ms.date: 07/11/2025 --- # .NET Aspire architecture overview @@ -165,7 +165,9 @@ Continuing from the [diagram in the previous](#app-host-dcp-flow) section, consi :::image type="content" source="media/dcp-architecture-thumb.png" alt-text="A diagram depicting the architecture of the Developer Control Plane (DCP)." lightbox="media/dcp-architecture.png"::: -DCP logs are streamed back to the app host, which then forwards them to the developer dashboard. While the developer dashboard exposes commands such as start, stop, and restart, these commands are not part of DCP itself. Instead, they are implemented by the app model runtime, specifically within its "dashboard service" component. These commands operate by manipulating DCP objects—creating new ones, deleting old ones, or updating their properties. For example, restarting a .NET project involves stopping and deleting the existing representing the project and creating a new one with the same specifications. For more information on commands, see [Custom resource commands in .NET Aspire](../fundamentals/custom-resource-commands.md). +DCP logs are streamed back to the app host, which then forwards them to the developer dashboard. While the developer dashboard exposes commands such as start, stop, and restart, these commands are not part of DCP itself. Instead, they are implemented by the app model runtime, specifically within its "dashboard service" component. These commands operate by manipulating DCP objects—creating new ones, deleting old ones, or updating their properties. For example, restarting a .NET project involves stopping and deleting the existing representing the project and creating a new one with the same specifications. + +For more information on container networking, see [How container networks are managed](../fundamentals/networking-overview.md#how-container-networks-are-managed). ## Developer dashboard diff --git a/docs/fundamentals/networking-overview.md b/docs/fundamentals/networking-overview.md index 8e9e579c82..59ad08f557 100644 --- a/docs/fundamentals/networking-overview.md +++ b/docs/fundamentals/networking-overview.md @@ -1,7 +1,7 @@ --- title: .NET Aspire inner loop networking overview description: Learn how .NET Aspire handles networking and endpoints, and how you can use them in your app code. -ms.date: 10/29/2024 +ms.date: 07/11/2025 ms.topic: overview --- @@ -30,6 +30,29 @@ To help visualize how endpoints work, consider the .NET Aspire starter templates :::image type="content" source="media/networking/networking-proxies-1x.png" lightbox="media/networking/networking-proxies.png" alt-text=".NET Aspire Starter Application template inner loop networking diagram."::: +## How container networks are managed + +When you add one or more container resource(s), .NET Aspire creates a dedicated container bridge network to enable service discovery between containers. This bridge network is a virtual network that lets containers communicate with each other and provides a DNS server for container-to-container service discovery using DNS names. + +The network's lifetime depends on the container resources: + +- If all containers have a session lifetime, the network is also session-based and is cleaned up when the app host process ends. +- If any container has a persistent lifetime, the network is persistent and remains running after the app host process terminates. Aspire reuses this network on subsequent runs, allowing persistent containers to keep communicating even when the app host isn't running. + +For more information on container lifetimes, see [Container resource lifetime](orchestrate-resources.md#container-resource-lifetime). + +Here are the naming conventions for container networks: + +- **Session networks**: `aspire-session-network--` +- **Persistent networks**: `aspire-persistent-network--` + +Each app host instance gets its own network resources. The only differences are the network's lifetime and name; service discovery works the same way for both. + +Containers register themselves on the network using their resource name. Aspire uses this name for service discovery between containers. For example, a `pgadmin` container can connect to a database resource named `postgres` using `postgres:5432`. + +> [!NOTE] +> Host services, such as projects or other executables, don't use container networks. They rely on exposed container ports for service discovery and communication with containers. For more details on service discovery, see [service discovery overview](../service-discovery/overview.md). + ## Launch profiles When you call , the app host looks for _Properties/launchSettings.json_ to determine the default set of endpoints. The app host selects a specific launch profile using the following rules: From c3a15adc32eff17667a5f930a27dfe7293f2628f Mon Sep 17 00:00:00 2001 From: David Pine Date: Fri, 11 Jul 2025 09:38:40 -0500 Subject: [PATCH 2/3] Fix MD --- docs/architecture/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architecture/overview.md b/docs/architecture/overview.md index a8983d06a3..b813b952d8 100644 --- a/docs/architecture/overview.md +++ b/docs/architecture/overview.md @@ -165,7 +165,7 @@ Continuing from the [diagram in the previous](#app-host-dcp-flow) section, consi :::image type="content" source="media/dcp-architecture-thumb.png" alt-text="A diagram depicting the architecture of the Developer Control Plane (DCP)." lightbox="media/dcp-architecture.png"::: -DCP logs are streamed back to the app host, which then forwards them to the developer dashboard. While the developer dashboard exposes commands such as start, stop, and restart, these commands are not part of DCP itself. Instead, they are implemented by the app model runtime, specifically within its "dashboard service" component. These commands operate by manipulating DCP objects—creating new ones, deleting old ones, or updating their properties. For example, restarting a .NET project involves stopping and deleting the existing representing the project and creating a new one with the same specifications. +DCP logs are streamed back to the app host, which then forwards them to the developer dashboard. While the developer dashboard exposes commands such as start, stop, and restart, these commands are not part of DCP itself. Instead, they are implemented by the app model runtime, specifically within its "dashboard service" component. These commands operate by manipulating DCP objects—creating new ones, deleting old ones, or updating their properties. For example, restarting a .NET project involves stopping and deleting the existing representing the project and creating a new one with the same specifications. For more information on container networking, see [How container networks are managed](../fundamentals/networking-overview.md#how-container-networks-are-managed). From cba7b18b5cb04a5c4335b4507e9ac4b84ba47dde Mon Sep 17 00:00:00 2001 From: David Pine Date: Fri, 11 Jul 2025 10:50:19 -0500 Subject: [PATCH 3/3] Update docs/fundamentals/networking-overview.md Co-authored-by: Andy (Steve) De George <67293991+adegeo@users.noreply.github.com> --- docs/fundamentals/networking-overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/fundamentals/networking-overview.md b/docs/fundamentals/networking-overview.md index 59ad08f557..b83cd8e138 100644 --- a/docs/fundamentals/networking-overview.md +++ b/docs/fundamentals/networking-overview.md @@ -32,7 +32,7 @@ To help visualize how endpoints work, consider the .NET Aspire starter templates ## How container networks are managed -When you add one or more container resource(s), .NET Aspire creates a dedicated container bridge network to enable service discovery between containers. This bridge network is a virtual network that lets containers communicate with each other and provides a DNS server for container-to-container service discovery using DNS names. +When you add one or more container resources, .NET Aspire creates a dedicated container bridge network to enable service discovery between containers. This bridge network is a virtual network that lets containers communicate with each other and provides a DNS server for container-to-container service discovery using DNS names. The network's lifetime depends on the container resources: