Creating a realiable and scalable redirect server with Docker & Mocha tests (FTW??)
If you’re a web developer or systems engineer working with web applications you’ve probably had to deal with creating a redirect for your site. Whether this is a redirect of additional domain names (domain.co > domain.com) or rewriting old paths to a new location (/my/old/path > /my/new/path).
This will also mean you’ve worked with the dreaded mod_rewrite syntax which makes absolutely no sense at all and makes you feel you’re back in ’90. After an hour of excruciating struggling you will suddenly have an urge to start bingewatching friends, seinfeld and frasier.
Maybe the hardest part of getting your redirects to work is testing them. You’ll have to spin up apache, set your hosts file and hope for the best. I always keep my fingers crossed when finally deploying my work to production. There arn’t many commands as scary as service apache reload (maybe rm -rf /).
To make all of our lives a bit easier, here is a failsafe way to create a scalable redirect server that will always work as expected in any environment:
Dockerfile
The Dockerfile is based from the official Apache Alpine docker image.
It adds NodeJS to be able to perform Mocha unit tests of the redirect rules.
The tests are executed during build, and as such provide an ultimate failsafe for deployment.
httpd.conf
The httpd.conf file makes sure that the mod_rewrite module is loaded and that the server does not expose unnecessary headers.
It also adds an inclusion for the rewrite configuration.
conf.d/urlrewrite.conf
This is where the actual magic occurs. Add as many rewrite rules as you like!
test/redirect.test.js
The test file is a set of Mocha tests and a single convenience function that actually performs the rewrite check on the Apache server by calling the url with Axios and interpreting the result.
The check should cover most scenario’s but you might want to add some additional logic if you have really intense redirect logic.
The goal of the tests is to run them on container build, which will make sure that all the rewrite rules are checked before a new version is taken into production.
Unfortunately, there is no code coverage for mod_rewrite so you will have to make sure that you cover all your bases with the tests.
In this scenario, test-driven development is recommended. It will also help you write your redirect rules as you get immediate feedback on the expected output.
test.sh
The test runner that is called in the Dockerfile.
It does some magic like adding the rewrite for example.org, install Mocha and start Apache.
Make sure that this file is marked as an executable (chmod +x test.sh ) in your project.
package.json
Finally, we add the package.json file to make sure that Axios and Mocha are installed.
There is a small gimmick hidden in the test script. If you run this locally, it will build thedocker container, which will also start the tests.
If you have all these files in your project, you can add tests in the test/redirect.test.js file and the rewrite rules in the conf.d/urlrewrite.conf file. To verify your work, simply run npm test
The extra good part of this setup is that you can host it on GitHub and have your favorite CI tools like Travis or CircleCI build and test the docker image. If the tests fail, the CI tool will fail. If the tests succeed, you can have the CI tool automatically deployed the container o AWS or GCP and have it run in production where it can scale indefinitely.
With this setup, you will be able to finally say you are no longer afraid of mod_rewrite.
🎉🎉 Acknowledgements 🎉🎉
A big shoutout to the development team of Guidion, which served as a guinee pig for this project. They provided real-life examples, good discussions on architecture and a clear direction on what a developer would expect out of working with mod_rewrite.
Like any other tech company, they are always looking for good people. If you fancy working in an inspiring environment that incubated this project, check out their career site (sorry, dutch site only):
