Add dedicated documentation for DCP container networking tunnel#530
Add dedicated documentation for DCP container networking tunnel#530IEvangelist merged 7 commits intomainfrom
Conversation
…ixes #325) Co-authored-by: IEvangelist <7679720+IEvangelist@users.noreply.github.com>
IEvangelist
left a comment
IEvangelist
left a comment
There was a problem hiding this comment.
This PR looks good so far, but let's double check it for accuracy by using the .github/skills/doc-tester/SKILL.md skill. Please also consider all new comments and feedback/suggestions. @copilot
|
please also link to architecture content that contains details for DCP |
Co-authored-by: IEvangelist <7679720+IEvangelist@users.noreply.github.com>
Addressed both review comments in 0bb13c3:
Ran doc-tester validation: all 5 internal links return HTTP 200, Steps component renders numbered steps correctly, and both OS tabs (bash/PowerShell) display and switch as expected. |
IEvangelist
left a comment
IEvangelist
left a comment
There was a problem hiding this comment.
@copilot please see my comment
| import { Aside, Steps } from '@astrojs/starlight/components'; | ||
| import OsAwareTabs from '@components/OsAwareTabs.astro'; | ||
|
|
||
| During local development, your Aspire app model often includes a mix of container resources and host-based services (such as .NET projects or executables). Container-to-container communication works naturally over the bridge network, but containers that need to reach services running on the host require a different approach. Aspire solves this with the **container tunnel**, a DCP capability that provides reliable, transparent container-to-host connectivity. |
There was a problem hiding this comment.
Instead of .NET projects or executables we should say something about C#, TypeScript, Python, as we support much more than just .NET.
Also, DCP is mentioned before it's defined in the following paragraph. We need to fix that and please also link to architecture content that contains details for DCP
There was a problem hiding this comment.
Fixed in 3f8702e — broadened to "C#, Python, or TypeScript projects", moved the full "Developer Control Plane (DCP)" definition to the intro paragraph with a link to the architecture overview, and updated the next paragraph to use just "DCP" since it's already defined.
There was a problem hiding this comment.
Pull request overview
Adds a dedicated Fundamentals doc page explaining Aspire’s DCP container tunnel (container-to-host connectivity), and links it from existing networking documentation so readers can discover the feature and how to enable it.
Changes:
- Added new
fundamentals/container-networking.mdxpage documenting the container tunnel, network identifiers, and enablement viaASPIRE_ENABLE_CONTAINER_TUNNEL. - Added a cross-reference from
fundamentals/networking-overview.mdxto the new page. - Added a sidebar entry for “Container networking”.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| src/frontend/src/content/docs/fundamentals/networking-overview.mdx | Adds a pointer to the new container networking/tunnel documentation. |
| src/frontend/src/content/docs/fundamentals/container-networking.mdx | New dedicated doc page describing the DCP container tunnel, network identifiers, and opt-in instructions. |
| src/frontend/config/sidebar/docs.topics.ts | Adds the new Fundamentals sidebar entry (with translated labels). |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
You can also share your feedback on Copilot code review. Take the survey.
| [service discovery](/fundamentals/service-discovery/). | ||
| </Aside> | ||
|
|
||
| When containers need to reach host-based services, Aspire can use the **container tunnel** to provide reliable connectivity. For more information, see [Container networking](/fundamentals/container-networking/). |
| import { Aside, Steps } from '@astrojs/starlight/components'; | ||
| import OsAwareTabs from '@components/OsAwareTabs.astro'; | ||
|
|
||
| During local development, your Aspire app model often includes a mix of container resources and host-based services (such as .NET projects or executables). Container-to-container communication works naturally over the bridge network, but containers that need to reach services running on the host require a different approach. Aspire solves this with the **container tunnel**, a DCP capability that provides reliable, transparent container-to-host connectivity. |
…e with architecture link Co-authored-by: IEvangelist <7679720+IEvangelist@users.noreply.github.com>
Added in 3f8702e — the intro paragraph now links DCP to |
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
|
Hey @copilot, please rebase this PR as there are merge conflicts. Also, please consider the following feedback as well: The biggest issue is that in Aspire 13.3 container tunnel is ENABLED by default. Other than that I would change steps 2 and 3 in the description of how the tunnel works to the following <Steps>
1. **Dependency detection**: When the AppHost builds the app model, it identifies which containers reference endpoints on host-based resources.
2. **Tunnel setup**: DCP creates a network path (proxy endpoint) from the container bridge network to the host, so containers can reach host-bound endpoints. This happens for every host-bound endpoint referenced by one or more containers.
3. **Endpoint injection**: When a container resolves an endpoint that is implemented by a host-based resource, the endpoint resolves to corresponding proxy endpoint provided by the tunnel. Proxy endpoint information is then injected into container via environment variables or startup parameters, in the same way as it happens for other endpoints.
4. **Automatic cleanup**: When the AppHost process stops, DCP tears down the tunnel along with the rest of the orchestrated resources.
</Steps> |
# Conflicts: # src/frontend/config/sidebar/docs.topics.ts # src/frontend/src/content/docs/fundamentals/networking-overview.mdx Co-authored-by: IEvangelist <7679720+IEvangelist@users.noreply.github.com>
Merged main to resolve conflicts in
Note: your suggested MDX content for steps 2 and 3 appeared empty in the comment — I rewrote them to describe the tunnel container and endpoint injection. Please let me know if you'd like different wording. Warning Firewall rules blocked me from connecting to one or more addresses (expand for details)I tried to connect to the following addresses, but was blocked by firewall rules:
If you need me to access, download, or install something from one of these locations, you can either:
|
karolz-ms
left a comment
karolz-ms
left a comment
There was a problem hiding this comment.
Looks great overall, thank you, but please consider my comment regarding "how it works" section--I think as-is that part is a bit confusing.
|
|
||
| 2. **Tunnel container**: DCP deploys a lightweight tunnel container on the Aspire container bridge network. This container serves as the entry point for all container-to-host traffic. | ||
|
|
||
| 3. **Endpoint injection**: DCP injects the tunnel container's address into each dependent container as environment variables, so that containers seamlessly route traffic to the host through the tunnel. |
There was a problem hiding this comment.
The container (and its address) are the same and indeed serves as a single point of entry, but the port is different (one container network port for each unique host port). Also, they are not the same value (it is NOT the case that host port 1234 will be projected as port 1234 on container network).
Also, the addresses and ports may be injected as container variables, but may also be provided as startup parameters, or in general, retrieved via reference expressions.
There was a problem hiding this comment.
Fixed in 58b5175:
- Step 2 now clarifies that the tunnel container exposes a separate port for each unique host port, and that the container network port values differ from the original host port values.
- Step 3 renamed to "Endpoint resolution" — now mentions reference expressions as the general mechanism, with environment variables, startup parameters, or other configuration as possible delivery methods.
…ssions Agent-Logs-Url: https://github.com/microsoft/aspire.dev/sessions/011751c3-b5b5-4725-8d3d-080ef9ed5c51 Co-authored-by: IEvangelist <7679720+IEvangelist@users.noreply.github.com>
Addressed in Warning Firewall rules blocked me from connecting to one or more addresses (expand for details)I tried to connect to the following addresses, but was blocked by firewall rules:
If you need me to access, download, or install something from one of these locations, you can either:
|
Adds a new Fundamentals documentation page explaining Aspire's DCP container tunnel for container-to-host connectivity, and links it from existing networking documentation so readers can discover the feature.
Changes Made
fundamentals/container-networking.mdxdocumenting the container tunnel, network identifiers, and how to disable the tunnel if needed.docs.topics.ts.networking-overview.mdxto the new container networking page.<Steps>component; step 2 clarifies that the tunnel container exposes a separate port for each unique host port (with different port values than the originals); step 3 describes endpoint resolution via reference expressions, which may surface as environment variables, startup parameters, or other configuration mechanisms.OsAwareTabswith bash and PowerShell tabs for environment variable instructions.ASPIRE_ENABLE_CONTAINER_TUNNEL=falseif the tunnel causes issues.✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.