Azure WebApp Github deployment using ZipDeploy - package not working

Question

Azure WebApp Github deployment using ZipDeploy - package not working

kaitlynm 21

Azure shows my deployment was successful and the latest deployment is active. GitHub workflow logs show success on each step with Package deployment using ZIP Deploy initiated and Successfully deployed web package to App Service displayed when deploying via workflow running azure/webapps@v2. This caused an error '403 forbidden - You don't have access to this resource' when trying to access via the app service URL. When attempting to fix this error in the Kudu bash console and viewing the associated application logs, while azure is running the startup script, it was returning an error explaining it could not find or access some files in the root directory. See error shown in Azure application logs below.

The configuration used for the pipeline is GitHub repo only contains the WordPress custom theme files, GitHub workflows and other necessary files that regard the application of the custom theme (No Wordpress installation, nodemodules etc). The workflow then automatically pushes the changes to the repo to Azure by using the Azure WebApp Zip Deploy service. This is why I was confused when the output was this error related to missing the root files such as index.php, as these files would have already existed on the Azure server wwwroot folder and the repository or deployment is unrelated to the location or existence of this file.

Looking into the contents of wwwroot on the Kudu scm site, all the files for the whole application are there as expected. However, the timestamps for each directory/file in wwwroot show that the new component files I had pushed through GitHub were missing and and changes to the existing files had not been pushed it to the Azure Web app. Some files had the timestamp of a previous deployment that had similar issues to this one, but none have a timestamp for the latest deployment made today 23/02/2022.

The only way to stop the error 403 forbidden is to remove the WEBSITE_RUN_FROM_PACKAGE="1" setting from Configuration within the Azure portal. Then restarting the server results in the website URL being accessible but still outdated content. Due to this, I looked into deployments being generated by the Azure ZipDeploy process, the deployment zip's contain everything from the Github repository as expected. I know the site is now only running and not returning the same 403 error because I have disabled the website using the package but I need to run the site this way.

I assume the whole issue is due to an problem with the running the deploy.sh as my latest deployments have different log data compared to previous deployment logs, mine state Skipping build and Post build, both with Project type: Run-From-Zip. This also confuses me as I thought the deployment should be run from the package created, rather than the actual Zip file. I'll attach a copy of the previous deployment log and my latest deployment log to show what I mean by the above.

Further to this, if I use an FTP software - in my case FileZilla - to access the site's data, within the directory 'site' > deployments : all the existing deployments are located here and I started investigating into the differences between my deployments made and the previous deployments which were truly successful by identifying the active deployment and the most recent deployment that truly was successful. The only difference is the new deployments are not generating a manifest file which all the previous successful deployments contain and the log files have a much larger file size in comparison which makes me believe something is not right regarding the deployment script - deploy.sh - running.

I'd ideally like to get the site running the latest code I have deployed to Github by using the ZipDeploy generated package. Any help would be appreciated :)

3 answers

Your answer

Answer 1

kaitlynm-1035, Thanks for sharing a detailed description of the issue.

Just to highlight on how it works - I understand your requirement and as you indicated - zipdeploy is intended for fast and easy deployments from development environments, as well as deployment of ready-to-run sites built by continuous integration services such as Visual Studio Team Services.

Unlike other Kudu deployment mechanisms, Kudu assumes by default that deployments from zip files are ready to run and do not require additional build steps during deployment, such as npm install (or dotnet restore/dotnet publish).
However, this can be overridden by setting the SCM_DO_BUILD_DURING_DEPLOYMENT deployment setting to true, or by specifying custom script generator arguments or a custom deployment script [As in your case].

Kudu handles continuous deployments and provides HTTP endpoints for deployment, in your case - zipdeploy.
Yes, when you deploy a ZIP package, App Service unpacks its contents in the default path for your app (D:\home\site\wwwroot for Windows, /home/site/wwwroot for Linux).

However for FTP and WebDeploy, these mechanisms do not go through Kudu.

Kindly let us know I'll follow with you further investigation (privately)

ajkuma 28,036 Reputation points Microsoft Employee Moderator

2022-02-25T06:16:53.987+00:00

Adding more info:

By default, the deployment engine assumes that a ZIP package is ready to run as-is and doesn't run any build automation.
So, to enable the same build automation as in a Git deployment, set the SCM_DO_BUILD_DURING_DEPLOYMENT app setting.

To disable this, such as when performing deployment of an already-built site, set:

SCM_DO_BUILD_DURING_DEPLOYMENT=false
--The default for zip deployments is false, and for all other deployment methods is true.

Answer 2

kaitlynm 21

@Anonymous I cant seem to reply to any of your messages, I don't know why.
I'm not sure my changes to the WordPress theme repo when pushing are being packaged correctly as the packages found in the deployments directory in the app are missing a file called manifest which was generated each time the previous developer made deployments but specifically missing from every one of my attempted deployments. Further to this, the deployment logs found in the Azure portal for the deployments I have tried show a different range of steps compared to the previous developer's deployments, that were successful and I have shown that comparison with the images above. I assume my deployment logs should be running the same steps as the previous deployments as the YAML workflow file on GitHub has not been changed and I'm still using the zip deploy method through GitHub actions as a continuous deployment which is how it was previously set up. The workflow does run build commands like NPM before using the zipdeploy service to deploy to azure.

