HashiCorp Consul hits 1.0
© Shutterstock / Visual society
HashiCorp Consul 1.0 is here! It’s been three years since the initial release and now the tool “has hit a threshold of broad usage, feature richness, and operational maturity,” according to the official announcement.
It’s been three years since HashiCorp Consul 0.1 was released — its aim was “to address the challenges of running and maintaining a microservices architecture. Since that initial release, Consul has consistently added new functionality to make it easier to build robust service-oriented applications,” according to the blog post announcing 1.0.
This tool for service discovery and runtime configuration for distributed applications and infrastructure joins Vagrant and Packer as the third HashiCorp product to reach the 1.0 milestone.
You can download HashiCorp Consul 1.0 here.
You can also download older versions of Consul from the releases service.
What’s new in HashiCorp Consul 1.0?
- Support for HCL Config Files: Consul now supports HashiCorp’s HCL format for config files. This is easier to work with than JSON and supports comments. As part of this change, all config files will need to have either an
.jsonextension in order to specify their format. [GH-3480]
- Support for Binding to Multiple Addresses: Consul now supports binding to multiple addresses for its HTTP, HTTPS, and DNS services. You can provide a space-separated list of addresses to
addressesconfigurations, or specify a go-sockaddr template that resolves to multiple addresses. [GH-3480]
- Support for RFC1434 DNS TXT records: Consul DNS responses now contain the node meta data encoded according to RFC1434 as TXT records. [GH-3343]
- Support for Running Subproccesses Directly Without a Shell: Consul agent checks and watches now support an
argsconfiguration which is a list of arguments to run for the subprocess, which runs the subprocess directly without a shell. The old
handlerconfigurations are now deprecated (specify a shell explicitly if you require one). A
-shell=falseoption is also available on
consul watch, and
consul execto run the subprocesses associated with those without a shell. [GH-3509]
- Sentinel Integration: (Consul Enterprise) Consul’s ACL system integrates with Sentinel to enable code policies that apply to KV writes.
There are 13 breaking changes in this release, so you should read the upgrade notes for 1.0.
Check out the v1.0.0 CHANGELOG for information on the latest release, including the list of improvements and bug fixes.
Consul — Key features
Consul offers several key features:
- Service Discovery: Clients of Consul can provide a service, such as
mysql, and other clients can use Consul to discover providers of a given service. Using either DNS or HTTP, applications can easily find the services they depend upon.
- Health Checking: Consul clients can provide any number of health checks, either associated with a given service (“is the webserver returning 200 OK”), or with the local node (“is memory utilization below 90%”). This information can be used by an operator to monitor cluster health, and it is used by the service discovery components to route traffic away from unhealthy hosts.
- KV Store: Applications can make use of Consul’s hierarchical key/value store for any number of purposes, including dynamic configuration, feature flagging, coordination, leader election, and more. The simple HTTP API makes it easy to use.
- Multi Datacenter: Consul supports multiple datacenters out of the box. This means users of Consul do not have to worry about building additional layers of abstraction to grow to multiple regions.
Consul is designed to be friendly to both the DevOps community and application developers, making it perfect for modern, elastic infrastructures.
DevOps at HashiCorp
Speaking of DevOps, earlier this year we talked with Armon Dadgar, co-founder and CTO at HashiCorp about DevOps Defined, their guide for adopting DevOps to accelerate application delivery.
Here’s a sneak peek at the interview:
JAXenter: How does HashiCorp define DevOps? More importantly, how does it do DevOps?
Armon Dadgar: We think of DevOps as a process, not a collection of tools. It starts by looking at the various people and teams, primarily developers, operators, and security and figuring out how they should work together. When we look at the entire development to production lifecycle, there are seven steps. You have to write the app, test, package, provision infrastructure, deploy, monitor, and secure. If you try to remove any step, it is quickly obvious why they are all necessary. Depending on the industry there may be additional steps required for compliance or other requirements, but in general, these steps are both necessary and sufficient.
Our definition of DevOps is about organizing the process by which all seven steps are done focusing on overall throughput. Instead of a traditional waterfall, DevOps is about decoupling the teams and empowering individuals. Allowing developers to deploy and scale their services without talking to operators for example. This is where the tools come in. Vagrant allows developers to quickly set up their development environments to start or switch projects independently. Nomad allows developers to deploy their applications and manage the lifecycle and capacity independently of operators. Operators are responsible for providing the platform developers are consuming, using Terraform allows them to delegate responsibility and work in parallel managing a common infrastructure. Vault allows security teams to define policy and manage access to secret materials, while other teams can consume secrets programmatically without filing tickets against security.
We like to separate the problem into three discrete layers: infrastructure, security, and runtime. The infrastructure is provisioned by operators and provided to the rest of the organization. The security team uses the infrastructure provided to manage secrets and delegate access. Lastly, the runtime is the set of services and middleware provided to developers to allow them to deploy and manage their applications.
As you would imagine, this view of DevOps informs how we do things at HashiCorp. Internally, our platform team is responsible for providing the core services other teams need to deploy and manage their apps independently. The platform team provides Consul, Vault, and Nomad as a service to the rest of the organization and manages that infrastructure using Terraform. Application teams deploy with Nomad, monitor with Consul, and access secrets from Vault without coordinating with our platform team, which allows them to work faster.
JAXenter: What are the DevOps tools HashiCorp offers and how do they help professionals deliver better applications, faster?
Armon Dadgar: HashiCorp offers a suite of tools, each of which helps with a discreet part of the application delivery process. Vagrant helps with building and testing applications, Packer to package VMs or containers, Terraform to provision infrastructure, Nomad to deploy applications, Consul to provide service discovery and monitoring, and Vault to secure secrets and infrastructure. Each of the tools solves a specific set of problems, but they are built with a common philosophy and approach.
We talk about our design philosophy in the Tao of HashiCorp, and this uniformity makes it easier for users to expand their usage from a single tool to the entire HashiCorp suite without feeling like they are starting at ground zero. Organizations typically start by bringing in one of these tools to solve a specific problem, and then adopt more tools incrementally as they have gain comfort and solve their original problem.
Read the entire interview here.