Support provisioning azure resources for dev

[davidfowl]

• Use the Azure management SDK to spin up resources for various app model components.
• Added azure resources that we have components for i.e. ServiceBus, KeyVault and Storage (queues, blobs and tables)
• If the azure subscription isn't specific in config provisioning will log a warning and skip. This means the app won't change.
• Also preserved passing connection information to the dev host via configuration also still works (this was preserved)

Most of this logic was reverse engineered from various samples and many bicep files in a playground. This makes playing with azure resources much easier.

PS: There is no tear down of the resources when the app closes.

@karolz-ms I'd like to figure out a way to represent "external resources" in dcp (components that exist but are managed externally).

[davidfowl]

How do we get things added to the feed? Azure.ResourceManager.Authorization is missing? Queued a job to mirror this package

[mitchdenny]

More of a general comment about the API approach here. I wonder whether it might be better to do something like this:

var builder = DistributedApplication.CreateBuilder(args);
var provisioner = builder.AddAzureProvisioner(sub, rg, location);

var storage = provisioner.AddAzureStorage(name);
// or
var storage = builder.AddAzureStorage(name, provisioner); // provisioner would be an optional argument

The idea is that it allows the developer some control over which subscription and RG is used for a specific resource. We probably also want the ability to supply a Bicep fragment and pass in properties to that.

[davidfowl]

I think we should allow overrides on the component AddX methods to override the resource group that is used.

Can they be successful using the provisioner at all? Why not have them not use it and get already provisioned resources?

[davidfowl]

The idea is that it allows the developer some control over which subscription and RG is used for a specific resource. We probably also want the ability to supply a Bicep fragment and pass in properties to that.

if we get this feedback from more people as they use it. I think we should make sub, region and location(s) to be required config and we can see what problems arise from there.

We can design more API if we need to.

FWIW: I prefer this one:

var builder = DistributedApplication.CreateBuilder(args);
var provisioner = builder.AddAzureProvisioner(sub, rg, location);

var storage = provisioner.AddAzureStorage(name);