mirror of https://github.com/status-im/consul.git
Merge pull request #14593 from hashicorp/docs/search-desc-batch03
docs: Search Metadata Batch 03
This commit is contained in:
Jeff Boruszak
GitHub
commit
78c53efc25
|
|
@ -1,11 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Anti-Entropy
|
||||
description: |
|
||||
This section details the process and use of anti-entropy in Consul.
|
||||
page_title: Anti-Entropy Enforcement
|
||||
description: >-
|
||||
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.
|
||||
This page details how services and checks are registered, how the catalog is
|
||||
|
|
|
|||
|
|
@ -1,10 +1,8 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Consensus Protocol
|
||||
page_title: Consensus Protocol | Raft
|
||||
description: >-
|
||||
Consul uses a consensus protocol to provide Consistency as defined by CAP. The
|
||||
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.
|
||||
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
|
||||
|
|
|
|||
|
|
@ -1,7 +1,8 @@
|
|||
---
|
||||
layout: docs
|
||||
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
|
||||
|
|
|
|||
|
|
@ -1,12 +1,8 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Gossip Protocol
|
||||
page_title: Gossip Protocol | Serf
|
||||
description: >-
|
||||
Consul uses a gossip protocol to manage membership and broadcast messages to
|
||||
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.
|
||||
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.
|
||||
---
|
||||
|
||||
# Gossip Protocol
|
||||
|
|
|
|||
|
|
@ -1,16 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Improving Consul Resilience
|
||||
page_title: Fault Tolerance in Consul
|
||||
description: >-
|
||||
Fault tolerance is the ability of a system to continue operating without interruption
|
||||
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.
|
||||
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.
|
||||
---
|
||||
|
||||
# Improving Consul Resilience
|
||||
# Fault Tolerance
|
||||
|
||||
Fault tolerance is the ability of a system to continue operating without interruption
|
||||
despite the failure of one or more components.
|
||||
|
|
|
|||
|
|
@ -2,12 +2,10 @@
|
|||
layout: docs
|
||||
page_title: Consul Architecture
|
||||
description: >-
|
||||
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 page
|
||||
documents the system architecture.
|
||||
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.
|
||||
---
|
||||
|
||||
# Consul Architecture
|
||||
# Consul Internals Overview
|
||||
|
||||
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
|
||||
|
|
|
|||
|
|
@ -1,14 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Jepsen Testing
|
||||
page_title: Consistency Verification | Jepsen Testing Results
|
||||
description: >-
|
||||
Jepsen is a tool, written by Kyle Kingsbury, designed to test the partition
|
||||
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 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.
|
||||
---
|
||||
|
||||
# Jepsen Testing
|
||||
# Jepsen Testing Results
|
||||
|
||||
[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
|
||||
|
|
|
|||
|
|
@ -1,9 +1,8 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Service Discovery
|
||||
page_title: Service Discovery Explained
|
||||
description: >-
|
||||
Learn what service discovery is, its benefits, 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.
|
||||
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.
|
||||
---
|
||||
|
||||
# What is service discovery?
|
||||
|
|
|
|||
|
|
@ -1,9 +1,8 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Service Mesh
|
||||
page_title: Service Mesh Explained
|
||||
description: >-
|
||||
Learn what a service mesh is, its benefits, and how it works.
|
||||
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.
|
||||
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.
|
||||
---
|
||||
|
||||
# What is a service mesh?
|
||||
|
|
|
|||
|
|
@ -1,12 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Connect - Certificate Management
|
||||
page_title: Service Mesh Certificate Authority: AWS Certificate Manager
|
||||
description: >-
|
||||
Consul can be used with AWS Certificate Manager Private CA to manage and sign
|
||||
certificates.
|
||||
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.
|
||||
---
|
||||
|
||||
# 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
|
||||
Authority
|
||||
|
|
|
|||
|
|
@ -1,14 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Connect - Certificate Management
|
||||
page_title: Certificate Authority: Built-in Service Mesh CA
|
||||
description: >-
|
||||
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 root certificate and
|
||||
private key on Consul servers. It can also be configured with a custom
|
||||
certificate and private key if needed.
|
||||
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.
|
||||
---
|
||||
|
||||
# Built-In CA
|
||||
# Built-In Certificate Authority for Service Mesh
|
||||
|
||||
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
|
||||
|
|
|
|||
|
|
@ -1,10 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Connect - Certificate Management
|
||||
description: An overview of the Connect Certificate Authority mechanisms.
|
||||
page_title: Service Mesh Certificate Authority: Overview
|
||||
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
|
||||
servers using the configured CA (Certificate Authority) provider. A CA provider
|
||||
|
|
|
|||
|
|
@ -1,12 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Connect - Certificate Management
|
||||
page_title: Service Mesh Certificate Authority: Vault
|
||||
description: >-
|
||||
Consul can be used with Vault to manage and sign certificates. The Vault CA
|
||||
provider uses the Vault PKI secrets engine to generate and sign certificates.
|
||||
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.
|
||||
---
|
||||
|
||||
# Vault as a Connect CA
|
||||
# Vault as a Service Mesh Certificate Authority
|
||||
|
||||
Consul can be used with [Vault](https://www.vaultproject.io) to
|
||||
manage and sign certificates.
|
||||
|
|
|
|||
|
|
@ -1,13 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Discovery Chain
|
||||
page_title: Service Mesh Traffic Management: Discovery Chain
|
||||
description: >-
|
||||
The service discovery process can be modeled as a "discovery chain" which
|
||||
passes through three distinct stages: routing, splitting, and resolution. Each
|
||||
of these stages is controlled by a set of configuration entries.
|
||||
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.
|
||||
---
|
||||
|
||||
# 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,14 +1,13 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Connect - L7 Traffic Management
|
||||
page_title: Service Mesh Traffic Management: Overview
|
||||
description: >-
|
||||
Layer 7 traffic management allows operators to divide L7 traffic between
|
||||
different subsets of service instances when using Connect.
|
||||
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.
|
||||
---
|
||||
|
||||
-> **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
|
||||
different
|
||||
|
|
|
|||
|
|
@ -1,14 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Connect - Native Application Integration - Go
|
||||
page_title: Service Mesh Native App Integration: Go Apps
|
||||
description: >-
|
||||
We provide a library that makes it drop-in simple to integrate Connect with
|
||||
most Go applications. For most Go applications, Connect can be natively
|
||||
integrated in just a single line of code excluding imports and struct
|
||||
initialization.
|
||||
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.
|
||||
---
|
||||
|
||||
# Connect-Native Integration with Go
|
||||
# Service Mesh Native Integration for Go Applications
|
||||
|
||||
-> **Note:** When calling `ConnectAuthorize()` on incoming connections this library
|
||||
will return _deny_ if `Permissions` are defined on the matching intention.
|
||||
|
|
|
|||
|
|
@ -1,13 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Connect - Native Application Integration
|
||||
page_title: Service Mesh Native App Integration: Overview
|
||||
description: >-
|
||||
Applications can natively integrate with the Connect API to support accepting
|
||||
and establishing connections to other Connect services without the overhead of
|
||||
a proxy sidecar.
|
||||
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.
|
||||
---
|
||||
|
||||
# Connect-Native App Integration
|
||||
# Service Mesh Native App Integration Overview
|
||||
|
||||
~> **Note:** The Native App Integration does not support many of the Connect service
|
||||
mesh features, and is not under active development.
|
||||
|
|
|
|||
|
|
@ -1,12 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Connect - Observability
|
||||
description: |-
|
||||
This page documents the configurations necessary for L7 observability using
|
||||
Consul Connect.
|
||||
page_title: Service Mesh Observability: Overview
|
||||
description: >-
|
||||
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.
|
||||
---
|
||||
|
||||
# Observability
|
||||
# Service Mesh Observability Overview
|
||||
|
||||
In order to take advantage of Connect's L7 observability features you will need
|
||||
to:
|
||||
|
|
|
|||
|
|
@ -1,12 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Connect - UI Visualization
|
||||
description: |-
|
||||
This page describes how to set up and customize the Service Mesh Topology
|
||||
visualization in Consul's UI.
|
||||
page_title: Service Mesh Observability: UI Visualization
|
||||
description: >-
|
||||
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.
|
||||
---
|
||||
|
||||
# UI Visualization
|
||||
# Service Mesh Observability: UI Visualization
|
||||
|
||||
-> Coming here from "Configure metrics dashboard" or "Configure dashboard"? See [Configuring Dashboard URLs](#configuring-dashboard-urls).
|
||||
|
||||
|
|
|
|||
|
|
@ -1,13 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Connect - Proxy Registration
|
||||
page_title: Service Mesh Proxy Registration Overview
|
||||
description: >-
|
||||
To make connect aware of proxies you will need to register them as Consul
|
||||
services. This section describes the process and options for proxy
|
||||
registration.
|
||||
To make Consul aware of proxies in your service mesh, you must register them. Learn about methods for configuring and registering sidecar proxies.
|
||||
---
|
||||
|
||||
# Proxy Registration
|
||||
# Service Mesh Proxy Overview
|
||||
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -1,13 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Connect - Service Registration
|
||||
page_title: Register a Service Mesh Proxy Outside of a Service Registration
|
||||
description: >-
|
||||
A per-service proxy sidecar transparently handles inbound and outbound service
|
||||
connections. You can register these sidecars with reasonable defaults by nesting
|
||||
their definitions in the service definition.
|
||||
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.
|
||||
---
|
||||
|
||||
# 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.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Connect - Sidecar Service Registration
|
||||
description: |-
|
||||
Sidecar service registrations provide a convenient shorthand for registering a
|
||||
sidecar proxy inline with a regular service definition.
|
||||
page_title: Register a Service Mesh Proxy in a Service Registration
|
||||
description: >-
|
||||
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 Service Registration
|
||||
# Register a Service Mesh Proxy in a Service Registration
|
||||
|
||||
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
|
||||
|
|
|
|||
|
|
@ -1,12 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Internals
|
||||
page_title: Internals Overview
|
||||
description: >-
|
||||
This section covers some of the internals of Consul, such as the architecture,
|
||||
consensus and gossip protocols, and security model.
|
||||
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.
|
||||
---
|
||||
|
||||
# Consul Internals
|
||||
# Consul Internals Overview
|
||||
|
||||
This section covers some of the internals of Consul. Understanding the internals of Consul is necessary to successfully
|
||||
use it in production.
|
||||
|
|
|
|||
Loading…
Reference in New Issue