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:
- Incrementally build a storyline of what I know you need to know.
- Choose topics from real-world customer examples.
- 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
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online