github.com/KyaXTeam/consul@v1.4.5/website/source/docs/connect/proxies/sidecar-service.md (about)

     1  ---
     2  layout: "docs"
     3  page_title: "Connect - Sidecar Service Registration"
     4  sidebar_current: "docs-connect-proxies-sidecar-service"
     5  description: |-
     6    Sidecar service registrations provide a convenient shorthand for registering a
     7    sidecar proxy inline with a regular service definition.
     8  ---
     9  
    10  # Sidecar Service Registration
    11  
    12  Connect proxies are typically deployed as "sidecars" that run on the same node
    13  as the single service instance that they handle traffic for. They might be on
    14  the same VM or running as a separate container in the same network namespace.
    15  
    16  To simplify the configuration experience when deploying a sidecar for a service
    17  instance, Consul 1.3 introduced a new field in the Connect block of the [service
    18  definition](/docs/agent/services.html).
    19  
    20  The `connect.sidecar_service` field is a complete nested service definition on
    21  which almost any regular service definition field can be set. The exceptions are
    22  [noted below](#limitations). If used, the service definition is treated
    23  identically to another top-level service definition. The value of the nested
    24  definition is that _all fields are optional_ with some opinionated defaults
    25  applied that make setting up a sidecar proxy much simpler.
    26  
    27  ## Minimal Example
    28  
    29  To register a service instance with a sidecar, all that's needed is:
    30  
    31  ```json
    32  {
    33    "name": "web",
    34    "port": 8080,
    35    "connect": { "sidecar_service": {} }
    36  }
    37  ```
    38  
    39  This will register the `web` service as normal, but will also register another
    40  [proxy service](/docs/connect/proxies.html) with defaults values used.
    41  
    42  The above expands out to be equivalent to the following explicit service
    43  definitions:
    44  
    45  ```json
    46  {
    47    "name": "web",
    48    "port": 8080,
    49  }
    50  {
    51    "name": "web-sidecar-proxy",
    52    "port": 20000,
    53    "kind": "connect-proxy",
    54    "checks": [
    55      {
    56        "Name": "Connect Sidecar Listening",
    57        "TCP": "127.0.0.1:20000",
    58        "Interval": "10s"
    59      },
    60      {
    61        "name": "Connect Sidecar Aliasing web",
    62        "alias_service": "web"
    63      }
    64    ],
    65    "proxy": {
    66      "destination_service_name": "web",
    67      "destination_service_id": "web",
    68      "local_service_address": "127.0.0.1",
    69      "local_service_port": 8080,
    70    }
    71  }
    72  ```
    73  
    74  Details on how the defaults are determined are [documented
    75  below](#sidecar-service-defaults).
    76  
    77  -> **Note:** Sidecar service registrations are only a shorthand for registering
    78  multiple services. Consul will not start up or manage the actual proxy processes
    79  for you.
    80  
    81  ## Overridden Example
    82  
    83  The following example shows a service definition where some fields are
    84  overridden to customize the proxy configuration.
    85  
    86  ```json
    87  {
    88    "name": "web",
    89    "port": 8080,
    90    "connect": {
    91      "sidecar_service": {
    92        "proxy": {
    93          "upstreams": [
    94            {
    95              "destination_name": "db",
    96              "local_bind_port": 9191
    97            }
    98          ],
    99          "config": {
   100            "handshake_timeout_ms": 1000
   101          }
   102        }
   103      }
   104    }
   105  }
   106  ```
   107  
   108  This example customizes the [proxy
   109  upstreams](/docs/connect/proxies.html#upstream-configuration-reference)
   110  and some [built-in proxy
   111  configuration](/docs/connect/configuration.html#built-in-proxy-options).
   112  
   113  ## Sidecar Service Defaults
   114  
   115  The following fields are set by default on a sidecar service registration. With
   116  [the exceptions noted](#limitations) any field may be overridden explicitly in
   117  the `connect.sidecar_service` definition to customize the proxy registration.
   118  The "parent" service refers to the service definition that embeds the sidecar
   119  proxy.
   120  
   121   - `id` - ID defaults to being `<parent-service-id>-sidecar-proxy`. This can't
   122     be overridden as it is used to [manage the lifecycle](#lifecycle) of the
   123     registration.
   124   - `name` - Defaults to being `<parent-service-name>-sidecar-proxy`.
   125   - `tags` - Defaults to the tags of the parent service.
   126   - `meta` - Defaults to the service metadata of the parent service.
   127   - `port` - Defaults to being auto-assigned from a [configurable
   128     range](/docs/agent/options.html#sidecar_min_port) that is
   129     by default `[21000, 21255]`.
   130   - `kind` - Defaults to `connect-proxy`. This can't be overridden currently.
   131   - `check`, `checks` - By default we add a TCP check on the local address and
   132     port for the proxy, and a [service alias
   133     check](/docs/agent/checks.html#alias) for the parent service. If either
   134     `check` or `checks` fields are set, only the provided checks are registered.
   135   - `proxy.destination_service_name` - Defaults to the parent service name.
   136   - `proxy.destination_service_id` - Defaults to the parent service ID.
   137   - `proxy.local_service_address` - Defaults to `127.0.0.1`.
   138   - `proxy.local_service_port` - Defaults to the parent service port.
   139  
   140  ## Limitations
   141  
   142  Almost all fields in a [service definition](/docs/agent/services.html) may be
   143  set on the `connect.sidecar_service` except for the following:
   144  
   145   - `id` - Sidecar services get an ID assigned and it is an error to override
   146     this. This ensures the agent can correctly de-register the sidecar service
   147     later when the parent service is removed.
   148   - `kind` - Kind defaults to `connect-proxy` and there is currently no way to
   149     unset this to make the registration be for a regular non-connect-proxy
   150     service.
   151   - `connect.sidecar_service` - Service definitions can't be nested recursively.
   152   - `connect.proxy` - (Deprecated) [Managed
   153     proxies](/docs/connect/proxies/managed-deprecated.html) can't be defined on a
   154     sidecar.
   155   - `connect.native` - Currently the `kind` is fixed to `connect-proxy` and it's
   156     an error to register a `connect-proxy` that is also Connect-native.
   157  
   158  ## Lifecycle
   159  
   160  Sidecar service registration is mostly a configuration syntax helper to avoid
   161  adding lots of boiler plate for basic sidecar options, however the agent does
   162  have some specific behavior around their lifecycle that makes them easier to
   163  work with.
   164  
   165  The agent fixes the ID of the sidecar service to be based on the parent
   166  service's ID. This enables the following behavior.
   167  
   168   - A service instance can _only ever have one_ sidecar service registered.
   169   - When re-registering via API or reloading from configuration file:
   170     - If something changes in the nested sidecar service definition, the change
   171       will _update_ the current sidecar registration instead of creating a new
   172       one.
   173     - If a service registration removes the nested `sidecar_service` then the
   174       previously registered sidecar for that service will be deregistered
   175       automatically.
   176   - When reloading the configuration files, if a service definition changes it's
   177     ID, then a new service instance _and_ a new sidecar instance will be
   178     registered. The old ones will be removed since they are no longer found in
   179     the config files.
   180