We run azure app services with 30-50 tenants. I don’t understand how we’re meant to model this with the Azure Web App targets. Creating 50 targets and then tying each one to a tenant is possible but seems like a duplication of effort. We can use scripting to dynamically create targets and then delete them after deployment (and it seems this is what is recommended for a multitenant setup) but it seems like the “Deploy an Azure Web App” should allow this out of the box, the way the IIS step has built-in capability of creating AppPools and Sites dynamically and configuring things like bindings, ssl settings, etc.
In short, I’m trying to undertstand why the Azure Account or App Service Plan does not stand in as the “Deployment Target”, roughly equivalent to a server in a non-PaaS world. Then any number of apps could be deployed into the single Deployment Target.
In the multitenant scenario should we be using the azure web app step or is there another recommended way to set this up?
We have a blog post that walks through a scenario that is similar to the one you describe. The walkthrough uses the Deploy an Azure Web App step for the application deployment. In the multi-tenant scenario, one web-app per tenant per environment is the recommended approach.
The overview of the process is to create your Azure infrastructure through an ARM template or PowerShell, then create the corresponding Octopus deployment target via the Dynamic Infrastructure cmdlets. Then an Azure Web App step, either in the same process or a separate project, can be used to deploy to all the web apps with a matching Role tag.
As mentioned in the documentation, when you create a target via the cmdlets that are running within the scope of a tenant, the target will be scoped to that tenant.
Using the dynamic infrastructure cmdlets in your process will mean that you only have to script the target management once and will continue to work as you add more tenants. You also don’t have to delete the target after the deployment, they can continue to be available to deploy updated versions of your applications. The idea behind the dynamic target cmdlets is to be able to manage your Octopus targets in a similar manner as you manage your Azure infrastructure.
We are still refining the dynamic infrastructure process and the deployment targets and are hoping to make these things easier to work within the future. A deployment target that is specific to an App Service Plan, an Azure Resource Group, or an Azure Subscription are possibilities that we have considered.
We are also working on some more walk-through guides around Dynamic Infrastructure and your multi-tenant scenario will be one that will be covered.
I hope this helps you out. Please get back to me if you need further information or guidance.
Thanks, the post was very helpful. I plan to use an azure arm template to set up the web app then create the octo target in the preprocessing script of the deploy web app step.
We plan to use azure vault to store our secrets. However it seems like only the arm template step has automatic access in octo. Are there any plans to allow any sensitive variable in Octo to be pulled in from Vault when doing a deploy?
.
One thing to note, you will need to create your Azure Web App target in a step prior to the Deploy an Azure Web App step, this could either be a standalone step or a post-deploy step i the Azure ARM step.
There is an open uservoice suggestion for support for Azure Vault. At this stage I would suggest voting and adding your support over there. I don’t have a timeframe for this support at this stage.
I was able to get the create from ARM template working along with dynamically creating the octo target. What I’m not understanding is how to cleanly deploy to the correct azure web app in the deploy step. The blog post suggests using roles. In my case I have multiple tenants and each tenant has multiple apps, for example here are my azure web apps:
tenant1-app1
tenant2-app1
tenant2-app1
tenant2-app2
If I am dynamically creating the targets how would I ensure that my step which deploys “App1” to “tenant1” goes only to the correct dynamically created target “tenant1-app1”?
After experimenting, I see that New-OctopusAzureWebAppTarget seems to automatically restrict the dynamically created target to the tenant if its run in a tenanted deployment. So the answer seems to be to use the target Role to make sure my apps are kept straight