Have you ever had a situation where there was a bug in some deployed application, but the simple act of running that application locally made the bug impossible to find? It could’ve been that there was no local infrastructure (e.g. databases) to back the running services. Or port-configuration was hard-coded into the application (so it collided with other ports on your host machine; people love to hard-code to port
8080). Or, scarier still, the application was never actually run locally because it was deemed too difficult in the first place (in which case, you wonder how the deployed application worked at all)?
In an age where we have Docker to effectively ship the containerized machines that our applications run on, there really isn’t an excuse for making local development a more consistent experience. If there is greater confidence in running code locally, it becomes quicker to spot and fix bugs. It becomes quicker to onboard new developers and make them productive with the codebase. It allows you to run the application alongside other applications more easily (which is crucial if you are on a team that is in charge of multiple microservices).
So in this article, we’re going to go over how to set up a local, containerized environment for us to run a simple application stack.
The application is going to be an HTTP server that simply says "Hello, world", albeit with a counter to say how many times a visitor arrived at the site. We will build this application in Go, and use Redis as external storage for the counter.
Crucially, we want the following things out of the setup:
- Developers should only need
docker-composeinstalled on the host machine to run this application, not
- However, developers that want to opt-out of
dockershould still be able to run the web service entirely on their host machine
- Local ports should not cause interference with existing apps. We are not going to hard-code these infrastructure details – it should be easy to re-configure
- Developers should be able to get into the container and start running commands as though they were the host. This will encourage developers to do their development in the container as opposed to outside, where possible.