Spike: Marain Deployment vNext

[JamesDawson]

(not intended to be merged in the current form)

Marain Deployment vNext Spike

This branch contains PoC deployment work that builds on some earlier work, including:

• https://github.com/marain-dotnet/Marain.Tenancy/tree/feature/corvus-deployment
• https://github.com/marain-dotnet/Marain.Tenancy/tree/feature/dapr
• https://github.com/corvus-dotnet/Corvus.Deployment/tree/feature/uniqueSuffix

Overview

• Targets hosting in Azure Container Apps rather than Azure Functions
• ARM deployment migrated to Bicep:
  • Marain.Instance orchestrated in deploy-instance.ps1
    • Includes: Container App Environment, optional ACR, shared key vault & app config store, published config/secrets
  • Marain.Tenancy orchestrated in deploy-tenancy.ps1
    • Includes: Storage, container app, published config/secrets
  • Initial set of reusable Bicep modules
  • Intended to easily support use of existing Azure services (cross-subscription) or provisioning dedicated instances:
    • Container App Environment
    • Azure Container Registry
    • App Configuration Store
  • Support for using a single Marain key vault or the current vault per service approach
  • Aims to minimise the need to pass secrets in or out of the ARM deployment
• Uses Corvus.Deployment and InvokeBuild as basis for the deployment process
• Opinonated config management approach as per Corvus.Deployment:
  • common.ps1 - shared settings across all environments
  • sample.ps1 - a sample environment using a MPN subscription
  • ARM deployment publishes required config to Key Vault and App Configuration

Build

An initial build (using Endjin.RecommendedPractices.Build) has been setup and extended to produce a suitable container image.

Endjin.RecommendedPractices

The erp folder is a placeholder for elements that, if retained, could be extracted into separate Endjin.RecommendedPractices.* repositories:

• erp/bicep - reusable Bicep modules
• erp/deploy - reusable deployment processes, equivalent to Endjin.RecommendedPractices.Build but for deployment

Testing the spike

The deployment of the Marain Instance and Marain Tenancy infrastructure & services can be run as follows:

az login
az account set -s <subscription-id>
Connect-AzAccount
Set-AzContext -SubscriptionId <subscription-id>
./Solutions/deploy-runner.ps1 -Environment sample -StackName <your-initials> -ServiceInstance i1

You can also experiment with different configurations by modifying a copy of the sample.ps1 configuration script.

[idg10]

This is just for functions. Howard was adding an ASP.NET Core host, which uses the more straightforward appsettings.json stuff instead of the slightly idiosyncratic functions-specific local.settings.json.

In any case, this should say where this file goes.

[idg10]

This is out of date with how things are now on main. For dev storage, this works:

    "TenantCacheConfiguration__GetTenantResponseCacheControlHeaderValue": "max-age=300",

    "RootBlobStorageConfiguration__ConnectionStringPlainText": "UseDevelopmentStorage=true"

So there are a couple of important changes:

1. it's now all under RootBlobStorageConfiguration, not RootTenantBlobStorageConfigurationOptions
2. we're now using the current corvus tenancy bits, which have removed the old weirdness in which AccountName was sometimes interpretted as a connection string (and it means that if you are using KeyVault it looks a bit different now)

[idg10]

Which service principal is this? Is it the managed identity of the function app? If so, we want this to be determined dynamically don't we?

[idg10]

So is this just for VS's benefit? Or is this also used to build deployable artifacts?

[idg10]

So are we dropping functions entirely as an option? (If so, the readme definitely shouldn't be discussing local.settings.json)