I'm trying to run some pre deployment tasks (unit tests etc) with NPM on an Azure website, however the version of node on the VM is v0.10.32, the current version of node is v4.2.4.
I have non administrative access to the command line via the SCM website, no RDP etc.
Is there any way to upgrade?
Ensure the Azure Web App has the node version you want.
Go to yoursite.scm.azurewebsites.net
Choose Debug Console (PowerShell or CMD)
Navigate to D:\Program Files (x86)\nodejs
Run dir to see the available nodejs versions.
For instance, if there is a directory named 6.3.0, then you can use it.
// App Setting
WEBSITE_NODE_DEFAULT_VERSION 6.3.0
// package.json
engines":{"node": "6.3.0"}
You can specify the version of node that the app is running on using the package.json file. Add:
"engines":{"node":version}
e.g.:
"engines":{"node": "0.12.x"},
More info: https://azure.microsoft.com/en-us/documentation/articles/nodejs-specify-node-version-azure-apps/
2017 update. All above didn't work for me in.
I changed:
// package.json
engines":{"node": "8.0.0"}
and then I added app settings value
<appSettings>
<add key="WEBSITE_NODE_DEFAULT_VERSION" value="8.0.0" />
</appSettings>
I restarted an app million times, and the solution was to change iisnode.yml
nodeProcessCommandLine: "D:\Program Files (x86)\nodejs\8.0.0\node.exe"
That's it. I hope it will help someone.
Update
Just to clarify things: I'm talking about App Service
And if you ftp to your App you will see iisnode.yml here:
Changing NodeJs Version in Azure Portal
Navigate to your web app in azure portal
Click on Application settings in Settings blade.
You can include WEBSITE_NODE_DEFAULT_VERSION as key and version of nodejs you want as value in app settings.
Example: WEBSITE_NODE_DEFAULT_VERSION 8.0.0
For me, the solution was neither to set the engine version in package.json, nor to set WEBSITE_NODE_DEFAULT_VERSION, but to use the az command line as described here:
az webapp config set \
--resource-group <resource-group-name> \
--name <app-name> \
--linux-fx-version "NODE|14-lts"
Related
I have a webapp which is running in Node 16, I am updating to node 18. I have used below command to update.
az webapp config set -g RG_NAME -n APP_NAME --linux-fx-version "NODE|18LTS
once done, when I run az webapp config show, I can see its in Node 18, but the UI (Azure portal) doesnt show the latest changes, because the stack is choosen Empty. when I manually set the stack to Node, its showing properly. Is it just UI issue or I have to set any parameters to actually update the stack ?
I have created NodeJS App and deployed to Azure Linux App Service with NODE 16LTS.
Immediately after deploying the app, in Azure Portal I can see the stack as NODE 16.
As you have mentioned, updated the runtime stack with NODE 18 LTS with the given command.
az webapp config set -g YourRGName -n YourAppName --linux-fx-version "NODE|18LTS"
Even I can see the runtime stack setting becoming empty.
Is it just UI issue or I have to set any parameters to actually update the stack ?
AFAIK, we don't have any option to set the parameters while updating the stack.
Manually I have updated the runtime stack and again tried to update the version for the second time with CLI Command.
Again, I see the runtime stack option Empty. This is the default behavior of Azure App Service UI in Portal.
I've learned how to deploy .sh scripts to Azure with Azure CLI. But it seems like I have no clear understanding of how they work.
I'm creating the script that simply unarchives a .tgz archive in a current directory of Azure Web App, and then just deletes it. Quite simple:
New-Item ./startup.sh
Set-Content ./startup.sh '#!/bin/sh'
Add-Content ./startup.sh 'tar zxvf archive.tgz; rm-rf ./archive.tgz'
And then I deploy the script like this:
az webapp deploy --resource-group Group
--name Name
--src-path ./startup.sh
--target-path /home/site/wwwroot/startup.sh
--type=startup
Supposedly, it should appear in /home/site/wwwroot/, but for some reason it never does. No matter how I try. I thought it just gets executed and then deleted automatically (since I specified it as a startup script), but the archive is there, not unarchived at all.
My stack is .NET Core.
What am I doing wrong, and what's the right way to do what I need to do? Thank you.
I don't know if it makes sense, but I think the problem might be that you're using the target-path parameter while you should be using path instead.
From the documentation you cited, when describing the Azure CLI functionality, they state:
The CLI command uses the Kudu publish API to deploy the package and can be
fully customized.
The Kudu publish API reference indicates, when describing the different values for type and especially startup:
type=startup: Deploy a script that App Service automatically uses as the
startup script for your app. By default, the script is deployed to
D:\home\site\scripts\<name-of-source> for Windows and
home/site/wwwroot/startup.sh for Linux. The target path can be specified
with path.
Note the use of path:
The absolute path to deploy the artifact to. For example,
"/home/site/deployments/tools/driver.jar", "/home/site/scripts/helper.sh".
I never tested it, I am aware that the option is not described when taking about the az webapp deploy command itself, and it may be just an error in the documentation, but it may work:
az webapp deploy --resource-group Group
--name Name
--src-path ./startup.sh
--path /home/site/wwwroot/startup.sh
--type=startup
Note that the path you are providing is the default one; as a consequence, you could safely delete it if required:
az webapp deploy --resource-group Group
--name Name
--src-path ./startup.sh
--type=startup
Finally, try including some debug or echo commands in your script: perhaps the problem can be motivated for any permissions issue and having some traces in the logs could be helpful as well.
I get the following warning while deploying my application to AZURE.
(node:6568) [DEP0064] DeprecationWarning: tls.createSecurePair() is
deprecated. Please use tls.Socket instead.
But this does not allow my application to start. Azure logs show the following thing:
PATH OF LOGS: D:\home\LogFiles\Application>
I know this question is already 8 month old, but just for completeness I am going to provide the answer on how to suppress warnings for Node in Azure. There is actually multiple ways:
Using iisnode.yml
Just put the following line in the iisnode.yml:
nodeProcessCommandLine: node.exe --no-deprecation --no-warnings
Or if you use a full path to a version of Node, you'll need to quote it, e.g.
nodeProcessCommandLine: "D:\Program Files (x86)\nodejs\10.6.0\node.exe" --no-deprecation --no-warnings
Using web.config
Toward the end of the file, you'll see a commented out tag. Replace it by something like this:
<iisnode nodeProcessCommandLine="node.exe --no-deprecation --no-warnings"/>
Notes
iisnode.yml takes precedence over web.config
See the original post on how to add runtime flags in Azure here: Pass flags to NodeJS's Chrome V8 engine in Azure Web Apps
in my node js web app, i use node version = 6.9.1:
"engines": {
"node": "6.9.1"
}
and when i do deployment with
git push azure master
it shows correct node is used.
...
remote: Selected node.js version 6.9.1. Use package.json file to choose a different version.
remote: Selected npm version 3.10.8
...
but my app service is not started correctly because of node.exe crashed.
later i output the used node version number in my entry point script, i get
Node version:v0.6.20
from file D:\home\LogFiles\Application\xxxx-stdout-xxxx.txt
so obviously Azure App service is not using my defined version of node.exe.
later i follow https://learn.microsoft.com/en-us/azure/nodejs-specify-node-version-azure-apps
add below text in file D:\home\site\wwwroot\iisnode.yml to fix this issue.
nodeProcessCommandLine: "D:\Program Files (x86)\nodejs\6.9.1\node.exe"
so my question is why Azure App Service (iisnode) is not using my defined node version in package.json ?
To change the NodeJs version of Azure App Service by using iisnode.yml(which won’t change node version on kudu cli or during deployment), you need to set iisnode.yml file manually in your app root folder with including below line as you have mentioned:
nodeProcessCommandLine: "D:\Program Files (x86)\nodejs\5.9.1\node.exe"
Then you need to set iisnode.yml file using package.json during source control deployment.
Azure Source Control deployment process would involve below steps
1. Moves content to azure web app
2. Creates default deployment script, if there isn’t one(deploy.cmd, .deployment files) in web app root folder
3. Run’s deployment script where it creates iisnode.yml file if you mention nodejs version in package.json file > engine
Reference: https://blogs.msdn.microsoft.com/azureossds/2016/04/20/nodejs-and-npm-versions-on-azure-app-services/.
Or else you can use App Settings in Azure portal to change the version of NodeJs.
I had Composer Site extension installed till now on azure php webapp.
I need custom deployment that can run grunt tasks also. So I created the .deployment and deploy.sh files in project root. But that deploy.sh is not being picked up.
.deployment file contents:
[config]
command = bash deploy.sh
Looking at the deployment logs, I find this
2017-05-04T06:21:03.9301086Z,Updating submodules.,8bc3029f-d77b-4c1e-860f-a3d439d7a354,0
2017-05-04T06:21:03.9926050Z,Preparing deployment for commit id 'e2b45fb52b'.,61c286b1-5c00-4c11-ae14-54e0711d6857,0
2017-05-04T06:21:04.2632947Z,Running custom deployment command...,e71c397e-bc63-4357-abc4-acd49bc2041d,0
2017-05-04T06:21:04.3101663Z,Running deployment command...,24db1c4f-8a51-463b-8c4a-ee040bc5dfd8,0
2017-05-04T06:21:04.3101663Z,Command: D:\home\SiteExtensions\ComposerExtension\Hooks\deploy.cmd,,0
2017-05-04T06:21:04.4039215Z,The system cannot find the path specified.,,1
2017-05-04T06:21:04.4195462Z,The system cannot find the path specified.\r\nD:\Program Files (x86)\SiteExtensions\Kudu\62.60430.2807\bin\Scripts\starter.cmd D:\home\SiteExtensions\ComposerExtension\Hooks\deploy.cmd,,2
Seems like somewhere the trigger for Composer site extension still remains which is being invoked during deployment.
How can I completely remove Composer site extension and use my custom deployment script deploy.sh? Thanks in advance.
Found the problem. After uninstalling Composer SiteExtension, this environment variable is still present APPSETTING_COMMAND = D:\home\SiteExtensions\ComposerExtension\Hooks\deploy.cmd. Deleted the environment variable using kudu console and then deployment succeeded.
After removing the Composer Extension the APPSETTING_COMMAND remains as an environment variable.
Use the Kudu PowerShell command Remove-Item Env:\APPSETTING_COMMAND to remove the variable online.
Alternatively, restarting the App Service via the overview tab will refresh the environment variables, though this could be a little invasive.