mirror of https://github.com/status-im/consul.git
501 lines
17 KiB
Plaintext
501 lines
17 KiB
Plaintext
---
|
|
layout: docs
|
|
page_title: Connect - 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.
|
|
---
|
|
|
|
# Proxy Service Registration
|
|
|
|
To function as a Connect proxy, proxies must be declared as a proxy types in
|
|
their service definitions, and provide information about the service they
|
|
represent.
|
|
|
|
To declare a service as a proxy, the service definition must contain
|
|
the following fields:
|
|
|
|
- `kind` `(string)` must be set to `connect-proxy`. This declares that the
|
|
service is a proxy type.
|
|
|
|
- `proxy.destination_service_name` `(string)` must be set to the service that
|
|
this proxy is representing. Note that this replaces `proxy_destination` in
|
|
versions 1.2.0 to 1.3.0.
|
|
|
|
~> **Deprecation Notice:** From version 1.2.0 to 1.3.0, proxy destination was
|
|
specified using `proxy_destination` at the top level. This will continue to work
|
|
until at least 1.5.0 but it's highly recommended to switch to using
|
|
`proxy.destination_service_name`.
|
|
|
|
- `port` `(int)` must be set so that other Connect services can discover the
|
|
exact address for connections. `address` is optional if the service is being
|
|
registered against an agent, since it'll inherit the node address.
|
|
|
|
Minimal Example:
|
|
|
|
```json
|
|
{
|
|
"name": "redis-proxy",
|
|
"kind": "connect-proxy",
|
|
"proxy": {
|
|
"destination_service_name": "redis"
|
|
},
|
|
"port": 8181
|
|
}
|
|
```
|
|
|
|
With this service registered, any Connect clients searching for a
|
|
Connect-capable endpoint for "redis" will find this proxy.
|
|
|
|
### Sidecar Proxy Fields
|
|
|
|
Most Connect proxies are deployed as "sidecars" which means they are co-located
|
|
with a single service instance which they represent and proxy all inbound
|
|
traffic to. In this case the following fields should also be set if you are deploying your proxy as a sidecar but defining it in its own service registration:
|
|
|
|
- `proxy.destination_service_id` `(string: <required>)` is set to the _id_
|
|
(and not the _name_ if they are different) of the specific service instance
|
|
that is being proxied. The proxied service is assumed to be registered on
|
|
the same agent although it's not strictly validated to allow for
|
|
un-coordinated registrations.
|
|
|
|
- `proxy.local_service_port` `(int: <required>)` must specify the port the
|
|
proxy should use to connect to the _local_ service instance.
|
|
|
|
- `proxy.local_service_address` `(string: "")` can be set to override the IP or
|
|
hostname the proxy should use to connect to the _local_ service. Defaults to
|
|
`127.0.0.1`.
|
|
|
|
### Complete Configuration Example
|
|
|
|
The following is a complete example showing all the options available when
|
|
registering a proxy instance.
|
|
|
|
```json
|
|
{
|
|
"name": "redis-proxy",
|
|
"kind": "connect-proxy",
|
|
"proxy": {
|
|
"destination_service_name": "redis",
|
|
"destination_service_id": "redis1",
|
|
"local_service_address": "127.0.0.1",
|
|
"local_service_port": 9090,
|
|
"local_service_socket_path": "/tmp/redis.sock",
|
|
"mode": "transparent",
|
|
"transparent_proxy": {},
|
|
"config": {},
|
|
"upstreams": [],
|
|
"mesh_gateway": {},
|
|
"expose": {}
|
|
},
|
|
"port": 8181
|
|
}
|
|
```
|
|
|
|
#### Proxy Parameters
|
|
|
|
- `destination_service_name` `(string: <required>)` - Specifies the _name_ of the
|
|
service this instance is proxying. Both side-car and centralized
|
|
load-balancing proxies must specify this. It is used during service
|
|
discovery to find the correct proxy instances to route to for a given service
|
|
name.
|
|
|
|
- `destination_service_id` `(string: "")` - Specifies the _ID_ of a single
|
|
specific service instance that this proxy is representing. This is only valid
|
|
for side-car style proxies that run on the same node. It is assumed that the
|
|
service instance is registered via the same Consul agent so the ID is unique
|
|
and has no node qualifier. This is useful to show in tooling which proxy
|
|
instance is a side-car for which application instance and will enable
|
|
fine-grained analysis of the metrics coming from the proxy.
|
|
|
|
- `local_service_address` `(string: "")` - Specifies the address a side-car
|
|
proxy should attempt to connect to the local application instance on.
|
|
Defaults to 127.0.0.1.
|
|
|
|
- `local_service_port` `(int: <optional>)` - Specifies the port a side-car
|
|
proxy should attempt to connect to the local application instance on.
|
|
Defaults to the port advertised by the service instance identified by
|
|
`destination_service_id` if it exists otherwise it may be empty in responses.
|
|
|
|
- `local_service_socket_path` - The path of a Unix domain socket to connect to the local application
|
|
instance. This is created by the application. This conflicts with `local_service_address`
|
|
and `local_service_port`. This is only supported when using Envoy for the proxy.
|
|
|
|
- `mode` `(string: "")` - One of \`direct\` or \`transparent\`. Added in v1.10.0.
|
|
- `"transparent"` - represents that inbound and outbound application traffic is being
|
|
captured and redirected through the proxy. This mode does not enable the traffic redirection
|
|
itself. Instead it signals Consul to configure Envoy as if traffic is already being redirected.
|
|
- `"direct"` - represents that the proxy's listeners must be dialed directly by the local
|
|
application and other proxies.
|
|
- `""` - Default mode. The default mode will be `"direct"` if no other configuration
|
|
applies. The order of precedence for setting the mode is
|
|
1. Proxy Service's `Proxy` configuration
|
|
2. The `service-defaults` configuration for the service.
|
|
3. The `global` `proxy-defaults`.
|
|
|
|
- `transparent_proxy` `(object: {})` - Specifies the configuration specific to proxies in `transparent` mode.
|
|
The format is defined in the [Transparent Proxy Configuration Reference](#transparent-proxy-configuration-reference).
|
|
Added in v1.10.0.
|
|
|
|
- `config` `(object: {})` - Specifies opaque config JSON that will be
|
|
stored and returned along with the service instance from future API calls.
|
|
|
|
- `upstreams` `(array<Upstream>: [])` - Specifies the upstream services
|
|
this proxy should create listeners for. The format is defined in
|
|
[Upstream Configuration Reference](#upstream-configuration-reference).
|
|
|
|
- `mesh_gateway` `(object: {})` - Specifies the mesh gateway configuration
|
|
for this proxy. The format is defined in the [Mesh Gateway Configuration Reference](#mesh-gateway-configuration-reference).
|
|
|
|
- `expose` `(object: {})` - Specifies the configuration to expose HTTP paths through this proxy.
|
|
The format is defined in the [Expose Paths Configuration Reference](#expose-paths-configuration-reference),
|
|
and is only compatible with an Envoy proxy.
|
|
|
|
### Upstream Configuration Reference
|
|
|
|
The following examples show all possible upstream configuration parameters.
|
|
|
|
-> Note that `snake_case` is used here as it works in both [config file and API
|
|
registrations](/docs/agent/services#service-definition-parameter-case).
|
|
|
|
Upstreams support multiple destination types. Both examples are shown below
|
|
followed by documentation for each attribute.
|
|
|
|
#### Service Destination
|
|
|
|
```json
|
|
{
|
|
"destination_type": "service",
|
|
"destination_name": "redis",
|
|
"datacenter": "dc1",
|
|
"local_bind_address": "127.0.0.1",
|
|
"local_bind_port": 1234,
|
|
"local_bind_socket_path": "/tmp/redis_5678.sock",
|
|
"local_bind_socket_mode": "0700",
|
|
"config": {},
|
|
"mesh_gateway": {
|
|
"mode": "local"
|
|
}
|
|
},
|
|
```
|
|
|
|
#### Prepared Query Destination
|
|
|
|
```json
|
|
{
|
|
"destination_type": "prepared_query",
|
|
"destination_name": "database",
|
|
"local_bind_address": "127.0.0.1",
|
|
"local_bind_port": 1234,
|
|
"config": {}
|
|
},
|
|
```
|
|
|
|
- `destination_name` `(string: <required>)` - Specifies the name of the service
|
|
or prepared query to route connect to. The prepared query should be the name
|
|
or the ID of the prepared query.
|
|
- `destination_namespace` `(string: "")` - <EnterpriseAlert inline />
|
|
Specifies the namespace of the upstream service.
|
|
- `local_bind_port` `(int: <required>)` - Specifies the port to bind a local
|
|
listener to for the application to make outbound connections to this upstream.
|
|
- `local_bind_address` `(string: "")` - Specifies the address to bind a
|
|
local listener to for the application to make outbound connections to this
|
|
upstream. Defaults to `127.0.0.1`.
|
|
- `local_bind_socket_path` `(string: "")` - Specifies the path at which to bind a Unix
|
|
domain socket listener for the application to make outbound connections to
|
|
this upstream. This conflicts with specifying the local_bind_port
|
|
or local_bind_address. This is only supported when using Envoy as a proxy.
|
|
- `local_bind_socket_mode` `(string: "")` - Specifies the (optional) Unix octal
|
|
file permissions to use for the socket.
|
|
- `destination_type` `(string: "")` - Specifies the type of discovery
|
|
query to use to find an instance to connect to. Valid values are `service` or
|
|
`prepared_query`. Defaults to `service`.
|
|
- `datacenter` `(string: "")` - Specifies the datacenter to issue the
|
|
discovery query to. Defaults to the local datacenter.
|
|
- `config` `(object: {})` - Specifies opaque configuration options that
|
|
will be provided to the proxy instance for this specific upstream. Can contain
|
|
any valid JSON object. This might be used to configure proxy-specific features
|
|
like timeouts or retries for the given upstream. See the [built-in proxy
|
|
configuration
|
|
reference](/docs/connect/proxies/built-in#proxy-upstream-config-key-reference) for
|
|
options available when using the built-in proxy. If using Envoy as a proxy,
|
|
see [Envoy configuration
|
|
reference](/docs/connect/proxies/envoy#proxy-upstream-config-options)
|
|
- `mesh_gateway` `(object: {})` - Specifies the mesh gateway configuration
|
|
for this proxy. The format is defined in the [Mesh Gateway Configuration Reference](#mesh-gateway-configuration-reference).
|
|
|
|
### Transparent Proxy Configuration Reference
|
|
|
|
The following examples show additional configuration for transparent proxies.
|
|
|
|
Added in v1.10.0.
|
|
|
|
-> Note that `snake_case` is used here as it works in both [config file and API
|
|
registrations](/docs/agent/services#service-definition-parameter-case).
|
|
|
|
#### Configure a proxy listener for outbound traffic on port 22500
|
|
|
|
```json
|
|
{
|
|
"outbound_listener_port": 22500,
|
|
"dialed_directly": true
|
|
}
|
|
```
|
|
|
|
- `outbound_listener_port` `(int: 15001)` - The port the proxy should listen on for outbound traffic.
|
|
This must be the port where outbound application traffic is captured and redirected to.
|
|
- `dialed_directly` `(bool: false)` - Determines whether this proxy instance's IP address can be dialed
|
|
directly by transparent proxies. Typically transparent proxies dial upstreams using the "virtual"
|
|
tagged address, which load balances across instances. Dialing individual instances can be helpful
|
|
in cases like stateful services such as a database cluster with a leader.
|
|
|
|
~> **Note:** Dynamic routing rules such as failovers and redirects do not apply to services dialed directly.
|
|
Additionally, the connection is proxied using a TCP proxy with a connection timeout of 5 seconds.
|
|
|
|
### Mesh Gateway Configuration Reference
|
|
|
|
The following examples show all possible mesh gateway configurations.
|
|
|
|
-> Note that `snake_case` is used here as it works in both [config file and API
|
|
registrations](/docs/agent/services#service-definition-parameter-case).
|
|
|
|
#### Using a Local/Egress Gateway in the Local Datacenter
|
|
|
|
```json
|
|
{
|
|
"mode": "local"
|
|
}
|
|
```
|
|
|
|
#### Direct to a Remote/Ingress in a Remote Datacenter
|
|
|
|
```json
|
|
{
|
|
"mode": "remote"
|
|
}
|
|
```
|
|
|
|
#### Prevent Using a Mesh Gateway
|
|
|
|
```json
|
|
{
|
|
"mode": "none"
|
|
}
|
|
```
|
|
|
|
#### Default Mesh Gateway Mode
|
|
|
|
```json
|
|
{
|
|
"mode": ""
|
|
}
|
|
```
|
|
|
|
- `mode` `(string: "")` - This defines the mode of operation for how
|
|
upstreams with a remote destination datacenter get resolved.
|
|
- `"local"` - Mesh gateway services in the local datacenter will be used
|
|
as the next-hop destination for the upstream connection.
|
|
- `"remote"` - Mesh gateway services in the remote/target datacenter will
|
|
be used as the next-hop destination for the upstream connection.
|
|
- `"none"` - No mesh gateway services will be used and the next-hop destination
|
|
for the connection will be directly to the final service(s).
|
|
- `""` - Default mode. The default mode will be `"none"` if no other configuration
|
|
enables them. The order of precedence for setting the mode is
|
|
1. Upstream
|
|
2. Proxy Service's `Proxy` configuration
|
|
3. The `service-defaults` configuration for the service.
|
|
4. The `global` `proxy-defaults`.
|
|
|
|
### Expose Paths Configuration Reference
|
|
|
|
The following examples show possible configurations to expose HTTP paths through Envoy.
|
|
|
|
Exposing paths through Envoy enables a service to protect itself by only listening on localhost, while still allowing
|
|
non-Connect-enabled applications to contact an HTTP endpoint.
|
|
Some examples include: exposing a `/metrics` path for Prometheus or `/healthz` for kubelet liveness checks.
|
|
|
|
-> Note that `snake_case` is used here as it works in both [config file and API
|
|
registrations](/docs/agent/services#service-definition-parameter-case).
|
|
|
|
#### Expose listeners in Envoy for HTTP and GRPC checks registered with the local Consul agent
|
|
|
|
```json
|
|
{
|
|
"expose": {
|
|
"checks": true
|
|
}
|
|
}
|
|
```
|
|
|
|
#### Expose an HTTP listener in Envoy at port 21500 that routes to an HTTP server listening at port 8080
|
|
|
|
```json
|
|
{
|
|
"expose": {
|
|
"paths": [
|
|
{
|
|
"path": "/healthz",
|
|
"local_path_port": 8080,
|
|
"listener_port": 21500
|
|
}
|
|
]
|
|
}
|
|
}
|
|
```
|
|
|
|
#### Expose an HTTP2 listener in Envoy at port 21501 that routes to a gRPC server listening at port 9090
|
|
|
|
```json
|
|
{
|
|
"expose": {
|
|
"paths": [
|
|
{
|
|
"path": "/grpc.health.v1.Health/Check",
|
|
"protocol": "http2",
|
|
"local_path_port": 9090,
|
|
"listener_port": 21501
|
|
}
|
|
]
|
|
}
|
|
}
|
|
```
|
|
|
|
- `checks` `(bool: false)` - If enabled, all HTTP and gRPC checks registered with the agent are exposed through Envoy.
|
|
Envoy will expose listeners for these checks and will only accept connections originating from localhost or Consul's
|
|
[advertise address](/docs/agent/options#advertise). The port for these listeners are dynamically allocated from
|
|
[expose_min_port](/docs/agent/options#expose_min_port) to [expose_max_port](/docs/agent/options#expose_max_port).
|
|
This flag is useful when a Consul client cannot reach registered services over localhost. One example is when running
|
|
Consul on Kubernetes, and Consul agents run in their own pods.
|
|
- `paths` `array<Path>: []` - A list of paths to expose through Envoy.
|
|
- `path` `(string: "")` - The HTTP path to expose. The path must be prefixed by a slash. ie: `/metrics`.
|
|
- `local_path_port` `(int: 0)` - The port where the local service is listening for connections to the path.
|
|
- `listener_port` `(int: 0)` - The port where the proxy will listen for connections. This port must be available for
|
|
the listener to be set up. If the port is not free then Envoy will not expose a listener for the path,
|
|
but the proxy registration will not fail.
|
|
- `protocol` `(string: "http")` - Sets the protocol of the listener. One of `http` or `http2`. For gRPC use `http2`.
|
|
|
|
### Unix Domain Sockets
|
|
|
|
The following examples show additional configuration for Unix domain sockets.
|
|
|
|
Added in v1.10.0.
|
|
|
|
To connect to a service via local Unix Domain Socket instead of a
|
|
port, add `local_bind_socket_path` and optionally `local_bind_socket_mode`
|
|
to the upstream config for a service:
|
|
|
|
<Tabs>
|
|
<Tab heading="HCL">
|
|
|
|
```hcl
|
|
upstreams = [
|
|
{
|
|
destination_name = "service-1"
|
|
local_bind_socket_path = "/tmp/socket_service_1"
|
|
local_bind_socket_mode = "0700"
|
|
}
|
|
]
|
|
```
|
|
|
|
</Tab>
|
|
<Tab heading="JSON">
|
|
|
|
```json
|
|
"upstreams": [
|
|
{
|
|
"destination_name": "service-1",
|
|
"local_bind_socket_path": "/tmp/socket_service_1",
|
|
"local_bind_socket_mode": "0700"
|
|
}
|
|
]
|
|
```
|
|
|
|
</Tab>
|
|
</Tabs>
|
|
|
|
This will cause Envoy to create a socket with the path and mode
|
|
provided, and connect that to service-1.
|
|
|
|
The mode field is optional, and if omitted will use the default mode
|
|
for Envoy. This is not applicable for abstract sockets. See the
|
|
[Envoy documentation](https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/core/v3/address.proto#envoy-v3-api-msg-config-core-v3-pipe)
|
|
for details.
|
|
|
|
-> These options conflict with the `local_bind_socket_port` and
|
|
`local_bind_socket_address` options. For a given upstream the proxy can bind either to an IP port or
|
|
a Unix socket, but not both.
|
|
|
|
Similarly to expose a service listening on a Unix Domain socket to the service
|
|
mesh, use either the `socket_path` field in the service definition or the
|
|
`local_service_socket_path` field in the proxy definition. These
|
|
fields are analogous to the `port` and `service_port` fields in their
|
|
respective locations.
|
|
<Tabs>
|
|
<Tab heading="HCL">
|
|
|
|
```hcl
|
|
services {
|
|
name = "service-2"
|
|
socket_path = "/tmp/socket_service_2"
|
|
}
|
|
```
|
|
|
|
</Tab>
|
|
<Tab heading="JSON">
|
|
|
|
```json
|
|
"services": {
|
|
"name": "service-2",
|
|
"socket_path": "/tmp/socket_service_2"
|
|
}
|
|
```
|
|
|
|
</Tab>
|
|
</Tabs>
|
|
Or in the proxy definition:
|
|
<Tabs>
|
|
<Tab heading="HCL">
|
|
|
|
```hcl
|
|
services {
|
|
name = "socket_service_2"
|
|
connect {
|
|
sidecar_service {
|
|
proxy {
|
|
name = "service-2"
|
|
local_service_socket_path = "/tmp/socket_service_2"
|
|
...
|
|
}
|
|
}
|
|
}
|
|
}
|
|
```
|
|
|
|
</Tab>
|
|
<Tab heading="JSON">
|
|
|
|
```json
|
|
"services": {
|
|
"name": "socket_service_2",
|
|
"connect": {
|
|
"sidecar_service": {
|
|
"proxy": {
|
|
"name": "service-2",
|
|
"local_service_socket_path": "/tmp/socket_service_2"
|
|
...
|
|
}
|
|
}
|
|
}
|
|
}
|
|
```
|
|
|
|
</Tab>
|
|
</Tabs>
|
|
|
|
There is no mode field since the service is expected to create the
|
|
socket it is listening on, not the Envoy proxy.
|
|
Again, the `socket_path` and `local_service_socket_path` fields conflict
|
|
with `address`/`port` and `local_service_address`/`local_service_port`
|
|
configuration options.
|