BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News HashiCorp Releases Consul 1.5.0 with Layer 7 Observability and Centralized Configuration

HashiCorp Releases Consul 1.5.0 with Layer 7 Observability and Centralized Configuration

This item in japanese

Hashicorp released version 1.5.0 of Consul, their service mesh application and key-value store. These are the first features released on their new roadmap for Consul including support for L7 observability and load balancing via Envoy, centralized configuration, and ACL authentication support for trusted third-party applications.

With this release, Consul Connect now supports L7 observability and load balancing via the Envoy integration. Connect was added to Consul in the 1.4 release and provides secure service-to-service communication, leveraging automatic TLS encryption and identify-based authorization. With Connect, as with any service mesh, all traffic in and out of a service flows through the side-car proxy with Connect acting as a control plane. This allows Connect to respond to changes in the workloads and network. The proxies form a data plane which provides a consistent source of application metrics which can be emitted to a time-series database or other form of application monitoring software. Consul Connect also allows for configuration of distributed tracing. Both configuration of metrics and distributed tracing can now be configured for layer 4 and at layer 7 HTTP and gRPC.

Version 1.5 also includes ACL enhancements including expiration times, roles, and service identify mappings. These improvements enabled services to obtain a valid ACL token using a third-party identity. According to the Consul team, "The main complexity users face when setting up is how to create and distribute a valid ACL token for a service which has the correct access to register itself with the service catalog". By introducing ACL auth methods, applications can use trusted third-parties to obtain their ACL token with the correct permission automatically. This release includes the first auth method which makes use of Kubernetes Service Accounts for services running on Kubernetes.

This release also looks to address the coupling of configuration with the deployment of the application. With the existing model, configuration is managed by the local Consul agent meaning changes in configuration require a re-deploy of the application. With this release, configuration can now be managed from a centralized location with the agents listening for configuration change in the Consul server. When the configuration is updated, all proxies referencing that configuration will automatically reload their settings without requiring a re-deploy.

Diagram illustrating updating configuration from centralized Consul server

Diagram illustrating workflow of configuration being applied form the centralized Consul server (credit: HashiCorp)

 

For example, to add centralized configuration to enable a StatsD collector for metrics you could add the following:

kind = "proxy-defaults"
name = "global"
config {
    envoy_dogstatsd_url = "udp://127.0.0.1:9125"
}

Assuming this was in a file called policy.hcl, this can be written to the Consul server using the following command: consul config write proxy.hcl. The write command also supports a -cas option (compare-and-swap) to prevent overwriting of other modifications.

There are two supported values for kind: proxy-defaults and service-defaults. Proxy-defaults allows for configuring global default across all services for Connect proxy configuration. Only one global entry is supported currently. Service defaults control the default global values for a service, such as its protocol.

The Kubernetes integrations will also be updated to support the new features outlined above. This includes the L7 observability and new ACL auth methods. These updates will be released shortly after the Consul 1.5.0 release. For a full list of changes in this area, review the changelogs for consul-k8s and consul-helm.

This release also includes filtering support across a number of Consul’s HTTP APIs. This allows for the addition of a query parameter to pass a filtering expression into the API call using the filter parameter:

curl -G <path> --data-urlencode 'filter=<filter expression>'

These filter expressions are written in plain text format and support both Boolean logic, matching operators, and parenthesization.

According to the Consul roadmap, future releases of Consul should include HTTP path-based routing and traffic shifting features. With HTTP path-based routing, Consul will be able to route traffic to different upstream services based on Path or HTTP header. This extends the current layer 4 networking support with layer 7 routing. The traffic shifting feature will allow for a percentage of traffic to be routed to specific instances of a service or an entirely different service. This allows for canary testing of new releases of software by updating only a portion of the service and directing a fraction of traffic into the updated instances.

For more details and additional improvements included in this release, please review the official announcement on the HashiCorp blog. The CHANGELOG provides the full list of changes in the release. Consul is available to download for free from the HashiCorp site.

Rate this Article

Adoption
Style

BT