So we are deploying a new application to an existing Azure App Service (Linux) we were able to initially deploy fine but suspect our application doesn’t run because the previous prototype version of our application is still there.
So we changed the Process step for the Azure App Service deployment such that the following was configured
Remove Additional Files: Files in the destination that are not part of the deployment will be removed
Now when it comes to get rid of the unwanted files we get:
Now the Azure Service Principal our deployments run under is a Contributor on the App Service however this does not seem to give it the necessary rights to get the job done. We are reluctant to make it the Owner of the App Service as it could then have the rights to do bad things like delete the App Service.
Any advice on what level / specific permissions the Service Principal requires to get the job done?
I always find this a little tricky to get right on Azure. Owner access is useful in some use cases, for instance in cases where you are spinning up and spinning down resource groups, Web Apps, Databases then you will definitely need more access than most are comfortable. I use Runbooks for my provisioning and destruction of Web Apps and I use Owner here so I can create these as and when I need to. You can see a sample of this on Octopus Samples using Guest Authentication. This is a sample where I provision and destroy the Infrastructure each day. This needs access to create Resource Groups, App Services, DB’s and then deploys the database and the code to the Web App.
An approach is to have multiple Azure Service Principals for different tasks. This does add a layer of complexity but having multiple ASP’s will mean you can select the correct account for the correct process.
One way to deal with this is to use a custom role in Azure that you can assign to your Service Principal. For this to be supported you would need to have Azure AD P1 or P2 and I’m not aware if this is something you could do. You can read more about this in the Azure Docs.
Another approach here is to use slots in Azure Web Apps and then switch the slot round as part of the deployment. You could deploy to a staging slot and then switch round the slots. This avoids adding additional permissions as you can deploy to an empty slot and then switch them round. The benefit with Slots is that you can create them using Azure PowerShell
#Remove the staging slot if it exists
Remove-AzureRMWebAppSlot -Name #{WebSite} -Slot Staging -ResourceGroupName #{ResourceGroup} -Force -ErrorAction Continue
#Create the staging slot
New-AzureRMWebAppSlot -Name #{WebSite} -Slot Staging -ResourceGroupName #{ResourceGroup}
Something I should add is that we do not have direct access over our App Services, ResourceGroups etc, a third party consultant manages then on our behalf, spinning them up and down on demand is not currently an option.
We do currently make high use of slots, we do deploy to a staging slot already then swap to production, however these slots already contain the problematic files. I will look to create a new slot and see if it contains the problematic files to begin with, if it does that won’t help. If they don’t then by doing some careful swaps may be able to get rid of problematic files.
If not it will be a case of determining exactly what permissions are required to delete the files with WebDeploy and see if we can apply those to the principal. Any further info Octopus could provide in this area would be appreciated.
When creating a slot it should start with an empty file structure which you can then populate with items from your Package. It may be worthwhile trying to create a slot that isn’t named Staging as this is a common naming pattern and I expect what might be happening is that the slot is never removed at the end of the deployment process and that’s why it contains files.
I’ve just tested this on one of my demo apps… I did the following:
Browsed to my App
Created a slot called Pre-Deployment
Browsed to Pre-Deployment Slot URL and confirmed the Microsoft default site loaded.
Tested Production Slot and confirmed the main site was working.
Switched slots and in the main URL, the default Azure Web App site loaded.
The slot switch worked as expected. It feels like the problem is that the slots are not empty and that’s why you’re seeing this issue.