App Dev Manager Chris Tjoumas explains how to configure Azure Web App to run 64-bit Node.js. This is a follow-up to his previous post on deploying Ghost on Azure Web App.
*There is an update to this post as of 4/18/20 with additional details for 64 bit support.Â
In my previous post, I explained how to deploy Ghost on Azure Web App; however, Ghost v2.25.5 now requires Node.JS 64-bit to support the sharp package v0.22.1. If you followed my initial instructions to create the free App Service, you will notice that this build will break your post images. The sharp package is used to convert those posted images into optimized formats for performance. Without a functional sharp package, the Web App performance will be noticeably slower.
To fix this issue, you need to configure Azure Web App and Node.js to use 64-bit, which is only available in the App Service Basic Tier and above.
Configure Azure Web App to 64-bit Platform and Node.js:
- Navigate to your Web App in the Azure Portal
- Click on Configuration
- Under Application settings, edit the WEBSITE_NODE_DEFAULT_VERSION and enter 10.15.2 and click Save
-
- You can identify the installed version by going to Kudu for your app (https://<your hostname>.scm.azurewebsite.net) and browsing to D:\Program Files\nodejs. You’ll see the version (64-bit since we are under “Program Files”) listed here. You can also go to https://<your hostname>.scm.azurewebsite.net/api/diagnostics/runtime to see the list of NodeJS versions that Azure Web App supports. For example, one of the versions listed for NodeJS is {“version”:”10.15.2″,”npm”:”6.4.1″}, which I’ll use here.
- Verify the node version by running the Kudu console and typing “node -v” (you should see 10.15.2, in this case)
- Add WEBSITE_NPM_DEFAULT_VERSION and set the value to 6.4.1
- Click Save.
- Click General settings and change Platform to 64 Bit
- Click Save.
- Jump over to your source code and edit iisnode.yml in the root by adding the following:
nodeProcessCommandLine: "D:\Program Files\nodejs\10.15.2\node.exe"
- Â Finally, check in your change to kick-off a new build
Changing the Node.js version in this file will set the run-time environment which iisnode uses. The kudu command would use the Node.js version set in Application Settings, so it’s important to set both.
Navigate to your site and verify everything works! Now back to blogging (or fixing any apps which need 64-bit Node.js)!
Thank you. I followed your instruction.
Is it safe to assume that the nodejs runs 64bit by checking the node.exe in the Kudu Process Explorer?
General Tab:
file name D:\Program Files\nodejs\12.13.0\node.exe
command line “D:\Program Files\nodejs\12.13.0\node.exe” “D:\Program Files\iisnode\interceptor.js” “D:\home\site\wwwroot\server\iis.js”
The Environmental Variables tab of the node.exe process reads:
PROCESSOR_ARCHITECTURE AMD64
SITE_BITNESS AMD64
Thank you.
Hi M H,
It seems like that should do the trick, however there may be a Kudu limitation (I would need to do a bit more research into that), if you look at what Eric Cote responded to above. There is a workaround which I haven't tested but is listed in the GitHub issue I linked - however in this case, it doesn't appear that you really need 64-bit to run this sharp package; you can...
This is not working for me.
I modified the deploy.cmd to add a line in the deployment section:
node -p “process.arch”
This commande simply returns the architecture (“ia32” or “x64”). When I run this in the Windows Azure Kudu deployment, then take a look at the logs, it confirms to me that the node running in deployment still runs in 32 bits. Even though the iisservice runs in 64 bits. Grrrr!
The following article seems to confirm that kudu runs the installation services in 32 bits, even when IIS and other services are set to run in 64 bits:
https://github.com/aspnet/AspNetCore.Docs/issues/13013
In fact, when I go to the above step ii, where you test the version of node using node -v, if at that precise step I use node -p "process.arch", I still get 32 bits, not 64.
Can anyone else confirm?
Hi Eric,
My apologies for missing this! For some reason I didn't see the notification. Yes, I'm also seeing ia32 when I run node - p "process.arch". There is a bit of info out there which you may have seen: https://github.com/Azure/azure-functions-nodejs-worker/issues/158. It's possible that there is a better solution at this point, but there are workarounds at least.
However, one thing I did notice was that you can actually run Ghost with a 32-bit architecture; if you...
Hey Eric,
I've been working with Jessica Deen (https://jessicadeen.com) who has been working a lot with a similar Ghost on Azure project and was looking at this same issue. She spoke with our product team and while it's not yet documented, here's what you need to do:
1. Set WEBSITE_NODE_DEFAULT_VERSION to ~10 (the ~ is needed and not a typo)
2. Keep your platform setting as is stated in this post (64 Bit)
3. Remove any other...
Thank you! One thing to note is that if you have a web.config with an <iisnode> tag then you need to define it like below. App Services seems to ignore the iisnode.yml when you have the <issnode> tag on your web.config
<iisnode watchedFiles=”web.config;*.js” debuggingEnabled=”false” nodeProcessCommandLine=”\Program Files\nodejs\10.15.2\node.exe” />
Hi Jason –
Thanks for pointing this out! Great addition to note.
Chris