Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Azure deployment nodejs x64 #1914

Open
francesconero opened this issue Feb 29, 2016 · 19 comments

Comments

Projects
None yet
10 participants
@francesconero
Copy link

commented Feb 29, 2016

Is there a way to use a 64 bit nodejs binary when building node modules during deployment?

It seems that trying to use a downloaded x64 nodejs binary to issue the npm install still fails on subequents node-gyp calls, which resort back to using the global command node (which points to D:\Program Files (x86)\...).

I ask this beause some native modules need the 64bit binary to correctly be built. (for example lovell/sharp)

@snobu

This comment has been minimized.

Copy link
Contributor

commented May 18, 2016

We run node through iisnode. This should do it:

https://azure.microsoft.com/en-us/documentation/articles/nodejs-specify-node-version-azure-apps/

Create an iisnode.yml file in the same directory as the server.js file, and then add the following content to the iisnode.yml file:
nodeProcessCommandLine: "D:\home\site\wwwroot\bin\node.exe"
This path is where the node.exe file within your project will be located once you have published your application to the Azure Website.

The iisnode.yml configuration file is not a replacement of web.config: both can exist at the same time. However, if iisnode.yml is present, its settings override the values specified in the system.webServer\iisnode section of web.config.

However since you seem to hit that problem at deployment time you need to alter the PATH env var and add the path to your x64 binary before the x86 node stuff.
https://github.com/projectkudu/kudu/wiki/Xdt-transform-samples

  <add name="PATH" value="d:\home\site\node64;%PATH%" xdt:Locator="Match(name)" xdt:Transform="InsertIfMissing" />

Feels a bit hacky and now i wonder if there's a cleaner way..
Maybe generating a custom deployment script instead of altering PATH?
https://github.com/projectkudu/kudu/wiki/Custom-Deployment-Script#a-first-lets-generate-a-deployment-script-for-the-nodejs-website

@ahmelsayed

This comment has been minimized.

Copy link
Member

commented May 18, 2016

I think @francesconero is referring to npm building native modules. I made a fix which puts the VC++ compiler and a bunch of other lib and h files on azure VMs to support building native npm modules but I only included the files needed for building x86 modules because I figured we don't even have x64 bit node on the server. @francesconero are you bringing your own node runtime?

@snobu

This comment has been minimized.

Copy link
Contributor

commented May 19, 2016

Right. I remember that. Referencing the issue for context: #1076

@francesconero

This comment has been minimized.

Copy link
Author

commented May 19, 2016

@ahmelsayed yes, exactly, @snobu sorry if I wasn't clear. If I remember correctly, I tried to issue a npm install through a downloaded x64 node executable. I gave up pretty quickly though, since it's easier right now to build on an external windows machine and just copy the node modules over.

Edit: it seems that @snobu's first answer might actually be a possible solution, no?

@Freundschaft

This comment has been minimized.

Copy link

commented Mar 30, 2017

