【應用服務 App Service】App Service使用Git部署時,遇見500錯誤

路邊兩盞燈發表於2020-10-27

問題描述

Azure App Service在部署的時候支援多種方式,如Zip,VS 2019, VS Code,或者是Git部署,當使用Git部署遇見500錯誤時,可以通過其他的部署方式來驗證是否也同樣不可以成功。也可以直接登入到Kudu站點,拖拽檔案的方式部署站點。

如以下圖片就是在使用Git部署時候遇見的錯誤:

【應用服務 App Service】App Service使用Git部署時,遇見500錯誤

由於這裡的錯誤資訊只是返回500,而沒有跟多詳細的錯誤日誌,所以可以通過 git log -p 命令列印出全部日誌。檢視是否有可以定位錯誤的資訊,在這次的500錯誤中,git 日誌中沒有任何錯誤描述。

 【應用服務 App Service】App Service使用Git部署時,遇見500錯誤

所以針對以上的問題,需要換一種方式來發布檔案。檢視是否可以釋出成功。

最終解決

在後期的繼續分析中,發現是App Service的磁碟空間已被佔滿,出現了OnErrorRequest System.IO.IOException: There is not enough space on the disk的資訊,這下就非常明確是磁碟空間不夠,解決辦法就是清理檔案或者是把App Service的定價層升級。得到更多的儲存空間。

 

如果想了解更多關於App Service 檔案系統,可以檢視github文件:https://github.com/projectkudu/kudu/wiki/Understanding-the-Azure-App-Service-file-system

Understanding the Azure App Service file system

There are three main types of files that an Azure Web App can deal with

Persisted files

This is what you can view as your web site's files. They follow a structure described here. They are rooted in d:\home, which can also be found using the %HOME% environment variable. For App Service on Linux and Web app for Containers, persistent storage is rooted in /home.

These files are persistent, meaning that you can rely on them staying there until you do something to change them. Also, they are shared between all instances of your site (when you scale it up to multiple instances). Internally, the way this works is that they are stored in Azure Storage instead of living on the local file system.

Free and Shared sites get 1GB of space, Basic sites get 10GB, and Standard sites get 50GB. See more details on the Web App Pricing page.

Temporary files

A number of common Windows locations are using temporary storage on the local machine. For instance

  • %APPDATA% points to something like D:\local\AppData.
  • %TMP% goes to D:\local\Temp.

Unlike Persisted files, these files are not shared among site instances. Also, you cannot rely on them staying there. For instance, if you restart a web app, you'll find that all of these folders get reset to their original state.

For Free, Shared and Consumption (Functions) sites, there is a 500MB limit for all these locations together (i.e. not per-folder).

For Standard and Basic sites, the limit is higher and differs depending on the SKU. The limit applies to all sites in the same App Service Plan. For instance, if you have 10 sites in S2 App Service Plan, those sites (and their scm sites) will have a combined limit of 15 GB. See limit for other SKU below.

SKU FamilyB1/S1/etc.B2/S2/etc.B3/S3/etc.
Basic, Standard, Premium 11 GB 15 GB 58 GB
PremiumV2, Isolated 21 GB 61 GB 140 GB

Another important note is that the Main site and the scm site do not share temp files. So if you write some files there from your site, you will not see them from Kudu Console (and vice versa). You can make them use the same temp space if you disable separation (via WEBSITE_DISABLE_SCM_SEPARATION). But note that this is a legacy flag, and its use is not recommended/supported.

You can check your limit and usage in portal by going to "Diagnose and solve problems" section of your App Service blade, selecting "Best Practices", "Best Practices for Availability, Performance", and then "Temp File Usage On Workers". Please note that the displayed usage and limits are per worker, and are aggregated across all apps in the same app service plan.

Machine level read-only files

The Web App is able to access many standard Windows locations like %ProgramFiles% and %windir%. These files can never be modified by the Web App.

相關文章