[Update article]: Add details on container networking for 9.4

[danegsta]

Proposed topic or title

Container network

Location in table of contents.

docs/fundamentals/networking-overview

Reason for the article

Aspire creates a custom container network to enable container-to-container service discovery. While it was mentioned in the what's new article for Aspire 9.0, there's no documentation on the network or how it relates to service discovery.

We're making some changes to the network we create in 9.4, so it makes sense to document this new behavior specifically.

Article abstract

When you have one or more container resources, Aspire will create a dedicated custom container bridge network to enable service discovery between container resources. Container bridge networks are virtual networks that allows individual containers to communicate with other containers on the same network and provide containers with a DNS server that allows for container to container service discovery using DNS names.

If all container resources have session lifetime, the container network will also have a session lifetime and be cleaned up when the app host process is terminated. If any container resources have a persistent lifetime, the container network will be created with a persistent lifetime and be left running when the app host process is terminated and re-used on the next run of the app host. This allows persistent containers to continue communicating with each other when the app host isn't running.

If a session lifetime network is created, it's name will start with aspire-session-network- followed by a unique prefix ID and the app host application name. It a persistent lifetime network is created, it's name will start with aspire-persistent-network- followed by a project hash and the host application name. Each app host instance will get its own network resources. The network lifetime and name are the only differences; otherwise all networks are used the same way with regards to service discovery.

Containers register themselves on the network using their resource name and Aspire uses the resource name for service discovery between containers. For example, a pgadmin container might use postgres:5432 to connect to an associated database resource named postgres.

Host services such as projects or other executables don't use container networks; they rely on exposed container ports for service discovery.

Relevant searches

container network