Kudu: NVM Support

[deevus]

Hi guys

It would be great if kudu supported nvm. I use https://github.com/coreybutler/nvm-windows/ locally and it works a charm.

I think that the same workflow that people use would work now as well, but where you could support more versions of node sooner.

Thoughts?

[ramijarrar]

Is this being considered yet?

The current selection of Node versions is very limited at best and often lags behind the latest releases (which can contain important bug fixes/patches).

[davidebbo]

The current selection of Node versions is very limited at best and often lags behind the latest releases (which can contain important bug fixes/patches).

Can you clarify those comments? We almost always have the latest versions available (currently 6.9.1 & 7.1.0), and the version selection is quite large. Maybe you are looking in the wrong place?

[ramijarrar]

I was referring to latest versions across release cycles: e.g 4.6.2, 5.11.0, 0.10.48, 0.12.17 (none of which are supported at the moment)

And in terms of overall selection, I'd still consider 15% (58/395) to be quite limited - especially in situations when we are constrained by dependencies/frameworks.

[yaserjarrar]

As an example demonstrating the need for more specific releases, the latest version of Meteor is using node v4.6.2 which is currently not available.

[davidebbo]

Is nvm something that can be just copied into an app and run from there, or does it it machine install? Generally, the rule in the Azure Web Apps sandbox is that you can't do anything that is machine impactful. You can only bring files, either under d:\home (persisted) or d:\local (temp). So depending on how it works, using nvm may or may not be feasible.

[ramijarrar]

Nope. It will definitely need machine install (otherwise we could get this done with a custom deploy script)

[davidebbo]

Do you know specifically what it needs that needs to be machine level? e.g. does it need to update the registry or system files? On the surface, that seems unlikely for a tool like this. My guess is that they ship it as an MSI, but that it doesn't actually need anything machine level and would probably run from xcopied files.

The bar to install something on the VM is quite high, so I'd like to exhaust alternatives first.

[deevus]

It doesn't need machine install. It can exist on the filesystem no problem.
It does however require administrator access to "install" a version of
node. I think that's because it needs to change the system path

On Mon, 5 Dec 2016, 09:46 David Ebbo [e-mail] wrote:

Do you know specifically what it needs that needs to be machine level?
e.g. does it need to update the registry or system files? On the surface,
that seems unlikely for a tool like this. My guess is that they ship it as
an MSI, but that it doesn't actually need anything machine level and would
probably run from xcopied files.

The bar to install something on the VM is quite high, so I'd like to
exhaust alternatives first.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/projectkudu/kudu/issues/2130#issuecomment-264737896,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA0QghEpI5LLporzaAfXi5J0MlXgehCBks5rE0LHgaJpZM4J4m5X
.

[davidebbo]

That's definitely problematic, as that means that even if we preinstalled nvm on the VM, it wouldn't be able to run from the sandbox, making it useless.

But I'm surprised that it needs to change the machine level system path. I don't know anything about it, but on the surface I'd think what it really needs to do is:

• Download some files of the cloud
• Set the PATH & environment in the current shell (and not machine level), allowing Node to then be run in that shell.

[deevus]

Perhaps there's a way to run it without privileges.

On Mon, 5 Dec 2016, 09:56 David Ebbo [e-mail] wrote:

That's definitely problematic, as that means that even if we preinstalled
nvm on the VM, it wouldn't be able to run from the sandbox, making it
useless.

But I'm surprised that it needs to change the machine level system path. I
don't know anything about it, but on the surface I'd think what it really
needs to do is:

• Download some files of the cloud
• Set the PATH & environment in the current shell (and not machine
  level), allowing Node to then be run in that shell.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/projectkudu/kudu/issues/2130#issuecomment-264738560,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA0Qgk9LKZ_IZUTymSs-5FvgANaCzCubks5rE0UdgaJpZM4J4m5X
.

[davidebbo]

I'll try playing around with that thing.

[ramijarrar]

From the README:

NVM for Windows maintains a single symlink that is put in the system PATH during installation only. Switching to different versions of node is a matter of switching the symlink target.

It sounds like privileges are just needed for the installation.

[davidebbo]

I think we can bypass that part by simply not using the symlink, and just putting things on the PATH.

[davidebbo]

Ok, so that seems to work. Try the following steps:

