Book Image

Simplifying Service Management with Consul

By : Robert E. Jackson
Book Image

Simplifying Service Management with Consul

By: Robert E. Jackson

Overview of this book

Within the elastic and dynamic nature of cloud computing, efficient and accurate service discovery provides the cornerstone for all communications. HashiCorp Consul facilitates this service discovery efficiently and securely, independent of the operating environment. This book will help you build a solid understanding of both the concepts and applications of HashiCorp Consul. You'll begin by finding out what you can do with Consul, focusing on the conceptual views of configuration samples along with Terraform code to expedite lab environment and hands-on experimentation, which will enable you to apply Consul effectively in your everyday lives. As you advance, you'll learn how to set up your own Consul cluster and agents in a single datacenter or location and understand how Consul utilizes RAFT and GOSSIP protocols for communication. You'll also explore the practical applications of primary Consul use cases, including communication flows and configuration and code examples. With that knowledge, you'll extend Consul across datacenters to discuss the applicability of multiple regions, multiple clouds, and hybrid cloud environments. By the end of this Consul book, you will have the tools needed to create and operate your own Consul cluster and be able to facilitate your service discovery and communication.
Table of Contents (12 chapters)
1
Section 1: Consul Use Cases and Architecture
6
Section 2: Use Cases Deep Dive

State your intentions

Now that we understand how our applications will communicate over the service mesh, we need to understand how to configure and manage that communication. We may want to think that all of our services will live in harmony, and only those that should speak to each other shall do so. However, as altruistic as this idea is, it isn't very realistic. Therefore, we need a mechanism to easily define what applications can, and more importantly cannot, access one another within the Consul system. For this, we use what is called a Consul intention.

The nice thing about where we are with Consul services is that each service is defined by a human-understandable name. I would strongly recommend clear and distinct service names within any system simply to avoid ambiguity. However, that effort provides some additional comfort in that we can now specify intentions via the service name. If you've ever had to deal with any sort of IP-based firewall, you should find...