Why does the wardeploy api require WAR files to be zipped up?

Question

I currently am trying to deploy a WAR file to a Tomcat instance in AZ Web Apps and I'm using the following command (with a few redactions), for reference I'm using this official documentation:

curl -X POST -u <myuser> --data-binary @<mywar>.war https://<mysite>.scm.azurewebsites.net/api/wardeploy  

After successfully authenticating to the end point, the deployment starts, fails, and the log files are infuriatingly vague and this is all they state:

Cleaning up temp folders from previous zip deployments and extracting pushed zip file /tmp/zipdeploy/c4918393-3970-4860-b564-8f026cfa23d3.zip (0.02 MB) to /tmp/zipdeploy/extracted
End of Central Directory record could not be found.

This error gave me a weird hunch that it was trying to do some sort of zip operations on the WAR file and failing. Given there's also a zipdeploy API on the same documentation page I decided to put the WAR file into a zip and re-ran the same command to the wardeploy API and surprise surprise it happily shipped it off this time. Admittedly it didn't correctly mount the WAR file (it ends up in .../wwwroot/webapps/ROOT but doesn't unpack into files) but I'm utterly confused as to why this deployment method to the dedicated wardeploy api only seems to work if the file is wrapped in a ZIP.

Any thoughts? It's like the zipdeploy API has been copied to the wardeploy endpoint and someone forgot to change it, either that or I'm somehow doing something incredibly wrong even though I'm following the documentation.

Answer 1

@Paul Webby , Thanks for the great question. To provide detailed insights on this, the post may be little longer.

In regards to how wardeploy works - wardeploy builds on top of zip push deploy. In simplest terms, it takes over the unpacking of the WAR file from Tomcat by unpacking it by itself. The WAR file is unpacked to a temporary location and the unpacked contents are then copied over to the appropriate directory in /home/site/wwwroot/webapps. While doing this, only the files that have changed since the previous deployment are copied.

This works great with scaled out web apps as Tomcat no more performs the unpacking, thereby eliminating the race conditions.

By default, wardeploy deploys to the ROOT app.

Optionally, you can simply use the query parameter name to specify the name of the app you want to deploy to: /api/wardeploy?name=NAME_OF_APP.
-For example, /api/wardeploy?name=myapp will deploy to the /home/site/wwwroot/webapps/myapp directory instead of /home/site/wwwroot/webapps/ROOT.

Whereas,

MSDeploy unzips and lays out the artifacts; you require VS or MSDeploy tooling to generate MSDeploy zip package. If you are using other tooling such as typical zip tool, the MSDeploy may not understand why the content resulting in unintelligible error such as certain directory not found or create file operation failed. The content in the zip is usually not the same as the outcome on d:\home\site\wwwroot.

ZipDeploy is intended for xcopy or ftp style deployment. It unzips the artifacts and lay them out exactly to d:\home\site\wwwroot. In this case, you can use any tooling (included with Windows) to zip your content.

By default, the Zip package will be deflated to d:\home\site\wwwroot as is.

-Optionally, to allow Zip package deployed with ZipDeploy to mount as virtual filesystem directly without deflating or extracting, you can set
appSettings WEBSITE_RUN_FROM_PACKAGE=1. This setting does not work with MSDeploy.

See this doc for more details.

Hope this helps!