Publish-AzWebApp is not working for Linux function app
Publish-AzWebApp -ResourceGroupName Default-Web-WestUS -Name MyApp -ArchivePath C:\\project\\app.zip
I am using the above command in powershell and running that powershell in CICD process. But that is not deploying the files to function app(App service deployed) which is in Linux.
Getting the following error:
Service unavailable
It is working fine for Windows.
The following reasons will result in a service unavailable error:
The function host is down/restarting.
Platform issue as a result of the backend server not being available/allocated
A memory leak in the code caused the backend server to return a service unavailable error.
The "Diagnose and solve problems" blade in the Function app should be used to select the "Function app down or reporting" detector.
The diagnostic information regarding the function app and its infrastructure will be displayed by this detector. This will provide some insight into the issues regarding function hosts. Also, look under the Web app restarted section to determine if any platform-related issues contributed to the service unavailable error.
As you are running on Linux platform, then you would get information about the container recycles in the Web app restarted detector.
Related
I ran into an issue while migrating an Azure app service from .Net Core 5 to 6 while also updating the stack configuration in Azure Portal to use .Net version ".Net 6 (LTS)". The app service only contains continuous webjobs that process service bus messages. Locally, the webjob project runs fine but when deployed to Azure it fails to start. In Kudu tools I'm presented with an error:
[01/03/2023 18:21:32 > 1b0f90: ERR ] Unhandled exception. System.IO.IOException: Failed to bind to address http://127.0.0.1:5000: address already in use.
[01/03/2023 18:21:32 > 1b0f90: ERR ] ---> Microsoft.AspNetCore.Connections.AddressInUseException: Only one usage of each socket address (protocol/network address/port) is normally permitted.
[01/03/2023 18:21:32 > 1b0f90: ERR ] ---> System.Net.Sockets.SocketException (10048): Only one usage of each socket address (protocol/network address/port) is normally permitted.
Eventually I am able to get past the error by applying the app setting ASPNETCORE_URLS=http://localhost:5001 to the app service, and applying the same app setting every .Net Core 6 app service running web jobs in the same app service plan except I have to increment the port to something different. This does not seem to be a problem with non-webjob applications, and only occurs when I configure the app service stack to ".Net 6 (LTS)" in Azure Portal.
My question is: Is there another workaround to this issue? I find adding unique port assignments to every webjob running .Net 6 to be a cumbersome and not ideal, and this issue will exist as a serious gotcha for future development.
Here is the dependencies I am pulling in:
Azure.Messaging.ServiceBus Version=7.11.0
Microsoft.Azure.WebJobs Version=3.0.32
Microsoft.ApplicationInsights.AspNetCore Version=2.21.0
Microsoft.ApplicationInsights.NLogTarget Version=2.21.0
Microsoft.Azure.Services.AppAuthentication Version=1.6.2
Microsoft.Azure.WebJobs.Extensions Version=4.0.1
Microsoft.Azure.WebJobs.Extensions.ServiceBus Version=5.3.0
Microsoft.Azure.WebJobs.Extensions.Storage Version=5.0.1
NLog Version=5.0.4
NLog.Targets.Seq Version=2.1.0
NLog.Web.AspNetCore Version=5.1.4
To reproduce:
Create two or more .Net Core 6 applications that only implement Webjobs. My Webjobs functions process Service Bus topic messages, not sure if this is important to reproduce.
Deploy the Webjob applications to the same App Service Plan
In the configuration blade settings tab for each web app make sure that the runtime stack is set to ".Net 6 (LTS)", keep the rest as default.
Now when you go to view the webjobs in Azure Portal you will see that the job is stuck in a restart cycle.
The problem seems to be around setting the stack settings version to ".Net 6 (LTS)". From this article it seems that this setting makes the app service Run Kestrel with YARP, I'm guessing the feature parity is not 1:1 with the previous stack.
Example project that can reproduce the issue can be found on Github. Follow README found in .\Scripts to deploy example to Azure.
Note: there seems to be an issue with the template setting the stack to .Net 6. This may need to be done manually post deployment to fully reproduce the issue.
I have created 2 .NET Core 6 Applications and deployed to Azure Web Jobs in same Azure App Service.
Make sure to enable Always On option in App Service => Configuration => General Settings to ensure WebJobs are running Continuously.
I have updated the Stack settings run time Version to .NET 6.
Now when you go to view the webjobs in Azure Portal you will see that the job is stuck in a restart cycle.
Yes, even I got stuck with the same issue. The WebJob which I have published 2nd is showing the Pending Restart status.
When I click on the Logs, I can see the below error is Logged.
Make sure that you are setting a connection string named >`AzureWebJobsDashboard` in your Microsoft Azure Website >configuration by using the following format >`DefaultEndpointsProtocol=https;AccountName=**NAME**;Account>Key=**KEY**` pointing to the Microsoft Azure Storage account where >the Microsoft Azure WebJobs Runtime logs are stored.
In the second Console App, I haven't Configured the WebJobs and Storage Account.
Updated the code and published again.
Now I can see both the Jobs are in Running State.
My Program.cs file:
// See https://aka.ms/new-console-template for more information
using System.Threading.Tasks;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;
namespace WebJobApp
{
class Program
{
static async Task Main()
{
var builder = new HostBuilder();
builder.UseEnvironment(EnvironmentName.Development);
builder.ConfigureWebJobs(b =>
{
b.AddAzureStorageCoreServices();
b.AddAzureStorageQueues();
});
builder.ConfigureLogging((context, b) =>
{
b.AddConsole();
});
var host = builder.Build();
using (host)
{
await host.RunAsync();
}
}
}
}
Reference taken from MSDoc.
My issue:
When I try access the main URL for my web app, Azure replies with a '403 - You do not have permission to view this directory or page'.
Context:
I have deployed a Python webapp to Azure using the Pipeline/Release on DevOps (Azure Web App Deploy task seems to run successfully with the artifact generated by the Pipeline). I have previously deployed Python Function Apps successfully with a similar pipeline (different app type of course, and sku).
The Kudu SCM page works e.g.,: myapp.scm.azurewebsites.net
All logs seem to indicate the webapp deployment was successful. If I use CMD or Powershell from the SCM, I can see my app.py (for Flask) is in the correct location. The deployment has my requirements under the site packages installed including Flask.
The app runs quite successfully on my local machine via 'flask run', after I activate the virtual environment.
Yet when I try connect to myapp.azurewebsites.net, I get a 403 on the plain route. Anything after it like /test or /myapi returns a 404.
Something I do not see in any of the logs I can access via Kudu is mention of 'gunicorn', which I believe is what Azure uses by default. I just want to see some kind of log output somewhere to show that flask or gunicorn or something has successfully loaded app.py and is listening for incoming connections.
Maybe you do not know why I would get 403's, but you might know where I should be seeing the aforementioned logs.
TIA for any suggestions.
EDIT:
Something to add is that if I enable logs, and connect to the logstream then I do see logs generated as I access Kudu. This suggests some Application & Web Server are running - at least for whatever container runs that side of things.
It even notes the failed connections from Postman for the actual myapp.azurewebsites.net, but has nothing other than a line indicating that there is a 403.
My app has been stripped down to the most bare app.py with no includes other than Flask and routes which simply return a string. Most includes in requirements.txt have also been stripped out.
Still same issue.
I do have an answer after a couple of days worth of pulling my hair out.
Turns out that the 403's were not actually a permissions issue.
az webapp list-runtimes --os windows
The list shows no runtimes available for Python/Flask Web App. This is why I could not find any gunicorn or Flask logs - neither are set up. Azure deployed the artifact's zip and called it a day.
To rectify this, the DevOps Pipeline/Release must run on Linux. The Azure Web App Deploy task, when set to "Web App on Linux", will have Python runtime stacks available. Once selected, these will allow for a startup command to be specified. (Such as flask run --host=0.0.0.0 --port=8000)
Furthermore in azuredeploy.json the "Microsoft.Web/serverfarms" must have a "kind" specified to include "linux". It also requires:
"properties": {"reserved" : true}
Once deployed, logs indicate that docker is being set to an internal port of 8000 while the default 'flask run' which is executed would use 5000.
Ideally: use gunicorn with port mapping but, to get things going, tell flask to use port 8000.
I've deployed and published several Function Apps without issues over the last 12 months. However, as of this week, when publishing a Function App using the following PowerShell script:
func azure functionapp publish <functionAppName> --java
I will receive the following error after a few minutes: "Timed out waiting for SCM to update the Environment Settings"
Similarly, I'm also unable to deploy any Function Apps, using:
mvn azure-functions:deploy
In the Function App activity log, the following error is logged for both cases:
Operation name: Sync Web Apps Function Triggers.
Status: Failed.
Error code: BadRequest (HTTP Status Code: 400)
Message: Encountered an error (InternalServerError) from host runtime.
So far I've created the Application setting WEBSITE_WEBDEPLOY_USE_SCM (value: true) based on feedback in another topic, which unfortunately hasn't helped. Other than that I've not been able to find much other information on this issue.
Does anyone have any thoughts?
Resolved this issue myself. The Application Setting WEBSITE_CONTENTAZUREFILECONNECTIONSTRING contained an outdated storage account key.
I'd like to add an offsite Windows VM to Azure Arc for health monitoring. The VM is hosted by Vultr and runs Windows Server 2016 Standard Build 14393.
However, installing AzureConnectedMachineAgent.msi on the target VM fails with error code 1603. Installation log also contains this error:
Start-Service : Service 'Guest Configuration Extension service
WixQuietExec64: (ExtensionService)' cannot be started due to the following error: Cannot start
WixQuietExec64: service ExtensionService on computer '.'.
WixQuietExec64: At C:\Program Files\AzureConnectedMachineAgent\ExtensionService\GC\Modules\Exte
WixQuietExec64: nsionService\ServiceHelper.psm1:367 char:5
Any suggestions on how to fix this?
You may Check if the user with which you are logged into the VM have
sufficient permissions to start a system service
If you find the following in the
%ProgramData%\AzureConnectedMachineAgent\Log\himds.log or in installation logs :
time="2021-02-11T08:39:38-08:00" level=error msg="Cannot open event source: Azure Hybrid Instance Metadata Service."
You can verify the permissions by collecting the following registry
key from an impacted server.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog\Application\CustomS
Mitigation can be to grant the permission to write to the
SECURITY_SERVICE_RID S-1-5-6 which would grant the required
permissions to the himds service account.
https://learn.microsoft.com/en-us/windows/win32/secauthz/well-known-sids.
If the registry key does NOT exist on the impacted VM, then this
resolution will NOT apply as there will be a separate root cause such
as AV interference.
If the root cause is not found here ,then a procmon trace needs to be
taken to analyze the root cause for the msi not being able to start a
service.
( In case a procmon trace has to be analyzed , please open an MS
Support ticket)
To get support for Windows Agent and extensions in Azure, the Windows
Agent on the Windows VM must be later than or equal to version
2.7.41491.911. However the cause for the failure of agent installation is different in this case.
You may also want to check %programdata%\ext_mgr_logs\gc_ext_telemetry.txt log which must have had an entry something like this :
<GCLOG>........ Not starting Extension Service since machine is an Azure VM</GCLOG>
Cause:
This can happen while attempting to install the agent on an Azure VM.This is an unsupported production scenario.One Should not be installing this agent on an Azure VM as it conflicts with the Azure Guest Agent and interferes with Azure VM management.
If one wishes to use an Azure VM simply for testing purposes then
they can follow the below document for guidance
https://learn.microsoft.com/en-us/azure/azure-arc/servers/plan-evaluate-on-azure-virtual-machine
I followed a tutorial on deploying a simple Node app from VSCode using the Azure App Service extension.
The app runs fine locally.
When I deploy I get this output:
Creating resource group "appsvc_linux_centralus" in location "centralus"...
Successfully created resource group "appsvc_linux_centralus".
Ensuring App Service plan "appsvc_linux_centralus" exists...
Creating App Service plan "appsvc_linux_centralus"...
Successfully created App Service plan "appsvc_linux_centralus".
Creating new web app "XXX-node-users-api"...
Created new web app "XXX-node-users-api": https://XXX-node-users-api.azurewebsites.net
21:28:12 XXX-node-users-api: Creating zip package...
21:28:33 XXX-node-users-api: Starting deployment...
Error: The service is unavailable.
In the portal there is nothing listed in Diagnose and solve problems. How can I tell why the service in unavailable (which it does show when I click on the link)?
UPDATE:
I followed the same process with a different Node app (which I got from another MS tutorial) and I got this:
Using existing resource group "appsvc_linux_centralus".
Ensuring App Service plan "appsvc_linux_centralus" exists...
Successfully found App Service plan "appsvc_linux_centralus".
Creating new web app "nodejs-docs-hello-world-20190805"...
Created new web app "nodejs-docs-hello-world-20190805": https://nodejs-docs-hello-world-20190805.azurewebsites.net
22:13:06 nodejs-docs-hello-world-20190805: Creating zip package...
22:13:07 nodejs-docs-hello-world-20190805: Starting deployment...
22:14:31 nodejs-docs-hello-world-20190805: Fetching changes.
22:14:31 nodejs-docs-hello-world-20190805: Cleaning up temp folders from previous zip deployments and extracting pushed zip file /tmp/zipdeploy/59khfmlp.zip (0.00 MB) to /tmp/zipdeploy/extracted
22:14:31 nodejs-docs-hello-world-20190805: Central Directory corrupt.
Error: Deployment to "nodejs-docs-hello-world-20190805" failed. See output channel for more details.
I get the feeling I'm doing something obvious wrong or the extension is mangling the code. Where do I start?
Thanks
I tried to deploy my app (the first one I tried to deploy to Azure) to Heroku which in comparison was simple and the logs trivially easy to get.
Doing this pointed to two changes I needed to make. I could then deploy to Azure using the VS Code extension.
There was not a npm start script in package.json so I added one.
The port was being set statically. Which, for Heroku at least, is not allowed. Changed
var server = app.listen(3000, function () {
to
var server = app.listen(process.env.PORT || 3000, function () {
Interestingly the second repo I tried already used both of these techniques so I'm no wiser as to how I might address that.