Some of web apps from time to time fails to deploy or breaks and I end up getting a 503 error. I took out the website run from package and it ran fine but i have a lot of apps for both web and function apps and I want to know why this happened. Do I still need to use it or not? Should I still use it or not? Is the WEBSITE RUN FROM PACKAGE causing these apps to break or is there another way to fix them? Does something need to be updated in my part through settings etc? I deploy all of my apps through the azure pipeline builds. This is bothering me a lot as I dont want my pipelines to break now esp when I send out releases. Much appreciated with any insight.
WEBSITE_RUN_FROM_PACKAGE is recommended way for deployment of Function Apps if you want to deploy using ZIP deploy.
When you are running the function and If your function is returning the 503 Service Unavailable, then check the Request-Response time because there is a time limit for request processing in Azure Function Http Request i.e., 230 Seconds available in this MS Doc. In this case, either increase the timeout value or change the Hosting Plan to higher or use async pattern in Azure Durable Functions for long running tasks.
If you are getting the 503 Service Error unavailable post-deployment, then it will be 2 causes mainly:
check your function host is down or restarting state.
Check the memory consumption exceeded your Hosting Plan limit (Consumption Plan - Functions) and also, check the troubleshooting steps given in this SO 71658591.
Updated Answer
I can See the bug raised in GitHub Azure Functions Repo earlier with the similar scenario that the user #qJake is getting 503 Service when deployed Azure Functions using Azure DevOps when using the setting WEBSITE_RUN_FROM_PACKAGE and resolved the issue-solutions given in the ticket #11444
Related
I am trying to use the "FREE" layer of Azure App Services using the GitLab Container Registry.
To do the DEPLOY I am using WebHook, but I am not having success. I call WebHook to start Deploy (via Postman) and when analyzing the deployment LOGs, nothing happens.
The strangest thing is that at times it works, but it seems to be only once a day.
I call WebHook as follows:
https://$<my-app>:<token>#<my-app>.scm.azurewebsites.net/docker/hook
Are there any limitations for being a free tier?
#Junior, please note that with Web Apps free tier there are a few quotas.
The two that you might be hitting are:
You can only use the CPU 3 out of every 5 minutes
You can only use the CPU 60 minutes every 24 hours
Source:https://learn.microsoft.com/azure/azure-resource-manager/management/azure-subscription-service-limits#app-service-limits
Windows Web Apps have a quota blade that allow you to see if you are actively hitting a quota. I would suggest checking there. Also check the diagnose and solve blade for your app to verify one of the above quotas are being hit.
I am using the Devops release pipeline to deploy new releases to my function apps.
However a few days ago, the release pipeline stopped working and I continue to receive the following error message on deployments:
Error: Error: Failed to deploy web package to App Service. Bad Request (CODE: 400)
After digging in the kudu stack trace, I find the following:
Error occurred, type: error, text: No space left on device
However, when I look at my quota usage on the app service plan that hosts my function apps, I have not even exceeded 1% of my quota. I am on a basic app service plan that provides 10gb of storage and my function apps combined have used 50mib.
I am reaching out to see if anyone else has/is currently experiencing this issue and what they did to resolve it.
Many Thanks!
Adam
Some advice for trouble shooting:
You can use the Kudu service to see the size of all the files on the Azure. This way you can further check your storage. Go to Azure portal -> Your_APP_Service -> development tool -> advanced tool to access Kudu service and download the extension. You can click this blog for detailed information.
The issue may be that your source code and output are too large. In this case, try using a self-hosted agent and clear the cache.
The reason for the issue may also be that the packages uploaded at one time are too large, which leads to the shortage of temporary files. Click on the link to see if you have exceeded the temporary file limit.
I had the same problem, I connected with ssh to app service and run:
$ df -h
and scale up (App service plan)(be careful the server IP can change)
And after run the pipeline, Its run Correctly, if you wish you can return to the previous plan.
If anyone encounters this issue in the future this may resolve your problem.
I believe the problem with deployments may have been caused by a corrupt function app in the app service plan. I noticed that the function app I recently added had been categorised as a container although I never specified it as such. Anyway, deleting that function app and recreating it resolved the issue. All deployments to that app service plan are now working fine!
I have a working azure web app, I cant deploy anything when I click Deployment center it just stuck at Fetching deployment data
If I wait for while I get this:
I have to mention that I had apps before on azure and everything worked smooth.. the only difference between the apps is that the broken app I created with azure VS extension.
all the apps are configured to auto-deploy from Bitbucket
For me, there wasn't enough space on the disk. I saw this "lack of space" error message after clicking Deployments in Kudu (Advanced Tools in your web app). I deleted the LogFiles folder to free up space and everything went back to normal.
I had the same problem with deployment sticking/breaking when I was trying to use the F (free) tier. I was trying to push a .NET Core app with https: support enabled in the app. Because the F tier does not support SSL, it broke everything and there was no trace to say what the problem was. Not sure if this was your problem as well, but if anyone is trying to do the same thing that I did, I hope this is helpful. Changing to an S (standard) tier fixed it. I suppose disabling https: support in the app you are trying to push would work as well, but I did not try that approach.
This happened to me last night. Finished up some changes to an API and front end app. API published to app service without issue from Github pipeline. Front end app would not publish. Error was:
Deployment Failed with Error: Error: Failed to deploy web package to App Service. Conflict (CODE: 409)
Same issue as here. The deploument center would never load and eventually would give me a Gateway Timeout error. Two hours I spent trying to figure out what was wrong. Even opened a support ticket. It was a problem with the Azure service that was resolved by the next morning.
I deployed a continuous WebJobs to my existing Azure WebApp using DevOps. It is up and running.
When I tried to stop the webJob in the Azure web frontend it did not work.
So I used the stop Command of the Azure WebApp API.
POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{name}/continuouswebjobs/{webJobName}/stop?api-version=2016-08-01
Surprisingly this call returned a 404 error.
However, when I executed the Get Continuous WebJob Command it returns all infos about the webJob, which means that it could be found.
GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{name}/continuouswebjobs/{webJobName}?api-version=2016-08-01
I also tried using the Kudu API.
POST /api/continuouswebjobs/{job name}/stop
However, the stop command resulted in the same 404 response message whereas the get command resulted in a positive result that the WebJob is in State "Running".
GET /api/continuouswebjobs/{job name}
Is there any reason for this behavior? How is it possible to start/ stop the webJob using the above mentioned post requests.
As it turned out the way I was deploying was the root of the problem.
Daniels answer to this question helped me a lot.
Basically you need to create a Virtual Application within your WebApp and then deploy your WebJob to this application from within Azure Devops.
When done this way you are in a position to successfully start/ stop the continuous webjob with all of the above mentioned APIs.
According to what I read here, the accepted answer's linked subject (worth reading!), and my own configuration problem that concerned only one project of our projects, I noticed that in our case, the webjob that causes the 404 error was not published with the same output directory, it was published with $(Build.ArtifactStagingDirectory)/My.Api/app_data/jobs/Continuous/MyWebjob instead of $(Build.ArtifactStagingDirectory)/My.Api/app_data/jobs/Continuous/
So in our case we don't use virtual applications.
What's your way to stop webjob in the front end?
And the API to stop a continuous webjob, you could try with this
POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{name}/continuouswebjobs/{webJobName}/stop?api-version=2016-08-01
Further more information, you could refer to this doc:Stop Continuous Web Job
I have an Azure Service Bus Trigger that has been working both locally and in our Azure environment. Unfortunately, I had been deploying this to a consumption service plan, and I need it on a regular service plan. All deployments have been via Visua Studio.
No problem, right? I deployed the exact same code to a different service plan (in the same resource group) and it does not work. Messages are not being taken off of the queue.
At first I thought it was a connectivity or configuration issue, but then I noticed that the function isn't listed under "Functions."
I realize that the difference service plan itself isn't likely to be the cause, but I can't figure out what else has changed. I have also redeployed this code using the Consumption Plan and the trigger works perfectly.
Thanks for the advice.
I've just checked the debug console for both versions and there's obviously a lot missing from the one that isn't working. Bummer that VS said the deployment was successful. Btw, the bad version is "running." I guess I'll have to deploy again with some verbose output to see if that helps.