问题描述
Azure App Service在部署的时候支持多种方式,如Zip,VS 2019, VS Code,或者是Git部署,当使用Git部署遇见500错误时,可以通过其他的部署方式来验证是否也同样不可以成功。也可以直接登录到Kudu站点,拖拽文件的方式部署站点。
如以下图片就是在使用Git部署时候遇见的错误:
由于这里的错误信息只是返回500,而没有跟多详细的错误日志,所以可以通过 git log -p 命令打印出全部日志。查看是否有可以定位错误的信息,在这次的500错误中,git 日志中没有任何错误描述。
所以针对以上的问题,需要换一种方式来发布文件。查看是否可以发布成功。
最终解决
在后期的继续分析中,发现是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 likeD:\local\AppData
.%TMP%
goes toD:\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 Family | B1/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.