A Tale of Two Web Servers
Many people know that IBM i already had the Apache web server. Now, Njinx is available too.
It was the best of times, it was the first of times. At least, it was the first time I announced a new open source delivery in a COMMON session! In a crowded room in Orlando, I declared a fresh addition to 5733-OPS: the nginx web server, to be delivered into option 11 of the product.
Many people know that IBM i already had the Apache web server. Now, another option is available. In today’s post, I aim to give a quick overview of the two major web servers available.
Apache
First up, let’s discuss Apache. This offering is a revered piece of the IBM i open source story. It was actually the first open source software that we assimilated into the operating system. It has been a fundamental part of our platform. It shows that open source can stand the test of time. After all, the integration efforts were completed in 2002! Here we are, fifteen years later, still maintaining, supporting, and enhancing it!
Odds are, your system has it installed, because lots of things depend on it! The web-based Navigator for i interface, IBM i Access for Mobile, and the Integrated Web Services (IWS) all run on Apache. Most PHP, Websphere Application Server, and Integrated Application Server deployments are also Apache-based. Without this web server, your IBM i system would be severely handicapped!
For those unfamiliar with the Apache offering, here’s a quick primer. Today, the Apache HTTP server is shipped as part of the 5770-DG1 product. There’s also a group PTF available.
Creating an Apache instance is easy. The common, well-known way is through the HTTP Administration UI. To get there, just point your browser at http://<system_name>:2001/HTTPAdmin.
One can create Apache HTTP Server instances outside of the HTTP Administration UI, as outlined in this support document. However, that’s not common. Either way, it’s quite simple to get your first web page up and running. The HTTP Administration UI will create a boilerplate web page that is served up as default.
Nginx
Apache has long been, and will continue to be, the highly integrated, highly utilized web server for IBM i. This is particularly true for most Java- and PHP-based applications. We’re not moving workloads off Apache onto nginx, and don’t expect the HTTP Administration UI to become an nginx interface. Simply put, we delivered nginx so that users have another option available. For certain deployments, nginx may be the right choice for your application.
It’s worth noting, though, that nginx is not a direct competition to Apache. In fact, they can work together. Several websites have used nginx for its reverse proxy or load balancing capabilities while using Apache for serving up data from the application server.
It just so happens that this new HTTP server fulfills some important needs. Perhaps most importantly, nginx can effortlessly be run inside a chroot container. What is chroot? Delivered as part of 5733OPS Option 3, the chroot utilities are based on the open source ibmichroot project. With a chroot container, applications can be deployed inside an Integrated File System (IFS) “jail” without risk of damaging or compromising other parts of the IFS. It has become an important mechanism for PASE, since it can be useful for so many things like code compilation, application deployment, etc. When running a web server inside a chroot “jail,” it grants extra security and integrity.
Also, nginx uses the same SSL directives as on other platforms. In this sense, it varies from our Apache solution. Apache uses the IBM i system SSL capabilities, meaning that the SSL directives are somewhat unique to IBM i. In the Apache case, setup is normally done in the HTTP Administration UI (shown earlier). Nginx, on the other hand, uses the popular OpenSSL capabilities (delivered as part of the 5733-SC1 product) to accomplish this task. Neither SSL methodology is better. Apache is more aligned with traditional IBM i configuration, where nginx is aligned with the greater open source community.
Since nginx uses industry-standard SSL technology, that opens up even more potential. For instance, the letsencrypt.org web site allows anyone to obtain a trusted certificate at zero cost. You can use a letsencrypt.org certificate with either Apache or nginx, but with one can more easily automate the update and renewal of certificates with nginx.
So, how to get running with nginx? Well, first you’ll need 5733-OPS options 7 and 11 installed with the required PTF’s (SI64951, SI63663, and SI62570). Better yet, install level 4 or later of the open source PTF Group (SF99123, SF99223, or SF99225, depending on IBM i release). At the time of this writing, level 4 has not been released, but I promise it will be soon!
Once you have the PTFs installed, create an nginx.conf file, along with any accompanying files, then invoke nginx with the “-c” option. To stop it, just add “-s stop” to the command. In the following screen shot, my nginx.conf defines a simple web configuration with 5 worker processes. The first command in this screenshot, “ps,” shows no nginx processes running. Then I start the web server, run “ps” again (which shows my nginx process and 5 worker processes), then stopped it with the “-c” invocation:
Of course, before I run the nginx stop command, I can view the webpage in my browser:
You might notice that when you run the nginx command, control returns immediately to the terminal. While this is varies from other shell commands, it is completely normal. Nginx submits worker jobs in the background. This is analogous to running in batch. For more information on nginx, a great starting point would be the nginx beginner’s guide.
Lots of Choices
As a general rule, the realm of open source provides a multitude of options. Apache and nginx are great options for scalable, high-performance web hosting. However, one can be web serving with neither of these! Often, there are several HTTP server options available as part of each language’s offering set also. Python users could deploy CherryPy, Node.JS users might use the built-in http/https modules, and so on.
So, which do you choose? In some cases, there are obvious answers. If you’re learning a language and building your first web application, pick what’s most readily available. If you need to run a production web page inside a chroot, go to nginx. If you like the highly-integrated experience that Apache provides, take that route. In some cases, of course, the correct route might not be as obvious. I don’t intend to provide an in-depth analysis comparing the two web technologies. The Internet is rich with such analysis from people more qualified than I. Instead, I’m here to assure you of two things: first, that my team is delivering solutions for a wide range of enterprise applications; second, that there is no “wrong” choice between Apache and nginx. Both are highly sophisticated pieces of software that will have no problems meeting the demands of your organization. Whether you’re modernizing an application’s user interface, deploying web services for mobile applications, or creating an original web solution, open source software can drive your project to success!