Rancher provides a fantastic user interface over Docker. It helps you to see what’s going on in your Dockerised network, whilst at the same time providing a mechanism to create a whole stack of services with a single command.
As a developer, I’m keen that the code I use in development is as close as possible to the code I use in production. Therefore, when I use something like rancher-compose to create my network of services in a production-like environment at ec2, I also want to do the same on my own laptop. This substantially increases the chances that my code will work first time when I take it into production.
It therefore made sense to me to run a local Rancher server. When thinking about this, I discovered this Rancher blog post, which nicely covered some of the issues one might face. I got this working with relative ease.
A common failure point when going from development to production is scaling. A developer often will see no point in running more than one instance of his code. Push the code to production, run more than one, and suddenly it all fails. To avoid this, I wanted to run multiple VMs on my laptop, each managed by a local Rancher server.
This was a great idea, except that the overlay network, which makes it really easy for services to find each other, didn’t work. After some investigation, and help from the Rancher team, I managed to build an updated boot2docker.iso image on which networking was available.
I have just executed a single script, which invokes rancher-compose a few times, and watched as an Apache Solr instance starts up, Zookeeper before it, followed by various Solr pre-requisites such as creating a Zookeeper chroot, uploading configs, creating collections and aliases and starting my indexing process. One single click, and I have multiple hosts running, with freshly indexed content.
For anyone wanting to make use of this directly, when the above blog post tells you to use –virtualbox-boot2docker-url, replace this with: