I'm using Azure Web Apps and every time I try to make it use node 14.x it resets back to 10.x after every deployment.
When I go to Configuration > General the Stack is blank, I have to select Node and then 14.x to make it work.
Edit: Linux is used not Windows
I managed to solve the problem by adding
runtimeStack: "NODE|14-lts"
in the yaml file, 16.x is not yet supported so it defaults back to 10.x
Add WEBSITE_NODE_DEFAULT_VERSION app setting for the Node version, but make sure the exact version you fill in is installed on the workers (assuming Windows workers here, since you don't specify) -
https://{yourWebAppName}.scm.azurewebsites.net/api/diagnostics/runtime
That's the Kudu API route returning runtime versions. Pick the latest installed Node version from there.
Your app setting becomes
WEBSITE_NODE_DEFAULT_VERSION = 14.16.0
As long as you don't remove or overwrite this app setting, your Node version will stay consistent across code deployments.
Tracking a GitHub issue here since the documentation page is confusing about the version values -
https://github.com/MicrosoftDocs/azure-docs/issues/79475
Related
I have a Node 12 app and am trying to assess when i should migrate up to a newer version of Node. Even though it is no longer officialy suppported the app builds today on v12. I read in heroku's documentation (https://devcenter.heroku.com/articles/nodejs-support) that I can install "most node versions". That seems to explain why the app is still building, but then I also read that official buildpack support is given to active or LTS node versions.
Given the above, what is the implication for older apps? That it will build until a breaking change in the buildpack stops it from building? Is there a buildpack per node version which, if true, would mean that the build will work but without benefit of updates or bugfixes?
So, I've inherited an Azure Function App written in Node.js from a contractor who did a little work for us. This piece of code was developed outside our C# stack, so I'm having to go back and maintain it.
I'm trying to update the Azure Function Extensions runtime for the project in Visual Studio Code, however it seems to be ignoring the local.settings.json for my development environment, and no matter which flags I set, it continues to run the 2.x runtime.
And when it runs, I'm seeing the following errors:
However the documentation they're referencing has zero information about migrating from 2.x to 3.x other than that it 'will be seemless in most cases'.
And of course, the function app won't run:
The problem ended up being the version of the core tools running on my development VM.
As per the documentation here, the core tools version needs to be installed (x64 version for VS Code).
In spite of the fact that I setup this Dev VM yesterday, it still needed to have the core tools version updated to the latest. Once I updated it, it was able to spin up the function locally as expected.
I'm working with React + Firebase.
And the only Node environment I'm currently deploying to is Firebase's Cloud Function environment. I'm using their Node 8 environment. Their Node 10 is still in Beta.
Should my local machine Node version match their environment? I.e: should I have Node 8 installed just because I'm deploying to a Node 8 environment?
Will it hurt anything if I have Node 12 on my PC? What are the downsides of that? What is the recommendation for this?
Yes, you should use the same version so you can avoid having different issues on on your development environment and you production environment because of the different features available in different versions.
Easy way of having multiple versions of node installed on your local environment (plus you can change the default one at any time) is NVM
When I try to set Azure Functions to stable versions 1.0.14 or 1.0.13 locally & in the Portal - I tend to receive a 500 error when trying to GET an endpoint. Through some debugging, I managed to correct this by changing the version to beta. No errors.
Has anyone else seen this issue? Is there any way around this without actually having to recreate the function using the desired version?
Thank you!
You probably mistake Azuer Function SDK version for Azure Function Runtime version.
try to set Azure Functions to stable versions 1.0.14 or 1.0.13 locally & in the Portal
1.0.14 or 1.0.13 you mentioned is SDK version(latest is 1.0.19 right now), which is used to build our function project. Of course we can't set SDK version on portal as build is done before we publish pre-compiled code to Azure. If we develop in browser, the build process and SDK version(the latest) is under the control of Azure.
I managed to correct this by changing the version to beta. No errors.
You may have created a v2 function locally, hence function depends on beta runtime. And you specify a wrong version of 1.x like 1.0.14, so 1.0.11959 is used. We can see 500 error is caused by mismatched runtime and you have corrected it. If you have planned to work with v2 function(.net standard), nothing malfunctions so far.
And some more info about function runtime version.
Function Runtime version
There are two major versions: 1.x for .Net Framework and 2.x for .Net Standard.
Syntax
Major version :~1 for 1.x , ~2 for 2.x. With this format, function app on Azure is automatically updated to new minor versions of the runtime when they become available.
Minor version 1.x:1.0.11959; 2.x: 2.0.11961-alpha, 2.0.12050-alpha. (All versions available right now). Function app on Azure is kept on that version until we explicitly change it.
Where to find
Runtime version in Function app settings.
FUNCTIONS_EXTENSION_VERSION in Application settings.
Configuration
Two scenarios we need to change runtime.
Major version change. ~1 to ~2 or reverse.
We may see prompt below if there are functions in the app.
Major version upgrades can introduce breaking changes to languages and bindings. When upgrading major versions of the runtime, consider creating a new function app and migrate your functions to this new app.
In an empty function app(delete existing functions or create new app), change runtime in Function app settings.
We can directly set FUNCTIONS_EXTENSION_VERSION in Application settings if published project depends on another runtime.
Minor version pinned to avoid breaking changes(probably the last time to use as 2.x is planned to be GA by this fall).
See breaking changes in 2.0.12050-alpha(beta), we can pin FUNCTIONS_EXTENSION_VERSION to 2.0.11961-alpha and follow steps to work with changes and move to beta.
Find more breaking changes to fix if our 2.x function runtime is pinned to some older version, which have all been removed on Azure.
Wrong version handler
If we specify a wrong version of 1.x like 1.0.14, Azure will leverage latest minor version instead. It is same with 2.x.
For local dev
Commonly speaking, local dev doesn't need runtime configuration because we choose Cli first(using tools like npm or VS does in background), we are clear about the major version at least.
Some local places to find function runtime version.
VS, New Function project v1 or v2.
VS/VSCode c# function, in functionappname.csproj, see <AzureFunctionsVersion>v2</AzureFunctionsVersion>.
VSCode, functionapp/.vscode/setting.json, see "azureFunctions.projectRuntime": "~2"
Function core tools(Cli), run func, we may see Function Runtime Version:2.0.12050.0
Start a function app in VS/VSCode/Cli, besides 4, we can also see Cli output Starting Host (HostId=xx, InstanceId=xx, Version=2.0.12050.0, ..)
Very useful information, thank you Jerry! I managed to solve my issue by recreating the Azure function without using .NET Standard. Azure lets you know that changing certain settings may lead to the function not working properly. After recreating with the proper runtime set in both portal and project, it worked.
When I'm deploying the Service Fabric Application with new version, the complete application is getting replaced with new version in service fabric cluster. And it is working fine as expected in upgrade scenario. But, When I deploy the application with downgraded version, application is not getting replaced rather it is again creating an application with older version.
After the application deployment, I have two different versions of same application in service fabric cluster.
How we can downgrade the application to older version with application deployment. Does we need to change settings/parameters for cluster or in power shell command.
Service Fabric cluster with two versions after deployment of older version image
Thanks.
This is a view of the Service Fabric Image store, which shows the current versions available, below this you should be able to see the actual version that is being used within the cluster, see below, versions 1.0.0 and 1.0.1 are currently in the image store but version 1.0.0 is the version being used.
You can confirm this by looking at your nodes as well.
EDIT:
To remove the unwanted versions from the cluster run the following in PowerShell, obvious replace with your application name and version.
> Unregister-ServiceFabricApplicationType -ApplicationTypeName DowngradeDemoType -ApplicationTypeVersion 1.0.1