I have a Java web app that I run on an Azure App Service instance. To deploy it, I use a Bitbucket repo with a .war file inside it. When I commit a new .war file to this repo, it is supposed to be deployed automagically by the service. However, more often than not, I have to either restart, re-deploy, or even upload the .war file via FTP for the deployment to be completed successfully.
I have a single Jetty instance residing in this service, hence my .war file is named ROOT.war. AFAIK, when uploaded to the service (whether via Bitbucket or FTP), this .war file should be unarchived into the same directory, which is /site/wwwroot/webapps. In my case, this doesn't happen. The web app works with the ROOT.war file sitting alone inside /site/wwwroot/webapps. And every once in a while, I get a ROOT folder under /site/wwwroot/webapps, with two default files index.jsp and background.png. I don't have the slightest idea what causes the ROOT folder to appear with these default files. The only clue I have is that it happened a couple of times after I changed an environment variable.
Also after the ROOT folder appears with the empty server files, the only way I can re-deploy the app is to manually delete this ROOT folder via FTP or the console provided in the portal, and only then my re-deploy request succeeds with my web app.
So, if it isn't clear enough, my question is what is going on here? I can't make anything out of the behaviors I'm facing. I feel like I'm using this Azure service blindly, and can't get to fix anything when something goes wrong. Are there any resources that may explain what happens in the background when a web app is deployed?
So, Azure API Apps are a PAAS, not IAAS service. You can access the PaaS platform by coming to yoursite.scm.azurewebsites.net, where you can browse the file system in CMD or Powershell, and you can see the running processes. This may feel like you are on a single VM, but you are not. The data you see here is replicated down into your API App instances. You can control how many instances you have through scaling your API App.
I have commonly seen your issue with deploying, then ROOT being empty(working internally to see this fixed...). The best method that works every time for me, is to stop your API App, manually UNZIP your ROOT.war. Move the files into /ROOT/, then to start your API App.
You can simply place ROOT.war, and let the system unpack it when you turn it back on, but this can sometimes lead to that empty ROOT directory, then requiring another restart.
All of this has me moving to Spring-Boot instead. No unpacking required. Simply configure your web.config and drop the jar file.
https://docs.microsoft.com/en-us/azure/app-service-web/web-sites-java-custom-upload#springboot
I had the same problem. The solution is to call the endpoint after de deploy.
The four-step is very important and start the process that you mentioned before (the automagically deploy).
I lost a lot of time figuring out what was the problem.