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.
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.
I have browsed various questions here on SO, but none seem to have helped.
So, I have the following setup on Azure. I had a simple flask app running, which I could access using https://xyz.azurewebsites.net.
I was trying to look at the example here (https://learn.microsoft.com/en-us/azure/active-directory-b2c/configure-authentication-sample-python-web-app?tabs=linux). I can reproduce this example fine when I have the local server running and specifying the redirect uri as http://localhost:5000/getAToken.
Now, I want to use my deployed app, so I changed the redirect URI in the azure portal under authentication as
https://xyz.azurewebsites.net/getAToken
However, this always returns the redirect URI mismatch error.
On the flask side, I have kept the configuration as:
REDIRECT_PATH = "/getAToken"
Although I tried putting the full absolute URL as well and it did not work.
I have followed the same document which you have provided and able to access the Application even after deploying to Azure App Service.
In app_config.py, change the authority_template to
authority_template = "https://{b2c_tenant}.b2clogin.com/{b2c_tenant}.onmicrosoft.com/{signupsignin_user_flow}"
OR
Copy paste the tenant and user_flow value directly.
authority_template = "https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{user_flow}"
Local Output:
Deploy the Application to Azure App Service:
Create a new repository in GitHub and push the VSCode to it.
OR
If you face any issues in pushing the code to Git.
Create a new repository, copy and clone the application which you have provided.
Your Repository:
And change the values in app_config.py accordingly (from your local VSCode).
In Azure Portal => Create a new App Service with Run time Stack Python.
From Deployment center => Deploy the code using GitHub Actions.
Add the Redirect URI of the deployed Application in App registration.
https://YourDeployedAppName.azurewebsites.net/getAToken
Here my deployed app name is myadb2c.So, update the Redirect URI as below.
https://myadb2c.azurewebsites.net/getAToken
***Workflow in GitHub Repository: ***
Deployed Application Output:
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.
This is a follow-up question to this question. The answer in the original question helped me, but I am stuck somewhere else. As a reminder, I want to deploy my application using a publish profile. My web app in Azure has two subfolders inside wwwroot and one of them is called backend. I want to deploy my application to that folder. I am not sure why msdeploy wants to create anything, since the web app is already there - I just need to get the artifacts inside the backend folder.
Here is the relevant part of the log (with some names changed to xyz):
2018-06-14T09:19:25.0295238Z Start executing msdeploy.exe
2018-06-14T09:19:25.0323018Z "C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -source:package='D:\a\r1\a\artifacts\drop\xyz.zip' -dest:auto,computerName="https://xyz.scm.azurewebsites.net:443/msdeploy.axd?site=xyz/backend",userName="$xyz",password="***",authtype="basic",includeAcls="False" -verb:sync -disableLink:AppPoolExtension -disableLink:ContentExtension -disableLink:CertificateExtension -setParamFile:"D:\a\r1\a\artifacts\drop\xyz.SetParameters.xml"
-enableRule:DoNotDeleteRule -retryAttempts:6 -retryInterval:10000
2018-06-14T09:19:25.6154385Z Info: Using ID '89f1210b-39ba-4758-b7ee-76a06407a503' for connections to the remote server.
2018-06-14T09:19:28.0800802Z Info: Creating application (Default Web Site)
2018-06-14T09:19:28.2012951Z ##[debug]rc:1
2018-06-14T09:19:28.2013216Z ##[debug]rc:1
2018-06-14T09:19:28.2013360Z ##[debug]success:false
2018-06-14T09:19:28.2013523Z ##[debug]success:false
2018-06-14T09:19:28.2073234Z ##[error]Failed to deploy web package to App Service.
2018-06-14T09:19:28.2081930Z ##[debug]Processed: ##vso[task.issue type=error;]Failed to deploy web package to App Service.
2018-06-14T09:19:28.2082198Z ##[debug]{}
2018-06-14T09:19:28.2082470Z ##[debug]System.DefaultWorkingDirectory=D:\a\r1\a
2018-06-14T09:19:28.2083178Z ##[error]Error Code: ERROR_USER_NOT_AUTHORIZED_FOR_CREATEAPP More Information: Could not
complete an operation with the specified provider ("createApp") when
connecting using the Web Management Service. This can occur if the
server administrator has not authorized the user for this operation.
createApp http://go.microsoft.com/fwlink/?LinkId=178034 Learn more
at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_USER_NOT_AUTHORIZED_FOR_CREATEAPP.
Error count: 1.
I managed to resolve the issue. According to this answer by #starian chen-MSFT, I needed to set the correct parameter in SetParameters.xml. I did this by adding the following to my Visual Studio Build task:
/p:DeployIisAppPath="xyz"
where xyz is the value of DeployIisAppPath element in the publish profile.
The reason is that Azure expecting that site name will be presented twice in scm.azurewebsites.net:443/msdeploy.axd?site=%SiteNameHere%" and the same value as a parameter, by default value from file SetParameters.xml is used for second.
So, you need to modify the value of IIS Web Application Name parameter in xxx.SetParameters.xml programming (e.g. PowerShell or other tasks), after that it should works fine.
Azure staging web deploy fails with ERROR_USER_NOT_AUTHORIZED_FOR_CREATEAPP but not for production
I am using this piece of code to call the service bus queue from my node.js file running in Azure Worker Role .
var azure = require('azure'),
config = require('./config');
var serviceBusClient = azure.createServiceBusService(config.sbConnection);
console.log("Start");
serviceBusClient.getQueue("myqueue", function (error, queue) {
if(error){
console.log(error);
}
console.log(queue);
});
console.log("End");
In this code worker role only log "start" and "end" but getQueue API is not working and not throwing any error and it is working fine on my local machine and logging the response.
I tested in a new Cloud Service with your node.js script code, and deploy to Azure. And I configed the .csdef file to pipe the output into a log file, like: <ProgramEntryPoint commandLine="node.cmd .\worker.js > sblog.txt" setReadyOnProcessStart="true" /> to check the output of the node.js script.
Everything worked fine on my side. Could you please confirm whether you have messages in your queue, and whether you have any specific configurations in your .csdef file.
update
According the description at https://azure.microsoft.com/en-us/documentation/articles/nodejs-specify-node-version-azure-apps/:
If you are hosting your application in an Azure Cloud Service (web or worker role,) and it is the first time you have deployed the application, Azure will attempt to use the same version of Node.js as you have installed on your development environment if it matches one of the default versions available on Azure.
And we can check the available nodejs version in cloud service via the powershell command: Get-AzureServiceProjectRoleRuntime. The available version list is :0.6.17,0.6.20,0.8.4,0.8.22,0.8.26 and 0.10.21.
If you want to use your custom nodejs version, you can package the entire node.js execute application folder into your cloud service application. And modify the node.cmd file in your cloud service application to direct the node.js execute application's path in your cloud service package.