Generator/Source Generator/Dynamic Resource load from Docker Compose/Helm Charts/various compute environments

[Manuele Lucchi (manuelelucchi)]

Most compute environments now provide a publish feature that generates YAML manifests or other deployment artifacts. However, many existing infrastructures already have a large number of YAML files (Docker Compose, Kubernetes manifests, Helm charts, etc.) that eventually need to be rewritten as Aspire AppHosts.

The work in #12384 is already a good starting point for this scenario.

I wonder whether a Source Generator approach could be considered as well. It feels more aligned with Aspire's strongly-typed model and would allow developers to apply overrides on the generated output. For example, a specific image definition could be replaced with a richer Aspire integration or typed resource when available.

This approach would be useful for teams that want to keep their existing infrastructure definitions as the source of truth while using Aspire for custom applications and higher-level orchestration.

Another possible approach would be a static code generator (for example as a CLI option) that generates AppHost code from existing definitions. The generated code would then be checked into source control and maintained manually. This would mainly serve as a migration path from Docker Compose or other infrastructure definitions to Aspire.

To me these are two complementary scenarios:

• Source Generator: infrastructure definitions remain the source of truth and Aspire code is generated automatically.
• Static/CLI Generator: generate Aspire code once to help migration and then maintain the AppHost directly.

Has the Aspire team considered any of these approaches for reducing the effort required to adopt Aspire in existing environments?

[David Negstad (danegsta)]

For supporting Compose yaml in the app model, the design we've discussed internally is extending https://github.com/microsoft/dcp to support it (either as a concrete resource and controller or via some helper commands for parsing the config). DCP is the local dev orchestrator for Aspire and is written in Go, which would make it straightforward to use the official Compose serializers instead of having to maintain a custom one in C#.

[David Fowler (davidfowl)]

Also we won't build anything that only work with C# based apphosts.

[Manuele Lucchi (manuelelucchi)]

Shouldn't every compute environment be able to support it indipendently? Like you know, loading a local env starting from azure bicep files. I guess source gen is out of the scene since that won't work with polyglot, but a code generation from the cli could do?

[David Fowler (davidfowl)]

Yea I don’t see why these wouldn’t just be integrations that load those files. Doesn’t need cli or source generator support

[Pedro Brown (pedrobrown)]

Just added a comment in Discussion 18680 that might be relevant to this discussion as well.

We recently ran a local experiment with an existing application that already had a Helm chart, similar to the migration scenario described in Discussion #18741. The goal was to model the Kubernetes resources in the AppHost and compare the output of aspire publish with the existing chart.

(...)

In summary, the most useful additions would be:

• typed Job and CronJob resource support;
• C# customization of generated workload kinds;
• reusable APIs for ConfigMap imports and volume mounts;
• support for externally managed Secrets and Secret providers;
• preservation of generated parameters and configuration when customizing resources.