its still a pain, I'm trying to deploy https://github.com/lovell/sharp to my azure app, which is only readily available for x64 windows.
I can replace node with the 64 bit version, but npm will still be stuck with 32 bit :(

@yaoyel

This comment has been minimized.

Copy link

commented Sep 29, 2017

@Freundschaft same problem with me ,did you solved it?

@Freundschaft

This comment has been minimized.

Copy link

commented Sep 29, 2017

@yaoyel in the end the only soltuion that worked for me was to upload the compiled binaries directly instead going through NPM, back then I wasnt able to find a more elegant workaround, not sure if something changed now.

@snobu

This comment has been minimized.

Copy link
Contributor

commented Sep 29, 2017

Now there's App Service on Linux workers and you can bring your own Docker container or use the_blessed_ ones that come with the service. The service is generally available and offers SLA.

@Freundschaft

This comment has been minimized.

Copy link

commented Sep 29, 2017

ah nice, that makes totally sense, docker solves a lot of problem for you in that case

@eatfrog

This comment has been minimized.

Copy link

commented Oct 23, 2017

bumping this since ive struggled with the same problem all day. eventually i tried the app service on linux with docker, but the node image seems to lack python so i still cant build sharp. what a total nightmare this seemingly easy thing has turned out to be.

has anybody found a solution that doesnt involve uploading compiled binaries?

@snobu

This comment has been minimized.

Copy link
Contributor

commented Oct 23, 2017

Build your own container, import from a Node one, add in the Python deps and publish to either Docker Hub or Azure Container Registry, then tell your Web App to pull from that location.

You can still keep code in source control and use Kudu to deploy, there's no need to ship your code with the container. Make sure your container expects the app at /home/site/wwwroot since that's where things gets mounted from storage (also the path where Kudu deploys to).

You can fork and customize one of the official (blessed) images if you like the Node one:
https://hub.docker.com/r/appsvc/node/~/dockerfile/

@rand0me

This comment has been minimized.

Copy link

commented Sep 24, 2018

Thanks for working suggestion, but does someone cares about fixing this bug?

For me, using Linux App Service is not an option, because it lacks of Consumption Plan (which is required in my project). Neither I want to upload a compiled binaries and create child process and other shims and hacks.

☺️

@thomas-mindruptive

This comment has been minimized.

Copy link

commented Apr 18, 2019

Hi,
is there already a solution apart from uploading my "own" nodejs.
Thanks

@suwatch

This comment has been minimized.

Copy link
Member

commented Apr 18, 2019

We are currently making certain 64 bits nodes available on Azure App Service VM. Anyone would be able to use it. @mhoeger can provide more details (ETA, what versions etc).

@thomas-mindruptive

This comment has been minimized.

Copy link

commented Apr 18, 2019

Thanks a lot, in the meantime It tried:
@mhoeger

  • Upload node 10.15.3 64 bit via kudu to d:\home\node-10.15.3
  • Set languageWorkers:node:defaultExecutablePath containing that path in azure portal, section "configuration"
  • added iisnode.yml pointing to new node-10.15.3. to my deployment
  • restarted app
  • redeployed via git (local rep): during the process, kudu correctly recognizes the node version in iisnode.yml (output says: "the iisnode.yml file explicitly...") but the node install process still uses "...\program files(x86)..."

thanks

@mhoeger

This comment has been minimized.

Copy link

commented Apr 18, 2019

@thomas-mindruptive - Ashley Grant's recommendation here should be helpful! Azure/azure-functions-nodejs-worker#158 (comment)

As a note, we do currently have one 64-bit node version deployed (mainly for testing before we switch logic). Try changing languageWorkers:node:defaultExecutablePath to D:\Program Files\nodejs\10.15.2 and it should work.

I'll update this thread later with details on how the official support works when it is ready!

@thomas-mindruptive

This comment has been minimized.

Copy link

commented Apr 18, 2019

@mhoeger
Thanks, I changed the languageWorkers:node:defaultExecutablePath as mentioned but get the same errors

ERR! sharp Windows x86 (32-bit) node.exe ...
...
remote: gyp ERR! command "D:\\Program Files (x86)\\nodejs\\10.14.1\\node.exe"

Should I change the path env-variable or create a ".deployment" file maybe?

Thanks and best

@thomas-mindruptive

This comment has been minimized.

Copy link

commented Apr 18, 2019

PS: If I remove WEBSITE_NODE_DEFAULT_VERSION from the app configuration (so languageWorkers:node:defaultExecutablePath) is the only setting pointing to a node version/path, I get errors containing the path D:\Program Files (x86)\npm\1.4.28\node_modules.... So it falls back to an old npm/node version.
Best

@thomas-mindruptive

This comment has been minimized.

Copy link

commented Apr 18, 2019

Sorry to bother you again. Found a way it works:
Set WEBSITE_NODE_DEFAULT_VERSION to D:\Program Files\nodejs\10.15.2, too.
Thanks and best
Thomas

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.