Aspire Integration #4465
Description
Problem Statement
An ever-increasing portion of the .Net development ecosystem* are in the process of migrating their local development to run through .Net Aspire. Aspire allows the development team to have a single entrypoint for all of their required development resources, substantially simplifying onboarding of new developers.
Around a month ago I wanted to try using self-hosted Sentry because I just like having everything running locally whenever I develop as I can f*ck up as much as I want without affecting anyone else, so the obvious first thing I did was look up how to set up Sentry inside of Aspire. This brought me to this article. This article didn't talk about how to use Aspire to host Sentry, so I went digging some more.
After not finding the integration, the second thing I looked for a Sentry docker image. This technically exists, but was deprecated 6 years ago in favour of a docker-compose installation bash script. This seems to have been done because Sentry requires external container resources to run, which a simple docker run cannot fulfill (i.e. the docker image was never really standalone, so it was a false promise)
This is where .Net Aspire comes in; .Net Aspire enables you - the Sentry team - to declaratively define these container relationships in a .Net Aspire integration. Which, in essence, is a composable and sharable super-powered version of a docker-compose file.
* I have even heard rumors that there are developers outside the .Net ecosystem that are starting to use .Net Aspire during development because it simplifies local orchestration to an even greater extent than a docker-compose file.
Solution Brainstorm
What I'm proposing is creating a new NuGet package, Sentry.Aspire which adds something like the following members:
// Probably some more interfaces, but these are the obvious ones.
public interface ISentryResource : IResource, IResourceWithEnvironment
{
public string Dsn { get; }
public Uri Url { get; }
// ... More stuff here presumably ...
}
public class CloudHostedSentryResource : ISentryResource;
public class SelfHostedSentryResource : ContainerResource, ISentryResource;
// This API would, when run using `aspire run`,
// do all required setup steps to initiate a self-hosted Sentry instance,
// and return necessary values back to the AppHost, like the URI, Port, etc.
// If needed, you might add a third parameter which includes some options.
public static IResourceBuilder<SelfHostedSentryResource> AddSelfHostedSentry(this IDistributedApplicationBuilder builder, [ResourceName] string name);
// This API would, when run using `aspire publish`,
// would use some sort of system to create and/or connect to a cloud-hosted Sentry Project.
// This part of the API can be punted for a later version, but I just wanted to mention a possible future.
// If needed, you might add a third parameter which includes some options.
public static IResourceBuilder<CloudHostedSentryResource> AddCloudHostedSentry(this IDistributedApplicationBuilder builder, [ResourceName] string name);
// This API would make the cloud-hosted resource run self-hosted during development.
// If needed, you might add a second parameter which includes the same options
// as mentioned in the `AddSelfHostedSentry` method above.
// Maybe even share them with the `AddCloudHostedSentry` if the options turn out to be identical.
public static IResourceBuilder<SelfHostedSentryResource> RunAsContainer(this IResourceBuilder<CloudHostedSentryResource> sentryResource);I tried to follow the pattern used by the first-party Azure integrations, like the Azure Postgres integration in the API suggestion above.
This could then be used something like this:
var builder = DistributedApplication.CreateBuilder(args);
var sentry = builder.AddCloudHostedSentry("sentry").RunAsContainer();
var web = builder.AddProject<Projects.App_Web>("web")
// During development, the `web` resource would now have all required
// environment variables needed to connect to the self-hosted Sentry instance,
// like `SENTRY_DSN`, `SENTRY_URL`, etc.
// During publishing, these environment variables would instead point
// to the cloud-hosted version.
.WithReference(sentry);
builder.Build().Run();If the user of the integration instead wanted to always use the cloud-hosted version, they could simply do this to the above example.
- var sentry = builder.AddCloudHostedSentry("sentry").RunAsContainer();
+ var sentry = builder.AddCloudHostedSentry("sentry");If the user wanted to always use the self-hosted version, they would instead do this:
- var sentry = builder.AddCloudHostedSentry("sentry").RunAsContainer();
+ var sentry = builder.AddSelfHostedSentry("sentry");I recommend getting in contact with the .Net Aspire team (Or maybe the Community Toolkit team) before finalizing this API, as I am not versed into the best ways to implement Aspire integrations.