Use this handy technique to get the most from your IBM i Web app resources
Editor’s note: This article is excerpted from chapter 11 of Open Source Starter Guide for IBM i Developers.
Apache is the latest incarnation of HTTP server on IBM i. What can you do with Apache? Well, since Apache is so efficient in serving up static resources and resources passed to it from CGI programs, you can leverage it for many things. I use it primarily as a reverse proxy for the plethora of programs, pages, and other plumbing in my Web apps (nice alliteration, eh?).
What is a reverse proxy? A very handy little tool, in my humble opinion. If you are constrained on external IPs like I am (I get two!), then the ability to run multiple websites and yet pipe them to a single IP address is quite handy. My public-facing websites all share the same public IP, but behind the scenes, Apache directs them to their correct internal server instances—and I have a bunch of them running on my IBM i.
Here is an example of what my main Apache configuration file looks like:
# Configuration originally created by Create HTTP Server wizard on Mon Oct 22 13:16:16 MDT 2012
LoadModule proxy_module /QSYS.LIB/QHTTPSVR.LIB/QZSRCORE.SRVPGM
LoadModule proxy_http_module /QSYS.LIB/QHTTPSVR.LIB/QZSRCORE.SRVPGM
LoadModule proxy_connect_module /QSYS.LIB/QHTTPSVR.LIB/QZSRCORE.SRVPGM
LoadModule proxy_ftp_module /QSYS.LIB/QHTTPSVR.LIB/QZSRCORE.SRVPGM
LoadModule proxy_balancer_module /QSYS.LIB/QHTTPSVR.LIB/QZSRCORE.SRVPGM
LoadModule zend_enabler_module /QSYS.LIB/QHTTPSVR.LIB/QZFAST.SRVPGM
AddType application/x-httpd-php .php .php5
AddHandler fastcgi-script .php .php5
AddType video/ogg .ogm
AddType video/ogg .ogv
AddType video/ogg .ogg
AddType video/webm .webm
AddType audio/webm .weba
AddType image/jpeg .jpg
AddType image/jpeg .jpeg
AddType image/png .png
AddType image/svg+xml .svg
AddType application/x-shockwave-flash .swf
AddType video/mp4 .mp4
AddType video/x-m4v .m4v
AddCharset UTF-8 .htm .html
DirectoryIndex index.php index.html
ProxyPass /asaap3 http://10.0.10.206:6080/asaap3
ProxyPassReverse /asaap3 http://10.0.10.206:6080/asaap3
ProxyPass /asaapwm http://10.0.10.206:6080/asaapwm
ProxyPassReverse /asaapwm http://10.0.10.206:6080/asaapwm
Allow From all
Allow From all
ProxyPass / http://10.0.10.205:3030/
ProxyPassReverse / http://10.0.10.205:3030/
As you can see, or maybe you can’t, I have several different server instances referenced here. Way at the top, the initial LoadModule directives are creating an environment where PHP apps could live, if needed. They load service programs from the ZendSvr library. I don’t have any CGIDEV2 CGI pages that live in the main configuration, but I certainly do pass the traffic back to some CGIDEV2 sites. The next thing to pay attention to is the Listen directive, which is basically saying that this server instance is running on an internal address of 10.0.10.200 on port 80, standard for HTTP.
So, you might be thinking, if this is an internal address, how does the outside traffic get in? That takes a firewall, and I have one that is out there listening with an Internet-addressable IP on port 80. The firewall then maps that traffic back to my internal address (Network Address Translation—NAT—is the process). At that point, Apache is examining headers to see which Web address is being requested, so that it can figure which host to map the traffic to internally. I skipped over all the MIME types that Apache will allow in, but those are listed (mostly video and media files)—but the first virtual host is the asaap.com site. Note that www.asaap.com will be directed to the virtual host, but also any (*) host on the asaap.com domain will also end up here (for example, mobile.asaap.com, demo.asaap.com).
Finally, we see two reverse proxy paths that point to different subdomains. This happens to be a Tomcat server instance, so the two subdomains are actually pointing to two different applications running on Tomcat. So basically, if you typed in the URL of www.asaap.com/asaap3, it would be mapped to the asaap3 application running on Tomcat on port 6080 at the internal address on 10.0.10.206.
The beauty of the reverse proxy is that you can have all sorts of servers supplying resources to the same Web domain without anyone being the wiser. So, I could also have a Web server running PHP but referenced in the asaap.com URL as www.asaap.com/blog and actually have it point to a WordPress instance running elsewhere on my network. Yet even though someone navigated from www.asaap.com/asaap3 to www.asaap.com/blog, they never knew that they were changing servers. Very cool and flexible!
The other thing I have found helpful with using Apache for a reverse proxy is that by having a single “main” instance that receives all the traffic, it allows me to bounce a particular instance or change a configuration of that instance without losing all my websites. In addition, if all the servers serve sites that share the same domain, your configuration of SSL can reside on the “main” Apache instance with a wildcard certificate, encrypting all of your external traffic without the hassle of configuring SSL for every server instance you have. If you have PHP, node.js, Tomcat, CGIDEV2, Rails, and some static resources as well, then a reverse proxy will just make life much simpler. And, in this business, simple is good!
What do CGI apps look like? Well, we can take a quick look at some CGIDEV2 configuration directives. You might see something like this:
# MobileREM directives
ScriptAliasMatch /mobilerem/(.*) /qsys.lib/mobilerem.lib/$1
Alias /mobileremjs /www/mobileapps/htdocs/mobilerem/js
Alias /mobileremcss /www/mobileapps/htdocs/mobilerem/css
allow from all
In this case, the URL is mapping anything that follows the /mobilerem/ subdomain to the mobilerem library. So, if I had an CGIDEV2 RPG program in the mobilerem library called mypgm.pgm, and the URL parsed looked like this: www.mysite.com/mobilerem/mypgm.pgm, then the directive above would execute the CGI program in the mobilerem library. Nice and flexible!