Support running and debugging Aspire service projects in Containers

[DamianEdwards]

It should be possible to configure a composed project resource to run in Docker. We'll need to consider the integration/composition with VS container tools for Docker and whether we build the project in the host or in the container itself.

[mitchdenny]

Are you talking about something like this:

var builder = DistributedApplication.CreateBuilder(args);
builder.AddProject<Projects.Foo>("foo").AsContainer();

[andref15]

Are you talking about something like this:

var builder = DistributedApplication.CreateBuilder(args);
builder.AddProject<Projects.Foo>("foo").AsContainer();

Something like that would be okay, however I think it would be nicer to just support this through the WithLaunchProfile method. I'm not sure if it's possible to check if the launch profile is a docker/container profile and just do the container logic implicitly when that's the case, but if it isn't maybe using a boolean parameter like isContainer or something.

To be clear I might be missing some complications or other things, that could make the AsContainer fluent api method a better option.

[mitchdenny]

I'm thinking it might even be better to do something like this:

var builder = DistributedApplication.CreateBuilder(args);
builder.AddProjectContainer<Projects.Foo>("foo");

I've been playing around with what the developer experience is for folks building extensions to expire based on .NET apps that run in containers. A scenario that I've been playing with is creating a reusable component that allows you to easily receiver webhook notifications from GitHub and forward them to an Azure Storage queue. The container with the actual application logic would be hosted in Docker Hub, and there would be a NuGet package containing extension methods for wiring it up. This is what the usage would look like in a consuming application.

var builder = DistributedApplication.CreateBuilder(args);
var secret = builder.AddSecretStore("mysecrets").AddSecret("webhooksharedsecret");
var queues = builder.AddAzureStorage("azstorage").AddQueue("azqueues");
var webhookReceiver = builder.AddGitHubWebhookReceiver("webhookreceiver", secret, queues);

For the developer building this extension they want to be able to just have an Aspire host that they can run in their own repo that allows them to spin up their web app. Having an API like AddProjectContainer<T>(...) would allow for this scenario:

public static IResourceBuilder<T> AddGitHubWebhookReceiver(this IDistributedApplicationBuilder builder, string name, IResourceBuilder<SecretResource> secret, IResourceBuilder<AzureQueueStorageResource> queues)
{
  #if DEBUG
    return AddProjectContainer(...);
  #endif

   #if !DEBUG
    return AddContainer(...);
   #endif
}

It allows the return type to always be a container, even though in the home repo for the Aspire extension you can build from project sources and attach debuggers etc. AddProjectContainer(...) might rely on something with launch profiles to make this work as you've suggested though.

[paulomorgado]

I was thinking more in the lines of specifying a launch profile that runs the project on a container.

From Visual Studio Container Tools for Docker:

"Container (.NET SDK)": {
  "commandName": "SdkContainer",
  "launchBrowser": true,
  "launchUrl": "{Scheme}://{ServiceHost}:{ServicePort}",
  "environmentVariables": {
    "ASPNETCORE_HTTPS_PORTS": "8081",
    "ASPNETCORE_HTTP_PORTS": "8080"
  },
  "publishAllPorts": true,
  "useSSL": true
}

One can always build and publish the container. But one of the added values of Aspire is the full developer experience that includes debugging.

[davidfowl]

@danegsta I would defer to you. It needs to work on the command line though

[paulomorgado]

It needs to work on the command line though

If the Aspire host is specifying a launch profile, what difference would that make?