We have a multi-tenant web app, using a “website per tenant” model. Currently, we have a Azure Web App deployment target for each site, which is in the appropriate environment, and each tenant is authorised for the deployment target, and the related Azure account. (Unfortunately, there are a couple of different accounts).
I would like to enhance our deployment process to make use of deployment slots (mainly so we can warm up the app to reduce the impact of deployment). I was trying to follow the instructions, but I hit a snag in trying to get a reference to the Azure account to run the Powershell scripts as. I tried using #{Octopus.Action.Azure.AccountId}, but that didn’t work - I got an error creating the deployment:
An attempt to parse the variable symbol “Octopus.Action.Azure.AccountId” appears to have resulted in a self referencing loop (Octopus.Action.Azure.AccountId). Ensure that recursive loops do not exist in the variable values.
I think what would help is a property on the Azure Web App system variable that refers to the account? That doesn’t seem to exist (looking here, and also at the popup binding helper thingy…). Coincidentally, the powershell commands that I would need to run need the resource group name, and I don’t think that exists on the web app system variable either…
Is there any way to work around this without creating a project variable template containing the Azure account, web app name & resource group - all data that already exists in Octopus in one form or another - and then populating variables for ~50 tenants?
Hi Jon,
Thanks for getting in touch and sorry for the delay in this reply.
We reproduced the self-referencing loop problem you mentioned, and we believe a way around this is to instead switch the account field into binding mode on your step and use some naming-convention and variable substitution to map to the correct account for the given environment/tenant combination.
For example, if we focus just on the environment side of things, let’s say I have two environments Development and Staging…
I could create two accounts named MyAzureAccountForDevelopment and MyAzureAccountForStaging with the appropriate scoping, then use the environment-related system variables in variable substitution on the step’s account field (in bound mode) to map to the correct account at deployment time, like so:
At deployment time, that variable substitution will replace the environment name and reference the associated account by name.
Would something like that work for you?
Regarding the resource group name, unfortunately that documentation is out of date (we’ll aim to fix that up today). But the good news is that there is a variable available for the resource group. If you
print evaluated variables (by creating project variables called OctopusPrintVariables and OctopusPrintEvaluatedVariables and set their value to True) then either create a new release and run a new deployment or update the variable snapshot of your existing release, you can select the Verbose log-level on the task screen and see a list of ALL the variables available at the time of the deployment. If you then search this log for “.Azure.” you’ll see the Azure-related variables that are available to you based on the account that was resolved. If this is a web-app target step, the app name and resource group should be available as variables for the step itself:
E.g.
I hope this at least points you in some directions that might be useful.
Let me know how you go.
Cheers
Mark
