Configure Azure App Service for 64-bit platform and Node.js

Developer Support

August 8th, 20198 0

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

Machine generated alternative text: WEBSITE NODE DEFAULT VERSION 10.152

    1. 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.
    2. 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

Machine generated alternative text: WEBSITE NPM DEFAULT VERSION q 64.1

  • Click Save.
  • Click General settings and change Platform to 64 Bit

Platform settings Platform 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)!

Developer Support App Dev Customer Success Account Manager, Microsoft Developer Support

Read next

DevOps and Beyond Outcomes
Not only do high-velocity organizations get better at what they do, they get better at getting better at what they do. This scales so that no one can keep up with them. After all, most companies hire from the same pool of talent, they use the same software practices such as Agile/Scrum, they use the same tools, and so on.
Developer Support
August 8, 2019
0 comment

8 comments

Discussion is closed. Login to edit/delete existing comments.

  • JasonDevComp 0

    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” />

    • Chris TjoumasMicrosoft employee 0

      Hi Jason –

      Thanks for pointing this out! Great addition to note.

      Chris

  • Eric Cote 0

    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!

    • Eric Cote 0

      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?

      • Chris TjoumasMicrosoft employee 0

        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 delete the web app setting “npm_config_arch = x64” and trigger a re-deploy, it should work and you can run it entirely on x32. I believe the only drawback is you won’t use the latest sharp package Ghost is using, which will result in additional redirects.

        Thanks,
        Chris

        • Chris TjoumasMicrosoft employee 0

          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 settings you have – delete the nodeProcessCommandLine entry noted above in iisnode.yml, delete any other environment variables, and delete any customizations you may have added to your deploy.cmd.

          Once you have finished this, deploy this to your app. If you get any error restart your app and redeploy, if necessary. After I ran this, I was able to run node -p “process.arch” and did receive x64.

          Jessica will have a blog post to specify this so I will look at the best way to get this updated (possibly updating this one and linking to hers).

          Thanks!

          Chris

  • M H 0

    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.

    • Chris TjoumasMicrosoft employee 0

      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 simply delete the npm_config_arch = x64 web app setting and run it using a x32 architecture.

      One thing I have on my TODO list is to switch my deployment over using Azure DevOps instead of Kudu, which may remove this issue in using node 64-bit.

      Thanks,
      Chris

Feedback usabilla icon