Troubleshooting Node.js Deploys on Beanstalk – The Express v4 node ./bin/www Switch Up

I’ve gotten a ton of 502 errors and related issues that crop up when deploying the Beanstalk. One of the issues that cropped up a few times recently, until I stumbled into a working solution was the 502 NGINX error. I went digging around and ended up just trying to deploy a default, fresh from the ‘express newAppNameHere’ creation and still got the error.

I went digging through the Beanstalk configuration for the app and found this little tidbit.

Node Command (Click for full size image)
Node Command (Click for full size image)

I’ve pointed out the section where I’ve added the command.
[sourcecode language=”bash”]
node ./bin/www
[/sourcecode]

Based on the commands that are executed normally, it seems `npm start` would work work to get the application started. But I have surmised the issue is that the commands are executed sequentially;

[sourcecode language=”bash”]
node server.js
node app.js
npm start
[/sourcecode]

When these are executed in order, errors crop up and the command that should work `npm start` begins with a corrupted and error laden beginning. Leaving the application not running. However by adding the `node ./bin/www` to the text box all the others are skipped and this command is issued, resulting in a running application.

The other thing is to follow the now standard approach of just issue `npm start`, but being sure to replace what I put in the text box above (`node ./bin/www`) with `npm start` so that beanstalk only runs npm start instead of the ordered execution.

How to Build an NPM Package, Beginning the Symphonize Project

NPM has helped to build on the massive Node.js popularity and drive JavaScript from a simple scripting language in the web browser to a powerful and capable back-end server language. A quick refresher, NPM stands for Node.js Package Manager and each package is made up of:

  1. a folder containing a program described by a package.json file.
  2. a gzipped tarball containing [1]
    1. a url that resolves to [2]
    2. a <name>@<version> that is published on the registry with [A]
    3. a <name>@<tag> that points to [B]
    4. a <name> that has a “latest” tag satisfying [C]
    5. a git url that, when cloned, results in [1]
Path structure view in Jetbrains Webstorm IDE.
Path structure view in Jetbrains Webstorm IDE.

With that basic understanding of what a module is that NPM provides, let’s jump through the steps to build a module that provides some basic functionality. I won’t cover too many parts in detail yet, just the happy path to getting an NPM library running.

First let’s create an appropriate folder and file structure to get started with. Here’s the commands I ran to get started.

[sourcecode language=”bash”]
mkdir bin
mkdir lib
[/sourcecode]

With these two directories created I then created the following files in the designated paths. In bin I created the symphonize.js file and in lib I created a main.js file.

Now, I added the following code to the symphonize.js file.

[sourcecode language=”javascript”]
exports.Coupling = function (searchThis, forThis) {
var returnValue = ‘no’;
if (searchThis.indexOf(forThis) > -1) {
returnValue = ‘yes’;
}
return returnValue;
}
[/sourcecode]

In the main.js file I added the following.

[sourcecode language=”javascript”]
(function () {
var couple = require(‘../bin/symphonize’);
couple.Coupling("Sample text", "Sample");
}).call(this)
[/sourcecode]

There are a number of issues with this code, I know, but it’s just a sample of the minimal amount of code, folder structure and packages.json that I need to get this package installed and ready for iteration as I move forward with the actual code base and what functionality will actually be added. Speaking of the packages.json file, I created one and added the following configuration settings to it.

[sourcecode language=”javascript”]
{
"author": "Adron Hall",
"name": "symphonize",
"description": "Prints out data to the console! Will be iterating soon for real functionality!",
"version": "0.1.0",
"repository": {
"url": "git@github.com:Adron/symphonize.git"
},
"main": "./lib/main",
"bin": {
"replaceme": "./bin/symphonize"
},
"dependencies": {},
"devDependencies": {},
"optionalDependencies": {},
"engines": {
"node": "*"
}
}
[/sourcecode]

That is now enough for me to at least get the module added to the global NPM repository, get things pointed back to Github appropriately and move forward with actual coding. I might even setup some continuous builds and delivery at some point, since I’ve now got the end point of where the libraries will be going. The commands to get a module uploaded to the NPM Repository are as follows. This command of course assumes I’ve already added a user using npm adduser or I’ve added one via the web site interface at https://npmjs.org/.

[sourcecode language=”bash”]
npm publish
[/sourcecode]

I’ve now got everything prepared and uploaded to NPM there is now a symphonize module library ready for use.

My NPM Page for Symphonize. Click to go to the actual NPM page.
My NPM Page for Symphonize. Click to go to the actual NPM page.

Here’s a few quick references to where everything is:

Deploy a Framework Friday #3 with node.js + express.js

Time for the node.js “Deploy a Framework Friday”. First get node.js and express.js installed (i.e. npm install express) and then create your node.js application.

[sourcecode language=”bash”]
adron$ express nodejs

create : nodejs
create : nodejs/package.json
create : nodejs/app.js
create : nodejs/public
create : nodejs/public/javascripts
create : nodejs/public/images
create : nodejs/public/stylesheets
create : nodejs/public/stylesheets/style.css
create : nodejs/routes
create : nodejs/routes/index.js
create : nodejs/views
create : nodejs/views/layout.jade
create : nodejs/views/index.jade

dont forget to install dependencies:
$ cd nodejs && npm install
[/sourcecode]

Once the app is installed open up the app.js file and edit the code so that it reflects what is shown below.

[sourcecode language=”javascript”]
var express = require(‘express’)
, routes = require(‘./routes’);

var app = module.exports = express.createServer();

// Configuration

app.configure(function(){
app.set(‘views’, __dirname + ‘/views’);
app.set(‘view engine’, ‘jade’);
app.use(express.bodyParser());
app.use(express.methodOverride());
app.use(app.router);
app.use(express.static(__dirname + ‘/public’));
});

app.configure(‘development’, function(){
app.use(express.errorHandler({ dumpExceptions: true, showStack: true }));
});

app.configure(‘production’, function(){
app.use(express.errorHandler());
});

// Routes

app.get(‘/’, routes.index);

// Cloud Foundry Environment Variables
var port = (process.env.VMC_APP_PORT || 3000);

app.listen(port);
console.log("Cloud Foundry Demo Express server listening on port %d in %s mode.", app.address().port, app.settings.env);
[/sourcecode]

The emphasis is the port variable added for the VMC_APP_PORT. This variable is needed by the Cloud Foundry system to know which port that node will use to host on, which Cloud Foundry will then intelligently map to so you will get the standard default port 80 activity you expect. For more information about all this hosting mess with node.js check out one of my previous write ups on the topic on the New Relic Blog.

Once you’ve setup this file, then just deploy using the with npm support option that states the version of node.

[sourcecode language=”bash”]
vmc push –version=node06
[/sourcecode]

For more information about deploying node apps with npm module dependencies check out this blog entry on “Cloud Foundry supports node.js modules with NPM“.

All done. Yes, there is more Deploy a Framework Fridays coming up, so stay tuned!