Sidecar Service Registration

    To simplify the configuration experience when deploying a sidecar for a service instance, Consul 1.3 introduced a new field in the Connect block of the service definition.

    To deploy a service and sidecar proxy locally, complete the .

    The field is a complete nested service definition on which almost any regular service definition field can be set. The exceptions are noted below. If used, the service definition is treated identically to another top-level service definition. The value of the nested definition is that all fields are optional with some opinionated defaults applied that make setting up a sidecar proxy much simpler.

    To register a service instance with a sidecar, all that’s needed is:

    The above expands out to be equivalent to the following explicit service definitions:

    Details on how the defaults are determined are .

    Note: Sidecar service registrations are only a shorthand for registering multiple services. Consul will not start up or manage the actual proxy processes for you.

    The following example shows a service definition where some fields are overridden to customize the proxy configuration.

    The following fields are set by default on a sidecar service registration. With the exceptions noted any field may be overridden explicitly in the connect.sidecar_service definition to customize the proxy registration. The “parent” service refers to the service definition that embeds the sidecar proxy.

    • - ID defaults to being <parent-service-id>-sidecar-proxy. This can’t be overridden as it is used to manage the lifecycle of the registration.
    • - Defaults to being <parent-service-name>-sidecar-proxy.
    • tags - Defaults to the tags of the parent service.
    • - Defaults to being auto-assigned from a configurable range specified by sidecar_min_port and .
    • kind - Defaults to . This can’t be overridden currently.
    • , checks - By default we add a TCP check on the local address and port for the proxy, and a service alias check for the parent service. If either check or checks fields are set, only the provided checks are registered.
    • - Defaults to the parent service name.
    • proxy.destination_service_id - Defaults to the parent service ID.
    • - Defaults to 127.0.0.1.
    • proxy.local_service_port - Defaults to the parent service port.

    Almost all fields in a may be set on the except for the following:

    • id - Sidecar services get an ID assigned and it is an error to override this. This ensures the agent can correctly deregister the sidecar service later when the parent service is removed.
    • - Service definitions can’t be nested recursively.
    • connect.proxy - (Deprecated) can’t be defined on a sidecar.
    • connect.native - Currently the kind is fixed to connect-proxy and it’s an error to register a connect-proxy that is also Connect-native.

    Sidecar service registration is mostly a configuration syntax helper to avoid adding lots of boiler plate for basic sidecar options, however the agent does have some specific behavior around their lifecycle that makes them easier to work with.

    The agent fixes the ID of the sidecar service to be based on the parent service’s ID. This enables the following behavior.

    • A service instance can only ever have one sidecar service registered.
    • When re-registering via API or reloading from configuration file:
      • If something changes in the nested sidecar service definition, the change will update the current sidecar registration instead of creating a new one.
      • If a service registration removes the nested then the previously registered sidecar for that service will be deregistered automatically.
    • When reloading the configuration files, if a service definition changes its ID, then a new service instance and a new sidecar instance will be registered. The old ones will be removed since they are no longer found in the config files.