azure-app-service / node Goto Github PK

The old documentation on how to configure PM2 with Linux App Service no longer exists on Github and references to PM2 have recently been removed from the official Linux App Service documentation (but still appear in Googles cache).

Can you at least add a readme to this repository on how to set that up from the docker blade under Linux App Service in the azure portal.

Also information on how to debug failed startup, and expected format for the 'start up file' input field in the portal blade.

I appreciate we can infer what to enter, but it should be made obvious. For example, entering pm2 start pm2.json causes a failed start, but works fine without PM2, and the pm2.json works fine locally. Clarity either way on whether this feature is still supported (which in theory, it appears to be) would be helpful.

pm2 started including pm2-docker binary from v2.x that has little benefits. Below link has more details
http://pm2.keymetrics.io/docs/usage/docker-pm2-nodejs/

You must click the "clear" button over and over until it finally activates, and clears the log stream. Also the entire log stream will jitter up and down a few pixels from time to time.

When I deploy one of these images to an Azure App Service instance and enable logging to filesystem, the log files contain these messages repeatedly:

can't open /dev/tty3: No such file or directory
can't open /dev/tty4: No such file or directory
can't open /dev/tty5: No such file or directory
can't open /dev/tty6: No such file or directory
can't open /dev/tty1: No such file or directory
can't open /dev/tty2: No such file or directory
can't open /dev/tty3: No such file or directory
...

It does contain my application logs to STD_OUT as well, but it gets buried under those messages which come and 30 a second. They are both in the files accessed via FTP and using the azure-cli az webapp log tail.

I have tried the 9.4 and 10.1.0.

Here are the container logs https://gist.github.com/Kyle-MacKinnon/063079a69d0909e5ba3b95dc42f1fec2

While migrating to Azure App Service my app fails to start and throws:

> NODE_ENV=production pm2 start server.js

internal/modules/cjs/loader.js:573
    throw err;
    ^

Error: Cannot find module '../constants.js'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:571:15)
    at Function.Module._load (internal/modules/cjs/loader.js:497:25)
    at Module.require (internal/modules/cjs/loader.js:626:17)
    at require (internal/modules/cjs/helpers.js:20:18)
    at Object.<anonymous> (/home/site/wwwroot/node_modules/.bin/pm2:11:20)
    at Module._compile (internal/modules/cjs/loader.js:678:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:689:10)
    at Module.load (internal/modules/cjs/loader.js:589:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:528:12)
    at Function.Module._load (internal/modules/cjs/loader.js:520:3)

package.json

{
  "name": "my-app",
  "version": "1.0.0",
  "description": "",
  "main": "server.js",
  "scripts": {
    "start": "NODE_ENV=production pm2 start server.js",
    "dev": "nodemon --ignore './public' server.js"
  },
  "author": "",
  "license": "ISC",
  "dependencies": {
    "pm2": "^3.3.1"
    ...
  },
  "devDependencies": {
    "nodemon": "^1.18.6",
  }
}

I saw App Service has pm2 installed globally, and if I comment out my start script it will pick the server.js automatically which then works, but for more control I really want to keep my own start script along pm2.

Any idea?
Thanks

In order to help reduce some of the clutter when selecting a runtime stack in the portal (see image below), and encourage the use of Node v6 runtimes that are actually part of the LTS stream (v6.9.*), could we remove the 6.2.2 and 6.6.0 containers, and simply provide Node v6 LTS images?

As these containers are specifically for node, why is there no node logging?

If you try to create a custom deploy script in your root called deploy.sh and point to it in .deployment, it takes a few deploys before it actually gets ran. Kudu seems to use the original deploy.sh

Creating a script with a different name seems to work better on the first try.

When using the ssh feature in Azure Portal, the initial prompt value shows the current folder as /home/site/wwwroot even though the pwd is /home. See the attached screenshot. I think the current behaviour is misleading.

As verified by Azure Support,

On this line https://github.com/Azure-App-Service/node/blob/master/10.10/Dockerfile#L40 we set the WORKDIR as /home/site/wwwroot which is why when you SSH in the prompt displays /home/site/wwwroot

