Serving a webpage takes up a lot of resources – especially when it is dynamically generated like those created via PHP. Each time someone requests a page, the backend has to perform a multitude of operations to deliver it. Concepts like caching are very familiar to anyone who has run a WordPress website. However, this idea is not limited to such a high level operation alone. We can install applications on the server itself that create cached copies of existing webpages and deliver them instead of regenerating from scratch.
One of the most famous server-based applications is known as Varnish Cache. In fact, any of you who have worked with a WordPress caching plug-in like W3 Total Cache, know that it has options to work in tandem with it, thereby improving its efficiency. If you’re limited to a shared hosting environment, you probably have no control over whether or not Varnish is installed on your server. You simply don’t have the permissions to download and install the necessary packages. But if you have a VPS or a dedicated server, you can very much do so.
In this tutorial, let’s look at how to install Varnish on a fresh WHM installation running on Cent OS. We are going to have to do the following sequentially:
- Change the Apache listening port;
- Locate the correct Varnish repo;
- Install the EPEL yum repository;
- Install varnish;
- Configure the varnish port and functionality;
- Start and monitor the service.
Change the Apache Listening Port
The way Varnish works, is by intercepting all traffic on the port that Apache listens in. It then interacts with Apache in the background and acts as a “middleman”. This is what is known as a “reverse proxy” since it’s a service that acts as a server instead of the client. But to pull this off, we need to configure Apache to listen on a port other than the default 80. Otherwise, it will be Apache that responds to web requests and not Varnish.
So we’re going to tell Apache to listen to port number 8080 instead of 80. After varnish has been installed, we’re going to configure it to use the port 8080 to communicate with Apache, effectively sitting in between the client and the server. I’d already written earlier about how to open up ports through the CSF firewall of WHM as well as how to change Apache’s port. If you want more details, you can refer to that article. For now, here’s a simple screenshot of changing Apache’s port to 8080 via the “Tweak Settings” option in WHM.
Once you make this change, your website will be unavailable until the completion of the process. So make sure that you’re ready to go the whole way before you start! Now it’s time to locate the correct varnish repository for your installation.
Locating the Correct Varnish Repo
This URL provides the complete directory of repositories for varnish sorted by Linux distributions:
http://repo.varnish-cache.org/
If you’re running CentOS, then we need to go to the “redhat” folder. Over here, you can see varnish versions from 2 to 4. Now the version you want to install will depend not only upon your OS, but upon its version as well. To find out which version of CentOS you’re running, login via SSH and type in the following command:
cat /etc/redhat-release
This will give you the release number of your OS and you can use that to figure out which version of varnish is compatible via this documentation page: https://www.varnish-cache.org/installation/redhat . Even with all this, it can be a bit tricky to find out which is the correct version of varnish for your CentOS installation. However, you can always install a slightly lower version to be on the safe side. You can see in the screenshot above, that my CentOS version is 6.6. So I found the following URL to hold a compatible varnish version:
http://repo.varnish-cache.org/redhat/varnish-3.0/el5/noarch/varnish-release/varnish-release-3.0-1.el5.centos.noarch.rpm
Once you’ve settled on which repo works for you, it’s time to set up the EPEL repository.
Setting up the EPEL Repository
The varnish installation requires a lot of dependencies. If you simply try and rpm it on a cold installation, several dependencies will fail and your installation won’t succeed. This is where EPEL comes in. It stands for “Extra Packages for Enterprise Linux” and is a convenient one source repository for most common Linux packages. Having this available allows you to install a much larger set of software without worrying about additional libraries that may not be present.
Indeed you can install varnish itself via EPEL, but they have some restrictions on non-backward-compatible version releases and so you won’t always get the latest software. However, don’t make the mistake of starting a varnish installation without it.
To enable and start using EPEL, all you need to do is type the following command into your SSH command box:
yum install epel-release –y
That’s it! You don’t need to take any further action as far as the EPEL repository is concerned. Now it’s time to move on to the installation of varnish itself.
Installing Varnish
To get started with installing Varnish, you need to recall the rpm URL you selected in the second step. Since I’ve already selected mine, I open up my SSH console and type in:
rpm --nosignature -i http://repo.varnish-cache.org/redhat/varnish-3.0/el5/noarch/varnish-release/varnish-release-3.0-1.el5.centos.noarch.rpm
This downloads the package which I can then install using the standard “yum” command like this:
yum install varnish
If all goes well, the entire installation should complete without a hitch especially with the EPEL libraries present. Unfortunately, you won’t know yet whether or not you got the right version for your OS. But I can confirm that the above repo works for CentOS 6.6. Now that the basic packages for varnish are installed, it’s time to configure it to work with Apache and WHM.
Configuring Varnish
The first thing to do is to tell varnish to listen in on port 80 for incoming http requests. Open up the following file for editing:
/etc/sysconfig/varnish
Here, locate the variable named VARNISH_LISTEN_PORT and set it to 80 as shown in the screenshot below:
Save the file and this stage of configuration has finished. In the next, we need to instruct varnish to communicate with Apache at port 8080 as well as tell it to cache not just HTML-based pages, but also CSS, JavaScript and various types of images. These instructions are contained in what is known as a “vcl” file which is then compiled and used by varnish. Here is the file we need to edit:
/etc/varnish/default.vcl
My server IP address is 87.76.28.180, so the following lines need to be present in the above file:
backend default {
.host = "87.76.28.180";
.port = "8080";
}
It’s possible that your version of default.vcl already contains something like this so you just need to modify it, making sure that you insert your own IP address instead of the one already present. Make sure that the port is 8080 – the same as the one to which we changed it in the very first step. For the remainder, paste the following into the file as well:
sub vcl_recv {
if (req.url ~ "\.(png|gif|jpg|swf|css|js)$") {
return(lookup);
}
}
sub vcl_fetch {
if (req.url ~ "\.(png|gif|jpg|swf|css|js)$") {
unset beresp.http.set-cookie;
}
}
The first block of code examines the incoming URL for any of the specified extensions and if there is a match, returns the file from cache if it exists. The second is meant to store images without any cookies. Save this file after you make the changes and return to the SSH console. We are now ready to start the varnish service with the following commands:
chkconfig varnish on service varnish start
If you selected the correct varnish repo in the second step, everything should work out fine and you should get a success message in green after you execute the second command:
In addition, you can also see what varnish is doing behind the scenes using this line:
varnishstat
This will give you a real-time compilation of what varnish is up to in great detail. You can use it to figure out what’s happening behind the scenes and troubleshoot errors.
And that’s the complete varnish installation from scratch. It now sits between your server and the various clients making sure that your backend doesn’t have to work extra hard to generate already created pages and files.