• Download https://github.com/coreybutler/nvm-windows/releases/download/1.1.1/nvm-noinstall.zip
• In Kudu console, create a d:\home\nvm folder and unzip nvm-noinstall.zip into it (e.g. using Kudu drag and drop)
• In that same folder, create a batch file called nvminstall.cmd that contains this:

if "%1" == "" goto usage
set NVM_HOME=%~dp0%

(echo root: %NVM_HOME% && echo arch: 32 && echo proxy: none) > %NVM_HOME%\settings.txt

nvm install %1

set path=%NVM_HOME%v%1;%path%

echo Current Node on the path is now:
node64 --version

goto :eof
:usage
echo Usage: e.g. nvminst 4.6.2

Node to install and use a version of Node, run something like nvminstall 4.6.2. Output should look like this the first time (node that installing npm takes a little while):

D:\home\nvm>nvminstall 4.6.2
Downloading node.js version 4.6.2 (64-bit)... Complete
Creating D:\home\nvm\\temp

Downloading npm version 2.15.11... Complete
Installing npm v2.15.11...

Installation complete. If you want to use this version, type

nvm use 4.6.2
Current Node on the path is now:
v4.6.2

And that's it, node and matching npm are on the path and usable.

It should be relatively easy for someone to polish this and turn this into a site extension that adds the nvm path to the PATH (using this technique), so that the only thing you need to do in your Kudu script is run nvminstall 4.6.2.

[ramijarrar]

Sounds really good. Will definitely try setting this up with a custom deploy (we maintain the meteor-azure script) and let you know how that goes.

[davidebbo]

The script ends up downloading 64 bit node even though I set it to 32 bit. Not sure why but it's probably a simple mistake somewhere.

@ramijarrar sounds good, please update with any follow up findings.

[ramijarrar]

You have to use "4.6.2 32" (otherwise it defaults to system arch)

[davidebbo]

Ah, I see. I tried it and confirmed! I expected that having arch: 32 in the settings.txt would take care of that.

[ramijarrar]

Getting errors relating to missing binaries post-deployment. It doesn't look like the app is being started with the custom Node (though I definitely have the right version in path throughout the build process).

@davidebbo Any thoughts?

Here is the full trace for reference:

## There is an issue with `node-fibers` ##
`D:\home\site\wwwroot\programs\server\node_modules\fibers\bin\win32-ia32-undefined\fibers.node` is missing.

Try running this to fix the issue: D:\Program Files (x86)\nodejs\node.exe D:\home\site\wwwroot\programs\server\node_modules\fibers/build
Mon Dec 05 2016 10:10:46 GMT+0000 (Coordinated Universal Time): Application has thrown an uncaught exception and is terminated:
Error: Missing binary. See message above.
    at Object.<anonymous> (D:\home\site\wwwroot\programs\server\node_modules\fibers\fibers.js:20:8)
    at Module._compile (module.js:446:26)
    at Object..js (module.js:464:10)
    at Module.load (module.js:353:31)
    at Function._load (module.js:311:12)
    at Module.require (module.js:359:17)
    at require (module.js:375:17)
    at Object.<anonymous> (D:\home\site\wwwroot\programs\server\boot.js:1:75)
    at Module._compile (module.js:446:26)
    at Object..js (module.js:464:10)
Application has thrown an uncaught exception and is terminated:
Error: Missing binary. See message above.
    at Object.<anonymous> (D:\home\site\wwwroot\programs\server\node_modules\fibers\fibers.js:20:8)
    at Module._compile (module.js:446:26)
    at Object..js (module.js:464:10)
    at Module.load (module.js:353:31)
    at Function._load (module.js:311:12)
    at Module.require (module.js:359:17)
    at require (module.js:375:17)
    at Object.<anonymous> (D:\home\site\wwwroot\programs\server\boot.js:1:75)
    at Module._compile (module.js:446:26)
    at Object..js (module.js:464:10)

[davidebbo]

Right, it's only on the path during the build script, but that doesn't affect the runtime.

Try creating a file named iisnode.yml in your D:\home\site\wwwroot folder, with the following content (replacing with the real path to your node.exe):

nodeProcessCommandLine: "D:\home\foo\bar\node.exe"

[ramijarrar]

Working now. Will let you know if I run into anything else.