I want to use Node.js v12.x to build and deploy but it uses 14.15.1:
Using Node version:
v14.15.1
Using Npm version:
6.14.8
If you arrived here wanting to set the Node.js runtime version that is used for your API backend, refer to https://learn.microsoft.com/en-us/azure/static-web-apps/configuration#platform
In summary, you will create a staticwebapp.config.json that sits where your app_location is pointed in your github workflow (typically the root of your project) or any subfolder of app_location
You can then set the runtime like this...
{
"platform": {
"apiRuntime": "node:16"
}
}
At the time of writing, your options are node:12, node:14, node:16. Reference the link above for the most up to date values.\
I'd like to answer the original question as well because I think the accepted answer is wrong. The azure CLI will say that az webapp ... can't find your project because it's a staticwebapp not a webapp.
The solution (and I'm not certain) should be to set the nodeEngines in package.json, like this:
{
"engines": {
"npm": ">=7.0.0",
"node": ">=16.0.0"
},
"dependencies": {
...
}
}
If I'm wrong about this, let me know in the comments and I'll update it.
You can set the desired node.js version via the Azure CLI:
az webapp config set --resource-group <resource-group-name> --name <app-name> --linux-fx-version "NODE|12.X"
For more information, see https://learn.microsoft.com/de-de/azure/app-service/configure-language-nodejs?pivots=platform-linux#set-nodejs-version
Related
As title, when I try to run my nodejs based azure function, I come across the following error:
The following 1 functions are in error: [7/2/19 1:41:17 AM] ***: The binding type(s) 'blobTrigger' are not registered. Please ensure the type is correct and the binding extension is installed.
I tried func extensions install --force with no luck still, any idea? My development environment is macOS and I tried both nodejs based azure-functions-core-tools and brew based install both doesn't work.
The most scary part is this used to work fine on the same machine, all a sudden it just failed to work.
Basically, you can refer to the offical tutorial for Linux Create your first function hosted on Linux using Core Tools and the Azure CLI (preview) to start up your work.
Due to the same shell bash used in MacOS and Linux, I will start up my sample demo for you on Linux and avoid using those incompatible operations. First of all, assumed that there is an usable NodeJS runtime in your environment. The version of node and npm is v10.16.0 and 6.9.0.
To install azure-functions-core-tools via npm and inspect it, as the figure below.
Next to init a project MyFunctionProj via func
Then to new a function with blob trigger
There is an issue about the requirement for .NET Core SDK. So I move to https://www.microsoft.com/net/download to install it, here is incompatible with MacOS, but I think you can easy to fix it by yourself. So I followed the offical installation instruction to install it.
After installed .NET Core SDK, try to func new again.
And completed like this.
To change two configuration files MyFunctionProj/local.settings.json and MyFunctionProj/MyBlobTrigger/function.json, as below.
MyFunctionProj/local.settings.json
{
"IsEncrypted": false,
"Values": {
"FUNCTIONS_WORKER_RUNTIME": "node",
"AzureWebJobsStorage": "<your real storage connection string like `DefaultEndpointsProtocol=https;AccountName=<your account name>;AccountKey=<your account key>;EndpointSuffix=core.windows.net`"
}
}
MyFunctionProj/MyBlobTrigger/function.json
{
"bindings": [
{
"name": "myBlob",
"type": "blobTrigger",
"direction": "in",
"path": "<the container name you want to monitor>/{name}",
"connection": "AzureWebJobsStorage"
}
]
}
Then, command func host start --build to start up it without any error.
Let's upload a test file named test.txt via Azure Storage Explorer to the container <the container name you want to monitor> which be configured in the function.json file. And you will see that MyBlobTrigger has been triggered and work fine.
Hope it helps.
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'm testing an Azure Functions app locally with the Azure Functions CLI tooling. Is there any way I can configure CORS settings for the local host?
You can configure CORS in the local settings file local.settings.json:
{
"Values": {
},
"Host": {
"CORS": "*"
}
}
Settings in the local.settings.json file are used only when you're
running projects locally
You can start the host like this
func host start --cors *
You can also be more specific and provide a comma delimited list of allowed urls
More here: https://github.com/Azure/azure-webjobs-sdk-script/issues/1012
Another easy way to configure CORS on Azure Functions is to use Azure Portal,
1- Go to the Function App Settings in Azure Portal
2 - Click on CORS and add your local host url
And there you have it!!
Hope this helps someone.
If you're having issues passing in the params via Visual Studio's Debug's "Application Arguments". This is how to pass the params from the command line:
1) Open an ordinary command prompt.
2) cd to your solution's compiled dll, i.e. "Your Solution Path"\bin\Debug\netstandard2.0
3) start the Azure function runtime from the command line, i.e.:
dotnet "C:\Users\USER\AppData\Local\Azure.Functions.V2.Cli\func.dll" host start --port 7071 --cors * --pause-on-error
4) To debug in Visual Studio, Debug->Attach to Process.. and attach to the donet.exe that will be running.
Hope that helps prevent someone from banging their head too much...
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"
I added a scripts.config file to .ebextensions at the root of my Node app deployed in beanstalk.I did not see the tags for the EC2 instances in the console. Nor did I see any mention of 1_add_tags in beanstalk logs. What did I do wrong and how do I find out if the commands in the script.config were called at all!
The config file in .ebextensions is as follows ....
01_add_tags:
command: ec2-create-tags $(ec2-metadata -i | cut -d ' ' -f2) --tag Environment=Production --tag Name=Proxy-Server --tag Application=something
env:
EC2_HOME: /opt/aws/apitools/ec2
EC2_URL: https://ec2.ap-southeast-2.ama...
JAVA_HOME: /usr/lib/jvm/jre
PATH: /bin:/usr/bin:/opt/aws/bin/
Cheers,
Prabin
Amazon's answer to the problem. (This worked for me) ...
You can utilise the ebextensions to execute certain commands on instance boot.
Supposing that you want to implement this on Linux based containers. I have formulated a sample config file for you and attached to this case.
Please follow below guidelines :
In the AWS Management console, check the IAM Role/Instance profile used by beanstalk. By default it uses "aws-elasticbeanstalk-ec2-role". Add permissions for this role to create new tags (ec2:CreateTags).
If you do not have ".ebextensions" folder at the root of your application or the "WEB-INF" folder, then create the folder.
Modify the key value pairs in the config file. Multiple pairs are separated by a space.
A sample snippet is as below:
{
"container_commands": {
"01_add_tags": {
"command": "aws ec2 create-tags --resources $(GET http://169.254.169.254/latest/meta-data/instance-id) --tags Key=ClientName,Value=testClient Key=NewTag,Value=new-value --region us-east-1"
}
}
}
Add the modified config file in the ".ebextensions" folder.
Upload this version to beanstalk. It should launch new instances and execute the config file.
Please give it sometime, preferably till the instances pass EC2 instance status checks. Refresh the page for the additional tags to be displayed.
Please note that we are using "Container_commands" instead of "Command" used in the blog.
Container Commands run after the application and web server have been set up and the application version file has been extracted, but before the application version is deployed. This is important as these commands have access to environment variables such as your AWS security credentials set by the instance-profile.
I would recommend you to go through the restrictions for AWS Resources tagging mentioned at http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#tag-restrictions
I would like to highlight that maximum number of tags per resource is 10.
Also check the table for tagging support for certain resource. For example, currently tagging is not supported for ELB.
I had the similar problem where I tried to install libjpeg using the ./ebextensions/foo.config file. I tried everything but was never able to find a good solution.
I was able to solve it though, by setting up a completely new Elastic Beanstalk Application and then deploying my same version on the new instance instead. When I did this everything was installed perfectly and working fine.
Check out my answers here:
https://stackoverflow.com/a/23109410/2335675
https://stackoverflow.com/a/23131959/2335675
Hope this fixes your issues as well.