However I don't know what is going wrong with the packaging or unpacking that is causing the site to run the 403 forbidden error, which is caused by missing files in wwwroot, whenever the configuration setting WEBSITE_RUN_FROM_PACKAGE is set to 1.

Please do let me know if that setting is incorrect for Zip Deploy as I mentioned before, I haven't used AZURE for web application deployment, but from reading the official documentation online I assumed to configure continuous deployment using Zip Deploy and Github actions that the WEBSITE_RUN_FROM_PACKAGE setting was needed as it replaced the WEBSITE_RUN_FROM_ZIP setting.

ajkuma 28,036 Reputation points Microsoft Employee Moderator

2022-02-28T13:33:44.283+00:00

@kaitlynm , Apologies for the delay in responding over the weekend and the issues you'd experienced with the Q&A platform (I'll relay this feedback to your platform team).

I understand you have checked some logs. If you haven’t done this already, please enable App Service Logs for the app.

1.Navigate to your Web App in the Azure Portal, select App Service Logs.
2.Enable Application Logging (FileSystem)
3./repro’ the issue/behavior
4.Navigate through Kudu site on: https://<yoursitename>.scm.azurewebsites.net/api/logs/docker
5.Review first docker.log.

As mentioned above, The WEBSITE_RUN_FROM_PACKAGE app setting is set, this command doesn't extract the package content to /home/site/wwwroot directory of your app.
Instead, it uploads the ZIP file as-is to /home/data/SitePackages, and creates a packagename.txt in the same directory, that contains the name of the ZIP package to load at runtime.
As a side note, via ARM template, review the dependencies required.

WEBSITE_RUN_FROM_PACKAGE - Makes wwwroot read only.

To investigate this issue further, I’ll need additional info about your WebApp and subscription (for this I’ll reach out you privately). Please do not share any PII data publicly.
kaitlynm 21 Reputation points

2022-03-01T11:15:20.893+00:00

@Anonymous No worries for the delay and thanks for relaying the feedback about the Q&A platform.

I had enabled App Service logging and analysing some logs but not the docker logs. Reviewing the first docker log just shows the same error I was explaining above being repeated on around 300 lines:

2022-03-01T00:01:09.980193790Z [Tue Mar 01 00:01:09.980004 2022] [autoindex:error] [pid 41] [client 172.16.2.1:11245] AH01276: Cannot serve directory /home/site/wwwroot/: No matching DirectoryIndex (index.php,index.html,default.htm,default.html,index.htm,index.html,index.php,hostingstart.html) found, and server-generated directory index forbidden by Options directive

This is the error I'm focused on resolving and caused the confusion surrounding WEBSITE_RUN_FROM_PACKAGE config. setting. Thanks for the help thus far, I may need a further investigation if the above error message doesn't give you much of a clue.
ajkuma 28,036 Reputation points Microsoft Employee Moderator

2022-03-02T13:43:47.527+00:00

@kaitlynm , Thanks for the follow-up and sharing the requested details. I'm reaching out to you privately to help investigate this issue further.

Answer 3

kaitlynm 21

@Anonymous As this is an issue with my workplace's web application that we are investigating, I will need to talk to my superior to get an approval before continuing with this route to fixing the issue. I will liaise with him this week some time and should get back in touch with the contact details you provided and follow up as soon as possible to work with you on fixing this issue. Hope you understand the delay and I look forward to your specialised assistance.

Thanks once again for all the guidance done so far and for your patience

kaitlynm 21 Reputation points

2022-03-08T15:10:00.08+00:00

@Anonymous Additionally, I think the issue will relate to this part of the documentation you sent the link for:

Best Practice

It is strongly recommended that this setting to be set at app creation time and immutable thru out the lifetime of an app. In fact, there is no scenario that one would need to change this setting occasionally or especially during deployment. Modifying this will cause the deployment and app runtime to behaviour incorrectly, guaranteed downtime and data loss perception (deployed files are not where they are expected) - imagine swapping a hard drive while installing a software to a computer.

I believe this as I when I joined the company and began the deployment stages, I had to re-configure the deployment connection to the GitHub repo as it had been lost somehow and then may not have added the setting before trying a deployment as I did not know it was required at the time due to the lack of experience using Azure, especially a pipeline. It seems highly likely that ruined the configuration of the application based on the WEBSITE_RUN_FROM_PACKAGE setting best practice.
ajkuma 28,036 Reputation points Microsoft Employee Moderator

2022-03-08T18:39:09.377+00:00

kaitlynm-1035, Thanks for the follow-up and your great feedback. No worries, I completely understand the situation. Whenever you are ready, we can work on this further.
And, to your 2nd comment- thanks for sharing your analysis. Yes, it could be related to lack 'settings' at the time app creation| as per the doc (Best Practice).

Share via

Azure WebApp Github deployment using ZipDeploy - package not working

3 answers

Your answer