c0780ef3e9
* converted main services page to services overview page * set up services usage dirs * added Define Services usage page * converted health checks everything page to Define Health Checks usage page * added Register Services and Nodes usage page * converted Query with DNS to Discover Services and Nodes Overview page * added Configure DNS Behavior usage page * added Enable Static DNS Lookups usage page * added the Enable Dynamic Queries DNS Queries usage page * added the Configuration dir and overview page - may not need the overview, tho * fixed the nav from previous commit * added the Services Configuration Reference page * added Health Checks Configuration Reference page * updated service defaults configuraiton entry to new configuration ref format * fixed some bad links found by checker * more bad links found by checker * another bad link found by checker * converted main services page to services overview page * set up services usage dirs * added Define Services usage page * converted health checks everything page to Define Health Checks usage page * added Register Services and Nodes usage page * converted Query with DNS to Discover Services and Nodes Overview page * added Configure DNS Behavior usage page * added Enable Static DNS Lookups usage page * added the Enable Dynamic Queries DNS Queries usage page * added the Configuration dir and overview page - may not need the overview, tho * fixed the nav from previous commit * added the Services Configuration Reference page * added Health Checks Configuration Reference page * updated service defaults configuraiton entry to new configuration ref format * fixed some bad links found by checker * more bad links found by checker * another bad link found by checker * fixed cross-links between new topics * updated links to the new services pages * fixed bad links in scale file * tweaks to titles and phrasing * fixed typo in checks.mdx * started updating the conf ref to latest template * update SD conf ref to match latest CT standard * Apply suggestions from code review Co-authored-by: Eddie Rowe <74205376+eddie-rowe@users.noreply.github.com> * remove previous version of the checks page * fixed cross-links * Apply suggestions from code review Co-authored-by: Eddie Rowe <74205376+eddie-rowe@users.noreply.github.com> --------- Co-authored-by: Eddie Rowe <74205376+eddie-rowe@users.noreply.github.com>
105 lines
4.9 KiB
Plaintext
105 lines
4.9 KiB
Plaintext
---
|
||
layout: docs
|
||
page_title: Service Mesh Configuration - Overview
|
||
description: >-
|
||
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.
|
||
---
|
||
|
||
# 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.
|
||
All other configurations are optional and have defaults suitable for many environments.
|
||
|
||
The terms _Consul Connect_ and _Consul service mesh_ are used interchangeably throughout this documentation.
|
||
|
||
## Agent configuration
|
||
|
||
Begin by enabling Connect for your Consul
|
||
cluster. By default, Connect is disabled. Enabling Connect requires changing
|
||
the configuration of only your Consul _servers_ (not client agents). To enable
|
||
Connect, add the following to a new or existing
|
||
[server configuration file](/consul/docs/agent/config/config-files). In an existing cluster, this configuration change requires a Consul server restart, which you can perform one server at a time to maintain availability. In HCL:
|
||
|
||
|
||
<CodeTabs heading="Enable Consul service mesh" tabs={[ "HCL", "JSON" ]}>
|
||
|
||
```hcl
|
||
connect {
|
||
enabled = true
|
||
}
|
||
```
|
||
|
||
```json
|
||
"connect": {
|
||
"enabled": true
|
||
}
|
||
```
|
||
</CodeTabs>
|
||
|
||
This will enable Connect and configure your Consul cluster to use the
|
||
built-in certificate authority for creating and managing certificates.
|
||
You may also configure Consul to use an external
|
||
[certificate management system](/consul/docs/connect/ca), such as
|
||
[Vault](https://www.vaultproject.io/).
|
||
|
||
Services and proxies may always register with Connect settings, but they will
|
||
fail to retrieve or verify any TLS certificates. This causes all Connect-based
|
||
connection attempts to fail until Connect is enabled on the server agents.
|
||
|
||
Other optional Connect configurations that you can set in the server
|
||
configuration file include:
|
||
|
||
- [certificate authority settings](/consul/docs/agent/config/config-files#connect)
|
||
- [token replication](/consul/docs/agent/config/config-files#acl_tokens_replication)
|
||
- [dev mode](/consul/docs/agent/config/cli-flags#_dev)
|
||
- [server host name verification](/consul/docs/agent/config/config-files#tls_internal_rpc_verify_server_hostname)
|
||
|
||
If you would like to use Envoy as your Connect proxy you will need to [enable
|
||
gRPC](/consul/docs/agent/config/config-files#grpc_port).
|
||
|
||
Additionally if you plan on using the observability features of Connect, it can
|
||
be convenient to configure your proxies and services using [configuration
|
||
entries](/consul/docs/agent/config-entries) which you can interact with using the
|
||
CLI or API, or by creating configuration entry files. You will want to enable
|
||
[centralized service
|
||
configuration](/consul/docs/agent/config/config-files#enable_central_service_config) on
|
||
clients, which allows each service's proxy configuration to be managed centrally
|
||
via API.
|
||
|
||
!> **Security note:** Enabling Connect is enough to try the feature but doesn't
|
||
automatically ensure complete security. Please read the [Connect production
|
||
tutorial](/consul/tutorials/developer-mesh/service-mesh-production-checklist) to understand the additional steps
|
||
needed for a secure deployment.
|
||
|
||
## Centralized proxy and service configuration
|
||
|
||
If your network contains many instances of the same service and many colocated sidecar proxies, you can specify global settings for proxies or services in [Configuration Entries](/consul/docs/agent/config-entries). You can override the centralized configurations for individual proxy instances in their
|
||
[sidecar service definitions](/consul/docs/connect/registration/sidecar-service),
|
||
and the default protocols for service instances in their [service
|
||
definitions](/consul/docs/services/usage/define-services).
|
||
|
||
## Schedulers
|
||
|
||
Consul Connect is especially useful if you are using an orchestrator like Nomad
|
||
or Kubernetes, because these orchestrators can deploy thousands of service instances
|
||
which frequently move hosts. Sidecars for each service can be configured through
|
||
these schedulers, and in some cases they can automate Consul configuration,
|
||
sidecar deployment, and service registration.
|
||
|
||
### Nomad
|
||
|
||
Connect can be used with Nomad to provide secure service-to-service
|
||
communication between Nomad jobs and task groups. The ability to use the dynamic
|
||
port feature of Nomad makes Connect particularly easy to use. Learn about how to
|
||
configure Connect on Nomad by reading the
|
||
[integration documentation](/consul/docs/connect/nomad).
|
||
|
||
### Kubernetes
|
||
|
||
The Consul Helm chart can automate much of Consul Connect's configuration, and
|
||
makes it easy to automatically inject Envoy sidecars into new pods when they are
|
||
deployed. Learn about the [Helm chart](/consul/docs/k8s/helm) in general,
|
||
or if you are already familiar with it, check out its
|
||
[connect specific configurations](/consul/docs/k8s/connect).
|