CheckType is used to create either the CheckMonitor or the CheckTTL.
The following types are supported: Script, HTTP, TCP, Docker, TTL, GRPC, Alias, H2PING. Script,
HTTP, Docker, TCP, GRPC, and H2PING all require Interval. Only one of the types may
to be provided: TTL or Script/Interval or HTTP/Interval or TCP/Interval or
Docker/Interval or GRPC/Interval or AliasService or H2PING/Interval.
Since types like CheckHTTP and CheckGRPC derive from CheckType, there are
helper conversion methods that do the reverse conversion. ie. checkHTTP.CheckType()
ConnectProxyConfig describes the configuration needed for any proxy managed
or unmanaged. It describes a single logical service’s listener and optionally
upstreams and sidecar-related config for a single instance. To describe a
centralized proxy that routed traffic for multiple services, a different one
of these would be needed for each, sharing the same LogicalProxyID.
DeregisterRequest is used for the Catalog.Deregister endpoint to
deregister a service, check, or node (only one should be provided).
If ServiceID or CheckID are not provided, the entire node is deregistered.
If a ServiceID is provided, any associated Checks with that service
are also deregistered.
MeshGatewayConfig controls how Mesh Gateways are configured and used
This is a struct to allow for future additions without having more free-hanging
configuration items all over the place
RegisterRequest is used for the Catalog.Register endpoint
to register a node as providing a service. If no service
is provided, the node is registered.
ServiceNode represents a node that is part of a service. ID, Address,
TaggedAddresses, and NodeMeta are node-related fields that are always empty
in the state store and are filled in on the way out by parseServiceNodes().
This is also why PartialClone() skips them, because we know they are blank
already so it would be a waste of time to copy them.
This is somewhat complicated when the address is really a unix domain socket; technically that
will override the address field, but in practice the two use cases should not overlap.
Upstream represents a single upstream dependency for a service or proxy. It
describes the mechanism used to discover instances to communicate with (the
Target) as well as any potential client configuration that may be useful such
as load balancer options, timeouts etc.