Introduction

NOTE: This blog post is an indirect continuation of a series of relatively short AWS automation posts, the last of which in the series can be found here. In that blog post, I discussed using an appspec.yml file in conjunction with scripts I had stored in a GitHub repository I owned that execute before installation on an EC2 instance finished, or before, depending on the task sequence I needed those tasks to be performed in.

In this blog post, I will be extending the InstallReactScripts-Build script to move some configuration files I need to the correct directories within my Ubuntu 20.04 instance, enable the Apache configuration, and restart the Apache server to serve my ReactJS web application on my Apache server.

IMPORTANT: This blog post assumes you have pre-configured Route 53 hosted zones in conjunction with a domain that you own. This particular project I am showcasing here already has Route 53 Hosted Zones configured with a namecheap domain name of teamredbrowser.team. In the interest of saving time, I will not be showcasing that setup, as it is fairly standard and well-documented elsewhere on the Internet.

In a production environment, ideally whatever web applications, websites, or projects that you want to be reachable via the world wide web should ideally NOT be hosted on just a specific port. Most people reading this post know this fact already, but it bears repeating. Additionally, Apache server hosting opens up monitoring tools and more functionality for us, so they are quite useful.

Setting Up Your VHost File

What are Virtual Host files? To paraphrase Apache’s own documentation, virtual hosts are essentially different web sites on a single machine. You can have either IP-based virtual hosts (multiple different IP addresses for each web site) or multiple different domain names running on each corresponding IP address.

Please note that since I am creating the entire server through Terraform plus AWS, I have direct access to my server configuration file, usually named httpd.conf. It is for this reason that I will NOT be using a .htaccess file, as it slows down every request the user makes to the server, to make a long story short. This is best explained by Daniel Morrel in his blog post on his website that discusses SEO (search engine optimization). For now though, I will continue on without a .htaccess file.

Here’s what a name-based virtual host file looks like.

For the most part, you can keep the overall FORMAT of this file the same, but obviously, you would have to swap out your ServerName, ServerAlias, DocumentRoot and Directory text to fit your server’s needs. For a quick start, however, you can consider this to be an easy “virtual host starter pack” that will work for most (if not all) Apache servers. That is of course assuming that you have your Route 53 Hosted Zones setup to point to your domain properly.

It is worth mentioning that in the picture above, the Directory link being /var/www/html/FrontEnd/teamred/build is referencing a directory that WILL exist AFTER a script is run on my instance after all the ReactJS files have been retrieved from my GitHub repository. React builds are essentially production-ready versions of a ReactJS application, and can be made using the command npm run build, which I will discuss more below.

Modifying the Post-Installation Script

Moving on, let’s talk about where this virtual host file actually goes. If you’re on a Linux machine, the default route will usually be /etc/apache2/sites-available. Since I am using AWS CodePipeline with an appropriately set-up Appspec.yml file (again, you can find this here) I will simply update my InstallReactScripts-Build script.

The above picture does a few things automatically for us. Firstly, after all of the files we need to run a React build are moved into our EC2 instance, the script switches directories to where my pre-configured vhost .conf file (teamredbrowser.team.conf) to the sites-available directory I was discussing before. Then the script changes directories to the sites-available directory itself and performs a2enmod rewrite and restarts Apache using systemctl restart apache2. a2enmod is a script that enables the module specified (in this case our teamredbrowser.team.conf file) by creating symlinks within the mods-enabled directory. No need to show that though! All you need to know is that the vhost file is now enabled after our handy script enables it and subsequently restarts Apache. Finally, the script changes directories back to my project’s folder (/var/www/html/FrontEnd/teamred), installs the required React scripts to interact with the app onto the EC2 Instance, and then runs npm run build. Your vhost file, if you set it up like I did to point to your build folder once it is created, should now redirect traffic to your domain! Congratulations.

Whew! Seems like a lot of work, right? Well if you were doing this on your own, you’d be right. However, that’s the beauty of automation - once you know that these files need to exist in specific directories and you have configured them once, you can automate the process of copying them to the directories that need them as I have shown you today.

Happy automating!