I am trying to use the the new feature to enable dynamic deployment targets for the App Service. It has been working fine when I create a physical Azure Web App deployment target with a unique role for the deployment target.
However after setting up the Deploy An Azure App Service and for the On Behalf of Role I create a new role that corresponds to the respective Tag in the Azure App Service I get the following issue in the deployment
| == Skipped: Step 14: Deploy API to Azure Staging ==
13:46:21 Verbose | Searched for targets:
13:46:21 Verbose | * specifically matching these ids: Machines-301
| * that are enabled
| * with no id exclusions
| * with no environment exclusions
| * has a role that overlaps: <TaggedRoleInWebApp>
| * with no tenant exclusions
| * with any health status
13:46:21 Info | Skipping this step as no matching targets were found
And it skips the step. I have the tag for the environment set too in my Web App.
Thanks for reaching out to Octopus support! I just want to gather some more information so that I can attempt to reproduce your configuration in-house.
Are you using a script similar to this example to create the new target in your deployment process?
Would you mind sending your full raw task log to us so I can get a better idea of your full deployment process? If you are willing, it would also be helpful to send the JSON output from your deployment process as well. You can remove any information you do not wish to share from the JSON before sending it. I will DM you a secure upload link you can use to send those to us.
I look forward to hearing back and please let me know if you have any other questions.
I’m not using a script, just the DEPLOY AN AZURE APP SERVICE process step as mentioned here.
This process step works fine with an AZURE WEB APP deployment taget. I created a role as part of the deployment target. So for the Cloud Target feature I remove the exisitnf role from the step and create a new one that matches the tag in the web app as mentioned here.
I then deploy just two processes (excluding everything else), the first being creating a slot via script and the second using the DEPLOY AN AZURE APP SERVICE step that deploys the azure container to that app service. The log entry above is pretty much all the raw logs state for that deployment, but I’ve run it a again and included the logs in the link you sent me.
As I said it works fine with static deployment targets, but cannot resolve the web app with dynamic ones.
On another note, I normally have a number of steps for my Azure web app deployment grouped into a parent step. This moves the role field up to the parent from the web app step. This is fine if you are selecting a static deployment target’s role.
But as the step on its own has the option of typing a role rather than selecting a deployment target’s role, as soon as you group this step and the role is moved to the parent you can no longer manually type a role, only select from the drop down.
So I now have to move all of the process steps for Azure out of the parent. Is this a bug ?
Thank you for sending over your task log and for the additional information. It was very helpful for recreating your process.
Do you have the Azure account variable configured as referenced here? I noticed your deployment is missing the Discovering Azure Web Applications targets step which is created when that variable is configured. I actually missed this variable myself originally and was seeing the same behavior.
As for your second question, what you are seeing is the currently intended behavior. It appears that the option to have separate roles and run conditions has been brought up before and could be considered down the road. I found one post on our User Voice forum which requests the ability to separate child step roles from the parent.
Let me know if this helps or if you have any other questions.
Thanks Dan, I’ll try that now. I added the variable but got confused on the link uses AzureAccount and that section uses Octopus.Azure.Account, renamed it and it works now thank you.
Regarding the the other issue is that I cannot now group these steps as once I do, the role is moved to the parent which only accepts a value from the drop down and it throws an error when trying to save the grouping. If I go back to the other way witha static deployment target it works fine because the parent step uses the drop-down role value.
That’s exactly what I did the first time around! I see what you mean about the role for the parent step as well. I actually noticed this after sending my last response so apologies for missing what you were saying. It does seem odd to me that you can no longer create a new role once you start grouping steps together. I don’t see any documentation explicitly explaining this so I will start some internal discussions on that one and get back to you when I have more information.
If you have any other questions in the meantime please let me know.
Sorry one more question. The dynamic targets are good for us as we are currently at 25 and to add another we would have to upgrade to 50 (I think) so could be expensive.
So it looks like that in oreder to run the dynamic targets I need to be less than 25 when running as creating the target (when we are at 25) puts us at 26 and throws an error.
Is this intended ? So if we deploy multiple web apps at once we would have to do them consecutively and not concurrently ?
Error running CreateDeploymentTargetOrchestrator for create-azurewebapptarget: You cannot create another target. This will exceed the limits of your current license. Please contact sales@octopus.com to upgrade your license.
That’s correct, based on your current license you can have no more than 25 total targets registered at a time (Infrastructure > Deployment Targets). The future plan is to add the ability to dynamically remove the targets as well, however for now you could tackle this with a script step.
We have an example script here on GitHub which would allow you to delete the targets based on the role. If you can adapt this to your deployment process you should be able to add and remove the targets on the fly and hopefully keep your count lower. Does that sound like it may work? Let me know if you have any other questions.
I’m not sure to be honest. We are going to have 30-50 web apps in Azure. Previously the containers were all hosted on one docker host and deploying multiple container was straight forward. Now we technically need 1 license per web app if we deploy more than 1 app at a time.
Even having the ability to disable (rather than delete) deployment targets that aren’t in use could create a massive headache, if we have to do another release for other parts of our estate - or some of the disabled targets aren’t re-enabled after a deployment error.
I’d be happy with a deployment target just for App Service that could be used to deploy multiple web apps (much like now on our docker server)
Let me ask around internally to see if we have any other options to help you out here. We have a few company holidays coming up here on Friday and Monday, but as soon as I have more information to pass along I will let you know.
