A few weeks back I wrote about playing with Habitat.sh after seeing the Chef team present it at their Berlin meetup. After writing my own super-simple Python+Flask service and writing a plan for it, I decided it was time to up my game a little and create a Habitat plan for something a little meatier.
It will probably be of no surprise that I decided to run with CrateDB.
Actually, before CrateDB, I ran with Jenkins. But that is a story for another day.
I Love It When A Plan.sh Comes Together
Writing a plan for CrateDB did not turn out to be too difficult:
- There was an existing core/elasticsearch plan already in place
- Crate.io provides plenty documentation on how to configure CrateDB
I continue to be a huge fan of CrateDB and so, if I was going to write a decent Habitat plan for CrateDB, it had to be an epic plan for CrateDB and support as much of the CrateDB config as I could.
Of course, before getting to the config, I needed to get a plan written. Given I had an official ElasticSearch plan to hand, this was never going to be too hard. Take a look…
Nothing to controversial in there, but some things to note. The CrateDB tarball contains everything it needs to run with the exception of the JRE itself. So core/jre8 is provided as a runtime dependency and most of the early steps in the plan (e.g. do_download(), do_verify()) can be kept as the default. do_build() needs to be overwritten because, in CrateDB, there is no Makefile to be run. Instead, all I needed to do, just as with the core/elasticsearch plan is install the tarball contents in the correct location and remove any cruft.
So that was the easy part; next I needed to wrestle with the CrateDB config. One of the nice things about Crate.io and CrateDB is the care taken over documentation. The config for the version of CrateDB for which I am writing this plan can be found over here.
That said, it was not quite as simple a religiously writing a Habitat template for that config documentation. There appears to be a little disparity between what is documented online and the default config shipped inside the CrateDB tarball:
- Some config in the tarball is not documented at all (e.g. “discovery.zen.ping.unicast.hosts”, a very common piece of config)
- Some config in the tarball has different syntax from the docs (e.g. “index.number_of_replicas” in the tarball, versus “number_of_replicas” in the docs).
I decided to produce a template that follows the online docs very closely. I know there are definitely some config options missing from those docs but, for now, I will leave them out of my template.
Here’s a little teaser of the resulting template:
I say “little” teaser because, as you’ll see from the CrateDB docs, this really is a small fraction of what is configurable for CrateDB. Creating all of the config templates took significantly longer than writing the plan itself.
I guess this is common.
Build It, Run It
No rocket science here:
- Enter the Habitat studio
The resulting Docker image is kinda large at ~420mb. That’s roughly twice the size of CrateDB’s official image on Docker Hub. I’m hoping this is a simple case of PEBCAK and that I’ll fix this as I learn more about Habitat.
Soon I will publish this plan for folks to play with. Before then, I need to investigate the weird discrepancies around the config. Once that is done, I will return to this topic and look into building/configuring CrateDB clusters using Habitat.