We would like to have a single Azure App Service that hosts both our front end and API. In order to achieve this we would like to have two virtual applications set up as so:
When our project is built a nupkg is created with the following folder structure:
I have used both the Az CLI and the new Az PowerShell
Publish-AzWebApp cmdlet to deploy this as a zip archive and this works fine. However, because Octopus only supports the older Azure RM PowerShell module which doesn’t have an equivalent
Publish cmdlet I opted to use the “Deploy an Azure Web App” step in Octopus.
When I run this step instead of putting the contents of nupkg in the
site\wwwroot folder on the app service, the contents are instead uploaded to
site\wwwroot\website, as seen in the screen shot below.
This then obviously leads to the site not starting because IIS does not find any applications in the physical paths that have been registered. It seems to me that Octopus is querying the web app to find its virtual application paths and then deciding to deploy the application to the physical path that maps to the
/ virtual path.
To be clear, I do not have anything set in the
Physical Path property of the Octopus step and if I do set that to a value of
foo, for example, then Octopus will deploy the contents of the nupkg to
site\wwwroot\website\foo. Also, I have run further tests to confirm this behaviour by changing the App Service to have a single virtual application which maps
\ (the default setup). Octopus will then deploy the files to
site\wwwroot but again the application will still fail to start as there is no application entry point in the root of our nupkg.
It seems to me that I have a couple of options:
- Change the structure of the nupkg so that the website project is published to the root with a subfolder for the API. I can revert the first virtual application back to the default physical path and Octopus will deploy the contents to the
wwwrootfolder and the application path mappings will match again.
- Run some PowerShell pre-deployment to temporarily change the virtual application paths and then revert them after deployment.
Option 1 is undesirable to me as I would rather keep the projects in separate folders to avoid potential weirdness from having applications nested inside of each other on disk and 2 is undesirable as it make the deployment process more complicated. Is there another way around this or am I doing something more fundamentally wrong with the way the virtual applications are structured?
Please could you advise?