mirror of https://github.com/status-im/consul.git
Merge pull request #14643 from hashicorp/docs/search-metadata-headers
docs: Search Description Refresh
This commit is contained in:
commit
2398fbead5
|
@ -1,12 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Configuration Entries
|
page_title: How to Use Configuration Entries
|
||||||
description: >-
|
description: >-
|
||||||
Consul allows storing configuration entries centrally to be used as defaults
|
Configuration entries define the behavior of Consul service mesh components. Learn how to use the `consul config` command to create, manage, and delete configuration entries.
|
||||||
for configuring other aspects of Consul.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Configuration Entries
|
# How to Use Configuration Entries
|
||||||
|
|
||||||
Configuration entries can be created to provide cluster-wide defaults for
|
Configuration entries can be created to provide cluster-wide defaults for
|
||||||
various aspects of Consul.
|
various aspects of Consul.
|
||||||
|
|
|
@ -1,11 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Consul Agent CLI Reference
|
page_title: Agents: CLI Reference
|
||||||
description: >-
|
description: >-
|
||||||
This topic describes the supported options for configuring Consul agents on the command line.
|
Add flags to the `consul agent` command to configure agent properties and actions from the CLI. Learn about configurable options and how to format them with examples.
|
||||||
---
|
---
|
||||||
|
|
||||||
# Command-line Options ((#commandline_options))
|
# Agents Command-line Reference ((#commandline_options))
|
||||||
|
|
||||||
-> **Note:** Some CLI arguments may be different from HCL keys. See [Configuration Key Reference](/docs/agent/config/config-files#config_key_reference) for equivalent HCL Keys.
|
-> **Note:** Some CLI arguments may be different from HCL keys. See [Configuration Key Reference](/docs/agent/config/config-files#config_key_reference) for equivalent HCL Keys.
|
||||||
|
|
||||||
|
|
|
@ -1,11 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Consul Agent Configuration Reference
|
page_title: Agents: Configuration File Reference
|
||||||
description: >-
|
description: >-
|
||||||
This topic describes the supported parameters for configuring Consul agents in HCL and JSON configuration files.
|
Use agent configuration files to assign attributes to agents and configure multiple agents at once. Learn about agent configuration file parameters and formatting with this reference page and sample code.
|
||||||
---
|
---
|
||||||
|
|
||||||
# Configuration Files ((#configuration_files))
|
# Agents Configuration File Reference ((#configuration_files))
|
||||||
|
|
||||||
You can create one or more files to configure the Consul agent on startup. We recommend
|
You can create one or more files to configure the Consul agent on startup. We recommend
|
||||||
grouping similar configurations into separate files, such as ACL parameters, to make it
|
grouping similar configurations into separate files, such as ACL parameters, to make it
|
||||||
|
|
|
@ -1,13 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Configuration
|
page_title: Agents: Configuration Explained
|
||||||
description: >-
|
description: >-
|
||||||
The agent has various configuration options that can be specified via the
|
Agent configuration is the process of defining server and client agent properties with CLI flags and configuration files. Learn what properties can be configured on reload and how Consul sets precedence for configuration settings.
|
||||||
command-line or via configuration files. All of the configuration options are
|
|
||||||
completely optional. Defaults are specified with their descriptions.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Configuration
|
# Agent Configuration
|
||||||
|
|
||||||
The agent has various configuration options that can be specified via
|
The agent has various configuration options that can be specified via
|
||||||
the command-line or via configuration files. All of the configuration
|
the command-line or via configuration files. All of the configuration
|
||||||
|
|
|
@ -1,13 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Agent
|
page_title: Agents Overview
|
||||||
description: >-
|
description: >-
|
||||||
The Consul agent is the core process of Consul. The agent maintains membership
|
Agents maintain register services, respond to queries, maintain datacenter membership information, and make most of Consul’s functions possible. Learn how to start, stop, and configure agents, as well as their requirements and lifecycle.
|
||||||
information, registers services, runs checks, responds to queries, and more.
|
|
||||||
The agent must run on every node that is part of a Consul cluster.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Consul Agent
|
# Agents Overview
|
||||||
|
|
||||||
This topic provides an overview of the Consul agent, which is the core process of Consul.
|
This topic provides an overview of the Consul agent, which is the core process of Consul.
|
||||||
The agent maintains membership information, registers services, runs checks, responds to queries, and more.
|
The agent maintains membership information, registers services, runs checks, responds to queries, and more.
|
||||||
|
|
|
@ -1,11 +1,8 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: RPC
|
page_title: Legacy RPC Protocol
|
||||||
description: >-
|
description: >-
|
||||||
The Consul agent provides a complete RPC mechanism that can be used to control
|
Consul agents originally could be controlled through the RPC protocol. This feature was deprecated in version 0.8 in favor of the HTTP API. Learn about agent RPC interactions and how they worked.
|
||||||
the agent programmatically. This RPC mechanism is the same one used by the CLI
|
|
||||||
but can be used by other applications to easily leverage the power of Consul
|
|
||||||
without directly embedding.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# RPC Protocol
|
# RPC Protocol
|
||||||
|
|
|
@ -1,13 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Sentinel in Consul
|
page_title: Sentinel ACL Policies (Enterprise)
|
||||||
description: >-
|
description: >-
|
||||||
Consul Enterprise uses Sentinel to augment the built-in ACL system to provide
|
Sentinel allows you to include conditional logic in access control policies. Learn how Consul can use Sentinel policies to extend the ACL system's capabilities for controlling key-value (KV) write access.
|
||||||
advanced policy enforcement. Sentinel policies can currently execute on KV
|
|
||||||
modify and service registration.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Sentinel Overview
|
# Sentinel for KV ACL Policy Enforcement
|
||||||
|
|
||||||
<EnterpriseAlert />
|
<EnterpriseAlert />
|
||||||
|
|
||||||
|
|
|
@ -1,13 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Telemetry
|
page_title: Agents: Enable Metrics
|
||||||
description: >-
|
description: >-
|
||||||
The Consul agent collects various runtime metrics about the performance of
|
Configure agent telemetry to collect operations metrics you can use to debug and observe Consul behavior and performance. Learn about configuration options, the metrics you can collect, and why they're important.
|
||||||
different libraries and subsystems. These metrics are aggregated on a ten
|
|
||||||
second interval and are retained for one minute.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Telemetry
|
# Agent Telemetry
|
||||||
|
|
||||||
The Consul agent collects various runtime metrics about the performance of
|
The Consul agent collects various runtime metrics about the performance of
|
||||||
different libraries and subsystems. These metrics are aggregated on a ten
|
different libraries and subsystems. These metrics are aggregated on a ten
|
||||||
|
|
|
@ -1,11 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Anti-Entropy
|
page_title: Anti-Entropy Enforcement
|
||||||
description: |
|
description: >-
|
||||||
This section details the process and use of anti-entropy in Consul.
|
Anti-entropy keeps distributed systems consistent. Learn how Consul uses an anti-entropy mechanism to periodically sync agent states with the service catalog to prevent the catalog from becoming stale.
|
||||||
---
|
---
|
||||||
|
|
||||||
# Anti-Entropy
|
# Anti-Entropy Enforcement
|
||||||
|
|
||||||
Consul uses an advanced method of maintaining service and health information.
|
Consul uses an advanced method of maintaining service and health information.
|
||||||
This page details how services and checks are registered, how the catalog is
|
This page details how services and checks are registered, how the catalog is
|
||||||
|
|
|
@ -1,10 +1,8 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Consensus Protocol
|
page_title: Consensus Protocol | Raft
|
||||||
description: >-
|
description: >-
|
||||||
Consul uses a consensus protocol to provide Consistency as defined by CAP. The
|
Consul ensures a consistent state using the Raft protocol. A quorum, or a majority of server agents with one leader, agree to state changes before committing to the state log. Learn how Raft works in Consul to ensure state consistency and how that state can be read with different consistency modes to balance read latency and consistency.
|
||||||
consensus protocol is based on Raft: In search of an Understandable Consensus
|
|
||||||
Algorithm. For a visual explanation of Raft, see The Secret Lives of Data.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Consensus Protocol
|
# Consensus Protocol
|
||||||
|
|
|
@ -1,7 +1,8 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Network Coordinates
|
page_title: Network Coordinates
|
||||||
description: A Decentralized Network Coordinate System, with several improvements based on several follow-on papers.
|
description: >-
|
||||||
|
Network coordinates are node locations in network tomography used to estimate round trip time (RTT). Learn how network coordinates manifest in Consul, how it calculates RTT, and how to work with coordinates to sort catalog information by nearness to a given node.
|
||||||
---
|
---
|
||||||
|
|
||||||
# Network Coordinates
|
# Network Coordinates
|
||||||
|
|
|
@ -1,12 +1,8 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Gossip Protocol
|
page_title: Gossip Protocol | Serf
|
||||||
description: >-
|
description: >-
|
||||||
Consul uses a gossip protocol to manage membership and broadcast messages to
|
Consul agents manage membership in datacenters and WAN federations using the Serf protocol. Learn about the differences between LAN and WAN gossip pools and how `serfHealth` affects health checks.
|
||||||
the cluster. All of this is provided through the use of the Serf library. The
|
|
||||||
gossip protocol used by Serf is based on SWIM: Scalable Weakly-consistent
|
|
||||||
Infection-style Process Group Membership Protocol, with a few minor
|
|
||||||
adaptations.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Gossip Protocol
|
# Gossip Protocol
|
||||||
|
|
|
@ -1,16 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Improving Consul Resilience
|
page_title: Fault Tolerance in Consul
|
||||||
description: >-
|
description: >-
|
||||||
Fault tolerance is the ability of a system to continue operating without interruption
|
Fault tolerance is a system's ability to operate without interruption despite component failure. Learn how a set of Consul servers provide fault tolerance through use of a quorum, and how to further improve control plane resilience through use of infrastructure zones and Enterprise redundancy zones.
|
||||||
despite the failure of one or more components. Consul's resilience, or fault tolerance,
|
|
||||||
is determined by the configuring of its voting server agents. Recommended strategies for
|
|
||||||
increasing Consul's fault tolerance include using 3 or 5 voting server agents, spreading
|
|
||||||
server agents across infrastructure availability zones, and using Consul Enterprise
|
|
||||||
redundancy zones to enable backup voting servers to automatically replace lost voters.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Improving Consul Resilience
|
# Fault Tolerance
|
||||||
|
|
||||||
Fault tolerance is the ability of a system to continue operating without interruption
|
Fault tolerance is the ability of a system to continue operating without interruption
|
||||||
despite the failure of one or more components.
|
despite the failure of one or more components.
|
||||||
|
|
|
@ -2,12 +2,10 @@
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Consul Architecture
|
page_title: Consul Architecture
|
||||||
description: >-
|
description: >-
|
||||||
Consul is a complex system that has many different moving parts. To help users
|
Consul datacenters consist of clusters of server agents (control plane) and client agents deployed alongside service instances (dataplane). Learn how these components and their different communication methods make Consul possible.
|
||||||
and developers of Consul form a mental model of how it works, this page
|
|
||||||
documents the system architecture.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Consul Architecture
|
# Consul Internals Overview
|
||||||
|
|
||||||
Consul is a complex system that has many different moving parts. To help
|
Consul is a complex system that has many different moving parts. To help
|
||||||
users and developers of Consul form a mental model of how it works, this
|
users and developers of Consul form a mental model of how it works, this
|
||||||
|
|
|
@ -1,14 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Jepsen Testing
|
page_title: Consistency Verification | Jepsen Testing Results
|
||||||
description: >-
|
description: >-
|
||||||
Jepsen is a tool, written by Kyle Kingsbury, designed to test the partition
|
Jepsen is a tool to measure the reliability and consistency of distributed systems across network partitions. Learn about the Jepsen testing performed on Consul to ensure it gracefully recovers from partitions and maintains consistent state.
|
||||||
tolerance of distributed systems. It creates network partitions while fuzzing
|
|
||||||
the system with random operations. The results are analyzed to see if the
|
|
||||||
system violates any of the consistency properties it claims to have.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Jepsen Testing
|
# Jepsen Testing Results
|
||||||
|
|
||||||
[Jepsen](http://aphyr.com/posts/281-call-me-maybe-carly-rae-jepsen-and-the-perils-of-network-partitions)
|
[Jepsen](http://aphyr.com/posts/281-call-me-maybe-carly-rae-jepsen-and-the-perils-of-network-partitions)
|
||||||
is a tool, written by Kyle Kingsbury, designed to test the partition
|
is a tool, written by Kyle Kingsbury, designed to test the partition
|
||||||
|
|
|
@ -1,9 +1,8 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Service Discovery
|
page_title: Service Discovery Explained
|
||||||
description: >-
|
description: >-
|
||||||
Learn what service discovery is, its benefits, and how it works.
|
Service discovery dynamically tracks and monitors service instances on your network and makes them discoverable through DNS queries. Learn about the benefits of service discovery and how it works.
|
||||||
Service mesh can solve many of the modern challenges that exist in multi-platform and multi-cloud application architectures, ranging from security to application resiliency.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# What is service discovery?
|
# What is service discovery?
|
||||||
|
|
|
@ -1,9 +1,8 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Service Mesh
|
page_title: Service Mesh Explained
|
||||||
description: >-
|
description: >-
|
||||||
Learn what a service mesh is, its benefits, and how it works.
|
Service mesh is a dedicated network layer for secure, resilient, observable microservice communication. Learn about using Consul's service mesh to solve service networking challenges in application architectures and manage complexity in multi-cloud, hybrid cloud, and multi-platform environments.
|
||||||
A service mesh can solve many of the modern challenges that exist in multi-platform and multi-cloud application architectures, ranging from security to application resiliency.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# What is a service mesh?
|
# What is a service mesh?
|
||||||
|
|
|
@ -1,12 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Connect - Certificate Management
|
page_title: Service Mesh Certificate Authority: AWS Certificate Manager
|
||||||
description: >-
|
description: >-
|
||||||
Consul can be used with AWS Certificate Manager Private CA to manage and sign
|
You can use the AWS Certificate Manager Private Certificate Authority as the Consul service mesh's certificate authority to secure your service mesh. Learn how to configure the AWS ACM Private CA, its limitations in Consul, and cost planning considerations.
|
||||||
certificates.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# AWS Certificate Manager Private CA as a Connect CA
|
# AWS Certificate Manager as a Service Mesh Certificate Authority
|
||||||
|
|
||||||
Consul can be used with [AWS Certificate Manager (ACM) Private Certificate
|
Consul can be used with [AWS Certificate Manager (ACM) Private Certificate
|
||||||
Authority
|
Authority
|
||||||
|
|
|
@ -1,14 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Connect - Certificate Management
|
page_title: Certificate Authority: Built-in Service Mesh CA
|
||||||
description: >-
|
description: >-
|
||||||
Consul ships with a built-in CA system so that Connect can be easily enabled
|
Consul has a built-in service mesh certificate authority that can be used to secure your service mesh without needing a separate CA system. Learn how to configure the built-in service mesh CA as a root CA or an intermediate CA connected to an existing PKI system.
|
||||||
out of the box. The built-in CA generates and stores the root certificate and
|
|
||||||
private key on Consul servers. It can also be configured with a custom
|
|
||||||
certificate and private key if needed.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Built-In CA
|
# Built-In Certificate Authority for Service Mesh
|
||||||
|
|
||||||
Consul ships with a built-in CA system so that Connect can be
|
Consul ships with a built-in CA system so that Connect can be
|
||||||
easily enabled out of the box. The built-in CA generates and stores the
|
easily enabled out of the box. The built-in CA generates and stores the
|
||||||
|
|
|
@ -1,10 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Connect - Certificate Management
|
page_title: Service Mesh Certificate Authority: Overview
|
||||||
description: An overview of the Connect Certificate Authority mechanisms.
|
description: >-
|
||||||
|
Consul uses a certificate authority (CA) to generate, use, manage, sign, and store certificates for your service mesh. Learn about certificate management, including configuration, root cert rotation, cross-signing, and regenerating the CA.
|
||||||
---
|
---
|
||||||
|
|
||||||
# Connect Certificate Management
|
# Service Mesh Certificate Authority Overview
|
||||||
|
|
||||||
Certificate management in Connect is done centrally through the Consul
|
Certificate management in Connect is done centrally through the Consul
|
||||||
servers using the configured CA (Certificate Authority) provider. A CA provider
|
servers using the configured CA (Certificate Authority) provider. A CA provider
|
||||||
|
|
|
@ -1,12 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Connect - Certificate Management
|
page_title: Service Mesh Certificate Authority: Vault
|
||||||
description: >-
|
description: >-
|
||||||
Consul can be used with Vault to manage and sign certificates. The Vault CA
|
You can use a Vault PKI secrets engine as the Consul service mesh's certificate authority to secure your service mesh. Learn how to configure the Vault CA as a root CA or an intermediate CA connected to an existing PKI system, and how to manage PKI paths with either Vault or Consul.
|
||||||
provider uses the Vault PKI secrets engine to generate and sign certificates.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Vault as a Connect CA
|
# Vault as a Service Mesh Certificate Authority
|
||||||
|
|
||||||
Consul can be used with [Vault](https://www.vaultproject.io) to
|
Consul can be used with [Vault](https://www.vaultproject.io) to
|
||||||
manage and sign certificates.
|
manage and sign certificates.
|
||||||
|
|
|
@ -1,11 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Create and Manage Peering Connections
|
page_title: Cluster Peering: Create and Manage Connections
|
||||||
description: >-
|
description: >-
|
||||||
This page describes how to use the Consul CLI to create, manage, and delete peering connections for cluster peering.
|
Generate a peering token to establish communication, export services, and authorize requests for cluster peering connections. Learn how to create, list, read, check, and delete peering connections.
|
||||||
---
|
---
|
||||||
|
|
||||||
# Create and Manage Peering Connections
|
# Create and Manage Cluster Peering Connections
|
||||||
|
|
||||||
~> **Cluster peering is currently in beta:** Functionality associated with cluster peering is subject to change. You should never use the beta release in secure environments or production scenarios. Features in beta may have performance issues, scaling issues, and limited support.<br /><br />Cluster peering is not currently available in the HCP Consul offering.
|
~> **Cluster peering is currently in beta:** Functionality associated with cluster peering is subject to change. You should never use the beta release in secure environments or production scenarios. Features in beta may have performance issues, scaling issues, and limited support.<br /><br />Cluster peering is not currently available in the HCP Consul offering.
|
||||||
|
|
||||||
|
|
|
@ -1,8 +1,8 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: What is Cluster Peering?
|
page_title: Service Mesh: What is Cluster Peering?
|
||||||
description: >-
|
description: >-
|
||||||
This page details the cluster peering process for connecting Consul clusters across datacenters, including differences between cluster peering and the similar concept of WAN federation.
|
Cluster peering establishes communication between independent clusters in Consul, allowing services to interact across datacenters. Learn about the cluster peering process, differences with WAN federation for multi-datacenter deployments, and technical constraints.
|
||||||
---
|
---
|
||||||
|
|
||||||
# What is Cluster Peering?
|
# What is Cluster Peering?
|
||||||
|
|
|
@ -2,7 +2,7 @@
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Cluster Peering on Kubernetes
|
page_title: Cluster Peering on Kubernetes
|
||||||
description: >-
|
description: >-
|
||||||
This page describes how to create peering connections, deploy services, export cluster services, and end peering connections for Consul cluster peering using Kubernetes (K8s).
|
If you use Consul on Kubernetes, learn how to enable cluster peering, create peering CRDs, and then manage peering connections in consul-k8s.
|
||||||
---
|
---
|
||||||
|
|
||||||
# Cluster Peering on Kubernetes
|
# Cluster Peering on Kubernetes
|
||||||
|
|
|
@ -1,12 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: 'Configuration Entry Kind: Exported Services'
|
page_title: Exported Services: Configuration Entry Reference
|
||||||
description: >-
|
description: >-
|
||||||
The exported-services configuration entry enables you to export services from a single file.
|
An exported services configuration entry defines the availability of a cluster's services to cluster peers and local admin partitions. Learn about `"exported-services"` config entry parameters and exporting services to other datacenters.
|
||||||
Settings in this configuration entry can apply to services in any namespace of the specified partition. Write access to the mesh resource is required.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Exported Services
|
# Exported Services Configuration Entry
|
||||||
|
|
||||||
This topic describes the `exported-services` configuration entry type. The `exported-services` configuration entry enables Consul to export service instances to other clusters from a single file and connect services across clusters. For additional information, refer to [Cluster Peering](/docs/connect/cluster-peering) and [Admin Partitions](/docs/enterprise/admin-partitions).
|
This topic describes the `exported-services` configuration entry type. The `exported-services` configuration entry enables Consul to export service instances to other clusters from a single file and connect services across clusters. For additional information, refer to [Cluster Peering](/docs/connect/cluster-peering) and [Admin Partitions](/docs/enterprise/admin-partitions).
|
||||||
|
|
||||||
|
|
|
@ -1,12 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Configuration Entry Definitions
|
page_title: Configuration Entry Overview
|
||||||
description: >-
|
description: >-
|
||||||
Consul allows storing configuration entries centrally to be used as defaults
|
Configuration entries define service mesh behaviors in order to secure and manage traffic. Learn about Consul’s different config entry kinds and get links to configuration reference pages.
|
||||||
for configuring other aspects of Consul.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Configuration Entries
|
# Configuration Entry Overview
|
||||||
|
|
||||||
Configuration entries can be used to configure the behavior of Consul Connect.
|
Configuration entries can be used to configure the behavior of Consul Connect.
|
||||||
|
|
||||||
|
|
|
@ -1,12 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: 'Configuration Entry Kind: Ingress Gateway'
|
page_title: Ingress Gateway: Configuration Entry Reference
|
||||||
description: >-
|
description: >-
|
||||||
The `ingress-gateway` config entry kind allows for configuring Ingress gateways
|
The ingress gateway configuration entry kind defines behavior to secure incoming communication between the service mesh and external sources. Use the reference guide to learn about `"ingress-gateway"` config entry parameters and exposing TCP and HTTP listeners.
|
||||||
with listeners that expose a set of services outside the Consul service mesh.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Ingress Gateway
|
# Ingress Gateway Configuration Entry
|
||||||
|
|
||||||
This topic provides reference information for the `ingress-gateway` configuration entry.
|
This topic provides reference information for the `ingress-gateway` configuration entry.
|
||||||
|
|
||||||
|
|
|
@ -1,14 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: 'Configuration Entry Kind: Mesh'
|
page_title: Mesh: Configuration Entry Reference
|
||||||
description: >-
|
description: >-
|
||||||
The mesh config entry kind allows for globally defining default
|
The mesh configuration entry kind defines global default settings like TLS version requirements for proxies inside the service mesh. Use the reference guide to learn about `""mesh""` config entry parameters and how to control communication with services outside of the mesh.
|
||||||
configuration across all services mesh proxies.
|
|
||||||
Settings in this config entry apply across all namespaces and federated datacenters.
|
|
||||||
Currently, only one mesh entry is supported.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Mesh
|
# Mesh Configuration Entry
|
||||||
|
|
||||||
-> **v1.10.0+:** This configuration entry is supported in Consul versions 1.10.0+.
|
-> **v1.10.0+:** This configuration entry is supported in Consul versions 1.10.0+.
|
||||||
|
|
||||||
|
|
|
@ -1,14 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: 'Configuration Entry Kind: Proxy Defaults'
|
page_title: Proxy Defaults: Configuration Entry Reference
|
||||||
description: >-
|
description: >-
|
||||||
The proxy-defaults config entry kind allows for configuring global config
|
The proxy defaults configuration entry kind defines default behaviors for sidecar proxies in the service mesh. Use the reference guide to learn about `""proxy-defaults""` config entry parameters and how to expose HTTP paths through Envoy.
|
||||||
defaults across all services for Connect proxy configuration. Currently, only
|
|
||||||
one global entry is supported.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Proxy Defaults
|
# Proxy Defaults Configuration Entry
|
||||||
|
|
||||||
|
|
||||||
The `proxy-defaults` configuration entry (`ProxyDefaults` on Kubernetes) allows you
|
The `proxy-defaults` configuration entry (`ProxyDefaults` on Kubernetes) allows you
|
||||||
to configure global defaults across all services for Connect proxy
|
to configure global defaults across all services for Connect proxy
|
||||||
|
|
|
@ -1,12 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: 'Configuration Entry Kind: Service Defaults'
|
page_title: Service Defaults: Configuration Entry Reference
|
||||||
description: >-
|
description: >-
|
||||||
The service-defaults config entry kind controls default global values for a
|
The service defaults configuration entry kind defines sets of default configurations that apply to all services in the mesh. Use the examples learn how to define a default protocol, default upstream configuration, and default terminating gateway.
|
||||||
service, such as its protocol.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Service Defaults
|
# Service Defaults Configuration Entry
|
||||||
|
|
||||||
-> **v1.8.4+:** On Kubernetes, the `ServiceDefaults` custom resource is supported in Consul versions 1.8.4+.<br />
|
-> **v1.8.4+:** On Kubernetes, the `ServiceDefaults` custom resource is supported in Consul versions 1.8.4+.<br />
|
||||||
**v1.5.0+:** On other platforms, this config entry is supported in Consul versions 1.5.0+.
|
**v1.5.0+:** On other platforms, this config entry is supported in Consul versions 1.5.0+.
|
||||||
|
|
|
@ -1,13 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: 'Configuration Entry Kind: Service Intentions'
|
page_title: Service Intentions: Configuration Entry Reference
|
||||||
description: >-
|
description: >-
|
||||||
The service-intentions config entry kind controls Connect traffic
|
The service intentions configuration entry kind defines the communication permissions between service types. Use the reference guide to learn about `""service-intentions""` config entry parameters and how to authorize L4 and L7 communication int he service mesh with intentions.
|
||||||
authorization for both networking layer 4 (e.g. TCP) and networking layer 7
|
|
||||||
(e.g. HTTP).
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Service Intentions ((#service-intentions))
|
# Service Intentions Configuration Entry ((#service-intentions))
|
||||||
|
|
||||||
-> **1.9.0+:** This config entry is available in Consul versions 1.9.0 and newer.
|
-> **1.9.0+:** This config entry is available in Consul versions 1.9.0 and newer.
|
||||||
|
|
||||||
|
|
|
@ -1,12 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: 'Configuration Entry Kind: Service Resolver'
|
page_title: Service Resolver: Configuration Entry Reference
|
||||||
description: >-
|
description: >-
|
||||||
The `service-resolver` config entry kind controls which service instances
|
The service resolver configuration entry kind defines subsets of service instances that satisfy upstream discovery requests. Use the reference guide to learn about `""service-resolver""` config entry parameters and how filtering by service subsets helps route traffic based on properties like version number.
|
||||||
should satisfy Connect upstream discovery requests for a given service name.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Service Resolver
|
# Service Resolver Configuration Entry
|
||||||
|
|
||||||
-> **v1.8.4+:** On Kubernetes, the `ServiceResolver` custom resource is supported in Consul versions 1.8.4+.<br />
|
-> **v1.8.4+:** On Kubernetes, the `ServiceResolver` custom resource is supported in Consul versions 1.8.4+.<br />
|
||||||
**v1.6.0+:** On other platforms, this config entry is supported in Consul versions 1.6.0+.
|
**v1.6.0+:** On other platforms, this config entry is supported in Consul versions 1.6.0+.
|
||||||
|
|
|
@ -1,12 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: 'Configuration Entry Kind: Service Router'
|
page_title: Service Router: Configuration Entry Reference
|
||||||
description: >-
|
description: >-
|
||||||
The service-router config entry kind controls Connect traffic routing and
|
The service router configuration entry kind defines where the service mesh routes requests based on L7 network information such as header or path. Use the reference guide to learn about `""service-router""` config entry parameters and how behaviors like request timeouts, retry behavior, header modification, and path rewriting can be applied to a request based on its header or path information.
|
||||||
manipulation at networking layer 7 (e.g. HTTP).
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Service Router
|
# Service Router Configuration Entry
|
||||||
|
|
||||||
The `service-router` config entry kind (`ServiceRouter` on Kubernetes) controls Connect traffic routing and
|
The `service-router` config entry kind (`ServiceRouter` on Kubernetes) controls Connect traffic routing and
|
||||||
manipulation at networking layer 7 (e.g. HTTP).
|
manipulation at networking layer 7 (e.g. HTTP).
|
||||||
|
|
|
@ -1,14 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: 'Configuration Entry Kind: Service Splitter'
|
page_title: Service Splitter: Configuration Entry Reference
|
||||||
description: >-
|
description: >-
|
||||||
The service-splitter config entry kind controls how to split incoming Connect
|
The service splitter configuration entry kind defines how to divide service mesh traffic between service instances. Use the reference guide to learn about `""service-splitter""` config entry parameters and how it can be used for traffic management behaviors like canary rollouts, blue green deployment, and load balancing across environments.
|
||||||
requests across different subsets of a single service (like during staged
|
|
||||||
canary rollouts), or perhaps across different services (like during a v2
|
|
||||||
rewrite or other type of codebase migration).
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Service Splitter
|
# Service Splitter Configuration Entry
|
||||||
|
|
||||||
-> **v1.8.4+:** On Kubernetes, the `ServiceSplitter` custom resource is supported in Consul versions 1.8.4+.<br />
|
-> **v1.8.4+:** On Kubernetes, the `ServiceSplitter` custom resource is supported in Consul versions 1.8.4+.<br />
|
||||||
**v1.6.0+:** On other platforms, this config entry is supported in Consul versions 1.6.0+.
|
**v1.6.0+:** On other platforms, this config entry is supported in Consul versions 1.6.0+.
|
||||||
|
|
|
@ -1,12 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: 'Configuration Entry Kind: Terminating Gateway'
|
page_title: Terminating Gateway: Configuration Entry Reference
|
||||||
description: >-
|
description: >-
|
||||||
The `terminating-gateway` config entry kind allows for configuring terminating gateways
|
The terminating gateway configuration entry kind defines behavior to secure outgoing communication between the service mesh and non-mesh services. Use the reference guide to learn about `""terminating-gateway""` config entry parameters and connecting from your service mesh to external or non-mesh services registered with Consul.
|
||||||
to proxy traffic from services in the Consul service mesh to services outside the mesh.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Terminating Gateway
|
# Terminating Gateway Configuration Entry
|
||||||
|
|
||||||
-> **v1.8.4+:** On Kubernetes, the `TerminatingGateway` custom resource is supported in Consul versions 1.8.4+.<br />
|
-> **v1.8.4+:** On Kubernetes, the `TerminatingGateway` custom resource is supported in Consul versions 1.8.4+.<br />
|
||||||
**v1.8.0+:** On other platforms, this config entry is supported in Consul versions 1.8.0+.
|
**v1.8.0+:** On other platforms, this config entry is supported in Consul versions 1.8.0+.
|
||||||
|
|
|
@ -1,13 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Connect - Configuration
|
page_title: Service Mesh Configuration: Overview
|
||||||
description: >-
|
description: >-
|
||||||
A Connect-aware proxy enables unmodified applications to use Connect. A
|
Learn how to enable and configure Consul's service mesh capabilities in agent configurations, and how to integrate with schedulers like Kubernetes and Nomad. ""Connect"" is the subsystem that provides Consul’s service mesh capabilities.
|
||||||
per-service proxy sidecar transparently handles inbound and outbound service
|
|
||||||
connections, automatically wrapping and verifying TLS connections.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Service Mesh Configuration
|
# Service Mesh Configuration Overview
|
||||||
|
|
||||||
There are many configuration options exposed for Consul service mesh. The only option
|
There are many configuration options exposed for Consul service mesh. The only option
|
||||||
that must be set is the `connect.enabled` option on Consul servers to enable Consul service mesh.
|
that must be set is the `connect.enabled` option on Consul servers to enable Consul service mesh.
|
||||||
|
|
|
@ -1,9 +1,8 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: How Connect Works
|
page_title: Service Mesh: How it Works
|
||||||
description: >-
|
description: >-
|
||||||
This page details the internals of Consul Connect: mutual TLS, agent caching
|
Consul's service mesh enforces secure service communication using mutual TLS (mTLS) encryption and explicit authorization. Learn how the service mesh certificate authorities, intentions, and agents work together in the ""Connect"" subsystem to provide Consul’s service mesh capabilities.
|
||||||
and performance, intention and certificate authority replication.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# How Service Mesh Works
|
# How Service Mesh Works
|
||||||
|
|
|
@ -1,11 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Connectivity Tasks
|
page_title: Gateway Types
|
||||||
description: >-
|
description: >-
|
||||||
Tasks related to connectivity into, out of, and between Consul service meshes.
|
Ingress, terminating, and mesh gateways are proxies that direct traffic into, out of, and inside of Consul's service mesh. Learn how these gateways enable different kinds of service-to-service communication.
|
||||||
---
|
---
|
||||||
|
|
||||||
# Connectivity Tasks
|
# Types of Gateway Connections in a Service Mesh
|
||||||
|
|
||||||
~> **Note**: The features shown below are extensions of Consul's service mesh capabilities. If you are not utilizing
|
~> **Note**: The features shown below are extensions of Consul's service mesh capabilities. If you are not utilizing
|
||||||
Consul service mesh then these features will not be relevant to your task.
|
Consul service mesh then these features will not be relevant to your task.
|
||||||
|
|
|
@ -1,15 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Connect - Development and Debugging
|
page_title: Service Mesh Debugging
|
||||||
description: >-
|
description: >-
|
||||||
It is often necessary to connect to a service for development or debugging. If
|
Use the `consul connect proxy` command to connect to services or masquerade as other services for development and debugging purposes. Example code demonstrates connecting to services that are part of the service mesh as listeners only.
|
||||||
a service only exposes a Connect listener, then we need a way to establish a
|
|
||||||
mutual TLS connection to the service. The `consul connect proxy` command can
|
|
||||||
be used for this task on any machine with access to a Consul agent (local or
|
|
||||||
remote).
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Developing and Debugging Connect Services
|
# Service Mesh Debugging
|
||||||
|
|
||||||
It is often necessary to connect to a service for development or debugging.
|
It is often necessary to connect to a service for development or debugging.
|
||||||
If a service only exposes a Connect listener, then we need a way to establish
|
If a service only exposes a Connect listener, then we need a way to establish
|
||||||
|
|
|
@ -1,8 +1,8 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Distributed Tracing
|
page_title: Service Mesh Distributed Tracing
|
||||||
description: >-
|
description: >-
|
||||||
Distributed tracing is a way to track and correlate requests across microservices.
|
Distributed tracing tracks the path of a request as it traverses the service mesh. Consul supports distributed tracing for applications that have it implemented. Learn how to integrate tracing libraries in your application and configure Consul to participate in that tracing.
|
||||||
---
|
---
|
||||||
|
|
||||||
# Distributed Tracing
|
# Distributed Tracing
|
||||||
|
|
|
@ -1,11 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Gateways
|
page_title: Gateways Overview
|
||||||
description: >-
|
description: >-
|
||||||
Gateways provide connectivity into, out of, and between Consul service meshes.
|
Gateways are proxies that direct traffic into, out of, and inside of Consul's service mesh. They secure communication with external or non-mesh network resources and enable services on different runtimes, cloud providers, or with overlapping IP addresses to communicate with each other.
|
||||||
---
|
---
|
||||||
|
|
||||||
# Gateways
|
# Gateways Overview
|
||||||
|
|
||||||
This topic provides an overview of the gateway features shipped with Consul. Gateways provide connectivity into, out of, and between Consul service meshes. You can configure the following types of gateways:
|
This topic provides an overview of the gateway features shipped with Consul. Gateways provide connectivity into, out of, and between Consul service meshes. You can configure the following types of gateways:
|
||||||
|
|
||||||
|
|
|
@ -1,9 +1,8 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Using Ingress Gateways to Connect External Traffic to Internal Services
|
page_title: Ingress Gateway | Service Mesh
|
||||||
description: >-
|
description: >-
|
||||||
This topic describes how ingress gateways enable traffic from external services to reach services inside the Consul service mesh.
|
Ingress gateways listen for requests from external network locations and route authorized traffic to destinations in the service mesh. Use custom TLS certificates with ingress gateways through Envoy's gRPC Secret Discovery Service (SDS).
|
||||||
It provides guidance on how to use Envoy and how to plug into your preferred gateway.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Ingress Gateways
|
# Ingress Gateways
|
||||||
|
|
|
@ -1,12 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Service-to-service Traffic Across Datacenters
|
page_title: Mesh Gateways between Datacenters
|
||||||
description: >-
|
description: >-
|
||||||
This topic describes how to configure mesh gateways to route a service's data to upstreams
|
Mesh gateways are specialized proxies that route data between services that cannot communicate directly. Learn how to enable service-to-service traffic across datacenters and review example configuration entries.
|
||||||
in other datacenters. It describes how to use Envoy and how you can integrate with your preferred gateway.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Service-to-service Traffic Across Datacenters
|
# Mesh Gateways between Datacenters
|
||||||
|
|
||||||
-> **1.6.0+:** This feature is available in Consul versions 1.6.0 and newer.
|
-> **1.6.0+:** This feature is available in Consul versions 1.6.0 and newer.
|
||||||
|
|
||||||
|
|
|
@ -1,12 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Service-to-service Traffic Across Partitions
|
page_title: Mesh Gateways between Admin Partitions
|
||||||
description: >-
|
description: >-
|
||||||
This topic describes how to configure mesh gateways to route a service's data to upstreams
|
Mesh gateways are specialized proxies that route data between services that cannot communicate directly with upstreams. Learn how to enable service-to-service traffic across admin partitions and review example configuration entries.
|
||||||
in other partitions. It describes how to use Envoy and how you can integrate with your preferred gateway.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Service-to-service Traffic Across Partitions
|
# Mesh Gateways between Admin Partitions
|
||||||
|
|
||||||
-> **Consul Enterprise 1.11.0+:** Admin partitions are supported in Consul Enterprise versions 1.11.0 and newer.
|
-> **Consul Enterprise 1.11.0+:** Admin partitions are supported in Consul Enterprise versions 1.11.0 and newer.
|
||||||
|
|
||||||
|
|
|
@ -1,12 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Service-to-service Traffic Across Peered Clusters
|
page_title: Mesh Gateways between Peered Clusters
|
||||||
description: >-
|
description: >-
|
||||||
This topic describes how to configure mesh gateways to route a service's data to upstreams
|
Mesh gateways are specialized proxies that route data between services that cannot communicate directly. Learn how to enable service-to-service traffic across clusters in different datacenters or admin partitions that have an established peering connection.
|
||||||
in clusters that have a peering connection.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Service-to-service Traffic Across Peered Clusters
|
# Mesh Gateways between Peered Clusters
|
||||||
|
|
||||||
~> **Cluster peering is currently in beta**: Functionality associated with cluster peering is subject to change. You should never use the beta release in secure environments or production scenarios. Features in beta may have performance issues, scaling issues, and limited support.
|
~> **Cluster peering is currently in beta**: Functionality associated with cluster peering is subject to change. You should never use the beta release in secure environments or production scenarios. Features in beta may have performance issues, scaling issues, and limited support.
|
||||||
|
|
||||||
|
|
|
@ -1,11 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: WAN Federation via Mesh Gateways
|
page_title: Mesh Gateways for WAN Federation
|
||||||
description: |-
|
description: >-
|
||||||
WAN federation via mesh gateways allows for Consul servers in different datacenters to be federated exclusively through mesh gateways.
|
You can use mesh gateways to simplify the networking requirements for WAN federated Consul datacenters. Mesh gateways reduce cross-datacenter connection paths, ports, and communication protocols.
|
||||||
---
|
---
|
||||||
|
|
||||||
# WAN Federation via Mesh Gateways
|
# Mesh Gateways for WAN Federation
|
||||||
|
|
||||||
-> **1.8.0+:** This feature is available in Consul versions 1.8.0 and higher
|
-> **1.8.0+:** This feature is available in Consul versions 1.8.0 and higher
|
||||||
|
|
||||||
|
|
|
@ -1,10 +1,8 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Internal <> External Services - Terminating Gateways
|
page_title: Terminating Gateway | Service Mesh
|
||||||
description: >-
|
description: >-
|
||||||
A terminating gateway enables traffic from services in the Consul
|
Terminating gateways send requests from inside the service mesh to external network locations and services outside the mesh. Learn about requirements and terminating gateway interactions with Consul's service catalog.
|
||||||
service mesh to services outside the mesh. This section details
|
|
||||||
how to configure and run a terminating gateway.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Terminating Gateways
|
# Terminating Gateways
|
||||||
|
|
|
@ -1,9 +1,8 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Service Mesh
|
page_title: Service Mesh on Consul
|
||||||
description: |-
|
description: >-
|
||||||
Consul Connect provides service-to-service connection authorization and
|
Consul’s service mesh makes application and microservice networking secure and observable with identity-based authentication, mutual TLS (mTLS) encryption, and explicit service-to-service authorization enforced by sidecar proxies. Learn how Consul’s service mesh works and get started on VMs or Kubernetes.
|
||||||
encryption using mutual TLS.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Consul Service Mesh
|
# Consul Service Mesh
|
||||||
|
|
|
@ -1,10 +1,8 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Service-to-service permissions - Intentions (Legacy Mode)
|
page_title: Intentions (Legacy Mode)
|
||||||
description: >-
|
description: >-
|
||||||
Intentions define access control for services via Connect and are used to
|
Intentions define service communication permissions in the service mesh. As of version 1.9, Consul uses a new system for creating and managing intentions. Learn how intentions worked in earlier versions of Consul with this legacy documentation.
|
||||||
control which services may establish connections. Intentions can be managed
|
|
||||||
via the API, CLI, or UI.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Intentions in Legacy Mode
|
# Intentions in Legacy Mode
|
||||||
|
|
|
@ -1,12 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Service-to-service permissions - Intentions
|
page_title: Service Mesh Intentions
|
||||||
description: >-
|
description: >-
|
||||||
Intentions define access control for services via Connect and are used to
|
Intentions define communication permissions in the service mesh between microservices. Learn about configuration basics, wildcard intentions, precedence and match order, and protecting intention management with ACLs.
|
||||||
control which services may establish connections or make requests.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Intentions
|
# Service Mesh Intentions
|
||||||
|
|
||||||
-> **1.9.0 and later:** This guide only applies in Consul versions 1.9.0 and
|
-> **1.9.0 and later:** This guide only applies in Consul versions 1.9.0 and
|
||||||
later. The documentation for the legacy intentions system is
|
later. The documentation for the legacy intentions system is
|
||||||
|
|
|
@ -1,13 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Discovery Chain
|
page_title: Service Mesh Traffic Management: Discovery Chain
|
||||||
description: >-
|
description: >-
|
||||||
The service discovery process can be modeled as a "discovery chain" which
|
The discovery chain compiles service router, splitter, and resolver configuration entries to direct traffic to specific instances in a service mesh. Learn about compiled discovery chain results, including discovery graph nodes and targets.
|
||||||
passes through three distinct stages: routing, splitting, and resolution. Each
|
|
||||||
of these stages is controlled by a set of configuration entries.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Discovery Chain
|
# Discovery Chain for Service Mesh Traffic Management
|
||||||
|
|
||||||
-> **1.6.0+:** This feature is available in Consul versions 1.6.0 and newer.
|
-> **1.6.0+:** This feature is available in Consul versions 1.6.0 and newer.
|
||||||
|
|
||||||
|
|
|
@ -1,14 +1,13 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Connect - L7 Traffic Management
|
page_title: Service Mesh Traffic Management: Overview
|
||||||
description: >-
|
description: >-
|
||||||
Layer 7 traffic management allows operators to divide L7 traffic between
|
Consul can route, split, and resolve Layer 7 traffic in a service mesh to support workflows like canary testing and blue/green deployments. Learn about the three configuration entry kinds that define L7 traffic management behavior in Consul.
|
||||||
different subsets of service instances when using Connect.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
-> **1.6.0+:** This feature is available in Consul versions 1.6.0 and newer.
|
-> **1.6.0+:** This feature is available in Consul versions 1.6.0 and newer.
|
||||||
|
|
||||||
# L7 Traffic Management
|
# Service Mesh Traffic Management Overview
|
||||||
|
|
||||||
Layer 7 traffic management allows operators to divide L7 traffic between
|
Layer 7 traffic management allows operators to divide L7 traffic between
|
||||||
different
|
different
|
||||||
|
|
|
@ -1,14 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Connect - Native Application Integration - Go
|
page_title: Service Mesh Native App Integration: Go Apps
|
||||||
description: >-
|
description: >-
|
||||||
We provide a library that makes it drop-in simple to integrate Connect with
|
Consul's service mesh supports native integrations of Go applications into the service mesh through a Go library. Example code demonstrates how to connect your Go applications to the service mesh.
|
||||||
most Go applications. For most Go applications, Connect can be natively
|
|
||||||
integrated in just a single line of code excluding imports and struct
|
|
||||||
initialization.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Connect-Native Integration with Go
|
# Service Mesh Native Integration for Go Applications
|
||||||
|
|
||||||
-> **Note:** When calling `ConnectAuthorize()` on incoming connections this library
|
-> **Note:** When calling `ConnectAuthorize()` on incoming connections this library
|
||||||
will return _deny_ if `Permissions` are defined on the matching intention.
|
will return _deny_ if `Permissions` are defined on the matching intention.
|
||||||
|
|
|
@ -1,13 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Connect - Native Application Integration
|
page_title: Service Mesh Native App Integration: Overview
|
||||||
description: >-
|
description: >-
|
||||||
Applications can natively integrate with the Connect API to support accepting
|
When using sidecar proxies is not possible, applications can natively integrate with Consul service mesh, but have reduced access to service mesh features. Learn how “Connect-Native” apps use mTLS to authenticate with Consul and how to add integrations to service registrations.
|
||||||
and establishing connections to other Connect services without the overhead of
|
|
||||||
a proxy sidecar.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Connect-Native App Integration
|
# Service Mesh Native App Integration Overview
|
||||||
|
|
||||||
~> **Note:** The Native App Integration does not support many of the Connect service
|
~> **Note:** The Native App Integration does not support many of the Connect service
|
||||||
mesh features, and is not under active development.
|
mesh features, and is not under active development.
|
||||||
|
|
|
@ -1,13 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Connect - Nomad
|
page_title: Sevice Mesh: Nomad Integration
|
||||||
description: >-
|
description: >-
|
||||||
Connect can be used with [Nomad](https://www.nomadproject.io) to provide
|
Consul's service mesh can be applied to provide secure communication between services managed by Nomad's scheduler and orchestrator functions, including Nomad jobs and task groups. Use the guide and reference documentation to learn more.
|
||||||
secure service-to-service communication between Nomad jobs. The ability to use
|
|
||||||
the dynamic port feature of Nomad makes Connect particularly easy to use.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Connect on Nomad
|
# Consul and Nomad Integration
|
||||||
|
|
||||||
Consul Connect can be used with [Nomad](https://www.nomadproject.io) to provide
|
Consul Connect can be used with [Nomad](https://www.nomadproject.io) to provide
|
||||||
secure service-to-service communication between Nomad jobs and task groups.
|
secure service-to-service communication between Nomad jobs and task groups.
|
||||||
|
|
|
@ -1,12 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Connect - Observability
|
page_title: Service Mesh Observability: Overview
|
||||||
description: |-
|
description: >-
|
||||||
This page documents the configurations necessary for L7 observability using
|
To use Consul's observability features, configure sidecar proxies in the service mesh to collect and emit L7 metrics. Learn about configuring metrics destinations and a service's protocol and upstreams.
|
||||||
Consul Connect.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Observability
|
# Service Mesh Observability Overview
|
||||||
|
|
||||||
In order to take advantage of Connect's L7 observability features you will need
|
In order to take advantage of Connect's L7 observability features you will need
|
||||||
to:
|
to:
|
||||||
|
|
|
@ -1,12 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Connect - UI Visualization
|
page_title: Service Mesh Observability: UI Visualization
|
||||||
description: |-
|
description: >-
|
||||||
This page describes how to set up and customize the Service Mesh Topology
|
Consul's UI can display a service's topology and associated metrics from the service mesh. Learn how to configure the UI to collect metrics from your metrics provider, modify access for metrics proxies, and integrate custom metrics providers.
|
||||||
visualization in Consul's UI.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# UI Visualization
|
# Service Mesh Observability: UI Visualization
|
||||||
|
|
||||||
-> Coming here from "Configure metrics dashboard" or "Configure dashboard"? See [Configuring Dashboard URLs](#configuring-dashboard-urls).
|
-> Coming here from "Configure metrics dashboard" or "Configure dashboard"? See [Configuring Dashboard URLs](#configuring-dashboard-urls).
|
||||||
|
|
||||||
|
|
|
@ -1,10 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Connect - Built-in Proxy
|
page_title: Built-in Proxy Configuration | Service Mesh
|
||||||
description: Consul Connect comes with a built-in proxy for testing and development.
|
description: >-
|
||||||
|
Consul includes a built-in L4 proxy with limited capabilities to use for development and testing only. Use the built-in proxy config key reference to learn about the options you can configure.
|
||||||
---
|
---
|
||||||
|
|
||||||
# Built-In Proxy Options
|
# Built-in Proxy Configuration for Service Mesh
|
||||||
|
|
||||||
~> **Note:** The built-in proxy is not supported for production deployments. It does not
|
~> **Note:** The built-in proxy is not supported for production deployments. It does not
|
||||||
support many of the Connect service mesh features, and is not under active development.
|
support many of the Connect service mesh features, and is not under active development.
|
||||||
|
|
|
@ -1,10 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Connect - Envoy Integration
|
page_title: Envoy Proxy Configuration | Service Mesh
|
||||||
description: Consul Connect has first-class support for configuring Envoy proxy.
|
description: >-
|
||||||
|
Consul supports Envoy proxies to direct traffic throughout the service mesh. Learn about Consul versions and their Envoy support, and use the reference guide to review options for bootstrap configuration, dynamic configuration, and advanced topics like escape hatch overrides.
|
||||||
---
|
---
|
||||||
|
|
||||||
# Envoy Integration
|
# Envoy Proxy Configuration for Service Mesh
|
||||||
|
|
||||||
Consul Connect has first class support for using
|
Consul Connect has first class support for using
|
||||||
[Envoy](https://www.envoyproxy.io) as a proxy. Consul configures Envoy by
|
[Envoy](https://www.envoyproxy.io) as a proxy. Consul configures Envoy by
|
||||||
|
|
|
@ -1,13 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Connect - Proxies
|
page_title: Service Mesh Proxy Overview
|
||||||
description: >-
|
description: >-
|
||||||
A Connect-aware proxy enables unmodified applications to use Connect. This
|
In Consul service mesh, each service has a sidecar proxy that secures connections with other services in the mesh without modifying the underlying application code. You can use the built-in proxy, Envoy, or a custom proxy to handle communication and verify TLS connections.
|
||||||
section details how to use either Envoy or Consul's built-in L4 proxy, and
|
|
||||||
describes how you can plug in a proxy of your choice.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Connect Proxies
|
# Service Mesh Proxy Overview
|
||||||
|
|
||||||
A Connect-aware proxy enables unmodified applications to use Connect. A
|
A Connect-aware proxy enables unmodified applications to use Connect. A
|
||||||
per-service proxy sidecar transparently handles inbound and outbound service
|
per-service proxy sidecar transparently handles inbound and outbound service
|
||||||
|
|
|
@ -1,13 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Connect - Proxy Integration
|
page_title: Custom Proxy Configuration | Service Mesh
|
||||||
description: >-
|
description: >-
|
||||||
A Connect-aware proxy enables unmodified applications to use Connect. A
|
Consul supports custom proxy integrations for service discovery and sidecar instantiation. Learn about proxy requirements for service mesh operations, as well as how to authorize inbound and outbound connections for your custom proxy.
|
||||||
per-service proxy sidecar transparently handles inbound and outbound service
|
|
||||||
connections, automatically wrapping and verifying TLS connections.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Connect Custom Proxy Integration
|
# Custom Proxy Configuration for Service Mesh
|
||||||
|
|
||||||
This topic describes the process and API endpoints you can use to extend proxies for integration with Consul.
|
This topic describes the process and API endpoints you can use to extend proxies for integration with Consul.
|
||||||
|
|
||||||
|
|
|
@ -1,13 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Connect - Deprecated Managed Proxies
|
page_title: Managed Proxy for Connect (Legacy)
|
||||||
description: |-
|
description: >-
|
||||||
Consul 1.2 launched its Connect Beta period with a feature named Managed
|
Consul's service mesh originally included a proxy manager that was deprecated in version 1.6. Learn about the reasons for its deprecation and how it worked with this legacy documentation.
|
||||||
Proxies which are now deprecated. This page describes how they worked and why
|
|
||||||
they are no longer supported.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Managed Proxy Deprecation
|
# Managed Proxy for Connect Legacy Documentation
|
||||||
|
|
||||||
Consul Connect was first released as a beta feature in Consul 1.2.0. The initial
|
Consul Connect was first released as a beta feature in Consul 1.2.0. The initial
|
||||||
release included a feature called "Managed Proxies". Managed proxies were
|
release included a feature called "Managed Proxies". Managed proxies were
|
||||||
|
|
|
@ -1,13 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Connect - Proxy Registration
|
page_title: Service Mesh Proxy Registration Overview
|
||||||
description: >-
|
description: >-
|
||||||
To make connect aware of proxies you will need to register them as Consul
|
To make Consul aware of proxies in your service mesh, you must register them. Learn about methods for configuring and registering sidecar proxies.
|
||||||
services. This section describes the process and options for proxy
|
|
||||||
registration.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Proxy Registration
|
# Service Mesh Proxy Overview
|
||||||
|
|
||||||
To make Connect aware of proxies you will need to register them in a [service
|
To make Connect aware of proxies you will need to register them in a [service
|
||||||
definition](/docs/discovery/services), just like you would register any other service with Consul. This section outlines your options for registering Connect proxies, either using independent registrations, or in nested sidecar registrations.
|
definition](/docs/discovery/services), just like you would register any other service with Consul. This section outlines your options for registering Connect proxies, either using independent registrations, or in nested sidecar registrations.
|
||||||
|
|
|
@ -1,13 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Connect - Service Registration
|
page_title: Register a Service Mesh Proxy Outside of a Service Registration
|
||||||
description: >-
|
description: >-
|
||||||
A per-service proxy sidecar transparently handles inbound and outbound service
|
You can register a service mesh sidecar proxy separately from the registration of the service instance it fronts. Learn about proxy configuration options and how to format them with examples.
|
||||||
connections. You can register these sidecars with reasonable defaults by nesting
|
|
||||||
their definitions in the service definition.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Proxy Service Registration
|
# Register a Service Mesh Proxy Outside of a Service Registration
|
||||||
|
|
||||||
This topic describes how to declare a proxy as a `connect-proxy` in service definitions. The `kind` must be declared and information about the service they represent must be provided to function as a Consul service mesh proxy.
|
This topic describes how to declare a proxy as a `connect-proxy` in service definitions. The `kind` must be declared and information about the service they represent must be provided to function as a Consul service mesh proxy.
|
||||||
|
|
||||||
|
|
|
@ -1,12 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Connect - Sidecar Service Registration
|
page_title: Register a Service Mesh Proxy in a Service Registration
|
||||||
description: |-
|
description: >-
|
||||||
Sidecar service registrations provide a convenient shorthand for registering a
|
You can register a service instance and its sidecar proxy at the same time. Learn about default settings, customizable parameters, limitations, and lifecycle behaviors of the sidecar proxy.
|
||||||
sidecar proxy inline with a regular service definition.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Sidecar Service Registration
|
# Register a Service Mesh Proxy in a Service Registration
|
||||||
|
|
||||||
Connect proxies are typically deployed as "sidecars" that run on the same node
|
Connect proxies are typically deployed as "sidecars" that run on the same node
|
||||||
as the single service instance that they handle traffic for. They might be on
|
as the single service instance that they handle traffic for. They might be on
|
||||||
|
|
|
@ -1,13 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Connect - Security
|
page_title: Service Mesh Security: Best Practices
|
||||||
description: |-
|
description: >-
|
||||||
Connect enables secure service-to-service communication over mutual TLS. This
|
Consul provides secure service mesh communication by default. Additional configuration can improve network security by preventing unauthorized access and traffic sniffing. Review security considerations, our recommendations, and best practices.
|
||||||
provides both in-transit data encryption as well as authorization. This page
|
|
||||||
will document how to secure Connect.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Connect Security
|
# Best Practices for Service Mesh Security
|
||||||
|
|
||||||
Connect enables secure service-to-service communication over mutual TLS. This
|
Connect enables secure service-to-service communication over mutual TLS. This
|
||||||
provides both in-transit data encryption as well as authorization. This page
|
provides both in-transit data encryption as well as authorization. This page
|
||||||
|
|
|
@ -1,13 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Connect - Transparent Proxy
|
page_title: Service Mesh: Enable Transparent Proxy Mode
|
||||||
sidebar_title: Transparent Proxy
|
description: >-
|
||||||
description: |-
|
Learn how transparent proxy enables Consul on Kubernetes to direct inbound and outbound traffic through the service mesh. Use transparent proxying to increase application security without configuring individual upstream services.
|
||||||
Transparent proxy is used to direct inbound and outbound traffic to services via the Envoy proxy and configure
|
|
||||||
upstreams via intentions.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Transparent Proxy
|
# Enable Transparent Proxy Mode
|
||||||
|
|
||||||
This topic describes how to use Consul’s transparent proxy feature, which allows applications to communicate through the service mesh without modifying their configurations. Transparent proxy also hardens application security by preventing direct inbound connections that bypass the mesh.
|
This topic describes how to use Consul’s transparent proxy feature, which allows applications to communicate through the service mesh without modifying their configurations. Transparent proxy also hardens application security by preventing direct inbound connections that bypass the mesh.
|
||||||
|
|
||||||
|
|
|
@ -1,14 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Monitor Services - Check Definitions
|
page_title: Configure Health Checks
|
||||||
description: >-
|
description: >-
|
||||||
One of the primary roles of the agent is management of system- and
|
Agents can be configured to periodically perform custom checks on the health of a service instance or node. Learn about the types of health checks and how to define them in agent and service configuration files.
|
||||||
application-level health checks. A health check is considered to be
|
|
||||||
application-level if it is associated with a service. A check is defined in a
|
|
||||||
configuration file or added at runtime over the HTTP interface.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Checks
|
# Health Checks
|
||||||
|
|
||||||
One of the primary roles of the agent is management of system-level and application-level health
|
One of the primary roles of the agent is management of system-level and application-level health
|
||||||
checks. A health check is considered to be application-level if it is associated with a
|
checks. A health check is considered to be application-level if it is associated with a
|
||||||
|
|
|
@ -1,13 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Find Services - DNS Interface
|
page_title: Find services with DNS
|
||||||
description: >-
|
description: >-
|
||||||
One of the primary query interfaces for Consul is DNS. The DNS interface
|
For service discovery use cases, Domain Name Service (DNS) is the main interface to look up, query, and address Consul nodes and services. Learn how a Consul DNS lookup can help you find services by tag, name, namespace, partition, datacenter, or domain.
|
||||||
allows applications to make use of service discovery without any high-touch
|
|
||||||
integration with Consul.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# DNS Interface
|
# Query services with DNS
|
||||||
|
|
||||||
One of the primary query interfaces for Consul is DNS.
|
One of the primary query interfaces for Consul is DNS.
|
||||||
The DNS interface allows applications to make use of service
|
The DNS interface allows applications to make use of service
|
||||||
|
|
|
@ -1,16 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Register Services - Service Definitions
|
page_title: Register Services with Service Definitions
|
||||||
description: >-
|
description: >-
|
||||||
One of the main goals of service discovery is to provide a catalog of
|
Define and register services and their health checks with Consul to make a service available for service discovery or service mesh access. Learn how to format service definitions with this reference page and sample code.
|
||||||
available services. To that end, the agent provides a simple service
|
|
||||||
definition format to declare the availability of a service and to potentially
|
|
||||||
associate it with a health check. A health check is considered to be
|
|
||||||
application level if it is associated with a service. A service is defined in
|
|
||||||
a configuration file or added at runtime over the HTTP interface.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Services
|
# Register Services with Service Definitions
|
||||||
|
|
||||||
One of the main goals of service discovery is to provide a catalog of available
|
One of the main goals of service discovery is to provide a catalog of available
|
||||||
services. To that end, the agent provides a simple service definition format
|
services. To that end, the agent provides a simple service definition format
|
||||||
|
|
|
@ -94,4 +94,4 @@ to [build distributed semaphores](https://learn.hashicorp.com/consul/developer-c
|
||||||
### Vault
|
### Vault
|
||||||
|
|
||||||
If you plan to use Consul KV as a backend for Vault, please review [this
|
If you plan to use Consul KV as a backend for Vault, please review [this
|
||||||
tutorial](https://learn.hashicorp.com/tutorials/vault/ha-with-consul).
|
tutorial](/vault/tutorials/day-one-consul/ha-with-consul?utm_source=docs).
|
||||||
|
|
|
@ -1,7 +1,8 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Consul Enterprise Admin Partitions
|
page_title: Admin Partitions (Enterprise)
|
||||||
description: Consul Enterprise enables you to create partitions that can be administrated across namespaces.
|
description: >-
|
||||||
|
Admin partitions define boundaries between services managed by separate teams, enabling a service mesh across k8s clusters controlled by a single Consul server. Learn about their requirements and how to deploy admin partitions on Kubernetes.
|
||||||
---
|
---
|
||||||
|
|
||||||
# Consul Enterprise Admin Partitions
|
# Consul Enterprise Admin Partitions
|
||||||
|
|
|
@ -1,8 +1,8 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Consul Enterprise Audit Logging
|
page_title: Audit Logging (Enterprise)
|
||||||
description: >-
|
description: >-
|
||||||
Consul Enterprise provides the ability to write events of user behavior with Consul's API so operations and security users can perform legal compliance auditing.
|
Audit logging secures Consul by capturing a record of HTTP API access and usage. Learn how to format agent configuration files to enable audit logs and specify the path to save logs to.
|
||||||
---
|
---
|
||||||
|
|
||||||
# Audit Logging
|
# Audit Logging
|
||||||
|
|
|
@ -1,10 +1,8 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Consul Enterprise Automated Backups
|
page_title: Automated Backups (Enterprise)
|
||||||
description: >-
|
description: >-
|
||||||
Consul Enterprise provides a highly available service that manages taking
|
Learn about launching the snapshot agent to automatically backup files to a cloud storage provider so that you can restore Consul servers. Supported providers include: Amazon S3, Google Cloud Storage, and Azure Blob Storage.
|
||||||
snapshots, rotation and sending backup files offsite to Amazon S3 (or
|
|
||||||
S3-compatible endpoints), Google Cloud Storage, or Azure Blob Storage.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Automated Backups
|
# Automated Backups
|
||||||
|
|
|
@ -1,10 +1,8 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Consul Enterprise Advanced Federation
|
page_title: Federated Network Areas (Enterprise)
|
||||||
description: >-
|
description: >-
|
||||||
Consul Enterprise enables you to federate Consul datacenters together on a
|
Network areas connect individual datacenters in a WAN federation, providing an alternative to connecting every datacenter. Learn how to support hub-and-spoke network topologies in a WAN federated Consul deployment.
|
||||||
pairwise basis, enabling partially-connected network topologies like
|
|
||||||
hub-and-spoke.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Consul Enterprise Advanced Federation
|
# Consul Enterprise Advanced Federation
|
||||||
|
|
|
@ -2,8 +2,7 @@
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Consul Enterprise
|
page_title: Consul Enterprise
|
||||||
description: >-
|
description: >-
|
||||||
Consul Enterprise features a number of capabilities beyond the open source
|
Consul Enterprise is a paid offering that extends Consul’s open source functions to support large and complex deployments. Learn about scaling infrastructure, simplifying operations, and making networks more resilient with Enterprise.
|
||||||
offering that may be beneficial in certain workflows.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Consul Enterprise
|
# Consul Enterprise
|
||||||
|
|
|
@ -1,7 +1,8 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Consul Enterprise License FAQ
|
page_title: Enterprise License FAQ
|
||||||
description: Frequently Asked Questions pertaining to Consul Enterprise Licensing.
|
description: >-
|
||||||
|
Review frequently asked questions (FAQs) about Consul Enterprise licenses to learn more about how licenses work, what happens when they expire, and how to get a trial license.
|
||||||
---
|
---
|
||||||
|
|
||||||
# Frequently Asked Questions (FAQ)
|
# Frequently Asked Questions (FAQ)
|
||||||
|
|
|
@ -1,7 +1,8 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Consul Enterprise License
|
page_title: Enterprise Licenses
|
||||||
description: Consul Enterprise License Overview.
|
description: >-
|
||||||
|
Consul Enterprise server, client, and snapshot agents require a license on startup in order to use Enterprise features. Learn how to apply licenses using environment variables or configuration files.
|
||||||
---
|
---
|
||||||
|
|
||||||
# Consul Enterprise License
|
# Consul Enterprise License
|
||||||
|
|
|
@ -1,7 +1,8 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Consul Enterprise Namespaces
|
page_title: Namespaces (Enterprise)
|
||||||
description: Consul Enterprise enables data isolation with Namespaces.
|
description: >-
|
||||||
|
Namespaces reduce operational challenges in large deployments. Learn how to define a namespace so that multiple users or teams can access and use the same datacenter without impacting each other.
|
||||||
---
|
---
|
||||||
|
|
||||||
# Consul Enterprise Namespaces
|
# Consul Enterprise Namespaces
|
||||||
|
|
|
@ -1,9 +1,8 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Consul Enterprise Network Segments
|
page_title: Network Segments (Enterprise)
|
||||||
description: |-
|
description: >-
|
||||||
Consul Enterprise enables you create separate LAN gossip pools within one
|
Network segments enable LAN gossip in a datacenter when network rules or firewalls prevent specific sets of clients from communicating directly. Learn about configuring server and client agents to operate in segmented networks.
|
||||||
cluster to segment network groups.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Network Segments
|
# Network Segments
|
||||||
|
|
|
@ -1,9 +1,8 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Consul Enterprise Enhanced Read Scalability
|
page_title: Read Replicas (Enterprise)
|
||||||
description: >-
|
description: >-
|
||||||
Consul Enterprise supports increased read scalability without impacting write
|
Learn how you can add non-voting servers to datacenters as read replicas to provide enhanced read scalability without impacting write latency.
|
||||||
latency by introducing read replicas.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Enhanced Read Scalability with Read Replicas
|
# Enhanced Read Scalability with Read Replicas
|
||||||
|
|
|
@ -1,9 +1,8 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Consul Enterprise Redundancy Zones
|
page_title: Redundancy Zones (Enterprise)
|
||||||
description: >-
|
description: >-
|
||||||
Consul Enterprise redundancy zones enable hot standby servers on a per
|
Redundancy zones are regions of a cluster containing "hot standby" servers, or non-voting servers that can replace voting servers in the event of a failure. Learn about redundancy zones and how they improve resiliency and increase fault tolerance without affecting latency.
|
||||||
availability zone basis.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Redundancy Zones
|
# Redundancy Zones
|
||||||
|
|
|
@ -1,10 +1,8 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Sentinel in Consul
|
page_title: Sentinel in Consul (Enterprise)
|
||||||
description: >-
|
description: >-
|
||||||
Consul Enterprise uses Sentinel to augment the built-in ACL system to provide
|
Sentinel is an access-control-policy-as-code framework and language. Learn how Consul can use Sentinel policies to extend the ACL system's capabilities and further secure your clusters by controlling key-value (KV) store write access.
|
||||||
advanced policy enforcement. Sentinel policies can currently execute on KV
|
|
||||||
modify and service registration.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Sentinel in Consul
|
# Sentinel in Consul
|
||||||
|
|
|
@ -1,10 +1,8 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Consul Enterprise Automated Upgrades
|
page_title: Automated Upgrades (Enterprise)
|
||||||
description: >-
|
description: >-
|
||||||
Consul Enterprise supports an upgrade pattern that allows operators to deploy
|
Automated upgrades simplify the process for updating Consul. Learn how Consul can gracefully transition from existing server agents to a new set of server agents without Consul downtime.
|
||||||
a complete cluster of new servers and then just wait for the upgrade to
|
|
||||||
complete.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Automated Upgrades
|
# Automated Upgrades
|
||||||
|
|
|
@ -1,15 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Bootstrapping a Datacenter
|
page_title: Bootstrap a Datacenter
|
||||||
description: >-
|
description: >-
|
||||||
An agent can run in both client and server mode. Server nodes are responsible
|
Bootstrapping a datacenter is the initial deployment process in Consul that starts server agents and joins them together. Learn how to automatically or manually join servers in a cluster.
|
||||||
for running the consensus protocol and storing the cluster state. Before a
|
|
||||||
Consul cluster can begin to service requests, a server node must be elected
|
|
||||||
leader. Thus, the first nodes that are started are generally the server nodes.
|
|
||||||
Bootstrapping is the process of joining these server nodes into a cluster.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Bootstrapping a Datacenter
|
# Bootstrap a Datacenter
|
||||||
|
|
||||||
An agent can run in either client or server mode. Server nodes are responsible for running the
|
An agent can run in either client or server mode. Server nodes are responsible for running the
|
||||||
[consensus protocol](/docs/architecture/consensus) and storing the cluster state.
|
[consensus protocol](/docs/architecture/consensus) and storing the cluster state.
|
||||||
|
|
|
@ -1,9 +1,8 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Cloud Auto-join
|
page_title: Auto-join a Cloud Provider
|
||||||
description: >-
|
description: >-
|
||||||
Consul supports automatically joining a Consul datacenter using cloud metadata
|
Auto-join enables agents to automatically join other agents running in the cloud. To configure auto-join, specify agent addresses with compute node metadata for the cloud provider instead of an IP address. Use the CLI or an agent configuration file to configure cloud auto-join.
|
||||||
on various providers.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Cloud Auto-join
|
# Cloud Auto-join
|
||||||
|
|
|
@ -2,8 +2,7 @@
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Glossary
|
page_title: Glossary
|
||||||
description: >-
|
description: >-
|
||||||
This page collects brief definitions of some of the technical terms used in
|
The glossary is a list of technical terms with a specific meaning in Consul. Use the glossary to understand Consul concepts and study for the certification exam.
|
||||||
the documentation.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Consul Vocabulary
|
# Consul Vocabulary
|
||||||
|
|
|
@ -1,9 +1,8 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Get Started
|
page_title: Install Consul
|
||||||
description: |-
|
description: >-
|
||||||
Installing Consul is simple. You can download a precompiled binary, compile
|
Install Consul to get started with service discovery and service mesh. Follow the installation instructions to download the precompiled binary, or use Go to compile from source.
|
||||||
from source or run on Kubernetes. This page details these methods.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Install Consul
|
# Install Consul
|
||||||
|
|
|
@ -1,11 +1,8 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Manual Bootstrapping
|
page_title: Manually Bootstrap a Datacenter
|
||||||
description: >-
|
description: >-
|
||||||
When deploying Consul to a datacenter for the first time, there is an initial
|
Manually bootstrap a datacenter to deploy your Consul servers and join them together for the first time. For Consul v0.4+, we recommend automatic bootstrapping instead.
|
||||||
bootstrapping that must be done. As of Consul 0.4, an automatic bootstrapping
|
|
||||||
is available and is the recommended approach. However, older versions only
|
|
||||||
support a manual bootstrap that is documented here.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Manually Bootstrapping a Datacenter
|
# Manually Bootstrapping a Datacenter
|
||||||
|
|
|
@ -1,10 +1,8 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Server Performance
|
page_title: Server Performance Requirements
|
||||||
description: >-
|
description: >-
|
||||||
Consul requires different amounts of compute resources, depending on cluster
|
Consul servers require sufficient compute resources to communicate and process data quickly. Learn about Consul's minimum server requirements and recommendations for different workloads.
|
||||||
size and expected workload. This guide provides guidance on choosing compute
|
|
||||||
resources.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Server Performance
|
# Server Performance
|
||||||
|
|
|
@ -2,8 +2,7 @@
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Required Ports
|
page_title: Required Ports
|
||||||
description: >-
|
description: >-
|
||||||
Before starting Consul it is important to have the necessary bind ports
|
Consul requires multiple ports for directing DNS, HTTP, gRPC, gossip, and sidecar proxy requests. Learn about required and optional ports, and how Consul uses them for specific communication functions.
|
||||||
accessible.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Required Ports
|
# Required Ports
|
||||||
|
|
|
@ -1,9 +1,8 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Consul Tools
|
page_title: Consul Tools
|
||||||
description: |-
|
description: >-
|
||||||
From this page you can download various tools for Consul. These tools are
|
Consul's capabilities can be extended through integration with other tools. Learn about Consul-related tools created by HashiCorp and by the Consul community.
|
||||||
maintained by HashiCorp and the Consul Community.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Download Consul Tools
|
# Download Consul Tools
|
||||||
|
|
|
@ -1,7 +1,8 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Network Infrastructure Automation Integration Program
|
page_title: Network Infrastructure Automation (NIA) Integration Program
|
||||||
description: Guide to partnership integrations for Consul NIA
|
description: >-
|
||||||
|
The Network Infrastructure Automation (NIA) Integration Program allows partners to develop Terraform modules for Consul-Terraform-Sync (CTS) that HashiCorp reviews to consider publishing as officially verified. Learn about how to participate in the program.
|
||||||
---
|
---
|
||||||
|
|
||||||
# Network Infrastructure Automation Integration Program
|
# Network Infrastructure Automation Integration Program
|
||||||
|
|
|
@ -1,7 +1,8 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Consul Integration Program
|
page_title: Consul Integration Program
|
||||||
description: Guide to partnership integrations for Consul.
|
description: >-
|
||||||
|
The Consul Integration Program allows approved partners to develop Consul integrations that HashiCorp reviews to consider publishing as officially verified. Learn about how to participate in the program.
|
||||||
---
|
---
|
||||||
|
|
||||||
# Consul Integration Program
|
# Consul Integration Program
|
||||||
|
|
|
@ -1,12 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Internals
|
page_title: Internals Overview
|
||||||
description: >-
|
description: >-
|
||||||
This section covers some of the internals of Consul, such as the architecture,
|
To enhance your understanding of how to use, troubleshoot, and secure Consul, learn more about Consul's internal properties and how it works under the hood.
|
||||||
consensus and gossip protocols, and security model.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Consul Internals
|
# Consul Internals Overview
|
||||||
|
|
||||||
This section covers some of the internals of Consul. Understanding the internals of Consul is necessary to successfully
|
This section covers some of the internals of Consul. Understanding the internals of Consul is necessary to successfully
|
||||||
use it in production.
|
use it in production.
|
||||||
|
|
|
@ -2,7 +2,7 @@
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Annotations and Labels
|
page_title: Annotations and Labels
|
||||||
description: >-
|
description: >-
|
||||||
The list of available labels and annotations for running Consul on Kubernetes.
|
Annotations and labels configure Consul sidecar properties and injection behavior when scheduling Kubernetes clusters. Learn about the annotations and labels that enable Consul’s service mesh and secure upstream communication on k8s in this reference guide.
|
||||||
---
|
---
|
||||||
|
|
||||||
# Annotations and Labels
|
# Annotations and Labels
|
||||||
|
|
|
@ -1,8 +1,8 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Consul on Kubernetes Architecture
|
page_title: Consul on Kubernetes Control Plane Architecture
|
||||||
description: >-
|
description: >-
|
||||||
A high level overview of Consul on Kubernetes Architecture
|
When running on Kubernetes, Consul’s control plane architecture does not change significantly. Server agents are deployed as a StatefulSet with a persistent volume, while client agents run as a k8s DaemonSet with an exposed API port.
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
||||||
|
|
|
@ -1,10 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Compatibility Matrix
|
page_title: Consul on Kubernetes Version Compatibility
|
||||||
description: Compatibility Matrix for Consul Kubernetes
|
description: >-
|
||||||
|
New releases require corresponding version updates to Consul on Kubernetes and its Helm chart. Review the compatibility matrix for Consul and consul-k8s and additional notes for integrating Vault and third-party platforms.
|
||||||
---
|
---
|
||||||
|
|
||||||
# Compatibility Matrix for Consul on Kubernetes
|
# Consul on Kubernetes Version Compatibility
|
||||||
|
|
||||||
For every release of Consul on Kubernetes, a Helm chart, `consul-k8s-control-plane` binary and a `consul-k8s` CLI binary is built and distributed through a single version. When deploying via Helm, the recommended best path for upgrading Consul on Kubernetes, is to upgrade using the same `consul-k8s-control-plane` version as the Helm Chart, as the Helm Chart and Control Plane binary are tightly coupled.
|
For every release of Consul on Kubernetes, a Helm chart, `consul-k8s-control-plane` binary and a `consul-k8s` CLI binary is built and distributed through a single version. When deploying via Helm, the recommended best path for upgrading Consul on Kubernetes, is to upgrade using the same `consul-k8s-control-plane` version as the Helm Chart, as the Helm Chart and Control Plane binary are tightly coupled.
|
||||||
|
|
||||||
|
|
|
@ -1,10 +1,11 @@
|
||||||
---
|
"---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Configuring a Connect CA Provider
|
page_title: Configure Certificate Authority (CA) for Consul on Kubernetes
|
||||||
description: Configuring a Connect CA Provider
|
description: >-
|
||||||
---
|
Consul includes a built-in CA, but when bootstrapping a cluster on k8s, you can configure your service mesh to use a custom certificate provider instead. Learn how to configure Vault as an external CA in primary and secondary datacenters and manually rotate Vault tokens.
|
||||||
|
---"
|
||||||
|
|
||||||
# Configuring a Connect CA Provider
|
# Configure Certificate Authority (CA) for Consul on Kubernetes
|
||||||
|
|
||||||
~> **NOTE:** The instructions below should only be used for initially bootstrapping a cluster with **Consul K8s 0.38.0+.**
|
~> **NOTE:** The instructions below should only be used for initially bootstrapping a cluster with **Consul K8s 0.38.0+.**
|
||||||
To update the Connect CA provider on an existing cluster or to update any properties, such as tokens, of the CA provider,
|
To update the Connect CA provider on an existing cluster or to update any properties, such as tokens, of the CA provider,
|
||||||
|
|
|
@ -1,10 +1,11 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Kubernetes Health Checks
|
page_title: Configure Health Checks for Consul on Kubernetes
|
||||||
description: Configuring Kubernetes Health Checks
|
description: >-
|
||||||
|
Kubernetes has built-in health probes you can sync with Consul's health checks to ensure service mesh traffic is routed to healthy pods. Learn how to register a TTL Health check and use mutating webhooks to redirect k8s liveness, readiness, and startup probes through Envoy proxies.
|
||||||
---
|
---
|
||||||
|
|
||||||
# Kubernetes Health Checks in Consul on Kubernetes
|
# Configure Health Checks for Consul on Kubernetes
|
||||||
|
|
||||||
~> This topic requires familiarity with [Kubernetes Health Checks](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).
|
~> This topic requires familiarity with [Kubernetes Health Checks](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).
|
||||||
|
|
||||||
|
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue