1. Service Code and Helm chart with Consul agent configuration are stored in GitHub. DevOps engineers edit the Helm chart, enabling Connect and/or setting upstream dependencies.
  2. GitHub checkin triggers an automated CI/CD build in Azure DevOps. Helm chart gets deployed using Azure CLI and/or a set of bash scripts.
  3. Kubernetes cluster is provisioned in Azure with Consul agents installed, configured for Consul Connect and service running.

When configuration changes need to be made to the service, the workflow restarts with DevOps engineers editing Helm chart in GitHub and triggering the rolling update in AKS.

Service Segmentation with Consul Connect

Now that you have both the Consul cluster and a set of services running and configured for Consul Connect, you can define security rules by specifying which services are allowed to talk to each other. Service identity is provided with TLS certificates that are generated and managed by Consul’s built-in certificate authority (CA) or other CA. This identity-based service authorization approach allows you to segment the network without relying on any networking middleware. You can accomplish this segmentation with intentions, which can be defined using the CLI, API or UI. For example, the following intention denies communication from db to web (connections will not be allowed).

$ consul intention create -deny db web
Created: db => web (deny)

Happy Consuling

In Part 2 of this article series on Consul, you learned about service mesh properties of Consul, their underlying architecture, as well as several ways to deploy and configure Consul agents on Azure. When combined with service discovery and configuration properties, all easy to setup, use, and scale, Consul provides a powerful cloud-native service mesh solution for the modern cloud.

Questions or feedback? Let us know in the comments.