Introduction
Why use HashiCorp Validated Designs?
HashiCorp Validated Designs (HVD) provide practitioners with opinionated guidance for achieving production-grade deployments of HashiCorp products. These designs are purpose-built for delivering foundational use cases, with a baseline level of architectural and operational maturity. They draw on the field experiences of Solutions Engineers and Solutions Architects working with customers across a wide range of environments and organizational requirements.
Each guide provides access to an opinionated reference architecture, including key design decisions and the rationale behind them. Where applicable, guides identify modular design components that you can adjust to align with organizational or regulatory requirements without compromising the overall integrity of the implementation. For many deployments we include Terraform modules to automate large portions of infrastructure provisioning and software installation.
This Administration Guide is for platform and operations teams responsible for running Consul Enterprise after installation. It assumes the Consul Installation Guide has been completed and the system is running. For application-team service discovery and service mesh workflows, see the Consul User Guide.
Objectives
This guide covers operating Consul Enterprise as a platform service. Consul lets you register services in a centralized registry to discover, monitor, and track their health status. It also enables secure network connectivity between services across multiple cloud environments, runtimes, and platforms.
Deploying Consul will help your organization provide the following solutions:
- Identity-based networking provides a dynamic way of referencing services by their identity. This lets you quickly respond to scaling events without updating IP addresses for new instances inside your firewalls and load balancers.
- A multi-platform service discovery solution provides a better way for applications to discover each other across different deployment platforms.
By leveraging these solutions, your organization can:
- Reduce the time required to scale infrastructure by providing dynamic capabilities to discover services and get the health status to communicate securely with dynamically scaled infrastructure.
- Reduce the time required to release new features to consumers Consul allows development to test new features and route traffic to old and new features based on traffic resolving and splitting rules.
Prerequisites
When using Consul Enterprise (Self-managed / Self-Hosted version of HCP Consul), this guide assumes that you have a basic understanding of Consul and have reviewed or implemented the Consul Enterprise Installation Guide.
Please note: In this document, Consul Enterprise refers to both the self-managed and the HashiCorp-managed (HCP Consul) versions of Consul.
Architecture assumptions
Many of the recommendations and best practices outlined in this document are platform-agnostic and include information that could apply to any platform. When we need to highlight platform-specific details, this document focuses on specifics for running Consul Enterprise server agents deployed on Amazon EC2 instances with client workloads running in either Amazon EC2 instances or Amazon’s managed Elastic Kubernetes Service within a single Amazon Region.
The following is a sample high-level architecture diagram that shows the Consul Enterprise deployment this Administration Guide recommends. The Consul Enterprise server agents are deployed by the Terraform module from the Installation Guide. Client workloads running in Amazon EKS are segregated into Consul Enterprise Admin Partitions corresponding to each Kubernetes cluster.
Language and definitions
This documentation intentionally uses technology-agnostic terminology. However, some terms do not translate perfectly between the cloud providers. The following are the definitions of terms this document uses.
| Cloud Provider Terms | Definition |
|---|---|
| Region | A physical location around the world with multiple clusters of data centers. |
| Availability zone (AZ) | One or more discrete data centers within a region. Each AZ has redundant power, networking, and connectivity. |
| Public subnet | A network accessible by application users. |
| Private subnet | A network used by applications, but inaccessible by application users. |
| Secrets Manager (SM) | System that can store secrets for bootstrapping. |
| Virtual private cloud (VPC) | Software defined cloud networking |
| Consul Term | Definition |
|---|---|
| Consul Enterprise(opens in new tab) | Self-managed / Self-Hosted version of HCP Consul |
| Datacenter(opens in new tab) | A Consul datacenter is the smallest unit of Consul infrastructure that can perform basic Consul operations. This may coincide with cloud regions' boundaries. |
| Partition or Admin Partition(opens in new tab) | A logical boundary within a single Consul datacenter that delineates unique network boundaries or teams. |
| Peering or Cluster Peering(opens in new tab) | A Consul datacenter or admin partition that has an established relationship with another datacenter or admin partition |
Sample project plan
The following table itemizes this guide’s artifacts and its expected timeline to help project managers create their project plans. You can exclude some of these activities. Reach out to your HashiCorp account team for additional guidance. They can help you customize this plan to suit your specific and unique requirements.
HashiCorp Validated Design (HVD) deliverables
| Deliverable | Brief Description | Approx. time to complete |
|---|---|---|
| People & process | ||
| Define user data, roles, and authentication | Define how users interact with the self-service platform and configure authentication methods, roles, and policies to be applied. Create policies as code and document team organization | 1-2 weeks |
| Identify self-service workflow | Identify all personas and teams that will be part of the platform's consumers and producers. Document the workflow and specify inputs and outputs required to integrate with all development processes | 2-3 weeks |
| Initial configuration | ||
| Configure Consul as code | Automate the initial configuration of your security policies, admin partitions and namespaces, and consumer workflows. | 2 weeks |
| Configure DNS forwarding | Setup DNS forwarding for local agents and remote systems to allow for consumer discovery workflows. | 1-2 weeks |
| Configure platform monitoring | Configure exporting of telemetry and logging data and integrate with your monitoring platform. | 2 weeks |
| Setup backup, restore, and upgrades | Familiarize the team responsible for operating Consul Enterprise with the different operational procedures required to ensure the ability to adopt new features and provide resilience in the event of unexpected issues. Test and validate the procedures. | 2 weeks |
| Security operational procedures | Validate operational rotation procedures and ensure they align with your organizational security requirements. | 1-2 weeks |
| Multiplatform service registration and health checking | ||
| Build health checking workflow | Determine appropriate health checks for your applications to ensure you only direct discovery traffic to healthy instances. | 2-6 weeks |
| Build service registration workflow | Targeting the first pilot consumers, build a service registration workflow that includes your health check definition | 2-6 weeks |
| Service catalog discovery | ||
| Build Consumer Workflow | Identify all of the consumers for the initially targeted applications and ensure you can perform a smooth migration from the current way they are addressing services to leveraging the Consul Service Catalog. | 2-6 weeks |