Jorge Acetozi is a software engineer who spends almost his whole day having fun with things such as AWS, CoreOS, Kubernetes, Docker, Terraform, Ansible, Cassandra, Redis, Elasticsearch, Graylog, New Relic, Sensu, Elastic Stack, Fluentd, RabbitMQ, Kafka, Java, Spring, and much more! He loves deploying applications in production while thousands of users are online, monitoring the infrastructure, and acting quickly when monitoring tools decide to challenge his heart’s health!

  • White Facebook Icon
  • White Twitter Icon
  • github-white-icon_edited

November 27, 2017

July 2, 2016

Please reload

Books, courses and notes

Etcd Overview

July 2, 2016

 

Etcd is a distributed, consistent key-value store used for shared configuration and service discovery. It's written in Go and maintained by CoreOS team and it comes with CoreOS Linux distribution, although it's easily installed in any other Linux distribution or even in Windows environment. The project code and its full documentation can be found in GitHub.

 

It's being used by mature projects like Kubernetes and Cloud Foundry and it's surrounded by an active community.

 

Etcd handles the communication between etcd machines via the Raft consensus algorithm. It's very important that you understand the concepts behind Raft, specially when debugging issues or tuning configurations.

 

You may think of etcd as a distributed key-value store where you can write a value associated with a key and recover it by its key later. Let's see a simple example:

 

node1@etcdcluster$ etcdctl set /my_key "my value"
node2@etcdcluster$ etcdctl get /my_key my value


We've written the value "my value" from node1 and recovered it later from node2.

 

A more sophisticated example would be storing a Spring Boot application configuration to production environment from a Jenkins job that builds the artifact and recovering it later on from a Docker container startup script that does something like:

 

etcdctl get /myapp/production/config > /opt/myapp/config/application.yml

java -jar myapp.jar --spring.config.location=/opt/myapp/config/application.yml

 

That would let you build only one artifact without any configuration file inside and reuse it in as many environments as you'd like, making it easier to build a pipeline in which you promote your artifact from dev, QA, staging, production environments by only changing its configuration file that is now outside your application and easily recoverable in etcd. This would be a practical example of "shared configuration" etcd attribute.

 

Besides that, etcd has a nice, easy to use, out-of-the-box feature that allows you to watch keys and take an action based on changes, like reconfigure you app endpoints for an external web service, change log levels dynamically and so on. Really nice, isn't it?

 

Before you build your own etcd cluster in next tutorial, why don't you play a little with this nice 5 nodes etcd cluster online simulator at http://play.etcd.io? You can write, read, kill nodes and see it in a nice, graphical way.

 

 

 

In the next tutorial we’ll setup an etcd cluster into Amazon EC2.

 

Share on Facebook
Share on Twitter
Please reload