Update: instructions are even simpler thanks to consul v0.3.1+; and releases v5+ of consul-boshrelease. This post documents the old two deployment-step sequence. As of v5 there is now only one deployment required. See the project README.
Whether you’re a BOSH user already or not, you might be interested to use it to boot your stable consul cluster, to keep it up-to-date, and scale it over time.
This post continues a sequence on posts on consul, which is looking quite nice.
What is "bootstrap" to a consul cluster? From the docs on initial bootstrapping:
The first server that is deployed in a new datacenter must provide the
-bootstrapconfiguration option. …The final step is to remove the
-bootstrapflag. This is important since we don’t want the node to be able to make unilateral decisions in the case of a failure of the other two nodes.
In all forms of configuration management I think this is going to require two steps.
For BOSH, and the new consul-boshrelease, I’ve tried to get them down to two simple steps.
For an AWS EC2 cluster these two steps would be:
Step 1. 4-VM with bootstrap VM:
templates/make_manifest aws-ec2 bootstrap
bosh -n deploy
Immediately move on to…
Step 2. 3-VM cluster, removing bootstrap VM
templates/make_manifest aws-ec2 cluster
bosh deploy
The bootstrap VM will be destroyed, and the remaining VMs will become a stable bootstrap-less cluster.
If you’ve never seen BOSH deployment before, or if you can never watch enough of BOSH deploying clusters of servers, then here is the deployment against a local vagrant version of BOSH (bosh-lite):
Whilst developing services and applications that use consul, I’ve upgraded my test consul clusters a number of times and consul client agents no longer lose access to the cluster (oops).
Spread the word
