mirror of https://github.com/status-im/consul.git
/docs/connect
This commit is contained in:
boruszak
parent
dc66e10e71
commit
653cfb431d
|
|
@ -1,13 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Connect - Configuration
|
||||
page_title: Service Mesh Configuration: Overview
|
||||
description: >-
|
||||
A Connect-aware proxy enables unmodified applications to use Connect. A
|
||||
per-service proxy sidecar transparently handles inbound and outbound service
|
||||
connections, automatically wrapping and verifying TLS connections.
|
||||
Consul's service mesh must be enabled before use. Learn how to enable service mesh in agent configurations, the features you can configure, and how schedulers like Kubernetes and Nomad impact configuration. Consul Connect is another name for Consul’s service mesh functions.
|
||||
---
|
||||
|
||||
# Service Mesh Configuration
|
||||
# Service Mesh Configuration Overview
|
||||
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -1,9 +1,8 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: How Connect Works
|
||||
page_title: Service Mesh: How it Works
|
||||
description: >-
|
||||
This page details the internals of Consul Connect: mutual TLS, agent caching
|
||||
and performance, intention and certificate authority replication.
|
||||
Consul's service mesh uses mutual TLS certificates and intentions to identify and authorize agent communication across datacenters. Learn how mTLS, agents, and intentions work together in the service mesh, also called Consul Connect.
|
||||
---
|
||||
|
||||
# How Service Mesh Works
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Connectivity Tasks
|
||||
page_title: Gateway Types
|
||||
description: >-
|
||||
Tasks related to connectivity into, out of, and between Consul service meshes.
|
||||
Mesh, ingress, and terminating 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
|
||||
Consul service mesh then these features will not be relevant to your task.
|
||||
|
|
|
|||
|
|
@ -1,15 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Connect - Development and Debugging
|
||||
page_title: Service Mesh Debugging
|
||||
description: >-
|
||||
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 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).
|
||||
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.
|
||||
---
|
||||
|
||||
# Developing and Debugging Connect Services
|
||||
# Service Mesh 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
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Distributed Tracing
|
||||
page_title: Service Mesh Distributed Tracing
|
||||
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 implement tracing libraries in your application and configure Consul to use it.
|
||||
---
|
||||
|
||||
# Distributed Tracing
|
||||
|
|
|
|||
|
|
@ -1,9 +1,8 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Service Mesh
|
||||
description: |-
|
||||
Consul Connect provides service-to-service connection authorization and
|
||||
encryption using mutual TLS.
|
||||
page_title: Service Mesh on Consul
|
||||
description: >-
|
||||
Consul’s service mesh makes applications secure and observable through encrypted communication, identity-based mTLS authorization, and sidecar proxies. Learn how Consul’s service mesh works and get started on VMs or Kubernetes.
|
||||
---
|
||||
|
||||
# Consul Service Mesh
|
||||
|
|
|
|||
|
|
@ -1,10 +1,8 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Service-to-service permissions - Intentions (Legacy Mode)
|
||||
page_title: Intentions (Legacy Mode)
|
||||
description: >-
|
||||
Intentions define access control for services via Connect and are used to
|
||||
control which services may establish connections. Intentions can be managed
|
||||
via the API, CLI, or UI.
|
||||
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.
|
||||
---
|
||||
|
||||
# Intentions in Legacy Mode
|
||||
|
|
|
|||
|
|
@ -1,12 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Service-to-service permissions - Intentions
|
||||
page_title: Service Mesh Intentions
|
||||
description: >-
|
||||
Intentions define access control for services via Connect and are used to
|
||||
control which services may establish connections or make requests.
|
||||
Intentions define communication access in the service mesh through inbound and outbound connection permissions between microservices. Learn about configuration basics, wildcard intentions, precedence and match order, and protecting intention management with ACLs.
|
||||
---
|
||||
|
||||
# Intentions
|
||||
# Service Mesh Intentions
|
||||
|
||||
-> **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
|
||||
|
|
|
|||
|
|
@ -1,13 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Connect - Nomad
|
||||
page_title: Sevice Mesh: Nomad Integration
|
||||
description: >-
|
||||
Connect can be used with [Nomad](https://www.nomadproject.io) to provide
|
||||
secure service-to-service communication between Nomad jobs. The ability to use
|
||||
the dynamic port feature of Nomad makes Connect particularly easy to use.
|
||||
Consul's service mesh can be applied to Nomad's scheduler and orchestration functions to provide secure communication for Nomad jobs and task groups. Use the guide and reference documentation to learn more.
|
||||
---
|
||||
|
||||
# Connect on Nomad
|
||||
# Consul and Nomad Integration
|
||||
|
||||
Consul Connect can be used with [Nomad](https://www.nomadproject.io) to provide
|
||||
secure service-to-service communication between Nomad jobs and task groups.
|
||||
|
|
|
|||
|
|
@ -1,13 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Connect - Security
|
||||
description: |-
|
||||
Connect enables secure service-to-service communication over mutual TLS. This
|
||||
provides both in-transit data encryption as well as authorization. This page
|
||||
will document how to secure Connect.
|
||||
page_title: Service Mesh Security: Best Practices
|
||||
description: >-
|
||||
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.
|
||||
---
|
||||
|
||||
# Connect Security
|
||||
# Best Practices for Service Mesh Security
|
||||
|
||||
Connect enables secure service-to-service communication over mutual TLS. This
|
||||
provides both in-transit data encryption as well as authorization. This page
|
||||
|
|
|
|||
|
|
@ -1,13 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Connect - Transparent Proxy
|
||||
sidebar_title: Transparent Proxy
|
||||
description: |-
|
||||
Transparent proxy is used to direct inbound and outbound traffic to services via the Envoy proxy and configure
|
||||
upstreams via intentions.
|
||||
page_title: Transparent Proxy | Service Mesh
|
||||
description: >-
|
||||
Learn how transparent proxies enable Consul on Kubernetes to direct inbound and outbound traffic through the service mesh. Use a transparent proxy to increase application security without configuring individual services and intentions.
|
||||
---
|
||||
|
||||
# Transparent Proxy
|
||||
# Transparent Proxies in a Service Mesh
|
||||
|
||||
Transparent proxy allows applications to communicate through the mesh without changing their configuration.
|
||||
Transparent proxy also hardens application security by preventing direct inbound connections that bypass the mesh.
|
||||
|
|
|
|||
Loading…
Reference in New Issue