This is the fourth post in the series about building a three-tier application for demonstration, lab, and education purposes. If you have been following along, you have created the base Photon template as well as simple database and application servers.
This post covers the final layer of our stack, the web presentation tier. I have said it before, but the configuration of the web server here is really simple, and if you have made it this far, you’re golden.
The Web Server (web-01a)
All of the hosts in this application run “web server” software, but this one has the web server designation because it is the one that the user directly accesses. The entire back end could be replaced with real application middleware and an RDBMs, but the user expects this one to present an SSL-encrypted web page on port 443. This time, I have chosen not to use Apache, and there is no need for Python. There is no CGI, and minimal configuration is required aside from issuing another certificate for the SSL. This tier is mostly interesting because it will support the virtual name of the application in addition to the real name(s) of your web server(s).
The red box in the following diagram highlights the component that we are building in this post.
Again, the first steps look quite a bit like the steps we performed for the application and database servers as we assign the personality to the template. I will again outline the steps here as a reminder. Details can be found in my post about the database server.
Let’s get started!
- Deploy a copy of the base Photon template you created by following the steps in my first post.
- Name it something that makes sense to you for your web server. I called mine web-01a
- Power it up and log in as the root user
- Change the hostname in /etc/hostname and in /etc/hosts
- Change the IP address in /etc/systemd/network/10-static-eth0.network
- Use a SSH client to access the machine as root (makes pasting possible)
Instead of installing Apache again, we are going to use nginx. You can do the same thing with Apache, but I wanted to try something a little more lightweight and the nginx configuration for this use case is really simple.
Install nginx to be used as a reverse proxy
The web server machine will function as a reverse proxy, sending user requests bound for port 443 on this server to the application server at https://app-01a.corp.local:8443
# tdnf install nginx
The nginx install is less than 6 MB and takes a few seconds:
Configure the reverse proxy
Edit the configuration file, /etc/nginx/nginx.conf
# vi +116 /etc/nginx/nginx.conf
by adding the following at the bottom of the file, at line 116, just before the closing “}” in the file.
# HTTPS server
#
server {
listen 443;
server_name webapp.corp.local;
ssl on;
ssl_certificate /etc/nginx/ssl/webapp.pem;
ssl_certificate_key /etc/nginx/ssl/webapp.key;
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 2m;
location / {
proxy_pass https://app-01a.corp.local:8443/;
proxy_set_header Host $host;
proxy_redirect http:// https://;
}
}
Notice that we need an SSL certificate and a key to make this work. We have done this before, so let’s create those now.
Make the ssl directory and switch into it
Let’s just create the certificates in the place that the server expects them to be.
# mkdir -p /etc/nginx/ssl # cd /etc/nginx/ssl
Build the configuration file
It is common for multiple web servers to be configured in a pool, behind a load balancer. I create the certificate here using a name, webapp.corp.local. This name can be assigned to the load balancer’s VIP. If there is only one web server, as in my example here, this name can also be an alias that resolves to the one web server. For simplicity, and possibly for other use cases, the certificate configuration we build here includes the names of three web servers: web-01a, web-02a and web-03a.
Create the file webapp.conf
# vi webapp.conf
with the following contents, modified as needed for your environment:
[req] distinguished_name = req_distinguished_name x509_extensions = v3_req default_md = sha256 prompt = no [req_distinguished_name] C = US ST = California L = Palo Alto O = VMware OU = Hands-on Labs CN = webapp.corp.local [v3_req] keyUsage = keyEncipherment, dataEncipherment extendedKeyUsage = serverAuth subjectAltName = @alt_names [alt_names] DNS.1 = webapp.corp.local DNS.2 = web-01a.corp.local DNS.3 = web-02a.corp.local DNS.4 = web-03a.corp.local
Save and close the file.
Generate the key and certificate
Note that this is a long command and you may need to scroll to the right to get all of it. Ensure it ends with “webapp.conf”
# openssl req -x509 -nodes -days 1825 -newkey rsa:2048 -keyout webapp.key -out webapp.pem -config webapp.conf
(optional) Validate that the PEM file “looks right”
I put this command here for those who want to look at the certificate. It is a good command to know in case you have a certificate file and want to know what information it contains. That can help you match the certificate to the proper host without needing to install it and then find out it is not the right one.
# openssl x509 -in webapp.pem -noout -text
Start the nginx server and configure it to startup when the VM boots
# systemctl start nginx # systemctl enable nginx
Verify
With the other components (db-01a, app-01a) online, reachable and tested, you can test the whole solution with curl from the console of the web server
# curl -k https://web-01a/cgi-bin/app.py
This should return the data from the database in HTML format by executing the script on the application server.
You can filter the results by appending a querystring. Try this one:
# curl -k https://web-01a/cgi-bin/app.py?querystring=science
That query should return a single entry with a name containing the word science. It may be difficult to read on the command line since it is HTML. These look nicer via a GUI web browser anyway, and you can modify the filter using the form at the top of the table:
That’s it!
You now have the components of a rudimentary three-tier web application that you can use in your lab. I hope this build has provided some useful tools for you. In the final post, I will use this set of VMs and cover an example of how to implement a pool of webservers in front of the application and database tier.
Thank you for reading!
Oh, just one more thing…
Notice the pretty green lock next to the URL in my web browser in the previous screen shot?
SSL Certificate Trust
In this application, we have a self-signed SSL certificate. It should be created with the name webapp.corp.local, or whatever you selected for your environment. To get rid of the web browser security warnings and have the shiny green lock show up, you need to do two things:
Configure DNS Records
The only record you need from the client side is one that points to webapp.corp.local.
If you have a Windows-based DNS server, you can create the records using PowerShell. The following 2 lines create a DNS host (A) record for web-01a.corp.local and then a DNS alias (CNAME) record for webapp.corp.local that points to it.
PS> Add-DnsServerResourceRecordA -ComputerName 'dns.corp.local' -ZoneName 'corp.local' -name 'db-01a' -IPv4Address '192.168.120.10' -CreatePtr PS> Add-DnsServerResourceRecordCName -ComputerName 'dns.corp.local' -ZoneName 'corp.local' -Name 'webapp' -HostNameAlias 'web-01a.corp.local.'
This configuration allows the virtual name webapp to be separate from the web-01a name and enables the addition of other web servers to a pool, followed by the reassignment of the webapp name to a load balancer IP.
If you don’t have Windows-based DNS, you can edit your /etc/hosts file on the client or add the DNS records to your nameserver using the procedures required for your environment.
Trust the Self-Signed Certificate
Once you have name resolution knocked out, you need to trust the certificate on your client. You can really trust the certificate, or you can sometimes create an exception in the web browser. Do whichever works for you and makes you happy. Without trust, this is what the connection looks like in Chrome:
In our labs, we download the web server’s certificate to the client machine and add it to the Windows Trusted Root Certification Authorities store or one of the subtrees within Keychain Access on MacOS. That will handle IE on Windows, and Chrome browsers on Windows and MacOS.
If you save the certificate file to your desktop in Windows and double-click it, the bold text pretty much sums up what you need to do.
There are a variety of ways to get this done, and there are some shortcuts, but the process has not changed in many years and this Microsoft Windows Blog article covers a process that works.
Firefox manages its own trust store, so you need to import it separately if you want to use that browser. Check the Mozilla Wiki for detailed instructions about how to do this. Note that newer versions of Firefox have implemented more strict checking. Basically, they refuse to accept a “leaf” certificate that is specified as a Certificate Authority certificate (why is your web server using the CA certificate??) and will not allow a non-CA certificate to be added to its trusted root CA certificate store. Getting this to look nice requires additional hoops that are beyond the scope of this article. We have a Microsoft CA implemented in our labs and generally issue certificates from there. Since that CA is trusted by all clients within the environment, there is no issue.
Thank you again for reading!
You can finish the series with the last post: Use Cases.
