Nginx serves many purposes. One is to sit in front of your Node.js, Ruby, Python, and other application servers, making it a single point of entry.

In the article "Drivers, Start Your Nginx!", I discussed how to install the Nginx web server and walked through how to set up a simple index.html "Hello World" program. An obvious next step would be to have Nginx act as a front-end to your application servers so it can accomplish what's called a "reverse proxy."

Wikipedia defines a reverse proxy as:

... a type of proxy server that retrieves resources on behalf of a client from one or more servers. These resources are then returned to the client as though they originated from the proxy server itself.

In our scenario, we will be using Nginx to front a number of Node.js servers for load-balancing purposes. Below I've created a simple Node.js application that can have the port specified when it's started. The variable port is necessary because we will have each Node.js application listening on separate ports and have Nginx round-robin to each one to spread the work around.

--- app.js ---

var http = require('http')

var port = process.argv[2]

http.createServer(function (req, res) {

res.writeHead(200, {'Content-Type': 'text/plain'})

res.end('Hello World\n')

console.log('%s Request for port %d', new Date(), port)

}).listen(port, '127.0.0.1')

console.log('Server running at http://127.0.0.1:%d/', port)

Note that specifying 127.0.0.1 as the IP address means the Node.js app will only accept local requests. This inherently means I can't access the Node.js application from my laptop's browser by specifying http://myibmi:5001 and instead will only allow connection attempts that happen from within my IBM i. This is good because I don't want the Node.js app to be accessible directly; I want all traffic to go through Nginx instead.

Below is the Nginx configuration that acts as a proxy for the Node.js application servers.

--- nginx.conf ---

pid /home/aaron/nginx/nginx.pid;

events {

}

http {

upstream node_servers {

   server localhost:5001;

   server localhost:5002;

}

server {

   listen 8080;

   location / {

     proxy_pass http://node_servers;

   }

}

}

The proxy_pass directive declares the protocol (http) and address of our Node.js application server. In some scenarios, you only need to proxy a single application server, but in our scenario, we have multiples. That's where the Nginx upstream feature comes into play as a mechanism to specify a group of servers. Note how the proxy_pass is connected to upstream by the "node_servers" name.

Now start the Nginx server, as shown below. I included pwd and cd commands to give context.

$ pwd

/home/aaron

$ cd nginx

$ /opt/freeware/sbin/nginx -c ~/nginx/nginx.conf

At this point I haven't actually started my Node.js application servers. If I visit the URL where Nginx is listening, I will get a 502 Bad Gateway error, as shown in Figure 1.

Figure 1: Nginx gives this response when application servers are down.

This error can be modified to convey that the site is under construction because it many times means the application servers are being restarted because of fresh deployment.

Now we'll go ahead and start both Node.js servers in separate shell sessions, as shown below.

$ node app.js 5001

Server running at http://127.0.0.1:5001/

Wed Dec 09 2015 02:19:31 GMT+0000 (UTC) Request for port 5001

Wed Dec 09 2015 02:19:33 GMT+0000 (UTC) Request for port 5001

Wed Dec 09 2015 02:19:34 GMT+0000 (UTC) Request for port 5001

Wed Dec 09 2015 02:19:35 GMT+0000 (UTC) Request for port 5001

Wed Dec 09 2015 02:19:36 GMT+0000 (UTC) Request for port 5001

Wed Dec 09 2015 02:19:38 GMT+0000 (UTC) Request for port 5001

Wed Dec 09 2015 02:19:39 GMT+0000 (UTC) Request for port 5001

Wed Dec 09 2015 02:19:45 GMT+0000 (UTC) Request for port 5001

$ node app.js 5002

Server running at http://127.0.0.1:5002/

Wed Dec 09 2015 02:19:30 GMT+0000 (UTC) Request for port 5002

Wed Dec 09 2015 02:19:32 GMT+0000 (UTC) Request for port 5002

Wed Dec 09 2015 02:19:34 GMT+0000 (UTC) Request for port 5002

Wed Dec 09 2015 02:19:35 GMT+0000 (UTC) Request for port 5002

Wed Dec 09 2015 02:19:36 GMT+0000 (UTC) Request for port 5002

Wed Dec 09 2015 02:19:37 GMT+0000 (UTC) Request for port 5002

Wed Dec 09 2015 02:19:38 GMT+0000 (UTC) Request for port 5002

Wed Dec 09 2015 02:19:43 GMT+0000 (UTC) Request for port 5002

You'll see the console.log statement output is in play and is letting us see a timestamp of when each request is processed. If you look closely, you can see the timestamps alternate between the two shell sessions, giving us confidence that Nginx is in fact doing a round-robin between the two servers. Victory!

This concludes the Nginx reverse proxy tutorial.

Now, I have a question for you.

What are some other things you want to know concerning open source on IBM i?

I generally write from three foundations:

1. Incrementally build a storyline of what I know you need to know.
2. Choose topics from real-world customer examples.
3. Get feedback from readers on topics they'd like to know more about.

So, what other topics would you like to see covered? Is further detail needed to clarify previous topics of personal interest?

Let me know in the comments or reach me directly at This email address is being protected from spambots. You need JavaScript enabled to view it..

Aaron Bartell is Director of IBM i Innovation for Krengel Technology, Inc. Aaron facilitates adoption of open-source technologies on IBM i through professional services, staff training, speaking engagements, and the authoring of best practices within industry publications andwww.litmis.com. With a strong background in RPG application development, Aaron covers topics that enable IBM i shops to embrace today's leading technologies, including Ruby on Rails, Node.js, Git for RPG source change management, and RSpec for unit testing RPG. Aaron is a passionate advocate of vibrant technology communities and the corresponding benefits available for today's modern application developers. Connect with Aaron via email atThis email address is being protected from spambots. You need JavaScript enabled to view it..

Aaron lives with his wife and five children in southern Minnesota. He enjoys the vast amounts of laughter that having a young family brings, along with camping and music. He believes there's no greater purpose than to give of our life and time to help others.