Tag : consul

High Availability (HA) is a common requirement. Unfortunately it is often the case that HA considerations need to be made from the ground up while designing a service. Sometimes a component of your service might be the best tool for your business case, but the nature of its business task or a trade off made

Consul (or etcd) and Docker are fast becoming core primitives for orchestrating production systems. Docker for packaging and containerization of workloads; Consul makes it simple for services to register themselves and to discover other services via DNS or an HTTP API. For example, etcd is involved in much of the Diego rewrite of Cloud Foundry

Consul makes it simple for services to register themselves and to discover other services via a DNS or HTTP interface, provides built-in health checks, and more. It also includes a key-value store similar to Etcd or Zookeeper. I’m starting to think of a local Consul agent – either running in client or server mode –

The animated gif* demo below shows: observe a master node failure (consul health checks) promote a slave to become master configure other slaves to the new master configure the original master to become a slave (if it ever awakens/returns to the cluster) And all without touching my configuration management tool (which is BOSH in this

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

This article is a continuation of investigations into service discovery, which started 3 days earlier with The world’s quickest demonstration of consul. One side of DNS is the ability for clients to find backend services/web apps without knowing implementation details: the IP addresses of host machines. The flipside is equally important: the ability for the

Continuing to explore consul for service discovery, I added some health checks to the redis cluster from the previous post (World’s quickest demo of consul). As you can see below if a health check is critical, then the service is removed from the DNS listing. If a health check is a warning, then it continues

"What is service discovery?" and "Should I investigate consul?" are questions for another day. Today is the day for the world’s quickest demonstration* of advertising a master-slave-slave redis cluster across consul. *No effort was made to verify this claim. Step-by-step: It shows a running cluster of consul servers Sadly, there is no redis service available.