But on this line https://github.com/Azure-App-Service/node/blob/master/10.10/Dockerfile#L9 we add cd /home to /etc/bash.bashrc so that whenever the shell is called (such as when an SSH operation is performed) the cd /home is executed and therefore the current directory is actually set to /home

Hi,

I have got a non-standard way of Node remote debugging worked. I'd like to ask advice on getting to work the standard way if possible.

Current approach
I am running App Service with a non-standard JS file location booted from an NPM script. E.g.

{
  "scripts": {
    "dev": "node src/main/main.js"
  }
}

I have currently got remote debugging working like this:

{
  "scripts": {
    "dev": "node src/main/main.js",
    "dev_debug": "node --inspect=0.0.0.0:11111 src/main/main.js"
  }
}

Then use AZ CLI SSH + port forwarding to get the port to my local machine. This work ok.

Other attempts
I initially had the following:

{
  "scripts": {
    "dev": "node src/main/main.js",
    "dev_debug": "node --inspect=0.0.0.0:$APPSVC_TUNNEL_PORT src/main/main.js"
  }
}

But I found that $APPSVC_TUNNEL_PORT did not have a value on the App Service machine. Do I need to enable some other setting to make sure this env var is populated correctly?

Or is there some better way entirely to get remote debugging working with Node and a custom file/script?

Any advice would be much appreciated!

Thanks

For the start command, which one is used? There is some precedence?

Hello,

I am using the v8.9.4 node image. I am trying to figure out how to get pm2 to start in built-in cluster mode. If I scale up my app service plan I can actually have more CPU. I want to get pm2 to spin up more clusters. this command pm2 start app.js -i max auto detects the number of CPUs and spins up right number of node instances.

This should in theory be transparent to the web app. I tried to spin up the cluster manually by running that command straight in console, and they spin up alright. Also use up CPU much better.

How can I use the current container to start my application using pm2 in cluster mode?

Thanks!

Hi,
node/6.9.3-1/sshd_config RhostsAuthentication looks like not a must.
when I comments it, docker image run successfully without warning '/etc/ssh/sshd_config line 15: Deprecated option RhostsAuthentication'.
I wonder to know if it led to a potential hazard with comment.
Thanks

When deploying repos created with a node version differing from that of the app service, and containing package-lock.json, the app service is often unable to do "npm install" correctly. It will complete, but not install the correct modules, and the node runtime will fail.

I modified my kudu deployment script to remove package-lock.json before the npm install.

Also, the purpose and behavior of package-lock.json is somewhat in flux: npm/npm#18103

At the very least, maybe add a warning to only use package-lock if you are deving on the exact same version your app service is running.

Since the node docker containers are extremely slow at doing an npm install, and often crash, MS support has been advising me to use the kudu bash tool to rerun npm manually.

Running npm in that shell results in an extremely old npm version (3.10.10), and the resulting node_modules folder structure is not compatible with the runtime node version.

You have to use the other command to do npm installs from the bash shell properly ("/opt/nodejs/8.1.0/bin/node" "/opt/npm/5.0.3/node_modules/npm/bin/npm-cli.js" install --production)

Why doesn't the default npm match the npm used by the build script? Why does npm install timeout/crash on even simple node apps?

We use Yarn as the package manager of choice on all our applications. We're now trying to deploy our first application to Azure and have found Yarn is not available and there seems to be no easy way to install it.

Our application references other repo's via git submodules which also use Yarn so we cannot just switch back to npm and I don't think maintaining npm lock and a yarn lock files in parallel is a sensible idea.

Your competitors already support Yarn or provide an easy path to installing it.
https://devcenter.heroku.com/changelog-items/1065
https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/ebextensions.html

Hi there - hoping this is the correct place for this question.

I am looking to upgrade some App Services to use the recently released Node.js version which patches for security vulnerabilities https://nodejs.org/en/blog/release/v6.14.3/

Are there plans to add this to the list of available versions in App Service - or is it best to add this version to my own apps manually?

If not - are PR's accepted for new versions, and how long would they take to be available on App Service?

Thank you.

As of this posting, current versions are Node.js v8.1.0 + npm v5.0.3